問題導讀：
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）的原因是什么？
概述：
<ignore_js_op>
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介紹
2、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的目錄結構如下：
3.2Secondary NameNode的目錄結構如下：
4、JobTracker介紹
4.1JobClient
在Hadoop中，作業是使用Job對象來抽象的，對於Job，我首先不得不介紹它的一個大家伙JobClient——客戶端的實際工作者。JobClient除了自己完成一部分必要的工作外，還負責與JobTracker進行交互。所以客戶端對Job的提交，絕大部分都是JobClient完成的，從上圖中，我們可以得知JobClient提交Job的詳細流程主要如下：
4.2JobTracker
上面談到了客戶端的JobClient對一個作業的提交所做的工作，那么這里，就要好好的談一談JobTracker為作業的提交到底干了那些個事情——一.為作業生成一個Job；二.接受該作業。
我們都知道，客戶端的JobClient把作業的所有相關信息都保存到了JobTracker的系統目錄下(當然是HDFS了)，這樣做的一個最大的好處就是客戶端干了它所能干的事情同時也減少了服務器端JobTracker的負載。下面就來看看JobTracker是如何來完成客戶端作業的提交的吧！哦。對了，在這里我不得不提的是客戶端的JobClient向JobTracker正式提交作業時直傳給了它一個改作業的JobId，這是因為與Job相關的所有信息已經存在於JobTracker的系統目錄下，JobTracker只要根據JobId就能得到這個Job目錄。
<ignore_js_op>
對於上面的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的設置。
上面流程已經完畢，可以總結為下圖：
<ignore_js_op>
--------------------------------------------------------------------------------------------------------------------------
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數量中的大者。
| 1.job的本質是什么？ 在MapReduce中，一個准備提交執行的應用程序稱為“作業（job）” 2.任務的本質是什么？ 從一個作業划分出 得、運行於各個計算節點的工作單元稱為“任務（task）” 3.文件系統的Namespace由誰來管理，Namespace的作用是什么？ Namenode 管理者文件系統的Namespace 4.Namespace 鏡像文件(Namespace image)和操作日志文件(edit log)文件的作用是什 么？ Namenode 管理者文件系統的Namespace。它維護着文件系統樹(filesystem tree)以及 文件樹中所有的文件和文件夾的元數據(metadata)。管理這些信息的文件有兩個，分 別是Namespace 鏡像文件(Namespace image)和操作日志文件(edit log) 5.Namenode記錄着每個文件中各個塊所在的數據節點的位置信息，但是他並不持久化 存儲這些信息，為什么？ 因為這些信息會在系統啟動因為這些信息會在系統啟動時從數據節點重建。 6.客戶端讀寫某個數據時，是否通過NameNode？ 當需要通過客戶端讀/寫某個 數據時，先由NameNode告訴客戶端去哪個DataNode進行 具體的讀/寫操作，然后，客戶端直接與這個DataNode服務器上的后台程序進行通 信 ，並且對相關的數據塊進行讀/寫操作。 8.一旦某個task失敗了，JobTracker如何處理？ 一旦某個task失敗了，JobTracker就會自動重新開啟這個task 9.JobClient JobClient在獲取了JobTracker為Job分配的id之后，會在JobTracker的 系統目錄(HDFS)下為該Job創建一個單獨的目錄，目錄的名字即是Job的id，該目錄下 會包含文件job.xml、job.jar等文件，這兩個文件的作用是什么？ 10.JobTracker根據什么就能得到這個Job目錄？ JobTracker只要根據JobId就能得到這個Job目錄。 11.JobTracker提交作業之前，為什么要檢查內存？ 客戶端提交作業之前，會根據實際的應用情況配置作業任務的內存需求，同時 JobTracker為了提高作業的吞吐量會限制作業任務的內存需求，所以在Job的提交時， JobTracker需要檢查Job的內存需求是否滿足JobTracker的設置。 12.每個TaskTracker產生多個java 虛擬機（JVM）的原因是什么？ 每個TaskTracker可以產生多個java 虛擬機（JVM），用於並行處理多個map以及reduce任務 |