1. 概述
隨着企業要處理的數據量越來越大，MapReduce思想越來越受到重視。Hadoop是MapReduce的一個開源實現，由於其良好的擴展性和容錯性，已得到越來越廣泛的應用。Hadoop作爲一個基礎數據處理平臺，雖然其應用價值已得到大家認可，但仍存在很多問題，以下是主要幾個：
（1） Namenode/jobtracker單點故障。 Hadoop採用的是master/slaves架構，該架構管理起來比較簡單，但存在致命的單點故障和空間容量不足等缺點，這已經嚴重影響了Hadoop的可擴展性。
（2） HDFS小文件問題。在HDFS中，任何block，文件或者目錄在內存中均以對象的形式存儲，每個對象約佔150byte，如果有1000 0000個小文件，每個文件佔用一個block，則namenode需要2G空間。如果存儲1億個文件，則namenode需要20G空間。這樣namenode內存容量嚴重製約了集羣的擴展。
（3） jobtracker同時進行監控和調度，負載過大。爲了解決該問題，yahoo已經開始着手設計下一代Hadoop MapReduce（見參考資料1）。他們的主要思路是將監控和調度分離，獨立出一個專門的組件進行監控，而jobtracker只負責總體調度，至於局部調度，交給作業所在的client。
（4） 數據處理性能。 很多實驗表明，其處理性能有很大的提升空間。Hadoop類似於數據庫，可能需要專門的優化工程師根據實際的應用需要對Hadoop進行調優，有人稱之爲“Hadoop Performance Optimization” (HPO)。
爲了提高其數據性能，很多人開始優化Hadoop。總結看來，對於Hadoop，當前主要有幾個優化思路：
（1） 從應用程序角度進行優化。由於mapreduce是迭代逐行解析數據文件的，怎樣在迭代的情況下，編寫高效率的應用程序，是一種優化思路。
（2） 對Hadoop參數進行調優。當前hadoop系統有190多個配置參數，怎樣調整這些參數，使hadoop作業運行儘可能的快，也是一種優化思路。
（3） 從系統實現角度進行優化。這種優化難度是最大的，它是從hadoop實現機制角度，發現當前Hadoop設計和實現上的缺點，然後進行源碼級地修改。該方法雖難度大，但往往效果明顯。
以上三種思路出發點均是提高hadoop應用程序的效率。實際上，隨着社會的發展，綠色環保觀念也越來越多地融入了企業，因而很多人開始研究Green Hadoop，即怎樣讓Hadoop完成相應數據處理任務的同時，使用最少的能源（見參考資料[14][15]）。
本文主要介紹了當前學術界的一些優化思路，有人試圖從Hadoop自動配置角度對Hadoop進行優化，但更多的是從系統實現角度進行優化，概括其優化點和實驗效果如下：
（1） 論文[6]試圖從參數自動調優角度對Hadoop進行優化，論文只給出了可能的解決方案，並未給出實現，因而效果不可知。但它給出了一種Hadoop優化的新思路，即怎樣對其190多個配置參數進行自動調整，使應用程序執行效率最高。
（2） 論文[7]提出prefetching和preshuffling機制，在不同負載不同規模集羣下測試，效率提升了約73%。
（3） 論文[8]研究了影響Hadoop效率的五個因素，並通過提出相應的解決方案，使Hadoop效率提高了2.5~3.5倍。
（4） 論文[9]爲Hadoop提供了一種索引機制– Trojan Index，同時提出了一種高效的join算法– Trojan Join，實驗表明，效率比Hadoop和HadoopDB高很多。
除了學術界的優化，工業界也在不斷進行優化以適應自己公司的產品需要，主要有：
（1）Baidu公司。baidu對Hadoop中關鍵組件使用C++進行了重寫（包括map, shuffler和reducer等），經他們內部測試（5 nodes，40GB data），效率提升了約20%（見參考資料[4]）。
（2）淘寶。淘寶針對自己集羣特點（作業小，slot多，作業之間有依賴，集羣共享，有些作業有時效性），對jobtracker和namenode進行了優化，據其官方博客稱，其jobtracker有較大性能提升，且namenode吞吐量提升了8+倍（見參考資料[5]）。但其具體優化方法，未公開。
2. 從應用程序角度進行優化
（1） 避免不必要的reduce任務
如果要處理的數據是排序且已經分區的，或者對於一份數據, 需要多次處理, 可以先排序分區；然後自定義InputSplit, 將單個分區作爲單個mapred的輸入；在map中處理數據, Reducer設置爲空。
這樣, 既重用了已有的 “排序”, 也避免了多餘的reduce任務。
（2）外部文件引入
有些應用程序要使用外部文件，如字典，配置文件等，這些文件需要在所有task之間共享，可以放到分佈式緩存DistributedCache中（或直接採用-files選項，機制相同）。
更多的這方面的優化方法，還需要在實踐中不斷積累。
（3） 爲job添加一個Combiner
爲job添加一個combiner可以大大減少shuffle階段從map task拷貝給遠程reduce task的數據量。一般而言，combiner與reducer相同。
（4） 根據處理數據特徵使用最適合和簡潔的Writable類型
Text對象使用起來很方便，但它在由數值轉換到文本或是由UTF8字符串轉換到文本時都是低效的，且會消耗大量的CPU時間。當處理那些非文本的數據時，可以使用二進制的Writable類型，如IntWritable， FloatWritable等。二進制writable好處：避免文件轉換的消耗；使map task中間結果佔用更少的空間。
（5） 重用Writable類型
很多MapReduce用戶常犯的一個錯誤是，在一個map/reduce方法中爲每個輸出都創建Writable對象。例如，你的Wordcout mapper方法可能這樣寫：
|
1
2
3
4
5
6
7
8
9
10
11
|
public
void map(...) { … for
(String word : words) { output.collect(new
Text(word), new
IntWritable(1)); }} |
這樣會導致程序分配出成千上萬個短週期的對象。Java垃圾收集器就要爲此做很多的工作。更有效的寫法是：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
class
MyMapper … { Text wordText =
new Text(); IntWritable one =
new IntWritable(1); public
void map(...) { for
(String word: words) { wordText.set(word); output.collect(wordText, one); } }} |
（6） 使用StringBuffer而不是String
當需要對字符串進行操作時，使用StringBuffer而不是String，String是read-only的，如果對它進行修改，會產生臨時對象，而StringBuffer是可修改的，不會產生臨時對象。
（7）調試
最重要，也是最基本的，是要掌握MapReduce程序調試方法，跟蹤程序的瓶頸。具體可參考：
http://www.cloudera.com/blog/2009/12/7-tips-for-improving-mapreduce-performance/
3. 對參數進行調優
3.1 參數自動調優
論文[6]試圖從自動化參數調優角度對hadoop應用程序運行效率進行優化。Hadoop目前有190多個配置參數，其中大約有25個對hadoop應用程序效率有顯著的影響。
論文首先分析了database優化思路。Database會根據用戶輸入的SQL建立一個代價模型：，其中y表示查詢q優化目標（如運行時間），p表示q的查詢計劃，r表示爲執行計劃p而申請的資源量，d表示一些統計信息。數據庫會根據該代價模型評估不同的查詢計劃，並選擇一個最優的執行查詢。這種數據庫模型很難擴展應用到mapreduce環境中，主要是因爲：
（1） mapreduce作業一般是採用C，C++或java編寫，與聲明性語言SQL有明顯不同。
（2） 缺少有關輸入數據的統計信息。Mapreduce作業通常是運行時解析動態輸入文件的，因而運行之前schema或者統計信息均是未知的。
（3） 它們的優化空間不同。數據庫的查詢優化空間（主要是選擇最優的plan）與mapreduce的優化空間（主要是配置參數調優）不同。
本論文提出了三種可行的方案，第一種是基於採樣的方法，借鑑Terasort作業的思路，先對輸入數據進行採樣，然後通過樣本估算不同配置下作業的執行時間，最後選擇一種最優的配置。該方法需要解決的一個問題是，由於reduce階段和map階段存在數據依賴，因而map完成之前，reduce的所有信息均是未知的。有一種也是可行的思路是，執行作業之前，先採樣選擇一個樣本組成一個小作業，然後執行該小作業以估算大作業性能。該方法也存在一個需要解決的問題，怎樣採樣才能使樣本最能代表總體？
第二種是Late Binding，即延遲綁定，其思想是延遲設置其中的一個或多個參數，直到job已經部分執行，且這些參數可以確定。比如hadoop中的combiner操作實際就是採用的這一機制，作業在執行完map()之前不知道要不要進行combine。
第三種是Competition-based Approaches，其思想是，首先，同時執行多個配置有不同參數的task，然後，儘快決定哪種配置的task執行速度快，最後，殺掉其它task。
該文章完全是個調研性的論文，它先研究了數據庫的一些調優方法，經過研究發現不可以直接將這些方法應用於mapreduce系統中，進而針對mapreduce獨有的特點，提出了幾種也許可行的方法，但論文中並未給出實現。
3.2 參數手工配置
3.2.1 Linux文件系統參數調整
（1） noatime 和 nodiratime屬性
文件掛載時設置這兩個屬性可以明顯提高性能。。默認情況下，Linux ext2/ext3 文件系統在文件被訪問、創建、修改時會記錄下文件的時間戳，比如：文件創建時間、最近一次修改時間和最近一次訪問時間。如果系統運行時要訪問大量文件，關閉這些操作，可提升文件系統的性能。Linux 提供了 noatime 這個參數來禁止記錄最近一次訪問時間戳。
（2） readahead buffer
調整linux文件系統中預讀緩衝區地大小，可以明顯提高順序讀文件的性能。默認buffer大小爲256 sectors，可以增大爲1024或者2408 sectors（注意，並不是越大越好）。可使用blockdev命令進行調整。
（3） 避免RAID和LVM操作
避免在TaskTracker和DataNode的機器上執行RAID和LVM操作，這通常會降低性能。
3.2.2 Hadoop通用參數調整
（1） dfs.namenode.handler.count或mapred.job.tracker.handler.count
namenode或者jobtracker中用於處理RPC的線程數，默認是10，較大集羣，可調大些，比如64。
（2） dfs.datanode.handler.count
datanode上用於處理RPC的線程數。默認爲3，較大集羣，可適當調大些，比如8。需要注意的是，每添加一個線程，需要的內存增加。
（3） tasktracker.http.threads
HTTP server上的線程數。運行在每個TaskTracker上，用於處理map task輸出。大集羣，可以將其設爲40~50。
3.2.3 HDFS相關配置
（1） dfs.replication
文件副本數，通常設爲3，不推薦修改。
（2） dfs.block.size
HDFS中數據block大小，默認爲64M，對於較大集羣，可設爲128MB或者256MB。（也可以通過參數mapred.min.split.size配置）
（3） mapred.local.dir和dfs.data.dir
這兩個參數mapred.local.dir和dfs.data.dir 配置的值應當是分佈在各個磁盤上目錄，這樣可以充分利用節點的IO讀寫能力。運行 Linux sysstat包下的iostat -dx 5命令可以讓每個磁盤都顯示它的利用率。
3.2.4 map/reduce 相關配置
（1） {map/reduce}.tasks.maximum
同時運行在TaskTracker上的最大map/reduce task數，一般設爲(core_per_node)/2~2*（cores_per_node）。
（2） io.sort.factor
當一個map task執行完之後，本地磁盤上(mapred.local.dir)有若干個spill文件，map task最後做的一件事就是執行merge sort，把這些spill文件合成一個文件（partition）。執行merge sort的時候，每次同時打開多少個spill文件由該參數決定。打開的文件越多，不一定merge sort就越快，所以要根據數據情況適當的調整。
（3） mapred.child.java.opts
設置JVM堆的最大可用內存，需從應用程序角度進行配置。
3.2.5 map task相關配置
（1） io.sort.mb
Map task的輸出結果和元數據在內存中所佔的buffer總大小。默認爲100M，對於大集羣，可設爲200M。當buffer達到一定閾值，會啓動一個後臺線程來對buffer的內容進行排序，然後寫入本地磁盤(一個spill文件)。
（2） io.sort.spill.percent
這個值就是上述buffer的閾值，默認是0.8，即80%，當buffer中的數據達到這個閾值，後臺線程會起來對buffer中已有的數據進行排序，然後寫入磁盤。
（3） io.sort.record
Io.sort.mb中分配給元數據的內存百分比，默認是0.05。這個需要根據應用程序進行調整。
（4） mapred.compress.map.output/ Mapred.output.compress
中間結果和最終結果是否要進行壓縮，如果是，指定壓縮方式（Mapred.compress.map.output.codec/ Mapred.output.compress.codec）。推薦使用LZO壓縮。Intel內部測試表明，相比未壓縮，使用LZO壓縮的TeraSort作業運行時間減少60%，且明顯快於Zlib壓縮。
3.2.6 reduce task相關配置
（1） Mapred.reduce.parallel
Reduce shuffle階段copier線程數。默認是5，對於較大集羣，可調整爲16~25。
4. 從系統實現角度進行優化
4.1 在可移植性和性能之間進行權衡
論文[16]主要針對HDFS進行了優化，它分析了HDFS性能低下的兩個原因：調度延遲和可移植性假設。
（1） 調度延遲
Hadoop採用的是動態調度算法，即：當某個tasktracker上出現空slot時，它會通過HEARBEAT（默認時間間隔爲3s，當集羣變大時，會適當調大）告訴jobtracker，之後jobtracker採用某種調度策略從待選task中選擇一個，再通過HEARBEAT告訴tasktracker。從整個過程看，HDFS在獲取下一個task之前，一直處於等待狀態，這造成了資源利用率不高。此外，由於tasktracker獲取新task後，其數據讀取過程是完全串行化的，即：tasktracker獲取task後，依次連接namenode，連接datanode並讀取數據，處理數據。在此過程中，當tasktracker連接namenode和datanode時，HDFS仍在處於等待狀態。
爲了解決調度延遲問題，可以考慮的解決方案有：重疊I/O和CPU階段（pipelining），task預取（task prefetching），數據預取（data prefetching）等
（2）可移植性假設
爲了增加Hadoop的可移植性，它採用java語言編寫，這實際上也潛在的造成了HDFS低效。Java儘管可以讓Hadoop的可移植性增強，但是它屏蔽了底層文件系統，這使它沒法利用一些底層的API對數據存儲和讀寫進行優化。首先，在共享集羣環境下，大量併發讀寫會增加隨機尋道，這大大降低讀寫效率；另外，併發寫會增加磁盤碎片，這將增加讀取代價（HDFS適合文件順序讀取）。
爲了解決該問題，可以考慮的解決方案有：修改tasktracker上的線程模型，現在Hadoop上的採用的模型是one thread per client，即每個client連接由一個線程處理（包括接受請求，處理請求，返回結果）；修改之後，可將線程分成兩組，一組用於處理client通信（Client Thread），一組用於存取數據（Disk Threads，可採用one thread per disk）。
4.2 Prefetching與preshuffling
論文[7]提出了兩種優化策略，分別爲Prefetching和preshuffling。
(1) PreFetching
preFetching包括Block-intra prefetching和Block-inter prefetching：
Block-intra Prefetching對block內部數據處理方式進行優化。採用的策略是以雙向處理（bi-directional processing）方式提升效率，即一端進行計算，一端預取將要用到的數據（同步機制）。
需解決兩個問題，一是計算和預取同步。借用進度條（processing bar）的概念，進度條監控兩端的進度，當同步將被打破時，調用一個信號。二是確定合適的預取率。通過實驗發現，預取數據量並不是越多越好。採用重複實驗的方法確定預取數據率。
Block-inter Prefetching在block層面預取數據。當某個task正在處理數據塊A1時，預測器預測它接下來要處理的數據塊，假設是A2，A3，A4,則將這幾個數據塊讀到task所在的rack上，這樣加快了task接下來數據讀取速度。
(2) PreShuffling
數據被map task處理之前，由預測器判斷每條記錄將要被哪個reduce task處理，將這些數據交由靠近該reduce task的節點上的map task處理。
主頁：http://incubator.apache.org/projects/hama.html
4.3 Five Factors
論文[8]分析了5個影響Hadoop性能的因素，分別爲計算模型，I/O模型，數據解析，索引和調度，同時針對這5個因素提高了相應的提高性能的方法，最後實驗證明，通過這些方法可以將Hadoop性能提高2.5到3.5倍。
（1） 計算模型
在Hadoop中，map task產生的中間結果經過sort-merge策略處理後交給reduce task。而這種處理策略（指sort-merge）不能夠定製，這對於有些應用而言（有些應用程序可能不需要排序處理），性能不佳。此外，即使是需要排序歸併處理的，sort-merge也並不是最好的策略。
本文實現了Fingerprinting Based Grouping（基於hash）策略，該方法明顯提高了Hadoop性能。
（2） I/O模型
Reader可以採用兩種方式從底層的存儲系統中讀取數據：direct I/O和streaming I/O。direct I/O是指reader直接從本地文件中讀取數據；streaming I/O指使用某種進程間通信方式（如TCP或者JDBC）從另外一個進程中獲取數據。從性能角度考慮，direct I/O性能更高，各種數據庫系統都是採用direct I/O模式。但從存儲獨立性考慮，streaming I/O使Hadoop能夠從任何進程獲取數據，如datanode或database，此外，如果reader不得不從遠程節點上讀取數據，streaming I/O是僅有的選擇。
本文對hadoop的文件讀寫方式進行了改進，當文件位於本地時，採用direct I/O方式；當文件位於其它節點上時，採用streaming I/O方式。（改進之前，hadoop全是採用streaming I/O方式）。改進後，效率約提高10%。
（3） 數據解析
在hadoop中，原始數據要被轉換成key/value的形式以便進一步處理，這就是數據解析。現在有兩種數據解析方法：immutable decoding and mutable decoding。Hadoop是採用java語言編寫的，java中很多對象是immutable，如String。當用戶試圖修改一個String內容時，原始對象會被丟棄而新對象會被創建以存儲新內容。在Hadoop中，採用了immutable對象存儲字符串，這樣每解析一個record就會創建一個新的對象，這就導致了性能低下。
本文比較了immutable實現和mutable實現，immutable性能遠高於mutable（join是10倍，select是2倍）。
（4） 索引
HDFS設計初衷是處理無結構化數據，既然這樣，怎麼可能爲數據添加索引。實際上，考慮到以下幾個因素，仍可以給數據添加索引：
A、 hadoop提供了結構將數據記錄解析成key/value對，這樣也許可以給key添加索引。
B、 如果作業的輸入是一系列索引文件，可以實現一個新的reader高效處理這些文件。
本文設計了一個range 索引，與原系統比較，連接操作提高了大約10倍，選擇操作大約提高了2.5倍。
（5） 調度
Hadoop採用的是動態調度策略，即每次調度一個task運行，這樣會帶來部分開銷。而database採用的靜態調度的策略，即在編譯的時候就確定了調度方案。當用戶提交一個sql時，優化器會生成一個分佈式查詢計劃交給每一個節點進行處理。
本文使用一個benchmark評估運行時調度的代價，最終發現運行時調度策略從兩個角度影響性能：需要調度的task數；調度算法。對於第一個因素，可以調整block的大小減少task數，對於第二個因素，需要做更多研究，設計新的算法。
本文調整block大小(從64增大到5G)，發現block越大，效率越高，提升性能約20%~30%。
主頁：http://www.comp.nus.edu.sg/~epic/
總結
這只是一篇研究性的論文，它只是用實驗驗證了這5個因素會影響hadoop性能，具體實現不具有通用性，如果想將這5個方面在hadoop中實現，並能夠實際的使用，也會還有比較長的距離。
4.4 Hadoop++
論文[9]提出了Hadoop++系統，它爲處理結構化或者半結構化數據而設計的，它在Hadoop基礎上做了兩點改進，一是爲HDFS設計了一種索引—Trojan Index。思路是：當數據被加載到HDFS時，自動爲每個split建立索引，這樣雖然會增加數據加載時的代價，但不影響數據處理過程；二是設計了一種新的join算法—Trojan join。該join算法在數據加載時，將需要join的數據表按照join屬性的hash值存放到相同split中，這樣只要在map階段進行局部join便可以得到最終結果，該算法跳過了mapreduce的shuffle和reduce階段，避免了數據傳輸的帶來的通信代價，因而大大提高了效率。
Hadoop++系統最大的優點是沒有直接修改hadoop代碼，只是在Hadoop之上提供了供應用程序訪問的API。
官方主頁：http://infosys.cs.uni-saarland.de/hadoop++.php
5. Hadoop其它問題
5.1 單點故障問題
Hadoop採用的是C/S架構，因而存在明顯的namenode/jobtracker單點故障問題。相比於jobtracker，namenode的單點故障問題更爲急迫，因爲namenode的故障恢復時間很長，其時間主要花在fsimage加載和blockReport上，下面是一組測試數據：
當前主要的解決思路有：
（1） Zookeeper。利用分佈式系統的可靠協調系統zookeeper維護主從namenode之間的一致性。
（2） 熱備。添加熱備從namenode，主從namenode之間通過分佈式協議維護數據一致性。
（3） 分佈式namespace。多個namenode共同管理底層的datanode。
5.2 小文件問題
小文件是指文件size小於HDFS上block大小的文件。這樣的文件會給hadoop的擴展性和性能帶來嚴重問題。首先，在HDFS中，任何block，文件或者目錄在內存中均以對象的形式存儲，每個對象約佔150byte，如果有1000 0000個小文件，每個文件佔用一個block，則namenode需要2G空間（存兩份）。如果存儲1億個文件，則namenode需要20G空間。這樣namenode內存容量嚴重製約了集羣的擴展。 其次，訪問大量小文件速度遠遠小於訪問幾個大文件。HDFS最初是爲流式訪問大文件開發的，如果訪問大量小文件，需要不斷的從一個datanode跳到另一個datanode，嚴重影響性能。最後，處理大量小文件速度遠遠小於處理同等大小的大文件的速度。每一個小文件要佔用一個slot，而task啓動將耗費大量時間甚至大部分時間都耗費在啓動task和釋放task上。
對於Hadoop小文件問題，當前主要有兩種解決方案，（1）設計一種工具（比如mapreduce作業）交給用戶，讓用戶自己每隔一段時間將小文件打包成大文件，當前Hadoop本身提供了幾個這樣的工具，包括Hadoop Archive（Hadoop提供了shell命令），Sequence file（需自己寫程序實現）和CombineFileInputFormat（需自己寫程序實現）。（2）從系統層面解決HDFS小文件，論文[10][11]介紹了它們思路，大體上說思路基本一致：在原有HDFS基礎上添加一個小文件處理模塊，當用戶上傳一個文件時，判斷該文件是否屬於小文件，如果是，則交給小文件處理模塊處理，否則，交給通用文件處理模塊處理。小文件處理模塊的設計思想是，先將很多小文件合併成一個大文件，然後爲這些小文件建立索引，以便進行快速存取和訪問。
6. 總結
本文檔介紹Hadoop現有的優化點，總體來說，對於Hadoop平臺，現在主要有三種優化思路，分別爲：從應用程序角度角度進行優化；從參數配置角度進行優化；從系統實現角度進行優化。對於第一種思路，需要根據具體應用需求而定，同時也需要在長期實踐中積累和總結；對於第二種思路，大部分採用的方法是根據自己集羣硬件和具體應用調整參數，找到一個最優的。對於第三種思路，難度較大，但效果往往非常明顯，總結這方面的優化思路，主要有以下幾個：
（1） 對namenode進行優化，包括增加其吞吐率和解決其單點故障問題。當前主要解決方案有3種：分佈式namenode，namenode熱備和zookeeper。
（2） HDFS小文件問題。當Hadoop中存儲大量小文件時，namenode擴展性和性能受到極大制約。現在Hadoop中已有的解決方案包括：Hadoop Archive，Sequence file和CombineFileInputFormat。
（3） 調度框架優化。在Hadoop中，每當出現一個空閒slot後，tasktracker都需要通過HEARBEAT向jobtracker所要task，這個過程的延遲比較大。可以用task預調度的策略解決該問題。
（4） 共享環境下的文件併發存取。在共享環境下，HDFS的隨機尋道次數增加，這大大降低了文件存取效率。可以通過優化磁盤調度策略的方法改進。
（5） 索引。索引可以大大提高數據讀取效率，如果能根據實際應用需求，爲HDFS上的數據添加索引，將大大提高效率。
7. 參考資料
1、 http://developer.yahoo.com/blogs/hadoop/posts/2011/02/mapreduce-nextgen/
2、http://www.webguo.com/2011/01/18/handoop_job_tuning.html
3、 Optimizing Hadoop Deployments
4、 Baidu Hadoop Extension：https://issues.apache.org/jira/browse/MAPREDUCE-1270
5、 淘寶數據平臺與產品部官方博客：http://www.tbdata.org/archives/1423
6、 Shivnath Babu: Towards automatic optimization of MapReduce programs. SoCC 2010: 137-142
7、 Sangwon Seo et al., HPMR: Prefetching and Pre-shuffling SharedMapReduce Computation Environment. In the Proceedings of 11th IEEEInternational Conference on Cluster Computing, Sep. 2009
8、 D. Jiang, B. C. Ooi, L. Shi, S. Wu: The Performance of MapReduce: An In-depth Study. Int’l Conference onVery Large Data Bases (VLDB), 2010
9、 Jens Dittrich, Jorge-Arnulfo Quiane-Ruiz, Alekh Jindal, Yagiz Kargin, Vinay Setty, and Jörg Schad Hadoop++: Making a Yellow Elephant Run Like a Cheetah (Without It Even Noticing)VLDB 2010/PVLDB, Singapore
10、Xuhui Liu, Jizhong Han, Yunqin Zhong, Chengde Han, Xubin He: Implementing WebGIS on Hadoop: A case study of improving small file I/O performance on HDFS. CLUSTER 2009: 1-8
11、Bo Dong, Jie Qiu, Qinghua Zheng, Xiao Zhong, Jingwei Li, Ying Li. A Novel Approach to Improving the Efficiency of Storing and Accessing Small Files on Hadoop: A Case Study by PowerPoint Files. In Proceedings of IEEE SCC’2010. pp.65~72
12、https://issues.apache.org/jira/browse/HDFS-1052
13、Feng Wang, Jie Qiu, Jie Yang, Bo Dong, Xin Hui Li, Ying Li. Hadoop high availability through metadata replication. In Proceedings of CloudDB’2009. pp.37~44
14、 Rini T. Kaushik, Milind A. Bhandarkar, Klara Nahrstedt. Evaluation and Analysis of GreenHDFS: A Self-Adaptive, Energy-Conserving Variant of the Hadoop Distributed File System. In Proceedings of CloudCom’2010. pp.274~287
15、 Willis Lang, Jignesh M. Patel. Energy Management for MapReduce Clusters. PVLDB, 2010: 129~139
16、Jeffrey Shafer, Scott Rixner, Alan L. Cox: The Hadoop distributed filesystem: Balancing portability and performance. ISPASS 2010: 122-1
17、博文：7 Tips for Improving MapReduce Performance