小米Kylin平滑遷移HBase實踐

根據美團等其他公司在Kylin社區的公開分享資料，跨HBase集羣升級方案需要在新集羣重新構建歷史的Cube，或者有一段時間的服務停止。

小米在Kylin生產環境的跨HBase集羣遷移中實現了無中斷的平滑遷移，對業務的影響減到最低。

背景

小米Kylin生產環境部署的是基於社區2.5.2修改的內部版本，所依賴HBase集羣是一個公共集羣，小米內部很多離線計算服務共享使用該HBase集羣。由於Kylin已經產生超過6000張HBase表，給HBase的metadata管理造成了不小的壓力，HBase metadata節點異常恢復的速度也受到極大的影響。隨着業務的增長，Kylin HBase表繼續快速增長，HBase集羣的運維壓力也越來越大。

爲了應對快速增長的業務需求，我們決定將Kylin使用的HBase集羣獨立運維。同時，公共集羣的HBase是基於社區0.98.11的小米內部版本，版本較舊。在集羣獨立過程中，HBase團隊推薦使用最新基於社區2.2.0的小米內部版本，升級後HBase對超大metadata的管理也更友好。

目標與挑戰

小米Kylin生產環境上運行着超過50個項目、300多個cube，服務於很多在線的BI或報表系統。本次升級希望儘量減小對業務的影響：

遷移數據和切換集羣期間，查詢服務不中斷；
項目、數據模型和cube的新增、更改、發起構建、發起合併等操作不受影響；
數據構建任務可延後調度，但不能超過天級別；

Kylin存儲在HBase中的數據主要有兩類：Kylin metadata(元數據)、Cube預計算數據。

元數據中存儲着所有的用戶、項目和數據模型的信息；數據模型對應的結果數據表；數據任務的執行參數、狀態和日誌；查詢使用的詞典等重要信息。由於我們接入了很多自動化BI系統，這部分信息隨時在變化。

Cube預計算數據是查詢使用的結果數據，每一個segment對應着一張數據表，預計算的數據表生成之後不會變化。我們雖然可以通過HBase snapshot複製後在新集羣restore的方式將數據複製到新的集羣，但是由於生產環境的Kylin中的數據表比較多，且以每天400張的速度不斷生成（注：因爲有合併和過期刪除策略，每天數據表的增加數量要少於400）。新的數據表生成後會在metadata中標記爲可查詢，若此時數據表的同步未完成，就會導致查詢失敗。

我們面對挑戰是如何保障數據遷移的過程中的服務可用性：

Kylin metadata不斷變化，Cube預計算數據存量巨大且在持續增加；
metadata可以做到秒級別同步，Cube預計算數據只能做到天級別（存量）和小時級別（增量）的同步；
metadata新舊集羣保證一致，Cube預計算數據遷移過程中保障可用；

如下圖所示：

圖1-通常方案的問題

遷移方案

因爲我們維護了基於Kylin-2.5.2的內部版本，希望通過修改代碼實現平滑遷移，其關鍵點是：

通過HBase replication保證新舊集羣Kylin metadata的數據同步

Kylin的meta信息存儲在HBase的kylin_metadata表中，兩個集羣的此表保持同步更新。

Kylin支持連接多個HBase集羣

查詢時如果在首選HBase中找不到需要的HTable，則回退到備選HBase集羣。（已提交社區：KYLIN-4175）

任務調度支持安全模式

安全模式下，用戶可繼續提交構建任務，且已在調度中的任務可以繼續執行，但新提交的任務暫緩調度。（已提交社區：KYLIN-4178）

遷移示意圖如下：

圖2-支持secondary HBase方案

除了上述關鍵點，還需要注意一些細節問題。

1. 超大metadata的數據遷移

超過閾值（默認爲10MB）的metadata存儲在HBase依賴的HDFS上，需要手動遷移這部分數據。我們通過Hadoop distcp來遷移此部分數據。

2. coprocessor的更新

Kylin使用了HBase的coprocessor機制，在執行查詢的時候掃描HBase的數據。起初我們認爲可以使用兼容HBase 0.98和2.2的coprocessor，實際測試中發現需要更新爲支持HBase2.2的coprocessor。Kylin提供了工具來進行批量的更新。

構建基於HBase 2.2的Kylin，需要基於社區的2.5.x-hadoop3.1或2.6.x-hadoop3.1分支。我們選擇從Hadoop3.1的分支上移植相關特性。相關的JIRA有：KYLIN-2565、KYLIN-3518

>>>>

遷移步驟

具體遷移步驟如下：

HBase團隊搭建好基於HBase 2.2的獨立HBase集羣
HBase團隊添加新老集羣kylin_metadata表的異步replication；
HBase團隊通過snapshot + restore同步HBase其他表，並更新coprocessor；
在測試節點上回放生產環境查詢請求，驗證新集羣HBase數據表可正常提供查詢；
開啓JobServer的安全模式，禁用新的任務調度；
滾動升級QueryServer，切換至兼容新舊HBase；
等待安全模式下所有任務運行完成，切換JobServer至新HBase並關閉安全模式；
等待表全部遷移完成，使用KylinHealthCheck工具檢查HBase表，確認所有在用cube segment對應的HBase表存在；
檢查確認後，從Kylin去除舊HBase集羣配置；
舊HBase集羣數據保留一段時間，最後清理刪除。

問題&解決

在演練和執行的過程中，我們遇到了如下的一些問題：

>>>>

Kylin metadata的一致性驗證

Metadata作爲最重要的HBase表，影響着Kylin的主要功能。雖然有HBase replication來保證數據同步，也最好雙重確認來保障服務可用性。

我們在Kylin中開發了一個腳本來批量對比兩個meta表，通過掃描meta表所有的鍵值和時間戳來發現差異。在初期確實發現了差異，也依此來修正了replication的配置。在HBase團隊的協助下，該表做到了實時的同步。

>>>>

新HBase數據表的可用性驗證

爲了驗證新集羣的數據可用性，我們啓動了一個測試的Kylin實例用以模擬兼容多個HBase集羣的查詢。測試實例不直接對用戶服務，而是通過回放SQL query來進行可用性測試。回放測試自動驗證查詢是否正常返回。

這種測試方式彌補了迴歸測試用例覆蓋範圍的不足，通過測試我們確實發現了隱藏的問題並進行了修復。在生產環境的切換中，未發生新的問題。

>>>>

HBase2 protobuf變更帶來的影響

測試中發現，若HBase返回數據量較大時會查詢報錯，提示消息的長度超過限制：

InvalidProtocolBufferException:Protocol message was too large. May be malicious.

在查詢時，HBase和Kylin之間的數據發送通過protobuf序列化。HBase 2修改了返回數據的方式，從一次性返回變成了流式的返回，從而觸發了protobuf的長度檢查邏輯。這個長度在protobuf 3之前的版本被限制爲64M，支持通過setSizeLimit()方法來修改。

實際上，大多數Hadoop項目都會使用shaded protobuf並修改這個限制。由於Kylin項目中未使用自己打包的protobuf，因此這裏需要通過接口修改長度限制。

相關討論見：KYLIN-3973。

>>>>

HBase寫大文件的異常

當Cube的預計算結果數據量比較大，單HBase region的文件大小超過配置的閾值時，向HBase 2.2寫文件會造成海量的小文件。這一步發生在將計算的結果轉換爲HFile時，此步驟的任務執行時間也比較長。這是由HBase 2.2的BUG導致，HBase的修復方案已合入最新分支。可以移植該patch以解決問題，也修改配置hbase.hregion.max.filesize來解決。

相關討論見：HBASE-22887、KYLIN-4292、KYLIN-4293。

>>>>

部分數據構建任務失敗

遷移過程中有兩種數據構建任務的失敗：包更新導致的失敗、segment合併的失敗。

由於Kylin的任務機制，在提交任務的時候就已經指定了使用的jar包的絕對路徑。如果Kylin的依賴升級後，jar包版本號發生了變化，就會導致執行異常。社區版本尚未修復，可以通過保留原來版本的文件來避免該問題。相關討論見：KYLIN-4268。

另外，多集羣的HBase配置僅支持了查詢引擎，在合併最新生成的HBase表時會出現異常。我們認爲segment合並可以接受一定時間的延遲，在HBase表同步完成後再觸發相關合並操作即可。

總結與展望

本次Kylin的HBase跨集羣遷移和版本升級的挑戰點是如何保證對用戶的影響最小。遷移的重點是設計一個高效遷移方案、保證遷移過程的數據一致性和正確性、保證測試方案的完整覆蓋，同時需要設計執行過程中的異常情況的判定和處理機制。

最後的Kylin滾動升級過程耗時2小時，也就意味着用戶作業的調度延後爲2小時。基於前期的大量工作，最終實現了對業務的影響最小。我們在維護的內部版本的基礎上，通過技術修改優雅解決問題，相關成果也反饋給社區。

>>>>

後續改進

目前使用HBase作爲Kylin的預計算結果存儲有着諸多問題。除了本文提到的海量表，還包括不支持第二索引、查詢引擎無法分佈式、掃描表的數據量和時間存在限制等問題，這些都限制了Kylin的能力。社區正在實現Kylin on Parquet的方案，數據存儲使用Parquet，查詢引擎使用SparkSQL，此方案能夠極大的提升Kylin的能力。我們期待該方案的落地，也會積極的參與相關討論、開發和測試。

致謝

感謝HBase團隊同學在遷移期間的給力支持！

關於我們

小米雲平臺計算平臺團隊，負責爲小米集團各業務線提供高品質的彈性調度和計算服務。包括離線平臺（Spark，Hadoop Yarn，Kylin，Doris等），流式平臺（Kafka，Flink及自研Talos等），彈性平臺（Docker，Kubernetes等）。武漢團隊主要負責Kylin、Druid等OLAP引擎開發。