hive可以讓你在hadoop上使用sql，但是在分布系統上的sql的調優是不同的。這裡有12個技巧能夠幫助你。
hive并不是一個關系型資料庫，但它假裝是大部分情況中的一個。它有表格，運作sql，并且支援jdbc和odbc。
這個啟示有利及不利的消息：hive不運作查詢資料庫方式。這是一個很長的故事，但是我在工作周花了80多個小時親自調整hive。不用說，我不必再頭疼了。是以，為了您的利益，這裡有一些建議，讓你的hive項目比我的運作的快一點。
1、不要使用mapreduce
你是否相信tez,spark或者impala,但是不相信mapreduce。它是緩慢的，它比hive還要慢。如果你在hortonwork的分布，你可以在腳本的頂部輸入 set hive.execution.engine=tez
在子句中使用impala.希望當你的impala不再合适的時候設定 hive.execution.engine=spark
2、不要在sql字元串配對
注意，尤其是在hive，如果你在本該是子句的地方配對字元串，會産生一個交叉的産品警告。如果你有一個幾秒内運作的查詢，與需要幾分鐘才能配對的字元串。你最好選擇使用多個工具，允許你添加搜尋hadoop。檢視elasticsearch’s hiveintegration or lucidwork’s integration for solr。或者，哪裡有cloudera search. rdbmses 非常善于做這個，但是hive就很差了。
apache hive拟人畫
3、不要加入一個子查詢
你最好建立一個臨時清單，然後加入臨時表不詢問hive如何智能的處理子查詢。也就是說不要這麼做。
而是要這麼樣做
在這一點上，它真的不應該在hive的進化上如此之快，但是它通常是這樣的。
4、使用parquet或者orc，但是不要把它們轉化成運動
這就是說，相對用parquet或者orc，例如，textfile。然而，如果你有文本資料進來，并且促進它變的更結構化，轉換到目标表。你不能從文本檔案加載資料到一個orc，是以做初始加載到文本。
如果你建立其他的表，你最終會運作不到你的分析。在那裡做orcing，因為轉換到orc或者parquet需要時間，并且不值得進行你的etl過程的第一步。如果你有簡單的平面檔案進來，并且不做任何調整。然後你被加載到一個臨時表，并且選擇建立一個orc或者parquet。我不嫉妒你因為它真的很慢。
5、嘗試把矢量化打開或者關閉
增加
在你的腳本的頂端。嘗試讓它們開或關，因為矢量化在hive的新版本中似乎有一些問題。
6、不要用結構加入
我不得不承認我原本的大腦的sql文法依然是sql-92時代，是以我無論如何不傾向于使用結構。但是如果你做一些像對複合pks子句超重複的事情，結構是友善的。不幸的是，hive隔斷了它們——尤其是在子句上，當然，在較小的資料集并沒有這麼做，也沒有産生任何錯誤的時間。在絕對禁區，你得到一個有趣的向量誤差。這個限制是沒有記錄任何我所知道的地方。把這個看成是一個有序的方式來了解你的執行引擎的内部結構!
7、檢查容器的尺寸
你可能需要為impala或者tez增加你容器的尺寸。此外，”建議”尺寸可能不适用于您的系統，如果你有較大的節點尺寸。你可能要確定你的yarn隊列和一般的yarn記憶是恰當的。你可能還想把它釘在一個東西上，這個東西不是所有人都使用的預設隊列。
8、啟動統計
hive的确有點愚蠢的東西加入，除非資料啟動起來。你可能還想在impala使用查詢提示。
9、考慮mapjoin優化
如果你對查詢做了解釋，你可能會發現最近hive的版本足夠聰明到去自動應用優化的。但是你需要去調整他們。
10、如果可以，把最大的表放在最後
11、區分你的朋友……額……
如果你在許多子句的地方有一個項目，如一個日期(但是并不是一個理想的範圍)或者重複的位置，您可能有您的區分鍵!分區的基本意思是”分裂成為它自己的目錄，”這意味着不是在尋找一個大的檔案，hive檢視一個檔案，因為你用你的join/where從句讓你隻看location=’nc’,這是你的一個小資料集。此外，與列值不同，您可以在負載資料報表中推分區。但是，請記住，hdfs不喜歡小的文檔。
12、使用哈希表列的比較
如果你在每個查詢中比較相同的10個字段，考慮使用()對比總結。這些有時是非常有用的，你可能會把它們放在一個輸出表中。注意hive0.12是低分辨率的，但是更好的可以使用的值在0.13。
本文作者：andrew c. oliver
來源：51cto