Hive 數據傾斜 和經常使用優化策略

Hive的數據傾斜
數據分佈不均勻，形成數據熱點，引發性能問題。Jobs 數比較多的做業運行效率相對比較低。主要表現爲，任務進度長時間維持在 99%或者 100%的附近，查看任務監控頁面，發現只有少許 reduce 子任務未完成，由於其處理的數據量和其餘的 reduce 差別過大。 單一 reduce 處理的記錄數和平均記錄數相差太大，一般達到好幾倍之多，最長時間遠大 於平均時長。
容易形成傾斜狀況，及應對方法
空值產生的數據傾斜，把空值的 key 變成一個字符串加上一個隨機數
不一樣數據類型關聯產生數據傾斜，統一關聯字段數據類型
大小表關聯查詢產生數據傾斜 使用map join，新版本能夠配置參數設置mapjoin，老版本須要經過提示
map join 概念：將其中作鏈接的小表（全量數據）分發到全部 MapTask 端進行 Join，從 而避免了 reduceTask，前提要求是內存足以裝下該全量數據，Map 端完成 Join 操做。
count(distinct col)和group by容易產生數據傾斜

Hive優化策略
優化經常使用手段
一、好的模型設計事半功倍
二、解決數據傾斜問題
三、減小 job 數
四、設置合理的 MapReduce 的 task 數，能有效提高性能。(好比，10w+級別的計算，用 160個 reduce，那是至關的浪費，1 個足夠)
五、瞭解數據分佈，本身動手解決數據傾斜問題是個不錯的選擇。這是通用的算法優化，但 算法優化有時不能適應特定業務背景，開發人員瞭解業務，瞭解數據，能夠經過業務邏輯精 確有效的解決數據傾斜問題
六、數據量較大的狀況下，慎用 count(distinct)，group by 容易產生傾斜問題
七、對小文件進行合併，是行之有效的提升調度效率的方法，假如全部的做業設置合理的文 件數，對雲梯的總體調度效率也會產生積極的正向影響
八、優化時把握總體，單個做業最優不如總體最優
排序選擇
cluster by：對同一字段分桶並排序，不能和 sort by 連用
distribute by + sort by：分桶，保證同一字段值只存在一個結果文件當中，結合 sort by 保證 每一個 reduceTask 結果有序
sort by：單機排序，單個 reduce 結果有序
order by：全局排序，缺陷是隻能使用一個 reduce

笛卡爾積
當 Hive 設定爲嚴格模式（hive.mapred.mode=strict）時，不容許在 HQL 語句中出現笛卡爾積， 這實際說明了 Hive 對笛卡爾積支持較弱。由於找不到 Join key，Hive 只能使用 1 個 reducer 來完成笛卡爾積。
固然也可使用 limit 的辦法來減小某個表參與 join 的數據量，但對於須要笛卡爾積語義的 需求來講，常常是一個大表和一個小表的 Join 操做，結果仍然很大（以致於沒法用單機處 理），這時 MapJoin纔是最好的解決辦法。MapJoin，顧名思義，會在 Map 端完成 Join 操做。 這須要將 Join 操做的一個或多個表徹底讀入內存。
PS：MapJoin 在子查詢中可能出現未知 BUG。在大表和小表作笛卡爾積時，規避笛卡爾積的 方法是，給 Join 添加一個 Join key，原理很簡單：將小表擴充一列 join key，並將小表的條 目複製數倍，join key 各不相同；將大表擴充一列 join key 爲隨機數。
精髓就在於複製幾倍，最後就有幾個 reduce 來作，並且大表的數據是前面小表擴張 key 值 範圍裏面隨機出來的，因此複製了幾倍 n，就至關於這個隨機範圍就有多大 n，那麼相應的， 大表的數據就被隨機的分爲了 n 份。而且最後處理所用的 reduce 數量也是 n，並且也不會 出現數據傾斜。

in/exists 語句
推薦使用 hive 的一個高效替代方案：left semi join

設置合理的 maptask 數量
Map 數過大
　　Map 階段輸出文件過小，產生大量小文件
　　初始化和建立 Map 的開銷很大
Map 數過小
　　文件處理或查詢併發度小，Job 執行時間過長
　　大量做業時，容易堵塞集羣 

參考資料：
https://www.cnblogs.com/qingyunzong/p/8847775.html