摘要：?# 前言 時間回到2011年，Hadoop作為新生事物，在阿里巴巴已經玩得風生水起，上千臺規模的"云梯"是當時國內名聲顯赫的計算平臺。 這一年，Hadoop的好兄弟HBase由畢玄大師帶入淘寶，開啟了它的阿里之旅。

前言

時間回到2011年，Hadoop作為新生事物，在阿里巴巴已經玩得風生水起，上千臺規模的"云梯"是當時國內名聲顯赫的計算平臺。
這一年，Hadoop的好兄弟HBase由畢玄大師帶入淘寶，開啟了它的阿里之旅。從最初的淘寶歷史交易記錄，到去年的支付寶消費記錄存儲在線歷史存儲統一；從螞蟻安全風控的多年存儲演進，到HBase、TT、Galaxy的大數據激情迭代；HBase在阿里經歷過年輕的苦澀，釋放過青春的活力，也付出過成長的代價。幾代人的不懈努力下，五年陳的HBase開始表現出更成熟、更完善、更豐富的一面，成為公司內部被廣泛使用的存儲產品之一。
經過阿里集團內部的錘煉，集團將這個技術紅利輸送給廣大阿里云客戶。現已推出云數據庫HBase產品，支持海量的PB級的大數據存儲，適用于高吞吐的隨機讀寫的場景。目前免費公測中，查看申請

本篇會系統性的闡述HBase的定位、建設思路，其中相關內容可能并未深入展開，后續會有專項介紹，請大家隨時關注云棲社區相關文章。

概述

HBase是一個開源的非關系型分布式數據庫（NoSQL）,基于谷歌的BigTable建模，是一個高可靠性、高性能、高伸縮的分布式存儲系統，使用HBase技術可在廉價PC Server上搭建起大規模結構化存儲集群。

HBase最初是以Hadoop子項目的形式進行開發建設，直到2010年5月才正式成為Apache的頂級項目獨立發展。伴隨著互聯網時代數據的澎湃增長，HBase作為基礎存儲系統得到了快速發展與應用，大批知名商業公司(Facebook、Yahoo、阿里等)不自主地加入到了HBase生態建設隊伍，成為Apache最活躍的社區之一。

HBase的能力特點，可以簡單概括為下表，基于這些能力，其被廣泛應用于海量結構化數據在線訪問、大數據實時計算、大對象存儲等領域

阿里從2011年初開始步入HBase的發展、建設之路，是國內最早應用、研究、發展、回饋的團隊，也誕生了HBase社區在國內的第一位Committer，成為HBase在中國發展的積極布道者。過去的幾年時間，阿里累積向社區回饋了上百個Patch, 在諸多核心模塊的功能、穩定性、性能作出積極重大的貢獻，擁有多位Committer，成為推動HBase的長遠發展的重要力量之一。

阿里是一家綜合生態型公司，內部龐大業務矩陣高速發展，在基礎存儲方面，需要更好的功能靈活性、基礎設施適應性、服務穩定性、效率成本。
因此，阿里HBase團隊發展維護了HBase的內部分支，其基于阿里巴巴/螞蟻金服的環境和業務需求，對社區HBase進行深度定制與改進，從軟件系統、解決方案、穩定護航、發展支撐等全方位提供一站式大數據基礎存儲服務。

HBase在阿里的使用

Ali-HBase作為阿里巴巴大廈的基礎存儲設施，全面服務于淘寶、天貓、螞蟻金服、菜鳥、阿里云、高德、優酷等各個領域，滿足業務對于大數據分布式存儲的基本需求。

在剛剛過去的2016年雙11，HBase承載訪問量達到了上百GB/秒(寫入)與上百GB/秒(讀取)，相當于全國人民一秒收發一條短信，在業務記錄、安全風控、實時計算、日志監控、消息聊天等多個場景發揮重要價值。面對如此規模的業務體量，阿里巴巴團隊對于如何基于HBase打造穩定、高效、易用的存儲服務，形成了一套完善的產品體系與實踐經驗，其整體大圖如下：

總體上，我們以定制的軟件內核為中心，建設質量平臺、運維平臺、業務平臺和數據流設施四大內容，以支持業務對于基礎數據服務的全方位需求。

接下來，本文會圍繞可用性、數據流、性能優化等方面介紹最近的一些具體工作，希望能夠給相關領域的同學帶來一點幫助。

高可用建設

服務持續可用是互聯網系統的顯著特征，但由于物理環境、軟件Bug的不確定性，要做到系統的高可用往往不是一件容易的事，尤其是對于有狀態的存儲系統而言。今天，我們統一使用SLA(服務等級協議)去衡量一個分布式系統的可用性，比如SLA達到99.99%的系統，其全年的不可用時間小于52.6分鐘；99.999%的系統，其全年的不可用時間小于5.25分鐘，達到這個能力的系統一般可以稱之為高可用。

面對斷電、斷網、硬件故障等物理機房的不可靠性，任何一個高可用系統必須通過雙機房，甚至多機房部署的方式進行容災。對于存儲系統，這就要求數據能夠在機房間冗余復制，并保證各個機房的數據對上層應用的一致性。所以，高可用建設是我們過去很長時間的重要工作。

集群異步復制

Apache HBase從0.92版本開始支持Replication功能，它會實時地、異步地將一個HBase集群中的增量數據復制(推送方式)到另一個HBase集群，當主集群故障不可用時，應用可以切換訪問到備集群，從而實現數據與服務的機房容災。關于HBase Replication的基本原理，讀者可以從社區官方Book中獲得詳細內容，本文便不再闡述。
下面的篇幅，將主要介紹阿里在使用Replication過程中的經驗與改進，期望能和在類似場景工作的同學有所共鳴。

復制效率

由于在線業務的可用性要求，阿里HBase很早便開始使用Replication功能去部署雙機房容災，迎之而來的第一個大問題是數據復制的效率，尤其異地遠距離部署（比如上海與深圳跨城復制）時更加嚴重，表現為數據復制的吞吐小于客戶端寫入主集群的吞吐，數據不斷積壓，延遲逐漸增大，只能等待凌晨低峰期逐漸消化。我們對此進行深入分析，著重優化了以下幾點，才得以保障跨城集群復制也能穩定保持在秒級內。

1. 提升源端發送效率?
   HBase Replication的基本數據復制過程是源端串行讀取HLog的內容，發送到目標端機器，由目標端解析HLog并寫入數據寫。我們發現，因為源端的串行讀取、發送HLog，當集群寫入吞吐大的時候，會存在嚴重的性能瓶頸，為此，我們重構了這一塊邏輯，將HLog的讀取與發送解耦，并且發送由單線程優化為多線程，使得整體的源端發送能力大幅提升。

2. 提升目標端Sink效率?
   在Replication的默認實現中，源端會按照HLog的原始寫入順序進行回放。為了提升目標端的寫入效率，我們將所有待發送的HLog先進行排序，使得同表同Region的數據都能合并處理，同時將目標端的數據寫入盡量并行化。

3. 熱點輔助?
   盡管做了以上兩點后，集群間的數據復制能力大大增強，但是個別服務器仍然會由于負載過大，而產生一定的復制延遲。從本質上來說，這是因為HBase的服務器分配了更多的資源服務于來自客戶端的寫入請求，當某個服務器成為集群中的寫入熱點并高負載工作時，這個節點的數據復制基本很難再消化龐大的寫吞吐。這是一個曾困擾我們很久的問題，你可以用一些運維的方式去解決。比如開啟更多的線程數，但這并不能總有效。因為服務于客戶端的線程數，要遠遠大于Replication的線程數。再比如從熱點服務器移走Region，降低吞吐與負載，但熱點并不保證是恒定的，可能會跳躍在各個服務器，我們也開發了新的基于歷史監控的負載均衡算法，以盡可能地讓請求均衡。

很多時候，通過運維管理手段能夠控制影響、化解問題，但當你需要維護上百個集群時，一點一滴的運維要求慢慢堆積成很高的壁壘。所以，我們嘗試改進系統能力，用自動、一勞永逸地方式去解決熱點下的數據復制積壓問題。面對熱點的基本思路是散列，在這個具體場景上，我們打破原先的自生產自推送的設計，利用整個集群的能力，使得熱點服務器上積壓的數據(HLog文件)，能夠由集群中的其他空閑服務器進行消化。

1. 配置在線調整?
   配置的在線調整不僅能極大提升運維幸福感，而且對于系統改進可以產生更加敏捷的反饋。這并不新鮮，但這是一項十分重要的能力，我們在系統改進的道路上也對其特別重視。HBase的Replication功能會有很多參數，我們將其全部優化為可在線調整，給日常的服務支撐帶來了很大的價值。

多鏈路

業務多地多單元部署是阿里技術架構的一項重要特征，這要求基礎存儲具備數據鏈路的靈活流動性。今天，阿里HBase會在多地部署多集群，集群間數據相互流動，以滿足單元化業務的需求。

在支持數據多鏈路的生產應用上，我們總結了以下幾個要點

1. 表級別鏈路?
   當一個HBase集群啟用多個數據鏈路后，我們期望自由設置表的數據可以被復制到其中的一個或多個鏈路，使得整個數據的流動更加靈活。為此，我們增加了一種特性，通過設置表的屬性，以決定該表的數據流向哪些鏈路，使得整個數據流動圖可以由業務架構師任意設計，十分靈活。此外，當需要在集群間熱遷移數據時，它也能帶來十分重大的作用。 整體效果如下，以表為單位數據可以任意流動：

1. 鏈路可視?
   當數據可以在多個集群任意流動后，一個很迫切的需求是鏈路拓撲以及復制狀況的可視。為此，我們強化了Replication的信息層，不僅源端保留它到多個目標的鏈路信息，而且每個目標端也會保留多個源端到它的鏈路信息，從而我們可以從任意一個集群繪制整個鏈路拓撲圖。同時，我們極大豐富Replication的運行狀況信息，并將之匯聚到HBase的Master節點，由其統一匯總展現，從中我們可以清晰得到數據是否積壓、復制的性能瓶頸、節點間的均衡情況、具體的延遲時間等信息，其中復制的延遲時間是一個十分關鍵的信息。 基本信息如圖

1. 循環復制?
   在數據多鏈路下，會產生一些循環復制的場景。比如集群A->B->C->A，這是一個簡單的鏈接式復制，當數據流過某個集群時，HBase Replication會在數據中添加該集群ID的信息，以防止同一條數據被多次流經同一個集群，基于這個設計，即使復制鏈路存在環，數據也不會產生無限循環流動。但是，仍然有一個效率問題不得不提，對于A<->B<->C<->A這樣一個數據鏈路，我們發現客戶端寫入到A集群的數據，在B集群和C集群上會被復制寫入兩次，一次通過A->B鏈路寫入，另一次通過A->C->B鏈路寫入。所以，為了避免這種寫入放大，需要在鏈路部署上防止產生這種環。在過去實踐的一些場景，發現這種環狀鏈路不得不存在，所以系統層面，我們也對Replication做了相關優化，以去除這種寫入放大。

2. 鏈路隔離?
   當源集群配置了多個數據鏈路后，我們總是期望這些鏈路之間相互隔離，不會因為一個鏈路的積壓影響其他鏈路。在大多數時候，這一切都如預期工作，但當集群故障時，糟糕的事情發生了，我們發現一個異常鏈路會阻塞全部鏈路的復制恢復，究其原因，是因為在數據復制的恢復期間，很多資源是所有鏈路共享的。所以，這些資源的鏈路解耦成為我們的工作，同時，也好好對數據復制的宕機恢復速度進行了優化。

數據的一致性

今天，大多數生產系統會使用異步方式去實現集群間的數據復制，因為這樣效率更高、邏輯更清晰。這意味著，集群間數據是最終一致模型，當流量從主切換到備，從備上無法訪問完整的數據，因為復制存在滯后，并且當主集群永久不可恢復，數據也會存在部分丟失。

為了滿足業務場景的強一致需求，我們采用了兩種方式。

第一種，異步復制下的強一致切換。雖然備集群的數據集滯后于主集群，但是在主集群網絡健康的情況下，仍然可以保障切換前后數據的強一致。
其基本過程如下，首先讓主集群禁止數據寫入，然后等待主集群的數據全部復制備集群，切換流量到備集群。這里存在兩個依賴，一個是集群的寫入控制功能(支持禁止來自客戶端的數據寫入)，另一個是復制延遲的確定性，雖然數據是異步復制的，但是我們將數據的復制時間點明確化，即該時間點之前寫入的數據已經完全復制到了備集群。

第二種，數據復制使用同步的方式。即當數據寫入返回客戶端成功后，能保證數據在主備集群均已寫入，從而即使主集群完全不可恢復，數據在備集群中也能保證完整。

為了滿足類似場景的需求，阿里HBase研發了同步方式的集群間數據復制，具體內容可參考下一節。

冗余與成本

數據在集群間的冗余復制，給系統的可用性帶來了數量級的提高，但同時也意味著更大的成本開銷，在保證可用性下如何優化成本是一個需要重點思考的問題，阿里HBase在這方面投入了較大精力的嘗試，具體內容將在接下來的"性能與成本"章節進行介紹。

集群同步復制

上文提到，HBase集群可以使用異步方式的數據復制來構建雙機房容災，當主集群故障不能提供服務時，就會切換請求到備集群，保障系統整體高可用。然而，異步復制模式下存在的問題是：在服務切換后，由于主備集群間的數據并非強一致，存在部分數據無法通過備集群獲取或者訪問到的內容過舊。也就是說，如果應用對于數據訪問具有強一致要求，現有的異步復制設計，無法在主集群故障時，仍然保證系統的高可用。

為此，阿里HBase團隊投入研發集群同步復制功能，使得主集群不可用時，備集群的數據能達到和主集群完全一致，業務可以無感知的切換到備集群。相比于異步復制，同步復制會帶來的額外的開銷，但整個寫入吞吐/性能的影響，在我們的設計中，做到了盡量的相近。其整體功能點如下：

1. 數據強一致性保證。數據寫入主備集群，主集群不可用后，備集群可以恢復所有在主集群寫入成功的數據

2. 高性能。主備集群HLog寫入采用異步并行的方式寫入，對寫入性能影響微弱

3. 列族級粒度。列族級別的配置，支持同集群下同個表的不同列簇可以使用不同的復制方式，同步或異步。

4. 同異步復制共存。任何情況下，同步復制表的任何操作不會影響異步表的讀寫。

5. 靈活切換。備集群不可用，同步復制可以一鍵切換為異步復制，不阻塞主集群寫入。

關于數據的強一致，我們進行了如下定義：

1. 返回應用成功，則一定主備都寫成功

2. 返回應用錯誤，則未決(主備是否成功不能確定)

3. 數據一旦讀取成功，則主備永遠均可讀，不會出現主讀成功切換至備后讀不到或者備讀得到主讀不到的情況

4. 任何情況下，保證主備集群的最終一致性

我們遵從簡單、高效的原則去設計同步復制功能，簡單意味著該功能與原核心邏輯保持最大程度的隔離，能夠快速達到生產穩定性要求，并能很好地降級成異步復制；高效意味著主備必須并行寫，這在錯誤處理上增加了不少的難度。整體實現方案如下：

1. 客戶端向主集群寫入數據的時候，會并行寫入兩份Log，一份是本地HLog文件，另一份是備集群的HLog文件，我們稱之為RemoteLog.兩者皆成功，才返回客戶端成功。

2. RemoteLog僅在故障切換后，用以回放數據。正常運行時，不做任何使用，備集群的數據仍然通過現有的異步復制鏈路寫入。同時，可以通過停寫RemoteLog，把同步復制降級成異步復制。

3. HBase數據的多版本特性，使得基于HLog的操作回放具有幕等性，所以，在故障切換后，RemoteLog中的數據回放會存在一定的重復，但不會影響數據正確性。

4. 主備集群存在Active和Standby狀態，只有Active狀態的集群才能接受客戶端的數據寫入

5. 在備集群切換為Active狀態之前，會對RemoteLog全局上鎖，從而防止客戶端寫入數據到主集群返回成功。這也意味著，主備集群在任何時刻，只有一個處于Active狀態，不會有腦裂發生。

6. RemoteLog會定期由主集群清理，主集群服務器的一個HLog文件對應一個或多個RemoteLog，所以當主集群的HLog文件中的數據被完全復制到備集群后，相應的RemoteLog就可以被刪除。

其基本結構如圖

在這里，主備角色是不對等的，我們通過部署進行分配。其中，主->備使用同步復制模式，一旦流量切換到備后，備->主使用異步復制模式。

由于主備雙Log的并發寫入，使得同步復制的性能能夠與異步復制接近，在實際使用中，我們觀察到客戶端寫入響應時間增加小于10%。最后，我們列舉一些應用同步復制容災的場景，以供大家參考。

1. 基于狀態變更數據的場景。HBase中提供了CheckAndMutate接口，用以支持條件寫入/更新/刪除，其含義是當某一條件達成時，才執行該寫操作。這意味著查詢到的數據必須是強一致的，不然就會寫入錯誤的數據。比如，對于一筆交易記錄，其狀態只能從“已付款”變更為“已發貨”，而不能從其他狀態變更為“已發貨”，所以在數據更新時需要做狀態的條件判斷。

2. 日志/消息的順序訂閱。對于日志/消息產品而言，訂閱數據的完整性是其最核心的保證，也就是說通過HBase進行Scan的時候，必須保證能掃描到范圍內的每一行數據。如果切換后，主備數據存在不一致，則會出現scan過程中跳過某些數據，造成訂閱少數據。

3. 流計算。由于流計算不停地基于中間結果和新的數據流進行迭代處理，作為存儲中間結果的數據庫，必須時刻具備數據的強一致，才能保證數據計算結果的正確性。

總結

集群間的數據復制是HBase用來構建機房容災、提供高可用性的重要武器，阿里HBase通常使用異步復制方式部署，著重改進其在復制效率、多鏈路、一致性等方面的能力。同時，也研發了一種高效的同步復制方式，以滿足數據強一致場景的容災需求。

數據傳輸管道設施

數據流動的訴求

在大數據的發展背景下，沒有一個系統可以處理所有的場景。因此，打通各個系統之間的數據通道，讓數據在在線存儲、實時分析、離線計算中高速流動，形成閉環，是打造大數據平臺、挖掘數據價值的關鍵一環。

HExporter系統

HBase作為一款高吞吐的在線數據存儲系統，我們希望其能高效、準確地吐出數據，以滿足業務對數據計算分析的多元化需求，這是我們建設HExporter系統的出發點。

HBase業務的數據規模飛速增長，單個業務數據量達到10T，百T級別非常常見，且越來越多的業務要求同步數據到離線計算系統進行計算。同時大部分離線計算任務是周期型，比如按天為單位進行計算，因此數據要按時間分區進行同步并保證單調性，這需要一個高效的時間分區增量方式的數據導出方案來應對日益增長的需求。這是我們建設HExporter系統的場景。

基于以上出發點和場景，我們期望建設一個實時的、高效的HBase數據管道設施，使得寫入到HBase系統的數據可以方便地傳輸復制到其他異構系統，
讓數據因為流動、計算、加工而產生新的價值。為此，阿里HBase團隊投入研發HExporter系統，其整體上具備以下能力：

1. 實時性。數據可以秒級復制到其他異構系統

2. 準確性。保證數據在HBase與其他系統間的最終一致性

3. 高吞吐。支持調整緩沖等級和壓縮等級，從而協調數據生產端和數據消費端的能力，達到最大的吞吐量。在實際應用中，HExporter可以有效使用95%的網絡帶寬并保持穩定運行。

4. 容災性。HBase主備容災模式下，數據能夠正常傳輸。

5. 時間確定性。明確標注同步時刻，該時刻之前寫入的數據都已經傳輸完成?；诖耍ＷC計算系統對某個時間分區的完整數據進行計算。

6. 可降級。支持按表取消數據傳輸。

7. 監控告警。支持傳輸延遲的監控與告警。

HExporter系統的整體架構如下:?

1. HExporter的數據是由HBase系統“推送”過來的，其利用了HBase系統本身的內部數據復制機制，模擬了備庫的角色。HBase的RegionServer將自身的數據打包，隨機發送到HExporter的采集節點。每一個數據包隨機的選擇采集節點，因此采集節點之間是完全對等的，可以動態的增加節點來提高HExporter的接收能力，它是水平可擴展的。為了支持主備模式下的HBase，HExporter需要同時采集主備集群，保證客戶端寫入HBase的數據不會因為主備間的網絡中斷而延遲采集。此時需要解決數據去重的問題：HExporter在收到數據包時，會檢查數據包的標記，這個標記表示了數據是否來自于最源端（客戶端寫入的集群），如果不是則直接拋棄這個數據包。

2. 大部分離線計算任務是周期型，比如按天為單位進行計算，數據要按時間分區進行同步，因此消費數據時必須能夠獲取時間信息。HExporter提供兩個維度的時間供消費方使用：業務時間(數據的生成時間）和存儲時間(數據寫入HBase的時間)。

3. 同步時間點指的是一個時刻，在該時刻之前寫入HBase的數據都已經被HExporter采集。由于數據的推送是隨機的，因此到達采集節點的數據在時間上是亂序的，同步時間點利用HBase在Zookeeper上記錄的日志信息計算每個RegionServer的同步時間點，最后選擇所有RegionServer同步時間點中的最小值記為集群的同步時間點。由于同步時間點的計算是保障數據有序的關鍵，必須能夠容忍宕機等問題。在HExporter的設計中，每一個采集節點都可以計算同步時間點，所有節點競爭同一個鎖（依賴Zookeeper實現），從而獲得這一輪計算同步時間點的權利。只要有一個采集節點存活，同步時間點的計算就可以正常工作。

目前，HExporter作為阿里HBase系統的基礎數據傳輸管道設施，每天有上百TB的數據被傳輸到離線計算平臺、在線分析引擎、搜索引擎等系統，這些系統協力配合滿足應用豐富多樣的數據需求。

性能與成本

數據冗余的背后

前面章節提到，我們使用數據在集群間的冗余復制來提高系統可用性，對于主備容災，這意味著我們需要花費一倍的額外成本來換取高可用，能不能降低開銷成為高可用能力是否可以普及的重要門檻。

跨集群分區數據復制

HBase使用HDFS作為其文件存儲系統，底層數據存儲默認使用三副本冗余以保障數據的可靠性，這也意味著HBase內部的HLog、Flush、Compaction過程會產生三份數據流量和存儲空間，包括網絡和磁盤。如果HBase的底層副本數能夠從3降低為2，很大程度上可以減少近1/3的成本，但是2個副本在實際運行中的數據丟失率仍然是不小的。所以，對于數據可靠性有要求的環境，三副本是最基本的要求。但是，當我們部署主備容災后，全局擁有了六個副本，能否降低單個集群的副本為兩個，全局從六個副本降低成四個副本，這成為資源優化的重要入口。

為了容忍單集群在兩副本下的數據丟失，我們需要建立跨集群的分區數據復制機制，使得當某一個集群數據文件丟失時，可以快速地從另一個集群進行恢復。為了適用于更多的場景，比如集群遷移、一鍵建站，我們在設計上會更加通用，支持將某個表的指定范圍數據高效、準確地復制到指定集群，整體功能可以概括如下:

1. 簡單。可以通過一個接口或者命令執行復制，并在系統UI上實時顯示進度。

2. 快速。整個復制任務會進行拆分，并由不同節點完成，大大提高速度。

3. 容錯和災難恢復。復制過程中任何出錯和宕機都能自我恢復。

在實現上，其類似于分布式任務調度，每一個提交的復制作業，會按照RowKey范圍拆成多個子任務，并且子任務的起止范圍是Region的子集，由Master派發給集群中的服務器，并保證失敗后的重新派發。任務調度中的相關數據，統一存儲在zookeeper上，從而保證宕機情況下作業的可恢復性。數據的具體復制根據情況會采用完全拷貝和部分復制兩種方式，如果文件內容的RowKey范圍是子任務的子集，則將其完全拷貝到指定集群；不然，則使用部分復制的方式，在拷貝期間過濾掉無效的數據。

詳細系統架構如下：

圖中的部分角色說明：?
DataMigrationManager: DMM,運行于HBase Master，負責接收復制作業、切割作業為多個子任務、派發子任務、監聽完成情況等。?
DataMigrationWorker: DMW, 運行于HBase Regionserver，負責完成子任務的數據復制到指定集群。?
Job: 一次數據復制作業，由用戶提交，內容包括表名，Rowkey范圍以及指定目標集群的地址信息。?
Task: Job分割后的子任務，多個子任務的Rowkey范圍拼接后組成完整的復制作業的Key范圍。

在擁有跨集群分區數據復制能力后，雙集群雙副本的運行方式得以應用普及，這能有效降低容災成本。
同時，我們的集群遷移、表遷移能力大大增強，在不限流下單節點可以達到70MB/秒，更重要的是這變成了一項能力、一個接口服務，而不是一堆運維操作，大大提升運維效率。

多集群多活服務

對于通常的雙集群容災部署，同一時間只有單個集群提供服務，使得另一個集群在大部分時間內處于資源閑置。為了改善這一情況，阿里HBase使用了以下幾種方式:

1. 業務對于數據無強一致要求，同個業務的部分客戶端訪問主集群，部分客戶端訪問備集群。這種方式對于業務應用部署存在一定的負擔，使其數據庫地址管理復雜化。

2. 交叉部署訪問，支持數據的強一致要求。一般我們會把類似場景的多個業務部署在同個集群中，通過交叉部署，在同一時間，使得一些業務訪問主集群，另一些業務訪問備集群，從而同時發揮兩個集群的資源。

3. 客戶端支持同時訪問雙集群。我們通過改造HBase的客戶端，使其支持同時訪問雙集群，這不僅可以提升集群的資源使用率，還大大降低了訪問毛刺，因為任何超過一定時間的請求都會被重發到另一個集群。

我們經常使用上述一二的方式去優化雙集群容災下的資源使用，并且取得很不錯的效果。?
現階段，由于業務場景對請求穩定性的更高要求，我們開發了“客戶端支持同時訪問雙集群”的功能，以規避單節點抖動（如網絡、磁盤、GC、鎖競爭、熱點）的影響，減少應用訪問HBase的響應毛刺。從實際測試使用看，開啟該功能后，整體毛刺比例下降達到一個數量級以上，有效去除HBase請求服務時間不穩定的影響。

更多性能工作

在過去的幾年，阿里HBase投入了很大的精力去進行系統的性能優化，包括Region級二級索引、Bucket Cache、Small Scan、Reversed Scan等很多重要優化已經反饋給社區，并在開源伙伴的一起努力下，不斷更新迭代，讀者可以從社區了解具體的原理與實現。

剛剛過去的2016年雙11，可以說是HBase的一場圣戰，面對巨大峰值流量從容應戰的背后是我們在性能優化上的很多新型武器。

1. 異步API?
   一直以來，HBase只能使用同步API方式訪問服務，使得吞吐型場景應用端大量線程阻塞在HBase接口，嚴重影響性能，而異步的思想并不陌生。

在去年雙11后，阿里HBase開發實現了一套全新的異步API，使得客戶端不需要阻塞等待到服務端返回結果,通過回調函數執行請求成功或失敗后的業務邏輯，大大提升請求吞吐。我們將其應用于監控、安全、日志等場景，整體寫入吞吐可以提升1至3倍。

1. 前綴BloomFilter?
   HBase利用BloomFilter過濾不必要的文件來提高HBase數據讀的性能，其效果只支持Get不支持Scan；在實際使用場景中，有很多業務Scan操作會掃描具有相同前綴的行，比如物流詳情場景，其Rowkey結構是：物流單號+時間戳，一個物流商品會經歷多個狀態，每有一次狀態轉移需要寫入一行數據，這些狀態正常在10個左右，通過Scan的方式可以查詢一個物流單號下的所有狀態。針對這個場景我們設計了前綴BloomFilter，在業務Scan的起止范圍存在公共前綴下，使得Scan操作也可以使用BloomFilter來過濾文件，大大提升了查詢效率；菜鳥物流詳情開啟前綴BloomFilter后，查詢性能提升一倍，做到大促不擴容，輕松hold住今年大促6.57億包裹的物流詳情查詢。

2. HLog壓縮?
   HLog從0.92版本開始支持字典壓縮，但其與Replication復制沖突，使得其一直無法真正地被使用，而大量在線業務使用寬表結構，幾十個字段的場景比比皆是，HLog的壓縮將有效提升寫入能力。為此，阿里HBase重構了HLog的壓縮機制，與HBase Replication功能完美兼容運行，在消費記錄、數據總線、庫存對賬等多個業務線獲得良好效果，提升寫入20%。

3. 內置計算?
   數據的聚合、校正、清洗是數據庫系統常見的計算場景，通過外部客戶端進行數據的掃描、計算、更新是我們常用的傳統方式。當面對TB級以上規模的時候，這種方式不僅效率低下，而且對本身的數據服務性能影響巨大。

阿里HBase一直在探索一種高效、環保的能力去解決我們對于數據基本計算的需求，幾經業務理解與抽象，最終找到一種基于coprocessor的數據庫內置計算方案。它不僅可以提供基本的Count、Avg、Sum、PV、UV等分析聚合能力，也可以提供常見的格式轉換、內容校正、字段清洗等數據管理能力。
其基本原理是，我們在HBase的Flush、Compaction、查詢返回等路徑添加coprocessor的hook，并開發很多通用的coprocessor插件，使得HBase服務端能夠在Compaction、Flush期間就完成數據計算工作，這不僅促使計算結果快速輸出，也大大減少數據存儲IO，大大提升整體性能。
2016年，憑借這個能力，多個幾百TB規模業務在一周以內完成字段清洗、格式轉換，并且全程對業務在線訪問無影響。憑借這個能力，很多秒級生產的指標數據，應用可以零成本聚合成小時級、日級等粗粒度指標，并對HBase系統減少50%以上的訪問壓力。

未來發展

隨著2016天貓雙十一的GMV定格在1207億，HBase的大促目標圓滿完成，然而完美的結果只是開始，阿里HBase團隊追求卓越的心永遠不會變，推陳出新也永遠不會停。在未來的日子里，我們將會重點攻破以下難題。

1. GC的挑戰?
   HBase作為JAVA性存儲系統，大容量的內存堆使得YoungGC、FullGC的停頓成為我們一直以來揮之不去的痛苦。探究GC的原理機制，我們明確HBase內部的寫緩沖Memstore和讀緩存BlockCache是造成GC停頓的最大源頭，正在嘗試用全新研發的完全自管理內存的Map以替換JDK自帶的Map，從而消除GC的影響。

2. SQL?
   我們正在嘗試提供SQL方式訪問HBase。它會增加數據類型，降低用戶的開發理解門檻，促進異構系統之間的數據流動效率；它會增加全局二級索引，使得多條件查詢更加高效；它會簡化查詢表達，使得性能優化更加普及；它會增加通用的熱點解決方案，幫助用戶免去復雜的散列邏輯。

3. 容器部署?
   我們正在嘗試將HBase部署運行于Docker之上，使得整體運維更加敏捷，集群伸縮更加自如，資源使用更加充分。

原文鏈接

本文為云棲社區原創內容，未經允許不得轉載。