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

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

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

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

• 易用性：由于不同引擎在語(yǔ)法以及適用場(chǎng)景上各有優(yōu)缺點(diǎn)，對(duì)于業(yè)務(wù)來(lái)說(shuō)存在學(xué)習(xí)和使用門檻，需要通過(guò)技術(shù)手段來(lái)降低或者消除這種門檻

• 擴(kuò)展性：技術(shù)是發(fā)展非常快的，未來(lái)隨著技術(shù)發(fā)展可能還會(huì)有其他更高效的引擎不斷出現(xiàn)，我們?cè)诩軜?gòu)設(shè)計(jì)上需要能夠考慮到很好地?cái)U(kuò)展性支持這些新的計(jì)算引擎，需要做到計(jì)算引擎的可插拔、易擴(kuò)展

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

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

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

BeaconServer本身是一個(gè)無(wú)狀態(tài)服務(wù)，我們可以很方便進(jìn)行水平擴(kuò)容，并且BeaconServer服務(wù)調(diào)整升級(jí)不影響HiveServer服務(wù)本身。

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

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

02

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

在介紹完我們智能引擎架構(gòu)之后，接下來(lái)進(jìn)入今天重點(diǎn)的主題Hive MetaStore在快手的挑戰(zhàn)。

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

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

接下來(lái)介紹一下Hive MetaStore服務(wù)當(dāng)前所面臨的挑戰(zhàn)。

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

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

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

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

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

03

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

針對(duì)上述問(wèn)題，我們考慮從幾個(gè)方面進(jìn)行優(yōu)化：

首先，訪問(wèn)量多的問(wèn)題，在大數(shù)據(jù)場(chǎng)景下，存在寫少讀多的特定，對(duì)于元數(shù)據(jù)主庫(kù)，當(dāng)前壓力也主要來(lái)自于大量的讀操作導(dǎo)致QPS過(guò)高，因此第一個(gè)優(yōu)化方向是通過(guò)讀寫分離來(lái)降低主庫(kù)壓力；

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

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

接下來(lái)我們從四個(gè)優(yōu)化方向分別進(jìn)行介紹：

1. MetaStore讀寫分離架構(gòu)設(shè)計(jì)

首先，我們介紹一下MetaStore讀寫分離架構(gòu)設(shè)計(jì)。

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

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

整體解決思路也很簡(jiǎn)單，我們?cè)诎炎x請(qǐng)求路由到從庫(kù)之前，先確保當(dāng)前服務(wù)所連接的從庫(kù)已經(jīng)完成數(shù)據(jù)同步即可。

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

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

2. MetaStore API優(yōu)化

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

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

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

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

第三，對(duì)于存儲(chǔ)分區(qū)信息的兩個(gè)大表（單表記錄超10億）查詢時(shí)延過(guò)高。

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

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

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

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

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

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

然后我們?cè)俜治鲆幌麓鎯?chǔ)分區(qū)信息的兩個(gè)大表查詢時(shí)延過(guò)高的問(wèn)題，看看性能瓶頸究竟在什么地方以及如何進(jìn)行針對(duì)性優(yōu)化。

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

這個(gè)查詢表達(dá)式使用PARTITION_KEY_VAL表中的PART_KEY_VAL字段來(lái)進(jìn)行匹配過(guò)濾，存在的問(wèn)題是：PARTITION_KEY_VAL表中沒(méi)有TBL_ID字段，導(dǎo)致會(huì)掃描到無(wú)關(guān)表的同名分區(qū)；PARTITION_KEY_VAL表中沒(méi)有索引列，無(wú)法通過(guò)索引加速。

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

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

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

接下來(lái)我們?cè)倏戳硪环N可優(yōu)化的場(chǎng)景，對(duì)于select * from table where p_date=20200101 and p_hourmin=1000這樣一條Hive查詢，由于其分區(qū)字段類型是string類型，但是Hive查詢中給的是整型值，導(dǎo)致無(wú)法通過(guò)分區(qū)名進(jìn)行過(guò)濾，會(huì)命中該表的全部子分區(qū)。

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

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

3. MetaStore流量控制架構(gòu)設(shè)計(jì)

我們接著聊一下MetaStore流量控制架構(gòu)設(shè)計(jì)：

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

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

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

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

4. MetaStore Federation架構(gòu)設(shè)計(jì)

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

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

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

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

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

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

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

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

▌結(jié)束語(yǔ)

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