共計(jì) 7451 個(gè)字符，預(yù)計(jì)需要花費(fèi) 19 分鐘才能閱讀完成。

本篇內(nèi)容介紹了“提高 MapReduce 性能的方法有哪些”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓丸趣 TV 小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

  Cloudera 提供給客戶的服務(wù)內(nèi)容之一就是調(diào)整和優(yōu)化 MapReduce job 執(zhí)行性能。MapReduce 和 HDFS 組成一個(gè)復(fù)雜的分布式系統(tǒng)，并且它們運(yùn)行著各式各樣用戶的代碼，這樣導(dǎo)致沒有一個(gè)快速有效的規(guī)則來(lái)實(shí)現(xiàn)優(yōu)化代碼性能的目的。在我看來(lái)，調(diào)整 cluster 或 job 的運(yùn)行更像一個(gè)醫(yī)生對(duì)待病人一樣，找出關(guān)鍵的“癥狀”，對(duì)于不同的癥狀有不同的診斷和處理方式。

  在醫(yī)學(xué)領(lǐng)域，沒有什么可以代替一位經(jīng)驗(yàn)豐富的醫(yī)生；在復(fù)雜的分布式系統(tǒng)上，這個(gè)道理依然正確—有經(jīng)驗(yàn)的用戶和操作者在面對(duì)很多常見問題上都會(huì)有“第六感”。我曾經(jīng)為 Cloudera 不同行業(yè)的客戶解決過(guò)問題，他們面對(duì)的工作量、數(shù)據(jù)集和 cluster 硬件有很大區(qū)別，因此我在這方面積累了很多的經(jīng)驗(yàn)，并且想把這些經(jīng)驗(yàn)分享給諸位。

  在這篇 blog 里，我會(huì)高亮那些提高 MapReduce 性能的建議。前面的一些建議是面向整個(gè) cluster 的，這可能會(huì)對(duì) cluster 操作者和開發(fā)者有幫助。后面一部分建議是為那些用 Java 編寫 MapReduce job 的開發(fā)者而提出。在每一個(gè)建議中，我列出一些“癥狀”或是“診斷測(cè)試”來(lái)說(shuō)明一些針對(duì)這些問題的改進(jìn)措施，可能會(huì)對(duì)你有所幫助。

  請(qǐng)注意，這些建議中包含很多我以往從各種不同場(chǎng)景下總結(jié)出來(lái)的直觀經(jīng)驗(yàn)。它們可能不太適用于你所面對(duì)的特殊的工作量、數(shù)據(jù)集或 cluster，如果你想使用它，就需要測(cè)試使用前和使用后它在你的 cluster 環(huán)境中的表現(xiàn)。對(duì)于這些建議，我會(huì)展示一些對(duì)比性的數(shù)據(jù)，數(shù)據(jù)產(chǎn)生的環(huán)境是一個(gè) 4 個(gè)節(jié)點(diǎn)的 cluster 來(lái)運(yùn)行 40GB 的 Wordcount job。應(yīng)用了我以下所提到的這些建議后，這個(gè) job 中的每個(gè) map task 大概運(yùn)行 33 秒，job 總共執(zhí)行了差不多 8 分 30 秒。

第一點(diǎn)   正確地配置你的 Cluster
診斷結(jié)果 / 癥狀：
1. Linux top 命令的結(jié)果顯示 slave 節(jié)點(diǎn)在所有 map 和 reduce slot 都有 task 運(yùn)行時(shí)依然很空閑。
2. top 命令顯示內(nèi)核的進(jìn)程，如 RAID(mdX_raid*) 或 pdflush 占去大量的 CPU 時(shí)間。
3. Linux 的平均負(fù)載通常是系統(tǒng) CPU 數(shù)量的 2 倍。
4. 即使系統(tǒng)正在運(yùn)行 job，Linux 平均負(fù)載總是保持在系統(tǒng) CPU 數(shù)量的一半的狀態(tài)。
5. 一些節(jié)點(diǎn)上的 swap 利用率超過(guò)幾 MB

  優(yōu)化你的 MapReduce 性能的第一步是確保你整個(gè) cluster 的配置文件被調(diào)整過(guò)。對(duì)于新手，請(qǐng)參考這里關(guān)于配置參數(shù)的一篇 blog：配置參數(shù)。除了這些配置參數(shù)，在你想修改 job 參數(shù)以期提高性能時(shí)，你應(yīng)該參照下我這里的一些你應(yīng)該注意的項(xiàng)：

1.  確保你正在 DFS 和 MapReduce 中使用的存儲(chǔ) mount 被設(shè)置了 noatime 選項(xiàng)。這項(xiàng)如果設(shè)置就不會(huì)啟動(dòng)對(duì)磁盤訪問時(shí)間的記錄，會(huì)顯著提高 IO 的性能。

2. 避免在 TaskTracker 和 DataNode 的機(jī)器上執(zhí)行 RAID 和 LVM 操作，這通常會(huì)降低性能

3. 在這兩個(gè)參數(shù) mapred.local.dir 和 dfs.data.dir 配置的值應(yīng)當(dāng)是分布在各個(gè)磁盤上目錄，這樣可以充分利用節(jié)點(diǎn)的 IO 讀寫能力。運(yùn)行 Linux sysstat 包下的 iostat -dx 5 命令可以讓每個(gè)磁盤都顯示它的利用率。

4. 你應(yīng)該有一個(gè)聰明的監(jiān)控系統(tǒng)來(lái)監(jiān)控磁盤設(shè)備的健康狀態(tài)。MapReduce job 的設(shè)計(jì)是可容忍磁盤失敗，但磁盤的異常會(huì)導(dǎo)致一些 task 重復(fù)執(zhí)行而使性能下降。如果你發(fā)現(xiàn)在某個(gè) TaskTracker 被很多 job 中列入黑名單，那么它就可能有問題。

5. 使用像 Ganglia 這樣的工具監(jiān)控并繪出 swap 和網(wǎng)絡(luò)的利用率圖。如果你從監(jiān)控的圖看出機(jī)器正在使用 swap 內(nèi)存，那么減少 mapred.child.java.opts 屬性所表示的內(nèi)存分配。

基準(zhǔn)測(cè)試：
  很遺憾我不能為這個(gè)建議去生成一些測(cè)試數(shù)據(jù)，因?yàn)檫@需要構(gòu)建整個(gè) cluster。如果你有相關(guān)的經(jīng)驗(yàn)，請(qǐng)把你的建議及結(jié)果附到下面的留言區(qū)。

第二點(diǎn)   使用 LZO 壓縮
診斷結(jié)果 / 癥狀：
1. 對(duì) job 的中間結(jié)果數(shù)據(jù)使用壓縮是很好的想法。
2. MapReduce job 的輸出數(shù)據(jù)大小是不可忽略的。
3. 在 job 運(yùn)行時(shí)，通過(guò) linux top 和 iostat 命令可以看出 slave 節(jié)點(diǎn)的 iowait 利用率很高。

  幾乎每個(gè) Hadoop job 都可以通過(guò)對(duì) map task 輸出的中間數(shù)據(jù)做 LZO 壓縮獲得較好的空間效益。盡管 LZO 壓縮會(huì)增加一些 CPU 的負(fù)載，但在 shuffle 過(guò)程中會(huì)減少磁盤 IO 的數(shù)據(jù)量，總體上總是可以節(jié)省時(shí)間的。

  當(dāng)一個(gè) job 需要輸出大量數(shù)據(jù)時(shí)，應(yīng)用 LZO 壓縮可以提高輸出端的輸出性能。這是因?yàn)槟J(rèn)情況下每個(gè)文件的輸出都會(huì)保存 3 個(gè)幅本，1GB 的輸出文件你將要保存 3GB 的磁盤數(shù)據(jù)，當(dāng)采用壓縮后當(dāng)然更能節(jié)省空間并提高性能。

  為了使 LZO 壓縮有效，請(qǐng)?jiān)O(shè)置參數(shù) mapred.compress.map.output 值為 true。

基準(zhǔn)測(cè)試：
  在我的 cluster 里，Wordcount 例子中不使用 LZO 壓縮的話，job 的運(yùn)行時(shí)間只是稍微增加。但 FILE_BYTES_WRITTEN 計(jì)數(shù)器卻從 3.5GB 增長(zhǎng)到 9.2GB，這表示壓縮會(huì)減少 62% 的磁盤 IO。在我的 cluster 里，每個(gè)數(shù)據(jù)節(jié)點(diǎn)上磁盤數(shù)量對(duì) task 數(shù)量的比例很高，但 Wordcount job 并沒有在整個(gè) cluster 中共享，所以 cluster 中 IO 不是瓶頸，磁盤 IO 增長(zhǎng)不會(huì)有什么大的問題。但對(duì)于磁盤因很多并發(fā)活動(dòng)而受限的環(huán)境來(lái)說(shuō)，磁盤 IO 減少 60% 可以大幅提高 job 的執(zhí)行速度。

第三點(diǎn)   調(diào)整 map 和 reduce task 的數(shù)量到合適的值

自己的經(jīng)驗(yàn)，一般來(lái)說(shuō)，不可能跑一個(gè) job，改變整個(gè)集群的 hdfs block 的大小。通常提交 job 時(shí)候設(shè)置參數(shù)。

  job.setMapOutputValueClass(IntWritable.class);
       job.setNumReduceTasks(1);
       // 設(shè)置最小分片為 512M
       FileInputFormat.setMinInputSplitSize(job, 1024*1024*512);
       FileInputFormat.addInputPath(job, new Path( /usr/keyword/input));

診斷結(jié)果 / 癥狀：
1. 每個(gè) map 或 reduce task 的完成時(shí)間少于 30 到 40 秒。
2. 大型的 job 不能完全利用 cluster 中所有空閑的 slot。
3. 大多數(shù) map 或 reduce task 被調(diào)度執(zhí)行了，但有一到兩個(gè) task 還在準(zhǔn)備狀態(tài)，在其它 task 完成之后才單獨(dú)執(zhí)行

  調(diào)整 job 中 map 和 reduce task 的數(shù)量是一件很重要且常常被忽略的事情。下面是我在設(shè)置這些參數(shù)時(shí)的一些直觀經(jīng)驗(yàn)：

1. 如果每個(gè) task 的執(zhí)行時(shí)間少于 30 到 40 秒，就減少 task 的數(shù)量。Task 的創(chuàng)建與調(diào)度一般耗費(fèi)幾秒的時(shí)間，如果 task 完成的很快，我們就是在浪費(fèi)時(shí)間。同時(shí)，設(shè)置 JVM 重用也可以解決這個(gè)問題。

2. 如果一個(gè) job 的輸入數(shù)據(jù)大于 1TB，我們就增加 block size 到 256 或者 512，這樣可以減少 task 的數(shù)量。你可以使用這個(gè)命令去修改已存在文件的 block size: hadoop distcp -Ddfs.block.size=$[256*1024*1024] /path/to/inputdata  /path/to/inputdata-with/largeblocks。在執(zhí)行完這個(gè)命令后，你就可以刪除原始的輸入文件了 (/path/to/inputdata)。

3. 只要每個(gè) task 運(yùn)行至少 30 到 40 秒，那么就增加 map task 的數(shù)量，增加到整個(gè) cluster 上 map slot 總數(shù)的幾倍。如果你的 cluster 中有 100 個(gè) map slot，那就避免運(yùn)行一個(gè)有 101 個(gè) map task 的 job — 如果運(yùn)行的話，前 100 個(gè) map 同時(shí)執(zhí)行，第 101 個(gè) task 會(huì)在 reduce 執(zhí)行之前單獨(dú)運(yùn)行。這個(gè)建議對(duì)于小型 cluste 和小型 job 是很重要的。

4. 不要調(diào)度太多的 reduce task — 對(duì)于大多數(shù) job 來(lái)說(shuō)，我們推薦 reduce task 的數(shù)量應(yīng)當(dāng)?shù)扔诨蚴锹孕∮?cluster 中 reduce slot 的數(shù)量。

基準(zhǔn)測(cè)試：
  為了讓 Wordcount job 有很多的 task 運(yùn)行，我設(shè)置了如下的參數(shù)：Dmapred.max.split.size=$[16*1024*1024]。以前默認(rèn)會(huì)產(chǎn)生 360 個(gè) map task，現(xiàn)在就會(huì)有 2640 個(gè)。當(dāng)完成這個(gè)設(shè)置之后，每個(gè) task 執(zhí)行耗費(fèi) 9 秒，并且在 JobTracker 的 Cluster Summar 視圖中可以觀看到，正在運(yùn)行的 map task 數(shù)量在 0 到 24 之間浮動(dòng)。job 在 17 分 52 秒之后結(jié)束，比原來(lái)的執(zhí)行要慢兩倍多。

第四點(diǎn)   為 job 添加一個(gè) Combiner
診斷結(jié)果 / 癥狀：
1. job 在執(zhí)行分類的聚合時(shí)，REDUCE_INPUT_GROUPS 計(jì)數(shù)器遠(yuǎn)小于 REDUCE_INPUT_RECORDS 計(jì)數(shù)器。
2. job 執(zhí)行一個(gè)大的 shuffle 任務(wù) (例如，map 的輸出數(shù)據(jù)每個(gè)節(jié)點(diǎn)就是好幾個(gè) GB)。
3. 從 job 計(jì)數(shù)器中看出，SPILLED_RECORDS 遠(yuǎn)大于 MAP_OUTPUT_RECORDS。

  如果你的算法涉及到一些分類的聚合，那么你就可以使用 Combiner 來(lái)完成數(shù)據(jù)到達(dá) reduce 端之前的初始聚合工作。MapReduce 框架很明智地運(yùn)用 Combiner 來(lái)減少寫入磁盤以及通過(guò)網(wǎng)絡(luò)傳輸?shù)?reduce 端的數(shù)據(jù)量。

基準(zhǔn)測(cè)試：
  我刪去 Wordcount 例子中對(duì) setCombinerClass 方法的調(diào)用。僅這個(gè)修改就讓 map task 的平均運(yùn)行時(shí)間由 33 秒增長(zhǎng)到 48 秒，shuffle 的數(shù)據(jù)量也從 1GB 提高到 1.4GB。整個(gè) job 的運(yùn)行時(shí)間由原來(lái)的 8 分 30 秒變成 15 分 42 秒，差不多慢了兩倍。這次測(cè)試過(guò)程中開啟了 map 輸出結(jié)果的壓縮功能，如果沒有開啟這個(gè)壓縮功能的話，那么 Combiner 的影響就會(huì)變得更加明顯。

第五點(diǎn)   為你的數(shù)據(jù)使用最合適和簡(jiǎn)潔的 Writable 類型
診斷 / 癥狀：
1. Text 對(duì)象在非文本或混合數(shù)據(jù)中使用。
2. 大部分的輸出值很小的時(shí)候使用 IntWritable 或 LongWritable 對(duì)象。

  當(dāng)一個(gè)開發(fā)者是初次編寫 MapReduce，或是從開發(fā) Hadoop Streaming 轉(zhuǎn)到 Java MapReduce，他們會(huì)經(jīng)常在不必要的時(shí)候使用 Text 對(duì)象。盡管 Text 對(duì)象使用起來(lái)很方便，但它在由數(shù)值轉(zhuǎn)換到文本或是由 UTF8 字符串轉(zhuǎn)換到文本時(shí)都是低效的，且會(huì)消耗大量的 CPU 時(shí)間。當(dāng)處理那些非文本的數(shù)據(jù)時(shí)，可以使用二進(jìn)制的 Writable 類型，如 IntWritable，F(xiàn)loatWritable 等。

  除了避免文件轉(zhuǎn)換的消耗外，二進(jìn)制 Writable 類型作為中間結(jié)果時(shí)會(huì)占用更少的空間。當(dāng)磁盤 IO 和網(wǎng)絡(luò)傳輸成為大型 job 所遇到的瓶頸時(shí)，減少些中間結(jié)果的大小可以獲得更好的性能。在處理整形數(shù)值時(shí)，有時(shí)使用 VIntWritable 或 VLongWritable 類型可能會(huì)更快些—這些實(shí)現(xiàn)了變長(zhǎng)整形編碼的類型在序列化小數(shù)值時(shí)會(huì)更節(jié)省空間。例如，整數(shù) 4 會(huì)被序列化成單字節(jié)，而整數(shù) 10000 會(huì)被序列化成兩個(gè)字節(jié)。這些變長(zhǎng)類型用在統(tǒng)計(jì)等任務(wù)時(shí)更加有效，在這些任務(wù)中我們只要確保大部分的記錄都是一個(gè)很小的值，這樣值就可以匹配一或兩個(gè)字節(jié)。

  如果 Hadoop 自帶的 Writable 類型不能滿足你的需求，你可以開發(fā)自己的 Writable 類型。這應(yīng)該是挺簡(jiǎn)單的，可能會(huì)在處理文本方面更快些。如果你編寫了自己的 Writable 類型，請(qǐng)務(wù)必提供一個(gè) RawComparator 類—你可以以內(nèi)置的 Writable 類型做為例子。

基準(zhǔn)測(cè)試：
  對(duì)于 Wordcount 例子，我修改了它在 map 計(jì)數(shù)時(shí)的中間變量，由 IntWritable 改為 Text。并且在 reduce 統(tǒng)計(jì)最終和時(shí)使用 Integer.parseString(value.toString) 來(lái)轉(zhuǎn)換出真正的數(shù)值。這個(gè)版本比原始版本要慢近 10%—整個(gè) job 完成差不多超過(guò) 9 分鐘，且每個(gè) map task 要運(yùn)行 36 秒，比之前的 33 秒要慢。盡量看起來(lái)整形轉(zhuǎn)換還是挺快的，但這不說(shuō)明什么情況。在正常情況下，我曾經(jīng)看到過(guò)選用合適的 Writable 類型可以有 2 到 3 倍的性能提升的例子。

第六點(diǎn)   重用 Writable 類型
診斷 / 癥狀：
1. 在 mapred.child.java.opts 參數(shù)上增加 -verbose:gc -XX:+PriintGCDetails，然后查看一些 task 的日志。如果垃圾回收頻繁工作且消耗一些時(shí)間，你需要注意那些無(wú)用的對(duì)象。
2. 在你的代碼中搜索 new Text 或 new IntWritable。如果它們出現(xiàn)在一個(gè)內(nèi)部循環(huán)或是 map/reduce 方法的內(nèi)部時(shí)，這條建議可能會(huì)很有用。
3. 這條建議在 task 內(nèi)存受限的情況下特別有用。

  很多 MapReduce 用戶常犯的一個(gè)錯(cuò)誤是，在一個(gè) map/reduce 方法中為每個(gè)輸出都創(chuàng)建 Writable 對(duì)象。例如，你的 Wordcout mapper 方法可能這樣寫：

Java 代碼

public void map(…) { 

 … 

 for (String word : words) { 

 output.collect(new Text(word), new IntWritable(1)); 

 } 

} 

  這樣會(huì)導(dǎo)致程序分配出成千上萬(wàn)個(gè)短周期的對(duì)象。Java 垃圾收集器就要為此做很多的工作。更有效的寫法是：

Java 代碼

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); 

 } 

 } 

} 

基準(zhǔn)測(cè)試：
  當(dāng)我以上面的描述修改了 Wordcount 例子后，起初我發(fā)現(xiàn) job 運(yùn)行時(shí)與修改之前沒有任何不同。這是因?yàn)樵谖业?cluster 中默認(rèn)為每個(gè) task 都分配一個(gè) 1GB 的堆大小，所以垃圾回收機(jī)制沒有啟動(dòng)。當(dāng)我重新設(shè)置參數(shù)，為每個(gè) task 只分配 200MB 的堆時(shí)，沒有重用 Writable 對(duì)象的這個(gè)版本執(zhí)行出現(xiàn)了很嚴(yán)重的減緩 —job 的執(zhí)行時(shí)間由以前的大概 8 分 30 秒變成現(xiàn)在的超過(guò) 17 分鐘。原始的那個(gè)重用 Writable 的版本，在設(shè)置更小的堆時(shí)還是保持相同的執(zhí)行速度。因此重用 Writable 是一個(gè)很簡(jiǎn)單的問題修正，我推薦大家總是這樣做。它可能不會(huì)在每個(gè) job 的執(zhí)行中獲得很好的性能，但當(dāng)你的 task 有內(nèi)存限制時(shí)就會(huì)有相當(dāng)大的區(qū)別。

第七點(diǎn)   使用簡(jiǎn)易的剖析方式查看 task 的運(yùn)行
  這是我在查看 MapReduce job 性能問題時(shí)常用的一個(gè)小技巧。那些不希望這些做的人就會(huì)反對(duì)說(shuō)這樣是行不通的，但是事實(shí)是擺在面前。

  為了實(shí)現(xiàn)簡(jiǎn)易的剖析，可以當(dāng) job 中一些 task 運(yùn)行很慢時(shí)，用 ssh 工具連接上 task 所在的那臺(tái) task tracker 機(jī)器。執(zhí)行 5 到 10 次這個(gè)簡(jiǎn)單的命令 sudo killall -QUIT java(每次執(zhí)行間隔幾秒)。別擔(dān)心，不要被命令的名字嚇著，它不會(huì)導(dǎo)致任何東西退出。然后使用 JobTracker 的界面跳轉(zhuǎn)到那臺(tái)機(jī)器上某個(gè) task 的 stdout 文件上，或者查看正在運(yùn)行的機(jī)器上 /var/log/hadoop/userlogs/ 目錄中那個(gè) task 的 stdout 文件。你就可以看到當(dāng)你執(zhí)行那段命令時(shí)，命令發(fā)送到 JVM 的 SIGQUIT 信號(hào)而產(chǎn)生的棧追蹤信息的 dump 文件。([譯] 在 JobTracker 的界面上有 Cluster Summary 的表格，進(jìn)入 Nodes 鏈接，選中你執(zhí)行上面命令的 server，在界面的最下方有 Local Logs, 點(diǎn)擊 LOG 進(jìn)入，然后選擇 userlogs 目錄，這里可以看到以 server 執(zhí)行過(guò)的 jobID 命名的幾個(gè)目錄，不管進(jìn)入哪個(gè)目錄都可以看到很多 task 的列表，每個(gè) task 的 log 中有個(gè) stdout 文件，如果這個(gè)文件不為空，那么這個(gè)文件就是作者所說(shuō)的棧信息文件 )

  解析處理這個(gè)輸出文件需要一點(diǎn)點(diǎn)以經(jīng)驗(yàn)，這里我介紹下平時(shí)是怎樣處理的：
對(duì)于棧信息中的每個(gè)線程，很快地查找你的 java 包的名字 (假如是 com.mycompany.mrjobs)。如果你當(dāng)前線程的棧信息中沒有找到任何與你的代碼有關(guān)的信息，那么跳到另外的線程再看。

  如果你在某些棧信息中看到你查找的代碼，很快地查閱并大概記下它在做什么事。假如你看到一些與 NumberFormat 相關(guān)的信息，那么此時(shí)你需要記下它，暫時(shí)不需要關(guān)注它是代碼的哪些行。

  轉(zhuǎn)到日志中的下一個(gè) dump，然后也花一些時(shí)間做類似的事情然后記下些你關(guān)注的內(nèi)容。

  在查閱了 4 到 5 個(gè)棧信息后，你可能會(huì)意識(shí)到在每次查閱時(shí)都會(huì)有一些似曾相識(shí)的東西。如果這些你意識(shí)到的問題是阻礙你的程序變快的原因，那么你可能就找到了程序真正的問題。假如你取到 10 個(gè)線程的棧信息，然后從 5 個(gè)里面看到過(guò) NumberFormat 類似的信息，那么可能意味著你將 50% 的 CPU 浪費(fèi)在數(shù)據(jù)格式轉(zhuǎn)換的事情上了。

  當(dāng)然，這沒有你使用真正的分析程序那么科學(xué)。但我發(fā)現(xiàn)這是一種有效的方法，可以在不需要引入其它工具的時(shí)候發(fā)現(xiàn)那些明顯的 CPU 瓶頸。更重要的是，這是一種讓你會(huì)變的更強(qiáng)的技術(shù)，你會(huì)在實(shí)踐中知道一個(gè)正常的和有問題的 dump 是啥樣子。

  通過(guò)這項(xiàng)技術(shù)我發(fā)現(xiàn)了一些通常出現(xiàn)在性能調(diào)優(yōu)方面的誤解，列出在下面。
1. NumberFormat 相當(dāng)慢，盡量避免使用它。
2. String.split—不管是編碼或是解碼 UTF8 的字符串都是慢的超出你的想像— 參照上面提到的建議，使用合適的 Writable 類型。
3. 使用 StringBuffer.append 來(lái)連接字符串

“提高 MapReduce 性能的方法有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注丸趣 TV 網(wǎng)站，丸趣 TV 小編將為大家輸出更多高質(zhì)量的實(shí)用文章！