MapReduce 跑的慢的原因
MapReduce優(yōu)化方法
MapReduce優(yōu)化方法主要從六個方面考慮：數據輸入、Map階段、Reduce階段、IO傳輸、數據傾斜問題和常用的調優(yōu)參數。
1.數據輸入
2.Map階段
3.Reduce階段
4.I/O傳輸
5.數據傾斜問題
常用的調優(yōu)參數
1．資源相關參數
（1）以下參數是在用戶自己的MR應用程序中配置就可以生效（mapred-default.xml）
（2）應該在YARN啟動之前就配置在服務器的配置文件中才能生效（yarn-default.xml）
（3）Shuffle性能優(yōu)化的關鍵參數，應在YARN啟動之前就配置好（mapred-default.xml）
2．容錯相關參數(MapReduce性能優(yōu)化)
項目經驗之Hadoop參數調優(yōu)
1）HDFS參數調優(yōu)hdfs-site.xml
dfs.namenode.handler.count=20×〖log〗_e^(Cluster Size)，比如集群規(guī)模為8臺時，此參數設置為41
The number of Namenode RPC server threads that listen to requests from clients. If dfs.namenode.servicerpc-address is not configured then Namenode RPC server threads listen to requests from all nodes.
NameNode有一個工作線程池，用來處理不同DataNode的并發(fā)心跳以及客戶端并發(fā)的元數據操作。
對于大集群或者有大量客戶端的集群來說，通常需要增大參數dfs.namenode.handler.count的默認值10。
<property>
<name>dfs.namenode.handler.count</name>
<value>10</value>
</property>
2)YARN參數調優(yōu)yarn-site.xml
（1）情景描述：總共7臺機器，每天幾億條數據，
數據源->Flume->Kafka->HDFS->Hive面臨問題：數據統(tǒng)計主要用HiveSQL，
沒有數據傾斜，小文件已經做了合并處理，開啟的JVM重用，而且IO沒有阻塞，內存用了不到50%。
但是還是跑的非常慢，而且數據量洪峰過來時，整個集群都會宕掉。基于這種情況有沒有優(yōu)化方案。
（2）解決辦法：
內存利用率不夠。這個一般是Yarn的2個配置造成的，單個任務可以申請的最大內存大小，和Hadoop單個節(jié)點可用內存大小。
調節(jié)這兩個參數能提高系統(tǒng)內存的利用率。
（a）yarn.nodemanager.resource.memory-mb
表示該節(jié)點上YARN可使用的物理內存總量，默認是8192（MB），注意，如果你的節(jié)點內存資源不夠8GB，
則需要調減小這個值，而YARN不會智能的探測節(jié)點的物理內存總量。
（b）yarn.scheduler.maximum-allocation-mb
單個任務可申請的最多物理內存量，默認是8192（MB）。
3)集群資源分配參數（項目中遇到的問題）
集群有30臺機器，跑mr任務的時候發(fā)現(xiàn)5個map任務全都分配到了同一臺機器上，這個可能是由于什么原因導致的嗎？
解決方案：yarn.scheduler.fair.assignmultiple 這個參數 默認是開的，需要關掉
https://blog.csdn.net/leone911/article/details/51605172
- Hadoop宕機
1）如果MR造成系統(tǒng)宕機。此時要控制Yarn同時運行的任務數，和每個任務申請的最大內存。調整參數：yarn.scheduler.maximum-allocation-mb（單個任務可申請的最多物理內存量，默認是8192MB）
2）如果寫入文件過快造成NameNode宕機。那么調高Kafka的存儲大小，控制從Kafka到HDFS的寫入速度。例如，可以調整Flume每批次拉取數據量的大小參數batchsize。。
項目優(yōu)化參考:
優(yōu)化
1）Map階段
（1）增大環(huán)形緩沖區(qū)大小。由100m擴大到200m
（2）增大環(huán)形緩沖區(qū)溢寫的比例。由80%擴大到90%
（3）減少對溢寫文件的merge次數。（10個文件，一次20個merge）
（4）不影響實際業(yè)務的前提下，采用Combiner提前合并，減少 I/O。
2）Reduce階段
（1）合理設置Map和Reduce數：兩個都不能設置太少，也不能設置太多。太少，會導致Task等待，延長處理時間；太多，會導致 Map、Reduce任務間競爭資源，造成處理超時等錯誤。
（2）設置Map、Reduce共存：調整slowstart.completedmaps參數，使Map運行到一定程度后，Reduce也開始運行，減少Reduce的等待時間。
（3）規(guī)避使用Reduce，因為Reduce在用于連接數據集的時候將會產生大量的網絡消耗。
（4）增加每個Reduce去Map中拿數據的并行數
（5）集群性能可以的前提下，增大Reduce端存儲數據內存的大小。
3）IO傳輸
采用數據壓縮的方式，減少網絡IO的的時間。安裝Snappy和LZOP壓縮編碼器。
壓縮：
（1）map輸入端主要考慮數據量大小和切片，支持切片的有Bzip2、LZO。注意：LZO要想支持切片必須創(chuàng)建索引；
（2）map輸出端主要考慮速度，速度快的snappy、LZO；
（3）reduce輸出端主要看具體需求，例如作為下一個mr輸入需要考慮切片，永久保存考慮壓縮率比較大的gzip。
4）整體
（1）NodeManager默認內存8G，需要根據服務器實際配置靈活調整，例如128G內存，配置為100G內存左右，yarn.nodemanager.resource.memory-mb。
（2）單任務默認內存8G，需要根據該任務的數據量靈活調整，例如128m數據，配置1G內存，yarn.scheduler.maximum-allocation-mb。
（3）mapreduce.map.memory.mb ：控制分配給MapTask內存上限，如果超過會kill掉進程（報：Container is running beyond physical memory limits. Current usage:565MB of512MB physical memory used；Killing Container）。默認內存大小為1G，如果數據量是128m，正常不需要調整內存；如果數據量大于128m，可以增加MapTask內存，最大可以增加到4-5g。
（4）mapreduce.reduce.memory.mb：控制分配給ReduceTask內存上限。默認內存大小為1G，如果數據量是128m，正常不需要調整內存；如果數據量大于128m，可以增加ReduceTask內存大小為4-5g。
（5）mapreduce.map.java.opts：控制MapTask堆內存大小。（如果內存不夠，報：java.lang.OutOfMemoryError）
（6）mapreduce.reduce.java.opts：控制ReduceTask堆內存大小。（如果內存不夠，報：java.lang.OutOfMemoryError）
（7）可以增加MapTask的CPU核數，增加ReduceTask的CPU核數
（8）增加每個Container的CPU核數和內存大小
（9）在hdfs-site.xml文件中配置多目錄（多磁盤）
（10）NameNode有一個工作線程池，用來處理不同DataNode的并發(fā)心跳以及客戶端并發(fā)的元數據操作。dfs.namenode.handler.count=20 * log2 (Cluster Size)，比如集群規(guī)模為10臺時，此參數設置為60。
