百家乐必知技巧
數據庫

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

  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表中,兩個集群的此表保持同步更新。

2、Kylin支持連接多個HBase集群

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

3、 任務調度支持安全模式

安全模式下,用戶可繼續提交構建任務,且已在調度中的任務可以繼續執行,但新提交的任務暫緩調度。(已提交社區: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,Drois等),流式平臺(Kafka,Flink及自研Talos等),彈性平臺(Docker,Kubernetes等)。武漢團隊主要負責Kylin、Druid等OLAP引擎開發。

小米云平臺部,主要分享云存儲、云計算、系統、網絡、運維、私有云、安全、數據庫、內核等內容,歡迎感興趣的朋友們關注!

萬萬沒想到,HashMap默認容量的選擇,竟然背后有這么多思考!?

上一篇

盜版12306騙3000萬人下載,暴利高仿App是如何花式撈錢的?

下一篇

你也可能喜歡

小米Kylin平滑遷移HBase實踐

長按儲存圖像,分享給朋友

ITPUB 每周精要將以郵件的形式發放至您的郵箱


微信掃一掃

微信掃一掃
百家乐必知技巧 体彩p5 下载手机棋牌游戏五张 河南快三遗漏值 北京快中彩开奖走势图 牌九变牌技术 内蒙古快三 重庆快乐10分走势图 我爱玩棋牌 斗地主 14场胜负彩18088期对阵 快乐飞艇