小米Kylin平滑遷移HBase實踐


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

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

往期文章回顧:Talos網卡負載優化:基於個性化一致性哈希的負載均衡

  背景     

小米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或報表系統。本次升級希望儘量減小對業務的影響:

  1. 遷移數據和切換集羣期間,查詢服務不中斷;

  2. 項目、數據模型和cube的新增、更改、發起構建、發起合併等操作不受影響;

  3. 數據構建任務可延後調度,但不能超過天級別;

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

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

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

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

  1. Kylin metadata不斷變化,Cube預計算數據存量巨大且在持續增加;

  2. metadata可以做到秒級別同步,Cube預計算數據只能做到天級別(存量)和小時級別(增量)的同步;

  3. metadata新舊集羣保證一致,Cube預計算數據遷移過程中保障可用;

如下圖所示:

圖1-通常方案的問題

  遷移方案     

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

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

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

  1. Kylin支持連接多個HBase集羣

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

  1. 任務調度支持安全模式

安全模式下,用戶可繼續提交構建任務,且已在調度中的任務可以繼續執行,但新提交的任務暫緩調度。(已提交社區: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

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

聯繫方式:[email protected]

參考資料

[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


我就知道你“在看”

發佈了74 篇原創文章 · 獲贊 92 · 訪問量 8萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章