一说庭、什么是Hadoop然磷？

    這是一個(gè)看著不起眼，實(shí)則“送命題”的典型刊驴。往往大家關(guān)于大數(shù)據(jù)的其他內(nèi)容準(zhǔn)備得非常充分姿搜，反倒問(wèn)你什么是Hadoop卻有點(diǎn)猝不及防，回答磕磕絆絆捆憎，給面試官的印象就很不好舅柜。另外，回答這個(gè)問(wèn)題躲惰，一定要從事物本身上升到廣義去介紹致份。面試官往往通過(guò)這個(gè)問(wèn)題來(lái)判斷你是否具有最基本的認(rèn)知能力。

    Hadoop是一個(gè)能夠?qū)Υ罅繑?shù)據(jù)進(jìn)行分布式處理的軟件框架礁扮。以一種可靠知举、高效、可伸縮的方式進(jìn)行數(shù)據(jù)處理太伊。主要包括三部分內(nèi)容：*Hdfs雇锡，MapReduce，Yarn*

    Hadoop在廣義上指一個(gè)生態(tài)圈僚焦，泛指大數(shù)據(jù)技術(shù)相關(guān)的開(kāi)源組件或產(chǎn)品锰提，如HBase，Hive芳悲，Spark立肘，Zookeeper，Kafka名扛，flume…

image.png

二谅年、能跟我介紹下Hadoop和Spark的差異嗎？

    被問(wèn)到也不要驚訝肮韧，面試官往往通過(guò)你對(duì)于不同技術(shù)的差異描述融蹂，就能看出你是不是真的具有很強(qiáng)的學(xué)習(xí)能力旺订。

三放祟、Hadoop常見(jiàn)的版本有哪些鳍怨，分別有哪些特點(diǎn)，你一般是如何進(jìn)行選擇的?

    這個(gè)完全就是基于個(gè)人的經(jīng)驗(yàn)之談的跪妥，如果平時(shí)沒(méi)有細(xì)致研究過(guò)這些鞋喇，這個(gè)問(wèn)題一定是答不好的。

    由于Hadoop的飛速發(fā)展眉撵，功能不斷更新和完善侦香，Hadoop的版本非常多，同時(shí)也顯得雜亂纽疟。目前市面上罐韩，主流的是以下幾個(gè)版本：

• Apache 社區(qū)版本

  Apache 社區(qū)版本 完全開(kāi)源，免費(fèi)污朽，是非商業(yè)版本散吵。Apache社區(qū)的Hadoop版本分支較多，而且部分Hadoop存在Bug蟆肆。在選擇Hadoop矾睦、Hbase、Hive等時(shí)炎功，需要考慮兼容性枚冗。同時(shí)，這個(gè)版本的Hadoop的部署對(duì)Hadoop開(kāi)發(fā)人員或運(yùn)維人員的技術(shù)要求比較高蛇损。
  

• Cloudera版本

  Cloudera 版本 開(kāi)源赁温，免費(fèi)肛宋，有商業(yè)版和非商業(yè)版本，是在Apache社區(qū)版本的Hadoop基礎(chǔ)上束世，選擇相對(duì)穩(wěn)定版本的Hadoop酝陈，進(jìn)行開(kāi)發(fā)和維護(hù)的Hadoop版本。由于此版本的Hadoop在開(kāi)發(fā)過(guò)程中對(duì)其他的框架的集成進(jìn)行了大量的兼容性測(cè)試毁涉，因此使用者不必考慮Hadoop沉帮、Hbase、Hive等在使用過(guò)程中版本的兼容性問(wèn)題贫堰，大大節(jié)省了使用者在調(diào)試兼容性方面的時(shí)間成本穆壕。
  

• Hortonworks版本

  Hortonworks 版本 的 Hadoop 開(kāi)源、免費(fèi)其屏，有商業(yè)和非商業(yè)版本，其在 Apache 的基礎(chǔ)上修改偎行，對(duì)相關(guān)的組件或功能進(jìn)行了二次開(kāi)發(fā)川背，其中商業(yè)版本的功能是最強(qiáng)大，最齊全的蛤袒。
  
  所以基于以上特點(diǎn)進(jìn)行選擇熄云，我們一般剛接觸大數(shù)據(jù)用的就是CDH，在工作中大概率用 Apache 或者 Hortonworks妙真。
  

四缴允、能簡(jiǎn)單介紹Hadoop1.0，2.0珍德，3.0的區(qū)別嗎练般？

    一般能問(wèn)出這種問(wèn)題的面試官都是“狠人”，基本技術(shù)都不差锈候，他們往往是更希望應(yīng)聘者能在這些“細(xì)節(jié)”問(wèn)題上脫穎而出薄料。

    Hadoop1.0由分布式存儲(chǔ)系統(tǒng)HDFS和分布式計(jì)算框架MapReduce組成，其中HDFS由一個(gè)NameNode和多個(gè)DateNode組成晴及，MapReduce由一個(gè)JobTracker和多個(gè)TaskTracker組成都办。在Hadoop1.0中容易導(dǎo)致單點(diǎn)故障，拓展性差虑稼，性能低琳钉，支持編程模型單一的問(wèn)題。

    Hadoop2.0即為克服Hadoop1.0中的不足蛛倦，提出了以下關(guān)鍵特性：

• Yarn：它是Hadoop2.0引入的一個(gè)全新的通用資源管理系統(tǒng)歌懒，完全代替了Hadoop1.0中的JobTracker。在MRv1 中的 JobTracker 資源管理和作業(yè)跟蹤的功能被抽象為 ResourceManager 和 AppMaster 兩個(gè)組件溯壶。Yarn 還支持多種應(yīng)用程序和框架及皂，提供統(tǒng)一的資源調(diào)度和管理功能

• NameNode 單點(diǎn)故障得以解決：Hadoop2.2.0 同時(shí)解決了 NameNode 單點(diǎn)故障問(wèn)題和內(nèi)存受限問(wèn)題甫男，并提供 NFS，QJM 和 Zookeeper 三種可選的共享存儲(chǔ)系統(tǒng)

• HDFS 快照：指 HDFS（或子系統(tǒng)）在某一時(shí)刻的只讀鏡像验烧，該只讀鏡像對(duì)于防止數(shù)據(jù)誤刪板驳、丟失等是非常重要的。例如碍拆，管理員可定時(shí)為重要文件或目錄做快照若治，當(dāng)發(fā)生了數(shù)據(jù)誤刪或者丟失的現(xiàn)象時(shí)，管理員可以將這個(gè)數(shù)據(jù)快照作為恢復(fù)數(shù)據(jù)的依據(jù)

• 支持Windows 操作系統(tǒng)：Hadoop 2.2.0 版本的一個(gè)重大改進(jìn)就是開(kāi)始支持 Windows 操作系統(tǒng)

• Append：新版本的 Hadoop 引入了對(duì)文件的追加操作

  同時(shí)感混，新版本的Hadoop對(duì)于HDFS做了兩個(gè)非常重要的**增強(qiáng)**端幼，分別是支持異構(gòu)的存儲(chǔ)層次和通過(guò)數(shù)據(jù)節(jié)點(diǎn)為存儲(chǔ)在HDFS中的數(shù)據(jù)提供內(nèi)存緩沖功能
  
  相比于Hadoop2.0，Hadoop3.0 是直接基于 JDK1.8 發(fā)布的一個(gè)新版本弧满，同時(shí)婆跑，Hadoop3.0引入了一些重要的功能和特性
  

• HDFS可擦除編碼：這項(xiàng)技術(shù)使HDFS在不降低可靠性的前提下節(jié)省了很大一部分存儲(chǔ)空間

• 多NameNode支持：在Hadoop3.0中，新增了對(duì)多NameNode的支持庭呜。當(dāng)然滑进，處于Active狀態(tài)的NameNode實(shí)例必須只有一個(gè)。也就是說(shuō)疟赊，從Hadoop3.0開(kāi)始郊供，在同一個(gè)集群中峡碉，支持一個(gè) ActiveNameNode 和 多個(gè) StandbyNameNode 的部署方式近哟。

• MR Native Task優(yōu)化

• Yarn基于cgroup 的內(nèi)存和磁盤 I/O 隔離

• Yarn container resizing

  限于篇幅原因，這還都只是部分特性鲫寄，大家多注意菌哥標(biāo)記顏色的部分吉执，就足以應(yīng)對(duì)面試了。
  

五地来、說(shuō)下Hadoop常用的端口號(hào)

    Hadoop常用的端口號(hào)總共就那么幾個(gè)戳玫，大家選擇好記的幾個(gè)就OK了

• dfs.namenode.http-address:50070
• dfs.datanode.http-address:50075
• SecondaryNameNode：50090
• dfs.datanode.address:50010
• fs.defaultFS:8020 或者9000
• yarn.resourcemanager.webapp.address:8088
• 歷史服務(wù)器web訪問(wèn)端口：19888

六、簡(jiǎn)單介紹一下搭建Hadoop集群的流程

    這個(gè)問(wèn)題實(shí)在基礎(chǔ)未斑，這里也簡(jiǎn)單概述下咕宿。

    在正式搭建之前，我們需要準(zhǔn)備以下6步：

準(zhǔn)備工作

1. 關(guān)閉防火墻
2. 關(guān)閉SELINUX
3. 修改主機(jī)名
4. ssh無(wú)密碼拷貝數(shù)據(jù)
5. 設(shè)置主機(jī)名和IP對(duì)應(yīng)
6. jdk1.8安裝

搭建工作:

• 下載并解壓Hadoop的jar包
• 配置hadoop的核心文件
• 格式化namenode
• 啟動(dòng)…

七蜡秽、介紹一下HDFS讀寫流程

    這個(gè)問(wèn)題非掣В基礎(chǔ)，同時(shí)出現(xiàn)的頻率也是異常的高芽突，但是大家也不要被HDFS的讀寫流程嚇到试浙。相信看到這里的朋友，應(yīng)該不是第一次背HDFS讀寫繁多的步驟了寞蚌，菌哥在這里也不建議大家去背那些文字田巴，這里貼上兩張圖钠糊，大家要學(xué)會(huì)做到心中有圖，萬(wàn)般皆易壹哺。

• HDFS讀數(shù)據(jù)流程

在這里插入圖片描述

• HDFS的寫數(shù)據(jù)流程

  
  
  在這里插入圖片描述

八抄伍、介紹一下MapReduce的Shuffle過(guò)程，并給出Hadoop優(yōu)化的方案(包括：壓縮管宵、小文件逝慧、集群的優(yōu)化)

    MapReduce數(shù)據(jù)讀取并寫入HDFS流程實(shí)際上是有10步

在這里插入圖片描述

    其中最重要，也是最不好講的就是 shuffle 階段啄糙，當(dāng)面試官著重要求你介紹 Shuffle 階段時(shí)笛臣，可就不能像上邊圖上寫的那樣簡(jiǎn)單去介紹了。

    你可以這么說(shuō)：

    1) Map方法之后Reduce方法之前這段處理過(guò)程叫**Shuffle**

    2) Map方法之后隧饼，數(shù)據(jù)首先進(jìn)入到分區(qū)方法沈堡，把數(shù)據(jù)標(biāo)記好分區(qū)，然后把數(shù)據(jù)發(fā)送到環(huán)形緩沖區(qū)燕雁；環(huán)形緩沖區(qū)默認(rèn)大小100m诞丽，環(huán)形緩沖區(qū)達(dá)到80%時(shí)，進(jìn)行溢寫拐格；溢寫前對(duì)數(shù)據(jù)進(jìn)行排序僧免，排序按照對(duì)key的索引進(jìn)行字典順序排序，排序的手段**快排**捏浊；溢寫產(chǎn)生大量溢寫文件懂衩，需要對(duì)溢寫文件進(jìn)行**歸并排序**；對(duì)溢寫的文件也可以進(jìn)行Combiner操作金踪，前提是匯總操作浊洞，求平均值不行。最后將文件按照分區(qū)存儲(chǔ)到磁盤胡岔，等待Reduce端拉取法希。

    3）每個(gè)Reduce拉取Map端對(duì)應(yīng)分區(qū)的數(shù)據(jù)。拉取數(shù)據(jù)后先存儲(chǔ)到內(nèi)存中靶瘸，內(nèi)存不夠了苫亦，再存儲(chǔ)到磁盤。拉取完所有數(shù)據(jù)后，采用歸并排序?qū)?nèi)存和磁盤中的數(shù)據(jù)都進(jìn)行排序。在進(jìn)入Reduce方法前纠俭，可以對(duì)數(shù)據(jù)進(jìn)行分組操作。

講到這里你可能已經(jīng)口干舌燥饼丘，想緩一緩。
但面試官可能對(duì)你非常欣賞：
小伙幾辽话，看來(lái)你對(duì)MapReduce的Shuffle階段掌握很透徹啊肄鸽，那你跟我再介紹一下你是如何基于MapReduce做Hadoop的優(yōu)化的卫病，可以給你個(gè)提示，可以從壓縮典徘，小文件蟀苛，集群優(yōu)化層面去考慮哦~

image.png

可能你心里仿佛有一萬(wàn)只草泥馬在奔騰，但是為了順利拿下本輪面試逮诲，你還是不得不開(kāi)始思考帜平，如何回答比較好：

1）HDFS小文件影響

• 影響NameNode的壽命，因?yàn)槲募獢?shù)據(jù)存儲(chǔ)在NameNode的內(nèi)存中
• 影響計(jì)算引擎的任務(wù)數(shù)量梅鹦，比如每個(gè)小的文件都會(huì)生成一個(gè)Map任務(wù)

2）數(shù)據(jù)輸入小文件處理

• 合并小文件：對(duì)小文件進(jìn)行歸檔（Har）裆甩、自定義Inputformat將小文件存儲(chǔ)成SequenceFile文件。
• 采用ConbinFileInputFormat來(lái)作為輸入齐唆，解決輸入端大量小文件場(chǎng)景
• 對(duì)于大量小文件Job嗤栓，可以開(kāi)啟JVM重用

3）Map階段

• 增大環(huán)形緩沖區(qū)大小。由100m擴(kuò)大到200m
• 增大環(huán)形緩沖區(qū)溢寫的比例箍邮。由80%擴(kuò)大到90%
• 減少對(duì)溢寫文件的merge次數(shù)茉帅。（10個(gè)文件，一次20個(gè)merge）
• 不影響實(shí)際業(yè)務(wù)的前提下锭弊，采用Combiner提前合并堪澎，減少 I/O

4）Reduce階段

• 合理設(shè)置Map和Reduce數(shù)：兩個(gè)都不能設(shè)置太少，也不能設(shè)置太多味滞。太少樱蛤，會(huì)導(dǎo)致Task等待，延長(zhǎng)處理時(shí)間桃犬；太多刹悴，會(huì)導(dǎo)致 Map、Reduce任務(wù)間競(jìng)爭(zhēng)資源攒暇，造成處理超時(shí)等錯(cuò)誤。
• 設(shè)置Map子房、Reduce共存：調(diào)整 slowstart.completedmaps 參數(shù)形用，使Map運(yùn)行到一定程度后，Reduce也開(kāi)始運(yùn)行证杭，減少Reduce的等待時(shí)間
• 規(guī)避使用Reduce田度，因?yàn)镽educe在用于連接數(shù)據(jù)集的時(shí)候?qū)?huì)產(chǎn)生大量的網(wǎng)絡(luò)消耗。
• 增加每個(gè)Reduce去Map中拿數(shù)據(jù)的并行數(shù)
• 集群性能可以的前提下解愤，增大Reduce端存儲(chǔ)數(shù)據(jù)內(nèi)存的大小

5) IO 傳輸

• 采用數(shù)據(jù)壓縮的方式镇饺，減少網(wǎng)絡(luò)IO的的時(shí)間
• 使用SequenceFile二進(jìn)制文件

6) 整體

• MapTask默認(rèn)內(nèi)存大小為1G，可以增加MapTask內(nèi)存大小為4
• ReduceTask默認(rèn)內(nèi)存大小為1G送讲，可以增加ReduceTask內(nèi)存大小為4-5g
• 可以增加MapTask的cpu核數(shù)奸笤，增加ReduceTask的CPU核數(shù)
• 增加每個(gè)Container的CPU核數(shù)和內(nèi)存大小
• 調(diào)整每個(gè)Map Task和Reduce Task最大重試次數(shù)

7) 壓縮

    壓縮惋啃，可以參考這張圖

[圖片上傳失敗...(image-91591f-1604558885350)]

    **提示**：如果面試過(guò)程問(wèn)起，我們一般回答壓縮方式為Snappy监右，特點(diǎn)速度快边灭，缺點(diǎn)無(wú)法切分（可以回答在鏈?zhǔn)組R中，Reduce端輸出使用bzip2壓縮健盒，以便后續(xù)的map任務(wù)對(duì)數(shù)據(jù)進(jìn)行split）

九绒瘦、介紹一下 Yarn 的 Job 提交流程

    這里一共也有兩個(gè)版本，分別是詳細(xì)版和簡(jiǎn)略版扣癣，具體使用哪個(gè)還是分不同的場(chǎng)合惰帽。正常情況下，將簡(jiǎn)略版的回答清楚了就很OK父虑，詳細(xì)版的最多做個(gè)內(nèi)容的補(bǔ)充：

• 詳細(xì)版

  
  
  在這里插入圖片描述

• 簡(jiǎn)略版

[圖片上傳失敗...(image-9b8096-1604558885350)]

    其中簡(jiǎn)略版對(duì)應(yīng)的步驟分別如下：

1. client向RM提交應(yīng)用程序善茎，其中包括啟動(dòng)該應(yīng)用的ApplicationMaster的必須信息，例如ApplicationMaster程序频轿、啟動(dòng)ApplicationMaster的命令垂涯、用戶程序等
2. ResourceManager啟動(dòng)一個(gè)container用于運(yùn)行ApplicationMaster
3. 啟動(dòng)中的ApplicationMaster向ResourceManager注冊(cè)自己，啟動(dòng)成功后與RM保持心跳
4. ApplicationMaster向ResourceManager發(fā)送請(qǐng)求,申請(qǐng)相應(yīng)數(shù)目的container
5. 申請(qǐng)成功的container航邢，由ApplicationMaster進(jìn)行初始化耕赘。container的啟動(dòng)信息初始化后，AM與對(duì)應(yīng)的NodeManager通信膳殷，要求NM啟動(dòng)container
6. NM啟動(dòng)container
7. container運(yùn)行期間操骡，ApplicationMaster對(duì)container進(jìn)行監(jiān)控。container通過(guò)RPC協(xié)議向?qū)?yīng)的AM匯報(bào)自己的進(jìn)度和狀態(tài)等信息
8. 應(yīng)用運(yùn)行結(jié)束后赚窃，ApplicationMaster向ResourceManager注銷自己册招，并允許屬于它的container被收回

十、介紹下Yarn默認(rèn)的調(diào)度器勒极，調(diào)度器分類是掰，以及它們之間的區(qū)別

    關(guān)于Yarn的知識(shí)點(diǎn)考察實(shí)際上在面試中占的比重并的不多，像面試中常問(wèn)的無(wú)非就Yarn的Job執(zhí)行流程或者調(diào)度器的分類辱匿，答案往往也都差不多键痛，以下回答做個(gè)參考：

    1）Hadoop調(diào)度器主要分為三類：

• FIFO Scheduler：先進(jìn)先出調(diào)度器：優(yōu)先提交的，優(yōu)先執(zhí)行匾七，后面提交的等待【生產(chǎn)環(huán)境不會(huì)使用】
• Capacity Scheduler：容量調(diào)度器：允許看創(chuàng)建多個(gè)任務(wù)對(duì)列絮短，多個(gè)任務(wù)對(duì)列可以同時(shí)執(zhí)行。但是一個(gè)隊(duì)列內(nèi)部還是先進(jìn)先出昨忆《∑担【Hadoop2.7.2默認(rèn)的調(diào)度器】
• Fair Scheduler：公平調(diào)度器：第一個(gè)程序在啟動(dòng)時(shí)可以占用其他隊(duì)列的資源（100%占用），當(dāng)其他隊(duì)列有任務(wù)提交時(shí)，占用資源的隊(duì)列需要將資源還給該任務(wù)席里。還資源的時(shí)候叔磷，效率比較慢⌒采祝【CDH版本的yarn調(diào)度器默認(rèn)】

十一世澜、了解過(guò)哪些Hadoop的參數(shù)優(yōu)化

    前面剛回答完Hadoop基于壓縮，小文件署穗，IO的集群優(yōu)化寥裂，現(xiàn)在又要回答參數(shù)優(yōu)化，真的好煩啊(Ｔ▽Ｔ)如果你把自己放在實(shí)習(xí)生這個(gè)level案疲，你 duck 不必研究這么多關(guān)于性能調(diào)優(yōu)這塊的內(nèi)容封恰，畢竟對(duì)于稍有工作經(jīng)驗(yàn)的工程師來(lái)說(shuō)，調(diào)優(yōu)這塊是非常重要的

    我們常見(jiàn)的**Hadoop參數(shù)調(diào)優(yōu)**有以下幾種：

• 在hdfs-site.xml文件中配置多目錄褐啡，最好提前配置好诺舔，否則更改目錄需要重新啟動(dòng)集群
• NameNode有一個(gè)工作線程池，用來(lái)處理不同DataNode的并發(fā)心跳以及客戶端并發(fā)的元數(shù)據(jù)操作

dfs.namenode.handler.count=20 * log2(Cluster Size)

    比如集群規(guī)模為10臺(tái)時(shí)备畦，此參數(shù)設(shè)置為60

• 編輯日志存儲(chǔ)路徑dfs.namenode.edits.dir設(shè)置與鏡像文件存儲(chǔ)路徑dfs.namenode.name.dir盡量分開(kāi)低飒，達(dá)到最低寫入延遲
• 服務(wù)器節(jié)點(diǎn)上YARN可使用的物理內(nèi)存總量，默認(rèn)是8192（MB）懂盐，注意褥赊，如果你的節(jié)點(diǎn)內(nèi)存資源不夠8GB，則需要調(diào)減小這個(gè)值莉恼，而YARN不會(huì)智能的探測(cè)節(jié)點(diǎn)的物理內(nèi)存總量
• 單個(gè)任務(wù)可申請(qǐng)的最多物理內(nèi)存量拌喉，默認(rèn)是8192（MB）

十二、了解過(guò)Hadoop的基準(zhǔn)測(cè)試嗎?

    這個(gè)完全就是基于項(xiàng)目經(jīng)驗(yàn)的面試題了俐银，暫時(shí)回答不上來(lái)的朋友可以留意一下：

    我們搭建完Hadoop集群后需要對(duì)HDFS讀寫性能和MR計(jì)算能力測(cè)試尿背。測(cè)試jar包在hadoop的share文件夾下。

十三捶惜、你是怎么處理Hadoop宕機(jī)的問(wèn)題的?

    相信被問(wèn)到這里田藐，一部分的小伙伴已經(jīng)堅(jiān)持不下去了

[圖片上傳失敗...(image-c6c351-1604558885350)]

    但言歸正傳，被問(wèn)到了售躁，我們總不能說(shuō)俺不知道坞淮，灑家不會(huì)之類的吧?(?????)?下面展示一種回答，給大家來(lái)個(gè)Demo陪捷。

    如果MR造成系統(tǒng)宕機(jī)。此時(shí)要控制Yarn同時(shí)運(yùn)行的任務(wù)數(shù)诺擅，和每個(gè)任務(wù)申請(qǐng)的最大內(nèi)存市袖。調(diào)整參數(shù)：yarn.scheduler.maximum-allocation-mb（單個(gè)任務(wù)可申請(qǐng)的最多物理內(nèi)存量，默認(rèn)是8192MB）。

    如果寫入文件過(guò)量造成NameNode宕機(jī)苍碟。那么調(diào)高Kafka的存儲(chǔ)大小酒觅，控制從Kafka到HDFS的寫入速度。高峰期的時(shí)候用Kafka進(jìn)行緩存微峰，高峰期過(guò)去數(shù)據(jù)同步會(huì)自動(dòng)跟上舷丹。

十四、你是如何解決Hadoop數(shù)據(jù)傾斜的問(wèn)題的蜓肆，能舉個(gè)例子嗎?

    **性能優(yōu)化**和**數(shù)據(jù)傾斜**颜凯，如果在面試前不好好準(zhǔn)備，那就準(zhǔn)備在面試時(shí)吃虧吧~其實(shí)掌握得多了仗扬，很多方法都有相通的地方症概。下面貼出一種靠譜的回答，大家可以借鑒下：

    1）提前在map進(jìn)行combine早芭，減少傳輸?shù)臄?shù)據(jù)量

    在Mapper加上combiner相當(dāng)于提前進(jìn)行reduce彼城，即把一個(gè)Mapper中的相同key進(jìn)行了聚合，減少shuffle過(guò)程中傳輸?shù)臄?shù)據(jù)量退个，以及Reducer端的計(jì)算量募壕。

    如果導(dǎo)致數(shù)據(jù)傾斜的key 大量分布在不同的mapper的時(shí)候，這種方法就不是很有效了

    2）數(shù)據(jù)傾斜的key 大量分布在不同的mapper

    在這種情況语盈，大致有如下幾種方法：

• 局部聚合加全局聚合

  第一次在map階段對(duì)那些導(dǎo)致了數(shù)據(jù)傾斜的key 加上1到n的隨機(jī)前綴舱馅，這樣本來(lái)相同的key 也會(huì)被分到多個(gè)Reducer 中進(jìn)行局部聚合，數(shù)量就會(huì)大大降低黎烈。
  
  第二次mapreduce习柠，去掉key的隨機(jī)前綴，進(jìn)行全局聚合照棋。
  
  **思想**：二次mr资溃，第一次將key隨機(jī)散列到不同 reducer 進(jìn)行處理達(dá)到負(fù)載均衡目的。第二次再根據(jù)去掉key的隨機(jī)前綴烈炭，按原key進(jìn)行reduce處理溶锭。
  
  這個(gè)方法進(jìn)行兩次mapreduce，性能稍差符隙。
  

• 增加Reducer趴捅，提升并行度

JobConf.setNumReduceTasks(int)

• 實(shí)現(xiàn)自定義分區(qū)

  根據(jù)數(shù)據(jù)分布情況，自定義散列函數(shù)霹疫，將key均勻分配到不同Reducer