目前，Hadoop還只是數據倉庫產品的一個補充，和數據倉庫一起構建混搭架構為上層應用聯合提供服務。
Hadoop集群具體來說包含兩個集群：HDFS集群和YARN集群，兩者邏輯上分離，但物理上常在一起。
（1）HDFS集群：負責海量數據的存儲，集群中的角色主要有 NameNode / DataNode/SecondaryNameNode。
（2）YARN集群：負責海量數據運算時的資源調度，集群中的角色主要有 ResourceManager /NodeManager
（3）MapReduce：它其實是一個應用程序開發包。
一、HDFS
HDFS是一個高度容錯性的系統，適合部署在廉價的機器上。HDFS采用master/slave架構。一個HDFS集群是由一個Namenode和一定數目的Datanodes組成。Namenode是一個中心服務器，負責管理文件系統的名字空間(namespace)以及客戶端對文件的訪問。集群中的Datanode一般是一個節點一個，負責管理它所在節點上的存儲。架構如下圖：
A、NameNode
NameNode管理着文件系統的命名空間，維護着文件系統樹，它不存儲真實數據，存儲元數據(MetaData)[元數據(FileName、副本數、每一個副本所在的位置...)]，NameNode保存在內存中。
元數據信息通過以下文件和過程持久化到磁盤中。
a、fsimage--對元數據定期進行鏡像
b、edits--存放一定時間內對HDFS的操作記錄
c、checkpoint---檢查點
Namenode在內存中保存着整個文件系統的名字空間和文件數據塊映射(Blockmap)的映像。這個關鍵的元數據結構設計得很緊湊，因而一個有4G內存的Namenode足夠支撐大量的文件和目錄。當Namenode啟動時，它從硬盤中讀取Editlog和FsImage，將所有Editlog中的事務作用在內存中的FsImage上，並將這個新版本的FsImage從內存中保存到本地磁盤上，然后刪除舊的Editlog，因為這個舊的Editlog的事務都已經作用在FsImage上了。這個過程稱為一個檢查點(checkpoint)。在當前實現中，檢查點只發生在Namenode啟動時，在不久的將來將實現支持周期性的檢查點。
B、DataNode
存儲節點，真正存放數據的節點，用於保存數據，保存在磁盤上（在HDFS上保存的數據副本數默認是3個，這個副本數量是可以設置的）。基本單位是塊(block)，默認128M。
Datanode負責處理文件系統客戶端的讀寫請求。在Namenode的統一調度下進行數據塊的創建、刪除和復制。集群中單一Namenode的結構大大簡化了系統的架構。Namenode是所有HDFS元數據的仲裁者和管理者，這樣，用戶數據永遠不會流過Namenode。
Block塊的概念
每台機器都有磁盤，機器上的所有持久化數據都是存儲在磁盤上的。磁盤是通過塊來管理數據的，一個塊的數據是該磁盤一次能夠讀寫的最小單位，一般是512個字節，而建立在磁盤之上的文件系統也有塊的概念，通常是磁盤塊的整數倍，例如幾kb。
HDFS作為文件系統，一樣有塊的概念，對於分布式文件系統，使用文件塊將會帶來這些好處：
1.一個文件的大小不限制於集群中任意機器的磁盤大小
2.因為塊的大小是固定的，相對比不確定大小的文件，塊更容易進行管理和計算
3.塊同樣方便進行備份操作，以提高數據容錯性和系統的可靠性
為什么HDFS的塊大小會比文件系統的塊大那么多呢？
操作數據時，需要先從磁盤上找到指定的數據塊然后進行傳輸，而這就包含兩個動作：
1）數據塊尋址：找到該數據塊的起始位置
2）數據傳輸：讀取數據
也就是說，操作數據所花費的時間是由以上兩個步驟一起決定的，步驟1所花費的時間一般比步驟2要少很多，那么當操作的數據塊越多，尋址所花費的時間在總時間中就越小的可以忽略不計。所以塊設置的大，可以最小化磁盤的尋址開銷。但是HDFS的Block塊也不能設置的太大，會影響到map任務的啟動數，並行度降低，任務的執行數據將會變慢。
★名詞擴展：心跳機制、宕機、安全模式
C、SecondaryNameNode
輔助節點，用於同步元數據信息。輔助NameNode對fsimage和edits進行合並（冷備份）
NameNode 的元數據信息先往 edits 文件中寫,當 edits 文件達到一定的閾值(3600 秒或大小到 64M)的時候,會開啟合並的流程。合並流程如下:
①當開始合並的時候,SecondaryNameNode 會把 edits 和 fsimage 拷貝到自己服務器所在內存中,開始合並,合並生成一個名為 fsimage.ckpt 的文件。
②將 fsimage.ckpt 文件拷貝到 NameNode 上,成功后,再刪除原有的 fsimage,並將 fsimage.ckpt文件重命名為 fsimage。
③當 SecondaryNameNode將 edits 和 fsimage 拷貝走之后,NameNode 會立刻生成一個 edits.new 文件,用於記錄新來的元數據,當合並完成之后,原有的 edits 文件才會被刪除,並將 edits.new 文件重命名為 edits 文件,開啟下一輪流程。
二、YARN
1.1 YARN 基本架構
YARN是Hadoop 2.0中的資源管理系統，它的基本設計思想是將MRv1中的JobTracker拆分成了兩個獨立的服務：一個全局的資源管理器ResourceManager和每個應用程序特有的ApplicationMaster。
其中ResourceManager負責整個系統的資源管理和分配，而ApplicationMaster負責單個應用程序的管理。
1.2 YARN基本組成結構
YARN總體上仍然是Master/Slave結構，在整個資源管理框架中，ResourceManager為Master，NodeManager為Slave，ResourceManager負責對各個NodeManager上的資源進行統一管理和調度。當用戶提交一個應用程序時，需要提供一個用以跟蹤和管理這個程序的ApplicationMaster，它負責向ResourceManager申請資源，並要求NodeManger啟動可以占用一定資源的任務。由於不同的ApplicationMaster被分布到不同的節點上，因此它們之間不會相互影響。在本小節中，我們將對YARN的基本組成結構進行介紹。
圖2-9描述了YARN的基本組成結構，YARN主要由ResourceManager、NodeManager、ApplicationMaster（圖中給出了MapReduce和MPI兩種計算框架的ApplicationMaster，分別為MR AppMstr和MPI AppMstr）和Container等幾個組件構成。
1.ResourceManager（RM）
RM是一個全局的資源管理器，負責整個系統的資源管理和分配。它主要由兩個組件構成：調度器（Scheduler）和應用程序管理器（Applications Manager，ASM）。
（1）調度器
調度器根據容量、隊列等限制條件（如每個隊列分配一定的資源，最多執行一定數量的作業等），將系統中的資源分配給各個正在運行的應用程序。
需要注意的是，該調度器是一個“純調度器”，它不再從事任何與具體應用程序相關的工作，比如不負責監控或者跟蹤應用的執行狀態等，也不負責重新啟動因應用執行失敗或者硬件故障而產生的失敗任務，這些均交由應用程序相關的ApplicationMaster完成。調度器僅根據各個應用程序的資源需求進行資源分配，而資源分配單位用一個抽象概念“資源容器”（Resource Container，簡稱Container）表示，Container是一個動態資源分配單位，它將內存、CPU、磁盤、網絡等資源封裝在一起，從而限定每個任務使用的資源量。此外，該調度器是一個可插拔的組件，用戶可根據自己的需要設計新的調度器，YARN提供了多種直接可用的調度器，比如Fair Scheduler和Capacity Scheduler等。
（2） 應用程序管理器
應用程序管理器負責管理整個系統中所有應用程序，包括應用程序提交、與調度器協商資源以啟動ApplicationMaster、監控ApplicationMaster運行狀態並在失敗時重新啟動它等。
2. ApplicationMaster（AM）
用戶提交的每個應用程序均包含1個AM，主要功能包括：
與RM調度器協商以獲取資源（用Container表示）；
將得到的任務進一步分配給內部的任務；
與NM通信以啟動/停止任務；
監控所有任務運行狀態，並在任務運行失敗時重新為任務申請資源以重啟任務。
當前YARN自帶了兩個AM實現，一個是用於演示AM編寫方法的實例程序distributedshell，它可以申請一定數目的Container以並行運行一個Shell命令或者Shell腳本；另一個是運行MapReduce應用程序的AM—MRAppMaster，我們將在第8章對其進行介紹。此外，一些其他的計算框架對應的AM正在開發中，比如Open MPI、Spark等。
3. NodeManager（NM）
NM是每個節點上的資源和任務管理器，一方面，它會定時地向RM匯報本節點上的資源使用情況和各個Container的運行狀態；另一方面，它接收並處理來自AM的Container啟動/停止等各種請求。
4. Container
Container是YARN中的資源抽象，它封裝了某個節點上的多維度資源，如內存、CPU、磁盤、網絡等，當AM向RM申請資源時，RM為AM返回的資源便是用Container表示的。YARN會為每個任務分配一個Container，且該任務只能使用該Container中描述的資源。
需要注意的是，Container不同於MRv1中的slot，它是一個動態資源划分單位，是根據應用程序的需求動態生成的。截至本書完成時，YARN僅支持CPU和內存兩種資源，且使用了輕量級資源隔離機制Cgroups進行資源隔離。
1.3 YARN工作流程
當用戶向YARN中提交一個應用程序后，YARN將分兩個階段運行該應用程序：
第一個階段是啟動ApplicationMaster；
第二個階段是由ApplicationMaster創建應用程序，為它申請資源，並監控它的整個運行過程，直到運行完成。
如圖2-11所示，YARN的工作流程分為以下幾個步驟：
步驟1 用戶向YARN中提交應用程序，其中包括ApplicationMaster程序、啟動ApplicationMaster的命令、用戶程序等。
步驟2 ResourceManager為該應用程序分配第一個Container，並與對應的Node-Manager通信，要求它在這個Container中啟動應用程序的ApplicationMaster。
步驟3 ApplicationMaster首先向ResourceManager注冊，這樣用戶可以直接通過ResourceManager查看應用程序的運行狀態，然后它將為各個任務申請資源，並監控它的運行狀態，直到運行結束，即重復步驟4~7。
步驟4 ApplicationMaster采用輪詢的方式通過RPC協議向ResourceManager申請和領取資源。
步驟5 一旦ApplicationMaster申請到資源后，便與對應的NodeManager通信，要求它啟動任務。
步驟6 NodeManager為任務設置好運行環境（包括環境變量、JAR包、二進制程序等）后，將任務啟動命令寫到一個腳本中，並通過運行該腳本啟動任務。
步驟7 各個任務通過某個RPC協議向ApplicationMaster匯報自己的狀態和進度，以讓ApplicationMaster隨時掌握各個任務的運行狀態，從而可以在任務失敗時重新啟動任務。
在應用程序運行過程中，用戶可隨時通過RPC向ApplicationMaster查詢應用程序的當前運行狀態。
步驟8 應用程序運行完成后，ApplicationMaster向ResourceManager注銷並關閉自己。
1.4 多角度理解YARN
可將YARN看做一個雲操作系統，它負責為應用程序啟動ApplicationMaster（相當於主線程），然后再由ApplicationMaster負責數據切分、任務分配、啟動和監控等工作，而由ApplicationMaster啟動的各個Task（相當於子線程）僅負責自己的計算任務。當所有任務計算完成后，ApplicationMaster認為應用程序運行完成，然后退出。
參考文檔：