Hadoop平臺優(yōu)化文獻(xiàn)綜述

1、Hadoop平臺優(yōu)化文獻(xiàn)綜述（極力推薦）復(fù)制鏈接yiranwuqing yiranwuqing 當(dāng)前離線注冊時間2011-3-10最后登錄2012-3-20在線時間88小時閱讀權(quán)限90積分13835帖子61主題21精華0UID12322 IP卡 狗仔卡論壇元老簽到163注冊時間2011-3-10最后登錄2012-3-20在線時間88小時閱讀權(quán)限90積分13835 帖子61主題21精華0UID12322串個門加好友 打招呼發(fā)消息、電梯直達(dá)1#發(fā)表于2011-10-6 02:44:22只看該作者|倒序瀏覽1. 概述隨著企業(yè)要處理的數(shù)據(jù)量越來越大，MapReduce思想越來越受到重視。Hadoop是

2、MapReduce 的一個開源實現(xiàn)，由于其良好的擴展性和容錯性，已得到越來越廣泛的應(yīng)用。Hadoop作為 一個基礎(chǔ)數(shù)據(jù)處理平臺，雖然其應(yīng)用價值已得到大家認(rèn)可，但仍存在很多問題，以下是主要 幾個：（1）Namenode/jobtracker 單點故障。Hadoop 采用的是 master/slaves 架構(gòu)，該架構(gòu)管 理起來比較簡單，但存在致命的單點故障和空間容量不足等缺點，這已經(jīng)嚴(yán)重影響了 Hadoop 的可擴展性。（2）HDFS小文件問題。在HDFS中，任何block，文件或者目錄在內(nèi)存中均以對象 的形式存儲，每個對象約占150byte，如果有1000 0000個小文件，每個文件占用一個bl

3、ock， 則namenode需要2G空間。如果存儲1億個文件，則namenode需要20G空間。這樣namenode 內(nèi)存容量嚴(yán)重制約了集群的擴展。（3）jobtracker同時進(jìn)行監(jiān)控和調(diào)度，負(fù)載過大。為了解決該問題，yahoo已經(jīng)開始著 手設(shè)計下一代Hadoop MapReduce （見參考資料1）。他們的主要思路是將監(jiān)控和調(diào)度分離， 獨立出一個專門的組件進(jìn)行監(jiān)控，而jobtracker只負(fù)責(zé)總體調(diào)度，至于局部調(diào)度，交給作業(yè) 所在的cliento（4）數(shù)據(jù)處理性能。很多實驗表明，其處理性能有很大的提升空間。Hadoop類似于 數(shù)據(jù)庫，可能需要專門的優(yōu)化工程師根據(jù)實際的應(yīng)用需要對Hadoop

4、進(jìn)行調(diào)優(yōu)，有人稱之為“Hadoop Performance Optimization” （HPO）。為了提高其數(shù)據(jù)性能，很多人開始優(yōu)化Hadoop?？偨Y(jié)看來，對于Hadoop，當(dāng)前主要有幾個 優(yōu)化思路：（1）從應(yīng)用程序角度進(jìn)行優(yōu)化。由于mapreduce是迭代逐行解析數(shù)據(jù)文件的，怎樣在迭 代的情況下，編寫高效率的應(yīng)用程序，是一種優(yōu)化思路。（2）對Hadoop參數(shù)進(jìn)行調(diào)優(yōu)。當(dāng)前hadoop系統(tǒng)有190多個配置參數(shù)，怎樣調(diào)整這些參 數(shù)，使hadoop作業(yè)運行盡可能的快，也是一種優(yōu)化思路。（3）從系統(tǒng)實現(xiàn)角度進(jìn)行優(yōu)化。這種優(yōu)化難度是最大的，它是從hadoop實現(xiàn)機制角度， 發(fā)現(xiàn)當(dāng)前Hadoop設(shè)計和

5、實現(xiàn)上的缺點，然后進(jìn)行源碼級地修改。該方法雖難度大，但往往 效果明顯。以上三種思路出發(fā)點均是提高h(yuǎn)adoop應(yīng)用程序的效率。實際上，隨著社會的發(fā)展，綠色環(huán) 保觀念也越來越多地融入了企業(yè)，因而很多人開始研究Green Hadoop，即怎樣讓Hadoop完 成相應(yīng)數(shù)據(jù)處理任務(wù)的同時，使用最少的能源（見參考資料1415）。本文主要介紹了當(dāng)前學(xué)術(shù)界的一些優(yōu)化思路，有人試圖從Hadoop自動配置角度對Hadoop 進(jìn)行優(yōu)化，但更多的是從系統(tǒng)實現(xiàn)角度進(jìn)行優(yōu)化，概括其優(yōu)化點和實驗效果如下：（1） 論文6試圖從參數(shù)自動調(diào)優(yōu)角度對Hadoop進(jìn)行優(yōu)化，論文只給出了可能的解決方 案，并未給出實現(xiàn)，因而效果不可知。

6、但它給出了一種Hadoop優(yōu)化的新思路，即怎樣對其 190多個配置參數(shù)進(jìn)行自動調(diào)整，使應(yīng)用程序執(zhí)行效率最高。（2）論文7提出prefetching和preshuffling機制，在不同負(fù)載不同規(guī)模集群下測試，效 率提升了約73%。（3）論文8研究了影響Hadoop效率的五個因素，并通過提出相應(yīng)的解決方案，使Hadoop 效率提高了 2.53.5倍。（4）論文9為Hadoop提供了一種索引機制-Trojan Index，同時提出了一種高效的join 算法-Trojan Join，實驗表明，效率比Hadoop和HadoopDB高很多。除了學(xué)術(shù)界的優(yōu)化，工業(yè)界也在不斷進(jìn)行優(yōu)化以適應(yīng)自己公司的產(chǎn)品需要

7、，主要有：（1）Baidu公司。baidu對Hadoop中關(guān)鍵組件使用C+進(jìn)行了重寫（包括map, shuffler和 reducer等），經(jīng)他們內(nèi)部測試（5 nodes，40GB data），效率提升了約20% （見參考資料4）。（2）淘寶。淘寶針對自己集群特點（作業(yè)小，slot多，作業(yè)之間有依賴，集群共享，有些 作業(yè)有時效性），對jobtracker和namenode進(jìn)行了優(yōu)化，據(jù)其官方博客稱，其jobtracker有 較大性能提升，且namenode吞吐量提升了 8+倍（見參考資料5）。但其具體優(yōu)化方法，未 公開。從應(yīng)用程序角度進(jìn)行優(yōu)化（1）避免不必要的reduce任務(wù)如果要處理的數(shù)據(jù)是

8、排序且已經(jīng)分區(qū)的，或者對于一份數(shù)據(jù)，需要多次處理，可以先排序分 區(qū);然后自定義InputSplit,將單個分區(qū)作為單個mapred的輸入；在map中處理數(shù)據(jù),Reducer 設(shè)置為空。這樣，既重用了已有的“排序”，也避免了多余的reduce任務(wù)。（2）外部文件引入有些應(yīng)用程序要使用外部文件，如字典，配置文件等，這些文件需要在所有task之間共享， 可以放到分布式緩存DistributedCache中（或直接采用-files選項，機制相同）。更多的這方面的優(yōu)化方法，還需要在實踐中不斷積累。（3）為 job 添加一個 Combiner為job添加一個combiner可以大大減少shuffle階段從

9、map task拷貝給遠(yuǎn)程reduce task的數(shù) 據(jù)量。一般而言，combiner 與 reducer 相同。（4）根據(jù)處理數(shù)據(jù)特征使用最適合和簡潔的Writable類型Text對象使用起來很方便，但它在由數(shù)值轉(zhuǎn)換到文本或是由UTF8字符串轉(zhuǎn)換到文本時都是 低效的，且會消耗大量的CPU時間。當(dāng)處理那些非文本的數(shù)據(jù)時，可以使用二進(jìn)制的Writable 類型，如IntWritable， FloatWritable等。二進(jìn)制writable好處：避免文件轉(zhuǎn)換的消耗；使 map task中間結(jié)果占用更少的空間。（5）重用Writable類型很多MapReduce用戶常犯的一個錯誤是，在一個 map

10、/reduce方法中為每個輸出都創(chuàng)建 Writable對象。例如，你的Wordcout mapper方法可能這樣寫：123456789101112public void map(.) (for (String word : words) (output.collect(new Text(word), new IntWritable(1);這樣會導(dǎo)致程序分配出成千上萬個短周期的對象。Java垃圾收集器就要為此做很多的工作。 更有效的寫法是：123456789101112131415161718 1920class MyMapper Text wordText = new Text();IntWr

11、itable one = new IntWritable(l);public void map(.) (for (String word: words) (wordText.set(word);output.collect(wordText, one);（6）使用 StringBuffer 而不是 String當(dāng)需要對字符串進(jìn)行操作時，使用StringBuffer而不是String, String是read-only的，如果對它進(jìn)行修改，會產(chǎn)生臨時對象，而StringBuffer是可修改的，不會產(chǎn)生臨時對象。（7）調(diào)試最重要，也是最基本的，是要掌握MapReduce程序調(diào)試方法，跟蹤程序的瓶頸

12、。具體可參 考： HYPERLINK /blog/2009/12/7-tips-for-improving-mapreduce-performance/ /blog/2009/12/7-tips-for-improving-mapreduce-performance/對參數(shù)進(jìn)行調(diào)優(yōu)3.1參數(shù)自動調(diào)優(yōu)論文6試圖從自動化參數(shù)調(diào)優(yōu)角度對hadoop應(yīng)用程序運行效率進(jìn)行優(yōu)化。Hadoop目前有 190多個配置參數(shù)，其中大約有25個對hadoop應(yīng)用程序效率有顯著的影響。論文首先分析了 database優(yōu)化思路。Database會根據(jù)用戶輸入的SQL建立一個代價模型:， 其中y表示查詢q優(yōu)化目標(biāo)（如運行

13、時間），p表示q的查詢計劃，r表示為執(zhí)行計劃p而申 請的資源量，d表示一些統(tǒng)計信息。數(shù)據(jù)庫會根據(jù)該代價模型評估不同的查詢計劃，并選擇 一個最優(yōu)的執(zhí)行查詢。這種數(shù)據(jù)庫模型很難擴展應(yīng)用到mapreduce環(huán)境中，主要是因為：（1）mapreduce作業(yè)一般是采用C，C+或java編寫，與聲明性語言SQL有明顯不同。（2）缺少有關(guān)輸入數(shù)據(jù)的統(tǒng)計信息。Mapreduce作業(yè)通常是運行時解析動態(tài)輸入文件 的，因而運行之前schema或者統(tǒng)計信息均是未知的。（3）它們的優(yōu)化空間不同。數(shù)據(jù)庫的查詢優(yōu)化空間（主要是選擇最優(yōu)的plan）與mapreduce的優(yōu)化空間（主要是配置參數(shù)調(diào)優(yōu)）不同。本論文提出了三種可

14、行的方案，第一種是基于采樣的方法，借鑒Terasor t作業(yè)的思路，先對 輸入數(shù)據(jù)進(jìn)行采樣，然后通過樣本估算不同配置下作業(yè)的執(zhí)行時間，最后選擇一種最優(yōu)的配 置。該方法需要解決的一個問題是，由于reduce階段和map階段存在數(shù)據(jù)依賴，因而map 完成之前，reduce的所有信息均是未知的。有一種也是可行的思路是，執(zhí)行作業(yè)之前，先采 樣選擇一個樣本組成一個小作業(yè)，然后執(zhí)行該小作業(yè)以估算大作業(yè)性能。該方法也存在一個 需要解決的問題，怎樣采樣才能使樣本最能代表總體？第二種是Late Binding，即延遲綁定，其思想是延遲設(shè)置其中的一個或多個參數(shù)，直到j(luò)ob 已經(jīng)部分執(zhí)行，且這些參數(shù)可以確定。比如h

15、adoop中的combiner操作實際就是采用的這一 機制，作業(yè)在執(zhí)行完map()之前不知道要不要進(jìn)行combineo第三種是Competition-based Approaches，其思想是，首先，同時執(zhí)行多個配置有不同參數(shù)的 task，然后，盡快決定哪種配置的task執(zhí)行速度快，最后，殺掉其它task。該文章完全是個調(diào)研性的論文，它先研究了數(shù)據(jù)庫的一些調(diào)優(yōu)方法，經(jīng)過研究發(fā)現(xiàn)不可以直 接將這些方法應(yīng)用于mapreduce系統(tǒng)中，進(jìn)而針對mapreduce獨有的特點，提出了幾種也許 可行的方法，但論文中并未給出實現(xiàn)。3.2參數(shù)手工配置Linux文件系統(tǒng)參數(shù)調(diào)整noatime 和 nodirat

16、ime 屬性文件掛載時設(shè)置這兩個屬性可以明顯提高性能。默認(rèn)情況下，Linux ext2/ext3文件系統(tǒng)在 文件被訪問、創(chuàng)建、修改時會記錄下文件的時間戳，比如：文件創(chuàng)建時間、最近一次修改時 間和最近一次訪問時間。如果系統(tǒng)運行時要訪問大量文件，關(guān)閉這些操作，可提升文件系統(tǒng) 的性能。Linux提供了 noatime這個參數(shù)來禁止記錄最近一次訪問時間戳。readahead buffer調(diào)整linux文件系統(tǒng)中預(yù)讀緩沖區(qū)地大小，可以明顯提高順序讀文件的性能。默認(rèn)buffer大 小為256 sectors，可以增大為1024或者2408 sectors(注意，并不是越大越好)?？墒褂胋lockdev 命

17、令進(jìn)行調(diào)整。避免RAID和LVM操作避免在TaskTracker和DataNode的機器上執(zhí)行RAID和LVM操作，這通常會降低性能。Hadoop通用參數(shù)調(diào)整node.handler.count 或 mapred.job.tracker.handler.countnamenode或者jobtracker中用于處理RPC的線程數(shù)，默認(rèn)是10，較大集群，可調(diào)大些，比 如64 odfs.datanode.handler.countdatanode上用于處理RPC的線程數(shù)。默認(rèn)為3,較大集群，可適當(dāng)調(diào)大些，比如8。需要注 意的是，每添加一個線程，需要的內(nèi)存增加。tasktracker. HYPERLI

18、NK http:/http.threads http.threadsHTTP server上的線程數(shù)。運行在每個TaskTracker上，用于處理map task輸出。大集群，可 以將其設(shè)為4050oHDFS相關(guān)配置dfs.replication文件副本數(shù)，通常設(shè)為3,不推薦修改。dfs.block.sizeHDFS中數(shù)據(jù)block大小，默認(rèn)為64M，對于較大集群，可設(shè)為128MB或者256MB。(也可 以通過參數(shù) mapred.min.split.size 配置)mapred.local.dir和 dfs.data.dir這兩個參數(shù)mapred.local.dir和dfs.data.dir配

19、置的值應(yīng)當(dāng)是分布在各個磁盤上目錄，這樣可 以充分利用節(jié)點的IO讀寫能力。運行Linux sysstat包下的iostat -dx 5命令可以讓每個磁盤 都顯示它的利用率。map/reduce 相關(guān)配置map/reduce.tasks.maximum同時運行在 TaskTracker 上的最大 map/reduce task 數(shù)，一般設(shè)為(core_per_node)/22* (cores_per_node)。io.sort.factor當(dāng)一個map task執(zhí)行完之后，本地磁盤上(mapred.local.dir)有若干個spill文件，map task最 后做的一件事就是執(zhí)行merge so

20、rt，把這些spill文件合成一個文件(partition)0執(zhí)行merge sort 的時候，每次同時打開多少個spill文件由該參數(shù)決定。打開的文件越多，不一定merge sort 就越快，所以要根據(jù)數(shù)據(jù)情況適當(dāng)?shù)恼{(diào)整。mapred.child.java.opts設(shè)置JVM堆的最大可用內(nèi)存，需從應(yīng)用程序角度進(jìn)行配置。map task相關(guān)配置io.sort.mbMap task的輸出結(jié)果和元數(shù)據(jù)在內(nèi)存中所占的buffer總大小。默認(rèn)為100M，對于大集群， 可設(shè)為200M。當(dāng)buffer達(dá)到一定閾值，會啟動一個后臺線程來對buffer的內(nèi)容進(jìn)行排序， 然后寫入本地磁盤(一個spill文件)。

21、io.sort.spill.percent這個值就是上述buffer的閾值，默認(rèn)是0.8，即80%，當(dāng)buffer中的數(shù)據(jù)達(dá)到這個閾值，后 臺線程會起來對buffer中已有的數(shù)據(jù)進(jìn)行排序，然后寫入磁盤。io.sort.recordIo.sort.mb中分配給元數(shù)據(jù)的內(nèi)存百分比，默認(rèn)是0.05。這個需要根據(jù)應(yīng)用程序進(jìn)行調(diào)整。press.map.output/ Mpress中間結(jié)果和最終結(jié)果是否要進(jìn)行壓縮，如果是，指定壓縮方式 (Mpress.map.output.codec/ Mpress.codec)。推薦使用 LZO 壓縮。Intel內(nèi)部測試表明，相比未壓縮，使用LZO壓縮的TeraSort

22、作業(yè)運行時間減少60%，且明 顯快于Zlib壓縮。reduce task 相關(guān)配置(1) Mapred.reduce.parallelReduce shuffle階段copier線程數(shù)。默認(rèn)是5，對于較大集群，可調(diào)整為1625。從系統(tǒng)實現(xiàn)角度進(jìn)行優(yōu)化4.1在可移植性和性能之間進(jìn)行權(quán)衡論文16主要針對HDFS進(jìn)行了優(yōu)化，它分析了HDFS性能低下的兩個原因：調(diào)度延遲和可 移植性假設(shè)。(1)調(diào)度延遲Hadoop采用的是動態(tài)調(diào)度算法，即：當(dāng)某個tasktracker上出現(xiàn)空slot時，它會通過HEARBEAT (默認(rèn)時間間隔為3s，當(dāng)集群變大時，會適當(dāng)調(diào)大)告訴jobtracker，之后jobtrac

23、ker采用某 種調(diào)度策略從待選task中選擇一個，再通過HEARBEAT告訴tasktracker。從整個過程看， HDFS在獲取下一個task之前，一直處于等待狀態(tài)，這造成了資源利用率不高。此外，由于 tasktracker獲取新task后，其數(shù)據(jù)讀取過程是完全串行化的，即：tasktracker獲取task后， 依次連接namenode，連接datanode并讀取數(shù)據(jù)，處理數(shù)據(jù)。在此過程中，當(dāng)tasktracker連 接namenode和datanode時，HDFS仍在處于等待狀態(tài)。為了解決調(diào)度延遲問題，可以考慮的解決方案有：重疊I/O和CPU階段（pipelining）, task 預(yù)取

24、（task prefetching），數(shù)據(jù)預(yù)?。╠ata prefetching）等（2）可移植性假設(shè)為了增加Hadoop的可移植性，它采用java語言編寫，這實際上也潛在的造成了 HDFS低效。Java盡管可以讓Hadoop的可移植性增強，但是它屏蔽了底層文件系統(tǒng)，這使它沒法利用一 些底層的API對數(shù)據(jù)存儲和讀寫進(jìn)行優(yōu)化。首先，在共享集群環(huán)境下，大量并發(fā)讀寫會增 加隨機尋道，這大大降低讀寫效率；另外，并發(fā)寫會增加磁盤碎片，這將增加讀取代價（HDFS 適合文件順序讀?。榱私鉀Q該問題，可以考慮的解決方案有：修改tasktracker上的線程模型，現(xiàn)在Hadoop上 的采用的模型是one th

25、read per client，即每個client連接由一個線程處理（包括接受請求， 處理請求，返回結(jié)果）；修改之后，可將線程分成兩組，一組用于處理client通信（Client Thread）， 一組用于存取數(shù)據(jù)（Disk Threads，可采用 one thread per disk）。Prefetching 與 preshuffling論文7提出了兩種優(yōu)化策略，分別為Prefetching和preshuffling。（1）PreFetchingpreFetching 包括 Block-intra prefetching 和 Block-inter prefetching：Block-in

26、tra Prefetching對block內(nèi)部數(shù)據(jù)處理方式進(jìn)行優(yōu)化。采用的策略是以雙向處理 （bi-directional processing）方式提升效率，即一端進(jìn)行計算，一端預(yù)取將要用到的數(shù)據(jù)（同 步機制）。需解決兩個問題，一是計算和預(yù)取同步。借用進(jìn)度條（processing bar）的概念，進(jìn)度條監(jiān)控 兩端的進(jìn)度，當(dāng)同步將被打破時，調(diào)用一個信號。二是確定合適的預(yù)取率。通過實驗發(fā)現(xiàn)， 預(yù)取數(shù)據(jù)量并不是越多越好。采用重復(fù)實驗的方法確定預(yù)取數(shù)據(jù)率。Block-inter Prefetching在block層面預(yù)取數(shù)據(jù)。當(dāng)某個task正在處理數(shù)據(jù)塊A1時，預(yù)測器 預(yù)測它接下來要處理的數(shù)據(jù)塊，假

27、設(shè)是A2, A3, A4,則將這幾個數(shù)據(jù)塊讀到task所在的rack 上，這樣加快了 task接下來數(shù)據(jù)讀取速度。（2）PreShuffling數(shù)據(jù)被map task處理之前，由預(yù)測器判斷每條記錄將要被哪個reduce task處理，將這些數(shù) 據(jù)交由靠近該reduce task的節(jié)點上的map task處理。主頁： HYPERLINK /projects/hama.html /projects/hama.htmlFive Factors論文8分析了 5個影響Hadoop性能的因素，分別為計算模型，I/O模型，數(shù)據(jù)解析，索引 和調(diào)度，同時針對這5個因素提高了相應(yīng)的提高性能的方法，最后實驗證明，通

28、過這些方法 可以將Hadoop性能提高2.5到3.5倍。（1）計算模型在Hadoop中，map task產(chǎn)生的中間結(jié)果經(jīng)過sort-merge策略處理后交給reduce task。而這 種處理策略（指sort-merge）不能夠定制，這對于有些應(yīng)用而言（有些應(yīng)用程序可能不需要 排序處理），性能不佳。此外，即使是需要排序歸并處理的，sort-merge也并不是最好的策 略。本文實現(xiàn)了 Fingerprinting Based Grouping （基于hash）策略，該方法明顯提高了 Hadoop性（2）I/O模型Reader可以采用兩種方式從底層的存儲系統(tǒng)中讀取數(shù)據(jù):direct I/O和str

29、eaming I/O0direct I/O 是指reader直接從本地文件中讀取數(shù)據(jù)；streaming I/O指使用某種進(jìn)程間通信方式（如TCP 或者JDBC）從另外一個進(jìn)程中獲取數(shù)據(jù)。從性能角度考慮，direct I/O性能更高，各種數(shù)據(jù) 庫系統(tǒng)都是采用direct I/O模式。但從存儲獨立性考慮，streaming I/O使Hadoop能夠從任何 進(jìn)程獲取數(shù)據(jù)，如datanode或database，此外，如果reader不得不從遠(yuǎn)程節(jié)點上讀取數(shù)據(jù)， streaming I/O是僅有的選擇。本文對hadoop的文件讀寫方式進(jìn)行了改進(jìn)，當(dāng)文件位于本地時，采用direct I/O方式；當(dāng)文 件

30、位于其它節(jié)點上時，采用streaming I/O方式。（改進(jìn)之前，hadoop全是采用streaming I/O 方式）。改進(jìn)后，效率約提高10%o（3）數(shù)據(jù)解析在hadoop中，原始數(shù)據(jù)要被轉(zhuǎn)換成key/value的形式以便進(jìn)一步處理，這就是數(shù)據(jù)解析?，F(xiàn) 在有兩種數(shù)據(jù)解析方法：immutable decoding and mutable decoding。Hadoop 是采用 java 語言 編寫的，java中很多對象是immutable，如Stringo當(dāng)用戶試圖修改一個String內(nèi)容時，原始 對象會被丟棄而新對象會被創(chuàng)建以存儲新內(nèi)容。在Hadoop中，采用了 immutable對象存儲

31、 字符串，這樣每解析一個record就會創(chuàng)建一個新的對象，這就導(dǎo)致了性能低下。本文比較了 immutable實現(xiàn)和mutable實現(xiàn)，immutable性能遠(yuǎn)高于mutable （join是10倍， select 是 2 倍）。（4）索引HDFS設(shè)計初衷是處理無結(jié)構(gòu)化數(shù)據(jù)，既然這樣，怎么可能為數(shù)據(jù)添加索引。實際上，考慮 到以下幾個因素，仍可以給數(shù)據(jù)添加索引：A、hadoop提供了結(jié)構(gòu)將數(shù)據(jù)記錄解析成key/value對，這樣也許可以給key添加索引。B、如果作業(yè)的輸入是一系列索引文件，可以實現(xiàn)一個新的reader高效處理這些文件。 本文設(shè)計了一個range索引，與原系統(tǒng)比較，連接操作提高了大約

32、10倍，選擇操作大約提 高了 2.5倍。（5）調(diào)度Hadoop采用的是動態(tài)調(diào)度策略，即每次調(diào)度一個task運行，這樣會帶來部分開銷。而database 采用的靜態(tài)調(diào)度的策略，即在編譯的時候就確定了調(diào)度方案。當(dāng)用戶提交一個sql時，優(yōu)化 器會生成一個分布式查詢計劃交給每一個節(jié)點進(jìn)行處理。本文使用一個benchmark評估運行時調(diào)度的代價，最終發(fā)現(xiàn)運行時調(diào)度策略從兩個角度影響 性能：需要調(diào)度的task數(shù)；調(diào)度算法。對于第一個因素，可以調(diào)整block的大小減少task 數(shù)，對于第二個因素，需要做更多研究，設(shè)計新的算法。本文調(diào)整block大?。◤?4增大到5G），發(fā)現(xiàn)block越大，效率越高，提升性能

33、約20%30%。主頁： HYPERLINK .sg/epic/ .sg/epic/總結(jié)這只是一篇研究性的論文，它只是用實驗驗證了這5個因素會影響hadoop性能，具體實現(xiàn) 不具有通用性，如果想將這5個方面在hadoop中實現(xiàn)，并能夠?qū)嶋H的使用，也會還有比較 長的距離。Hadoop+論文9提出了 Hadoop+系統(tǒng)，它為處理結(jié)構(gòu)化或者半結(jié)構(gòu)化數(shù)據(jù)而設(shè)計的，它在Hadoop 基礎(chǔ)上做了兩點改進(jìn)，一是為HDFS設(shè)計了一種索引-Trojan Index。思路是：當(dāng)數(shù)據(jù)被加 載到HDFS時，自動為每個split建立索引，這樣雖然會增加數(shù)據(jù)加載時的代價，但不影響 數(shù)據(jù)處理過程；二是設(shè)計了一種新的join算

34、法一Trojan join。該join算法在數(shù)據(jù)加載時，將 需要join的數(shù)據(jù)表按照join屬性的hash值存放到相同split中，這樣只要在map階段進(jìn)行局 部join便可以得到最終結(jié)果，該算法跳過了 mapreduce的shuffle和reduce階段，避免了數(shù) 據(jù)傳輸?shù)膸淼耐ㄐ糯鷥r，因而大大提高了效率。Hadoop+系統(tǒng)最大的優(yōu)點是沒有直接修改hadoop代碼，只是在Hadoop之上提供了供應(yīng)用 程序訪問的API。官方主頁： HYPERLINK http:/infosys.cs.uni-saarland.de/hadoop+.php http:/infosys.cs.uni-saarl

35、and.de/hadoop+.phpHadoop其它問題單點故障問題Hadoop采用的是C/S架構(gòu)，因而存在明顯的namenode/jobtracker單點故障問題。相比于 jobtracker，namenode的單點故障問題更為急迫，因為namenode的故障恢復(fù)時間很長，其時 間主要花在fsimage加載和blockReport上，下面是一組測試數(shù)據(jù)：當(dāng)前主要的解決思路有：（1）Zookeepero利用分布式系統(tǒng)的可靠協(xié)調(diào)系統(tǒng)zookeeper維護(hù)主從namenode之間的 一致性。（2）熱備。添加熱備從namenode，主從namenode之間通過分布式協(xié)議維護(hù)數(shù)據(jù)一致 性。（3）分布式

36、namespaceo多個namenode共同管理底層的datanode。小文件問題小文件是指文件size小于HDFS上block大小的文件。這樣的文件會給hadoop的擴展性和 性能帶來嚴(yán)重問題。首先，在HDFS中，任何block，文件或者目錄在內(nèi)存中均以對象的形 式存儲，每個對象約占150byte，如果有1000 0000個小文件，每個文件占用一個block，則 namenode需要2G空間（存兩份）。如果存儲1億個文件，則namenode需要20G空間。這 樣namenode內(nèi)存容量嚴(yán)重制約了集群的擴展。其次，訪問大量小文件速度遠(yuǎn)遠(yuǎn)小于訪問 幾個大文件。HDFS最初是為流式訪問大文件開發(fā)的

37、，如果訪問大量小文件，需要不斷的從 一個datanode跳到另一個datanode，嚴(yán)重影響性能。最后，處理大量小文件速度遠(yuǎn)遠(yuǎn)小于處 理同等大小的大文件的速度。每一個小文件要占用一個slot，而task啟動將耗費大量時間甚 至大部分時間都耗費在啟動task和釋放task上。對于Hadoop小文件問題，當(dāng)前主要有兩種解決方案，（1）設(shè)計一種工具（比如mapreduce 作業(yè)）交給用戶，讓用戶自己每隔一段時間將小文件打包成大文件，當(dāng)前Hadoop本身提供 了幾個這樣的工具，包括Hadoop Archive （Hadoop提供了 shell命令），Sequence file （需自 己寫程序?qū)崿F(xiàn)）和

38、CombineFileInputFormat（需自己寫程序?qū)崿F(xiàn)）。（2）從系統(tǒng)層面解決HDFS 小文件，論文1011介紹了它們思路，大體上說思路基本一致：在原有HDFS基礎(chǔ)上添加 一個小文件處理模塊，當(dāng)用戶上傳一個文件時，判斷該文件是否屬于小文件，如果是，則交 給小文件處理模塊處理，否則，交給通用文件處理模塊處理。小文件處理模塊的設(shè)計思想是， 先將很多小文件合并成一個大文件，然后為這些小文件建立索引，以便進(jìn)行快速存取和訪問。總結(jié)本文檔介紹Hadoop現(xiàn)有的優(yōu)化點，總體來說，對于Hadoop平臺，現(xiàn)在主要有三種優(yōu)化思 路，分別為：從應(yīng)用程序角度角度進(jìn)行優(yōu)化;從參數(shù)配置角度進(jìn)行優(yōu)化；從系統(tǒng)實現(xiàn)角度

39、進(jìn) 行優(yōu)化。對于第一種思路，需要根據(jù)具體應(yīng)用需求而定，同時也需要在長期實踐中積累和總 結(jié)；對于第二種思路，大部分采用的方法是根據(jù)自己集群硬件和具體應(yīng)用調(diào)整參數(shù)，找到一 個最優(yōu)的。對于第三種思路，難度較大，但效果往往非常明顯，總結(jié)這方面的優(yōu)化思路，主 要有以下幾個：（1） 對namenode進(jìn)行優(yōu)化，包括增加其吞吐率和解決其單點故障問題。當(dāng)前主要解決方案有 3 種：分布式 namenode， namenode 熱備和 zookeeperoHDFS小文件問題。當(dāng)Hadoop中存儲大量小文件時，namenode擴展性和性能受 到極大制約。現(xiàn)在 Hadoop中已有的解決方案包括：Hadoop Arch

40、ive， Sequence file和 CombineFileInputFormato調(diào)度框架優(yōu)化。在Hadoop中，每當(dāng)出現(xiàn)一個空閑slot后，tasktracker都需要通過 HEARBEAT向jobtracker所要task,這個過程的延遲比較大?？梢杂胻ask預(yù)調(diào)度的策略解決 該問題。共享環(huán)境下的文件并發(fā)存取。在共享環(huán)境下，HDFS的隨機尋道次數(shù)增加，這大 大降低了文件存取效率?？梢酝ㄟ^優(yōu)化磁盤調(diào)度策略的方法改進(jìn)。索引。索引可以大大提高數(shù)據(jù)讀取效率，如果能根據(jù)實際應(yīng)用需求，為HDFS上 的數(shù)據(jù)添加索引，將大大提高效率。7.參考資料1、 HYPERLINK /blogs/hadoop/p

41、osts/2011/02/mapreduce-nextgen/ /blogs/hadoop/posts/2011/02/mapreduce-nextgen/2、 HYPERLINK /2011/01/18/handoop_job_tuning.html /2011/01/18/handoop_job_tuning.html3、Optimizing Hadoop Deployments4、Baidu Hadoop Extension： HYPERLINK /jira/browse/MAPREDUCE-1270 /jira/browse/MAPREDUCE-12705、淘寶數(shù)據(jù)平臺與產(chǎn)品部官方博客

42、：/archives/14236、Shivnath Babu: Towards automatic optimization of MapReduce programs. SoCC 2010: 137-1427、Sangwon Seo et al., HPMR: Prefetching and Pre-shuffling SharedMapReduce Computation Environment. In the Proceedings of 11th IEEEInternational Conference on Cluster Computing, Sep. 20098、D. Jiang, B. C. Ooi, L. Shi, S. Wu: The Performance of MapReduce: An In-depth Study. Int l Conferenc