如何讓Hive運行更快

這篇文章給大家分享的是有關如何讓Hive運行更快的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

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就很差了。

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。

感謝各位的閱讀！關于“如何讓Hive運行更快”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！