叢集優化

一個小叢集:1個master,10個datanode。 
最開始使用pig指令碼分析作業，後面作業執行時觀察發現，pig指令碼執行的小作業太多導致任務排程頻繁，叢集效率低。 
小作業太多的影響:

1. 頻繁新建和關閉task，頻繁分配container會消耗資源。
2. 一個oozie action先會啟動一個oozie laucher作業消耗一個container，然後再啟動實際的job，啟動的job首先會用個container啟動application master，然後在啟動計算的task 現在同時最多會有29個job，至少會有50個container不是在計算。

1 程式碼優化

1. 增加5分鐘基礎作業時間粒度，5分鐘->15分鐘，減少Job數
2. 合併15分鐘粒度作業，Pig->MR，grouping comparator，減少基礎資料重複讀取次數，減少Job數
3. 合併5分鐘基礎作業，一個作業處理三種話單，去除冗餘欄位（各粒度時間），減少Job數，減少資料量

2 叢集引數配置

2.1 HDFS

• HDFS塊大小:從預設的128MB調整為256MB，更大的塊大小(block)意味著更少的job，由於當前作業計算並不複雜，可以使用更大塊。
• 複製因子:預設是3，現在修改為2。減少資料儲存量，可以減小話單上傳的時間消耗
• DataNode處理程式計數:引數是dfs.datanode.handler.count 預設值是3，調整為30。datanode上用於處理RPC的執行緒數。預設為3，較大叢集，可適當調大些，比如8。需要注意的是，每新增一個執行緒，需要的記憶體增加。
• NameNode處理程式計數:引數是dfs.namenode.handler.count 預設是30，建議值是47，現在調整為60.namenode或者jobtracker中用於處理RPC的執行緒數，預設是10，較大叢集，可調大些，比如64。 NameNode服務處理程式計數:引數是 dfs.namenode.service.handler.count，預設值是30，建議值是47，現在調整為60。NameNode 用於服務呼叫的伺服器執行緒數量。
• 最大傳輸執行緒數:引數是一起配置的為:dfs.datanode.max.xcievers, dfs.datanode.max.transfer.threads對於datanode來說，就如同linux上的檔案控制代碼的限制，當datanode 上面的連線數操作配置中的設定時，datanode就會拒絕連線。 一般都會將此引數調的很大，40000+左右。

2.2 YARN

• 每個作業的 Reduce 任務的預設數量:引數為mapreduce.job.reduces預設值為1，現在調整為30。通過觀察當前執行的job例項，觀察其reduce執行時間，發現時間消耗不足1秒，故不必啟用過多reduce。
• 啟用 Ubertask 優化:Uber模式是Hadoop2.0針對MR小作業的優化機制。通過mapreduce.job.ubertask.enable來設定是否開啟小作業優化，預設為false。 如果用Job足夠小，則序列在的一個JVM完成該JOB，即MRAppMaster程序中，這樣比為每一個任務分配Container效能更好。關於Ubertask的詳細可以參考Ubertask模式。
• Map任務記憶體：引數為mapreduce.map.memory.mb，保持預設值1GB。
• Reduce任務記憶體:引數為mapreduce.reduce.memory.mb，保持預設值1GB。
• Map任務CPU虛擬核心：引數為mapreduce.map.cpu.vcores，為作業的每個 Map 任務分配的虛擬 CPU 核心數。預設每個map一個CPU，使用者提交應用程式時，可以指定每個任務需要的虛擬CPU個數。在MRAppMaster中，每個Map Task和Reduce Task預設情況下需要的虛擬CPU個數為1。
• Reduce任務CPU虛擬核心:引數為mapreduce.reduce.cpu.vcores，說明 與Map任務CPU虛擬核心一致。
• Map 任務最大堆疊:引數是mapreduce.map.java.opts.max.heap，Map 程序的最大 Java 堆疊（位元組）。該引數與mapreduce.reduce.java.opts.max.heap一樣，都是ClouderManager獨有的，標準的hadoop引數是mapreduce.map.java.opts和mapreduce.reduce.java.opts
• Reduce 任務最大堆疊: 同Map 任務最大堆疊。
• 容器記憶體:引數是yarn.nodemanager.resource.memory-mb。表示該節點上YARN可使用的實體記憶體總量，預設是8192（MB），注意，如果你的節點記憶體資源不夠8GB，則需要調減小這個值，而YARN不會智慧的探測節點的實體記憶體總量。當前配置為24GB。
• 容器虛擬 CPU 核心:引數是yarn.nodemanager.resource.cpu-vcores可以為容器分配的虛擬CPU核心的數量。叢集中每臺伺服器只有24個虛核，所以容器記憶體配24G記憶體就行，現在作業都小map、reduce都用不了太多記憶體，預設是1GB。多了也沒用，因為每個container至少要1個核。

2.3 Oozie

Oozie Server 的 Java 堆疊大小 預設值為1GB，現在修改為4GB。

2.4 HBase

• HBaseMaster的Java堆疊大小:暫無調整。

• HBase Region Server處理程式計數:引數為hbase.regionserver.handler.count,預設值為30，調節至150.是RegionServer的請求處理IO執行緒數。較少的IO執行緒，適用於處理單次請求記憶體消耗較高的Big PUT場景（大容量單次PUT或設定了較大cache的scan，均屬於Big PUT）或ReigonServer的記憶體比較緊張的場景。 較多的IO執行緒，適用於單次請求記憶體消耗低，TPS要求非常高的場景。設定該值的時候，以監控記憶體為主要參考。 這裡需要注意的是如果server的region數量很少，大量的請求都落在一個region上，因快速充滿memstore觸發flush導致的讀寫鎖會影響全域性TPS，不是IO執行緒數越高越好。 壓測時，開啟Enabling RPC-level logging，可以同時監控每次請求的記憶體消耗和GC的狀況，最後通過多次壓測結果來合理調節IO執行緒數。

• HBase RegionServer的Java堆疊大小(位元組）:HBase regionserver堆疊能多大就多大，計算方式是RegionServer java堆大小= 伺服器總記憶體-已分配記憶體 （注意：此配置為優化索引入庫）

2.5 伺服器引數

• 伺服器時鐘同步
• 修改swappiness值 在所有伺服器上，使用root使用者執行
  1. # sysctl vm.swappiness=0
  2. # echo 'vm.swappiness=0'>> /etc/sysctl.conf
  3. # sysctl -p
• 禁用透明巨頁
  1. # echo never >/sys/kernel/mm/redhat_transparent_hugepage/enabled