Hive作為SQL on Hadoop最穩(wěn)定田炭、應(yīng)用最廣泛的查詢引擎被大家所熟知通惫。但是由于基于MapReduce鼻忠，查詢執(zhí)行速度太慢而逐步引入其他的近實時查詢引擎如Presto等。值得關(guān)注的是Hive目前支持MapReduce凳兵、Tez和Spark三種執(zhí)行引擎百新，同時Hive3也會支持聯(lián)邦數(shù)據(jù)查詢的功能。所以Hive還是有很大進步的空間的庐扫。
當(dāng)然吟孙，諸如SparkSQL和Presto有著他們非常合適的應(yīng)用場景澜倦，我們的底層也是會有多種查詢引擎存在，以應(yīng)對不同業(yè)務(wù)場景的數(shù)據(jù)查詢服務(wù)杰妓。但是由于查詢引擎過多也會導(dǎo)致用戶使用體驗不好藻治，需要用戶掌握多種查詢引擎，而且要明確知道各個引擎的適用場景巷挥。而且多種SQL引擎各自提供服務(wù)會對數(shù)據(jù)倉庫建設(shè)過程中的血緣管理桩卵、權(quán)限管理、資源利用都帶來較大的困難倍宾。
之前對于底層平臺的統(tǒng)一SQL服務(wù)有考慮過在上層提供一層接口封裝雏节，進行SQL校驗、血緣管理高职、引擎推薦钩乍、查詢分發(fā)等等，但是各個引擎之間的語法差異較大怔锌，想要實現(xiàn)兼容的SQL層有點不太現(xiàn)實寥粹。最近看了快手分享的《SQL on Hadoop 在快手大數(shù)據(jù)平臺的實踐與優(yōu)化》，覺得有那么點意思埃元。大家有興趣的話可以看一看涝涤。
其實快手的實現(xiàn)核心邏輯是一樣的，有一個統(tǒng)一的SQL入口岛杀，提供SQL校驗阔拳，SQL存儲、引擎推薦类嗤、查詢分發(fā)進而實現(xiàn)血緣管理等糊肠。優(yōu)秀的是它基于Hive完成了上述工作，將Hive作為統(tǒng)一的入口而不是重新包裝一層遗锣。既利用了HiveServer2的架構(gòu)货裹，又做到了對于用戶的感知最小。而實現(xiàn)這些功能的基礎(chǔ)就是Hive Hooks黄伊，也就是本篇的重點。
Hook是一種在處理過程中攔截事件派殷，消息或函數(shù)調(diào)用的機制还最。Hive hooks是綁定到了Hive內(nèi)部的工作機制，無需重新編譯Hive毡惜。所以Hive Hook提供了使用hive擴展和集成外部功能的能力拓轻。我們可以通過Hive Hooks在查詢處理的各個步驟中運行/注入一些代碼，幫助我們實現(xiàn)想要實現(xiàn)的功能经伙。
根據(jù)鉤子的類型扶叉，它可以在查詢處理期間的不同點調(diào)用：
Pre-semantic-analyzer hooks：在Hive在查詢字符串上運行語義分析器之前調(diào)用勿锅。
Post-semantic-analyzer hooks：在Hive在查詢字符串上運行語義分析器之后調(diào)用。
Pre-driver-run hooks：在driver執(zhí)行查詢之前調(diào)用枣氧。
Post-driver-run hooks：在driver執(zhí)行查詢之后調(diào)用溢十。
Pre-execution hooks：在執(zhí)行引擎執(zhí)行查詢之前調(diào)用。請注意达吞，這個目的是此時已經(jīng)為Hive準(zhǔn)備了一個優(yōu)化的查詢計劃张弛。
Post-execution hooks：在查詢執(zhí)行完成之后以及將結(jié)果返回給用戶之前調(diào)用。
Failure-execution hooks：當(dāng)查詢執(zhí)行失敗時調(diào)用酪劫。
由以上的Hive Hooks我們都可以得出Hive SQL執(zhí)行的生命周期了吞鸭，而Hive Hooks則完整的貫穿了Hive查詢的整個生命周期。
對于Hive Hooks有了初步理解之后覆糟，后面我們會通過示例介紹如何實現(xiàn)一個Hive Hook刻剥，并且嘗試一下如何基于Hive實現(xiàn)統(tǒng)一的SQL查詢服務(wù)。
