概述
HBase 是一個(gè)開源的非關(guān)系型分布式數(shù)據(jù)庫(kù)（No
SQL）,基于谷歌的 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 作為阿里巴巴技術(shù)大廈的基礎(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)。
下面的篇幅，將主要介紹阿里在使用 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ù)寫入盡量并行化。
2.熱點(diǎn)輔助
盡管做了以上兩點(diǎn)后，集群間的數(shù)據(jù)復(fù)制能力大大增強(qiáng)，但是個(gè)別服務(wù)器仍然會(huì)由于負(fù)載過(guò)大，而產(chǎn)生一定的復(fù)制延遲。從本質(zhì)上來(lái)說(shuō)，這是因?yàn)?HBase 的服務(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)行消化。
3.配置在線調(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)：
2.鏈路可視
當(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)鍵的信息。
基本信息如圖：
3.循環(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)化，以去除這種寫入放大。
4.鏈路隔離
當(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)景，以供大家參考。
· 基于狀態(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)的條件判斷。
· 日志/消息的順序訂閱。對(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ù)。
· 流計(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í)別非常常見(jiàn)，且越來(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)傳輸完成。基于此，保證計(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)如下：
· 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ù)包。
· 大部分離線計(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í)間）。
· 同步時(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ù)被傳輸?shù)诫x線計(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)化上的很多新型武器。
異步 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 倍。
前綴 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 億包裹的物流詳情查詢。
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%。
內(nèi)置計(jì)算
數(shù)據(jù)的聚合、校正、清洗是數(shù)據(jù)庫(kù)系統(tǒng)常見(jiàn)的計(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 等分析聚合能力，也可以提供常見(jiàn)的格式轉(zhuǎn)換、內(nèi)容校正、
字段清洗等數(shù)據(jù)管理能力。
其基本原理是，我們?cè)?HBase 的 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)攻破以下難題。
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 的影響。
我們正在嘗試提供
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ù)雜的散列邏輯。
容器部署
我們正在嘗試將 HBase 部署運(yùn)行于 Docker 之上，使得整體運(yùn)維更加敏捷，集群伸縮更加自如，資源使用更加充分。
阿里技術(shù)
本文轉(zhuǎn)自公眾號(hào)阿里技術(shù)，轉(zhuǎn)載需授權(quán)
CDA數(shù)據(jù)分析師考試相關(guān)入口一覽（建議收藏）：
? 想報(bào)名CDA認(rèn)證考試，點(diǎn)擊>>>
“CDA報(bào)名”
了解CDA考試詳情；
? 想學(xué)習(xí)CDA考試教材，點(diǎn)擊>>> “CDA教材” 了解CDA考試詳情；
? 想加入CDA考試題庫(kù)，點(diǎn)擊>>> “CDA題庫(kù)” 了解CDA考試詳情；
? 想了解CDA考試含金量，點(diǎn)擊>>> “CDA含金量” 了解CDA考試詳情；
京公網(wǎng)安備 11010802034615號(hào)
經(jīng)營(yíng)許可證編號(hào)：京B2-20210330
