傾斜的原因：
使map的輸出資料更均勻的分布到reduce中去，是我們的最終目標。由於hash演算法的侷限性，按key hash會或多或少的造成資料傾斜。大量經驗表明資料傾斜的原因是人為的建表疏忽或業務邏輯可以規避的。
解決思路:
hive的執行是分階段的，map處理資料量的差異取決於上乙個stage的reduce輸出，所以如何將資料均勻的分配到各個reduce中，就是解決資料傾斜的根本所在
具體辦法：
記憶體優化和i/o優化:
驅動表：使用大表做驅動表，以防止記憶體溢位；join最右邊的表是驅動表；mapjoin無視join順序，用大表做驅動表；streamtable。
1. mapjoin是一種避免避免資料傾斜的手段
允許在map階段進行join操作，mapjoin把小表全部讀入記憶體中，在map階段直接拿另外乙個表的資料和記憶體中表資料做匹配，由於在map是進行了join操作，省去了reduce執行的效率也會高很多
在《hive：join遇到問題》有具體操作
在對多個表join連線操作時，將小表放在join的左邊，大表放在jion的右邊，
在執行這樣的join連線時小表中的資料會被快取到記憶體當中,這樣可以有效減少發生記憶體溢位錯誤的機率
沒有乙個表足夠小到能夠放進記憶體：用到bucket map join。其方法是兩個join表在join key上都做hash bucket，並且把你打算複製的那個（相對）小表的bucket數設定為大表的倍數。這樣資料就會按照join key做hash bucket。小表依然複製到所有節點，map join的時候，小表的每一組bucket載入成hashtable，與對應的乙個大表bucket做區域性join，這樣每次只需要載入部分hashtable就可以了。
2. 設定引數 參考這裡
hive.map.aggr = true
hive.groupby.skewindata=true 還有其他引數
3.sql語言調節
比如： group by維度過小時：採用sum() group by的方式來替換count(distinct)完成計算
4.streamtable
將在reducer中進行join操作時的小table放入記憶體，而大table通過stream方式讀取
5.索引
hive從0.80開始才有，提供了乙個bitmap點陣圖索引，索引可以加快group by查詢語句的執行速度，用的較少。
set mapreduce.map.memory.mb=1025;
set mapreduce.reduce.memory.mb=1025;
其他優化：
1、 列裁剪（column pruning）：只有需要用到的列才進行輸出
2、 謂詞下推（predicate pushdown）：盡早進行資料過濾(見圖表 7中，下面為先處理的邏
輯)，減少後續處理的資料量
3、 分割槽裁剪（partition pruning）：只讀取滿足分割槽條件的檔案
4、 map-join：對於join中一些小檔案，可以在map階段進行join操作，見3.2.2節map-join部分
5、 join-reordering：將在reducer中進行join操作時的小table放入記憶體，而大table通過
stream方式讀取
6、 group-by優化： 進行區域性聚合進行優化（包括hash-based和sort-based），對於skew
的key（key的row num和size在reduce時非常不均）可以進行兩次map-reduce的方式優化
hive的配置引數比較保守，所以效率會比較差一點，修改配置會讓查詢效率有比較大的提公升，記錄幾個對查詢效率影響比較重要的引數。
元資料：
巢狀sql並行執行優化:
四、排序優化
order by 實現全域性排序，乙個reduce實現，效率低
sort by 實現部分有序，單個reduce輸出的結果是有序的，效率高，通常和distribute by關鍵字一起使用（distribute by關鍵字 可以指定map 到 reduce端的分發key）
cluster by col1 等價於distribute by col1 sort by col1.
五、合併小檔案
檔案數目過多，會給 hdfs 帶來壓力，並且會影響處理效率，可以通過合併 map 和 reduce 的結果檔案來盡量消除這樣的影響
hive.merge.mapfiles = true是否和並 map 輸出檔案，預設為 true
hive.merge.mapredfiles = false是否合併 reduce 輸出檔案，預設為 false
hive.merge.size.per.task = 256*1000*1000合併檔案的大小。
這裡的引數沒有寫到上面的**裡是因為這是可以根據任務不同臨時設定的，而不一定非要是全域性設定。有時候全域性設定了反而對大檔案的操作有效能影響。
六、使用分割槽，rcfile，lzo，orcfile等
hive中的每個分割槽都對應hdfs上的乙個目錄，分割槽列也不是表中的乙個實際的字段，而是乙個或者多個偽列，在表的資料檔案中實際上並不儲存分割槽列的資訊與資料。partition關鍵字中排在前面的為主分割槽（只有乙個），後面的為副分割槽
靜態分割槽：靜態分割槽在載入資料和使用時都需要在sql語句中指定
例：(stat_date='20120625',province='hunan')
動態分割槽：使用動態分割槽需要設定hive.exec.dynamic.partition引數值為true，預設值為false，在預設情況下，hive會假設主分割槽時靜態分割槽，副分割槽使用動態分割槽；如果想都使用動態分割槽，需要設定set hive.exec.dynamic.partition.mode=nostrick，預設為strick
例：(stat_date='20120625',province)
hive大資料傾斜總結
在做shuffle階段的優化過程中，遇到了資料傾斜的問題，造成了對一些情況下優化效果不明顯。主要是因為在job完成後的所得到的 counters是整個job的總和，優化是基於這些counters得出的平均值，而由於資料傾斜的原因造成map處理資料量的差異過大，使得這些平均 值能代表的價值降低。hiv...
Hive資料傾斜
hive資料傾斜問題 傾斜原因 map輸出資料按key hash分配到reduce中,由於key分布不均勻 或者業務資料本身的特點。等原因造成的reduce上的資料量差異過大。1.1 key分布不均勻 1.2 業務資料本身的特性 1.3 sql語句造成資料傾斜 解決方案 1 引數調節 hive.ma...
HIVE 資料傾斜
解決資料傾斜，歸根結底是使map的輸出資料更均勻的分布到reduce中去。1 join 1 其中乙個表較小，但是key集中。分發到某乙個或幾個reduce上的資料遠高於平均值 2 大表與大表，但是分桶的判斷欄位0值或空值過多。這些空值都由乙個reduce處理，非常慢 2 group by group...