5、Hadoop基本組件原理總結(jié)

1、kHadoop基本組件原理總結(jié)第一章1、簡(jiǎn)述hadoop平臺(tái)的發(fā)展過(guò)程 Hadoop的出現(xiàn)來(lái)源于Google的兩款產(chǎn)品：GFS和Mapreduce。2006年3月份，Map/Reduce和Nutch Disrtributed File System，DNFS）分別被納入Hadoop項(xiàng)目中，Hadoop主要由HDFS，MapReduce和Hbase組成。 Hadoop是一個(gè)能夠?qū)Υ罅繑?shù)據(jù)進(jìn)行分布式處理的軟件框架。 Hadoop 以一種可靠、高效、可伸縮的方式進(jìn)行數(shù)據(jù)處理。Hadoop來(lái)源于于Apach Nutch(一個(gè)開(kāi)源的網(wǎng)絡(luò)搜索引擎)，是Apach Lucene（文本搜索引擎庫(kù)）的一部分。H

2、adoop的名字不是英文的縮寫(xiě)，他是一個(gè)虛構(gòu)的名字，來(lái)自于創(chuàng)始人Doug Cutting孩子的一個(gè)大象玩具的名字。 Nutch項(xiàng)目開(kāi)始于2002年，一個(gè)可工作的抓取工具和搜索系統(tǒng)很快浮出水面。但是此時(shí)他們意識(shí)到，他們的架構(gòu)無(wú)法擴(kuò)展到數(shù)十億網(wǎng)頁(yè)的網(wǎng)絡(luò)。在2003年Google發(fā)表的一篇描述分布式文件系統(tǒng)（Google file system 簡(jiǎn)稱GFS）的論文給了他們啟發(fā)和幫助。論文中稱Google正在使用這個(gè)系統(tǒng)?？梢越鉀Q他們?cè)诰W(wǎng)絡(luò)抓取過(guò)程中產(chǎn)生大量數(shù)據(jù)文件的存儲(chǔ)需求，因此產(chǎn)生了Nutch中的分布式文件系統(tǒng)（NDFS）。在2004年，Google發(fā)表了論文，向全世界介紹了MapReduce，M

3、apReduce是一種用于數(shù)據(jù)處理的編程模型。而Hadoop的另外一個(gè)核心模塊MapReduce就是這篇論文的一個(gè)具體實(shí)現(xiàn)。Nutch中的NDFS和MapReduce實(shí)現(xiàn)的應(yīng)用遠(yuǎn)不止搜索領(lǐng)域。在2006年2月，他們從Nutch中轉(zhuǎn)移出來(lái)一個(gè)Lucene一個(gè)獨(dú)立的子項(xiàng)目，稱為Hadoop。大約在同一時(shí)間，Dong Cutting加入雅虎。雅虎提供了一個(gè)專門(mén)的團(tuán)隊(duì)和資源將Hadoop發(fā)展成為一個(gè)可在網(wǎng)絡(luò)上運(yùn)行的系統(tǒng)。2008年2月雅虎宣布其搜索引擎產(chǎn)品可部署在一個(gè)1萬(wàn)個(gè)內(nèi)核的Hadoop集群上。在2008年4月，Hadoop打破世界紀(jì)錄，稱為最快排序1T數(shù)據(jù)的系統(tǒng)（不到三分鐘），擊敗了前一年的29

4、7秒冠軍。同年11月Google在報(bào)告中稱他的MapReduce在執(zhí)行1T數(shù)據(jù)排序只用了68秒。在2009年5月，報(bào)告稱雅虎的團(tuán)隊(duì)使用Hadoop對(duì)1T數(shù)據(jù)進(jìn)行排序只用了62秒。2、簡(jiǎn)述Hasoop名稱和及技術(shù)來(lái)源。名稱：Hadoop 是由道格.卡丁虛構(gòu)出來(lái)的一個(gè)名字。技術(shù)來(lái)源：hadoop來(lái)源于Google的三篇論文：GFS、MapReduce、BigTable。最初搭建的hadoop系統(tǒng)就是從這三篇論文出發(fā)的。3、簡(jiǎn)述Hadoop的體系架構(gòu)。Hadoop是實(shí)現(xiàn)了分布式并行處理任務(wù)的系統(tǒng)框架，其核心組成是HDFS和MapReduce兩個(gè)子系統(tǒng)，能夠自動(dòng)完成大任務(wù)計(jì)算和大數(shù)據(jù)儲(chǔ)存的分割工作。H

5、adoop有眾多子集。例如：Common、Yarn、Avro、Chukwa、Hive、Hbase、Zookeeper等。這些生態(tài)工具對(duì)Hadoop起到了良好的補(bǔ)充作用。HDFS系統(tǒng)是Hadoop的儲(chǔ)存系統(tǒng)，能夠?qū)崿F(xiàn)創(chuàng)建文件、刪除文件、移動(dòng)文件等功能，操作的數(shù)據(jù)主要是要處理的原始數(shù)據(jù)以及計(jì)算過(guò)程中的中間數(shù)據(jù)，實(shí)現(xiàn)高吞吐量的數(shù)據(jù)讀寫(xiě)。MapReduce系統(tǒng)是一個(gè)分布式計(jì)算框架，主要任務(wù)就是利用廉價(jià)的計(jì)算機(jī)對(duì)海量的數(shù)據(jù)進(jìn)行分解處理。4、簡(jiǎn)述MapReduce的體系架構(gòu)。-分布式編程架構(gòu)-以數(shù)據(jù)為中心，更看重吞吐率-分而治之（把對(duì)大規(guī)模數(shù)據(jù)集的操作，分發(fā)給一個(gè)主節(jié)點(diǎn)管理下的各個(gè)分節(jié)點(diǎn)共同完成，然后整合

6、各個(gè)節(jié)點(diǎn)的中間結(jié)果得到最終的輸出）-Map把一個(gè)任務(wù)分解成多個(gè)子任務(wù)-Reduce將分解后的多任務(wù)分別處理，并將結(jié)果匯總為最終的結(jié)果應(yīng)用舉例：清點(diǎn)圖書(shū)館藏書(shū)、統(tǒng)計(jì)單詞的出現(xiàn)次數(shù)、混合辣椒醬的制作等等。MapReduce架構(gòu)圖解5、簡(jiǎn)述HDFS和MapReduce在Hadoop中的角色。 HDFS和MapReduce是hadoop中的核心組成系統(tǒng)，能夠自動(dòng)完成大任務(wù)的計(jì)算和大數(shù)據(jù)儲(chǔ)存的分割工作。 HDFS系統(tǒng)是hadoop系統(tǒng)的儲(chǔ)存系統(tǒng)，MapReduce系統(tǒng)是一個(gè)分布式計(jì)算框架，主任務(wù)是能夠利用廉價(jià)的計(jì)算機(jī)對(duì)海量的數(shù)據(jù)進(jìn)行分解處理，很大的一個(gè)優(yōu)點(diǎn)是計(jì)算向數(shù)據(jù)靠近，這樣就降低了數(shù)據(jù)傳輸?shù)某杀尽?

7、HDFS在MapReduce任務(wù)處理過(guò)程中提供了文件操作和存儲(chǔ)等支持，MapReduce在HDFS的基礎(chǔ)上實(shí)現(xiàn)了了任務(wù)的分發(fā)、跟蹤、執(zhí)行等操作，收集結(jié)果，二者相互作用，完成了Hadoop的分布式集群任務(wù)。6、Hadoop技術(shù)原理Hdfs主要模塊：NameNode、DataNodeYarn主要模塊：ResourceManager、NodeManager常用命令：1）用hadoop fs 操作hdfs網(wǎng)盤(pán),使用Uri的格式訪問(wèn)（URI格式：secheme:/authority/path ,默認(rèn)是hdfs:/namenode:namenode port /parent path / child ,

8、簡(jiǎn)寫(xiě)為/parent path / child）2）使用start-dfs.sh啟動(dòng)hdfs1 MR執(zhí)行流程：1）客戶端提交Mr 的jar包程序給JobClient2）JobClient通過(guò)RPC和JobTracker 進(jìn)行通信返回新的JOB ID 和路徑3）Client將jar包寫(xiě)入到HDFS當(dāng)中(提交10份)4）開(kāi)始提交任務(wù)（任務(wù)的描述信息，不是Jar），有任務(wù)的詳細(xì)信息5）JobTracker進(jìn)行初始化任務(wù)，把任務(wù)放到調(diào)度器中，在一臺(tái)機(jī)器上6）讀取HDFS上的要處理的文件，開(kāi)始計(jì)算輸入分片7）TaskTracker通過(guò)心跳機(jī)制領(lǐng)取任務(wù)8）下載所需要的jar，配置文件等9）TaskTrac

9、ker啟動(dòng)一個(gè)Java child子進(jìn)程10）將結(jié)果寫(xiě)入HDFS 當(dāng)中第二章1、簡(jiǎn)述HDFS的體系結(jié)構(gòu)。 HDFS集群有兩類節(jié)點(diǎn)并以管理者工作模式運(yùn)行，即一個(gè)管理者管理多個(gè)工作者。NameNode管理文件系統(tǒng)的命名空間。他是維護(hù)著文件系統(tǒng)樹(shù)和及其中的所有文件和目錄。這些信息以兩個(gè)文件保存次磁盤(pán)中：命名空間鏡像文件和編輯日志文件。NameNode同時(shí)也記錄著每個(gè)文件中各個(gè)數(shù)據(jù)塊在節(jié)點(diǎn)上的信息，但是她不是永久保存塊的信息，這些此信息會(huì)在系統(tǒng)啟動(dòng)時(shí)由數(shù)據(jù)節(jié)點(diǎn)重建。HDFS體系結(jié)構(gòu)如上圖所示，HDFS也是按照Master和Slave的結(jié)構(gòu)。分NameNode、SecondaryNameNode、Dat

10、aNode這幾個(gè)角色。NameNode：是Master節(jié)點(diǎn)，是大領(lǐng)導(dǎo)。管理數(shù)據(jù)塊映射；處理客戶端的讀寫(xiě)請(qǐng)求；配置副本策略；管理HDFS的名稱空間；SecondaryNameNode：是一個(gè)小弟，分擔(dān)大哥namenode的工作量；是NameNode的冷備份；合并fsimage和fsedits然后再發(fā)給namenode。DataNode：Slave節(jié)點(diǎn)，奴隸，干活的。負(fù)責(zé)存儲(chǔ)client發(fā)來(lái)的數(shù)據(jù)塊block；執(zhí)行數(shù)據(jù)塊的讀寫(xiě)操作。熱備份：b是a的熱備份，如果a壞掉。那么b馬上運(yùn)行代替a的工作。冷備份：b是a的冷備份，如果a壞掉。那么b不能馬上代替a工作。但是b上存儲(chǔ)a的一些信息，減少a壞掉之后的

11、損失。fsimage:元數(shù)據(jù)鏡像文件（文件系統(tǒng)的目錄樹(shù)。）edits：元數(shù)據(jù)的操作日志（針對(duì)文件系統(tǒng)做的修改操作記錄）namenode內(nèi)存中存儲(chǔ)的是=fsimage+edits。SecondaryNameNode負(fù)責(zé)定時(shí)默認(rèn)1小時(shí)，從namenode上，獲取fsimage和edits來(lái)進(jìn)行合并，然后再發(fā)送給namenode。減少namenode的工作量。2、描述HDFS讀數(shù)據(jù)的操作過(guò)程。（1）client訪問(wèn)NameNode，查詢?cè)獢?shù)據(jù)信息，獲得這個(gè)文件的數(shù)據(jù)塊位置列表，返回輸入流對(duì)象。（2）就近挑選一臺(tái)datanode服務(wù)器，請(qǐng)求建立輸入流 。（3）DataNode向輸入流中中寫(xiě)數(shù)據(jù)，以pa

12、cket為單位來(lái)校驗(yàn)。（4）關(guān)閉輸入流。 HDFS讀流程3、簡(jiǎn)述HDFS寫(xiě)流程。（1）客戶端向NameNode發(fā)出寫(xiě)文件請(qǐng)求。（2）檢查是否已存在文件、檢查權(quán)限。若通過(guò)檢查，直接先將操作寫(xiě)入EditLog，并返回輸出流對(duì)象。（注：WAL，write ahead log，先寫(xiě)Log，再寫(xiě)內(nèi)存，因?yàn)镋ditLog記錄的是最新的HDFS客戶端執(zhí)行所有的寫(xiě)操作。如果后續(xù)真實(shí)寫(xiě)操作失敗了，由于在真實(shí)寫(xiě)操作之前，操作就被寫(xiě)入EditLog中了，故EditLog中仍會(huì)有記錄，我們不用擔(dān)心后續(xù)client讀不到相應(yīng)的數(shù)據(jù)塊，因?yàn)樵诘?步中DataNode收到塊后會(huì)有一返回確認(rèn)信息，若沒(méi)寫(xiě)成功，發(fā)送端沒(méi)收到確認(rèn)

13、信息，會(huì)一直重試，直到成功）（3）client端按128MB的塊切分文件。（4）client將NameNode返回的分配的可寫(xiě)的DataNode列表和Data數(shù)據(jù)一同發(fā)送給最近的第一個(gè)DataNode節(jié)點(diǎn)，此后client端和NameNode分配的多個(gè)DataNode構(gòu)成pipeline管道，client端向輸出流對(duì)象中寫(xiě)數(shù)據(jù)。client每向第一個(gè)DataNode寫(xiě)入一個(gè)packet，這個(gè)packet便會(huì)直接在pipeline里傳給第二個(gè)、第三個(gè)DataNode。（注：并不是寫(xiě)好一個(gè)塊或一整個(gè)文件后才向后分發(fā)）（5）每個(gè)DataNode寫(xiě)完一個(gè)塊后，會(huì)返回確認(rèn)信息。（注：并不是每寫(xiě)完一個(gè)pa

14、cket后就返回確認(rèn)信息，個(gè)人覺(jué)得因?yàn)閜acket中的每個(gè)chunk都攜帶校驗(yàn)信息，沒(méi)必要每寫(xiě)一個(gè)就匯報(bào)一下，這樣效率太慢。正確的做法是寫(xiě)完一個(gè)block塊后，對(duì)校驗(yàn)信息進(jìn)行匯總分析，就能得出是否有塊寫(xiě)錯(cuò)的情況發(fā)生）（6）寫(xiě)完數(shù)據(jù)，關(guān)閉輸輸出流。（7）發(fā)送完成信號(hào)給NameNode。（注：發(fā)送完成信號(hào)的時(shí)機(jī)取決于集群是強(qiáng)一致性還是最終一致性，強(qiáng)一致性則需要所有DataNode寫(xiě)完后才向NameNode匯報(bào)。最終一致性則其中任意一個(gè)DataNode寫(xiě)完后就能單獨(dú)向NameNode匯報(bào)，HDFS一般情況下都是強(qiáng)調(diào)強(qiáng)一致性。HDFS寫(xiě)過(guò)程4、理解RPC通訊機(jī)制。（1）Remote Procedure

15、 Call（簡(jiǎn)稱RPC）：遠(yuǎn)程過(guò)程調(diào)用協(xié)議。（2）概括的說(shuō)，RPC采用客戶機(jī)/服務(wù)器模式。請(qǐng)求程序就是一個(gè)客戶機(jī)，而服務(wù)提供程序就是一個(gè)服務(wù)器。首先，客戶機(jī)調(diào)用進(jìn)程發(fā)送一個(gè)有進(jìn)程參數(shù)的調(diào)用信息到服務(wù)進(jìn)程，然后等待應(yīng)答信息。在服務(wù)器端，進(jìn)程保持睡眠狀態(tài)直到調(diào)用信息的到達(dá)為止。當(dāng)一個(gè)調(diào)用信息到達(dá)，服務(wù)器獲得進(jìn)程參數(shù)，計(jì)算結(jié)果，發(fā)送答復(fù)信息，然后等待下一個(gè)調(diào)用信息，最后，客戶端調(diào)用進(jìn)程接收答復(fù)信息，獲得進(jìn)程結(jié)果，然后調(diào)用執(zhí)行繼續(xù)進(jìn)行。（3）工作原理圖：根據(jù)HDFS的儲(chǔ)存原理來(lái)看，簡(jiǎn)單分為如下：client: 用戶提出讀/寫(xiě)數(shù)據(jù)的需求namenode：協(xié)調(diào)與把控datanodes：數(shù)據(jù)存儲(chǔ)，數(shù)量常常較

16、多。SecondaryNameNode有兩個(gè)作用，一是鏡像備份，二是日志與鏡像的定期合并。兩個(gè)過(guò)程同時(shí)進(jìn)行，稱為checkpoint. 鏡像備份的作用:備份fsimage(fsimage是元數(shù)據(jù)發(fā)送檢查點(diǎn)時(shí)寫(xiě)入文件);日志與鏡像的定期合并的作用:將Namenode中edits日志和fsimage合并,防止(如果Namenode節(jié)點(diǎn)故障，namenode下次啟動(dòng)的時(shí)候，會(huì)把fsimage加載到內(nèi)存中，應(yīng)用edit log,edit log往往很大，導(dǎo)致操作往往很耗時(shí)。5、HDFS主要模塊及運(yùn)行原理Hdfs主要模塊：Hdfs的塊的實(shí)際保存位置：tmpHdfsPath + /dfs/data/cur

17、rent/BP-126879239-13-1648462/cureent/finalized中，保存?zhèn)z文件一個(gè)是塊，一個(gè)是塊的描述信息，即：blk_1073434 、blk_1073434_1015.meta1）NameNode：功能：是整個(gè)文件系統(tǒng)的管理節(jié)點(diǎn)。維護(hù)整個(gè)文件系統(tǒng)的文件目錄樹(shù)，文件/目錄的元數(shù)據(jù)和每個(gè)文件對(duì)應(yīng)的數(shù)據(jù)塊列表。接收用戶的請(qǐng)求。存儲(chǔ)：存儲(chǔ)DataNode中各個(gè)文件的基本元數(shù)據(jù)信息，其中元數(shù)據(jù)存儲(chǔ)是瓶頸，因?yàn)樵獢?shù)據(jù)需要保存2份，一份存在內(nèi)存中(內(nèi)存中有3個(gè)文件，fsimage,edits，內(nèi)存中的metaData)，一份序列化到硬盤(pán)上，但是內(nèi)存空間有

18、限，如果不停的保存幾K的元數(shù)據(jù)，容易導(dǎo)致內(nèi)存的不足，同時(shí)由于不停的從內(nèi)存序列化到硬盤(pán)，也占CPU。結(jié)構(gòu)：fsimage元數(shù)據(jù)鏡像文件：存儲(chǔ)某一段時(shí)間的NameNode的內(nèi)存元數(shù)據(jù)信息(fsimage.ckpt文件)edits:操作日志文件。（上傳文件的過(guò)程中，不停的向edits寫(xiě)日志，不斷的追加，直到成功后，內(nèi)存的元數(shù)據(jù)才會(huì)更新元數(shù)據(jù)。edits都是從0開(kāi)始的）fstime:保存最近一次checkpoint的時(shí)間（checkpoint跟文件的一鍵還原點(diǎn)意義相同）以上文件都保存在Linux系統(tǒng)中,edits日志是實(shí)時(shí)保存在磁盤(pán)，但edits與fsimage是v2.0版本，才是實(shí)時(shí)保存，2.0沒(méi)有

19、SecondaryNameNode。2）DataNode：以下針對(duì)Hadoop V 1.0 、V 0 的版本SecondaryNameNode功能：是HA（高可用性）的一個(gè)解決方案，是備用鏡像，但不支持熱備執(zhí)行過(guò)程：1）Secondary通知NameNode切換edits文件2）Secondary從NameNode中獲取fsimage和edits（通過(guò)http），Secondary獲取文件后，NameNode會(huì)生成新的edits.new文件，該文件從0開(kāi)始。3）Secondary將fsimage載入內(nèi)存，然后開(kāi)始合并4）Secondary將新生成的fsimage,在本地保存，并將其推送到Nam

20、eNode5）NameNode替換舊的鏡像。說(shuō)明：SecondNameNode默認(rèn)是安裝在NameNode節(jié)點(diǎn)上，但是這樣不安全。Yarn主要模塊：ResourceManager、NodeManager常用命令：1、用hadoop fs 操作hdfs網(wǎng)盤(pán),使用Uri的格式訪問(wèn)（URI格式：secheme:/authority/path ,默認(rèn)是hdfs:/namenode:namenode port /parent path / child , 簡(jiǎn)寫(xiě)為/parent path / child）2、使用start-dfs.sh啟動(dòng)hdfs第三章1、簡(jiǎn)述MapReduce的進(jìn)程。MapReduce

21、工作流程圖主要步驟：MapReduce主要步驟敘述：Map階段：每個(gè) Mapper任務(wù)是一個(gè)Java進(jìn)程,它會(huì)讀取HDFS中的文件,解析成很多的鍵值對(duì)經(jīng)過(guò)我們覆蓋的map方法處理后,轉(zhuǎn)換為很多的鍵值對(duì)再輸出。 Mapper接收< ckey, value形式的數(shù)據(jù)并處理成< key, value>形式的數(shù)據(jù),具體的處理過(guò)程用戶可以定義Step 1：把輸入文件按照一定的標(biāo)準(zhǔn)分片( InputSplit),每個(gè)輸入片的大小是固定的。默認(rèn)情況下,輸入片( nputSplit的大小與數(shù)據(jù)塊( Block)的大小是相同的。如果數(shù)據(jù)塊( Block)的大小是默認(rèn)值64MB,輸入文件有兩個(gè),

22、一個(gè)是32MB,一個(gè)是72MB,那么小的文件是一個(gè)輸入片,大文件會(huì)分為兩個(gè)數(shù)據(jù)塊64MB和8MB,一共產(chǎn)生三個(gè)輸入片。每一個(gè)輸入片由一個(gè) Mapper進(jìn)程處理。這里的三個(gè)輸入片,會(huì)有三個(gè) Mapper進(jìn)程處理。Step 2：用對(duì)輸入片中的記錄按照一定的規(guī)則解析成鍵值對(duì)。有個(gè)默認(rèn)規(guī)則是把每一行文本內(nèi)容解析成鍵值對(duì)。“鍵”是每一行的起始位置(單位是字節(jié)),“值”是本行的文本內(nèi)容。Step 3：調(diào)用Mapr類中的mp方法。第二階段中解析出來(lái)的每一個(gè)鍵值對(duì),調(diào)用一次map方法。如果有1000個(gè)鍵值對(duì),就會(huì)調(diào)用1000次map方法。每一次調(diào)用map方法會(huì)輸出零個(gè)或者多個(gè)鍵值對(duì)。Step 4：按照一定的規(guī)

23、則對(duì)第三階段輸出的鍵值對(duì)進(jìn)行分區(qū)。比較是基于鍵進(jìn)行的。默認(rèn)是只有一個(gè)區(qū)。分區(qū)的數(shù)量就是 Reducer任務(wù)運(yùn)行的數(shù)量。默認(rèn)只有一個(gè) Reducer任務(wù)。Step 5：對(duì)每個(gè)分區(qū)中的鍵值對(duì)進(jìn)行排序。首先,按照鍵進(jìn)行排序,對(duì)于鍵相同的鍵值對(duì),按照值進(jìn)行排序。比如三個(gè)鍵值對(duì)<2,2>、<1,3>、<2,1>,鍵和值分別是整數(shù)。那么排序后的結(jié)果是<1,3>、<2,1>、<2,2>。如果有第六階段,那么進(jìn)入第六階段;如果沒(méi)有,直接輸出到本地的 Linux文件中。Step 6：是對(duì)數(shù)據(jù)進(jìn)行歸約處理,也就是 reduce處理。鍵相等的鍵

24、值對(duì)會(huì)調(diào)用次 reduce方法。經(jīng)過(guò)這一階段,數(shù)據(jù)量會(huì)減少。歸約后的數(shù)據(jù)輸出到本地的 Linux文件中。本階段默認(rèn)是沒(méi)有的,需要用戶自己增加這一階段的代碼。執(zhí)行過(guò)程Reduce階段;Reduce任務(wù)接收Maper任務(wù)的輸出，規(guī)約處理后寫(xiě)入到HDFS中。Reduce進(jìn)程Step 1：Reducer任務(wù)會(huì)主動(dòng)從 Mapper任務(wù)復(fù)制其輸出的鍵值對(duì)。 Mapper任務(wù)可能會(huì)有很多,因此 Reducer會(huì)復(fù)制多個(gè) Mapper的輸出。Step 2：把復(fù)制到 Reducer的本地?cái)?shù)據(jù),全部進(jìn)行合并,即把分散的數(shù)據(jù)合并成一個(gè)大的數(shù)據(jù)。再對(duì)合并后的數(shù)據(jù)排序。Step 3：對(duì)排序后的鍵值對(duì)調(diào)用 reduce方

25、法,鍵相等的鍵值對(duì)調(diào)用一次 reduce方法,每次調(diào)用會(huì)產(chǎn)生零個(gè)或者多個(gè)鍵值對(duì)。最后把這些輸出的鍵值對(duì)寫(xiě)入到HDFS文件中。2、簡(jiǎn)述Hadoop的數(shù)據(jù)類型優(yōu)勢(shì)。（1）Text:使用UTF8格式存儲(chǔ)的文本（2）NullWritable:當(dāng)<key, value>中的key或value為空時(shí)使用3、理解hadoop序列化和Java序列化對(duì)比。 Java的序列化機(jī)制是不停的創(chuàng)建對(duì)象，但是在Hadoop序列化機(jī)制中，用戶可以復(fù)用對(duì)象，這樣就減少了Java對(duì)象的分配和回收，提高了利用率。序列化：是指把結(jié)構(gòu)化對(duì)象轉(zhuǎn)化為字節(jié)流，便于在網(wǎng)上傳輸或?qū)懙酱疟P(pán)上進(jìn)行永久保存。反序列化：是序列化的反過(guò)程。

26、就是把字節(jié)流轉(zhuǎn)換為結(jié)構(gòu)對(duì)象。Hadoop系列化有如下特點(diǎn);（1）緊湊：高效使用儲(chǔ)存空間（2）快速：讀寫(xiě)數(shù)據(jù)的額外開(kāi)銷少（3）可擴(kuò)展性：可透明的讀取老格式的數(shù)據(jù)（4）互操作：支持多種語(yǔ)言的交互序列化的作用：（1）序列化在分布式環(huán)境的兩大作用：進(jìn)程間通訊，永久儲(chǔ)存。（2）Hadoop節(jié)點(diǎn)間通訊4、列舉MapReduce常用接口類。 MapReduce輸入的處理類（1） FileInputFormat（2） InputSplitMapReduce輸出的處理類。（1）TextOutputFormat（2）SequenceFileOutputFormat（3）SequenceFileAsOutputFo

27、rmat（4）MapFileOutputFormat（5）MultipleOutputFormat第四章1、簡(jiǎn)述YARN架構(gòu)的進(jìn)程。 YARN框架主要是由Client、ResourceManager、NodeManager等進(jìn)程。 主要工作流程步驟：（1）Client向ResourceManager提交任務(wù)。（2）ResourceManager分配創(chuàng)建Container任務(wù)并告知NodeManager啟動(dòng)進(jìn)程MAAppMaster。（3）NodeManager接收指定任務(wù)并開(kāi)辟空間啟動(dòng)MAAppMaster（4）NodeManager完成任務(wù)之后會(huì)及時(shí)匯報(bào)給ResourceManager（5）

28、MRAPPMaster和ResourceManager交互，獲取運(yùn)行任務(wù)所需的資源。（6）MPAPPMaster獲取資源后和NodeManager驚醒通訊，啟動(dòng)MapTask或ReduceTask（7）任務(wù)運(yùn)行正常，定時(shí)向MRAPPMaster回報(bào)工作情況。YARN計(jì)算過(guò)程圖2、理解YARN和MapReduce的對(duì)比。（1） YARN大大減少了Job Tracker的資源消耗，并且讓監(jiān)測(cè)每個(gè)Job子任務(wù)狀態(tài)的程序分布式化了。（2） YARN中Application Master是一個(gè)可變更部分，用戶可以對(duì)不同編程模型編寫(xiě)自己的AppMst，讓更多類型的編程模型能跑在Hadoop集群中。（3）老

29、的框架中，Job Tracker一個(gè)很大的負(fù)擔(dān)就是監(jiān)控Job下任務(wù)的運(yùn)行狀況，現(xiàn)在由Application Master去做，而Resource Manager是監(jiān)測(cè)Application Master的運(yùn)行狀況，如果出問(wèn)題，會(huì)將其在其他機(jī)器上重啟。第五章1、簡(jiǎn)述Hbase數(shù)據(jù)庫(kù)。（1）Hbase是一個(gè)可分布、可擴(kuò)展的大數(shù)據(jù)存儲(chǔ)的 Hadoop數(shù)據(jù)庫(kù)。適用于隨機(jī)、實(shí)時(shí)讀寫(xiě)大數(shù)據(jù)操作時(shí)使用。它的目標(biāo)就是擁有一張大表,支持億行億列。 Hbase目標(biāo)主要依靠橫向擴(kuò)展,通過(guò)不斷增加廉價(jià)的商用服務(wù)器,來(lái)增加計(jì)算和存儲(chǔ)能力（2）Hbase是一個(gè)分布式的、面向列的開(kāi)源數(shù)據(jù)庫(kù)源于Goge的一篇論文 bigta

30、ble個(gè)結(jié)構(gòu)化數(shù)據(jù)的分布式存儲(chǔ)系統(tǒng)Hbase是 Google Bigtable的開(kāi)源實(shí)現(xiàn),它利用 Hadoop HDFS作為其文件存儲(chǔ)系統(tǒng),利用 Hadoop MapReduce來(lái)處理 HBase中的海量數(shù)據(jù),利用keeper作為協(xié)同服務(wù)。（3） Hbase- Hadoop Database,是一個(gè)高可靠性、高性能、面向列、可伸縮的分布式存儲(chǔ)系統(tǒng),利用 HBase技術(shù)可在廉價(jià) PC Server上搭建起大規(guī)模結(jié)構(gòu)化存儲(chǔ)集群。 Hbase利用 Hadoop HDFS作為其文件存儲(chǔ)系統(tǒng),利用 Hadoop MapReduce.處理 Hbase中的海量數(shù),利用 Zookeeper作為協(xié)調(diào)工具（4）H

31、base表數(shù)據(jù)可以儲(chǔ)存在本地，也可以儲(chǔ)存在HDFS上。2、簡(jiǎn)述Hbase的架構(gòu)角色。（1）Client包含訪問(wèn) Hbase的接口, Client維護(hù)著一些 cache來(lái)加快對(duì) Hbase的訪問(wèn),比如 Region的位置信息（2）Zookeeper保證任何時(shí)候,集群中只有一個(gè) running master存儲(chǔ)所有 Region的尋址入口。實(shí)時(shí)監(jiān)控 Region Server的狀態(tài),將 Region Server的上線和下線信息,實(shí)時(shí)通知給 Master存儲(chǔ) Hbase的 schema,包括有哪些 table,每個(gè)tabe有哪些 column family（3）Master可以啟動(dòng)多個(gè)HMaste

32、r 通過(guò) Zookeeper的 Master Election機(jī)制保證總有一個(gè) Master運(yùn)行。為 Region Server分配 Region。負(fù)責(zé) Region Server的負(fù)載均衡。發(fā)現(xiàn)失效的 Region Server并重新分配其上的 Region（4）Region Server 維護(hù) Master分配給它的 Region,處理對(duì)這些 Region的o請(qǐng)求。負(fù)責(zé)切分在運(yùn)行過(guò)程中變得過(guò)大的 Regione。3、理解Hbase過(guò)濾器的作用。Hbase篩選數(shù)據(jù)提供了一起租過(guò)濾器，通過(guò)這個(gè)過(guò)濾器可以在Hbase中的數(shù)據(jù)的多個(gè)維度上進(jìn)行對(duì)數(shù)據(jù)篩選的操作，也就是說(shuō)過(guò)濾器最終能夠篩選的數(shù)據(jù)能夠細(xì)

33、化到具體的一個(gè)單元格上。通常來(lái)說(shuō)，通過(guò)行、鍵、值來(lái)篩選數(shù)據(jù)的場(chǎng)景應(yīng)用的比較多。第六章hadoop詳細(xì)了解5個(gè)進(jìn)程的作用概述：Hadoop是一個(gè)能夠?qū)Υ罅繑?shù)據(jù)進(jìn)行分布式處理的軟件框架，實(shí)現(xiàn)了Google的MapReduce編程模型和框架，能夠把應(yīng)用程序分割成許多的 小的工作單元，并把這些單元放到任何集群節(jié)點(diǎn)上執(zhí)行。在MapReduce中，一個(gè)準(zhǔn)備提交執(zhí)行的應(yīng)用程序稱為“作業(yè)（job）”，而從一個(gè)作業(yè)劃分出 得、運(yùn)行于各個(gè)計(jì)算節(jié)點(diǎn)的工作單元稱為“任務(wù)（task）”。此外，Hadoop提供的分布式文件系統(tǒng)（HDFS）主要負(fù)責(zé)各個(gè)節(jié)點(diǎn)的數(shù)據(jù)存儲(chǔ)，并實(shí)現(xiàn)了 高吞吐率的數(shù)據(jù)讀寫(xiě)。在分布式存儲(chǔ)和分布式計(jì)算方

34、面，Hadoop都是用從/從（Master/Slave）架構(gòu)。在一個(gè)配置完整的集群上，想讓Hadoop這頭大 象奔跑起來(lái)，需要在集群中運(yùn)行一系列后臺(tái)(deamon）程序。不同的后臺(tái)程序扮演不用的角色，這些角色由NameNode、DataNode、 Secondary NameNode、JobTracker、TaskTracker組成。其中NameNode、Secondary NameNode、JobTracker運(yùn)行在Master節(jié)點(diǎn)上，而在每個(gè)Slave節(jié)點(diǎn)上，部署一個(gè)DataNode和TaskTracker，以便 這個(gè)Slave服務(wù)器運(yùn)行的數(shù)據(jù)處理程序能盡可能直接處理本機(jī)的數(shù)據(jù)。對(duì)Mast

35、er節(jié)點(diǎn)需要特別說(shuō)明的是，在小集群中，Secondary NameNode可以屬于某個(gè)從節(jié)點(diǎn)；在大型集群中，NameNode和JobTracker被分別部署在兩臺(tái)服務(wù)器上。我們已經(jīng)很熟悉這個(gè)5個(gè)進(jìn)程，但是在使用的過(guò)程中，我們經(jīng)常遇到問(wèn)題，那么該如何入手解決這些問(wèn)題。那么首先我們需了解的他們的原理和作用。1.Namenode介紹Namenode 管理者文件系統(tǒng)的Namespace。它維護(hù)著文件系統(tǒng)樹(shù)(filesystem tree)以及文件樹(shù)中所有的文件和文件夾的元數(shù)據(jù)(metadata)。管理這些信息的文件有兩個(gè)，分別是Namespace 鏡像文件(Namespace image)和操作日志文

36、件(edit log)，這些信息被Cache在RAM中，當(dāng)然，這兩個(gè)文件也會(huì)被持久化存儲(chǔ)在本地硬盤(pán)。Namenode記錄著每個(gè)文件中各個(gè)塊所在的數(shù)據(jù)節(jié)點(diǎn)的位置信息，但是他并不持久化存儲(chǔ)這些信息，因?yàn)檫@些信息會(huì)在系統(tǒng)啟動(dòng)時(shí)從數(shù)據(jù)節(jié)點(diǎn)重建。 Namenode結(jié)構(gòu)圖課抽象為如圖：客戶端(client)代表用戶與namenode和datanode交互來(lái)訪問(wèn)整個(gè)文件系統(tǒng)?？蛻舳颂峁┝艘恍┝械奈募到y(tǒng)接口，因此我們?cè)诰幊虝r(shí)，幾乎無(wú)須知道datanode和namenode，即可完成我們所需要的功能。1.1Namenode容錯(cuò)機(jī)制沒(méi)有Namenode，HDFS就不能工作。事實(shí)上，如果運(yùn)行namenode的機(jī)器

37、壞掉的話，系統(tǒng)中的文件將會(huì)完全丟失，因?yàn)闆](méi)有其他方法能夠?qū)⑽挥诓煌琩atanode上的文件塊(blocks)重建文件。因此，namenode的容錯(cuò)機(jī)制非常重要，Hadoop提供了兩種機(jī)制。第一種方式是將持久化存儲(chǔ)在本地硬盤(pán)的文件系統(tǒng)元數(shù)據(jù)備份。Hadoop可以通過(guò)配置來(lái)讓Namenode將他的持久化狀態(tài)文件寫(xiě)到不同的文件系統(tǒng)中。這種寫(xiě)操作是同步并且是原子化的。比較常見(jiàn)的配置是在將持久化狀態(tài)寫(xiě)到本地硬盤(pán)的同時(shí)，也寫(xiě)入到一個(gè)遠(yuǎn)程掛載的網(wǎng)絡(luò)文件系統(tǒng)。第二種方式是運(yùn)行一個(gè)輔助的Namenode(Secondary Namenode)。 事實(shí)上Secondary Namenode并不能被用作Nameno

38、de它的主要作用是定期的將Namespace鏡像與操作日志文件(edit log)合并，以防止操作日志文件(edit log)變得過(guò)大。通常，Secondary Namenode 運(yùn)行在一個(gè)單獨(dú)的物理機(jī)上，因?yàn)楹喜⒉僮餍枰加么罅康腃PU時(shí)間以及和Namenode相當(dāng)?shù)膬?nèi)存。輔助Namenode保存著合并后的Namespace鏡像的一個(gè)備份，萬(wàn)一哪天Namenode宕機(jī)了，這個(gè)備份就可以用上了。但是輔助Namenode總是落后于主Namenode，所以在Namenode宕機(jī)時(shí)，數(shù)據(jù)丟失是不可避免的。在這種情況下，一般的，要結(jié)合第一種方式中提到的遠(yuǎn)程掛載的網(wǎng)絡(luò)文件系統(tǒng)(NFS)中的Namenod

39、e的元數(shù)據(jù)文件來(lái)使用，把NFS中的Namenode元數(shù)據(jù)文件，拷貝到輔助Namenode，并把輔助Namenode作為主Namenode來(lái)運(yùn)行。2、Datanode介紹Datanode是文件系統(tǒng)的工作節(jié)點(diǎn)，他們根據(jù)客戶端或者是namenode的調(diào)度存儲(chǔ)和檢索數(shù)據(jù)，并且定期向namenode發(fā)送他們所存儲(chǔ)的塊(block)的列表。集群中的每個(gè)服務(wù)器都運(yùn)行一個(gè)DataNode后臺(tái)程序，這個(gè)后臺(tái)程序負(fù)責(zé)把HDFS數(shù)據(jù)塊讀寫(xiě)到本地的文件系統(tǒng)。當(dāng)需要通過(guò)客戶端讀/寫(xiě)某個(gè) 數(shù)據(jù)時(shí)，先由NameNode告訴客戶端去哪個(gè)DataNode進(jìn)行具體的讀/寫(xiě)操作，然后，客戶端直接與這個(gè)DataNode服務(wù)器上的后臺(tái)

40、程序進(jìn)行通 信，并且對(duì)相關(guān)的數(shù)據(jù)塊進(jìn)行讀/寫(xiě)操作。3、Secondary NameNode介紹Secondary NameNode是一個(gè)用來(lái)監(jiān)控HDFS狀態(tài)的輔助后臺(tái)程序。就想NameNode一樣，每個(gè)集群都有一個(gè)Secondary NameNode，并且部署在一個(gè)單獨(dú)的服務(wù)器上。Secondary NameNode不同于NameNode，它不接受或者記錄任何實(shí)時(shí)的數(shù)據(jù)變化，但是，它會(huì)與NameNode進(jìn)行通信，以便定期地保存HDFS元數(shù)據(jù)的 快照。由于NameNode是單點(diǎn)的，通過(guò)Secondary NameNode的快照功能，可以將NameNode的宕機(jī)時(shí)間和數(shù)據(jù)損失降低到最小。同時(shí)，如果

41、NameNode發(fā)生問(wèn)題，Secondary NameNode可以及時(shí)地作為備用NameNode使用。3.1NameNode的目錄結(jié)構(gòu)如下：$.dir/current/VERSION /edits /fsimage /fstime3.2Secondary NameNode的目錄結(jié)構(gòu)如下：$fs.checkpoint.dir/current/VERSION /edits /fsimage /fstime /previous.checkpoint/VERSION /edits /fsimage /fstime 如上圖，Secondary NameNode主要是做Namespace

42、image和Edit log合并的。那么這兩種文件是做什么的？當(dāng)客戶端執(zhí)行寫(xiě)操作，則NameNode會(huì)在edit log記錄下來(lái)，（我感覺(jué)這個(gè)文件有些像Oracle的online redo logo file）并在內(nèi)存中保存一份文件系統(tǒng)的元數(shù)據(jù)。Namespace image（fsimage）文件是文件系統(tǒng)元數(shù)據(jù)的持久化檢查點(diǎn)，不會(huì)在寫(xiě)操作后馬上更新，因?yàn)閒simage寫(xiě)非常慢（這個(gè)有比較像datafile）。由于Edit log不斷增長(zhǎng)，在NameNode重啟時(shí)，會(huì)造成長(zhǎng)時(shí)間NameNode處于安全模式，不可用狀態(tài)，是非常不符合Hadoop的設(shè)計(jì)初衷。所以要周期性合并Edit log，但是這

43、個(gè)工作由NameNode來(lái)完成，會(huì)占用大量資源，這樣就出現(xiàn)了Secondary NameNode，它可以進(jìn)行image檢查點(diǎn)的處理工作。步驟如下：（1）Secondary NameNode請(qǐng)求NameNode進(jìn)行edit log的滾動(dòng)（即創(chuàng)建一個(gè)新的edit log），將新的編輯操作記錄到新生成的edit log文件；（2）通過(guò)http get方式，讀取NameNode上的fsimage和edits文件，到Secondary NameNode上；（3）讀取fsimage到內(nèi)存中，即加載fsimage到內(nèi)存，然后執(zhí)行edits中所有操作（類似OracleDG，應(yīng)用redo log），并生成一個(gè)新

44、的fsimage文件，即這個(gè)檢查點(diǎn)被創(chuàng)建；（4）通過(guò)http post方式，將新的fsimage文件傳送到NameNode；（5）NameNode使用新的fsimage替換原來(lái)的fsimage文件，讓（1）創(chuàng)建的edits替代原來(lái)的edits文件；并且更新fsimage文件的檢查點(diǎn)間。整個(gè)處理過(guò)程完成。Secondary NameNode的處理，是將fsimage和edites文件周期的合并，不會(huì)造成nameNode重啟時(shí)造成長(zhǎng)時(shí)間不可訪問(wèn)的情況。4、JobTracker介紹JobTracker后臺(tái)程序用來(lái)連接應(yīng)用程序與Hadoop。用戶代碼提交到集群以后，由JobTracker決定哪個(gè)文件將

45、被處理，并且為 不同的task分配節(jié)點(diǎn)。同時(shí)，它還監(jiān)控所有的task，一旦某個(gè)task失敗了，JobTracker就會(huì)自動(dòng)重新開(kāi)啟這個(gè)task，在大多數(shù)情況下這 個(gè)task會(huì)被放在不用的節(jié)點(diǎn)上。每個(gè)Hadoop集群只有一個(gè)JobTracker，一般運(yùn)行在集群的Master節(jié)點(diǎn)上。下面我們?cè)敿?xì)介紹：4.1JobClient我們配置好作業(yè)之后，就可以向JobTracker提交該作業(yè)了，然后JobTracker才能安排適當(dāng)?shù)腡askTracker來(lái)完成該作業(yè)。那么MapReduce在這個(gè)過(guò)程中到底做了那些事情呢？這就是本文以及接下來(lái)的一片博文將要討論的問(wèn)題，當(dāng)然本文主要是圍繞客戶端在作業(yè)的提交過(guò)程中

46、的工作來(lái)展開(kāi)。先從全局來(lái)把握這個(gè)過(guò)程吧！ 在Hadoop中，作業(yè)是使用Job對(duì)象來(lái)抽象的，對(duì)于Job，我首先不得不介紹它的一個(gè)大家伙JobClient客戶端的實(shí)際工作者。JobClient除了自己完成一部分必要的工作外，還負(fù)責(zé)與JobTracker進(jìn)行交互。所以客戶端對(duì)Job的提交，絕大部分都是JobClient完成的，從上圖中，我們可以得知JobClient提交Job的詳細(xì)流程主要如下： JobClient在獲取了JobTracker為Job分配的id之后，會(huì)在JobTracker的系統(tǒng)目錄(HDFS)下為該Job創(chuàng)建一個(gè)單獨(dú)的目錄，目錄的名字即是Job的id，該目錄下會(huì)包含文件job.xm

47、l、job.jar、job.split等，其中，job.xml文件記錄了Job的詳細(xì)配置信息，job.jar保存了用戶定義的關(guān)于job的map、reduce操縱，job.split保存了job任務(wù)的切分信息。在上面的流程圖中，我想詳細(xì)闡述的是JobClient是任何配置Job的運(yùn)行環(huán)境，以及如何對(duì)Job的輸入數(shù)據(jù)進(jìn)行切分。4.2JobTracker上面談到了客戶端的JobClient對(duì)一個(gè)作業(yè)的提交所做的工作，那么這里，就要好好的談一談JobTracker為作業(yè)的提交到底干了那些個(gè)事情一.為作業(yè)生成一個(gè)Job；二.接受該作業(yè)。我們都知道，客戶端的JobClient把作業(yè)的所有相關(guān)信息都保存到了

48、JobTracker的系統(tǒng)目錄下(當(dāng)然是HDFS了)，這樣做的一個(gè)最大的好處就是客戶端干了它所能干的事情同時(shí)也減少了服務(wù)器端JobTracker的負(fù)載。下面就來(lái)看看JobTracker是如何來(lái)完成客戶端作業(yè)的提交的吧！哦。對(duì)了，在這里我不得不提的是客戶端的JobClient向JobTracker正式提交作業(yè)時(shí)直傳給了它一個(gè)改作業(yè)的JobId，這是因?yàn)榕cJob相關(guān)的所有信息已經(jīng)存在于JobTracker的系統(tǒng)目錄下，JobTracker只要根據(jù)JobId就能得到這個(gè)Job目錄。對(duì)于上面的Job的提交處理流程，我將簡(jiǎn)單的介紹以下幾個(gè)過(guò)程：1.創(chuàng)建Job的JobInProgress JobInPro

49、gress對(duì)象詳細(xì)的記錄了Job的配置信息，以及它的執(zhí)行情況，確切的來(lái)說(shuō)應(yīng)該是Job被分解的map、reduce任務(wù)。在JobInProgress對(duì)象的創(chuàng)建過(guò)程中，它主要干了兩件事，一是把Job的job.xml、job.jar文件從Job目錄copy到JobTracker的本地文件系統(tǒng)(job.xml->*/jobTracker/jobid.xml，job.jar->*/jobTracker/jobid.jar)；二是創(chuàng)建JobStatus和Job的mapTask、reduceTask存隊(duì)列來(lái)跟蹤Job的狀態(tài)信息。2.檢查客戶端是否有權(quán)限提交Job JobTracker驗(yàn)證客戶端是

50、否有權(quán)限提交Job實(shí)際上是交給QueueManager來(lái)處理的。3.檢查當(dāng)前mapreduce集群能夠滿足Job的內(nèi)存需求 客戶端提交作業(yè)之前，會(huì)根據(jù)實(shí)際的應(yīng)用情況配置作業(yè)任務(wù)的內(nèi)存需求，同時(shí)JobTracker為了提高作業(yè)的吞吐量會(huì)限制作業(yè)任務(wù)的內(nèi)存需求，所以在Job的提交時(shí)，JobTracker需要檢查Job的內(nèi)存需求是否滿足JobTracker的設(shè)置。上面流程已經(jīng)完畢，可以總結(jié)為下圖：5、TaskTracker介紹TaskTracker與負(fù)責(zé)存儲(chǔ)數(shù)據(jù)的DataNode相結(jié)合，其處理結(jié)構(gòu)上也遵循主/從架構(gòu)。JobTracker位于主節(jié)點(diǎn)，統(tǒng)領(lǐng) MapReduce工作；而TaskTracke

51、rs位于從節(jié)點(diǎn)，獨(dú)立管理各自的task。每個(gè)TaskTracker負(fù)責(zé)獨(dú)立執(zhí)行具體的task，而 JobTracker負(fù)責(zé)分配task。雖然每個(gè)從節(jié)點(diǎn)僅有一個(gè)唯一的一個(gè)TaskTracker，但是每個(gè)TaskTracker可以產(chǎn)生多個(gè)java 虛擬機(jī)（JVM），用于并行處理多個(gè)map以及reduce任務(wù)。TaskTracker的一個(gè)重要職責(zé)就是與JobTracker交互。如果 JobTracker無(wú)法準(zhǔn)時(shí)地獲取TaskTracker提交的信息，JobTracker就判定TaskTracker已經(jīng)崩潰，并將任務(wù)分配給其他 節(jié)點(diǎn)處理。5.1TaskTracker內(nèi)部設(shè)計(jì)與實(shí)現(xiàn)Hadoop采用mas

52、ter-slave的架構(gòu)設(shè)計(jì)來(lái)實(shí)現(xiàn)Map-Reduce框架，它的JobTracker節(jié)點(diǎn)作為主控節(jié)點(diǎn)來(lái)管理和調(diào)度用戶提交的作業(yè)，TaskTracker節(jié)點(diǎn)作為工作節(jié)點(diǎn)來(lái)負(fù)責(zé)執(zhí)行JobTracker節(jié)點(diǎn)分配的Map/Reduce任務(wù)。整個(gè)集群由一個(gè)JobTracker節(jié)點(diǎn)和若干個(gè)TaskTracker節(jié)點(diǎn)組成，當(dāng)然，JobTracker節(jié)點(diǎn)也負(fù)責(zé)對(duì)TaskTracker節(jié)點(diǎn)進(jìn)行管理。在前面一系列的博文中，我已經(jīng)比較系統(tǒng)地講述了JobTracker節(jié)點(diǎn)內(nèi)部的設(shè)計(jì)與實(shí)現(xiàn)，而在本文，我將對(duì)TaskTracker節(jié)點(diǎn)的內(nèi)部設(shè)計(jì)與實(shí)現(xiàn)進(jìn)行一次全面的概述。 TaskTracker節(jié)點(diǎn)作為工作節(jié)點(diǎn)不僅要和Jo

53、bTracker節(jié)點(diǎn)進(jìn)行頻繁的交互來(lái)獲取作業(yè)的任務(wù)并負(fù)責(zé)在本地執(zhí)行他們，而且也要和其它的TaskTracker節(jié)點(diǎn)交互來(lái)協(xié)同完成同一個(gè)作業(yè)。因此，在目前的Hadoop-實(shí)現(xiàn)版本中，對(duì)工作節(jié)點(diǎn)TaskTracker的設(shè)計(jì)主要包含三類組件：服務(wù)組件、管理組件、工作組件。服務(wù)組件不僅負(fù)責(zé)與其它的TaskTracker節(jié)點(diǎn)而且還負(fù)責(zé)與JobTracker節(jié)點(diǎn)之間的通信服務(wù)，管理組件負(fù)責(zé)對(duì)該節(jié)點(diǎn)上的任務(wù)、作業(yè)、JVM實(shí)例以及內(nèi)存進(jìn)行管理，工作組件則負(fù)責(zé)調(diào)度Map/Reduce任務(wù)的執(zhí)行。這三大組件的詳細(xì)構(gòu)成如下：下面來(lái)詳細(xì)的介紹這三類組件：服務(wù)組件 TaskTracker節(jié)點(diǎn)內(nèi)部的服務(wù)組件不僅用來(lái)為T(mén)askTracker節(jié)點(diǎn)、客戶端提供服務(wù)，而且還負(fù)責(zé)向TaskTracker節(jié)點(diǎn)請(qǐng)求服務(wù)，這一類組件主要包括HttpServer、TaskReportServer、JobClient三大組件。1.HttpSer