背景小米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引擎開發。

we want you

北京武漢均有職位，歡迎優秀的你加入~

聯系方式：computing-hr@xiaomi.com

參考資料[1] Apache Kylin跨機房遷移實戰?https://blog.bcmeng.com/post/kylin-migrate.html[2] KYLIN-4175: Support secondary hbase storage config for hbase cluster migration?https://issues.apache.org/jira/browse/KYLIN-4175[3] KYLIN-4178: Job scheduler support safe mode?https://issues.apache.org/jira/browse/KYLIN-4178[4] KYLIN-3973: InvalidProtocolBufferException: Protocol message was too large. May be malicious.?https://issues.apache.org/jira/browse/KYLIN-3973[5] KYLIN-3997: Add a health check job of Kylin?https://issues.apache.org/jira/browse/KYLIN-3997[6] KYLIN-4268: build job failed caused by hadoop utils update?https://issues.apache.org/jira/browse/KYLIN-4268[7] HBASE-22887: HFileOutputFormat2 split a lot of HFile by roll once per rowkey?https://issues.apache.org/jira/browse/HBASE-22887[8] KYLIN-4293: Backport HBASE-22887 to Kylin HFileOutputFormat3?https://issues.apache.org/jira/browse/KYLIN-4293[9] [DISCUSS] Columnar storage engine for Apache Kylin:?http://apache-kylin.74782.x6.nabble.com/DISCUSS-Columnar-storage-engine-for-Apache-Kylin-td11821.html猜你喜歡

1、Delta Lake 0.5.0 正式發布，支持包括 Hive/Presto 等多種查詢引擎

2、當小內存遇上大量數據，你該怎么解決這個問題？

3、從 Hive 大規模遷移作業到 Spark 在有贊的實踐

4、Docker 核心技術與實現原理

過往記憶大數據微信群，請添加微信：fangzhen0219,備注【進群】

總結

以上是生活随笔為你收集整理的与kylin_Kylin 迁移到 HBase 实践在小米的实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。