體系結構
Hadoop1的核心組成包括HDFS和MapReduce。HDFS和MapReduce的共同點就是他們都是分布式的。
HDFS是包括主節點NameNode,只有一個，還有很多從節點DataNode,還有很多個。
NameNode含有我們用戶存儲的元數據的信息，把這些數據存儲在硬盤上，但是在運行時是加載在內存中的。
Hadoop1HDFS缺點：
1) 當我們的NameNode無法在內存中加載全部的元數據信息的時候，集群的壽命到頭了。為了集群的壽命更長，我們需要設定NameNode的節點是大內存的，內存越大越好。
2) Namenode只有一個節點，所以權限設計不夠合理。 不能完全物理隔離。舉例：10個用戶共用linux權限隔離徹底還是每個用戶在獨立的機器上隔離的徹底，很明顯是后者。
3) HDFS存儲數據有blocK概念，默認是64MB，可以改成128或者256。如果上傳的數據都是大量的小文件，比如都是1MB,2MB的小文件，那么對我們的HDFS集群會造成NameNode的元數據信息會急劇膨脹，每個小文件都是獨立元數據信息。
改進：
1) 一個NameNode裝不下數據，硬件上已經無法突破，那么我們從軟件體系中進行改進。一個NameNode不夠用，那么就2個NameNode一起共存。它們組成hdfs federation。
2) 實現高可靠，可以實現NameNode的核心元數據同時存放在多個節點上。也可以使用SecondNameNode,NameNode宕了，SecondNameNode還可以做事。默認的情況下全是手動恢復或者手動切換，沒有自動化。HDFS 高可靠自動化需要第三方軟件。
Hadoop2 實現了HA，它有兩個NameNode。
寫數據的NameNode處於active狀態，讀數據的NameNode處於standby狀態。
HA兩個NameNode使用相同的命名空間。與HDFS聯盟不一樣，聯盟使用的是兩個獨立的命名空間。
兩個NameNode到底誰提供服務？如果一個NameNode宕了，是否還要改程序（IP、主機變了）？
我們不需要去管。不用改程序。我們只看到一個HDFS，根本看不到兩個NameNode的不同。對外提供的是統一的接口。
Active宕了，standby要轉為Active，誰去做這樣的事情？
兩種方式，一手工做，二自動切換。
如何實現HA自動切換，需要Zookeeper.
MapReduce包括主節點JobTracker,只有一個；還有從節點TaskTracker,有很多個。
JobTracker主要的工作是管理用戶提交的作業和分配資源。每個TaskTracker有兩個slot,也就是在一個TaskTracker最多有兩個運行任務，默認是兩個，可以更多，但是占有的內存也就多了。
MapReduce處理的作業都是批處理的作業，對實時性要求不高的作業。
Hadoop1MapReduce缺點：
1) 對於實時性作業和批處理作業，需要搭建不同的集群環境。意味着硬件投入會多，需要很多服務器去做這樣的事。並且相同的數據分散在兩套不同的集群體系中，數據需要同時傳在兩套不同的集群體系中。不同的環境運行的是不同的作業類型，從另一個角度講每個集群環境的資源利用率是不高的。集群可能是這樣的情況，用戶要求實時性的作業，那么使用spark或者storm,運行完之后，處理完的數據我們進行批處理，又由hadoop集群來做，從時間軸上來看，前面的集群是在前段時間有作業，后面的集群在后段時間有作業，資源利用率不高是從這個角度上講。為了提高資源的利用率最好把它們合並到一套平台上。
2) MapReduce職責過多，需要分解。
hadoop2:Yarn用於處理資源分配和任務調度。
Yarn:
ResourceManeger:分配資源的（CPU、內存）
NodeManeger:它管理Hadoop集群中單個計算節點
Yarn的RM接收到我們客戶提交的MapReduce程序后，把程序交給NodeManager,啟動一個進程xxxAppMaster(在某個NodeManager上), xxxAppMaster再在其他節點上分配tasktracker。
源碼編譯
為什么要進行hadoop的源碼編譯？
看這篇文章：http://blog.csdn.net/xuefengmiao/article/details/25182323
hadoop2的學習資料很少，只有官網的少數文檔。如果想更深入的研究hadoop2，除了僅看官網的文檔外，還要學習如何看源碼，通過不斷的調試跟蹤源碼，學習hadoop的運行機制。
當你發現hadoop 存在bug而你又有能力修復的時候，可以嘗試改源碼bug然后重新編譯，這樣你就可以使用你fix bug 后的hadoop了。
如何進行hadoop源碼的編譯？
可以看我之前寫過的一篇文章：