一種Hive效能調優方法（補充）

之前學習整理過一些hive調優的方法，最近在學習參考書的時候看到作者提供了乙個hive調優的解決方案，在這裡分享下。

案例所使用的資料**於美國航班資料、機場資料和天氣資料。用來查詢要查詢航班延誤（時間超過15分鐘）次數最多的5個機場，其出發機場的風速都超過1公尺/秒。

第乙個調優方向：執行引擎

hive目前支援3中執行引擎，每種引擎都有各自的優缺點。這裡將比較一下mapreduce執行引擎和tez執行引擎的效能。

1）mapreduce：

mapreduce支援引擎以傳統的mapreduce作業方式來執行hive查詢。它是最初的執行引擎，如果你的查詢不能用其他執行引擎來執行，它將是最安全的後備選項。通過將hive.execution.engine屬性的值設定為mr，就可以選擇該執行引擎。使用mapreduce執行查詢花費了475.732s（在作者的實驗裝置環境下），並且在查詢過程中將711mb的中間資料寫入磁碟。

2）tez

通過減少操作和限制寫入磁碟的中間資料量，apache tez可以提供比mapreduce執行引擎更高效的處理。tez避免來了不必要的hdfs寫入操作。

通過將hive.execution.engine的值設定為tex，並且更改兩個屬性，hive.prewarm.enabled=true和hive.prewarm.numcontainers=10，結果如下。

僅僅更改執行引擎就可以是執行時間減少309秒，接近65%。

第二個調優方向：儲存格式

有些檔案格式專門針對hive使用進行了優化，包括orc檔案和parquet，這裡來講一下orc檔案。

orc格式是一種基於列的儲存格式，這意味著，它並不是按照單個資料行連續將全部資料儲存在磁碟上，而是按每列連續儲存資料。這樣針對那些不包含某些列的查詢，就可以避免不必要的磁碟訪問，可以跳過那些在結果中不需要的大部分資料。orc格式是一種可分割的檔案格式，這意味著乙個檔案可以被分割成多個可並行處理的塊。每個資料塊被進一步細分為256mb的資料帶，而這些資料帶則用於將列資料儲存在一起。任何不需要特定列值的查詢都可以「跳過」這個資料帶。

為了度量orc的效能影響，需要首先建立原始表的兩個副本，它們將以orc格式儲存。結果如下：

使用orc合適儲存導致執行時間減少了100秒，即減少了超過60%。

第三個調優方向：向量化查詢執行

hive預設的查詢執行引擎一次處理一行，因此在巢狀迴圈中需要有多層虛擬方法呼叫，從cpu的視角來看這是非常低效的。向量化查詢執行是一種hive特性，其目的是按照每批1024行讀取資料，並且一次性對整個記錄集合（而不是對單條記錄）應用操作，進而消除那些效率低下的問題。而要使用向量化查詢執行，就必須以orc格式儲存資料。

向量化查詢執行需要先將hive.vertorized.execution.enabled屬性的值設定為true，並且針對有orc支援的表執行查詢。

相對於僅使用tez和orc來說，向量化執行導致執行時間縮短了12秒。

第四個調優方向：查詢執行計畫

這裡來講講基於代價的優化。

基於代價的優化(cbo)引擎利用了hive metastore的統計資料來產生最優的查詢計畫。用於優化的統計資訊有兩種型別：一種是表統計資訊，包括表的未壓縮大小、行數和用於儲存資料的檔案數；另一種是列統計資訊，其中包括ndv（唯一值的個數）和最小值/最大值/計數值。

cbo進行了連續重排序，改進了針對星型連線模式和濃密連線模式的計畫，並提供了基於樣本查詢的改進機會。

通過設定hive.stats.autogather為true，就可以進行自動化表統計資訊的全域性收集了。

一旦計算出統計資訊，就可以通過在hive內設定以下屬性來啟用cbo，這樣我們執行的每個查詢都可使用基於代價的優化引擎。

cbo引擎將執行時間進一步縮短了4秒，即7%，帶來了最終優化結果。

此外，cbo還可以產生最佳的順序，如下所示：

總體來說可以通過使用tez、orc儲存格式、向量化查詢執行和cbo引擎等技術來減少涉及兩個達標的單個查詢的執行時間，可以從475秒縮短到49秒以下。最重要的是，只需少量工作就可以將大多數技術都應用到現有的大多數hive表中。

本文的材料和語言來自於斯科特.肖的《hive實戰》，由唐富年老師翻譯。

有興趣的夥伴可以去翻看一下原文，自我感覺和《hive程式設計指南》一塊學習效果更好。

互勉~~~

一種Hive效能調優方法（補充）

hive效能調優

Hive效能調優

Hive實戰效能調優

一種Hive效能調優方法（補充）

hive效能調優

Hive效能調優

Hive實戰效能調優

相關推薦