0.7版本後hive開始支援任務執行選擇本地模式(local mode)。
大多數的hadoop job是需要hadoop提供的完整的可擴充套件性來處理大資料的。不過，有時hive的輸入資料量是非常小的。在這種情況下，為查詢出發執行任務的時間消耗可能會比實際job的執行時間要多的多。對於大多數這種情況，hive可以通過本地模式在單台機器上處理所有的任務。對於小資料集，執行時間會明顯被縮短。
如此一來，對資料量比較小的操作，就可以在本地執行，這樣要比提交任務到集群執行效率要快很多。
配置如下引數，可以開啟hive的本地模式：
set hive.exec.mode.local.auto=true;(預設為false)
當乙個job滿足如下條件才能真正使用本地模式：
limit語句經常會使用，不過，一般情況下，limit語句還是需要執行整個查詢語句，然後再返回部分結果。有乙個配置屬性可以開啟，避免這種情況：對資料來源進行抽樣。
hive.limit.optimize.enable=true --- 開啟對資料來源進行取樣的功能
hive.limit.row.
max.size --
- 設定最小的取樣容量
hive.limit.optimize.limit.
file
--- 設定最大的取樣樣本數
缺點：有可能部分資料永遠不會被處理到
hive假定查詢中最後的乙個表是大表。它會將其它表快取起來，然後掃瞄最後那個表。
因此通常需要將小表放前面。
當對3個或者更多個表進行join連線時，如果每個on子句都使用相同的連線鍵的話，那麼只會產生乙個mapreduce job。
減少每個階段的資料量,對於分割槽表要加分割槽，同時只選擇需要使用到的字段。
盡量避免乙個sql包含複雜邏輯，可以使用中間表來完成複雜的邏輯。
hive會將乙個查詢轉化為乙個或多個階段，包括：mapreduce階段、抽樣階段、合併階段、limit階段等。預設情況下，一次只執行乙個階段。 不過，如果某些階段不是互相依賴，是可以並行執行的。
set hive.exec.parallel=true,可以開啟併發執行。
set hive.exec.parallel.thread.number
=16; //同乙個sql允許最大並行度，預設為8。
會比較耗系統資源。
表現：任務進度長時間維持在99%（或100%），檢視任務監控頁面，發現只有少量（1個或幾個）reduce子任務未完成。因為其處理的資料量和其他reduce差異過大。
單一reduce的記錄數與平均記錄數差異過大，通常可能達到3倍甚至更多。 最長時長遠大於平均時長。
原因情形
後果join
其中乙個表較小，但是key集中
分發到某乙個或幾個reduce上的資料遠高於平均值
join
大表與大表，但是分桶的判斷欄位0值或空值過多
這些空值都由乙個reduce處理，非常慢
group by
group by 維度過小，某值的數量過多
處理某值的reduce非常耗時
count distinct
某特殊值過多
處理此特殊值reduce耗時
解決方案：
引數調節
hive.map.aggr=true
Hive查詢優化
害，最近組裡有個妹子不是很懂sql，一查就等好長時間，看的我十分揪心，算了，寫幾個常見的hive查詢優化叭。1.條目少的表或者子查詢放在join左邊，因為join左邊會讀入記憶體 select a.val b.val from a 條目少 join b on a.key b.key 2.join 操...
Hive查詢優化
1.先過濾,再查詢,因為每次生成中間表都會儲存到linux磁碟上 記住 不是hdfs 2.注意資料傾斜 傾斜的原因是reduce端資料的大量富集,可適度增加reduce 會著開啟 reduce自己判斷 某一比較大 自己再分開點.也就是合理設定 reduce數量 hive.exec.reducers....
hive查詢優化總結
hive查詢優化總結 儲存，學習，分享 join查詢操作的基本原則 應該將條目少的表 子查詢放在 join 操作符的左邊。原因是在 join 操作的 reduce 階段，位於 join 操作符左邊的表的內容會被載入進記憶體，將條目少的表放在左邊，可以有效減少發生記憶體溢位錯誤的機率。join查詢操作...