本節和大家一起學習一下Hadoop，通過它的實際應用來向大家展示它的功能，從而使讀者更容易了解，希望通過本節的介紹大家對Hadoop有初步的了解。
Hadoop最佳實踐
1.簡介
Hadoop是Apache自由軟件基金會資助的頂級項目，致力於提供基於map-reduce計算模型的高效、可靠、高擴展性分布式計算平台。
2.Map-Reduce應用場景
作為一種受限的分布式計算模型，Map-Reduce計算模型有其擅長的領域，也有其不擅長的方面：
條款1：map-reduce計算模型適用於批處理任務，即在可接受的時間內對整個數據集計算某個特定的查詢的結果，該計算模型不適合需要實時反映數據變化狀態的計算環境。
條款2：map-reduce計算模型是以“行”為處理單位的，無法回溯已處理過的“行”，故每行日志都必須是一個獨立的語義單元，行與行之間不能有語義上的關聯。
條款3：相對於傳統的關系型數據庫管理系統，Map-Reduce計算模型更適合於處理半結構化或無結構話的數據。
因為Map-Reduce計算模型是在處理的時候對數據進行解釋的，這就意味着輸入的Key和Value可以不是數據本身固有的屬性，Key、Value的選擇完全取決於分析數據的人。
條款4：Map-Reduce是一個線性可擴展模型，服務器越多，處理時間越短。
以下是同一個任務在不同機器數下獲得的測試結果：
3.任務調度優化
首先對一些術語進行一下說明。Job是一組客服端想要完成的工作，包括輸入數據，map-reduce程序以及配置信息，Hadoop通過將Job划分為一些task來執行，task又分為maptask和reducetask。
如何調度Hadoop任務才能充分發揮集群中所有服務器的能力呢？
條款5：每個Job的輸入文件不宜過大，也不宜過小。文件過大會造成reduce任務分布不均勻，導致reducetime的不可預知性，而大量的小文件則會嚴重影響Hadoop的性能。
Hadoop會將Job的輸入文件分割成64M固定大小的split，每個split啟動一個maptask處理，這個split中的每個record都經過用戶定義的map函數處理生成中間結果。若輸入文件小於64M，則此文件單獨作
為一個split處理。故當輸入文件中有大量的小文件時，那么管理這些小文件的開銷以及maptask的創建開銷會占據絕大多數的Job執行時間。
為了找到Hadoop合適的Job文件大小，我們在一個有50台退役機器組成的集群做了一組性能測試，結果如下表：
我們把一個任務的計算時間分為兩部分：reduceshuffletime和reducetime。
lreduceshuffletime是reduce任務把map輸出的<key，value>對copy到本地的時間，即reduceshuffletime=map時間+<key，value>對網絡傳輸時間。
lreducetime就是rudece處理這些<key，value>對的時間。
從上表我們可以得出結論：
l各個任務的reduceshuffletime是完全線性的（隨着任務量增加，時間線性增加）。
l任務量在300G以內，reducetime基本線性增長，之后隨着任務量增加，reducetime呈現隨機性加大的趨勢。在任務量達到 550G后這種隨機性更加明顯，先后運行同樣的任務時間可能會相差一個小時。可以推斷，隨着任務量增加，reduce任務分布不均勻的機率提高，導致了 reducetime的不可預知性。
l上面兩個時間的疊加影響下，在300G以內退役機器處理任務的時間是線性增加的。300G以上的任務需要分成若干個小任務串行運行，保證reduce處理在線性可控的區間內。本節關於Hadoop方面的知識沒有介紹完畢，請關注下節介紹。