Apache Hive是由Facebook開源的數(shù)據(jù)倉庫系統(tǒng)，提供SQL查詢能力，快手基于Hive搭建數(shù)據(jù)倉庫，隨著業(yè)務迅速發(fā)展和數(shù)據(jù)規(guī)模增長，Hive的性能開始成為瓶頸，無法滿足業(yè)務需求。

Hive把用戶SQL通過解釋器轉(zhuǎn)換為一系列MR作業(yè)提交到hadoop環(huán)境中運行，MR存在作業(yè)啟動、調(diào)度開銷大、落盤多磁盤IO重的問題，這導致其性能注定無法太好，針對Hive查詢速度慢的問題，業(yè)界先后推出了包括presto/impala/spark等查詢引擎，在實現(xiàn)和適用場景上各有優(yōu)缺點。

在計算引擎層面我們所面臨的幾個挑戰(zhàn)是：

• 高性能：業(yè)務要求更高的查詢性能，需要引入更高效的計算引擎

• 易用性：由于不同引擎在語法以及適用場景上各有優(yōu)缺點，對于業(yè)務來說存在學習和使用門檻，需要通過技術手段來降低或者消除這種門檻

• 擴展性：技術是發(fā)展非?？斓?，未來隨著技術發(fā)展可能還會有其他更高效的引擎不斷出現(xiàn)，我們在架構設計上需要能夠考慮到很好地擴展性支持這些新的計算引擎，需要做到計算引擎的可插拔、易擴展

• 低成本：圍繞Hive我們構建了大量周邊工具及服務，包括資源管理、血緣管理、權限控制等各個方面。如果每引入一個引擎都再各自開發(fā)一套周邊工具及服務的建設會是一個非常昂貴的事，所以這一塊需要做到低成本接入

基于上述考慮，我們最終基于HiveServer本身的Hook架構，實現(xiàn)一個BeaconServer。所有的查詢?nèi)匀灰訦iveServer作為統(tǒng)一入口，從而解決易用性和低成本的問題。

BeaconServer作為后端Hook Server服務，配合HS2中的Hook，在HS2 服務之外實現(xiàn)了所需的功能，包括根據(jù)一定規(guī)則路由SQL到適當?shù)囊?，從而起到查詢加速的效果。當前支持的模塊包括路由、審計、SQL 重寫、錯誤分析、優(yōu)化建議等。

BeaconServer本身是一個無狀態(tài)服務，我們可以很方便進行水平擴容，并且BeaconServer服務調(diào)整升級不影響HiveServer服務本身。

基于上述架構，我們很好的應對了前面所提到的四大挑戰(zhàn)，引入了更高效的計算引擎，在業(yè)務無感知的前提下大幅提升了查詢效率。

這里特別提一下，除了引入presto、spark等高效計算引擎并對齊進行優(yōu)化之外，我們針對Hive本身的FetchTask機制（本地讀取hdfs文件返回結(jié)果，不存在作業(yè)提交開銷）也進行了系列改進，使其適用場景更廣，查詢效率更高，在日常查詢中也占了很大比重。

02

Hive MetaStore在快手的挑戰(zhàn)

在介紹完我們智能引擎架構之后，接下來進入今天重點的主題Hive MetaStore在快手的挑戰(zhàn)。

首先，我們基于整體服務架構簡單說明一下Hive MetaStore服務的作用以及其重要性：Hive Metastore是hive用來管理元數(shù)據(jù)的服務，包含database、table、partition等元信息，presto/spark也都以Hive Metastore作為統(tǒng)一的元數(shù)據(jù)中心。

除了計算引擎本身，數(shù)據(jù)血緣、數(shù)據(jù)地圖、數(shù)據(jù)依賴等上層服務也重度依賴Hive Metatstore。

接下來介紹一下Hive MetaStore服務當前所面臨的挑戰(zhàn)。

由于快手業(yè)務使用場景需要大面積使用動態(tài)分區(qū)，同時數(shù)據(jù)量和查詢量也在隨著業(yè)務快速增長，這對Hive MetaStore服務的性能和穩(wěn)定性帶來挑戰(zhàn)：

• 訪問量非常大，目前每天查詢量是50萬+，此外數(shù)據(jù)地圖、數(shù)據(jù)依賴服務也會直接調(diào)用Hive MetaStore服務API

• 動態(tài)分區(qū)大量使用，很多業(yè)務還需要采用多級動態(tài)分區(qū)，單表一天的子分區(qū)數(shù)可能上萬，部分頭部表的總分區(qū)數(shù)達到數(shù)百萬規(guī)模

• Hive表總分區(qū)達到1.5億，由于多級分區(qū)的存在，元數(shù)據(jù)庫中存儲分區(qū)信息的單表記錄已超過10億

• 最后就是分區(qū)增速快，當前單日新增分區(qū)數(shù)近50萬

03

Hive MetaStore在快手的優(yōu)化

針對上述問題，我們考慮從幾個方面進行優(yōu)化：

首先，訪問量多的問題，在大數(shù)據(jù)場景下，存在寫少讀多的特定，對于元數(shù)據(jù)主庫，當前壓力也主要來自于大量的讀操作導致QPS過高，因此第一個優(yōu)化方向是通過讀寫分離來降低主庫壓力；

其次，在HIVE的元數(shù)據(jù)查詢上，存在大量的多表聯(lián)合查詢，尤其存儲分區(qū)信息的兩個大表（PARTITONS和PARTITION_KEY_VALS）之間的聯(lián)合查詢，會對服務帶來很大壓力，可能導致查詢超時以及慢查詢等問題，因此第二個優(yōu)化方向是優(yōu)化元數(shù)據(jù)API調(diào)用；

最后，從長遠考慮，隨著業(yè)務發(fā)展，數(shù)據(jù)量和訪問量還會持續(xù)上漲，我們需要具備在極端情況下對于不同優(yōu)先級的訪問進行流量控制的能力，滿足服務分級保障的需求，同時具備在服務容量不足時對服務進行水平擴容的能力。

接下來我們從四個優(yōu)化方向分別進行介紹：

1. MetaStore讀寫分離架構設計

首先，我們介紹一下MetaStore讀寫分離架構設計。

根據(jù)業(yè)務應用場景和需求不同，例如數(shù)據(jù)血緣、數(shù)據(jù)地圖、數(shù)據(jù)依賴等服務只有讀請求，我們可以直接把MetaStore服務拆分為讀寫和只讀，只讀服務鏈接從庫來承接這部分讀請求。從庫本身可水平擴展，能夠很好的降低服務QPS壓力，把服務訪問延遲控制在較好的水平，滿足業(yè)務需求。

在查詢場景中，既有讀請求也有寫請求，沒有辦法直接從服務層面進行拆分。由于大數(shù)據(jù)場景下普遍寫少讀多，大量讀請求直接發(fā)送到主庫會導致QPS峰值高，服務抖動引發(fā)慢查詢，進而影響服務穩(wěn)定性。對此我們的優(yōu)化方案是在查詢層面實現(xiàn)HiveMetaStore API粒度的讀寫分離，通過把對主庫的讀請求盡量路由到從庫，從而有效降低主庫的QPS壓力。這個方案要解決的一個主要問題是如何保證數(shù)據(jù)一致性，避免由于主從同步延遲，導致讀請求在從庫中漏讀數(shù)據(jù)或者讀取到錯誤的過期數(shù)據(jù)。

整體解決思路也很簡單，我們在把讀請求路由到從庫之前，先確保當前服務所連接的從庫已經(jīng)完成數(shù)據(jù)同步即可。

具體流程為：在HiveServer或者Spark提交SQL創(chuàng)建會話鏈接時，會首先從主庫獲取并保存當前最新的GTID，在同一個會話中，每次寫請求操作完成后，都會更新當前會話所持有的GTID；對于讀請求，會首先獲取從庫當前的GTID，通過比較GTID來判斷從庫是否已經(jīng)完成了數(shù)據(jù)同步，只有當從庫GTID大于等于當前會話持有的GTID時，這次讀操作才會被真正路由到從庫。

通過上述讀寫分離方案，我們主庫的QPS負載下降70%+，并且由于壓力下降，主庫的慢查詢問題也同步大幅減少，有效提升了服務穩(wěn)定性。

2. MetaStore API優(yōu)化

我們通過讀寫分離手段卸載了主庫壓力，把大量訪問請求轉(zhuǎn)移到從庫，一方面我們可以通過水平擴容進行負載均衡來緩解從庫壓力，另一方面通過優(yōu)化MetaStore接口調(diào)用，也能夠有效提升服務性能和穩(wěn)定性。

根據(jù)我們分析定位，MetaStore API調(diào)用當前主要面臨的問題包括：

第一，查詢層面存在大量的API調(diào)用，造成底層服務QPS過高；

第二，在Hive MetaStore層，單次API調(diào)用訪問的數(shù)據(jù)量過大，容易導致服務瞬時壓力大；

第三，對于存儲分區(qū)信息的兩個大表（單表記錄超10億）查詢時延過高。

第二個單次訪問數(shù)據(jù)量大，造成服務瞬時壓力高，改成分批方式返回，就能起到削峰作用；第三個分析對兩張大表的查詢性能瓶頸，針對具體問題采用合適的優(yōu)化方案。

首先針對API調(diào)用量大的問題，我們需要查一下為什么有這么多的調(diào)用，是不是都是正常必要的調(diào)用以及如何減少冗余API的調(diào)用。這里我們主要進行了兩點優(yōu)化：

HIVE的DDL DESC TABLE命令，社區(qū)默認行為除了返回表相關元信息外，還會遍歷獲取這個表所有的分區(qū)信息，對于一個包含大量分區(qū)的表來說，這個操作會非常耗時同時也是不必要的。對此我們做的優(yōu)化是默認跳過這個遍歷獲取分區(qū)元信息的操作。通過測試對比，對于一個包含十萬分區(qū)的表執(zhí)行DESC命令，優(yōu)化前需要兩百多秒，優(yōu)化之后只需要0.2秒。

然后通過對于MetaStore API調(diào)用占比進一步分析發(fā)現(xiàn)，get_functions/get_function這兩個接口被大量調(diào)用，這個不太符合預期。經(jīng)過排查發(fā)現(xiàn)這個調(diào)用行為是Spark SQL在初始化Hive MetaStore的時候所觸發(fā)。社區(qū)Spark在3.0版本之前底層所依賴的Hive版本一直是1.2，在這個版本中的初始化實現(xiàn)會先通過get_database獲取所有的HIVE庫，然后針對每個HIVE庫再逐個調(diào)用get_functions接口，接口調(diào)用次數(shù)和總的HIVE庫數(shù)量成正比，導致了大量冗余調(diào)用。在Hive2.3版本中這塊行為已經(jīng)得到了優(yōu)化，我們通過升級Spark所依賴的HIVE包到2.3版本解決了該問題。根據(jù)我們的統(tǒng)計，優(yōu)化后整體API調(diào)用次數(shù)減少近30%。

其次針對單次訪問數(shù)據(jù)量大，造成服務瞬時壓力高的問題，我們可以考慮改成分批方式完成大數(shù)據(jù)量的掃描，從而起到削峰作用。

例如查詢一個大表某個時間范圍內(nèi)的所有分區(qū)，涉及分區(qū)數(shù)11W，優(yōu)化前由于需要一次性掃描大量數(shù)據(jù)并返回，導致元數(shù)據(jù)服務壓力過大，接口調(diào)用超時，任務查詢失??；我們通過把一次大查詢拆分成一系列小查詢，分批輪次返回需要的數(shù)據(jù)，就能有效規(guī)避服務層面瞬時壓力過大造成的一系列不良后果，優(yōu)化后這次查詢總共耗時17115毫秒。通過上圖元數(shù)據(jù)服務測試時的網(wǎng)絡壓力等指標變化，也可以間接反映優(yōu)化效果。

然后我們再分析一下存儲分區(qū)信息的兩個大表查詢時延過高的問題，看看性能瓶頸究竟在什么地方以及如何進行針對性優(yōu)化。

對于select * from table where p_date=‘20200101’ and p_product=‘a(chǎn)’這樣一條Hive查詢，在進行分區(qū)下推時發(fā)送給元數(shù)據(jù)服務的查詢表達式為：where ((( “FILTER0”.“PART_KEY_VAL”= ?) and (“FILTER2”.“PART_KEY_VAL”= ?)))。

這個查詢表達式使用PARTITION_KEY_VAL表中的PART_KEY_VAL字段來進行匹配過濾，存在的問題是：PARTITION_KEY_VAL表中沒有TBL_ID字段，導致會掃描到無關表的同名分區(qū)；PARTITION_KEY_VAL表中沒有索引列，無法通過索引加速。

針對上述問題，我們的優(yōu)化方案是應用PARTITONS表中的分區(qū)名索引加速查詢，并且PARTITIONS表中包含TBL_ID字段，也能夠有效避免對無關表的分區(qū)掃描。

通過分析expresssionTree，解析時間范圍子樹，獲取最長子串前綴：‘20200101’，從而得到優(yōu)化后的查詢表達式為：where ((( “FILTER0”.“PART_KEY_VAL”= ?) and (“FILTER2”.“PART_KEY_VAL”= ?))) and(“PARTITIONS”.“PART_NAME”like ? )。

這個查詢優(yōu)化前后的耗時對比為2662ms VS 786ms，取得了很大提升。

接下來我們再看另一種可優(yōu)化的場景，對于select * from table where p_date=20200101 and p_hourmin=1000這樣一條Hive查詢，由于其分區(qū)字段類型是string類型，但是Hive查詢中給的是整型值，導致無法通過分區(qū)名進行過濾，會命中該表的全部子分區(qū)。

優(yōu)化方案也很簡單，在SQL解析時，如果filter字段為分區(qū)字段，并且類型為string，強制轉(zhuǎn)換constantValue到string類型。

優(yōu)化前耗時：32288ms，優(yōu)化后耗時：586ms。

3. MetaStore流量控制架構設計

我們接著聊一下MetaStore流量控制架構設計：

Hive MetaStore作為核心的底層依賴服務，需要具備服務分級保障能力，當服務壓力過高響應能力出現(xiàn)瓶頸時，要能夠優(yōu)先滿足高優(yōu)先級任務請求、限制或者阻斷低優(yōu)先級請求的能力，防止元數(shù)據(jù)庫出現(xiàn)雪崩狀況。

整體流量控制架構設計如上圖所示，核心點在于引入BeaconServer服務作為中控層。Beacon Server作為中控層，支持動態(tài)更新設置流控策略，以及實時獲取當前元數(shù)據(jù)服務壓力狀況。Hive MetaStore作為客戶端會周期性去中控層獲取當前最新的元數(shù)據(jù)服務壓力狀況和流控策略，并針對不同優(yōu)先級的API調(diào)用請求采取對應的流控措施。

基于上述架構，我們可以實現(xiàn)在服務流量高峰期出現(xiàn)性能瓶頸時，能夠按比例延遲或阻斷部分低優(yōu)先級的訪問請求，保證高優(yōu)先級請求繼續(xù)得到正常響應，當服務壓力緩解狀態(tài)恢復正常后，再自動恢復對低優(yōu)先級訪問請求的響應。

流量控制架構在上線后，有效緩解了生命周期管理服務定期清理大批量分區(qū)時對于元數(shù)據(jù)服務造成TPS過高的壓力。

4. MetaStore Federation架構設計

最后介紹一下MetaStore Federation架構設計，長遠看，隨著業(yè)務量持續(xù)增加，MySQL單機依然會存在性能及存儲瓶頸的風險。解決MySQL單機瓶頸和壓力，業(yè)界通用方案是分庫分表，由于Hive元數(shù)據(jù)信息存儲采用三范式設計，表關聯(lián)較多，直接在MySQL層面進行拆庫拆表會存在改造成本大、風險高且不利于未來擴容的問題，因此我們考慮采取HiveMetaStore層面的Federation方案，實現(xiàn)元數(shù)據(jù)水平擴展能力。

首先看一下Hive MetaStore內(nèi)部實現(xiàn)邏輯，持久化元數(shù)據(jù)層被抽象成了RawStore，比如MySQL對應的實現(xiàn)時ObjectStore，HBase對應的實現(xiàn)則是HBaseStore。

基于上述原理，我們首先想到的方案1是基于ObjectStore已有功能和代碼實現(xiàn)KwaiStore，在KwaiStore中實現(xiàn)Hive DB路由數(shù)據(jù)源的功能，配置不同Hive DB到對應MySQL數(shù)據(jù)源的映射關系。

方案1的優(yōu)點在于可以保持包和配置的統(tǒng)一，降低韻味成本；缺點在于對Hive的侵入性較大，并且上線時如果要做到數(shù)據(jù)完全一致，需要暫停服務。

方案2是通過引入路由層，使用代理轉(zhuǎn)發(fā)請求的方式來實現(xiàn)。這個方案下Metastore代碼不用做任何改動，新增Router層，根據(jù)請求數(shù)據(jù)的Hive DBName來決定路由到哪個Metastore上去。Router層可以水平擴容，可以在Router層做很多擴展功能，白名單、多數(shù)據(jù)源支持(統(tǒng)一元數(shù)據(jù))、Hive DB 禁用、元數(shù)據(jù)權限等操作。在擴容時，可以在Router層添加規(guī)則，指定某個Hive DB 暫時不可訪問，待數(shù)據(jù)源完全準備好后，再添加路由規(guī)則到Router層，同時取消DB不可用限制；可以做到只影響部分Hive DB的使用。

總結(jié)一下，方案2的優(yōu)點在于對Hive 沒有侵入性，升級版本比較容易，可以靈活定制Router層策略，HA水平擴容，擴容MySQL時相對影響較小，上線風險較小，統(tǒng)一元數(shù)據(jù)入口，方便審計和溯源；不足之處在于新引入服務層，增加運維成本，Metastore被劃分標簽，配置不完全統(tǒng)一。

綜合考慮方案1和方案2的優(yōu)缺點，我們最終選擇了在HMHandler層來實現(xiàn)路由功能，在HMSHandler中維護一組HiveDB與RawStore的映射關系，在getMS()時傳入 Hive DB，路由根據(jù)db判斷應該使用那個RawStore，不修改RawStore中API的實現(xiàn)，不涉及到持久化層的侵入改造。

這個方案的優(yōu)點是配置統(tǒng)一，運維成本低；不修改持久化層，改造難度??；缺點是需要調(diào)整大量Thrift API，在調(diào)用時傳入DB。

▌結(jié)束語

以上是本次關于HiveMetaStore服務在快手遇到的挑戰(zhàn)與優(yōu)化的全部內(nèi)容。今天的分享就到這里，謝謝大家。