Hive是Hadoop的子專案，它提供了對資料的結構化管理和類SQL語言的查詢功能。SQL的互動方式極大程度地降低了Hadoop生態環境中資料處理的門檻，使用者不需要編寫程式，通過SQL語句就可以對資料進行分析和處理。目前很多計算需求都可以由Hive來完成，極大程度地降低了開發成本。

目前，Hive底層使用MapReduce作為實際計算框架，SQL的互動方式隱藏了大部分MapReduce的細節。這種細節的隱藏在帶來便利性的同時，也對計算作業的調優帶來了一定的難度。未經優化的SQL語句轉化後的MapReduce作業，它的執行效率可能大大低於使用者的預期。本文我們就來分析一個簡單語句的優化過程。

日常統計場景中，我們經常會對一段時期內的欄位進行消重並統計數量，SQL語句類似於

SELECT COUNT( DISTINCT id ) FROM TABLE_NAME WHERE ...;

這條語句是從一個表的符合WHERE條件的記錄中統計不重複的id的總數。

該語句轉化為MapReduce作業後執行示意圖如下，圖中還列出了我們實驗作業中Reduce階段的資料規模：

由於引入了DISTINCT，因此在Map階段無法利用combine對輸出結果消重，必須將id作為Key輸出，在Reduce階段再對來自於不同Map Task、相同Key的結果進行消重，計入最終統計值。
我們看到作業執行時的Reduce Task個數為1，對於統計大資料量時，這會導致最終Map的全部輸出由單個的ReduceTask處理。這唯一的Reduce Task需要Shuffle大量的資料，並且進行排序聚合等處理，這使得它成為整個作業的IO和運算瓶頸。
經過上述分析後，我們嘗試顯式地增大Reduce Task個數來提高Reduce階段的併發，使每一個Reduce Task的資料處理量控制在2G左右。具體設定如下：

set mapred.reduce.tasks=100

調整後我們發現這一引數並沒有影響實際Reduce Task個數，Hive執行時輸出“Number of reduce tasks determined at compile time: 1”。原來Hive在處理COUNT這種“全聚合(full aggregates)”計算時，它會忽略使用者指定的Reduce Task數，而強制使用1。我們只能採用變通的方法來繞過這一限制。我們利用Hive對巢狀語句的支援，將原來一個MapReduce作業轉換為兩個作業，在第一階段選出全部的非重複id，在第二階段再對這些已消重的id進行計數。這樣在第一階段我們可以通過增大Reduce的併發數，併發處理Map輸出。在第二階段，由於id已經消重，因此COUNT(*)操作在Map階段不需要輸出原id資料，只輸出一個合併後的計數即可。這樣即使第二階段Hive強制指定一個Reduce Task，極少量的Map輸出資料也不會使單一的Reduce Task成為瓶頸。改進後的SQL語句如下：

SELECT COUNT(*) FROM (SELECT DISTINCT id FROM TABLE_NAME WHERE … ) t;

實際執行時，我們發現Hive還對這兩階段的作業做了額外的優化。它將第二個MapReduce作業Map中的Count過程移到了第一個作業的Reduce階段。這樣在第一階Reduce就可以輸出計數值，而不是消重的全部id。這一優化大幅地減少了第一個作業的Reduce輸出IO以及第二個作業Map的輸入資料量。最終在同樣的執行環境下優化後的語句執行只需要原語句20%左右的時間。優化後的MapReduce作業流如下：

從上述優化過程我們可以看出，一個簡單的統計需求，如果不理解Hive和MapReduce的工作原理，它可能會比優化後的執行過程多四、五倍的時間。我們在利用Hive簡化開發的同時，也要儘可能優化SQL語句，提升計算作業的執行效率。

注：文中測試環境Hive版本為0.9