大數據時代的結構化存儲-HBase的應用實踐

  • 2019 年 10 月 6 日
  • 筆記

前言

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

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

概述

HBase是一個開源的非關係型分散式資料庫（NoSQL）,基於Google的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. 時間確定性。明確標註同步時刻，該時刻之前寫入的數據都已經傳輸完成。基於此，保證計算系統對某個時間分區的完整數據進行計算。
  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之上，使得整體運維更加敏捷，集群伸縮更加自如，資源使用更加充分。

寫在最後

阿里在HBase領域積累的這些能力，將通過雲資料庫HBase的產品化，輸出給阿里雲的廣大客戶收益。對於使用的公司： 不需要再擔心技術上遇到的一個個瓶頸難題，雲資料庫HBase已經為你解決 不需要再擔心招聘HBase頂尖高手，阿里雲技術專家將為你貼身服務 不需要彈性擴容、自動化運維等事宜，依託雲產品，這些能力將快速實現

Tags:

VirMach 便宜 VPS