HiveServer2

這是一個服務端接口，可以使用遠程客戶端執(zhí)行對hive的查詢，并返回結果。

Hive的調優(yōu)策略

作為大數(shù)據(jù)領域的數(shù)據(jù)倉庫組件，在設計和開發(fā)的時候，都需要注意效率。這個時候調優(yōu)就顯得很重要了。數(shù)據(jù)傾斜、數(shù)據(jù)冗余、job或者I/O過多、MapReduce分配不合理都會導致hive的效率降低。

而如何對hive進行調優(yōu)呢？其實主要就是架構優(yōu)化，參數(shù)優(yōu)化和SQL優(yōu)化。

那我們一個一個來看吧，首先是架構優(yōu)化。

架構優(yōu)化

執(zhí)行引擎

既然是架構，那么先從核心引擎來看，hive本身呢是支持多種引擎的，MapReduce、TeZ、spark、flink。都是hive可以支持的引擎。這些在hivesite.xml中的hive.execution.engine來控制。

相對來說Tez是一個比較好的選擇，可以拆分MapReduce的過程，減少文件的儲存，提高性能。

優(yōu)化器

這點就和sql很像，在執(zhí)行計算之前，生成和優(yōu)化邏輯執(zhí)行計劃與物理執(zhí)行計劃。hive有兩種優(yōu)化器。

其一是向量優(yōu)化器，就是執(zhí)行變成一批1024行，而不是一行一行來執(zhí)行。這樣就縮短了時間，但是缺陷不明。。。并且數(shù)據(jù)儲存必須用ORC格式。

其二就是成本優(yōu)化器。。。具體不詳。。。

除了優(yōu)化器，還有的就是我們之前就知道的分區(qū)表和分桶表了，通過切割數(shù)據(jù)來降低時耗。

其實做到這一步了，基本也調優(yōu)的差不多了，在架構上如果想繼續(xù)優(yōu)化，就得改變數(shù)據(jù)的儲存格式了，畢竟這就要犧牲掉一些信息了。

文件格式里面最簡單的就是TextFile（純文本儲存格式），不過我想一般應該走不到這步吧。

最后還不行，就只能對數(shù)據(jù)進行壓縮了，減少map和reduce間的數(shù)據(jù)傳輸，從而提升性能。

參數(shù)優(yōu)化

本地模式

前面討論的都是hive處理的數(shù)據(jù)量較大時的調優(yōu)，當然了，hive大多時應該都是處理大數(shù)據(jù)集的。那么當數(shù)據(jù)集小的時候，hive用分布式去處理其實是有些牛刀殺雞了，因為分布式啟動的時間甚至都比數(shù)據(jù)處理的時間要長，這個時候就需要將hive轉至本地模式（前面提到過）了。

嚴格模式

聽起來好像還挺厲害的，本質就是禁止三種有風險的語句，第一就是查詢時不限定分區(qū)；第二是join時的重復；第三是order by排序后不使用limit來限制。說實話感覺效果就那樣。

SQL優(yōu)化

列裁剪和分區(qū)裁剪

簡單理解就是查詢的時候只取需要的列和分區(qū)，多余的碰都不碰。將節(jié)儉進行到底

sort by 代替 order by

就是排序方法的一個替換，個人覺得加個limit就可以了，不必這么大費周章吧。

group by代替count

這個count的確得謹慎使用，不過大哥你group by也沒好到哪去吧，數(shù)據(jù)傾斜你group by比count還惡心。

明天寫個優(yōu)化的實戰(zhàn)吧，待我先看一看