2023年2月27日
Q1.簡(jiǎn)述Hadoop小文件弊端：
在第三章介紹HDFS時(shí)，3.1.2章節(jié)已指出HDFS無(wú)法高效存儲(chǔ)大量小文件。針對(duì)hadoop小文件弊端，我想從三個(gè)方面來(lái)回答：
1）定義：
指文件大小小于一個(gè)塊的文件（HDFS默認(rèn)是64MB）；
2）弊端：
a.NameNode檢索效率大大降低：HDFS使用NameNode來(lái)管理文件系統(tǒng)的元數(shù)據(jù)，并保存在內(nèi)存當(dāng)中，客戶端通過(guò)檢索元數(shù)據(jù)，可以快速獲取文件實(shí)際存儲(chǔ)位置。此時(shí)，如果小文件非常多，則NameNode要消耗很大的內(nèi)存來(lái)保存元數(shù)據(jù)信息，客戶端檢索元數(shù)據(jù)的效率也大大降低，需要耗費(fèi)較多時(shí)間才能獲取文件的實(shí)際存儲(chǔ)位置；
b.Map任務(wù)大幅增加，性價(jià)比低：Mapreduce處理大量小文件時(shí)，產(chǎn)生過(guò)多Map任務(wù)，線程管理開(kāi)銷大幅增加，性價(jià)比非常低；
c.嚴(yán)重影響HDFS性能：訪問(wèn)大量小文件時(shí)，需要頻繁在不同DataNode之間跳轉(zhuǎn)訪問(wèn)，性能影響較大。
3）解決方案：
將多個(gè)小文件進(jìn)行合并，可以設(shè)置小文件閾值，超限值的小文件可以進(jìn)行合并處理。如：利用Apache官方工具去合并HDFS上的小文件（Hadoop Archive）。
Q2.HDFS中DataNode掛掉如何處理?
1）正常情況下：
當(dāng)客戶端上傳文件時(shí)，它與DataNode建立pipeline管道。一方面，客戶端會(huì)向DataNode發(fā)送數(shù)據(jù)包，另一方面，DataNode在接收到數(shù)據(jù)包之后，會(huì)向客戶端發(fā)送ack確認(rèn)；
2）突然掛掉時(shí)：
客戶端接收不到DataNode的ack確認(rèn)，此時(shí)客戶端會(huì)通知NameNode，NameNode檢查該塊的副本，并通知另一個(gè)DataNode復(fù)制副本，將掛掉的DataNode下線，不再讓DataNode參與文件上傳下載。
Q3.HDFS中NameNode掛掉如何處理？
1）方式一：
將SecondaryNameNode中數(shù)據(jù)拷貝到NameNode存儲(chǔ)數(shù)據(jù)的目錄，用于恢復(fù)NameNode目錄；
2）方式二：
使用-importCheckpoint選項(xiàng)啟動(dòng)NameNode守護(hù)進(jìn)程，從而將SecondaryNameNode中數(shù)據(jù)拷貝到NameNode目錄中。
Q4.HBase讀寫流程？
1）讀流程：
a.Client客戶端先訪問(wèn)zookeeper,獲取meta表位于哪個(gè)Region Server；
b.訪問(wèn)meta表對(duì)應(yīng)的Region Server服務(wù)器，根據(jù)請(qǐng)求的信息（namespace,table,rowkey)，查詢出目標(biāo)表位于哪個(gè)Region Server中的哪個(gè)region。并將該表的region信息，以及meta表的位置信息緩存在客戶端的緩存中，以便下次訪問(wèn);
c.與目標(biāo)表所在的Region Server進(jìn)行通訊;
d.分別在Block Cache（讀緩存），MemStore和Store File查詢目標(biāo)數(shù)據(jù)，并將查到的數(shù)據(jù)進(jìn)行合并，此處所有數(shù)據(jù)是指同一條數(shù)據(jù)的不同版本（time stamp）或者不同的類型;
e.將從文件中查詢到的數(shù)據(jù)塊緩存到block cache;
f.將合并后的數(shù)據(jù)返回給客戶端。
2）寫流程：
a.客戶端先訪問(wèn)zookeeper，獲取Meta表位于那個(gè)region server;
b.訪問(wèn)Meta表對(duì)應(yīng)的region server服務(wù)器，根據(jù)請(qǐng)求的信息（namespace:table/rowkey）,在meta表中查詢出目標(biāo)數(shù)據(jù)位于哪個(gè)region server的哪個(gè)region中。并將該表的region信息以及meta表的位置信息緩存到客戶端的meta cache，方便下次訪問(wèn);
c.與目標(biāo)數(shù)據(jù)的region server進(jìn)行通訊;
d.將數(shù)據(jù)寫入到WAL中;
e.將數(shù)據(jù)寫入到對(duì)應(yīng)的memstore中;
f.向客戶端發(fā)送寫入成功的信息;
g.等達(dá)到memstore的刷寫時(shí)機(jī)后，將數(shù)據(jù)刷寫到HFILE中。
Q5.MapReduce為什么一定要有Shuffle過(guò)程
1）Shuffle：
是指對(duì)Map輸出結(jié)果進(jìn)行分區(qū)、排序、合并等處理并交給Reduce的過(guò)程；
2）針對(duì)不同的Map，有可能輸出相同的Key，相同的Key必須發(fā)送到同一個(gè)Reduce端處理，因此需要Shuffle進(jìn)行排序分區(qū)，減少跨節(jié)點(diǎn)數(shù)據(jù)傳輸?shù)馁Y源消耗。將數(shù)據(jù)完整的從map task端拉取數(shù)據(jù)到reduce task端，以減少磁盤IO對(duì)task的影響。
Q6.MapReduce中的三次排序
1）當(dāng)map函數(shù)產(chǎn)生輸出時(shí)，會(huì)首先寫入內(nèi)存的環(huán)形緩沖區(qū)，當(dāng)達(dá)到設(shè)定的閥值，在刷寫磁盤之前，后臺(tái)線程會(huì)將緩沖區(qū)的數(shù)據(jù)劃分成相應(yīng)的分區(qū)。在每個(gè)分區(qū)中，后臺(tái)線程按鍵進(jìn)行內(nèi)排序；
2）在Map任務(wù)完成之前，磁盤上存在多個(gè)已經(jīng)分好區(qū)，并排好序的，大小和緩沖區(qū)一樣的溢寫文件，這時(shí)溢寫文件將被合并成一個(gè)已分區(qū)且已排序的輸出文件。由于溢寫文件已經(jīng)經(jīng)過(guò)第一次排序，所有合并文件只需要再做一次排序即可使輸出文件整體有序；
3）在reduce階段，需要將多個(gè)Map任務(wù)的輸出文件copy到ReduceTask中后合并，由于經(jīng)過(guò)第二次排序，所以合并文件時(shí)只需再做一次排序即可使輸出文件整體有序。
Q7.MapReduce為什么不能產(chǎn)生過(guò)多小文件
1）MapReduce小文件問(wèn)題：
是指每個(gè)Map任務(wù)的啟動(dòng)需要消耗一定的時(shí)間，并且這個(gè)過(guò)程是非常消耗性能的，當(dāng)小文件非常多的時(shí)候，就會(huì)切出大量InputSplit，而每個(gè)Split對(duì)應(yīng)一個(gè)Map任務(wù)，這些任務(wù)的運(yùn)行時(shí)間極短，但啟動(dòng)時(shí)間累加也是一個(gè)大數(shù)目。
2）可以考慮在數(shù)據(jù)處理時(shí)，就將小文件合并成大文件，再上傳到HDFS做后續(xù)的分析。
Q8.實(shí)戰(zhàn)
1）MRJob及MRStep是新接觸的工具包，首先熟悉了這兩個(gè)工具包的使用。參考了以下博文：
https://blog.csdn.net/qq_41474121/article/details/109119761
https://www.cnpython.com/tags/476019
2）明確需要解決的問(wèn)題，主要需對(duì)以下四個(gè)子函數(shù)進(jìn)行填空，用于計(jì)算用戶訪問(wèn)過(guò)的每個(gè)位置的簽到概率：
a.mapper(self,_,line):#填入mapper的具體步驟
b.combiner(self,key,values):#填入combiner的具體步驟
c.reducer_init(self):# 填入reducer_init的具體步驟
d.reducer(self,key,values):# 填入reducer的具體步驟
3)代碼填空解答：
這塊還需要再思考和實(shí)踐，一時(shí)之間尚無(wú)頭緒，未完待續(xù)...
學(xué)習(xí)資源引自datawhale開(kāi)源學(xué)習(xí)課程~感恩！
https://github.com/datawhalechina/juicy-bigdata
https://datawhalechina.github.io/juicy-bigdata/#/
