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

前言

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

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

概述

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

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

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

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

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

HBase在阿里的使用

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

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

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

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

高可用建設

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

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

集群異步復制

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

復制效率

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

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

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

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

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

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

多鏈路

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

在支持數(shù)據(jù)多鏈路的生產(chǎn)應用上，我們總結(jié)了以下幾個要點

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

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

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

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

數(shù)據(jù)的一致性

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

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

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

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

為了滿足類似場景的需求，阿里HBase研發(fā)了同步方式的集群間數(shù)據(jù)復制，具體內(nèi)容可參考下一節(jié)。

冗余與成本

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

集群同步復制

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

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

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

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

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

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

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

關于數(shù)據(jù)的強一致，我們進行了如下定義：

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

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

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

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

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

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

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

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

4. 主備集群存在Active和Standby狀態(tài)，只有Active狀態(tài)的集群才能接受客戶端的數(shù)據(jù)寫入

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

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

其基本結(jié)構(gòu)如圖

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

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

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

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

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

總結(jié)

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

數(shù)據(jù)傳輸管道設施

數(shù)據(jù)流動的訴求

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

HExporter系統(tǒng)

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

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

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

1. 實時性。數(shù)據(jù)可以秒級復制到其他異構(gòu)系統(tǒng)

2. 準確性。保證數(shù)據(jù)在HBase與其他系統(tǒng)間的最終一致性

3. 高吞吐。支持調(diào)整緩沖等級和壓縮等級，從而協(xié)調(diào)數(shù)據(jù)生產(chǎn)端和數(shù)據(jù)消費端的能力，達到最大的吞吐量。在實際應用中，HExporter可以有效使用95%的網(wǎng)絡帶寬并保持穩(wěn)定運行。

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

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

6. 可降級。支持按表取消數(shù)據(jù)傳輸。

7. 監(jiān)控告警。支持傳輸延遲的監(jiān)控與告警。

HExporter系統(tǒng)的整體架構(gòu)如下:?

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

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

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

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

性能與成本

數(shù)據(jù)冗余的背后

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

跨集群分區(qū)數(shù)據(jù)復制

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

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

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

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

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

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

詳細系統(tǒng)架構(gòu)如下：

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

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

多集群多活服務

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

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

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

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

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

更多性能工作

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

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

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

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

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

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

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

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

未來發(fā)展

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

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

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

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

原文鏈接

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。