作者 | 胡夢宇，知乎數據架構平臺開發工程師
責編 | 屠敏
頭圖 | CSDN 下載自東方 IC
出品 | CSDN（ID：CSDNnews）
背景
ApacheHive 是基于 Apache Hadoop 的一個數據倉庫工具，可以將結構化的數據文件映射為一張數據庫表，并且提供了 Hive SQL 進行查詢和分析，在離線數倉中被廣泛使用。
HiveMetastore 是 Hive 的元信息管理工具，它提供了操作元數據的一系列接口，其后端存儲一般選用關系型數據庫如 Derby、 MySQL 等。現在很多除了Hive 之外計算框架都支持以 Hive Metastore 為元數據中心來查詢底層 Hadoop 生態的數據，比如 Presto、Spark、Flink 等等。
在知乎，我們是將元信息存儲在 MySQL 內的，隨著業務數據的不斷增長，MySQL 內已經出現單表數據量兩千多萬的情況，當用戶的任務出現 Metastore 密集操作的情況時，往往會出現緩慢甚至超時的現象，極大影響了任務的穩定性。長此以往，MySQL 在未來的某一天一定會不堪重負，因此優化 Hive 的元數據庫勢在必行。
在去年，我們做過數據治理，Hive 表生命周期管理，定期去刪除元數據，期望能夠減少 MySQL 的數據量，緩解元數據庫的壓力。但是經過實踐，發現該方案有以下缺點：
-
數據的增長遠比刪除的要快，治標不治本；
-
在刪除超大分區表（分區數上百萬）的分區時，會對 MySQL 造成一定的壓力，只能單線程去做，否則會影響其他正常的 Hive 查詢，效率極其低下；
-
在知乎，元信息刪除是伴隨數據一起刪除的（刪除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(https://github.com/pingcap/tidb).
TiDB 是 PingCAP 開源的分布式 NewSQL 數據庫，它支持水平彈性擴展、ACID 事務、標準 SQL、MySQL 語法和 MySQL 協議，具有數據強一致的高可用特性，是一個不僅適合 OLTP 場景還適 OLAP 場景的混合數據庫。
選用 TiDB 的理由如下：
-
TiDB 完全兼容 MySQL 的協議，經過測試，TiDB 支持 Hive Metastore 對元數據庫的所有增刪改查操作， 使用起來不存在兼容性相關的問題。因此，除了將MySQL 的數據原樣 dump 到 TiDB，幾乎沒有其他工作需要做；
-
TiDB 由于其分布式的架構，在大數據集的表現遠遠優于 MySQL；
-
TiDB 的可擴展性十分優秀，支持水平彈性擴展，不管是選用分庫分表還是 Federation，都可能會再次遇到瓶頸，屆時需要二次切分和擴容，TiDB 從根本上解決了這個問題；
-
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 以下。
2. 我們從元數據庫層面測試了一些 Metastore 提交的 SQL，尤其是那些會造成元數據庫壓力巨大的 SQL，例如：
SELECT `A0`.`PART_NAME`,`A0`.`PART_NAME` AS `NUCORDER0` FROM `PARTITIONS` `A0` LEFT OUTER JOIN `TBLS` `B0` ON `A0`.`TBL_ID` = `B0`.`TBL_ID` LEFT OUTER JOIN `DBS` `C0` ON `B0`.`DB_ID` = `C0`.`DB_ID` WHERE `C0`.`NAME` = '${database_name}' AND `B0`.`TBL_NAME` = '${table_name}' ORDER BY `NUCORDER0`
當某個 Hive 表的分區數量十分巨大時，這條 SQL 會給元數據庫造成相當大的負擔。遷移前，此類 SQL 在 MySQL 運行時間約為 30s - 40s，遷移后，在TiDB 運行僅需 6s - 7s，提升相當明顯。
3. 數據同步平臺上的Hive 元數據庫內的 SDS 表的同步任務時間從 90s 降低到 15s。
展望
在 Hive Metastore 的場景下，我們已經感受到了 TiDB 在大數據應用場景下的魅力。后續我們希望 TiDB 能夠成為跨數據中心的服務，通過數據副本的跨機房部署，打通離線與在線，讓離線場景能夠在對在線服務無壓力的情況下為數據提供實時的ETL 能力，解決離線 ETL 任務實時性差的問題。為此，我們正在開發 TiBigData(https://github.com/pingcap-incubator/TiBigData)。
目前其作為PingCAP incubator 的孵化項目。由來自知乎的 TiKV Maintainer 孫曉光發起。PingCAP Incubator 旨在梳理一套相對完整的TiDB 生態開源項目孵化體系，將關于 TiDB 開源生態的想法與實際生產環境中的需求相關聯，通過開源項目協作方式，共同將想法落地。力求想法項目化。從「我有一個想法」到「項目順利畢業」，PingCAP提供一系列的資源支持，確保所有項目孵化的流程都有章可循，同時結合項目不同特征及孵化目的，將項目劃分為 Feature 類和 Project 類，針對性地給出孵化流程建議。PingCAPIncubator 中的項目有：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 帶來更加完整的大數據能力。
