化實(shí)戰(zhàn)：從執(zhí)行計(jì)劃到數(shù)據(jù)傾斜的全面調(diào)優(yōu)指南)
1. 為什么Hive性能優(yōu)化是個(gè)繞不開的坎做數(shù)據(jù)倉庫這行的沒人能繞開Hive。不管你上層用的是Spark SQL、Flink SQL還是Trino底層存儲(chǔ)大概率還是落在HDFS上元數(shù)據(jù)還是那套Metastore表格式不是ORC就是Parquet。Hive這東西說它老也好說它慢也好但架不住它生態(tài)成熟、穩(wěn)定、便宜。問題在于很多人用Hive就是寫SQL跑數(shù)跑得慢就加資源加完還慢就罵罵咧咧換引擎。實(shí)際上大部分性能問題根本不在引擎本身而在SQL寫法、表設(shè)計(jì)、分區(qū)策略、文件布局這些地方。我見過太多團(tuán)隊(duì)一個(gè)ETL任務(wù)跑三個(gè)小時(shí)查下來就是全表掃描加笛卡爾積改完SQL直接降到八分鐘。也見過數(shù)據(jù)傾斜把整個(gè)集群拖垮最后發(fā)現(xiàn)是某個(gè)key的記錄數(shù)是其他key的幾萬倍。Hive性能優(yōu)化這件事核心不是背參數(shù)而是理解它背后的執(zhí)行模型——MapReduce也好Tez也好Spark也好底層邏輯都是分而治之你要做的是讓數(shù)據(jù)分得均勻、算得局部、傳得少。這篇文章適合誰看如果你是數(shù)據(jù)開發(fā)工程師、數(shù)倉建設(shè)者、ETL負(fù)責(zé)人或者你每天的工作就是跟Hive SQL打交道那這篇內(nèi)容就是給你寫的。我會(huì)從執(zhí)行計(jì)劃、表設(shè)計(jì)、SQL寫法、參數(shù)調(diào)優(yōu)、數(shù)據(jù)傾斜處理這幾個(gè)維度把Hive性能優(yōu)化這件事拆開揉碎講清楚。每個(gè)優(yōu)化點(diǎn)我都會(huì)說明為什么這么做有效背后的原理是什么以及在實(shí)際操作中怎么落地。不堆術(shù)語不抄文檔全是實(shí)戰(zhàn)里踩出來的經(jīng)驗(yàn)。2. 先看懂Hive到底怎么跑你的SQL2.1 從SQL到任務(wù)執(zhí)行流程拆解很多人優(yōu)化Hive就是憑感覺加參數(shù)問他為什么加這個(gè)參數(shù)答不上來。這不行。你得先知道一條Hive SQL提交之后到底經(jīng)歷了什么。一條SQL進(jìn)來Hive首先通過Antlr做詞法語法解析生成抽象語法樹AST。然后經(jīng)過語義分析綁定元數(shù)據(jù)信息比如這張表有哪些字段、分區(qū)是什么、存儲(chǔ)格式是什么。接著生成邏輯執(zhí)行計(jì)劃再經(jīng)過一系列優(yōu)化器規(guī)則——謂詞下推、列裁剪、分區(qū)裁剪、常量折疊等等——變成物理執(zhí)行計(jì)劃。最后根據(jù)你設(shè)置的執(zhí)行引擎把物理計(jì)劃翻譯成MapReduce任務(wù)、Tez DAG或者Spark Job。關(guān)鍵點(diǎn)在這里優(yōu)化器能做的事情是有限的。它只能在你寫的SQL基礎(chǔ)上做等價(jià)變換如果你寫的SQL本身就是全表掃描加笛卡爾積優(yōu)化器救不了你。所以優(yōu)化的第一原則是寫SQL的時(shí)候就要考慮執(zhí)行計(jì)劃長(zhǎng)什么樣。舉個(gè)例子你寫了一個(gè)SELECT * FROM orders WHERE dt 2024-01-01如果orders表是按dt分區(qū)的優(yōu)化器會(huì)自動(dòng)做分區(qū)裁剪只掃描對(duì)應(yīng)分區(qū)。但如果你寫的是SELECT * FROM orders WHERE substr(dt,1,4) 2024分區(qū)裁剪就失效了因?yàn)閮?yōu)化器無法從函數(shù)表達(dá)式反推分區(qū)范圍。這就是典型的“寫法決定性能”。2.2 執(zhí)行引擎的選擇邏輯Hive支持多種執(zhí)行引擎最常見的是MapReduce、Tez和Spark。很多人問選哪個(gè)我的答案從來都是看你的集群現(xiàn)狀和任務(wù)特征。MapReduce是最穩(wěn)的但也是最慢的。每個(gè)MapReduce階段都要落盤中間結(jié)果寫HDFS下一個(gè)階段再從HDFS讀。一個(gè)復(fù)雜的SQL可能被拆成五六個(gè)MapReduce任務(wù)每個(gè)任務(wù)都有啟動(dòng)開銷和IO開銷。Tez把多個(gè)MapReduce任務(wù)合并成一個(gè)DAG中間結(jié)果不落盤或者少落盤性能提升明顯。Spark基于內(nèi)存計(jì)算迭代計(jì)算場(chǎng)景優(yōu)勢(shì)大但對(duì)內(nèi)存要求高且和Hive on Spark的兼容性需要額外關(guān)注。我個(gè)人的經(jīng)驗(yàn)是如果集群資源緊張、任務(wù)以批處理為主、對(duì)穩(wěn)定性要求極高用MapReduce如果追求性能且集群有Tez優(yōu)先用Tez如果團(tuán)隊(duì)已經(jīng)有Spark生態(tài)用Spark引擎也合理。但不管用哪個(gè)引擎表設(shè)計(jì)、分區(qū)策略、文件大小這些底層的東西不變優(yōu)化邏輯是相通的。提示切換執(zhí)行引擎不是銀彈。我見過有人把MapReduce換成Tez性能沒提升反而更慢原因是小文件太多Tez的DAG啟動(dòng)開銷被放大了。引擎切換前先解決小文件問題。2.3 執(zhí)行計(jì)劃怎么看看執(zhí)行計(jì)劃是優(yōu)化的基本功。在Hive里用EXPLAIN命令在Spark SQL里用EXPLAIN EXTENDED。重點(diǎn)看幾個(gè)東西Stage的劃分、Map和Reduce的數(shù)量、是否有數(shù)據(jù)傾斜的跡象、謂詞下推有沒有生效、Join的類型是什么。比如你看到執(zhí)行計(jì)劃里某個(gè)Stage的Reduce數(shù)量是1那說明所有數(shù)據(jù)都涌向一個(gè)Reducer這幾乎必然導(dǎo)致性能瓶頸。再比如你看到Map Join沒有生效而是走了Common Join那說明小表不夠小或者參數(shù)沒配對(duì)導(dǎo)致本可以避免的Shuffle發(fā)生了。我習(xí)慣在優(yōu)化前后各跑一次EXPLAIN對(duì)比Stage數(shù)量、Operator類型、數(shù)據(jù)流向。優(yōu)化有效的標(biāo)志通常是Stage數(shù)量減少、Shuffle數(shù)據(jù)量下降、Map Join替代Common Join、分區(qū)裁剪生效。3. 表設(shè)計(jì)層面的優(yōu)化地基沒打好后面全白搭3.1 分區(qū)與分桶讓數(shù)據(jù)有跡可循分區(qū)是Hive性能優(yōu)化里性價(jià)比最高的手段沒有之一。按天分區(qū)、按業(yè)務(wù)線分區(qū)、按地區(qū)分區(qū)本質(zhì)上就是把一張大表在存儲(chǔ)層面切成小目錄。查詢的時(shí)候如果帶上分區(qū)條件Hive直接定位到對(duì)應(yīng)目錄掃描的數(shù)據(jù)量可能從TB級(jí)降到GB級(jí)。但分區(qū)不是越多越好。每個(gè)分區(qū)對(duì)應(yīng)HDFS上的一個(gè)目錄分區(qū)太多會(huì)導(dǎo)致NameNode元數(shù)據(jù)壓力大同時(shí)小文件問題會(huì)非常嚴(yán)重。我見過有人按小時(shí)分區(qū)一天24個(gè)分區(qū)一年8760個(gè)分區(qū)每個(gè)分區(qū)里就幾MB數(shù)據(jù)查詢的時(shí)候光列目錄就耗掉幾秒。合理的分區(qū)粒度通常是天或者月具體看數(shù)據(jù)量和查詢模式。分桶是在分區(qū)的基礎(chǔ)上進(jìn)一步做哈希切分。CLUSTERED BY (user_id) INTO 64 BUCKETS意思是按user_id的哈希值把數(shù)據(jù)分成64個(gè)文件。分桶的好處是Join的時(shí)候如果兩邊都按同樣的鍵分桶可以做Bucket Map Join避免Shuffle采樣的時(shí)候可以直接對(duì)桶采樣不用全表掃描。分區(qū)和分桶怎么選我的經(jīng)驗(yàn)是分區(qū)用于過濾分桶用于Join和采樣。如果你的查詢經(jīng)常按時(shí)間過濾按時(shí)間分區(qū)。如果經(jīng)常按某個(gè)維度Join考慮按那個(gè)維度分桶。兩者可以疊加使用比如先按天分區(qū)再按user_id分桶。3.2 文件格式與壓縮IO是最大的瓶頸Hive表的數(shù)據(jù)最終落在HDFS上文件格式直接決定了讀取效率。TextFile是默認(rèn)格式可讀性好但性能最差因?yàn)樗葱写鎯?chǔ)查詢一列也要讀整行而且沒有壓縮。ORC和Parquet是列式存儲(chǔ)查詢時(shí)只讀需要的列壓縮比高自帶索引性能遠(yuǎn)超TextFile。ORC和Parquet怎么選ORC對(duì)Hive的兼容性更好支持ACID事務(wù)謂詞下推更徹底Parquet在Spark生態(tài)里更常用嵌套結(jié)構(gòu)支持更好。如果你們團(tuán)隊(duì)以Hive為主選ORC如果Spark和Hive混用Parquet更穩(wěn)妥。我實(shí)測(cè)下來同樣的數(shù)據(jù)量和查詢ORC的掃描速度通常比Parquet快10%到20%但差距沒有想象中那么大。壓縮方面Snappy是折中選擇壓縮比和速度平衡Zlib壓縮比更高但解壓慢LZO速度快但壓縮比一般。對(duì)于熱數(shù)據(jù)用Snappy對(duì)于冷數(shù)據(jù)歸檔用Zlib。注意ORC和Parquet自帶壓縮不需要額外指定壓縮格式建表時(shí)指定STORED AS ORC TBLPROPERTIES (orc.compressSNAPPY)即可。3.3 小文件治理NameNode的噩夢(mèng)小文件是Hive性能的隱形殺手。每個(gè)小文件在HDFS上都是一個(gè)獨(dú)立的塊NameNode要維護(hù)每個(gè)塊的元數(shù)據(jù)。小文件多了NameNode內(nèi)存吃緊查詢時(shí)Map任務(wù)數(shù)量暴增每個(gè)Map處理一點(diǎn)點(diǎn)數(shù)據(jù)就啟動(dòng)和銷毀開銷全花在調(diào)度上了。小文件怎么來的動(dòng)態(tài)分區(qū)插入是主要來源。你開啟動(dòng)態(tài)分區(qū)一條INSERT語句寫了幾百個(gè)分區(qū)每個(gè)分區(qū)里可能就幾KB數(shù)據(jù)。另一個(gè)來源是頻繁的增量寫入每次寫一點(diǎn)攢了一堆小文件。治理小文件有幾個(gè)手段。第一在寫入端控制動(dòng)態(tài)分區(qū)插入時(shí)設(shè)置hive.merge.mapfilestrue和hive.merge.mapredfilestrue讓Hive在任務(wù)結(jié)束后自動(dòng)合并小文件。第二定期做合并任務(wù)用ALTER TABLE ... CONCATENATE或者重寫一遍數(shù)據(jù)把多個(gè)小文件合并成大文件。第三調(diào)整Reduce數(shù)量Reduce數(shù)量決定了輸出文件數(shù)量適當(dāng)減少Reduce可以避免產(chǎn)生太多小文件但要注意不要造成單文件過大。注意合并小文件是有代價(jià)的會(huì)消耗額外的計(jì)算和IO資源。建議在業(yè)務(wù)低峰期做或者用獨(dú)立的合并任務(wù)調(diào)度。4. SQL寫法優(yōu)化同樣的邏輯不同的性能4.1 Join優(yōu)化的核心邏輯Join是Hive里最耗資源的操作沒有之一。Join的性能取決于三個(gè)因素參與Join的數(shù)據(jù)量、Join的鍵、Join的方式。Hive支持多種Join方式Common JoinReduce端Join、Map Join廣播小表、Bucket Map Join分桶Join、Sort Merge Bucket Join排序合并分桶Join。默認(rèn)情況下Hive會(huì)走Common Join也就是兩邊數(shù)據(jù)都按Join鍵做Shuffle然后在Reduce端做笛卡爾積匹配。這個(gè)過程的網(wǎng)絡(luò)傳輸和磁盤IO開銷巨大。Map Join是優(yōu)化Join的第一選擇。如果有一張表足夠小可以完全加載到內(nèi)存里Hive會(huì)把它廣播到每個(gè)Map節(jié)點(diǎn)在Map端完成Join避免Shuffle。觸發(fā)Map Join的條件是小表的大小小于hive.mapjoin.smalltable.filesize默認(rèn)25MB。你可以手動(dòng)指定/* MAPJOIN(small_table) */來強(qiáng)制走M(jìn)ap Join。但Map Join不是萬能的。如果小表其實(shí)不小廣播到每個(gè)節(jié)點(diǎn)會(huì)消耗大量?jī)?nèi)存和網(wǎng)絡(luò)帶寬反而拖慢任務(wù)。我見過有人強(qiáng)制Map Join一張500MB的表結(jié)果每個(gè)Map容器都OOM。判斷標(biāo)準(zhǔn)很簡(jiǎn)單小表大小乘以Map數(shù)量如果超過集群內(nèi)存總量的一定比例就不要用Map Join。Bucket Map Join和Sort Merge Bucket Join是更高級(jí)的優(yōu)化。如果兩張表都按Join鍵分桶且桶的數(shù)量成倍數(shù)關(guān)系可以做Bucket Map Join每個(gè)Map只處理對(duì)應(yīng)的桶避免全表Shuffle。Sort Merge Bucket Join要求兩邊都按Join鍵分桶且排序性能更好但建表要求更高。4.2 數(shù)據(jù)傾斜的識(shí)別與處理數(shù)據(jù)傾斜是Hive性能問題里最讓人頭疼的?，F(xiàn)象很簡(jiǎn)單大部分Reduce任務(wù)很快跑完少數(shù)幾個(gè)Reduce任務(wù)跑得極慢甚至卡在99%不動(dòng)。原因也簡(jiǎn)單某個(gè)Join鍵或者Group By鍵的數(shù)據(jù)量遠(yuǎn)超其他鍵導(dǎo)致處理這個(gè)鍵的Reduce任務(wù)負(fù)載過重。識(shí)別數(shù)據(jù)傾斜的方法看任務(wù)監(jiān)控如果Reduce階段有個(gè)別任務(wù)耗時(shí)是其他的幾倍甚至幾十倍基本可以確定是傾斜?；蛘吲芤粋€(gè)SELECT key, COUNT(*) FROM table GROUP BY key ORDER BY COUNT(*) DESC LIMIT 10看看最大key的計(jì)數(shù)是不是遠(yuǎn)超平均值。處理數(shù)據(jù)傾斜有幾種思路。第一種Map Join如果傾斜是因?yàn)樾”鞪oin大表把小表廣播出去在Map端完成Join傾斜自然消失。第二種加鹽打散給傾斜的鍵加上隨機(jī)前綴讓數(shù)據(jù)分散到多個(gè)Reduce然后再去掉前綴做二次聚合。第三種單獨(dú)處理傾斜鍵把傾斜的鍵單獨(dú)拎出來處理剩下的數(shù)據(jù)正常Join最后Union回去。第四種調(diào)整Reduce數(shù)量增加Reduce數(shù)量可以緩解傾斜但不能根治因?yàn)閮A斜鍵的數(shù)據(jù)量沒變只是分到了更多Reduce上單個(gè)Reduce的壓力可能還是大。我個(gè)人的經(jīng)驗(yàn)是優(yōu)先用Map Join不行就加鹽加鹽解決不了就單獨(dú)處理。加鹽的代價(jià)是SQL變復(fù)雜需要寫兩段邏輯再合并但效果通常很好。4.3 窗口函數(shù)與Group By的取舍窗口函數(shù)和Group By都能做聚合但性能特征不同。Group By會(huì)把數(shù)據(jù)按Key做Shuffle然后在Reduce端聚合輸出結(jié)果行數(shù)等于Key的數(shù)量。窗口函數(shù)不減少行數(shù)它在每行上計(jì)算一個(gè)聚合值但需要把數(shù)據(jù)按分區(qū)鍵排序排序開銷大。如果只需要聚合結(jié)果用Group By。如果需要在明細(xì)行上附加聚合信息用窗口函數(shù)。但要注意窗口函數(shù)的PARTITION BY鍵如果數(shù)據(jù)傾斜同樣會(huì)導(dǎo)致性能問題。而且窗口函數(shù)默認(rèn)會(huì)把整個(gè)分區(qū)的數(shù)據(jù)加載到內(nèi)存排序分區(qū)太大可能OOM。一個(gè)常見的優(yōu)化技巧是先用Group By做預(yù)聚合再用窗口函數(shù)。比如你要計(jì)算每個(gè)用戶的累計(jì)消費(fèi)可以先按用戶和日期Group By算出每日消費(fèi)再用窗口函數(shù)做累計(jì)這樣窗口函數(shù)處理的數(shù)據(jù)量小很多。4.4 謂詞下推與列裁剪的實(shí)戰(zhàn)細(xì)節(jié)謂詞下推是指把過濾條件下推到數(shù)據(jù)掃描階段盡量早地過濾掉不需要的數(shù)據(jù)。列裁剪是指只讀取查詢中用到的列不讀整行。這兩個(gè)優(yōu)化在列式存儲(chǔ)格式ORC、Parquet上效果特別明顯。但謂詞下推有失效的場(chǎng)景。如果過濾條件寫在子查詢里且子查詢有LIMIT或者窗口函數(shù)謂詞下推可能不生效。比如SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM t) tmp WHERE rn 10這個(gè)rn的過濾條件無法下推到掃描階段因?yàn)閞n是計(jì)算出來的。這種情況下Hive會(huì)先掃描全表計(jì)算ROW_NUMBER再過濾性能很差。列裁剪的注意事項(xiàng)是**避免使用SELECT ***。SELECT *會(huì)讀取所有列即使你只需要其中幾列。在寬表場(chǎng)景下這個(gè)差距可能是幾倍的IO。養(yǎng)成習(xí)慣需要什么列就寫什么列。5. 參數(shù)調(diào)優(yōu)讓Hive跑得更順滑5.1 Map與Reduce數(shù)量的控制Map數(shù)量由輸入文件的分片大小決定。mapreduce.input.fileinputformat.split.maxsize控制每個(gè)Map處理的最大數(shù)據(jù)量默認(rèn)等于HDFS塊大小通常128MB或256MB。如果小文件多可以調(diào)小這個(gè)值讓每個(gè)Map處理更少數(shù)據(jù)但Map數(shù)量會(huì)增多。如果文件大且少可以調(diào)大這個(gè)值減少M(fèi)ap數(shù)量。Reduce數(shù)量默認(rèn)由Hive根據(jù)輸入數(shù)據(jù)量估算但估算經(jīng)常不準(zhǔn)。hive.exec.reducers.bytes.per.reducer控制每個(gè)Reduce處理的數(shù)據(jù)量默認(rèn)256MB。hive.exec.reducers.max控制Reduce數(shù)量上限。你可以手動(dòng)指定Reduce數(shù)量SET mapred.reduce.tasks 100。Reduce數(shù)量不是越多越好。Reduce太多會(huì)導(dǎo)致每個(gè)Reduce處理的數(shù)據(jù)量很小啟動(dòng)和關(guān)閉開銷占比高Reduce太少會(huì)導(dǎo)致單個(gè)Reduce處理的數(shù)據(jù)量大容易傾斜和OOM。我的經(jīng)驗(yàn)值是每個(gè)Reduce處理128MB到256MB數(shù)據(jù)比較合適。你可以根據(jù)輸入數(shù)據(jù)總量除以這個(gè)值來估算Reduce數(shù)量。5.2 內(nèi)存與并行度參數(shù)Hive任務(wù)的內(nèi)存分為Map內(nèi)存和Reduce內(nèi)存。mapreduce.map.memory.mb和mapreduce.reduce.memory.mb控制容器內(nèi)存大小。mapreduce.map.java.opts和mapreduce.reduce.java.opts控制JVM堆大小通常設(shè)置為容器內(nèi)存的80%左右。如果任務(wù)報(bào)OOM先看是Map OOM還是Reduce OOM。Map OOM通常是Map Join的小表太大或者單個(gè)Map處理的數(shù)據(jù)量太大。Reduce OOM通常是數(shù)據(jù)傾斜導(dǎo)致單個(gè)Reduce處理的數(shù)據(jù)量過大或者聚合操作的內(nèi)存占用超限。調(diào)大內(nèi)存能解決一部分問題但根本解決要靠?jī)?yōu)化數(shù)據(jù)分布。并行度方面hive.exec.paralleltrue可以讓沒有依賴的Stage并行執(zhí)行hive.exec.parallel.thread.number控制并行線程數(shù)。這個(gè)參數(shù)在復(fù)雜SQL里效果明顯但要注意集群資源是否足夠并行度太高會(huì)互相搶資源。5.3 動(dòng)態(tài)分區(qū)與嚴(yán)格模式動(dòng)態(tài)分區(qū)插入是ETL里的常用操作但默認(rèn)配置下性能很差。hive.exec.dynamic.partition.mode默認(rèn)是strict要求至少有一個(gè)靜態(tài)分區(qū)。hive.exec.max.dynamic.partitions和hive.exec.max.dynamic.partitions.pernode控制動(dòng)態(tài)分區(qū)的最大數(shù)量默認(rèn)值偏小容易報(bào)錯(cuò)。開啟動(dòng)態(tài)分區(qū)后每個(gè)Map和Reduce都會(huì)為每個(gè)分區(qū)創(chuàng)建一個(gè)文件如果分區(qū)數(shù)量多小文件問題會(huì)很嚴(yán)重。建議開啟動(dòng)態(tài)分區(qū)的同時(shí)設(shè)置hive.merge.mapfiles和hive.merge.mapredfiles為true讓Hive在任務(wù)結(jié)束后自動(dòng)合并小文件。另外hive.exec.dynamic.partition要設(shè)為true否則動(dòng)態(tài)分區(qū)不生效。這些參數(shù)看起來瑣碎但配錯(cuò)一個(gè)就可能導(dǎo)致任務(wù)失敗或者性能驟降。6. 常見問題與排查技巧實(shí)錄6.1 任務(wù)卡在99%不動(dòng)的排查思路這是最經(jīng)典的問題。任務(wù)跑到99%然后卡住幾十分鐘甚至幾個(gè)小時(shí)。原因幾乎總是數(shù)據(jù)傾斜某個(gè)Reduce任務(wù)處理的數(shù)據(jù)量遠(yuǎn)超其他任務(wù)其他任務(wù)早就跑完了它還在慢慢磨。排查步驟第一看任務(wù)監(jiān)控找到那個(gè)卡住的Reduce任務(wù)看它的輸入數(shù)據(jù)量。第二跑一個(gè)Group By統(tǒng)計(jì)找出計(jì)數(shù)最大的Key。第三確認(rèn)這個(gè)Key是不是業(yè)務(wù)上的熱點(diǎn)比如某個(gè)大客戶、某個(gè)默認(rèn)值、某個(gè)空值。解決方案如果是Join導(dǎo)致的傾斜嘗試Map Join或者加鹽。如果是Group By導(dǎo)致的傾斜可以設(shè)置hive.groupby.skewindatatrueHive會(huì)自動(dòng)做兩階段聚合先加隨機(jī)前綴分散數(shù)據(jù)再去掉前綴聚合。這個(gè)參數(shù)對(duì)Group By傾斜有奇效但會(huì)增加一輪Shuffle。6.2 OOM錯(cuò)誤的定位與解決OOM分兩種JVM堆內(nèi)存溢出和物理內(nèi)存溢出。JVM堆內(nèi)存溢出會(huì)報(bào)java.lang.OutOfMemoryError: Java heap space物理內(nèi)存溢出會(huì)被YARN殺掉報(bào)Container killed by YARN for exceeding memory limits。JVM堆內(nèi)存溢出通常是Map Join的小表太大或者聚合操作的HashMap太大。解決方法是調(diào)大mapreduce.map.java.opts和mapreduce.reduce.java.opts或者放棄Map Join改用Common Join。物理內(nèi)存溢出通常是JVM堆外內(nèi)存使用過多比如ORC讀取時(shí)的緩沖區(qū)、網(wǎng)絡(luò)傳輸?shù)木彌_區(qū)。解決方法是調(diào)大容器內(nèi)存mapreduce.map.memory.mb和mapreduce.reduce.memory.mb同時(shí)確保JVM堆大小不超過容器內(nèi)存的80%。提示調(diào)大內(nèi)存不是萬能藥。如果數(shù)據(jù)傾斜嚴(yán)重單個(gè)Reduce處理的數(shù)據(jù)量是其他Reduce的幾十倍調(diào)大內(nèi)存只能延緩OOM不能根治。還是要從數(shù)據(jù)分布入手。6.3 小文件問題的應(yīng)急處理如果發(fā)現(xiàn)表目錄下小文件太多查詢性能急劇下降可以應(yīng)急做一次合并。用ALTER TABLE table_name PARTITION (dt2024-01-01) CONCATENATE可以把分區(qū)內(nèi)的小文件合并成大文件。但這個(gè)命令只對(duì)ORC和RCFile格式有效且合并后的文件大小不可控。更徹底的方法是重寫數(shù)據(jù)INSERT OVERWRITE TABLE table_name PARTITION (dt2024-01-01) SELECT * FROM table_name WHERE dt2024-01-01配合設(shè)置Reduce數(shù)量來控制輸出文件數(shù)量。這個(gè)操作會(huì)消耗計(jì)算資源建議在低峰期做。長(zhǎng)期方案是建立小文件監(jiān)控和定期合并機(jī)制。我通常會(huì)在ETL流程的最后加一個(gè)合并步驟用hive.merge相關(guān)參數(shù)自動(dòng)合并或者單獨(dú)跑一個(gè)合并任務(wù)。6.4 常見問題速查表問題現(xiàn)象可能原因排查方法解決方案任務(wù)卡在99%數(shù)據(jù)傾斜看Reduce任務(wù)耗時(shí)分布Map Join、加鹽、skewindataOOM內(nèi)存不足或數(shù)據(jù)傾斜看錯(cuò)誤日志和任務(wù)監(jiān)控調(diào)大內(nèi)存、優(yōu)化數(shù)據(jù)分布任務(wù)跑得慢但沒報(bào)錯(cuò)全表掃描、小文件多看執(zhí)行計(jì)劃和文件數(shù)量分區(qū)裁剪、合并小文件Reduce數(shù)量為1沒有Reduce階段或估算錯(cuò)誤看執(zhí)行計(jì)劃手動(dòng)設(shè)置Reduce數(shù)量Map Join不生效小表超過閾值看執(zhí)行計(jì)劃調(diào)大閾值或手動(dòng)MAPJOIN動(dòng)態(tài)分區(qū)報(bào)錯(cuò)分區(qū)數(shù)量超限看錯(cuò)誤信息調(diào)大max.dynamic.partitions7. 我在實(shí)際優(yōu)化中攢下的幾條硬核經(jīng)驗(yàn)優(yōu)化這件事參數(shù)是表邏輯是里。我見過太多人把參數(shù)抄來抄去結(jié)果任務(wù)該慢還是慢。真正有效的優(yōu)化一定是從理解數(shù)據(jù)和查詢模式開始的。第一條經(jīng)驗(yàn)先看數(shù)據(jù)量再看執(zhí)行計(jì)劃最后調(diào)參數(shù)。數(shù)據(jù)量決定了瓶頸在哪里執(zhí)行計(jì)劃告訴你Hive打算怎么跑參數(shù)只是微調(diào)。順序反了就是瞎調(diào)。第二條經(jīng)驗(yàn)小文件治理要常態(tài)化不要等出問題了再救火。我現(xiàn)在的習(xí)慣是任何寫入Hive的任務(wù)只要涉及動(dòng)態(tài)分區(qū)或者高頻增量寫入必須配自動(dòng)合并。這個(gè)習(xí)慣幫我省了無數(shù)次半夜爬起來處理故障的時(shí)間。第三條經(jīng)驗(yàn)數(shù)據(jù)傾斜的根因往往在業(yè)務(wù)側(cè)不在技術(shù)側(cè)。某個(gè)Key特別多可能是因?yàn)闃I(yè)務(wù)上有個(gè)大客戶或者某個(gè)字段默認(rèn)值是空導(dǎo)致大量數(shù)據(jù)涌向同一個(gè)Reduce。技術(shù)手段能緩解但根治要靠業(yè)務(wù)側(cè)的數(shù)據(jù)分布優(yōu)化。第四條經(jīng)驗(yàn)不要迷信Map Join。小表夠小才用不夠小就老老實(shí)實(shí)Common Join。強(qiáng)制Map Join導(dǎo)致OOM比Common Join慢得多。第五條經(jīng)驗(yàn)執(zhí)行引擎的選擇要看集群現(xiàn)狀不要跟風(fēng)。別人說Tez快你就換Tez結(jié)果集群沒調(diào)優(yōu)好反而更慢。先把MapReduce跑穩(wěn)再考慮升級(jí)引擎。最后分享一個(gè)我常用的優(yōu)化檢查清單每次優(yōu)化任務(wù)前過一遍分區(qū)裁剪生效了嗎列裁剪做了嗎Join方式選對(duì)了嗎Reduce數(shù)量合理嗎小文件合并了嗎數(shù)據(jù)傾斜處理了嗎內(nèi)存參數(shù)配了嗎這七個(gè)問題過完大部分性能問題都能定位到。 Hive性能優(yōu)化實(shí)戰(zhàn)：從執(zhí)行計(jì)劃到數(shù)據(jù)傾斜的全面調(diào)優(yōu)指南
1. 為什么Hive性能優(yōu)化是個(gè)繞不開的坎做數(shù)據(jù)倉庫這行的沒人能繞開Hive。不管你上層用的是Spark SQL、Flink SQL還是Trino底層存儲(chǔ)大概率還是落在HDFS上元數(shù)據(jù)還是那套Metastore表格式不是ORC就是Parquet。Hive這東西說它老也好說它慢也好但架不住它生態(tài)成熟、穩(wěn)定、便宜。問題在于很多人用Hive就是寫SQL跑數(shù)跑得慢就加資源加完還慢就罵罵咧咧換引擎。實(shí)際上大部分性能問題根本不在引擎本身而在SQL寫法、表設(shè)計(jì)、分區(qū)策略、文件布局這些地方。我見過太多團(tuán)隊(duì)一個(gè)ETL任務(wù)跑三個(gè)小時(shí)查下來就是全表掃描加笛卡爾積改完SQL直接降到八分鐘。也見過數(shù)據(jù)傾斜把整個(gè)集群拖垮最后發(fā)現(xiàn)是某個(gè)key的記錄數(shù)是其他key的幾萬倍。Hive性能優(yōu)化這件事核心不是背參數(shù)而是理解它背后的執(zhí)行模型——MapReduce也好Tez也好Spark也好底層邏輯都是分而治之你要做的是讓數(shù)據(jù)分得均勻、算得局部、傳得少。這篇文章適合誰看如果你是數(shù)據(jù)開發(fā)工程師、數(shù)倉建設(shè)者、ETL負(fù)責(zé)人或者你每天的工作就是跟Hive SQL打交道那這篇內(nèi)容就是給你寫的。我會(huì)從執(zhí)行計(jì)劃、表設(shè)計(jì)、SQL寫法、參數(shù)調(diào)優(yōu)、數(shù)據(jù)傾斜處理這幾個(gè)維度把Hive性能優(yōu)化這件事拆開揉碎講清楚。每個(gè)優(yōu)化點(diǎn)我都會(huì)說明為什么這么做有效背后的原理是什么以及在實(shí)際操作中怎么落地。不堆術(shù)語不抄文檔全是實(shí)戰(zhàn)里踩出來的經(jīng)驗(yàn)。2. 先看懂Hive到底怎么跑你的SQL2.1 從SQL到任務(wù)執(zhí)行流程拆解很多人優(yōu)化Hive就是憑感覺加參數(shù)問他為什么加這個(gè)參數(shù)答不上來。這不行。你得先知道一條Hive SQL提交之后到底經(jīng)歷了什么。一條SQL進(jìn)來Hive首先通過Antlr做詞法語法解析生成抽象語法樹AST。然后經(jīng)過語義分析綁定元數(shù)據(jù)信息比如這張表有哪些字段、分區(qū)是什么、存儲(chǔ)格式是什么。接著生成邏輯執(zhí)行計(jì)劃再經(jīng)過一系列優(yōu)化器規(guī)則——謂詞下推、列裁剪、分區(qū)裁剪、常量折疊等等——變成物理執(zhí)行計(jì)劃。最后根據(jù)你設(shè)置的執(zhí)行引擎把物理計(jì)劃翻譯成MapReduce任務(wù)、Tez DAG或者Spark Job。關(guān)鍵點(diǎn)在這里優(yōu)化器能做的事情是有限的。它只能在你寫的SQL基礎(chǔ)上做等價(jià)變換如果你寫的SQL本身就是全表掃描加笛卡爾積優(yōu)化器救不了你。所以優(yōu)化的第一原則是寫SQL的時(shí)候就要考慮執(zhí)行計(jì)劃長(zhǎng)什么樣。舉個(gè)例子你寫了一個(gè)SELECT * FROM orders WHERE dt 2024-01-01如果orders表是按dt分區(qū)的優(yōu)化器會(huì)自動(dòng)做分區(qū)裁剪只掃描對(duì)應(yīng)分區(qū)。但如果你寫的是SELECT * FROM orders WHERE substr(dt,1,4) 2024分區(qū)裁剪就失效了因?yàn)閮?yōu)化器無法從函數(shù)表達(dá)式反推分區(qū)范圍。這就是典型的“寫法決定性能”。2.2 執(zhí)行引擎的選擇邏輯Hive支持多種執(zhí)行引擎最常見的是MapReduce、Tez和Spark。很多人問選哪個(gè)我的答案從來都是看你的集群現(xiàn)狀和任務(wù)特征。MapReduce是最穩(wěn)的但也是最慢的。每個(gè)MapReduce階段都要落盤中間結(jié)果寫HDFS下一個(gè)階段再從HDFS讀。一個(gè)復(fù)雜的SQL可能被拆成五六個(gè)MapReduce任務(wù)每個(gè)任務(wù)都有啟動(dòng)開銷和IO開銷。Tez把多個(gè)MapReduce任務(wù)合并成一個(gè)DAG中間結(jié)果不落盤或者少落盤性能提升明顯。Spark基于內(nèi)存計(jì)算迭代計(jì)算場(chǎng)景優(yōu)勢(shì)大但對(duì)內(nèi)存要求高且和Hive on Spark的兼容性需要額外關(guān)注。我個(gè)人的經(jīng)驗(yàn)是如果集群資源緊張、任務(wù)以批處理為主、對(duì)穩(wěn)定性要求極高用MapReduce如果追求性能且集群有Tez優(yōu)先用Tez如果團(tuán)隊(duì)已經(jīng)有Spark生態(tài)用Spark引擎也合理。但不管用哪個(gè)引擎表設(shè)計(jì)、分區(qū)策略、文件大小這些底層的東西不變優(yōu)化邏輯是相通的。提示切換執(zhí)行引擎不是銀彈。我見過有人把MapReduce換成Tez性能沒提升反而更慢原因是小文件太多Tez的DAG啟動(dòng)開銷被放大了。引擎切換前先解決小文件問題。2.3 執(zhí)行計(jì)劃怎么看看執(zhí)行計(jì)劃是優(yōu)化的基本功。在Hive里用EXPLAIN命令在Spark SQL里用EXPLAIN EXTENDED。重點(diǎn)看幾個(gè)東西Stage的劃分、Map和Reduce的數(shù)量、是否有數(shù)據(jù)傾斜的跡象、謂詞下推有沒有生效、Join的類型是什么。比如你看到執(zhí)行計(jì)劃里某個(gè)Stage的Reduce數(shù)量是1那說明所有數(shù)據(jù)都涌向一個(gè)Reducer這幾乎必然導(dǎo)致性能瓶頸。再比如你看到Map Join沒有生效而是走了Common Join那說明小表不夠小或者參數(shù)沒配對(duì)導(dǎo)致本可以避免的Shuffle發(fā)生了。我習(xí)慣在優(yōu)化前后各跑一次EXPLAIN對(duì)比Stage數(shù)量、Operator類型、數(shù)據(jù)流向。優(yōu)化有效的標(biāo)志通常是Stage數(shù)量減少、Shuffle數(shù)據(jù)量下降、Map Join替代Common Join、分區(qū)裁剪生效。3. 表設(shè)計(jì)層面的優(yōu)化地基沒打好后面全白搭3.1 分區(qū)與分桶讓數(shù)據(jù)有跡可循分區(qū)是Hive性能優(yōu)化里性價(jià)比最高的手段沒有之一。按天分區(qū)、按業(yè)務(wù)線分區(qū)、按地區(qū)分區(qū)本質(zhì)上就是把一張大表在存儲(chǔ)層面切成小目錄。查詢的時(shí)候如果帶上分區(qū)條件Hive直接定位到對(duì)應(yīng)目錄掃描的數(shù)據(jù)量可能從TB級(jí)降到GB級(jí)。但分區(qū)不是越多越好。每個(gè)分區(qū)對(duì)應(yīng)HDFS上的一個(gè)目錄分區(qū)太多會(huì)導(dǎo)致NameNode元數(shù)據(jù)壓力大同時(shí)小文件問題會(huì)非常嚴(yán)重。我見過有人按小時(shí)分區(qū)一天24個(gè)分區(qū)一年8760個(gè)分區(qū)每個(gè)分區(qū)里就幾MB數(shù)據(jù)查詢的時(shí)候光列目錄就耗掉幾秒。合理的分區(qū)粒度通常是天或者月具體看數(shù)據(jù)量和查詢模式。分桶是在分區(qū)的基礎(chǔ)上進(jìn)一步做哈希切分。CLUSTERED BY (user_id) INTO 64 BUCKETS意思是按user_id的哈希值把數(shù)據(jù)分成64個(gè)文件。分桶的好處是Join的時(shí)候如果兩邊都按同樣的鍵分桶可以做Bucket Map Join避免Shuffle采樣的時(shí)候可以直接對(duì)桶采樣不用全表掃描。分區(qū)和分桶怎么選我的經(jīng)驗(yàn)是分區(qū)用于過濾分桶用于Join和采樣。如果你的查詢經(jīng)常按時(shí)間過濾按時(shí)間分區(qū)。如果經(jīng)常按某個(gè)維度Join考慮按那個(gè)維度分桶。兩者可以疊加使用比如先按天分區(qū)再按user_id分桶。3.2 文件格式與壓縮IO是最大的瓶頸Hive表的數(shù)據(jù)最終落在HDFS上文件格式直接決定了讀取效率。TextFile是默認(rèn)格式可讀性好但性能最差因?yàn)樗葱写鎯?chǔ)查詢一列也要讀整行而且沒有壓縮。ORC和Parquet是列式存儲(chǔ)查詢時(shí)只讀需要的列壓縮比高自帶索引性能遠(yuǎn)超TextFile。ORC和Parquet怎么選ORC對(duì)Hive的兼容性更好支持ACID事務(wù)謂詞下推更徹底Parquet在Spark生態(tài)里更常用嵌套結(jié)構(gòu)支持更好。如果你們團(tuán)隊(duì)以Hive為主選ORC如果Spark和Hive混用Parquet更穩(wěn)妥。我實(shí)測(cè)下來同樣的數(shù)據(jù)量和查詢ORC的掃描速度通常比Parquet快10%到20%但差距沒有想象中那么大。壓縮方面Snappy是折中選擇壓縮比和速度平衡Zlib壓縮比更高但解壓慢LZO速度快但壓縮比一般。對(duì)于熱數(shù)據(jù)用Snappy對(duì)于冷數(shù)據(jù)歸檔用Zlib。注意ORC和Parquet自帶壓縮不需要額外指定壓縮格式建表時(shí)指定STORED AS ORC TBLPROPERTIES (orc.compressSNAPPY)即可。3.3 小文件治理NameNode的噩夢(mèng)小文件是Hive性能的隱形殺手。每個(gè)小文件在HDFS上都是一個(gè)獨(dú)立的塊NameNode要維護(hù)每個(gè)塊的元數(shù)據(jù)。小文件多了NameNode內(nèi)存吃緊查詢時(shí)Map任務(wù)數(shù)量暴增每個(gè)Map處理一點(diǎn)點(diǎn)數(shù)據(jù)就啟動(dòng)和銷毀開銷全花在調(diào)度上了。小文件怎么來的動(dòng)態(tài)分區(qū)插入是主要來源。你開啟動(dòng)態(tài)分區(qū)一條INSERT語句寫了幾百個(gè)分區(qū)每個(gè)分區(qū)里可能就幾KB數(shù)據(jù)。另一個(gè)來源是頻繁的增量寫入每次寫一點(diǎn)攢了一堆小文件。治理小文件有幾個(gè)手段。第一在寫入端控制動(dòng)態(tài)分區(qū)插入時(shí)設(shè)置hive.merge.mapfilestrue和hive.merge.mapredfilestrue讓Hive在任務(wù)結(jié)束后自動(dòng)合并小文件。第二定期做合并任務(wù)用ALTER TABLE ... CONCATENATE或者重寫一遍數(shù)據(jù)把多個(gè)小文件合并成大文件。第三調(diào)整Reduce數(shù)量Reduce數(shù)量決定了輸出文件數(shù)量適當(dāng)減少Reduce可以避免產(chǎn)生太多小文件但要注意不要造成單文件過大。注意合并小文件是有代價(jià)的會(huì)消耗額外的計(jì)算和IO資源。建議在業(yè)務(wù)低峰期做或者用獨(dú)立的合并任務(wù)調(diào)度。4. SQL寫法優(yōu)化同樣的邏輯不同的性能4.1 Join優(yōu)化的核心邏輯Join是Hive里最耗資源的操作沒有之一。Join的性能取決于三個(gè)因素參與Join的數(shù)據(jù)量、Join的鍵、Join的方式。Hive支持多種Join方式Common JoinReduce端Join、Map Join廣播小表、Bucket Map Join分桶Join、Sort Merge Bucket Join排序合并分桶Join。默認(rèn)情況下Hive會(huì)走Common Join也就是兩邊數(shù)據(jù)都按Join鍵做Shuffle然后在Reduce端做笛卡爾積匹配。這個(gè)過程的網(wǎng)絡(luò)傳輸和磁盤IO開銷巨大。Map Join是優(yōu)化Join的第一選擇。如果有一張表足夠小可以完全加載到內(nèi)存里Hive會(huì)把它廣播到每個(gè)Map節(jié)點(diǎn)在Map端完成Join避免Shuffle。觸發(fā)Map Join的條件是小表的大小小于hive.mapjoin.smalltable.filesize默認(rèn)25MB。你可以手動(dòng)指定/* MAPJOIN(small_table) */來強(qiáng)制走M(jìn)ap Join。但Map Join不是萬能的。如果小表其實(shí)不小廣播到每個(gè)節(jié)點(diǎn)會(huì)消耗大量?jī)?nèi)存和網(wǎng)絡(luò)帶寬反而拖慢任務(wù)。我見過有人強(qiáng)制Map Join一張500MB的表結(jié)果每個(gè)Map容器都OOM。判斷標(biāo)準(zhǔn)很簡(jiǎn)單小表大小乘以Map數(shù)量如果超過集群內(nèi)存總量的一定比例就不要用Map Join。Bucket Map Join和Sort Merge Bucket Join是更高級(jí)的優(yōu)化。如果兩張表都按Join鍵分桶且桶的數(shù)量成倍數(shù)關(guān)系可以做Bucket Map Join每個(gè)Map只處理對(duì)應(yīng)的桶避免全表Shuffle。Sort Merge Bucket Join要求兩邊都按Join鍵分桶且排序性能更好但建表要求更高。4.2 數(shù)據(jù)傾斜的識(shí)別與處理數(shù)據(jù)傾斜是Hive性能問題里最讓人頭疼的?，F(xiàn)象很簡(jiǎn)單大部分Reduce任務(wù)很快跑完少數(shù)幾個(gè)Reduce任務(wù)跑得極慢甚至卡在99%不動(dòng)。原因也簡(jiǎn)單某個(gè)Join鍵或者Group By鍵的數(shù)據(jù)量遠(yuǎn)超其他鍵導(dǎo)致處理這個(gè)鍵的Reduce任務(wù)負(fù)載過重。識(shí)別數(shù)據(jù)傾斜的方法看任務(wù)監(jiān)控如果Reduce階段有個(gè)別任務(wù)耗時(shí)是其他的幾倍甚至幾十倍基本可以確定是傾斜?；蛘吲芤粋€(gè)SELECT key, COUNT(*) FROM table GROUP BY key ORDER BY COUNT(*) DESC LIMIT 10看看最大key的計(jì)數(shù)是不是遠(yuǎn)超平均值。處理數(shù)據(jù)傾斜有幾種思路。第一種Map Join如果傾斜是因?yàn)樾”鞪oin大表把小表廣播出去在Map端完成Join傾斜自然消失。第二種加鹽打散給傾斜的鍵加上隨機(jī)前綴讓數(shù)據(jù)分散到多個(gè)Reduce然后再去掉前綴做二次聚合。第三種單獨(dú)處理傾斜鍵把傾斜的鍵單獨(dú)拎出來處理剩下的數(shù)據(jù)正常Join最后Union回去。第四種調(diào)整Reduce數(shù)量增加Reduce數(shù)量可以緩解傾斜但不能根治因?yàn)閮A斜鍵的數(shù)據(jù)量沒變只是分到了更多Reduce上單個(gè)Reduce的壓力可能還是大。我個(gè)人的經(jīng)驗(yàn)是優(yōu)先用Map Join不行就加鹽加鹽解決不了就單獨(dú)處理。加鹽的代價(jià)是SQL變復(fù)雜需要寫兩段邏輯再合并但效果通常很好。4.3 窗口函數(shù)與Group By的取舍窗口函數(shù)和Group By都能做聚合但性能特征不同。Group By會(huì)把數(shù)據(jù)按Key做Shuffle然后在Reduce端聚合輸出結(jié)果行數(shù)等于Key的數(shù)量。窗口函數(shù)不減少行數(shù)它在每行上計(jì)算一個(gè)聚合值但需要把數(shù)據(jù)按分區(qū)鍵排序排序開銷大。如果只需要聚合結(jié)果用Group By。如果需要在明細(xì)行上附加聚合信息用窗口函數(shù)。但要注意窗口函數(shù)的PARTITION BY鍵如果數(shù)據(jù)傾斜同樣會(huì)導(dǎo)致性能問題。而且窗口函數(shù)默認(rèn)會(huì)把整個(gè)分區(qū)的數(shù)據(jù)加載到內(nèi)存排序分區(qū)太大可能OOM。一個(gè)常見的優(yōu)化技巧是先用Group By做預(yù)聚合再用窗口函數(shù)。比如你要計(jì)算每個(gè)用戶的累計(jì)消費(fèi)可以先按用戶和日期Group By算出每日消費(fèi)再用窗口函數(shù)做累計(jì)這樣窗口函數(shù)處理的數(shù)據(jù)量小很多。4.4 謂詞下推與列裁剪的實(shí)戰(zhàn)細(xì)節(jié)謂詞下推是指把過濾條件下推到數(shù)據(jù)掃描階段盡量早地過濾掉不需要的數(shù)據(jù)。列裁剪是指只讀取查詢中用到的列不讀整行。這兩個(gè)優(yōu)化在列式存儲(chǔ)格式ORC、Parquet上效果特別明顯。但謂詞下推有失效的場(chǎng)景。如果過濾條件寫在子查詢里且子查詢有LIMIT或者窗口函數(shù)謂詞下推可能不生效。比如SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM t) tmp WHERE rn 10這個(gè)rn的過濾條件無法下推到掃描階段因?yàn)閞n是計(jì)算出來的。這種情況下Hive會(huì)先掃描全表計(jì)算ROW_NUMBER再過濾性能很差。列裁剪的注意事項(xiàng)是**避免使用SELECT ***。SELECT *會(huì)讀取所有列即使你只需要其中幾列。在寬表場(chǎng)景下這個(gè)差距可能是幾倍的IO。養(yǎng)成習(xí)慣需要什么列就寫什么列。5. 參數(shù)調(diào)優(yōu)讓Hive跑得更順滑5.1 Map與Reduce數(shù)量的控制Map數(shù)量由輸入文件的分片大小決定。mapreduce.input.fileinputformat.split.maxsize控制每個(gè)Map處理的最大數(shù)據(jù)量默認(rèn)等于HDFS塊大小通常128MB或256MB。如果小文件多可以調(diào)小這個(gè)值讓每個(gè)Map處理更少數(shù)據(jù)但Map數(shù)量會(huì)增多。如果文件大且少可以調(diào)大這個(gè)值減少M(fèi)ap數(shù)量。Reduce數(shù)量默認(rèn)由Hive根據(jù)輸入數(shù)據(jù)量估算但估算經(jīng)常不準(zhǔn)。hive.exec.reducers.bytes.per.reducer控制每個(gè)Reduce處理的數(shù)據(jù)量默認(rèn)256MB。hive.exec.reducers.max控制Reduce數(shù)量上限。你可以手動(dòng)指定Reduce數(shù)量SET mapred.reduce.tasks 100。Reduce數(shù)量不是越多越好。Reduce太多會(huì)導(dǎo)致每個(gè)Reduce處理的數(shù)據(jù)量很小啟動(dòng)和關(guān)閉開銷占比高Reduce太少會(huì)導(dǎo)致單個(gè)Reduce處理的數(shù)據(jù)量大容易傾斜和OOM。我的經(jīng)驗(yàn)值是每個(gè)Reduce處理128MB到256MB數(shù)據(jù)比較合適。你可以根據(jù)輸入數(shù)據(jù)總量除以這個(gè)值來估算Reduce數(shù)量。5.2 內(nèi)存與并行度參數(shù)Hive任務(wù)的內(nèi)存分為Map內(nèi)存和Reduce內(nèi)存。mapreduce.map.memory.mb和mapreduce.reduce.memory.mb控制容器內(nèi)存大小。mapreduce.map.java.opts和mapreduce.reduce.java.opts控制JVM堆大小通常設(shè)置為容器內(nèi)存的80%左右。如果任務(wù)報(bào)OOM先看是Map OOM還是Reduce OOM。Map OOM通常是Map Join的小表太大或者單個(gè)Map處理的數(shù)據(jù)量太大。Reduce OOM通常是數(shù)據(jù)傾斜導(dǎo)致單個(gè)Reduce處理的數(shù)據(jù)量過大或者聚合操作的內(nèi)存占用超限。調(diào)大內(nèi)存能解決一部分問題但根本解決要靠?jī)?yōu)化數(shù)據(jù)分布。并行度方面hive.exec.paralleltrue可以讓沒有依賴的Stage并行執(zhí)行hive.exec.parallel.thread.number控制并行線程數(shù)。這個(gè)參數(shù)在復(fù)雜SQL里效果明顯但要注意集群資源是否足夠并行度太高會(huì)互相搶資源。5.3 動(dòng)態(tài)分區(qū)與嚴(yán)格模式動(dòng)態(tài)分區(qū)插入是ETL里的常用操作但默認(rèn)配置下性能很差。hive.exec.dynamic.partition.mode默認(rèn)是strict要求至少有一個(gè)靜態(tài)分區(qū)。hive.exec.max.dynamic.partitions和hive.exec.max.dynamic.partitions.pernode控制動(dòng)態(tài)分區(qū)的最大數(shù)量默認(rèn)值偏小容易報(bào)錯(cuò)。開啟動(dòng)態(tài)分區(qū)后每個(gè)Map和Reduce都會(huì)為每個(gè)分區(qū)創(chuàng)建一個(gè)文件如果分區(qū)數(shù)量多小文件問題會(huì)很嚴(yán)重。建議開啟動(dòng)態(tài)分區(qū)的同時(shí)設(shè)置hive.merge.mapfiles和hive.merge.mapredfiles為true讓Hive在任務(wù)結(jié)束后自動(dòng)合并小文件。另外hive.exec.dynamic.partition要設(shè)為true否則動(dòng)態(tài)分區(qū)不生效。這些參數(shù)看起來瑣碎但配錯(cuò)一個(gè)就可能導(dǎo)致任務(wù)失敗或者性能驟降。6. 常見問題與排查技巧實(shí)錄6.1 任務(wù)卡在99%不動(dòng)的排查思路這是最經(jīng)典的問題。任務(wù)跑到99%然后卡住幾十分鐘甚至幾個(gè)小時(shí)。原因幾乎總是數(shù)據(jù)傾斜某個(gè)Reduce任務(wù)處理的數(shù)據(jù)量遠(yuǎn)超其他任務(wù)其他任務(wù)早就跑完了它還在慢慢磨。排查步驟第一看任務(wù)監(jiān)控找到那個(gè)卡住的Reduce任務(wù)看它的輸入數(shù)據(jù)量。第二跑一個(gè)Group By統(tǒng)計(jì)找出計(jì)數(shù)最大的Key。第三確認(rèn)這個(gè)Key是不是業(yè)務(wù)上的熱點(diǎn)比如某個(gè)大客戶、某個(gè)默認(rèn)值、某個(gè)空值。解決方案如果是Join導(dǎo)致的傾斜嘗試Map Join或者加鹽。如果是Group By導(dǎo)致的傾斜可以設(shè)置hive.groupby.skewindatatrueHive會(huì)自動(dòng)做兩階段聚合先加隨機(jī)前綴分散數(shù)據(jù)再去掉前綴聚合。這個(gè)參數(shù)對(duì)Group By傾斜有奇效但會(huì)增加一輪Shuffle。6.2 OOM錯(cuò)誤的定位與解決OOM分兩種JVM堆內(nèi)存溢出和物理內(nèi)存溢出。JVM堆內(nèi)存溢出會(huì)報(bào)java.lang.OutOfMemoryError: Java heap space物理內(nèi)存溢出會(huì)被YARN殺掉報(bào)Container killed by YARN for exceeding memory limits。JVM堆內(nèi)存溢出通常是Map Join的小表太大或者聚合操作的HashMap太大。解決方法是調(diào)大mapreduce.map.java.opts和mapreduce.reduce.java.opts或者放棄Map Join改用Common Join。物理內(nèi)存溢出通常是JVM堆外內(nèi)存使用過多比如ORC讀取時(shí)的緩沖區(qū)、網(wǎng)絡(luò)傳輸?shù)木彌_區(qū)。解決方法是調(diào)大容器內(nèi)存mapreduce.map.memory.mb和mapreduce.reduce.memory.mb同時(shí)確保JVM堆大小不超過容器內(nèi)存的80%。提示調(diào)大內(nèi)存不是萬能藥。如果數(shù)據(jù)傾斜嚴(yán)重單個(gè)Reduce處理的數(shù)據(jù)量是其他Reduce的幾十倍調(diào)大內(nèi)存只能延緩OOM不能根治。還是要從數(shù)據(jù)分布入手。6.3 小文件問題的應(yīng)急處理如果發(fā)現(xiàn)表目錄下小文件太多查詢性能急劇下降可以應(yīng)急做一次合并。用ALTER TABLE table_name PARTITION (dt2024-01-01) CONCATENATE可以把分區(qū)內(nèi)的小文件合并成大文件。但這個(gè)命令只對(duì)ORC和RCFile格式有效且合并后的文件大小不可控。更徹底的方法是重寫數(shù)據(jù)INSERT OVERWRITE TABLE table_name PARTITION (dt2024-01-01) SELECT * FROM table_name WHERE dt2024-01-01配合設(shè)置Reduce數(shù)量來控制輸出文件數(shù)量。這個(gè)操作會(huì)消耗計(jì)算資源建議在低峰期做。長(zhǎng)期方案是建立小文件監(jiān)控和定期合并機(jī)制。我通常會(huì)在ETL流程的最后加一個(gè)合并步驟用hive.merge相關(guān)參數(shù)自動(dòng)合并或者單獨(dú)跑一個(gè)合并任務(wù)。6.4 常見問題速查表問題現(xiàn)象可能原因排查方法解決方案任務(wù)卡在99%數(shù)據(jù)傾斜看Reduce任務(wù)耗時(shí)分布Map Join、加鹽、skewindataOOM內(nèi)存不足或數(shù)據(jù)傾斜看錯(cuò)誤日志和任務(wù)監(jiān)控調(diào)大內(nèi)存、優(yōu)化數(shù)據(jù)分布任務(wù)跑得慢但沒報(bào)錯(cuò)全表掃描、小文件多看執(zhí)行計(jì)劃和文件數(shù)量分區(qū)裁剪、合并小文件Reduce數(shù)量為1沒有Reduce階段或估算錯(cuò)誤看執(zhí)行計(jì)劃手動(dòng)設(shè)置Reduce數(shù)量Map Join不生效小表超過閾值看執(zhí)行計(jì)劃調(diào)大閾值或手動(dòng)MAPJOIN動(dòng)態(tài)分區(qū)報(bào)錯(cuò)分區(qū)數(shù)量超限看錯(cuò)誤信息調(diào)大max.dynamic.partitions7. 我在實(shí)際優(yōu)化中攢下的幾條硬核經(jīng)驗(yàn)優(yōu)化這件事參數(shù)是表邏輯是里。我見過太多人把參數(shù)抄來抄去結(jié)果任務(wù)該慢還是慢。真正有效的優(yōu)化一定是從理解數(shù)據(jù)和查詢模式開始的。第一條經(jīng)驗(yàn)先看數(shù)據(jù)量再看執(zhí)行計(jì)劃最后調(diào)參數(shù)。數(shù)據(jù)量決定了瓶頸在哪里執(zhí)行計(jì)劃告訴你Hive打算怎么跑參數(shù)只是微調(diào)。順序反了就是瞎調(diào)。第二條經(jīng)驗(yàn)小文件治理要常態(tài)化不要等出問題了再救火。我現(xiàn)在的習(xí)慣是任何寫入Hive的任務(wù)只要涉及動(dòng)態(tài)分區(qū)或者高頻增量寫入必須配自動(dòng)合并。這個(gè)習(xí)慣幫我省了無數(shù)次半夜爬起來處理故障的時(shí)間。第三條經(jīng)驗(yàn)數(shù)據(jù)傾斜的根因往往在業(yè)務(wù)側(cè)不在技術(shù)側(cè)。某個(gè)Key特別多可能是因?yàn)闃I(yè)務(wù)上有個(gè)大客戶或者某個(gè)字段默認(rèn)值是空導(dǎo)致大量數(shù)據(jù)涌向同一個(gè)Reduce。技術(shù)手段能緩解但根治要靠業(yè)務(wù)側(cè)的數(shù)據(jù)分布優(yōu)化。第四條經(jīng)驗(yàn)不要迷信Map Join。小表夠小才用不夠小就老老實(shí)實(shí)Common Join。強(qiáng)制Map Join導(dǎo)致OOM比Common Join慢得多。第五條經(jīng)驗(yàn)執(zhí)行引擎的選擇要看集群現(xiàn)狀不要跟風(fēng)。別人說Tez快你就換Tez結(jié)果集群沒調(diào)優(yōu)好反而更慢。先把MapReduce跑穩(wěn)再考慮升級(jí)引擎。最后分享一個(gè)我常用的優(yōu)化檢查清單每次優(yōu)化任務(wù)前過一遍分區(qū)裁剪生效了嗎列裁剪做了嗎Join方式選對(duì)了嗎Reduce數(shù)量合理嗎小文件合并了嗎數(shù)據(jù)傾斜處理了嗎內(nèi)存參數(shù)配了嗎這七個(gè)問題過完大部分性能問題都能定位到。