一、小文件合并優化
Hive中的小文件分為Map端的小文件和Reduce端的小文件。
(1)、Map端的小文件優化是通過CombineHiveInputFormat操作。相關的參數是:
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;
(2)、Reduce端的小文件合并
Map端的小文件合并是為了將小文件合并成一個切片,然后使用一個MR任務來執行這個切片。而Reduce端的小文件合并是為了將多個小文件合并成為一個大文件。
其原理是根據計算任務輸出的文件的平均大小進行判斷,若符合條件,就會單獨的啟動一個額外的任務進行合并。
相關的參數:
--------------開啟合并map only任務輸出的小文件-----------
set hive.merge.mapfiles=true;
--------------開啟合并map reduce任務輸出的小文件-----------
set hive.merge.mapredfiles=true;
------觸發小文件合并的閾值,若某個計算任務輸出的文件平均大小低于該閾值,就會觸發合并-----
set hive.merge.smallfiles.avgsize=16000000;
------合并后的文件大小------------
set hive.merge.size.per.task=256000000;
二、CBO優化
CBO全稱就是Cost based Optimizer,即基于計算成本的優化。在Hive中,計算成本受到數據的行數、CPU個數、本地IO、HDFS IO、網絡IO等方面的影響,Hive會計算同一個SQL語句各個執行計劃的計算成本,然后選擇出計算成本最低的執行計劃來執行。目前CBO在Hive的MR引擎下主要用于join的優化。例如多表join時的join順序。
相關參數為:
--------是否啟用cbo優化--------
set hive.cbo.enable=true;
三、謂詞下推優化
謂詞下推是指盡量的將過濾操作前移,以減少后續計算步驟中的數據量。
相關的參數是:
---------是否開啟謂詞下推優化--------------
set hive.optimize.ppd=true;
其實,在CBO優化中也會完成一部分的謂詞下推操作,因為經過謂詞下推以后的執行計劃的計算成本往往會更低一些。
四、矢量化計算優化
Hive的矢量化計算依賴于CPU的矢量計算操作。他可以使原有的標量計算轉化為矢量化計算,提高查詢和計算的效率。
在標量計算中,每一條加法計算就會產生一條指令,但是如果這一批計算都是加法計算,就可以先對這批數據矢量化,然后對矢量化后的數據用一次加法指令就可以了,這樣就可以提高計算的效率。實現方式如圖:
相關的參數設置為:
set hive.vectorized.execution.enable=true;
五、Fetch抓取優化
Fetch抓取優化的出現是因為有些情況下的查詢其實不用走MapReduce,只需要簡單的讀取一下文件,將其中的結果讀取出來就可以了。例如select * from emp;
默認情況下是開啟這個參數的。相關參數是:
set hive.fetch.task.conversion=more;默認值就是more。none表示不開啟,還有一個參數是minimal,但是用的很少,要是開啟就直接用more就行了。
六、本地模式優化
當Hive的數據輸入量較小的時候,觸發任務執行的時間可能都比實際任務執行的時間長,這時就可以設置本地模式,在本地執行任務就可以了。對于小數據集來說,執行時間可以被明顯的縮短。
七、并行執行優化
并行執行就是說一條SQL語句其實是分為了多個Stage來執行的,多個Stage之間可能有依賴關系,也可能會沒有依賴關系,對于沒有依賴關系的Stage,我們可以讓他們并行的執行,這就是并行執行的優化目的。因為在默認情況下,不論Stage之間有沒有依賴關系,他都只會一個個的執行Stage。
相關參數設置:
---啟用并行執行優化
set hive.exec.parallel=true;
---同一個SQL語句的最大執行并行度,默認為8
set hive.exec.parallel.thread.number=8;
八、嚴格模式
Hive會嚴格的禁止一些危險的操作,這些危險的操作有:
(1)、分區表不使用分區字段過濾。不使用分區字段就代表著要操作的數據范圍是整個表,這對于分區表的操作是十分危險的,因為整張表的數據量非常的巨大,對整張表的操作可能會占用巨大的資源。
(2)、使用order by沒有使用limit過濾。order by也是一樣,他會是對全表的數據進行排序,這也是十分危險的情況,一般在學習階段因為數據量少不會注意這個要加上limit,但是在實際的生產環境下,數據量就是十分龐大,必須要加上limit才能夠被允許執行。
(3)、笛卡爾積。也是十分消耗資源的一種操作。例如A表有1萬條數據,B表有100條數據,進行笛卡爾積之后就會有100萬條數據,造成了數據嚴重膨脹,所以一般情況下也要嚴格禁止這種操作的執行。