hadoop中NameNode、DataNode、Secondary、NameNode、JobTra

Hadoop是一個可以對大量數據進行分佈式處理的軟件框架，實現了Google的MapReduce編程模型和框架，可以把應用程序分割成許多的 小的工做單元，並把這些單元放到任何集羣節點上執行。在MapReduce中，一個準備提交執行的應用程序稱爲「做業（job）」，而從一個做業劃分出 得、運行於各個計算節點的工做單元稱爲「任務（task）」。此外，Hadoop提供的分佈式文件系統（HDFS）主要負責各個節點的數據存儲，並實現了 高吞吐率的數據讀寫。

　　在分佈式存儲和分佈式計算方面，Hadoop都是用從/從（Master/Slave）架構。在一個配置完整的集羣上，想讓Hadoop這頭大 象奔跑起來，須要在集羣中運行一系列後臺(deamon）程序。不一樣的後臺程序扮演不用的角色，這些角色由NameNode、DataNode、 Secondary NameNode、JobTracker、TaskTracker組成。其中NameNode、Secondary  NameNode、JobTracker運行在Master節點上，而在每一個Slave節點上，部署一個DataNode和TaskTracker，以便 這個Slave服務器運行的數據處理程序能儘量直接處理本機的數據。對Master節點須要特別說明的是，在小集羣中，Secondary  NameNode能夠屬於某個從節點；在大型集羣中，NameNode和JobTracker被分別部署在兩臺服務器上。

咱們已經很熟悉這個5個進程，可是在使用的過程當中，咱們常常遇到問題，那麼該如何入手解決這些問題。那麼首先咱們需瞭解的他們的原理和做用。

1.Namenode

Namenode 管理者文件系統的Namespace。它維護着文件系統樹(filesystem tree)以及文件樹中全部的文件和文件夾的元數據(metadata)。管理這些信息的文件有兩個，分別是Namespace 鏡像文件(Namespace image)和操做日誌文件(edit log)，這些信息被Cache在RAM中，固然，這兩個文件也會被持久化存儲在本地硬盤。Namenode記錄着每一個文件中各個塊所在的數據節點的位置信息，可是他並不持久化存儲這些信息，由於這些信息會在系統啓動時從數據節點重建。

Namenode結構圖課抽象爲如圖：

客戶端(client)表明用戶與namenode和datanode交互來訪問整個文件系統。客戶端提供了一些列的文件系統接口，所以咱們在編程時，幾乎無須知道datanode和namenode，便可完成咱們所須要的功能。

1.1 Namenode容錯機制

沒有Namenode，HDFS就不能工做。事實上，若是運行namenode的機器壞掉的話，系統中的文件將會徹底丟失，由於沒有其餘方法可以將位於不一樣datanode上的文件塊(blocks)重建文件。所以，namenode的容錯機制很是重要，Hadoop提供了兩種機制。

第一種方式是將持久化存儲在本地硬盤的文件系統元數據備份。Hadoop能夠經過配置來讓Namenode將他的持久化狀態文件寫到不一樣的文件系統中。這種寫操做是同步而且是原子化的。比較常見的配置是在將持久化狀態寫到本地硬盤的同時，也寫入到一個遠程掛載的網絡文件系統。

第二種方式是運行一個輔助的Namenode(Secondary Namenode)。 事實上Secondary Namenode並不能被用做Namenode它的主要做用是按期的將Namespace鏡像與操做日誌文件(edit log)合併，以防止操做日誌文件(edit log)變得過大。一般，Secondary Namenode 運行在一個單獨的物理機上，由於合併操做須要佔用大量的CPU時間以及和Namenode至關的內存。輔助Namenode保存着合併後的Namespace鏡像的一個備份，萬一哪天Namenode宕機了，這個備份就能夠用上了。

可是輔助Namenode老是落後於主Namenode，因此在Namenode宕機時，數據丟失是不可避免的。在這種狀況下，通常的，要結合第一種方式中提到的遠程掛載的網絡文件系統(NFS)中的Namenode的元數據文件來使用，把NFS中的Namenode元數據文件，拷貝到輔助Namenode，並把輔助Namenode做爲主Namenode來運行。

二、Datanode

Datanode是文件系統的工做節點，他們根據客戶端或者是namenode的調度存儲和檢索數據，而且按期向namenode發送他們所存儲的塊(block)的列表。

集羣中的每一個服務器都運行一個DataNode後臺程序，這個後臺程序負責把HDFS數據塊讀寫到本地的文件系統。當須要經過客戶端讀/寫某個 數據時，先由NameNode告訴客戶端去哪一個DataNode進行具體的讀/寫操做，而後，客戶端直接與這個DataNode服務器上的後臺程序進行通 信，而且對相關的數據塊進行讀/寫操做。

三、Secondary NameNode

Secondary  NameNode是一個用來監控HDFS狀態的輔助後臺程序。就想NameNode同樣，每一個集羣都有一個Secondary  NameNode，而且部署在一個單獨的服務器上。Secondary  NameNode不一樣於NameNode，它不接受或者記錄任何實時的數據變化，可是，它會與NameNode進行通訊，以便按期地保存HDFS元數據的 快照。因爲NameNode是單點的，經過Secondary  NameNode的快照功能，能夠將NameNode的宕機時間和數據損失下降到最小。同時，若是NameNode發生問題，Secondary  NameNode能夠及時地做爲備用NameNode使用。

3.1NameNode的目錄結構以下：

${dfs.name.dir}/current/VERSION

                                         /edits

                                         /fsimage

                                         /fstime

3.2Secondary NameNode的目錄結構以下：

${fs.checkpoint.dir}/current/VERSION

                                                /edits

                                                /fsimage

                                                /fstime

                                /previous.checkpoint/VERSION

                                                                      /edits

                                                                      /fsimage

                                                                      /fstime

如上圖，Secondary NameNode主要是作Namespace image和Edit log合併的。

那麼這兩種文件是作什麼的？當客戶端執行寫操做，則NameNode會在edit log記錄下來，（我感受這個文件有些像Oracle的online redo logo file）並在內存中保存一份文件系統的元數據。

Namespace image（fsimage）文件是文件系統元數據的持久化檢查點，不會在寫操做後立刻更新，由於fsimage寫很是慢（這個有比較像datafile）。

因爲Edit log不斷增加，在NameNode重啓時，會形成長時間NameNode處於安全模式，不可用狀態，是很是不符合Hadoop的設計初衷。因此要週期性合併Edit log，可是這個工做由NameNode來完成，會佔用大量資源，這樣就出現了Secondary NameNode，它能夠進行image檢查點的處理工做。步驟以下：

（1）       Secondary NameNode請求NameNode進行edit log的滾動（即建立一個新的edit log），將新的編輯操做記錄到新生成的edit log文件；

（2）       經過http get方式，讀取NameNode上的fsimage和edits文件，到Secondary NameNode上；

（3）       讀取fsimage到內存中，即加載fsimage到內存，而後執行edits中全部操做（相似OracleDG，應用redo log），並生成一個新的fsimage文件，即這個檢查點被建立；

（4）       經過http post方式，將新的fsimage文件傳送到NameNode；

（5）       NameNode使用新的fsimage替換原來的fsimage文件，讓（1）建立的edits替代原來的edits文件；而且更新fsimage文件的檢查點時間。

整個處理過程完成。

Secondary NameNode的處理，是將fsimage和edites文件週期的合併，不會形成nameNode重啓時形成長時間不可訪問的狀況。

四、JobTracker

JobTracker後臺程序用來鏈接應用程序與Hadoop。用戶代碼提交到集羣之後，由JobTracker決定哪一個文件將被處理，而且爲 不一樣的task分配節點。同時，它還監控全部的task，一旦某個task失敗了，JobTracker就會自動從新開啓這個task，在大多數狀況下這 個task會被放在不用的節點上。每一個Hadoop集羣只有一個JobTracker，通常運行在集羣的Master節點上。

4.1JobClient

咱們配置好做業以後，就能夠向JobTracker提交該做業了，而後JobTracker才能安排適當的TaskTracker來完成該做業。那麼MapReduce在這個過程當中到底作了那些事情呢？這就是本文以及接下來的一片博文將要討論的問題，固然本文主要是圍繞客戶端在做業的提交過程當中的工做來展開。先從全局來把握這個過程吧！

在Hadoop中，做業是使用Job對象來抽象的，對於Job，我首先不得不介紹它的一個你們夥JobClient——客戶端的實際工做者。JobClient除了本身完成一部分必要的工做外，還負責與JobTracker進行交互。因此客戶端對Job的提交，絕大部分都是JobClient完成的，從上圖中，咱們能夠得知JobClient提交Job的詳細流程主要以下：

JobClient在獲取了JobTracker爲Job分配的id以後，會在JobTracker的系統目錄(HDFS)下爲該Job建立一個單獨的目錄，目錄的名字便是Job的id，該目錄下會包含文件job.xml、job.jar、job.split等，其中，job.xml文件記錄了Job的詳細配置信息，job.jar保存了用戶定義的關於job的map、reduce操縱，job.split保存了job任務的切分信息。在上面的流程圖中，我想詳細闡述的是JobClient是任何配置Job的運行環境，以及如何對Job的輸入數據進行切分。

4.2JobTracker

上面談到了客戶端的JobClient對一個做業的提交所作的工做，那麼這裏，就要好好的談一談JobTracker爲做業的提交到底幹了那些個事情——一.爲做業生成一個Job；二.接受該做業。

咱們都知道，客戶端的JobClient把做業的全部相關信息都保存到了JobTracker的系統目錄下(固然是HDFS了)，這樣作的一個最大的好處就是客戶端幹了它所能幹的事情同時也減小了服務器端JobTracker的負載。下面就來看看JobTracker是如何來完成客戶端做業的提交的吧！哦。對了，在這裏我不得不提的是客戶端的JobClient向JobTracker正式提交做業時直傳給了它一個改做業的JobId，這是由於與Job相關的全部信息已經存在於JobTracker的系統目錄下，JobTracker只要根據JobId就能獲得這個Job目錄。

對於上面的Job的提交處理流程，我將簡單的介紹如下幾個過程：

1.建立Job的JobInProgress

   JobInProgress對象詳細的記錄了Job的配置信息，以及它的執行狀況，確切的來講應該是Job被分解的map、reduce任務。在JobInProgress對象的建立過程當中，它主要乾了兩件事，一是把Job的job.xml、job.jar文件從Job目錄copy到JobTracker的本地文件系統(job.xml->*/jobTracker/jobid.xml，job.jar->*/jobTracker/jobid.jar)；二是建立JobStatus和Job的mapTask、reduceTask存隊列來跟蹤Job的狀態信息。

2.檢查客戶端是否有權限提交Job
    JobTracker驗證客戶端是否有權限提交Job其實是交給QueueManager來處理的。

3.檢查當前mapreduce集羣可以知足Job的內存需求
   客戶端提交做業以前，會根據實際的應用狀況配置做業任務的內存需求，同時JobTracker爲了提升做業的吞吐量會限制做業任務的內存需求，因此在Job的提交時，JobTracker須要檢查Job的內存需求是否知足JobTracker的設置。

上面流程已經完畢，能夠總結爲下圖：

五、TaskTracker

TaskTracker與負責存儲數據的DataNode相結合，其處理結構上也遵循主/從架構。JobTracker位於主節點，統領 MapReduce工做；而TaskTrackers位於從節點，獨立管理各自的task。每一個TaskTracker負責獨立執行具體的task，而 JobTracker負責分配task。雖然每一個從節點僅有一個惟一的一個TaskTracker，可是每一個TaskTracker能夠產生多個java 虛擬機（JVM），用於並行處理多個map以及reduce任務。TaskTracker的一個重要職責就是與JobTracker交互。若是 JobTracker沒法準時地獲取TaskTracker提交的信息，JobTracker就斷定TaskTracker已經崩潰，並將任務分配給其餘 節點處理。

5.1TaskTracker內部設計與實現

     Hadoop採用master-slave的架構設計來實現Map-Reduce框架，它的JobTracker節點做爲主控節點來管理和調度用戶提交的做業，TaskTracker節點做爲工做節點來負責執行JobTracker節點分配的Map/Reduce任務。整個集羣由一個JobTracker節點和若干個TaskTracker節點組成，固然，JobTracker節點也負責對TaskTracker節點進行管理。在前面一系列的博文中，我已經比較系統地講述了JobTracker節點內部的設計與實現，而在本文，我將對TaskTracker節點的內部設計與實現進行一次全面的概述。

      TaskTracker節點做爲工做節點不只要和JobTracker節點進行頻繁的交互來獲取做業的任務並負責在本地執行他們，並且也要和其它的TaskTracker節點交互來協同完成同一個做業。所以，在目前的Hadoop-0.20.2.0實現版本中，對工做節點TaskTracker的設計主要包含三類組件：服務組件、管理組件、工做組件。服務組件不只負責與其它的TaskTracker節點並且還負責與JobTracker節點之間的通訊服務，管理組件負責對該節點上的任務、做業、JVM實例以及內存進行管理，工做組件則負責調度Map/Reduce任務的執行。這三大組件的詳細構成以下：

下面來詳細的介紹這三類組件：

服務組件

     TaskTracker節點內部的服務組件不只用來爲TaskTracker節點、客戶端提供服務，並且還負責向TaskTracker節點請求服務，這一類組件主要包括HttpServer、TaskReportServer、JobClient三大組件。

1.HttpServer

     TaskTracker節點在其內部使用Jetty Web容器來開啓http服務，這個http服務一是用來爲客戶端提供Task日誌查詢服務，二是用來提供數據傳輸服務，即在執行Reduce任務時是經過TaskTracker節點提供的該http服務來獲取屬於本身的map輸出數據。這裏須要詳細介紹的是與該服務相關的配置參數，集羣管理者能夠經過TaskTracker節點的配置文件來配置該服務地址和端口號，對應的配置項爲：mapred.task.tracker.http.address。同時，爲了可以靈活的控制該該服務的吞吐量，管理者還能夠設置該http服務的內部工做線程數量，對應的配置爲：tasktracker.http.threads。

2.Task Reporter

       TaskTracker節點在接收到JobTracker節點發送過來的Map/Reduce任務以後，會把它們交給JVM實例來執行，而本身則須要收集這些任務的執行進度信息，這就使得Task在JVM實例中執行的時候須要不斷地向TaskTracker節點報告當前的執行狀況。雖然TaskTracker節點和JVM實例在同一臺機器上，可是它們之間的進程通訊倒是經過網絡I/O來完成的(此處並不討論這種通訊方式的性能)，也就是TaskTracker節點在其內部開啓一個端口來專門爲任務實例提供進度報告服務。該服務地址能夠經過配置項mapred.task.tracker.report.address來設置，而服務內部的工做線程的數量取2倍於該TaskTracker節點上的Map/Reduce Slot數量中的大者。