知乎 Hive Metastore 實踐：從 MySQL 到 TiDB

做者介紹：胡夢宇，知乎數據架構平臺開發工程師

背景

Apache Hive 是基於 Apache Hadoop 的一個數據倉庫工具，能夠將結構化的數據文件映射爲一張數據庫表，而且提供了 Hive SQL 進行查詢和分析，在離線數倉中被普遍使用。
Hive Metastore 是 Hive 的元信息管理工具，它提供了操做元數據的一系列接口，其後端存儲通常選用關係型數據庫如 Derby、 MySQL 等。如今不少除了 Hive 以外計算框架都支持以 Hive Metastore 爲元數據中心來查詢底層 Hadoop 生態的數據，好比 Presto、Spark、Flink 等等。
在知乎，咱們是將元信息存儲在 MySQL 內的，隨着業務數據的不斷增加，MySQL 內已經出現單表數據量兩千多萬的狀況，當用戶的任務出現 Metastore 密集操做的狀況時，每每會出現緩慢甚至超時的現象，極大影響了任務的穩定性。久而久之，MySQL 在將來的某一天必定會不堪重負，所以優化 Hive 的元數據庫勢在必行。
在去年，咱們作過數據治理，Hive 表生命週期管理，按期去刪除元數據，指望可以減小 MySQL 的數據量，緩解元數據庫的壓力。可是通過實踐，發現該方案有如下缺點：

1. 數據的增加遠比刪除的要快，治標不治本；
2. 在刪除超大分區表（分區數上百萬）的分區時，會對 MySQL 形成必定的壓力，只能單線程去作，不然會影響其餘正常的 Hive 查詢，效率極其低下；
3. 在知乎，元信息刪除是伴隨數據一塊兒刪除的（刪除 HDFS 過時數據，節約成本），Hive 的用戶可能存在建表不規範的狀況，將分區路徑掛錯，致使誤刪數據。

所以，咱們須要尋找新的技術方案來解決這個問題。

技術選型

已有方案

業內目前有兩種方案可供借鑑：

1. 對 MySQL 進行分庫分表處理，將一臺 MySQL 的壓力分攤到 MySQL 集羣；
2. 對 Hive Metastore 進行 Federation，採用多套 Hive Metastore + MySQL 的架構，在 Metastore 前方設置代理，按照必定的規則，對請求進行分發。

可是通過調研，咱們發現兩種方案都有必定的缺陷：

1. 對 MySQL 進行分庫分表，首先面臨的直接問題就是須要修改 Metastore 操做 MySQL 的接口，涉及到大量高風險的改動，後續對 Hive 的升級也會更加複雜；
2. 對 Hive Metastore 進行 Federation，儘管不須要對 Metastore 進行任何改動，可是須要額外維護一套路由組件，而且對路由規則的設置須要仔細考慮，切分現有的 MySQL 存儲到不一樣的 MySQL 上，而且可能存在切分不均勻，致使各個子集羣的負載不均衡的狀況；
3. 咱們天天都會同步一份 MySQL 的數據到 Hive，用做數據治理，生命週期管理等，同步是利用內部的數據同步平臺，若是採用上面兩種方案，數據同步平臺也須要對同步邏輯作額外的處理。

最終方案

其實問題主要在於，當數據量增長時，MySQL 受限於單機性能，很難有較好的表現，而將單臺 MySQL 擴展爲集羣，複雜度將會呈幾何倍上升。若是可以找到一款兼容 MySQL 協議的分佈式數據庫，就能完美解決這個問題。所以，咱們選擇了 TiDB。

TiDB 是 PingCAP 開源的分佈式 NewSQL 數據庫，它支持水平彈性擴展、ACID 事務、標準 SQL、MySQL 語法和 MySQL 協議，具備數據強一致的高可用特性，是一個不只適合 OLTP 場景還適 OLAP 場景的混合數據庫。

選用 TiDB 的理由以下：

1. TiDB 徹底兼容 MySQL 的協議，通過測試，TiDB 支持 Hive Metastore 對元數據庫的全部增刪改查操做， 使用起來不存在兼容性相關的問題。所以，除了將 MySQL 的數據原樣 dump 到 TiDB，幾乎沒有其餘工做須要作；
2. TiDB 因爲其分佈式的架構，在大數據集的表現遠遠優於 MySQL；
3. TiDB 的可擴展性十分優秀，支持水平彈性擴展，不論是選用分庫分表仍是 Federation，均可能會再次遇到瓶頸，屆時須要二次切分和擴容，TiDB 從根本上解決了這個問題；
4. TiDB 在知乎已經獲得了十分普遍的應用，相關技術相對來講比較成熟，所以遷移風險可控。

Hive 架構

遷移前

其中 Zue 是知乎內部使用的可視化查詢界面。

遷移後

在 Hive 的元數據庫遷移到 TiDB 了之後，架構幾乎沒有任何變化，只不過查詢的壓力由單臺 MySQL 節點分攤到了整個 TiDB 集羣，集羣越大，查詢效率越高，性能提高越明顯。

遷移流程

1. 將 TiDB 做爲 MySQL 的從庫，實時同步數據；
2. Metastore 縮容至 1 個，防止多個 Metastore 分別向 MySQL 及 TiDB 寫入，致使元數據不一致；
3. 選取業務低峯期，主從切換，將主切爲 TiDB，重啓 Metastore ；
4. Metastore 擴容。

此遷移過程對業務幾乎無感，成功上線。

運行概況

1. 咱們從 Hive 層面對數據庫進行了測試，模擬業務高峯期，多併發對百萬分區級別的表增刪分區，所執行的 Hive SQL 以下：

   ALTER TABLE '${table_name}' DROP IF EXISTS PARTITION(...);
   ALTER TABLE '${table_name}' ADD IF NOT EXISTS PARTITION(...);

花費時間從 45s-75s 下降到了 10s 如下。

1. 咱們從元數據庫層面測試了一些 Metastore 提交的 SQL，尤爲是那些會形成元數據庫壓力巨大的 SQL，例如：

SELECT `A0`.`PART_NAME`,`A0`.`PART_NAME` AS `NUCORDER0` FROM `PARTITIONS` `A0

當某個 Hive 表的分區數量十分巨大時，這條 SQL 會給元數據庫形成至關大的負擔。遷移前，此類 SQL 在 MySQL 運行時間約爲 30s - 40s，遷移後，在 TiDB 運行僅需 6s - 7s，提高至關明顯。

1. 數據同步平臺上的 Hive 元數據庫內的 SDS 表的同步任務時間從 90s 下降到 15s。

展望

在 Hive Metastore 的場景下，咱們已經感覺到了 TiDB 在大數據應用場景下的魅力。後續咱們但願 TiDB 可以成爲跨數據中心的服務，經過數據副本的跨機房部署，打通離線與在線，讓離線場景可以在對在線服務無壓力的狀況下爲數據提供實時的 ETL 能力，解決離線 ETL 任務實時性差的問題。爲此，咱們正在開發 TiBigData。

目前其做爲 PingCAP Incubator 的孵化項目。由來自知乎的 TiKV Maintainer 孫曉光發起。PingCAP Incubator 旨在梳理一套相對完整的 TiDB 生態開源項目孵化體系，將關於 TiDB 開源生態的想法與實際生產環境中的需求相關聯，經過開源項目協做方式，共同將想法落地。力求想法項目化。從「我有一個想法」到「項目順利畢業」，PingCAP 提供一系列的資源支持，確保全部項目孵化的流程都有章可循，同時結合項目不一樣特徵及孵化目的，將項目劃分爲 Feature 類和 Project 類，針對性地給出孵化流程建議。PingCAP Incubator 中的項目有：TiDB Dashboard、TiUP、TinyKV，TiDB Wasm 等。

完整項目請查看：
https://github.com/pingcap-incubator

PingCAP Incubator 完整文檔參考：
https://github.com/pingcap/community/tree/master/incubator

目前 TiBigData 項目已經爲 TiDB 提供了 Presto 與 Flink 的只讀支持。後續咱們但願在 PingCAP Incubator 計劃的扶持下同社區一塊兒建設 TiBigData 項目，力圖爲 TiDB 帶來更加完整的大數據能力。