hive在跑資料時經常會出現資料傾斜的情況，使的作業經常reduce完成在99%後一直卡住，最後的１%花了幾個小時都沒跑完，這種情況就很可能是資料傾斜的原因，解決方法要根據具體情況來選擇具體的方案
這種情況可以對異常值賦乙個隨機值來分散key
如：selectuserid , name
fromuser_info a
join (
select case when userid is null then cast ( rand ( 47 )* 100000 as i nt )
elseuserid
fromuser_read_log
)b on a . userid = b . userid
通過rand函式將為null的值分散到不同的值上，在key值比較就能解決資料傾斜的問題
注：對於異常值如果不需要的話，最好是提前過濾掉，這樣計算量可以大大減少
set hive.exec.reducers.bytes.per.reducer = 1000000000
也就是每個節點的reduce 預設是處理1g大小的資料，如果你的join 操作也產生了資料傾斜，那麼你可以在hive 中設定
set hive.optimize.skewjoin = true;
set hive.skewjoin.key = skew_key_threshold （default = 100000）
hive 在執行的時候沒有辦法判斷哪個key 會產生多大的傾斜，所以使用這個引數控制傾斜的閾值，如果超過這個值，新的值會傳送給那些還沒有達到的reduce, 一般可以設定成你
（處理的總記錄數/reduce個數）的2-4倍都可以接受.
傾斜是經常會存在的，一般select 的層數超過2層，翻譯成執行計畫多於3個以上的mapreduce job 都很容易產生傾斜，建議每次執行比較複雜的sql 之前都可以設一下這個引數. 如果你不知道設定多少，可以就按官方預設的1個reduce 只處理1g 的演算法，那麼 skew_key_threshold = 1g/平均行長. 或者預設直接設成250000000 (差不多算平均行長4個位元組)
set mapred.reduce.tasks=800;
預設是先設定hive.exec.reducers.bytes.per.reducer這個引數，設定了後hive會自動計算reduce的個數，因此兩個引數一般不同時使用
set hive.map.aggr=true (開啟map端combiner); //在map端做combiner,假如map各條資料基本上不一樣, 聚合沒什麼意義，做combiner反而畫蛇添足,hive裡也考慮的比較周到通過引數hive.groupby.mapaggr.checkinterval = 100000 (預設)
hive.map.aggr.hash.min.reduction=0.5(預設)
兩個引數的意思是：預先取100000條資料聚合,如果聚合後的條數/100000>0.5，則不再聚合
set hive.groupby.skewindata=true；//決定groupby操作是否支援傾斜的資料。注意：只能對單個字段聚合.控制生成兩個mr job,第乙個mr job map的輸出結果隨機分配到reduce做次預彙總,減少某些key值條數過多某些key條數過小造成的資料傾斜問題
此時，可以通過mapjoin來優化，
sethive.auto.convert.join=true; //將小表刷入記憶體中
sethive.mapjoin.smalltable.filesize = 2500000 ;//刷入記憶體表的大小(位元組)
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...
hive資料傾斜
key 分布不均勻 業務資料本身的特性 建表考慮不周全 某些 hql 語句本身就存在資料傾斜 1.空值產生的資料傾斜 在日誌中，常會有資訊丟失的問題，比如日誌中的 user id，如果取其中的 user id 和使用者表中的 user id 相關聯，就會碰到資料傾斜的問題。解決方案 1 user i...