胡海洋：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：
https://cwiki.apache.org/conf...
https://github.com/HotelsDotC...

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）
轉載請至 / 轉載合做入口