總結:
一:key分布不均勻
1)key為null或異常值
對key進行打散
通過rand函數(shù)將為null的值分散到不同的值上;
對異常值賦一個隨機值來分散key
2)key為正常值
1:設置reducer參數(shù)值腻异,使用這個參數(shù)控制傾斜的閾值庭惜,如果超過這個值,新的值會發(fā)送給那些還沒有達到的reduce
2:增加reduce的數(shù)量
3:業(yè)務需求方面進行細分
二:group by 產(chǎn)生傾斜的問題
group by既可以分類也可以去重
1:對Map 端部分聚合涝开,相當于Combiner循帐,設置hive.map.aggr=true
2:設置hive.groupby.skewindata=true
控制生成兩個MR Job,第一個MR Job Map的輸出結果隨機分配到reduce做次預匯總,減少某些key值條數(shù)過多某些key條數(shù)過小造成的數(shù)據(jù)傾斜問題
即就是生成兩個MapReduce Job。第一個Job進行預處理舀武、部分聚合拄养,使得結果是相同的Group By Key可以分發(fā)到不同的Reduce中;第二個MapReduce Job將預處理數(shù)據(jù)結果按照Group By Key分發(fā)到Reduce中银舱,完成最終的聚合操作瘪匿;
三:count distinct大量相同特殊值
count distinct時,將值為空的情況單獨處理寻馏,如果是計算count distinct棋弥,可以不用處理,直接過濾操软,在最后結果中加1嘁锯。如果還有其他計算,需要進行group by聂薪,可以先將值為空的記錄單獨處理家乘,再和其他計算結果進行union(合并)。
四:Join優(yōu)化
1:將小表刷入內(nèi)存中藏澳,可以設置刷入內(nèi)存表的大腥示狻;將大表放在最后
Join時翔悠,Hive會緩存join序列中除了最后一個表的所有記錄业崖,在通過最后一個表將結果序列化到文件系統(tǒng)中野芒。這有助于在reduce端減少內(nèi)存的使用量,實踐中双炕,應該把最大的那個表寫在最后狞悲,否則會因為緩存浪費大量內(nèi)存(表的大小從左到右是依次增加的)
MapJoin就是在map階段時進行表之間的連接,而不需要進入到Reduce階段才進行連接妇斤,這樣就省下了在Shuffle階段時要進行的大量數(shù)據(jù)傳輸摇锋,從而起到了優(yōu)化作業(yè)的作用。
2:本地模式執(zhí)行任務
如果數(shù)據(jù)量 比較小站超,可以通過本地模式執(zhí)行所有任務荸恕,即在執(zhí)行的過程中通過設置為本地模式,因為本地模式下不會轉換為mapreduce任務死相,而是將本地的數(shù)據(jù)文件格式輸出
五:limit
開啟limit優(yōu)化融求,使用limit進行抽樣查詢,不需要全表掃描算撮,缺點是有些需要的數(shù)據(jù)可能被忽略掉
六:并行執(zhí)行
hive在執(zhí)行查詢的時候會將查詢轉化為一個或多個Job鏈生宛,執(zhí)行器會按照順序執(zhí)行這些Job;如果這些Job沒有依賴關系钮惠,則可以采取并行方式進行執(zhí)行茅糜。
七:啟用嚴格模式
Hive設置以一種嚴格模式,防止用戶進行一些意想不到的查詢
1:分區(qū)查詢時where中沒有分區(qū)過濾條件素挽,不允許掃描所有的分區(qū)蔑赘;
2:使用order by時必須使用limit限制,即可以防止reduce的額外執(zhí)行時間预明;
3:笛卡兒積缩赛,必須使用on字段,而不能使用where字句替代
八:Jvm重用
Hive Hql會轉化成MapReduce撰糠,MR會將job任務轉化為多個任務酥馍,每個人物都是一個新的JVM實例,重用這些實例阅酪,可以減少性能消耗
默認情況下旨袒,每個task都是一個新的JVM實例,都需要開啟和銷毀术辐。對于小文件砚尽,每個文件都會對應一個task,在一些情況下辉词,JVM開啟和銷毀的時間可能會比實際處理數(shù)據(jù)的時間消耗要長必孤,JVM重用是Hadoop調(diào)優(yōu)參數(shù)的內(nèi)容,其對Hive的性能具有非常大的影響瑞躺,特別是對于小文件的場景敷搪,這類場景執(zhí)行時間都很短
九:調(diào)整map和reduce的個數(shù)
有些只需要map兴想,不需要reduce;
hive是按照輸入數(shù)據(jù)量的大小調(diào)整reducer個數(shù)赡勘,hive中可以配置一個reducer的數(shù)量大小嫂便,可以動態(tài)的調(diào)整;
詳細內(nèi)容
數(shù)據(jù)傾斜定義
任務進度長時間維持在99%(或100%)闸与,查看任務監(jiān)控頁面顽悼,發(fā)現(xiàn)只有少量(1個或幾個)reduce子任務未完成。因為其處理的數(shù)據(jù)量和其他reduce差異過大几迄。
單一reduce的記錄數(shù)與平均記錄數(shù)差異過大,通潮溃可能達到3倍甚至更多映胁。 最長時長遠大于平均時長。
1 原因
1)甲雅、key分布不均勻
2)解孙、業(yè)務數(shù)據(jù)本身的特性
3)、建表時考慮不周
4)抛人、某些SQL語句本身就有數(shù)據(jù)傾斜