衆所周知Hadoop2.0包括三個部分，分佈式存儲HDFS、資源調度YARN、分佈式計算MapReduce，而MapReduce是基於HDFS、YARN基礎之上進行的分佈式計算，HDFS和YARN搭建好分佈式集羣，MapReduce自然也就有了分佈式集羣環境，所以我們主要來說HDFS和YARN的集羣架構。
HDFS的集羣架構
HDFS有三個進程NN、SNN、DN，NN，Yarn是兩個進程RM、NM，每個進程都需要避免單點，保證高可用。
絕大多數大數據系統的架構都是一主多從的架構設計，主服務器只有一臺，掌控全局，因此保證HDFS中的主進程NameNode、YARN中的主進程ResourceManager做到高可用尤爲重要。
HDFS的HA架構圖如下
1、命名服務nameservice，HDFS的代理：
HA的架構設計中，我們設計了兩臺NameNode節點。對於客戶端訪問來說，HDFS是透明的，你有多少臺NameNode節點，客戶端並不關心，你HDFS只要保證一點，能讓我正常訪問HDFS系統就OK。但對於HDFS系統來說，兩個NameNode，你得選擇哪個提供給客戶端訪問，所以必須要有代理機制。
client訪問NN時，如果第一次訪問到standby節點，需要到其他NN節點上重試，直到訪問到active節點
2、ACTIVE NN: 對外提供服務，standby namenode保持備用狀態
ACTIVE NN主要 負責操作記錄寫到自己的editlog、同時寫JN集羣、接收DN的心跳和塊報告
3、standby namenode：
接收JN集羣的日誌，顯示讀取執行edit log操作(重演)，使得自己的元數據和active nn節點保持一致。
接收所有datanodes的心跳和塊報告，因爲文件塊的映射關係是存在內存裏的，不是存在磁盤上的，因此datanodes必須向兩個namenodes同時彙報自己的存儲情況。
4、active/standby 兩個NameNode組成主備
ZKFC 單獨的進程 zookeeperfailovercontrol，和ZooKeeper進行交互的
通過ZKFC完成active選舉、standby到active的切換
監控NN監控健康狀態
向zk集羣定期發送心跳，使得自己可以被選舉；
當自己被zk選舉爲active的時候，zkfc進程通過RPC協議調用使NN節點的狀態變爲active
5、HDFS的 HA 環境部署
hadoop001:ZK NN ZKFC JN DN
hadoop002:ZK NN ZKFC JN DN
hadoop003:ZK JN DN
詳細介紹下日誌同步這一塊，如何保證edit日誌文件的安全和完整
我們兩個NameNode節點，如果Active節點宕機，我Standby節點要接着繼續對服務，那麼這個正常對外服務源自與文件元數據的完整性，也就是說Active節點要實時非常安全、完整的記錄文件的操作日誌信息，這樣Standby在讀取的時候，讀取的日誌信息是完整的，當Active節點宕機，Standby才能接手繼續工作。
方案一：一個好的文件系統
找一臺比較好的服務器，作爲外部的文件存儲設備，Active節點的NameNode將edit日誌文件寫入，Standby節點的NameNode將讀取寫入的日誌文件。那麼這種方案需要好的企業級服務。成本上來說代價昂貴，與我們小成本、大集羣的分佈式理念相違背。
方案二：分佈式存儲日誌信息QJM
NameNode管理文件的元數據，包括fsimage和edits，在開始啓動的時候NameNode的Active節點和Standby節點元數據是一樣的。但是啓動之後，Active節點提供對外服務，那麼它的edits日誌文件在不停的變化，這個時候兩個NameNode節點上的日誌文件肯定是不一樣的。那麼就需要一種機制，保證Active節點的日誌安全的寫入某個地方，並且讓Standby節點能完整的讀取。
我們說HDFS文件的安全性和完整性是通過DataNode節點副本的方式來保證的，每一個文件的存儲默認至少是3份。那麼我們的edit日誌文件爲了保證安全性，也類似於DataNode文件的存儲方式，以2n+1副本的方式進行存儲。n表示允許損壞的機器節點數量。也就是說Active的NameNode節點將edit日誌存三份，允許其中一個節點寫入edit日誌失敗。那麼負責存儲edit日誌文件節點進程是誰呢？就是JournalNode。它的節點數必須是奇數。JournalNode負責管理edit日誌文件的安全性和完整性，從而達到NameNode的Active節點與Standby節點之間元數據的同步。
“use HDFS HA using the Quorum Journal Manager (QJM) to share edit logs between the Active and Standby NameNodes“這是官網的一句話。QJM，分佈式的日誌管理，節點名稱就是JournalNode。
active NameNode在向JournalNode寫數據過程，是同步寫入quorum 個JournalNode才成功返回，其餘JournalNode會做異步數據同步，和activemq集羣使用2n+1 leveldb做數據同步原理類似，都是爲了保證數據的可靠性。
所以一般架構設計中，還是採用QJM分佈式日誌存儲來達到兩個NameNode節點之間元數據的同步。
Yarn的集羣架構
1、和HDFS的區別
- ZKFC是RM裏的一個線程，
- 同步通過ZooKeeper，
- NM不用和Standby RM同步
2、爲了HDFS的同步數據不使用ZooKeeper進行數據存儲？
相對而言，YARN 產生的作業信息要比HDFS產生的edit log量小，因爲ZooKeeper每次做寫操作都要進行選舉，性能比較低。
3、ZK的/rmstore目錄存儲lock、state信息。
RM啓動時候會向ZK的/rmstore目錄寫lock文件，寫成功就爲active，否則standby。
RM產生的狀態數據也是存儲在這個目錄下，當activeRM掛了，另外一個standby RM通過ZKFC選舉成功爲active，會從/rmstore讀取相應的作業信息。
4、YARN的 HA 環境部署
hadoop001：zk rm(zkfc) nm
hadoop002：zk rm(zkfc) nm
hadoop003：zk nm
最後聊下大數據架構的兩個核心設計理念
- 移動計算比移動數據更划算
既然數據是龐大的，而程序要比數據小得多，將數據輸入給程序是不划算的，那麼就反其道而行之，將程序分發到數據所在的地方進行計算，也就是所謂的移動計算比移動數據更划算。
這就是爲什麼MapReduce的代碼會跑在和DataNode在同一臺機器上的原因。
- 一主多從的架構設計
傳統的應用，爲了分流要分而治之，而大數據恰恰相反，需要把數據的收集在一起，才能挖掘出潛在的數據價值 。