---

Hive作為大數據平臺舉足輕重的框架，以其穩定性和簡單易用性也成為當前構建企業級數據倉庫時使用最多的框架之一。

但是如果我們只局限于會使用Hive，而不考慮性能問題，就難搭建出一個完美的數倉，所以Hive性能調優是我們大數據從業者必須掌握的技能。本文將給大家講解Hive參數與性能調優的一些方法及技巧。

1. Limit 限制調整

一般情況下，limit語句還是需要執行整個查詢語句，然后再返回部分結果。

有一個配置屬性可以開啟，避免這種情況：對數據源進行抽樣。

hive.limit.optimize.enable=true -- 開啟對數據源進行采樣的功能

hive.limit.row.max.size -- 設置最小的采樣容量

hive.limit.optimize.limit.file -- 設置最大的采樣樣本數

缺點：有可能部分數據永遠不會被處理到

2. JOIN優化

1. 使用相同的連接鍵

當對3個或者更多個表進行join連接時，如果每個on子句都使用相同的連接鍵的話，那么只會產生一個MapReduce job。

2. 盡量盡早地過濾數據

減少每個階段的數據量,對于分區表要加分區，同時只選擇需要使用到的字段。

3. 盡量原子化操作

盡量避免一個SQL包含復雜邏輯，可以使用中間表來完成復雜的邏輯。

3. 小文件優化

1) 小文件過多產生的影響

首先對底層存儲HDFS來說，HDFS本身就不適合存儲大量小文件，小文件過多會導致namenode元數據特別大, 占用太多內存，嚴重影響HDFS的性能

對 Hive 來說，在進行查詢時，每個小文件都會當成一個塊，啟動一個Map任務來完成，而一個Map任務啟動和初始化的時間遠遠大于邏輯處理的時間，就會造成很大的資源浪費。而且，同時可執行的Map數量是受限的。

2) 怎么解決小文件過多

1. 使用 hive 自帶的 concatenate 命令，自動合并小文件

使用方法：

#對于非分區表 alter?table?A?concatenate;#對于分區表 alter?table?B?partition(day=20201224)?concatenate;

注意：
1、concatenate 命令只支持 RCFILE 和 ORC 文件類型。
2、使用concatenate命令合并小文件時不能指定合并后的文件數量，但可以多次執行該命令。
3、當多次使用concatenate后文件數量不在變化，這個跟參數 mapreduce.input.fileinputformat.split.minsize=256mb 的設置有關，可設定每個文件的最小size。

2. 調整參數減少Map數量

設置map輸入合并小文件的相關參數：

#執行Map前進行小文件合并 #CombineHiveInputFormat底層是?Hadoop的?CombineFileInputFormat?方法 #此方法是在mapper中將多個文件合成一個split作為輸入 set?hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;?--?默認#每個Map最大輸入大小(這個值決定了合并后文件的數量) set?mapred.max.split.size=256000000;???--?256M#一個節點上split的至少的大小(這個值決定了多個DataNode上的文件是否需要合并) set?mapred.min.split.size.per.node=100000000;??--?100M#一個交換機下split的至少的大小(這個值決定了多個交換機上的文件是否需要合并) set?mapred.min.split.size.per.rack=100000000;??--?100M

設置map輸出和reduce輸出進行合并的相關參數:

#設置map端輸出進行合并，默認為true set?hive.merge.mapfiles?=?true;#設置reduce端輸出進行合并，默認為false set?hive.merge.mapredfiles?=?true;#設置合并文件的大小 set?hive.merge.size.per.task?=?256*1000*1000;???--?256M#當輸出文件的平均大小小于該值時，啟動一個獨立的MapReduce任務進行文件merge set?hive.merge.smallfiles.avgsize=16000000;???--?16M

啟用壓縮:

#?hive的查詢結果輸出是否進行壓縮 set?hive.exec.compress.output=true;#?MapReduce?Job的結果輸出是否使用壓縮 set?mapreduce.output.fileoutputformat.compress=true;

3. 減少Reduce的數量

#reduce?的個數決定了輸出的文件的個數，所以可以調整reduce的個數控制hive表的文件數量， #hive中的分區函數?distribute?by?正好是控制MR中partition分區的， #然后通過設置reduce的數量，結合分區函數讓數據均衡的進入每個reduce即可。#設置reduce的數量有兩種方式，第一種是直接設置reduce個數 set?mapreduce.job.reduces=10;#第二種是設置每個reduce的大小，Hive會根據數據總大小猜測確定一個reduce個數 set?hive.exec.reducers.bytes.per.reducer=5120000000;?--?默認是1G，設置為5G#執行以下語句，將數據均衡的分配到reduce中 set?mapreduce.job.reduces=10; insert?overwrite?table?A?partition(dt) select?*?from?B distribute?by?rand();解釋：如設置reduce數量為10，則使用 rand()，?隨機生成一個數 x % 10?， 這樣數據就會隨機進入?reduce?中，防止出現有的文件過大或過小

4. 使用hadoop的archive將小文件歸檔

Hadoop Archive簡稱HAR，是一個高效地將小文件放入HDFS塊中的文件存檔工具，它能夠將多個小文件打包成一個HAR文件，這樣在減少namenode內存使用的同時，仍然允許對文件進行透明的訪問

#用來控制歸檔是否可用 set?hive.archive.enabled=true; #通知Hive在創建歸檔時是否可以設置父目錄 set?hive.archive.har.parentdir.settable=true; #控制需要歸檔文件的大小 set?har.partfile.size=1099511627776;#使用以下命令進行歸檔 ALTER?TABLE?A?ARCHIVE?PARTITION(dt='2022-02-24',?hr='12');#對已歸檔的分區恢復為原文件 ALTER?TABLE?A?UNARCHIVE?PARTITION(dt='2022-02-24',?hr='12');

注意:

歸檔的分區可以查看不能 insert overwrite，必須先 unarchive

4. 本地模式

有時hive的輸入數據量是非常小的。在這種情況下，為查詢出發執行任務的時間消耗可能會比實際job的執行時間要多的多。對于大多數這種情況，hive可以通過本地模式在單臺機器上處理所有的任務。對于小數據集，執行時間會明顯被縮短。

set hive.exec.mode.local.auto=true;

當一個job滿足如下條件才能真正使用本地模式：

job的輸入數據大小必須小于參數：hive.exec.mode.local.auto.inputbytes.max (默認128MB)

job的map數必須小于參數：hive.exec.mode.local.auto.tasks.max (默認4)

job的reduce數必須為0或者1

可用參數 hive.mapred.local.mem (默認0)控制child jvm使用的最大內存數。

5. strict模式

開啟嚴格模式對分區表進行查詢，在where子句中沒有加分區過濾的話，將禁止提交任務(默認：nonstrict)

set hive.mapred.mode=strict 開啟嚴格模式

注：使用嚴格模式可以禁止以下三種類型的查詢：

1. 對分區表的查詢必須使用到分區相關的字段

分區表的數據量通常都比較大，對分區表的查詢必須使用到分區相關的字段，不允許掃描所有分區，想想也是如果掃描所有分區的話那么對表進行分區還有什么意義呢。

當然某些特殊情況可能還是需要掃描所有分區，這個時候就需要記得確保嚴格模式被關閉。

2. order by必須帶limit

因為要保證全局有序需要將所有的數據拉到一個Reducer上，當數據集比較大時速度會很慢。個人猜測可能是設置了limit N之后就會有一個很簡單的優化算法：每個Reducer排序取N然后再合并排序取N即可，可大大減少數據傳輸量。

3. 禁止笛卡爾積查詢（join必須有on連接條件）

Hive不會對where中的連接條件優化為on，所以join必須帶有on連接條件，不允許兩個表直接相乘。

6. 并行執行優化

Hive會將一個查詢轉化成一個或者多個階段。這樣的階段可以是MapReduce階段、抽樣階段、合并階段、limit階段。或者Hive執行過程中可能需要的其他階段。默認情況下，Hive一次只會執行一個階段。不過，某個特定的job可能包含眾多的階段，而這些階段可能并非完全互相依賴的，也就是說有些階段是可以并行執行的，這樣可能使得整個job的執行時間縮短。如果有更多的階段可以并行執行，那么job可能就越快完成。

通過設置參數hive.exec.parallel值為true，就可以開啟并發執行。在共享集群中，需要注意下，如果job中并行階段增多，那么集群利用率就會增加。

set?hive.exec.parallel=true;?//打開任務并行執行 set?hive.exec.parallel.thread.number=16;?//同一個sql允許最大并行度，默認為8。

當然得是在系統資源比較空閑的時候才有優勢，否則沒資源，并行也起不來。

7. JVM優化

JVM重用是Hadoop調優參數的內容，其對Hive的性能具有非常大的影響，特別是對于很難避免小文件的場景或task特別多的場景，這類場景大多數執行時間都很短。

Hadoop的默認配置通常是使用派生JVM來執行map和Reduce任務的。這時JVM的啟動過程可能會造成相當大的開銷，尤其是執行的job包含有成百上千task任務的情況。JVM重用可以使得JVM實例在同一個job中重新使用N次。N的值可以在Hadoop的mapred-site.xml文件中進行配置。通常在10-20之間，具體多少需要根據具體業務場景測試得出。

<property><name>mapreduce.job.jvm.numtasks</name><value>10</value><description>How?many?tasks?to?run?per?jvm.?If?set?to?-1,?there?isno?limit.?</description> </property>

我們也可以在Hive中設置：

set mapred.job.reuse.jvm.num.tasks=10 設置jvm重用

這個功能的缺點是，開啟JVM重用將一直占用使用到的task插槽，以便進行重用，直到任務完成后才能釋放。如果某個“不平衡的”job中有某幾個reduce task執行的時間要比其他Reduce task消耗的時間多的多的話，那么保留的插槽就會一直空閑著卻無法被其他的job使用，直到所有的task都結束了才會釋放。

8. 推測執行優化

在分布式集群環境下，因為程序bug（包括Hadoop本身的bug），負載不均衡或者資源分布不均等原因，會造成同一個作業的多個任務之間運行速度不一致，有些任務的運行速度可能明顯慢于其他任務（比如一個作業的某個任務進度只有50%，而其他所有任務已經運行完畢），則這些任務會拖慢作業的整體執行進度。為了避免這種情況發生，Hadoop采用了推測執行（Speculative Execution）機制，它根據一定的法則推測出“拖后腿”的任務，并為這樣的任務啟動一個備份任務，讓該任務與原始任務同時處理同一份數據，并最終選用最先成功運行完成任務的計算結果作為最終結果。

設置開啟推測執行參數：Hadoop的mapred-site.xml文件中進行配置：

<property><name>mapreduce.map.speculative</name><value>true</value><description>If?true,?then?multiple?instances?of?some?map?tasks?may?be?executed?in?parallel.</description> </property><property><name>mapreduce.reduce.speculative</name><value>true</value><description>If?true,?then?multiple?instances?of?some?reduce?tasks?may?be?executed?in?parallel.</description> </property>

Hive本身也提供了配置項來控制reduce-side的推測執行:

set hive.mapred.reduce.tasks.speculative.execution=true

關于調優這些推測執行變量，還很難給一個具體的建議。如果用戶因為輸入數據量很大而需要執行長時間的map或者reduce task的話，那么啟動推測執行造成的浪費是非常巨大的。

9. 數據傾斜優化

數據傾斜的原理都知道，就是某一個或幾個key占據了整個數據的90%，這樣整個任務的效率都會被這個key的處理拖慢，同時也可能會因為相同的key會聚合到一起造成內存溢出。

Hive的數據傾斜一般的處理方案：

常見的做法，通過參數調優：

set?hive.map.aggr=true;?? set?hive.groupby.skewindata?=?ture;

當選項設定為true時，生成的查詢計劃有兩個MapReduce任務。

在第一個MapReduce中，map的輸出結果集合會隨機分布到reduce中，每個reduce做部分聚合操作，并輸出結果。

這樣處理的結果是，相同的Group By Key有可能分發到不同的reduce中，從而達到負載均衡的目的；

第二個MapReduce任務再根據預處理的數據結果按照Group By Key分布到reduce中（這個過程可以保證相同的Group By Key分布到同一個reduce中），最后完成最終的聚合操作。

但是這個處理方案對于我們來說是個黑盒，無法把控。

那么在日常需求的情況下如何處理這種數據傾斜的情況呢：

sample采樣，獲取哪些集中的key；

將集中的key按照一定規則添加隨機數；

進行join，由于打散了，所以數據傾斜避免了；

在處理結果中對之前的添加的隨機數進行切分，變成原始的數據。

10. 動態分區調整

動態分區屬性：設置為true表示開啟動態分區功能（默認為false）

hive.exec.dynamic.partition=true;

動態分區屬性：設置為nonstrict,表示允許所有分區都是動態的（默認為strict） 設置為strict，表示必須保證至少有一個分區是靜態的

hive.exec.dynamic.partition.mode=strict;

動態分區屬性：每個mapper或reducer可以創建的最大動態分區個數

hive.exec.max.dynamic.partitions.pernode=100;

動態分區屬性：一個動態分區創建語句可以創建的最大動態分區個數

hive.exec.max.dynamic.partitions=1000;

動態分區屬性：全局可以創建的最大文件個數

hive.exec.max.created.files=100000;

11. 其他參數調優

開啟CLI提示符前打印出當前所在的數據庫名

set hive.cli.print.current.db=true;

讓CLI打印出字段名稱

hive.cli.print.header=true;

設置任務名稱，方便查找監控

set mapred.job.name=P_DWA_D_IA_S_USER_PROD;

決定是否可以在 Map 端進行聚合操作

set hive.map.aggr=true;

有數據傾斜的時候進行負載均衡

set hive.groupby.skewindata=true;

對于簡單的不需要聚合的類似SELECT col from table LIMIT n語句，不需要起MapReduce job，直接通過Fetch task獲取數據

set hive.fetch.task.conversion=more;

最后

代碼優化原則：

理透需求原則，這是優化的根本；
把握數據全鏈路原則，這是優化的脈絡；
堅持代碼的簡潔原則，這讓優化更加簡單；
沒有瓶頸時談論優化，這是自尋煩惱。

·················END·················

總結

以上是生活随笔為你收集整理的如何优化Hive SQL ？？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。