Hadoop

官網：http://hadoop.apache.org/

The Apache™ Hadoop® project develops open-source software for reliable, scalable, distributed computing.

The Apache Hadoop software library is a framework that allows for the distributed processing of large data sets across clusters of computers using simple programming models. It is designed to scale up from single servers to thousands of machines, each offering local computation and storage. Rather than rely on hardware to deliver high-availability, the library itself is designed to detect and handle failures at the application layer, so delivering a highly-available service on top of a cluster of computers, each of which may be prone to failures.

以上爲官網首頁介紹，大體翻譯過來以下：

Apache™Hadoop®項目開發了用於可靠，可擴展的分佈式計算的開源軟件。

Apache Hadoop軟件庫是一個框架，容許使用簡單的編程模型跨計算機集羣分佈式處理大型數據集。 它旨在從單個服務器擴展到數千臺計算機，每臺計算機都提供本地計算和存儲。 庫自己不是依靠硬件來提供高可用性，而是設計用於檢測和處理應用程序層的故障，從而在計算機集羣之上提供高可用性服務，每一個計算機均可能容易出現故障。

1.什麼是hadoop  1.x和2.x區別

hadoop1.x版本只有hdfs和mapreduce，而2.x包含hdfs，mapreduce,yarn

hdfs:分佈式文件存儲系統，它存儲 Hadoop 集羣中全部存儲節點上的文件。對外部客戶機而言，HDFS 就像一個傳統的分級文件系統。能夠建立、刪除、移動或重命名文件，等等。hdfs存儲文件其實分爲兩個部分，一個是存儲文件元數據的namenode（文件系統的命名空間，文件名稱，文件目錄結構，文件的屬性[權限,建立時間,副本數]，文件對應哪些數據塊–>數據塊對應哪些datanode節點，固然namenode節點不會持久的存儲這種映射關係,是經過集羣在啓動和運時,datanode按期發送blockReport給namenode,以此namenode在內存中來動態維護的這種映射關係）節點，另外一個是存儲文件實際數據的datanode（數據塊和數據塊校驗和、與Namenode通訊、每隔3秒發送一個心跳包、每十次心跳發送一次blockReport）節點。其中namenode維護文件系統元數據是根據兩個文件進行的，一個是記錄文件最新數據的fsimage文件，另外一個則是記錄修改歷史的editlog文件。存儲文件是以block塊的方式進行存儲的，一個block默認128M，也有不多的64M。這裏就存在了一個容錯機制他的一個副本策略的問題，默認一份數據會有三個block，當前機器存儲一份（數據本地化），另一個機架存儲一份，該機架的不一樣機器存儲一份。

 

1. 第一副本：放置在上傳文件的DataNode上;若是是集羣外提交，則隨機挑選一臺磁盤不太慢、CPU不太忙的節點上;
2. 第二副本：放置在於第一個副本不一樣的機架的節點上;
3. 第三副本：與第二個副本相同機架的不一樣節點上;
4. 若是還有更多的副本：隨機放在節點中; 

 

　　　　　　　　　　　　　　　　　　　　　　　　　　　　副本放置策略

 

hdfs文件的讀寫流程：

 

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　文件寫流程

 

1. Client調用FileSystem.creat(filePath)方法，建立文件； 
2. FileSystem與元數據節點進行RPC通訊，在文件系統的命名空間中建立一個新的文件，元數據節點首先肯定文件原來不存在，而且客戶端有建立文件的權限，而後建立新文件，可是並不關聯任何block。(假如不成功,就返回錯誤信息,因此寫代碼要try-catch)； 
3. FileSystem返回FSDataOutputStream對象，客戶端進行寫數據；在client寫入數據時，FSDataOutputStream對象將它分紅一個個的包，寫入內部隊列，稱爲數據隊列（data queue）。數據流（Data Streamer）處理數據隊列，數據流的責任是根據適合的datanode的列表要求namenode分配適合的新塊來存儲數據副本。這一組datanode列表造成一個管線（pipeline）————默認副本數是3，因此有3個節點在管線中； 
4. 數據流將包分流給管線中第一個的datanode，這個節點會存儲包而且發送給管線中的第二個datanode。一樣地，第二個datanode存儲包而且傳給管線中的第三個數據節點； 
5. DFSOutputStream也有一個內部的數據包隊列來等待數據節點（datanode）收到確認，稱爲確認隊列。一個包只有在被管線中全部的節點確認後纔會被移除出確認隊列，此時數據寫入成功； 
6. 當客戶端結束寫入數據，則調用stream的close函數。 
7. 最後再調用FileSystem.complete()方法,告訴元數據節點寫入成功。 
注意：若是數據節點（datanode）在寫入的過程當中失敗，關閉管線（pipeline），確認隊列中的任何包都會被添加回數據隊列的前面，當前的數據塊在已經寫入的數據節點中被元數據節點賦予新的標示，則錯誤節點重啓後可以察覺其數據塊是過期的，會被刪除。失敗的數據節點從管線（pipeline）中移除，另外的數據塊則寫入pipeline中的另外兩個數據節點。元數據節點則被通知此數據塊是複製塊數不足，未來會再建立第三份備份。

總結：這一方法不只提供了很好的穩定性（數據塊存儲在兩個機架中）並實現很好的負載均衡，包括寫入帶寬（寫入操做只須要遍歷一個交換機）、讀取性能（能夠從兩個機架中選擇讀取）和集羣中塊的均勻分佈（客戶端只在本地機架上寫入一個塊）。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　文件讀流程

 1. 初始化FileSystem，而後客戶端(client)用FileSystem的open()函數打開文件； 
2. FileSystem用RPC調用元數據節點，獲得文件的數據塊信息，對於每個數據塊，元數據節點返回保存數據塊的數據節點的地址； 
3. FileSystem返回FSDataInputStream給客戶端，用來讀取數據，客戶端調用stream的read()函數開始讀取數據（固然讀操做對於Client端是透明的）； 
4. 這些datanode根據他們與client的距離來排序（根據網絡集羣的拓撲）。若是該client自己就是一個datanode，便從本地datanode中讀取；（體現了數據本地化） 
5. 當此數據塊讀取完畢時，FSDataInputStream關閉和此數據節點的鏈接，而後鏈接此文件下一個數據塊的最近的數據節點； 
6. 當客戶端讀取完畢數據的時候，調用FSDataInputStream的close函數，關閉輸入流。 

注意：在讀取的時候，若是client與datanode通訊時遇到一個錯誤，那麼它就會去嘗試對這個塊來講下一個最近的塊。它也會記住那個故障節點的datanode，以保證不會再對以後的塊進行徒勞無益的嘗試。client也會確認datanode發來的數據的校驗和。若是發現一個損壞的塊，它就會在client試圖從別的datanode中讀取一個塊的副本以前報告給namenode。 

這個設計的一個重點是，client直接聯繫datanode去檢索數據，並被namenode指引到塊中最好的datanode。由於數據流在此集羣中是在全部datanode分散進行的。因此這種設計能使HDFS可擴展到最大的併發client數量。同時，namenode只不過提供塊的位置請求（存儲在內存中，十分高效），不是提供數據。不然若是客戶端數量增加，namenode就會快速成爲一個「瓶頸」。

 

mapreduce:

mapreduce1.x：

• 首先客戶端要編寫好mapreduce程序，而後提交做業也就是job，job的信息會發送到JobTracker上，併爲該job分配一個ID值，接下來作檢查操做，確認輸入目錄是否存在，若是不存在，則會拋錯，若是存在繼續檢查輸出目錄是否存在，若是存在則會拋錯，不然繼續運行；當檢查工做都作好了JobTracker就會配置Job須要的資源了。
• JobTracker: 主要負責資源監控管理和做業調度 
  （a）監控全部TaskTracker 與job的健康情況,一旦發現失敗,就將相應的任務轉移到其餘節點； 
  （b）同時JobTracker會跟蹤任務的執行進度、資源使用量等信息,並將這些信息告訴任務調度器,而調度器會在資源出現空閒時,選擇合適的任務使用這些資源。
• TaskTracker：是JobTracker與Task以前的橋樑 
  （a）從JobTracker接收並執行各類命令:運行任務、提交任務、Kill任務、從新初始化任務; 
  （b）週期性地經過心跳機制,將節點健康狀況和資源使用狀況、各個任務的進度和狀態等彙報給JobTracker。
• Task Scheduler: 任務調度器(默認FIFO,先按照做業的優先級高低,再按照到達時間的前後選擇被執行的做業)

缺點：

• Hadoop1.x的MapReduce框架的主要侷限： 
  （1）JobTracker 是 Map-reduce 的集中處理點，存在單點故障，可靠性差； 
  （2）JobTracker 完成了太多的任務，形成了過多的資源消耗，當 map-reduce job 很是多的時候，會形成很大的內存開銷，潛在來講，也增長了 JobTracker 失效的風險，這也是業界廣泛總結出老 Hadoop 的 Map-Reduce 只能支持 4000 節點主機的上限，擴展性能差。 
  （3）可預測的延遲：這是用戶很是關心的。小做業應該儘量快得被調度，而當前基於TaskTracker->JobTracker ping（heartbeat）的通訊方式代價和延遲過大，比較好的方式是JobTracker->TaskTracker ping, 這樣JobTracker能夠主動掃描有做業運行的TaskTracker。

mapreduce2.x:

 MapReduce2組成部分

• ResourceManager（RM）包含兩個主要的組件：定時調用器(Scheduler)以及應用管理器(ApplicationManager) 
  （1）調度器（Scheduler）：根據容量，隊列等限制條件，將系統中的資源分配給各個正在運行的應用。這裏的調度器是一個「純調度器」，由於它再也不負責監控或者跟蹤應用的執行狀態等，此外，他也不負責從新啓動因應用執行失敗或者硬件故障而產生的失敗任務。調度器僅根據各個應用的資源需求進行調度，這是經過抽象概念「資源容器」完成的，資源容器（Resource Container）將內存，CPU，磁盤，網絡等資源封裝在一塊兒，從而限定每一個任務使用的資源量。總而言之，定時調度器負責嚮應用程序分配資源，它不作監控以及應用程序的狀態跟蹤，而且它不保證會重啓因爲應用程序自己或硬件出錯而執行失敗的應用程序。 
  （2）應用管理器（ApplicationsManager，ASM）：ASM主要負責接收做業，協商獲取第一個容器用於執行AM和提供重啓失敗AM container的服務。

• NodeManager：NM是每一個節點上的框架代理，主要負責啓動應用所需的容器，監控資源（內存，CPU，磁盤，網絡等）的使用狀況並將之彙報給調度器（Scheduler）。

• ApplicationMaster：每一個應用程序的ApplicationMaster負責從Scheduler申請資源，以及跟蹤這些資源的使用狀況以及任務進度的監控。

• Container：是YARN中資源的抽象，它將內存、CPU、磁盤、網絡等資源封裝在一塊兒。當AM向RM申請資源時，RM爲AM返回的資源即是用Container表示的。

 MapReduce2提交應用程序的過程分析

1. 在做業的提交階段，client向RM提交一個job，這時RM會進行檢查，若是沒有問題，會返回做業文件提交的路徑和jod id；client向HDFS上傳文件，準備就緒後請求RM運行做業；

2. 做業初始化階段，用戶將應用程序提交到ResourceManager後，RM爲該做業分配第一個Container，並與對應的NM通訊，在Container中啓動做業的MRAppMaster；

3. MRAppMaster首先向ResourceManager註冊，這樣用戶能夠直接經過ResourceManage查看應用程序的運行狀態，而後它將爲各個任務申請資源，並監控它的運行狀態；

4. MRAppMaster採用輪詢的方式式經過RPC協議向RM申請任務所需資源；

5. 一旦MRAppMaster申請到資源後，便與對應的NodeManager通訊，要求它啓動任務；

6. NodeManager爲任務設置好運行環境（包括環境變量、JAR包、二進制程序等）後，將任務啓動命令寫到一個腳本中，並經過運行該腳本啓動任務；

7. 各個任務經過某個RPC協議向MRAppMaster彙報本身的狀態和進度，以讓MRAppMaster隨時掌握各個任務的運行狀態，從而能夠在任務失敗時從新啓動任務。在應用程序運行過程當中，用戶可隨時經過RPC向MRAppMaster查詢應用程序的當前運行狀態;

8. 應用程序運行完成後，ApplicationMaster向ResourceManager註銷並關閉本身。

Yarn做爲集羣的資源管理框架，由ResourceManager資源管理器和NodeManager每一個節點上的框架代理組成。 
咱們須要知道的點是當用戶向YARN中提交一個應用程序後，怎樣進行資源管理和調度完成job的。 
能夠簡單的分兩個階段運行該應用程序： 

a. 第一個階段是啓動ApplicationMaster； b. 第二個階段是由ApplicationMaster建立應用程序，爲它申請資源，並監控它的整個運行過程，直到運行完