滴滴HBase大版本滾動升級之旅

桔妹導讀：滴滴HBase團隊日前完成了0.98版本 -> 1.4.8版本滾動升級，用戶無感知。新版本爲咱們帶來了豐富的新特性，在性能、穩定性與易用性方便也均有很大提高。咱們將整個升級過程當中面臨的挑戰、進行的思考以及解決的問題總結成文，但願對你們有所幫助。

1. 背景

目前HBase服務在我司共有國內、海外共計11個集羣，總吞吐超過1kw+/s，服務着地圖、普惠、車服、引擎、金融等幾乎所有部門與業務線。

然而有一個問題持續困擾着咱們：版本較社區落後較多——HBase線上集羣使用0.98版本，而社區目前最新的release版本爲2.3。這爲咱們的工做帶來了不少額外的掣肘與負擔，主要包括如下幾點：

• 新特性引入成本極高：

0.98版本能夠算是HBase第一個穩定版本，但過於老舊，社區已經再也不維護。想要backport新特性難度愈來愈大。

• 自研patch維護成本較高：

咱們基於0.98版本有數十個大大小小的自研patch，涵蓋了從label分組、ACL鑑權等大的feature到監控體系建設、審計日誌優化等Improvement以及各類bug fix。這些patch或是新版本中已支持但和咱們實現有差別，或是因爲版本差別過大沒法合入社區，並且隨着時間線的拉長，這種問題只會進一步惡化。

• 上層組件對於HBase存在必定需求：

得益於活躍的HBase生態圈，目前咱們的用戶使用形態也比較豐富，OLAP（Kylin）、時空索引（GeoMesa）、時序（OpenTSDB）、圖（JanusGraph）等等場景不一而足。然而這些上層引擎無一例外，最新版本沒有任何一款是依賴0.98版本HBase的。

所以對於HBase團隊而言，升級迫在眉睫刻不容緩。

2.挑戰

首先簡單介紹一下HBase的架構。HBase是一個典型的主從結構——主備Master用於管理集羣；RegionServer用於響應處理用戶讀寫請求；使用ZooKeeper保障集羣內的一致性；節點間經過RPC通訊；底層數據文件HFile存儲於HDFS中。

此外HBase具備至關豐富的上下游生態，從以StreamingSQL爲表明的實時任務到Spark、MR等批處理任務，經過下圖能夠得窺一二：

基於以上對集羣架構和上下游生態的梳理，能夠明確升級過程當中咱們主要面臨的挑戰有：

• RPC接口兼容性問題：

升級不可能一蹴而就，所以咱們須要確保全部RPC通訊接口新舊版本完美兼容。

• HFile兼容性問題；

不一樣版本中底層文件的數據格式有差別。1.4.8版本默認使用HFile v3，幸運的是0.98版本雖然使用HFile v2，但已經能夠兼容v3。這樣咱們就不須要再額外backport相關patch到0.98版本。此外也是基於這方面的因素，官方文檔中說明0.98版本想要升級到2.x版本，必須以1.x版本做爲過渡——這也是咱們本次升級選擇1.4.8版本的緣由。

• 自有patch兼容性問題：

如上文所述，咱們須要全量梳理自研的數十個patch——高版本是否有替代方案、替代方案是否兼容、是否須要移植到新版本、移植後的功能/性能/兼容性測試等。

• 上下游兼容性問題：

這一點你們看上圖就好不需再贅述，每一種引擎的應用都需確保徹底兼容。

• 可能引入的新問題：

HBase的社區release版本迄今仍然很是活躍，但同時這也意味着可能存在不少潛藏的問題（事實上咱們在升級過程當中也遇到了，解決了並反哺給社區）——這一點其實沒有什麼太好的辦法，只能要求咱們隨時緊密跟進社區，洞察新進展，即時發現問題修復問題。

基於以上這些挑戰點，其實不可貴出一個結論：咱們須要設計並實施大量的前置準備工做以保證升級過程的可靠性，但這並非什麼壞消息，由於只要咱們的準備工做足夠細緻完善，順利升級的把握和信心也就越強——這個思路在咱們從此的工做中也一樣適用。

下面簡單列舉了咱們完成的準備工做：

• Release Note review
• 自研patch移植與測試
• 基礎功能測試、性能測試
• 高階功能測試（Bulkload，Snapshot，Replication，Coprocessor等）
• 社區後續小版本patch梳理跟進（截止目前實際合入的有100餘個）
• 跨版本兼容性測試、RPC接口兼容性梳理
• 全量測試集制定與實施，涵蓋HBase ，Phoenix，GeoMesa，OpenTSDB，Janusgraph等全部使用場景
• 軟件包及配置文件準備

3. 升級方案

升級方案主要有兩種：新建集羣+數據遷移 和 滾動升級。

實際上滾動升級的方案必定是最優選，主要是出於對「release版本仍然不夠穩定」的擔心，咱們一度有所猶豫。但最終基於「充分的準備與測試」帶給咱們的信心，最終咱們仍然選擇了滾動升級。

簡單說明滾動升級的大體步驟：

1. 解決兼容性問題，主要體如今新建rsgroup元數據表並重寫數據、
2. 掛載新的coprocessor等；
3. 升級master節點；
4. 升級meta分組；
5. 依次升級業務分組；

4. 實操及問題

咱們從19年下半年啓動了這一輪滾動升級的調研與準備，今年3月下旬正式開始線上操做，截至5月初已完成了國內外共計9個集羣的升級工做，用戶無感知。

在此期間咱們也遇到了很多未解問題，這裏摘取一個Critical問題作簡單介紹：

region split過程當中疊加RS宕機引起數據丟失：

region split是一個至關複雜的事務過程，大致可分爲如下幾步：

• RegionServer開始執行split事務，在ZK region-in-transition下建立該region的節點，標記爲SPLIT；
• Master監聽到新的split節點，開始作一些初始化工做，並修改內存狀態，完成後將節點狀態改成SPLITING；
• RS監聽到節點狀態變爲SPLITING，開始正式執行split——關閉父region、建立子region文件夾並添加引用文件、修改meta表記錄兩個子region並將父region下線；
• 子region上線；

當父region下線、子region還未正式上線時RegionServer宕機，master上的ServerCrashProcedure線程開始進行回滾，會將子region刪除；此外master上還有一個CatalogJanitor線程作數據清理，正常split過程當中因爲ZK上存在對應節點，這個線程會被阻塞；然而因爲RS宕機，臨時節點也隨之消失，該線程正常工做，判斷meta表中父region已經下線，從而將父region刪除——至此父子region皆被刪除，致使數據丟失。
修復方案已提交社區：HBASE-23693

其它patch list：

• HBASE-22620 修復replication znode積壓問題；
• HBASE-21964 支持按Throttle Type取消quota設置；
• HBASE-24401 修復 hbase.server.keyvalue.maxsize=0 時append操做失敗的問題；
• HBASE-24184 修復只使用simple ACL時snapshot相關操做的鑑權問題；
• HBASE-24485 Backport，優化堆外內存初始化時間；
• HBASE-24501 Backport，去除ByteBufferArray中非必要的鎖；
• HBASE-24453 Backport，修復挪動表分組時缺乏校驗邏輯的問題；

5. 總結

本次升級工做從立項到完結耗時近一年，可以成功完成很是開心。一方面本次升級極大拉進了內部版本與社區release版本的距離，爲更加良性的版本迭代及社區互動夯實了基礎；另外一方面新版本引入了諸多新特性，在穩定性、易用性方面都爲咱們帶來了更爲廣闊的成長空間；更重要的是在這個過程當中咱們自身也沉澱出了一套系統的工做思路與方法論，期待後續能夠更好的爲業務賦能，爲公司創造價值。

---

做者簡介

滴滴資深貓奴，專一於HBase內核研發，滴滴HBase服務及上下游生態的建設與維護。

**歡迎關注滴滴技術公衆號！

滴滴技術 出品