本節(jié)和大家一起學(xué)習(xí)一下Hadoop，通過(guò)它的實(shí)際應(yīng)用來(lái)向大家展示它的功能，從而使讀者更容易了解，希望通過(guò)本節(jié)的介紹大家對(duì)Hadoop有初步的了解。

Hadoop最佳實(shí)踐

1.簡(jiǎn)介
Hadoop是Apache自由軟件基金會(huì)資助的頂級(jí)項(xiàng)目，致力于提供基于map-reduce計(jì)算模型的高效、可靠、高擴(kuò)展性分布式計(jì)算平臺(tái)。

2.Map-Reduce應(yīng)用場(chǎng)景
作為一種受限的分布式計(jì)算模型，Map-Reduce計(jì)算模型有其擅長(zhǎng)的領(lǐng)域，也有其不擅長(zhǎng)的方面：

條款1：map-reduce計(jì)算模型適用于批處理任務(wù)，即在可接受的時(shí)間內(nèi)對(duì)整個(gè)數(shù)據(jù)集計(jì)算某個(gè)特定的查詢(xún)的結(jié)果，該計(jì)算模型不適合需要實(shí)時(shí)反映數(shù)據(jù)變化狀態(tài)的計(jì)算環(huán)境。

條款2：map-reduce計(jì)算模型是以“行”為處理單位的，無(wú)法回溯已處理過(guò)的“行”，故每行日志都必須是一個(gè)獨(dú)立的語(yǔ)義單元，行與行之間不能有語(yǔ)義上的關(guān)聯(lián)。

條款3：相對(duì)于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)管理系統(tǒng)，Map-Reduce計(jì)算模型更適合于處理半結(jié)構(gòu)化或無(wú)結(jié)構(gòu)話的數(shù)據(jù)。

因?yàn)镸ap-Reduce計(jì)算模型是在處理的時(shí)候?qū)?shù)據(jù)進(jìn)行解釋的，這就意味著輸入的Key和Value可以不是數(shù)據(jù)本身固有的屬性，Key、Value的選擇完全取決于分析數(shù)據(jù)的人。

條款4：Map-Reduce是一個(gè)線性可擴(kuò)展模型，服務(wù)器越多，處理時(shí)間越短。

以下是同一個(gè)任務(wù)在不同機(jī)器數(shù)下獲得的測(cè)試結(jié)果：

 3.任務(wù)調(diào)度優(yōu)化
首先對(duì)一些術(shù)語(yǔ)進(jìn)行一下說(shuō)明。Job是一組客服端想要完成的工作，包括輸入數(shù)據(jù)，map-reduce程序以及配置信息，Hadoop通過(guò)將Job劃分為一些task來(lái)執(zhí)行，task又分為maptask和reducetask。

如何調(diào)度Hadoop任務(wù)才能充分發(fā)揮集群中所有服務(wù)器的能力呢？

條款5：每個(gè)Job的輸入文件不宜過(guò)大，也不宜過(guò)小。文件過(guò)大會(huì)造成reduce任務(wù)分布不均勻，導(dǎo)致reducetime的不可預(yù)知性，而大量的小文件則會(huì)嚴(yán)重影響Hadoop的性能。

Hadoop會(huì)將Job的輸入文件分割成64M固定大小的split，每個(gè)split啟動(dòng)一個(gè)maptask處理，這個(gè)split中的每個(gè)record都經(jīng)過(guò)用戶定義的map函數(shù)處理生成中間結(jié)果。若輸入文件小于64M，則此文件單獨(dú)作
為一個(gè)split處理。故當(dāng)輸入文件中有大量的小文件時(shí)，那么管理這些小文件的開(kāi)銷(xiāo)以及maptask的創(chuàng)建開(kāi)銷(xiāo)會(huì)占據(jù)絕大多數(shù)的Job執(zhí)行時(shí)間。

為了找到Hadoop合適的Job文件大小，我們?cè)谝粋€(gè)有50臺(tái)退役機(jī)器組成的集群做了一組性能測(cè)試，結(jié)果如下表：

我們把一個(gè)任務(wù)的計(jì)算時(shí)間分為兩部分：reduceshuffletime和reducetime。

lreduceshuffletime是reduce任務(wù)把map輸出的<key，value>對(duì)copy到本地的時(shí)間，即reduceshuffletime=map時(shí)間+<key，value>對(duì)網(wǎng)絡(luò)傳輸時(shí)間。

lreducetime就是rudece處理這些<key，value>對(duì)的時(shí)間。

從上表我們可以得出結(jié)論：

l各個(gè)任務(wù)的reduceshuffletime是完全線性的（隨著任務(wù)量增加，時(shí)間線性增加）。

l任務(wù)量在300G以?xún)?nèi)，reducetime基本線性增長(zhǎng)，之后隨著任務(wù)量增加，reducetime呈現(xiàn)隨機(jī)性加大的趨勢(shì)。在任務(wù)量達(dá)到550G后這種隨機(jī)性更加明顯，先后運(yùn)行同樣的任務(wù)時(shí)間可能會(huì)相差一個(gè)小時(shí)。可以推斷，隨著任務(wù)量增加，reduce任務(wù)分布不均勻的機(jī)率提高，導(dǎo)致了reducetime的不可預(yù)知性。

l上面兩個(gè)時(shí)間的疊加影響下，在300G以?xún)?nèi)退役機(jī)器處理任務(wù)的時(shí)間是線性增加的。300G以上的任務(wù)需要分成若干個(gè)小任務(wù)串行運(yùn)行，保證reduce處理在線性可控的區(qū)間內(nèi)。本節(jié)關(guān)于Hadoop方面的知識(shí)沒(méi)有介紹完畢，請(qǐng)關(guān)注下節(jié)介紹。

【編輯推薦】

1. Hadoop初探
2. 學(xué)習(xí)筆記 Hadoop是什么?
3. Hadoop集群與Hadoop性能優(yōu)化
4. HadoopHBase實(shí)現(xiàn)配置簡(jiǎn)單的單機(jī)環(huán)境
5. 深入剖析Hadoop HBase