Hive語句執行優化簡化UDF執行過程

hive會將執行的sql語句翻譯成對應mapreduce任務，當sql語句比較簡單時，效能還是可能處於可接受的範圍。但是如果涉及到非常複雜的業務邏輯，特別是通過程式的方式（一些模版語言生成）生成大量判斷語句時，出現的問題就會比較多。

當前專案中如果打包的數量過多，是當前效能的最大瓶頸，在做sql優化時，至少會存在乙個這樣的sql，當打包數量上百甚至到1千後，就會產生大量的 if/or 語句：

if((
( true == true and caid==2002158 and rcode in (12) and spid in('6ro6w') and (dateid >= 20141225 and dateid <= 20141227)) ),'package_0','') package_0,
if((
( true == true and caid==2002158 and rcode in (20) and spid in('6ro6x') and (dateid >= 20141225 and dateid <= 20141227)) ),'package_1','') package_1,
if((
( true == true and caid==2002158 and rcode in (124) and spid in('6ro6y') and (dateid >= 20141225 and dateid <= 20141227)) ),'package_2','') package_2,
if((
( true == true and caid==2002158 and rcode in (33) and spid in('6ro6z') and (dateid >= 20141225 and dateid <= 20141227)) ),'package_3','') package_3,
if((
( true == true and caid==2002158 and rcode in (126) and spid in('6ro70') and (dateid >= 20141225 and dateid <= 20141227)) ),'package_4','') package_4,

此時，執行的效率會非常低，目測在過千萬級的日誌量時，往往會執行天資料量級的耗時。在當前reducer階段中執行時的堆疊：

通過定時的取樣，發現在map過程中大部分的時間消耗在這種if/or呼叫。

最終考慮將其優化成乙個udf，這樣sql就可以不用重寫成多個了，經過測試發現優化效果非常好，同時只需指定兩個外部檔案即可。

split_package(caid, rcode, spid, dateid, "./524_1_1", "./region-000000000000000000000008-top100") package_list

此時，應該在sql中事先將其通過add file的方式加入資源，才能正常使用：

add file ./region-000000000000000000000008-top100;
add file ./524_1_1;

我們通過這種方式，成功地將sql語句縮短，並將執行時間由原來的1天縮減至5小時內，解決了當前發現的最大瓶頸。

對於其他可能導致sql過長的問題，同樣都採用該方式統一解決。

此外，由於資料中的每一行中都會呼叫到udf，因此對於udf函式中演算法的一小步改進，都能夠對整體效率起到很大的提公升。

此外，hive在提交任務時，會啟動乙個本地的jvm來對當前執行的sql進行解析，如果sql的長度過長時，也是乙個非常耗時的過程。比如乙個非常極端的例子，在我們的伺服器上，有一次執行了2w行的sql，解析時間居然消耗了50分鐘左右！因此，減少sql行數是必須可少的步驟，同時也需要保證提交任務的伺服器有一定的資源，否則在提交任務時過於耗時。

上個步驟只不過是優化的第乙個步驟，後續會繼續針對性能問題進行進一步的優化，因為我們當前的系統距離產品的要求還是有一定的差距的，優化無止境……

Hive語句執行優化簡化UDF執行過程

Shell指令碼執行Hive語句

Hive執行SQL語句報錯

hive優化及執行命令

Hive語句執行優化 簡化UDF執行過程

Shell指令碼執行Hive語句

Hive執行SQL語句報錯

hive優化及執行命令

相關推薦

Hive語句執行優化簡化UDF執行過程