胡海洋：Hive Metastore Federation 在滴滴的實踐

出品 | 滴滴技術

做者 | 胡海洋

前言：本文來自滴滴基礎平臺大數據架構離線引擎組，針對內部hive元數據上億級別存儲方案的實踐；該架構體系從根本上提升了hive元數據服務的穩定性及擴展性問題。

▍背景

Apache Hive 是基於 Apache Hadoop 之上構建的數據倉庫，提供了簡單易用的類 SQL 查詢語言，適合對大規模數據進行存儲、查詢操做，被普遍使用。

Hive 元數據 Metadata 包含用 Hive 建立的 Database、Table、Partition 等的元信息。此類元信息通常存儲在關係型數據庫中，如 Derby、MySQL 等。

在滴滴，咱們是將元數據存儲在MySQL 裏，隨着業務的不斷增加，Hive 元數據愈來愈龐大，出現單表存儲超過上億條記錄的狀況，這種狀況下會致使 MySQL查詢壓力過大，並且在高峯期間，常常致使機器 CPU 使用率達到 100%，影響服務穩定性。

爲此，咱們開始調研元數據 Federation 方案，實現元數據水平擴展能力，爲 MySQL 解壓，提高 Hive 穩定性。

▍Federation 方案介紹

• 2.1 Hive 架構體系演變
  

引入 Federation 以前的 Hive 架構體系：

該架構體系中用戶使用的 Hive 客戶端或者 Hivesever2 服務、Spark 引擎、Presto 引擎等都是訪問統一 Hive Metastore 服務獲取 Hive 元數據。

Hive Metastore 服務主要是使用 LVS + 多個 Hive Metastore 實例組成。全部的 Hive Metastore 實例共享一套主從 MySQL 環境做爲 Hive 元數據存儲 DB。

前期工做

爲了緩解 Hive 元數據存儲 DB（MySQL）查詢壓力，咱們作了不少元數據治理工做，包括長時間無用的庫、表、分區清理等。元數據訪問限制包括查詢分區表分區限制等功能，但這些並無從根本上解決 MySQL 壓力問題。

方案調研

• MySQL 機器查詢壓力大的問題主要因爲 Hive 元數據結構中只存在一個庫，庫中存在單表超過上億條記錄的狀況。那爲何不考慮 MySQL 分庫，分表等方案？若是採用 MySQL 分庫，分表等方案，須要大量更改 Hive Metastore 接口，這樣風險及成本較高，並且後期涉及 Hive 版本升級也會帶來更多工做量。

• 基於 Hive Metastore 層實現 Federation（waggle_dance），實現思路主要是以 Hive DB 切分，在 Hive DB 層面將元數據分佈多套 MySQL 環境存儲，這樣對 Hive Metastore 自己不須要作任何修改，這種方案也較好維護。

基於 Hive Metastore Federation 實現後的 Hive 架構體系：

• 2.2 waggle_dance 介紹
  

Reference：

• cwiki.apache.org/confluence/…

github.com/HotelsDotCo…

waggle-dance 是由 Hotels.com 公司開源的一個項目，該項目主要是聯合多個 Hive Metastore 數據查詢的服務，實現了一個統一的路由接口解決多套 Hive Metastore 環境間的元數據共享問題。

2.2.1 架構流程圖

從架構圖來看， waggle_dance 服務實際上是承擔 Router 路由的角色，後端配置多個 Hive Metastore 環境，接收客戶端的元數據請求，經過 DB 與 Hive Metastore 路由關係將請求具體轉發到相應的 Hive Metastore 環境執行操做。

這些操做對於客戶端來講徹底透明，對於客戶端只是訪問一套 Hive Metastore 的環境。

2.2.2 內部組件解析

waggle_dance 基於 Spring-boot 框架實現，主要包括以下幾個模塊：

• WaggleDance容器

服務啓動類，主要初始化容器 Spring boot，加載 Listener，每一個關鍵的類經過註解方式加載，初始化。

• YamlFederatedMetaStoreStorage 模塊
  

維護須要依賴 Hive Metastore 環境的配置信息及 Hive Database 名字到 Hive Metastore 服務之間的路由信息。

當前支持配置一個主 Hive Metastore 及多個從 Hive Metastore 策略。

主 Hive Metastore 與從 Hive Metastore 配置主要區分的屬性 access-control-type。

• 主 Hive Metastore 定義屬性 access-control-type：對當前環境的 Hive 元數據操做支持以上 4 種策略。

從 Hive Metastore 定義屬性 access-control-type：對當前環境的 Hive 元數據操做只支持 READ_ONLY 只讀策略。

         文件配置管理模塊

• WaggleDanceConfiguration: ThriftServer 服務屬性配置

• GraphiteConfiguration： Graphite 監控屬性配置

  ThriftServer 模塊

實現 ThriftServer 服務，基於 Hive ThriftHiveMetastore API 對外提供 RPC 服務。接口包括 create_database、drop_database、create_table 以及彙總信息查詢如 get_all_databases、set_ugi 等操做。

這樣能夠作到徹底兼容 Hive 客戶端，Hivesever2 等服務請求協議，最終經過路由解析至對應的 Hive Metastore 創建鏈接並調用同名方法執行操做。

幾個須要注意的地方：

• 接口的操做是區分只讀和讀寫等策略，會根據路配置文件中定義的 Hive Metastore 的 access-control-type 屬性決定。

• 對於那些沒法經過庫名來路由的接口，都是轉發至主 Hive Metastore 環境執行操做。

Monitor 模塊

• MonitoringConfiguration、MonitoredAspect：服務監控邏輯，主要採用 Java 監控類庫 Metrics 實現（項目官網 http://metrics.dropwizard.io/ ），該庫支持將相關監控信息經過 Ganglia 和 Graphite 等工具進行展現，主要對 JVM 內存，線程執行狀態，Hive 元數據相關操做等監控。

FederationsAdmin 管理模塊

• FederationsAdminController：restful 接口實現，供管理員使用，可動態完成對 Federation Metastore 註冊、註銷及 Hive Database 名字與 Metastore 路由信息修改。

▍滴滴實踐

• 3.1 服務改造
  

當前 waggle_dance 功能不能徹底知足咱們的使用要求，須要進行擴展。改進點以下：

• 目標是須要支持對多套 Hive Metastore 環境進行讀寫元數據操做，因此擴展 waggle-dance-federation.yml 文件模板支持配置多個主 Hive Metastore。

• MappingEventListener 增長 MULTI_PRIMARY 策略。根據多個主 Hive Metastore 模式實現對應的 Hive Database 名字->Metastore mapping 路由信息類。

• 修改 FederatedHMSHandler 等類相關處理邏輯（兼容 Hive 1.2.1 與 2.x 版本 Hive ThriftHiveMetastore API）。這樣作的好處是在客戶端保持 Hive 1.2.1 版本的狀況下能夠徹底兼容後端多個 Hive 版本 Metastore 服務，方便後期對 Metastore 服務版本升級。

• 修改監控模塊，因爲公司內部是使用 Ganglia 工具進行監控，將 Graphite 改造爲 Ganglia 並優化監控指標。

• 相關性能優化，爲了不每一個客戶端鏈接過程當中都須要創建一個 Database->Metastore mapping 路由信息耗費的內存操做，每一個 waggle_dance 實例啓動的時候緩存一個 Hive Database->Metastore mapping 路由信息，該信息會被每一個客戶端鏈接請求的線程共用。

  對於 Database->Metastore mapping 路由信息的維護，每一個 waggle_dance 實例會按期請求後端多套 Hive Metastore 服務進行數據更新。

改造後 waggle_dance 架構流程圖：

• 3.2 部署狀況
  

爲了將線上 MySQL 中的 Hive 元數據逐步分佈到多套 MySQL 環境存儲，須要部署一套新的 MySQL 環境（對應新的 Hive Metastore環境）。

通過內部壓力測試，咱們得出結論，一個 waggle_dance 實例能夠對接於一套 Hive Metastore 環境。考慮 Hive Metastore 環境橫向擴展及保證服務的穩定性，部署了一套 waggle_dance 集羣由 LVS+4 個 waggle_dance 實例組成。

後續會將已有 MySQL 中存儲的 Hive 庫，表元數據信息逐步遷移到新的 MySQL 環境，爲了遷移過程當中減小對用戶使用的影響，將來還須要開發 waggle-dance 按表路由等功能。

▍總結

當前方案上線已經穩定運行幾個月，新的體系架構會支持橫向擴展多套 MySQL 環境，從根本上解決因爲一套 MySQL 環境帶來的性能及服務穩定問題。

▍END

原文來源 / 滴滴雲（didi-cloud）

                                                                                 胡海洋
                                                                滴滴 | 基礎平臺部
                                                                      資深工程師

2017年加入滴滴，任職於基礎平臺大數據架構部，長期從事海量數據處理平臺研發工做; 關注分佈式計算、調度與存儲系統等技術領域。