問題導讀：
1.job的本質是什麼？
2.任務的本質是什麼？
3.檔案系統的Namespace由誰來管理，Namespace的作用是什麼？
4.Namespace 鏡像檔案(Namespace image)和記錄檔檔案(edit log)檔案的作用是什麼？
5.Namenode記錄着每個檔案中各個塊所在的資料節點的位置資訊，但是他并不持久化存儲這些資訊，為什麼？
6.用戶端讀寫某個資料時，是否通過NameNode？
7.namenode，datanode，Namespace image，Edit log之間的關系是什麼？
8.一旦某個task失敗了，JobTracker如何處理？
9.JobClient JobClient在擷取了JobTracker為Job配置設定的id之後，會在JobTracker的系統目錄(HDFS)下為該Job建立一個單獨的目錄，目錄的名字即是Job的id，該目錄下
會包含檔案job.xml、job.jar等檔案，這兩個檔案的作用是什麼？
10.JobTracker根據什麼就能得到這個Job目錄？
11.JobTracker送出作業之前，為什麼要檢查記憶體？
12.每個TaskTracker産生多個java 虛拟機（JVM）的原因是什麼？
概述：
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.1Namenode容錯機制
沒有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來運作。
----------------------------------------------------------------------------------------------------------------------------------------------------
2、Datanode介紹
Datanode是檔案系統的工作節點，他們根據用戶端或者是namenode的排程存儲和檢索資料，并且定期向namenode發送他們所存儲的塊(block)的清單。
叢集中的每個伺服器都運作一個DataNode背景程式，這個背景程式負責把HDFS資料塊讀寫到本地的檔案系統。當需要通過用戶端讀/寫某個 資料時，先由NameNode告訴用戶端去哪個DataNode進行具體的讀/寫操作，然後，用戶端直接與這個DataNode伺服器上的背景程式進行通 信，并且對相關的資料塊進行讀/寫操作。
---------------------------------------------------------------------------------------------------------------------------------------------------
3、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重新開機時造成長時間不可通路的情況。
--------------------------------------------------------------------------------------------------------------------------------------------------
4、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的設定。
上面流程已經完畢，可以總結為下圖：
--------------------------------------------------------------------------------------------------------------------------
5、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數量中的大者。
本文轉自 zouqingyun 51CTO部落格，原文連結：http://blog.51cto.com/zouqingyun/1656353，如需轉載請自行聯系原作者