什麼是Hadoop？
搞什麼東西之前，第一步是要知道What（是什麼），然後是Why（爲什麼），最後纔是How（怎麼做）。但很多開發的朋友在做了多年項目以後，都習慣是先How，然後What，最後纔是Why，這樣只會讓自己變得浮躁，同時往往會將技術誤用於不適合的場景。
Hadoop框架中最核心的設計就是：MapReduce和HDFS。MapReduce的思想是由Google的一篇論文所提及而被廣爲流傳的，簡單的一句話解釋MapReduce就是“任務的分解與結果的彙總”。HDFS是Hadoop分佈式文件系統（Hadoop Distributed File System）的縮寫，爲分佈式計算存儲提供了底層支持。
MapReduce從它名字上來看就大致可以看出個緣由，兩個動詞Map和Reduce，“Map（展開）”就是將一個任務分解成爲多個任務，“Reduce”就是將分解後多任務處理的結果彙總起來，得出最後的分析結果。這不是什麼新思想，其實在前面提到的多線程，多任務的設計就可以找到這種思想的影子。不論是現實社會，還是在程序設計中，一項工作往往可以被拆分成爲多個任務，任務之間的關係可以分爲兩種：一種是不相關的任務，可以並行執行；另一種是任務之間有相互的依賴，先後順序不能夠顛倒，這類任務是無法並行處理的。回到大學時期，教授上課時讓大家去分析關鍵路徑，無非就是找最省時的任務分解執行方式。在分佈式系統中，機器集羣就可以看作硬件資源池，將並行的任務拆分，然後交由每一個空閒機器資源去處理，能夠極大地提高計算效率，同時這種資源無關性，對於計算集羣的擴展無疑提供了最好的設計保證。（其實我一直認爲Hadoop的卡通圖標不應該是一個小象，應該是螞蟻，分佈式計算就好比螞蟻吃大象，廉價的機器羣可以匹敵任何高性能的計算機，縱向擴展的曲線始終敵不過橫向擴展的斜線）。任務分解處理以後，那就需要將處理以後的結果再彙總起來，這就是Reduce要做的工作。
圖1：MapReduce結構示意圖
上圖就是MapReduce大致的結構圖，在Map前還可能會對輸入的數據有Split（分割）的過程，保證任務並行效率，在Map之後還會有Shuffle（混合）的過程，對於提高Reduce的效率以及減小數據傳輸的壓力有很大的幫助。後面會具體提及這些部分的細節。
HDFS是分佈式計算的存儲基石，Hadoop的分佈式文件系統和其他分佈式文件系統有很多類似的特質。分佈式文件系統基本的幾個特點：
- 對於整個集羣有單一的命名空間。
- 數據一致性。適合一次寫入多次讀取的模型，客戶端在文件沒有被成功創建之前無法看到文件存在。
- 文件會被分割成多個文件塊，每個文件塊被分配存儲到數據節點上，而且根據配置會由複製文件塊來保證數據的安全性。
圖2：HDFS結構示意圖
上圖中展現了整個HDFS三個重要角色：NameNode、DataNode和Client。NameNode可以看作是分佈式文件系統中的管理者，主要負責管理文件系統的命名空間、集羣配置信息和存儲塊的複製等。NameNode會將文件系統的Meta-data存儲在內存中，這些信息主要包括了文件信息、每一個文件對應的文件塊的信息和每一個文件塊在DataNode的信息等。DataNode是文件存儲的基本單元，它將Block存儲在本地文件系統中，保存了Block的Meta-data，同時週期性地將所有存在的Block信息發送給NameNode。Client就是需要獲取分佈式文件系統文件的應用程序。這裏通過三個操作來說明他們之間的交互關係。
文件寫入：
- Client向NameNode發起文件寫入的請求。
- NameNode根據文件大小和文件塊配置情況，返回給Client它所管理部分DataNode的信息。
- Client將文件劃分爲多個Block，根據DataNode的地址信息，按順序寫入到每一個DataNode塊中。
文件讀取：
- Client向NameNode發起文件讀取的請求。
- NameNode返回文件存儲的DataNode的信息。
- Client讀取文件信息。
文件Block複製：
- NameNode發現部分文件的Block不符合最小複製數或者部分DataNode失效。
- 通知DataNode相互複製Block。
- DataNode開始直接相互複製。
最後再說一下HDFS的幾個設計特點（對於框架設計值得借鑑）：
- Block的放置：默認不配置。一個Block會有三份備份，一份放在NameNode指定的DataNode，另一份放在與指定DataNode非同一Rack上的DataNode，最後一份放在與指定DataNode同一Rack上的DataNode上。備份無非就是爲了數據安全，考慮同一Rack的失敗情況以及不同Rack之間數據拷貝性能問題就採用這種配置方式。
- 心跳檢測DataNode的健康狀況，如果發現問題就採取數據備份的方式來保證數據的安全性。
- 數據複製（場景爲DataNode失敗、需要平衡DataNode的存儲利用率和需要平衡DataNode數據交互壓力等情況）：這裏先說一下，使用HDFS的balancer命令，可以配置一個Threshold來平衡每一個DataNode磁盤利用率。例如設置了Threshold爲10%，那麼執行balancer命令的時候，首先統計所有DataNode的磁盤利用率的均值，然後判斷如果某一個DataNode的磁盤利用率超過這個均值Threshold以上，那麼將會把這個DataNode的block轉移到磁盤利用率低的DataNode，這對於新節點的加入來說十分有用。
- 數據交驗：採用CRC32作數據交驗。在文件Block寫入的時候除了寫入數據還會寫入交驗信息，在讀取的時候需要交驗後再讀入。
- NameNode是單點：如果失敗的話，任務處理信息將會紀錄在本地文件系統和遠端的文件系統中。
- 數據管道性的寫入：當客戶端要寫入文件到DataNode上，首先客戶端讀取一個Block然後寫到第一個DataNode上，然後由第一個DataNode傳遞到備份的DataNode上，一直到所有需要寫入這個Block的NataNode都成功寫入，客戶端纔會繼續開始寫下一個Block。
- 安全模式：在分佈式文件系統啓動的時候，開始的時候會有安全模式，當分佈式文件系統處於安全模式的情況下，文件系統中的內容不允許修改也不允許刪除，直到安全模式結束。安全模式主要是爲了系統啓動的時候檢查各個DataNode上數據塊的有效性，同時根據策略必要的複製或者刪除部分數據塊。運行期通過命令也可以進入安全模式。在實踐過程中，系統啓動的時候去修改和刪除文件也會有安全模式不允許修改的出錯提示，只需要等待一會兒即可。
下面綜合MapReduce和HDFS來看Hadoop的結構：
圖3：Hadoop結構示意圖
在Hadoop的系統中，會有一臺Master，主要負責NameNode的工作以及JobTracker的工作。JobTracker的主要職責就是啓動、跟蹤和調度各個Slave的任務執行。還會有多臺Slave，每一臺Slave通常具有DataNode的功能並負責TaskTracker的工作。TaskTracker根據應用要求來結合本地數據執行Map任務以及Reduce任務。
說到這裏，就要提到分佈式計算最重要的一個設計點：Moving Computation is Cheaper than Moving Data。就是在分佈式處理中，移動數據的代價總是高於轉移計算的代價。簡單來說就是分而治之的工作，需要將數據也分而存儲，本地任務處理本地數據然後歸總，這樣纔會保證分佈式計算的高效性。
爲什麼要選擇Hadoop？
說完了What，簡單地說一下Why。官方網站已經給了很多的說明，這裏就大致說一下其優點及使用的場景（沒有不好的工具，只用不適用的工具，因此選擇好場景才能夠真正發揮分佈式計算的作用）：
- 可擴展：不論是存儲的可擴展還是計算的可擴展都是Hadoop的設計根本。
- 經濟：框架可以運行在任何普通的PC上。
- 可靠：分佈式文件系統的備份恢復機制以及MapReduce的任務監控保證了分佈式處理的可靠性。
- 高效：分佈式文件系統的高效數據交互實現以及MapReduce結合Local Data處理的模式，爲高效處理海量的信息作了基礎準備。
使用場景：個人覺得最適合的就是海量數據的分析，其實Google最早提出MapReduce也就是爲了海量數據分析。同時HDFS最早是爲了搜索引擎實現而開發的，後來才被用於分佈式計算框架中。海量數據被分割於多個節點，然後由每一個節點並行計算，將得出的結果歸併到輸出。同時第一階段的輸出又可以作爲下一階段計算的輸入，因此可以想象到一個樹狀結構的分佈式計算圖，在不同階段都有不同產出，同時並行和串行結合的計算也可以很好地在分佈式集羣的資源下得以高效的處理。
