在過去幾年中渣淤，主要受到圍繞Stinger計劃的Hive社區(qū)創(chuàng)新的推動，Hive查詢時間得到了顯著改善捻撑，使Hive能夠以速度和規(guī)模支持批量和交互式工作負(fù)載磨隘。
但是，許多使用者仍然不熟悉以最快速度運行Hive查詢的基本技術(shù)和最佳實踐顾患。本文中番捂，將重點介紹一些常使用的簡單技術(shù)，以提高HIVE查詢的性能江解。
技術(shù)#1：使用TEZ
Hive可以使用Apache Tez執(zhí)行引擎而不是Map-reduce引擎设预。不會詳細(xì)介紹這里提到的使用Tez的許多好處; 相反，提出一個簡單的建議：如果在您的環(huán)境中默認(rèn)情況下沒有打開它犁河，請在Hive查詢的開頭使用Tez設(shè)置為“true”
set hive.execution.engine=tez;
技術(shù)#2：使用ORCFILE
Hive支持ORCfile鳖枕，這是一種新的表存儲格式，通過謂詞下推桨螺，壓縮等技術(shù)實現(xiàn)極佳的速度提升耕魄。
對每個HIVE表使用ORCFile應(yīng)該是一個明智的選擇，對于獲得HIVE查詢的快速響應(yīng)時間非常有益彭谁。
作為一個例子，考慮兩個大表A和B（存儲為文本文件允扇，這里沒有指定一些列）缠局，以及一個簡單的查詢 :
SELECT A.customerID, A.name, A.age, A.address join
B.role, B.department, B.salary
ON A.customerID=B.customerID;
此查詢可能需要很長時間才能執(zhí)行则奥，因為表A和B都存儲為TEXT。將這些表轉(zhuǎn)換為ORCFile格式通常會顯著縮短查詢時間：
CREATE TABLE A_ORC (
customerID int, name string, age int, address string
) STORED AS ORC tblproperties (“orc.compress" = “SNAPPY”);
INSERT INTO TABLE A_ORC SELECT * FROM A;
ORC支持壓縮存儲（使用ZLIB或如上所示使用SNAPPY）狭园，但也支持未壓縮存儲读处。
將基表轉(zhuǎn)換為ORC通常是取決于所在團(tuán)隊獲取數(shù)據(jù)的職責(zé)，由于其他優(yōu)先級唱矛，可能需要一些時間來更改完整的獲取數(shù)據(jù)過程罚舱。ORCFile的好處是如此明顯，以至于推薦如上所示的自助式方法 - 將A轉(zhuǎn)換為A_ORC绎谦，將B轉(zhuǎn)換為B_ORC并以此方式進(jìn)行連接管闷，以便立即從更快的查詢中受益，而不依賴于其他團(tuán)隊窃肠。
技術(shù)#3：VECTORIZATION
矢量化查詢執(zhí)行通過一次批量執(zhí)行1024行而不是每行一行來提高掃描包个，聚合，過濾器和連接等操作的性能冤留。
這個功能在Hive 0.13中引入，顯著縮短了查詢執(zhí)行時間，并且可以通過兩個參數(shù)設(shè)置輕松啟用：
set hive.vectorized.execution.enabled = true;
set hive.vectorized.execution.reduce.enabled = true;
技術(shù)#4：查詢優(yōu)化
在提交最終執(zhí)行之前吧雹，Hive會優(yōu)化每個查詢的邏輯和物理執(zhí)行計劃峭状。這些優(yōu)化不是基于查詢的成本 - 也就是說，直到運行時泊窘。
最近添加到Hive熄驼，基于成本的優(yōu)化，基于查詢成本執(zhí)行進(jìn)一步優(yōu)化州既，從而導(dǎo)致可能不同的決策：如何訂購聯(lián)接谜洽，執(zhí)行哪種類型的聯(lián)接，并行度等吴叶。
要使用基于成本的優(yōu)化（也稱為CBO）阐虚，請在查詢開頭設(shè)置以下參數(shù)
set hive.cbo.enable=true;
set hive.compute.query.using.stats=true;
set hive.stats.fetch.column.stats=true;
set hive.stats.fetch.partition.stats=true;
然后，通過運行Hive的“analyze”命令為CBO準(zhǔn)備數(shù)據(jù)蚌卤，以收集我們想要使用CBO的表的各種統(tǒng)計信息实束。
例如，在tweet數(shù)據(jù)表中逊彭，希望收集有關(guān)該表的統(tǒng)計信息以及大約2列：“sender”和“topic”：
analyze table tweets compute statistics;
analyze table tweets compute statistics for columns sender, topic;
使用HIVE 0.14（在HDP 2.2上）咸灿，analyze命令的工作速度要快得多，而且您不需要指定每一列侮叮，因此只需如下：
analyze table tweets compute statistics for columns;
現(xiàn)在使用此表執(zhí)行查詢應(yīng)該會導(dǎo)致不同的執(zhí)行計劃由于成本計算和Hive創(chuàng)建的不同執(zhí)行計劃而更快避矢。
技術(shù)#5：編寫良好的SQL
SQL是一種強大的聲明性語言。與其他聲明性語言一樣，編寫SQL語句的方法不止一種审胸。盡管每個語句的功能都相同亥宿，但它可能具有截然不同的性能特征
CREATE TABLE clicks (
timestamp date, sessionID string, url string, source_ip string
) STORED as ORC tblproperties (“orc.compress” = “SNAPPY”);
每條記錄代表一次點擊事件，希望找到每個sessionID的最新網(wǎng)址砂沛。
有人使用如下方式：
SELECT clicks.* FROM
clicks inner join
( select sessionID, max(timestamp) as max_ts from clicks
group by sessionID
) latest
ON clicks.sessionID = latest.sessionID AND clicks.timestamp = latest.max_ts;
在上面的查詢中烫扼，構(gòu)建一個子查詢來收集每個會話中最新事件的時間戳，然后使用內(nèi)部聯(lián)接來過濾掉其余的事件碍庵。
雖然查詢是一個合理的解決方案 - 從功能的角度來看 - 事實證明映企，有一種更好的方法來重寫這個查詢，如下所示
SELECT * FROM
( SELECT *,
RANK() over (partition by sessionID,order by timestamp desc) as rank
FROM clicks
) ranked_clicks
WHERE ranked_clicks.rank=1;
在這里静浴，使用Hive的OLAP功能（OVER和RANK）來實現(xiàn)相同的功能堰氓，但沒有使用表連接。
顯然马绝，刪除不必要的連接幾乎總能帶來更好的性能豆赏，而且當(dāng)使用大數(shù)據(jù)時，這比以往任何時候都更重要富稻。在很多情況下查詢不是最優(yōu)的 - 所以仔細(xì)查看每個查詢并考慮重寫是否可以使它更好更快掷邦。
