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

前言

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

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

概述

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

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

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

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

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

HBase在阿里的使用

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

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

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

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

高可用建設(shè)

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

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

集群異步復(fù)制

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

復(fù)制效率

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

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

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

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

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

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

多鏈路

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

在支持?jǐn)?shù)據(jù)多鏈路的生產(chǎn)應(yīng)用上，我們總結(jié)了以下幾個(gè)要點(diǎn)

1. 表級(jí)別鏈路?
   當(dāng)一個(gè)HBase集群?jiǎn)⒂枚鄠€(gè)數(shù)據(jù)鏈路后，我們期望自由設(shè)置表的數(shù)據(jù)可以被復(fù)制到其中的一個(gè)或多個(gè)鏈路，使得整個(gè)數(shù)據(jù)的流動(dòng)更加靈活。為此，我們?cè)黾恿艘环N特性，通過(guò)設(shè)置表的屬性，以決定該表的數(shù)據(jù)流向哪些鏈路，使得整個(gè)數(shù)據(jù)流動(dòng)圖可以由業(yè)務(wù)架構(gòu)師任意設(shè)計(jì)，十分靈活。此外，當(dāng)需要在集群間熱遷移數(shù)據(jù)時(shí)，它也能帶來(lái)十分重大的作用。 整體效果如下，以表為單位數(shù)據(jù)可以任意流動(dòng)：

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

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

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

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

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

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

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

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

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

冗余與成本

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

集群同步復(fù)制

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

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

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

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

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

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

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

關(guān)于數(shù)據(jù)的強(qiáng)一致，我們進(jìn)行了如下定義：

1. 返回應(yīng)用成功，則一定主備都寫成功

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

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

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

HExporter系統(tǒng)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

性能與成本

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

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

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

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

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

1. 簡(jiǎn)單?？梢酝ㄟ^(guò)一個(gè)接口或者命令執(zhí)行復(fù)制，并在系統(tǒng)UI上實(shí)時(shí)顯示進(jìn)度。

2. 快速。整個(gè)復(fù)制任務(wù)會(huì)進(jìn)行拆分，并由不同節(jié)點(diǎn)完成，大大提高速度。

3. 容錯(cuò)和災(zāi)難恢復(fù)。復(fù)制過(guò)程中任何出錯(cuò)和宕機(jī)都能自我恢復(fù)。

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

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

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

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

多集群多活服務(wù)

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

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

2. 交叉部署訪問(wèn)，支持?jǐn)?shù)據(jù)的強(qiáng)一致要求。一般我們會(huì)把類似場(chǎng)景的多個(gè)業(yè)務(wù)部署在同個(gè)集群中，通過(guò)交叉部署，在同一時(shí)間，使得一些業(yè)務(wù)訪問(wèn)主集群，另一些業(yè)務(wù)訪問(wèn)備集群，從而同時(shí)發(fā)揮兩個(gè)集群的資源。

3. 客戶端支持同時(shí)訪問(wèn)雙集群。我們通過(guò)改造HBase的客戶端，使其支持同時(shí)訪問(wèn)雙集群，這不僅可以提升集群的資源使用率，還大大降低了訪問(wèn)毛刺，因?yàn)槿魏纬^(guò)一定時(shí)間的請(qǐng)求都會(huì)被重發(fā)到另一個(gè)集群。

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

更多性能工作

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

剛剛過(guò)去的2016年雙11，可以說(shuō)是HBase的一場(chǎng)圣戰(zhàn)，面對(duì)巨大峰值流量從容應(yīng)戰(zhàn)的背后是我們?cè)谛阅軆?yōu)化上的很多新型武器。

1. 異步API?
   一直以來(lái)，HBase只能使用同步API方式訪問(wèn)服務(wù)，使得吞吐型場(chǎng)景應(yīng)用端大量線程阻塞在HBase接口，嚴(yán)重影響性能，而異步的思想并不陌生。

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

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

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

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

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

未來(lái)發(fā)展

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

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

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

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

原文鏈接

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