一、背景

大數據元數據服務Hive Metastore Service（以下簡稱HMS），存儲著數據倉庫中所依賴的所有元數據并提供相應的查詢服務，使得計算引擎（Hive、Spark、Presto）能在海量數據中準確訪問到需要訪問的具體數據，其在離線數倉的穩定構建上扮演著舉足輕重的角色。vivo離線數倉的Hadoop集群基于CDH 5.14.4版本構建，HMS的版本選擇跟隨CDH大版本，當前使用版本為1.1.0-cdh5.14.4。

vivo在HMS底層存儲架構未升級前使用的是MySQL存儲引擎，但隨著vivo業務發展，數據爆炸式增長，存儲的元數據也相應的增長到億級別（PARTITION_PARAMS：8.1億、

PARTITION_KEY_VALS：3.5億、PARTITIONS：1.4億），在如此大量的數據基數下，我們團隊經常面臨機器資源的性能瓶頸，往往用戶多并發的去查詢某些大分區表（50w+分區），機器資源的使用率就會被打滿，從而導致元數據查詢超時，嚴重時甚至整個HMS集群不可用，此時恢復手段只能暫時停服所有HMS節點，直到MySQL機器負載降下來后在逐步恢復服務。為此，針對當前MySQL方案存在的嚴重性能瓶頸，HMS急需一套完善的橫向擴展方案來解決當前燃眉之急。

二、橫向擴展技術方案選型

為解決HMS的性能問題，我們團隊對HMS橫向擴展方案做了大量的調研工作，總體下來業內在HMS的橫向擴展思路上主要分為對MySQL進行拆庫擴展或用高性能的分布式引擎替代MySQL。在第一種思路上做的比較成熟的方案有Hotels.com公司開源的Waggle Dance，實現了一個跨集群的Hive Metastore代理網關，他允許用戶同時訪問多個集群的數據，這些集群可以部署在不同的平臺上，特別是云平臺。第二種思路當前主流的做法是用分布式存儲引擎TiDB替換傳統的MySQL引擎，在Hive社區中有不少公司對hive 2.x接入TiDB做了大量的測試并應用到生產中（詳情點擊）。

2.1 Waggle Dance

Waggle-dance向用戶提供統一的入口，將來自Metastore客戶端的請求路由到底層對應的Metastore服務，同時向用戶隱藏了底層的Metastore分布，從而在邏輯層面整合了多個Metastore的Hive庫表信息。Waggle-dance實現了Metastore的Thrift API，客戶端無需改動，對用戶來說，Waggle-dance就是一個Metastore。其整體架構如下：

從Waggle-dance的架構中最突出的特性是其采用了多個不同的MySQL實例分擔了原單MySQL實例的壓力，除此之外其還有如下優勢：

1. 用戶側可以沿用Metastore客戶端的用法，配置多臺Waggle-dance的連接，在當前Waggle-dance連接服務不可用的時候切換到其他的Waggle-dance服務上。
2. Waggle-dance只需幾秒即可啟動，加上其無狀態服務的特性，使得Waggle-dance具備高效的動態伸縮性，可以在業務高峰期快速上線新的服務節點分散壓力，在低峰期下線部分服務節點釋放資源。
3. Waggle-dance作為一個網關服務，除了路由功能外，還支持后續的定制化開發和差異化部署，平臺可根據需要添加諸如鑒權、防火墻過濾等功能。

2.2 TiDB

TiDB 是 PingCAP 公司自主設計、研發的開源分布式關系型數據庫，是一款同時支持在線事務處理與在線分析處理 (Hybrid Transactional and Analytical Processing, HTAP) 的融合型分布式數據庫產品，具備水平擴容或者縮容、金融級高可用、實時 HTAP、云原生的分布式數據庫、兼容 MySQL 5.7 協議和 MySQL 生態等重要特性。在TiDB 4.x版本中，其性能及穩定性較與之前版本得到了很大的提升并滿足HMS的元數據查詢性能需求。故我們對TiDB也做了相應的調研及測試。結合HMS及大數據生態，采用TiDB作為元數據存儲整體的部署架構如下：

由于TiDB本身具有水平擴展能力，擴展后能均分查詢壓力，該特性就是我們解決HMS查詢性能瓶頸的大殺器。除此外該架構還有如下優勢：

1. 用戶無需任何改動；HMS側面沒有任何改動，只是其依賴的底層存儲發生變化。
2. 不破壞數據的完整性，無需將數據拆分多個實例來分擔壓力，對HMS來說其就是一個完整、獨立的數據庫。
3. 除引入TiDB作為存儲引擎外，不需要額外的其他服務支撐整個架構的運行。

2.3 TiDB和Waggle Dance對比

前面內容對Waggle-dance方案和TiDB方案做了簡單的介紹及優勢總結，以下列舉了這兩個方案在多個維度的對比：

通過上述多個維度的對比，TiDB方案在性能表現、水平擴展、運維復雜度及機器成本上都優于waggle-dance方案，故我們線上選擇了前者進行上線應用。 

三、TiDB上線方案

選擇TiDB引擎替代原MySQL存儲引擎，由于TiDB與MySQL之間不能做雙主架構，在切換過程中HMS服務須完全停服后并重新啟動切換至TiDB，為保障切換過程順利及后面若有重大問題發生能及時回滾，在切換前做了如下數據同步架構以保障切換前MySQL與TiDB數據一致以及切換后仍有MySQL兜底。

在上述架構中，切換前唯一可寫入的數據源只有源數據庫主庫，其他所有TiDB、MySQL節點都為只讀狀態，當且僅當所有HMS節點停服后，MySQL源數據庫從庫及TiDB源數據庫主庫的數據同步最大時間戳與源數據庫主庫一致時，TiDB源數據庫主庫才開放可寫入權限，并在修改HMS底層存儲連接串后逐一拉起HMS服務。

在上述架構完成后，即可開始具體的切換流程，切換整體流程如下：

其中在保障源MySQL與TiDB數據正常同步前，需要對TiDB做以下配置：

• tidb_skip_isolation_level_check需要配置為1 ，否則啟動HMS存在MetaException異常。
• tidb_txn_mode需配置為pessimistic ，提升事務一致性強度。
• 事務大小限制設置為3G，可根據自己業務實際情況進行調整。
• 連接限制設置為最大3000 ，可根據自己業務實際情況進行調整。

此外在開啟sentry服務狀態下，需確認sentry元數據中NOTIFICATION_ID的值是否落后于HMS元數據庫中NOTIFICATION_SEQUENCE表中的NEXT_EVENT_ID值，若落后需將后者替換為前者的值，否則可能會發生建表或創建分區超時異常。

以下為TiDB方案在在不同維度上的表現：

1. 在對HQL的兼容性上TiDB方案完全兼容線上所有引擎對元數據的查詢，不存在語法兼容問題，對HQL語法兼容度達100% 
2. 在性能表現上查詢類接口平均耗時優于MySQL，性能整體提升15%；建表耗時降低了80%，且支持更高的并發，TiDB性能表現不差于MySQL
3. 在機器資源使用情況上整體磁盤使用率在10%以下；在沒有熱點數據訪問的情況下，CPU平均使用率在12%；CPU.WAIT.IO平均值在0.025%以下;集群不存在資源使用瓶頸。
4. 在可擴展性上TiDB支持一鍵水平擴縮容，且內部實現查詢均衡算法，在數據達到均衡的情況下各節點可平攤查詢壓力。
5. 在容災性上TiDB Binlog技術可穩定支撐TiDB與MySQL及TiDB之間的數據同步，實現完整的數據備份及可回退選擇。
6. 在服務高可用性上TiDB可選擇LVS或HaProxy等服務實現負載均衡及故障轉移。

以下為上線后HMS主要API接口調用耗時情況統計：

圖片

圖片

圖片

圖片

圖片

圖片

圖片

圖片

（左右滑動，查看更多···）

四、問題及解決方案

4.1 在模擬TiDB回滾至MySQL過程中出現主鍵沖突問題

在TiDB數據增長3倍后，切換回MySQL出現主鍵重復異常，具體日志內容如下：

產生該問題的主要原因為每個 TiDB 節點在分配主鍵ID時，都申請一段 ID 作為緩存，用完之后再去取下一段，而不是每次分配都向存儲節點申請。這意味著，TiDB的AUTO_INCREMENT自增值在單節點上能保證單調遞增，但在多個節點下則可能會存在劇烈跳躍。因此，在多節點下，TiDB的AUTO_INCREMENT自增值從全局來看，并非絕對單調遞增的，也即并非絕對有序的，從而導致Metastore庫里的SEQUENCE_TABLE表記錄的值不是對應表的最大值。

造成主鍵沖突的主要原因是SEQUENCE_TABLE表記錄的值不為元數據中實際的最大值，若存在該情況在切換回MySQL后就有可能生成已存在的主鍵導致初見沖突異常，此時只需將SEQUENCE_TABLE里的記錄值設置當前實際表中的最大值即可。

4.2 PARTITION_KEY_VALS的索引取舍

在使用MySQL引擎中，我們收集了部分慢查詢日志，該類查詢主要是查詢分區表的分區，類似如下SQL：

#以下查詢為查詢三級分區表模板，且每級分區都有過來條件
SELECT PARTITIONS.PART_ID
FROM PARTITIONS
  INNER JOIN TBLS
  ON PARTITIONS.TBL_ID = TBLS.TBL_ID
    AND TBLS.TBL_NAME = '${TABLE_NAME}'
  INNER JOIN DBS
  ON TBLS.DB_ID = DBS.DB_ID
    AND DBS.NAME = '${DB_NAME}'
  INNER JOIN PARTITION_KEY_VALS FILTER0
  ON FILTER0.PART_ID = PARTITIONS.PART_ID
    AND FILTER0.INTEGER_IDX = ${INDEX1}
  INNER JOIN PARTITION_KEY_VALS FILTER1
  ON FILTER1.PART_ID = PARTITIONS.PART_ID
    AND FILTER1.INTEGER_IDX = ${INDEX2}
  INNER JOIN PARTITION_KEY_VALS FILTER2
  ON FILTER2.PART_ID = PARTITIONS.PART_ID
    AND FILTER2.INTEGER_IDX = ${INDEX3}
WHERE FILTER0.PART_KEY_VAL = '${PART_KEY}'
  AND CASE 
    WHEN FILTER1.PART_KEY_VAL <> '__HIVE_DEFAULT_PARTITION__' THEN CAST(FILTER1.PART_KEY_VAL AS decimal(21, 0))
    ELSE NULL
  END = 10
  AND FILTER2.PART_KEY_VAL = '068';

在測試中通過控制并發重放該類型的SQL，隨著并發的增加，各個API的平均耗時也會增長，且重放的SQL查詢耗時隨著并發的增加查詢平均耗時達到100s以上，雖然TiDB及HMS在壓測期間沒有出現任何異常，但顯然這種查詢效率會讓用戶很難接受。DBA分析該查詢沒有選擇合適的索引導致查詢走了全表掃描，建議對PARTITION_KEY_VALS的PARTITION_KEY_VAL字段添加了額外的索引以加速查詢，最終該類型的查詢得到了極大的優化，即使加大并發到100的情況下平均耗時在500ms內，對此我們曾嘗試對PARTITION_KEY_VALS添加上述索引操作。

但在線上實際的查詢中，那些沒有產生慢查詢的分區查詢操作其實都是按天分區的進行一級分區查詢的，其SQL類似如下：

SELECT "PARTITIONS"."PART_ID"
FROM "PARTITIONS"
  INNER JOIN "TBLS"
  ON "PARTITIONS"."TBL_ID" = "TBLS"."TBL_ID"
    AND "TBLS"."TBL_NAME" = 'tb1'
  INNER JOIN "DBS"
  ON "TBLS"."DB_ID" = "DBS"."DB_ID"
    AND "DBS"."NAME" = 'db1'
  INNER JOIN "PARTITION_KEY_VALS" "FILTER0"
  ON "FILTER0"."PART_ID" = "PARTITIONS"."PART_ID"
    AND "FILTER0"."INTEGER_IDX" = 0
  INNER JOIN "PARTITION_KEY_VALS" "FILTER1"
  ON "FILTER1"."PART_ID" = "PARTITIONS"."PART_ID"
    AND "FILTER1"."INTEGER_IDX" = 1
WHERE "FILTER0"."PART_KEY_VAL" = '2021-12-28'
  AND CASE 
    WHEN "FILTER1"."PART_KEY_VAL" <> '__HIVE_DEFAULT_PARTITION__' THEN CAST("FILTER1"."PART_KEY_VAL" AS decimal(21, 0))
    ELSE NULL
  END = 10;

由于對PARTITION_KEY_VALS的PARTITION_KEY_VAL字段添加了索引做查詢優化，會導致該類查詢生成的執行計劃中同樣會使用idx_PART_KEY_VAL索引進行數據掃描，該執行計劃如下：

添加的idx_PART_KEY_VAL索引在該字段的具有相同值的數據較少時，使用該索引能檢索較少的數據提升查詢效率。在hive中的表一級分區基本是按天進行分區的，據統計每天天分區的增量為26w左右，如果使用idx_PART_KEY_VAL索引，按這個數值計算，查詢條件為day>=2021-12-21 and day<2021-12-26的查詢需要檢索將近160w條數據，這顯然不是一個很好的執行計劃。

若執行計劃不走idx_PART_KEY_VAL索引，TiDB可通過dbs、tbls檢索出所有關聯partition數據，在根據part_id和過濾條件掃描PARTITION_KEY_VALS數據并返回。此類執行計劃掃描的數據量和需要查詢的表的分區總量有關，如果該表只有少數的分區，則查詢能夠迅速響應，但如果查詢的表有上百萬的分區，則該類執行計劃對于該類查詢不是最優解。

針對不同執行計劃的特性，整理了以下對比點：

在實際生產中元數據基本都是按天分區為主，每天增長大概有26w左右，且范圍查詢的使用場景較多，使用idx_PART_KEY_VAL索引查詢的執行計劃不太適合線上場景，故該索引需不適合添加到線上環境。

4.3 TiDB內存突增導致宕機問題

在剛上線TiDB服務初期，曾數次面臨TiDB內存溢出的問題，每次出現的時間都隨機不確定，出現的時候內存突增幾乎在一瞬間，若期間TiDB的內存抗住了突增量，突增部分內存釋放在很長時間都不會得到釋放，最終對HMS服務穩定性帶來抖動。

通過和TiDB開發、DBA聯合分析下，確認TiDB內存飆高的原因為用戶在使用Dashboard功能分析慢查詢引起；在分析慢查詢過程中，TiDB需要加載本地所有的slow-query日志到內存，如果這些日志過大，則會造成TiDB內存突增，此外，如果在分析期間，用戶點擊了取消按鈕，則有可能會造成TiDB的內存泄漏。針對該問題制定如下解決方案：

1. 使用大內存機器替換原小內存機器，避免分析慢查詢時內存不夠
2. 調大慢查詢閾值為3s，減少日志產生
3. 定時mv慢查詢日志到備份目錄

4.4 locate函數查詢不走索引導致TiKV負異常

在HMS中存在部分通過JDO的方式去獲取分區的查詢，該類查詢的過濾條件中用locate函數過濾PART_NAME數據，在TiDB中通過函數作用在字段中是不會觸發索引查詢的，所以在該類查詢會加載對應表的所有數據到TiDB端計算過濾，TiKV則需不斷掃描全表并傳輸數據到TiDB段，從而導致TiKV負載異常。

然而上述的查詢條件可以通過like方式去實現，通過使用like語法，查詢可以成功使用到PARTITIONS表的UNIQUEPARTITION索引過濾，進而在TiKV端進行索引過濾降低負載。

通過實現將locate函數查詢轉換為like語法查詢，有效降低了TiKV端的負載情況。在HMS端完成變更后，TiKV的CPU使用率降低了將近一倍，由于在KV端進行索引過濾，相應的io使用率有所上升，但網絡傳輸則有明顯的下降，由平均1G降低到200M左右。

除TiKV負載有明顯的降低，TiDB的整體性能也得到明顯的提升，各項操作耗時呈量級降低。以下整理了TiDB增刪改查的天平均耗時情況：

4.5 get_all_functions優化

隨著hive udf的不斷增長，HMS的get_all_functions api平均耗時增長的也越來越久，平均在40-90s，而該api在hive shell中首次執行查詢操作時會被調用注冊所有的udf，過長的耗時會影響用戶對hive引擎的使用體驗，例如執行簡單的show database需要等待一分鐘甚至更久才能返回結果。

導致該api耗時嚴重的主要原因是HMS通過JDO方式獲取所有的Function，在獲取所有的udf時后臺會遍歷每條func去關聯DBS、FUNC_RU兩個表，獲取性能極低。而使用directSQL的方式去獲取所有udf數據，響應耗時都在1秒以內完成，性能提升相當明顯。以下為directSQL的SQL實現邏輯：

select FUNCS.FUNC_NAME,
  DBS.NAME,
  FUNCS.CLASS_NAME,
  FUNCS.OWNER_NAME,
  FUNCS.OWNER_TYPE,
  FUNCS.CREATE_TIME,
  FUNCS.FUNC_TYPE,
  FUNC_RU.RESOURCE_URI,
  FUNC_RU.RESOURCE_TYPE
from FUNCS
left join FUNC_RU on FUNCS.FUNC_ID = FUNC_RU.FUNC_ID
left join DBS on FUNCS.DB_ID = DBS.DB_ID

五、總結

我們從2021年7月份開始對TiDB進行調研，在經歷數個月的測試于同年11月末將MySQL引擎切換到TiDB。由于前期測試主要集中在兼容性和性能測試上，忽略了TiDB自身可能潛在的問題，在上線初期經歷了數次因慢查詢日志將TiDB內存打爆的情況，在這特別感謝我們的DBA團隊、平臺運營團隊及TiDB官方團隊幫忙分析、解決問題，得以避免該問題的再次發生；與此同時，由于當前HMS使用的版本較低，加上大數據的組件在不斷的升級演進，我們也需要去兼容升級帶來的變動，如HDFS升級到3.x后對EC文件讀取的支持，SPARK獲取分區避免全表掃描改造等；此外由于TiDB的latin字符集支持中文字符的寫入，該特性會導致用戶誤寫入錯誤的中文分區，對于此類型數據無法通過現有API進行刪除，還需要在應用層去禁止該類型錯誤分區寫入，避免無用數據累積。

經歷了一年多的實際生產環境檢驗，TiDB內存整體使用在10%以內，TiKV CPU使用平穩，使用峰值均在30核內，暫不存在系統瓶頸；HMS服務的穩定性整體可控，關鍵API性能指標滿足業務的實際需求，為業務的增長提供可靠支持。在未來三年內，我們將保持該架構去支撐整個大數據平臺組件的穩定運行，期間我們也將持續關注行業內的變動，吸收更多優秀經驗應用到我們的生產環境中來，包括但不限于對性能更好的高版本TiDB嘗試，HMS的性能優化案例。