摘要：?ApsaraDB?for?HBase2.0于2018年6月6日即將正式發(fā)布上線啦！ 它是基于社區(qū)HBase2.0穩(wěn)定版的升級，也是阿里HBase多年的實踐經(jīng)驗和技術(shù)積累的持續(xù)延伸，全面解決了舊版本碰到的核心問題，并做了很多優(yōu)化改進，附加HBase2.0?開源新特性，可以說是HBase生態(tài)里的一個里程碑。

一、HBase2.0和阿里云的前世今生

??????ApsaraDB?for?HBase2.0于2018年6月6日即將正式發(fā)布上線啦！?
??????ApsaraDB?for?HBase2.0是基于社區(qū)HBase2.0穩(wěn)定版的升級，也是阿里HBase多年的實踐經(jīng)驗和技術(shù)積累的持續(xù)延伸，全面解決了舊版本碰到的核心問題，并做了很多優(yōu)化改進，附加HBase2.0?開源新特性，可以說是HBase生態(tài)里的一個里程碑。?
??????HBase在2007年開始發(fā)布第一個“可用”版，2010年成為Apache的頂級項目，阿里巴巴集團也在2010當(dāng)年就開始研究,于2011年就已經(jīng)開始把HBase投入生產(chǎn)環(huán)境使用，并成為阿里集團主要的存儲系統(tǒng)之一。那個時候HBase已經(jīng)運行在上千臺級別的大集群上，阿里巴巴可以說算是HBase當(dāng)時得到最大規(guī)模應(yīng)用的互聯(lián)網(wǎng)公司之一。從最初的淘寶歷史交易記錄，到螞蟻安全風(fēng)控數(shù)據(jù)存儲，HBase在幾代阿里專家的不懈努力下，HBase已經(jīng)表現(xiàn)得運行更穩(wěn)定、性能更高效，是功能更豐富的集團核心存儲產(chǎn)品之一。?
??????阿里集團自2012年培養(yǎng)了第一位“東八區(qū)”?HBase Committer，到今天，阿里巴巴已經(jīng)擁有3個PMC，6個Committer，阿里巴巴是中國擁有最多HBase Committer的公司之一。他們貢獻了許多bug?fix以及性能改進feature等，很可能你在用的某個特性，正是出自他們之手。他們?yōu)镠Base社區(qū)，也為HBase的成長貢獻了一份寶貴的力量。當(dāng)然，也孕育了一個更具有企業(yè)針對性的云上HBase企業(yè)版存儲系統(tǒng)——ApsaraDB?for?HBase。?
??????ApsaraDB?for?HBase2.0是基于開源HBase2.0基礎(chǔ)之上，融入阿里HBase多年大規(guī)模實戰(zhàn)檢驗和技術(shù)積累的新一代KV數(shù)據(jù)庫產(chǎn)品，結(jié)合了廣大企業(yè)云上生產(chǎn)環(huán)境的需求，提供許多商業(yè)化功能，比如 HBase?on?OSS、HBase云環(huán)境公網(wǎng)訪問、HBase?on?本地盤、HBase?on?共享存儲、冷熱分離、備份恢復(fù)、HBase安全機制等等，是適合企業(yè)生產(chǎn)環(huán)境的企業(yè)級大規(guī)模云KV數(shù)據(jù)庫。?
??????ApsaraDB?for?HBase2.0，源于HBase，不僅僅是HBase!

二、深入解讀云HBase架構(gòu)

??????ApsaraDB for HBase2.0是建立在龐大的阿里云生態(tài)基礎(chǔ)之上，重新定義了HBase云上的基礎(chǔ)架構(gòu)，對企業(yè)云上生產(chǎn)需求更有針對性，滿足了許多重要的云上應(yīng)用場景。其中最常見的有：存儲計算分離、一寫多讀、冷熱分離、SQL/二級索引、安全等。下面針對這些場景簡單介紹一下ApsaraDB for HBase2.0的基礎(chǔ)架構(gòu)。

2.1 存儲計算分離

??????早期存儲和計算一般都是一起的，這樣做帶來的好處是數(shù)據(jù)本地化，不消耗網(wǎng)絡(luò)資源。但是這會帶來一個問題，給應(yīng)用企業(yè)對集群起初的規(guī)劃帶來一定的難度，如果一開始使用過大的存儲、過大的計算資源，就是一種浪費，但是如果開始規(guī)劃存儲、計算過小，后期運維升級擴展有變得非常復(fù)雜，甚至升級/擴展過程會出現(xiàn)故障等等問題，這些都不不企業(yè)業(yè)務(wù)發(fā)展規(guī)劃不可忽略的問題。?
??????隨著網(wǎng)絡(luò)技術(shù)的發(fā)展，現(xiàn)在已經(jīng)進入25G甚至100G以上時代，網(wǎng)絡(luò)帶寬已經(jīng)不再是瓶頸。ApsaraDB for HBase2.0建立在阿里云之上，利用阿里云強大基礎(chǔ)技術(shù)，實現(xiàn)了云上HBase的高性能存儲計算分離的架構(gòu)。

??????如上圖所示，分布式region如上圖所示，分布式region計算層負(fù)責(zé)HBase相關(guān)的數(shù)據(jù)庫邏輯運算操作; 通過分布式HDFS&API接口讀寫遠端底層分布式文件存儲系統(tǒng)；其中遠端讀寫質(zhì)量和安全隔離由QOS層保障，QOS層利用高性能硬件加速遠端讀寫性能，保障了存儲分離的性能、安全要求；最終讀寫落到分布式存儲層，分布式存儲層通過副本形式保障數(shù)據(jù)安全可靠，可以容忍單節(jié)點、單rack fail的數(shù)據(jù)可靠性。云上HBase計算存儲分離架構(gòu)的實現(xiàn)，使得用戶集群規(guī)劃則變得簡單很多，存儲容量動態(tài)擴展，計算資源動態(tài)升配。基本不需要估算未來業(yè)務(wù)的規(guī)模了，真正做到按需使用，幫助用戶在業(yè)務(wù)運行之初就開始盡可能地降低成本，同時又可以隨時滿足業(yè)務(wù)發(fā)展導(dǎo)致資源的彈性擴展的需要。

2.2 冷熱分離/分級存儲

??????一般企業(yè)隨著業(yè)務(wù)數(shù)據(jù)不斷增長，數(shù)據(jù)量開始變大，這個時候就需要對數(shù)據(jù)進行冷熱程度區(qū)分對待，以優(yōu)化系統(tǒng)整體運行效率，并降低成本。舉個例子，如：冷數(shù)據(jù)寫入一次后，可能很久才被訪問一次，但是因為和熱數(shù)據(jù)存儲在一個數(shù)據(jù)塊上，可能讀這個熱數(shù)據(jù)的時候，冷數(shù)據(jù)也被順帶讀到內(nèi)存中，這可能是沒有必要的，我們更多希望被順帶讀出來的也是即將被訪問的熱數(shù)據(jù)。另外，因為熱數(shù)據(jù)的頻繁更新寫入，可能會引起系統(tǒng)更多得split、compaction等動作，這個時候，冷數(shù)據(jù)也被順帶一起多次讀寫磁盤了，實際上冷數(shù)據(jù)可能不需要這么頻繁地進行這種系統(tǒng)動作。再從成本考慮，業(yè)務(wù)上如果普遍可以接受陳年舊事——冷數(shù)據(jù)被訪問延時相對高一點點，那么就可以考慮把這些數(shù)據(jù)存儲在成本較低的介質(zhì)中。?
??????基于這種常見的企業(yè)場景需求，ApsaraDB for HBase2.0在阿里云基礎(chǔ)體系之上，設(shè)計了云HBase冷熱分離/分級存儲架構(gòu)，實現(xiàn)企業(yè)云上HBase應(yīng)用的冷熱分離場景需求，提高系統(tǒng)運行效率的同時，又降低存儲成本。

??????如圖所示，架構(gòu)分兩階段，第一階段實現(xiàn)分級存儲，用戶可以清晰的按照不同訪問頻度將數(shù)據(jù)存儲到不同冷熱級別的表上，從表級別上區(qū)分冷熱數(shù)據(jù)，實現(xiàn)分級存儲。第二階段是同表數(shù)據(jù)冷熱數(shù)據(jù)自動分離，用戶可以按照訪問頻率或者創(chuàng)建時間等條件，指定冷熱數(shù)據(jù)判斷標(biāo)準(zhǔn)依據(jù)，最終后端自動分離冷熱數(shù)據(jù)分別存儲。

2.3 一寫多讀/讀高可用

??????在舊版HBase運行的時候，當(dāng)一臺機器宕機的時候，這個機器所負(fù)責(zé)的region主要需要經(jīng)歷3個的處理流程才能恢復(fù)讀——發(fā)現(xiàn)宕機、重新分配此機器負(fù)責(zé)的region、上線region恢復(fù)。其中發(fā)現(xiàn)宕機可能就需要幾十秒，依賴于zookeeper的session timeout時間。在這個恢復(fù)過程中，用戶client是不可以讀這些region數(shù)據(jù)的。也就是此架構(gòu)的讀不是高可用的，無法保證99.9%的延時都 <20ms。在某些應(yīng)用業(yè)務(wù)里，可能更關(guān)心整體讀高可用、99.9%讀延時，且允許讀到舊數(shù)據(jù)的情況下，這就無法滿足。?
??????ApsaraDB for HBase2.0是基于2.0最新穩(wěn)定版，引入了region replicas功能，實現(xiàn)一寫多讀，擴充了高可用讀的能力。

??????如上圖，開啟這個功能的表，region會被分配到多個RegionServer上，其中replicaId=0的為主region，其他的為從region，只有主region可以寫入，主region負(fù)責(zé) flush memstore成為hfile，從region一方面根據(jù)hfile列表類讀到數(shù)據(jù)，另一方面對于剛寫入主region但還沒有flush到hdfs上的數(shù)據(jù)，通過replication同步到從region的memstore。如上圖所示，client1分別時間間隔內(nèi)寫入x=1、x=2、x=3，在同步數(shù)據(jù)的時候時，client2進行讀x的值，它是可以讀任何一臺server上的x值，這就保證了讀的高可用性，即使有機器掛了也可以有 99.9%延時 <20ms保證。?
??????可以看到這種架構(gòu)讀是高可用的，合適一寫多讀的場景，數(shù)據(jù)只保存一份。n臺機器掛了(n小于一個region的副本數(shù))，還可以正常讀數(shù)據(jù)。并且這里提供了兩種讀一致性模式，分別是strong和timeline-consistent模式。在strong模式下，只讀取主region的數(shù)據(jù)返回結(jié)果；在timeline-consistent模式下，允許讀任何一個region replica的數(shù)據(jù)返回，這對一些要求讀高可用的場景來說，體驗是比較友好的。

2.4 SQL/二級索引/全文檢索

??????HBase原生的設(shè)計只有按照rowkey的才能快速查詢檢索，這對復(fù)雜的企業(yè)業(yè)務(wù)檢索場景來說，是滿足不了的。且隨著業(yè)務(wù)的變化，開始設(shè)計的rowkey可能已經(jīng)不能滿足當(dāng)下系統(tǒng)的某些業(yè)務(wù)檢索需求了。這就要求對HBase的檢索功能進行加強。?
??????ApsaraDB for HBase2.0支持更完善的SQL接口、二級索引以及全文索引，用戶可以使用熟悉的SQL語句操作HBase系統(tǒng)；并且支持二級索引的創(chuàng)建、全量重建索引，以及增量數(shù)據(jù)自動同步索引的功能；2.0版本還將支持全文索引檢索功能，彌補了HBase不能模糊檢索的缺陷，把全文檢索的功能引入HBase系統(tǒng)當(dāng)中。

??????如上圖，ApsaraDB for HBase2.0體系內(nèi)置solr/phoenix內(nèi)核引擎，進行了深度改造與優(yōu)化，支持SQL/API方式操作數(shù)據(jù)庫，二級索引支持：全局索引、本地索引、全文索引等。索引支持全量重建、增量數(shù)據(jù)自動同步更新。在檢索查詢的時候，索引對用戶透明，HBase內(nèi)部根據(jù)索引元信息自動探測用戶查詢是否需要利用索引功能，增強了HBase系統(tǒng)檢索能力，有利于企業(yè)在云HBase業(yè)務(wù)上構(gòu)建更復(fù)雜的檢索場景。

2.5 安全體系

??????在用戶使用數(shù)據(jù)庫的時候，都習(xí)慣于傳統(tǒng)的類型MySQL的賬戶密碼體系，而大數(shù)據(jù)Hadoop/HBase生態(tài)當(dāng)中，默認(rèn)卻沒有一套完整且統(tǒng)一的認(rèn)證授權(quán)體系，組件內(nèi)置的身份認(rèn)證僅支持Kerberos協(xié)議，而權(quán)限控制依賴于每個生態(tài)組件自身的控制。?
??????ApsaraDB for HBase2.0基于Alibaba&Intel 合作項目Hadoop Authentication Service (HAS) 開發(fā)了一套屬于云HBase的認(rèn)證授權(quán)體系，兼容了Hadoop/HBase生態(tài)的Kerberos協(xié)議支持，并使用人們熟悉的賬戶密碼管理方式，允許對用戶訪問HBase的權(quán)限進行管理，兼容默認(rèn)ACL機制。

??????如上圖，ApsaraDB for HBase2.0安全體系基于HAS開發(fā)，使用Kerby替代MIT Kerberos服務(wù)，利用HAS插件式驗證方式建立一套人們習(xí)慣的賬戶密碼體系，用戶體驗更友好。

2.6 備份恢復(fù)

??????大數(shù)據(jù)時代，重要的信息系統(tǒng)中數(shù)據(jù)就是財富，數(shù)據(jù)的丟失可能會造成不可估量的損失。對于這種數(shù)據(jù)重要級別較高的場景，應(yīng)該要構(gòu)建一套災(zāi)難備份和恢復(fù)系統(tǒng)架構(gòu)，防止人為操作失誤、自然災(zāi)害等不可避免的偶然因素造成的損失。ApsaraDB for HBase2.0構(gòu)建在云體系下，支持全量、增量備份，同城/異地災(zāi)備功能。

??????如上圖，架構(gòu)可以允許用戶進行冷數(shù)據(jù)備份，備份數(shù)據(jù)保存在共享存儲中，成本低，需要時可以對備份數(shù)據(jù)讀取還原插入到系統(tǒng)中。同時也支持熱備份，集群之間通過全量HFile和增量HLog進行跨集群備份，最終做到同城/異地災(zāi)備，業(yè)務(wù)client可以在訪問當(dāng)下集群不可用時，自動切換到備用集群進行數(shù)據(jù)訪問業(yè)務(wù)。

三、2.0版本內(nèi)核解讀

??????開源HBase在2010年正式成為Apache頂級項目獨立發(fā)展，而阿里巴巴同步早在2010年初已經(jīng)開始步入HBase的發(fā)展、建設(shè)之路，是國內(nèi)最早應(yīng)用、研究、發(fā)展、回饋的團隊，也誕生了HBase社區(qū)在國內(nèi)的第一位Committer，成為HBase在中國發(fā)展的積極布道者。過去的8年時間，阿里累積向社區(qū)回饋了上百個patch, 結(jié)合內(nèi)部的阿里巴巴集團“雙十一”業(yè)務(wù)等的強大考驗，在諸多核心模塊的功能、穩(wěn)定性、性能作出積極重大的改進和突破，孕育了一個云上HBase企業(yè)版KV數(shù)據(jù)庫ApsaraDB for HBase。?
??????ApsaraDB for HBase發(fā)展至今，已經(jīng)開始進入了2.0 時代。ApsaraDB for HBase是基于開源HBase2.0版本，結(jié)合阿里HBase技術(shù)和經(jīng)驗的演進過來，其完全兼容HBase2.0，擁有HBase2.0的所有新特性的同時，更享受阿里專家&HBase?Committer們在源碼級別上的保駕護航。2.0相比1.x之前版本在內(nèi)核上有了許多改進，內(nèi)核功能更穩(wěn)定、高效、延時更低，功能更豐富。下面我們來介紹一下這些重要的功能特性。

3.1 新版Region分配器AMv2——穩(wěn)定性提高

??????在早期版本，HBase?Server端很多執(zhí)行業(yè)務(wù)過程都是使用handler線程實現(xiàn)的，而一個業(yè)務(wù)線程需要執(zhí)行的邏輯可能要經(jīng)歷幾個步驟。使用handler線程實現(xiàn)的這套機制最大的問題在于不支持異常回滾，沒有災(zāi)難恢復(fù)機制，執(zhí)行過程中出現(xiàn)異常，那么HBase可能會處在任務(wù)的中間狀態(tài)，引起常見的Region-In-Transition，可能就需要人為去清理。如：客戶端調(diào)用一個createTable?RPC請求，服務(wù)端需要創(chuàng)建HDFS目錄，寫入meta表，分配region，等待region上線，標(biāo)記region上線完成等等系列步驟，如果handler處理線程中間被中斷了，就導(dǎo)致系統(tǒng)殘留一下中間狀態(tài)的數(shù)據(jù)。

??????如上圖，region信息寫入meta表后進程被中斷了，而client認(rèn)為任務(wù)已經(jīng)完成了，實際上整個任務(wù)是失敗的。在進程恢復(fù)后，沒有很好的處理這個災(zāi)難問題回滾或者繼續(xù)恢復(fù)執(zhí)行剩下的步驟。?
??????針對這類問題，ApsaraDB for HBase2.0內(nèi)核做了兩個核心的改動，一個是引入ProcedureV2，解決諸如上述分布式多步驟流程處理的狀態(tài)最終一致性問題；二個是基于ProcedureV2基礎(chǔ)上，改造了AssignmentManager，使其在region上線過程被異常或災(zāi)難中斷后，進程恢復(fù)時可以自動回滾中間殘留狀態(tài)信息，重試中斷步驟并繼續(xù)執(zhí)行。最終避免了類似RIT的問題，實現(xiàn)“NO more HBCK, NO more RIT”，提供穩(wěn)定性，降低運維成本。
??????首先我們來看看ProcedureV2的原理，如下圖：

??????它使用ProcedureExecutor調(diào)用執(zhí)行用戶提交的procedure隊列，并在執(zhí)行procedure狀態(tài)變化的時候，使用ProcedureStore記錄procedure的狀態(tài)持久化到WAL中，如此反復(fù)。當(dāng)procedure執(zhí)行過程當(dāng)中進程被中斷了，在下一次進程恢復(fù)時，就可以根據(jù)之前持久化的procedure狀態(tài)恢復(fù)到指定步驟，并做必要的rollback步驟，再重試中斷的步驟繼續(xù)下去。

??????如上圖，最常見的就是狀態(tài)機Procedure，定制每次狀態(tài)在繼續(xù)向下執(zhí)行的時候，應(yīng)該做哪些操作，以及在中斷恢復(fù)后，應(yīng)該處理的rollback工作。回想上面創(chuàng)建表的例子，如果我們同樣在"add?regions?to?META"的時候失敗了，那么我們在恢復(fù)之后，就可以根據(jù)這個狀態(tài)信息，繼續(xù)執(zhí)行剩下的步驟，只有當(dāng)這個procedure?完成的時候，這個create?table的procedure?才算完成。當(dāng)然，client判斷是否創(chuàng)建表成功也不再是使用?“MetaReader.hasTable”來利用中間狀態(tài)得到結(jié)果，而是直接根據(jù)createTable的procedure?Id來查詢是否任務(wù)完整執(zhí)行結(jié)束。可以看出，在使用ProcedureV2和之前的線程處理有了很大的改進，更靈活的處理業(yè)務(wù)進程被中斷時的各種異常情況。?
??????再來看看AMv2的改進特性，正如上面所述，AssignmentManager?V2(簡稱AMv2)是基于ProcedureV2實現(xiàn)的新版region分配管理器。得益于ProcedureV2的設(shè)計實現(xiàn)，AMv2在進行region分配上下線時，可以在被各種情況中斷的情況下，自動恢復(fù)回滾執(zhí)行，使得region的狀態(tài)最終是自動恢復(fù)一致性的。除此之外，AMv2還重新設(shè)計了region信息保存和更新的邏輯。?
??????在舊版的AssignmentManager實現(xiàn)，是借助Zookeeper協(xié)同功能，Master與RegionServer共同完成的region狀態(tài)維護，代碼邏輯相對復(fù)雜、效率低。region狀態(tài)保存在3個地方：Zookeeper、meta表、Master內(nèi)存，當(dāng)一個分配流程過程中一端被異常中斷時，就容易出現(xiàn)集群狀態(tài)不一致的現(xiàn)象。如client?訪問時報的NotServingRegionException一種能就是region狀態(tài)不一致，Master認(rèn)為是分配到這個server上，而實際在這個server并沒有上線，此時client?rpc請求訪問，就會收到這個異常。
??????下圖為舊版AssignmentManager的region assign復(fù)雜流程：

??????如上圖流程顯示，第1、2、3條線是Master進程的不同線程，第4條是zk，第5、6條是RegionServer上的線程，第7條線是META表。Master和RegionServer都可以更新Zookeeper中region的狀態(tài)，RegionSever又可以更新?meta表中的?assignment?信息。Master?在將?region?assign?給?RegionServer?之前也會更新region?狀態(tài)信息，Master也可以從?Zookeeper和meta?表中獲取?region狀態(tài)更新。這導(dǎo)致很難維持region處于一個正常的狀態(tài)，特別是一端處于異常災(zāi)難中斷的時候。?
??????為了維持region處于一個正常的狀態(tài)，再加上各種異常中斷的情況考慮，HBase內(nèi)部使用了很多復(fù)雜的邏輯，這就大大增加了維護難度，對開發(fā)新功能、提升性能的優(yōu)化工作增加了復(fù)雜性。?
??????新版AssignmentManager V2 ，不僅基于ProcedureV2之上以支持各種中斷回滾重試，還重新設(shè)計了region分配邏輯，不再使用Zookeeper來保存region的狀態(tài)信息，region只持久化在meta表，以及Master的內(nèi)存中，并且只有Master去維護更新，這就簡化了狀態(tài)更新的一致性問題。而且，代碼邏輯較之前也清晰簡潔了，穩(wěn)定性提高了，維護的復(fù)雜性降低，性能也提高了。

??????如上圖，從測試結(jié)果來看，2.0中的 region assign 速度比V1提高非常快。綜合看，這個AMv2是個非常有重要的改進。

3.2 ?Netty Rpc Server和Client——增加吞吐，降低延時

??????在之前的版本中，HBase的RPC Server使用的是基于Java NIO實現(xiàn)的一套框架。在這套框架中有一個Listener線程負(fù)責(zé)accept來自Socket的連接請求，并將對應(yīng)的Connection注冊到NIO的Selector上。同時，有若干個Reader線程來負(fù)責(zé)監(jiān)聽這個selector上處于Readable狀態(tài)的Connection，將請求從Connection中讀出，放入對應(yīng)的Callqueue中，讓handler線程來執(zhí)行這些請求。雖然HBase社區(qū)對這套RPC框架進行了諸多優(yōu)化，包括去掉一些同步鎖，減少復(fù)制等等，但由于其線程模型的限制，以及Java NIO本身的瓶頸，在大壓力測試中，這套框架仍顯得力不從心。?
??????而Netty是一個高性能、異步事件驅(qū)動的NIO框架，?在業(yè)界有著非常廣泛地應(yīng)用，其穩(wěn)定性和性能都得到了多方面地印證。抱著“把專業(yè)的事情交給專業(yè)的人去做”的思想，在HBase2.0中，引入了Netty做為其服務(wù)器的RPC框架。引入Netty的工作由來自阿里巴巴的committer?binlijin完成，并做了相應(yīng)的測試。完成后HBase的RPC框架如圖所示：

??????從網(wǎng)絡(luò)上讀取請求和寫入response都由Netty來負(fù)責(zé)，由于HBase的絕大部分請求涉及了較多的IO和CPU操作，因此仍然需要一個Handler線程池來做請求的執(zhí)行，而和網(wǎng)絡(luò)相關(guān)的操作，完全交給了Netty。使用了Netty服務(wù)器后，HBase的吞吐增長了一倍，在高壓力下的延遲從0.92ms降到了0.25ms，更多的信息可以看下根據(jù)binlinjin在一次公開演講中的展示[附錄1]。目前Netty服務(wù)器已經(jīng)是HBase2.0的默認(rèn)RPC選項。

3.3 ?讀寫鏈路offheap——降低毛刺率，QPS增加

??????GC一直是java應(yīng)用中討論的一個話題，尤其在像HBase這樣的大型在線KV數(shù)據(jù)庫系統(tǒng)中，GC停頓會對請求延遲產(chǎn)生非常大的影響。同時，內(nèi)存碎片不斷惡化從而導(dǎo)致Full GC的發(fā)生，成為了HBase使用者們的一大痛點。?
??????在HBase的讀和寫鏈路中，均會產(chǎn)生大量的內(nèi)存垃圾和碎片。比如說寫請求時需要從Connection的ByteBuffer中拷貝數(shù)據(jù)到KeyValue結(jié)構(gòu)中，在把這些KeyValue結(jié)構(gòu)寫入memstore時，又需要將其拷貝到MSLAB中，WAL Edit的構(gòu)建，Memstore的flush等等，都會產(chǎn)生大量的臨時對象，和生命周期結(jié)束的對象。隨著寫壓力的上升，GC的壓力也會越大。讀鏈路也同樣存在這樣的問題，cache的置換，block數(shù)據(jù)的decoding，寫網(wǎng)絡(luò)中的拷貝等等過程，都會無形中加重GC的負(fù)擔(dān)。而HBase2.0中引入的全鏈路offheap功能，正是為了解決這些GC問題。大家知道Java的內(nèi)存分為onheap和offheap，而GC只會整理onheap的堆。全鏈路Offheap，就意味著HBase在讀寫過程中，KeyValue的整個生命周期都會在offheap中進行，HBase自行管理offheap的內(nèi)存，減少GC壓力和GC停頓。全鏈路offheap分為寫鏈路的offheap和讀鏈路的offheap。其中寫鏈路的offheap功能在HBase2.0中默認(rèn)開啟，讀鏈路的offheap功能仍然在完善中，即將在后續(xù)的小版本中開啟。?
????寫鏈路的offheap包括以下幾個優(yōu)化：?
????????1. 在RPC層直接把網(wǎng)絡(luò)流上的KeyValue讀入offheap的bytebuffer中?
????????2. 使用offheap的MSLAB pool?
????????3. 使用支持offheap的Protobuf版本（3.0+）?
????????4. 更準(zhǔn)確的Memstore size計算和更好的flush策略?
????讀鏈路的offheap主要包括以下幾個優(yōu)化：?
????????1. 對BucketCache引用計數(shù)，避免讀取時的拷貝?
????????2. 使用ByteBuffer做為服務(wù)端KeyValue的實現(xiàn)，從而使KeyValue可以存儲在offheap的內(nèi)存中?
????????3. 對BucketCache進行了一系列性能優(yōu)化?
??????來自阿里巴巴的HBase社區(qū)PMC Yu Li將讀鏈路offheap化運用在了阿里巴巴內(nèi)部使用的HBase集群中，使用讀鏈路offheap后，相應(yīng)集群的讀QPS增長了30%以上，同時毛刺率更加低，請求曲線更加平滑，成功應(yīng)對了2016年天貓雙十一的峰值[附錄2]。

3.4 In-Memory Compaction——減輕GC壓力，減少寫放大

??????回顧HBase的LSM結(jié)構(gòu)，HBase為每個region的每個store在內(nèi)存中創(chuàng)建一個memstore，一旦內(nèi)存達到一定閾值后，就會flush到HDFS上生成HFile。不斷的運行寫入，HFile個數(shù)就會變多，這個時候讀性能就會變差，因為它查詢一個數(shù)據(jù)可能需要打開所有存在這個行的HFile。解決這個問題就需要定期后臺運行Compaction操作，將多個HFile合并。但是這樣做會使得同一份數(shù)據(jù)，因多次compaction而會被寫入多次hdfs，引起了寫入放大的問題。可以看到，要想減少這個compaction的頻率的話，可以通過降低HFile的產(chǎn)生速度，同樣的內(nèi)存盡可能多的保存數(shù)據(jù)，并且在內(nèi)存中預(yù)先進行compaction操作，提高后期hfile的compaction效率。In-Memory Compaction應(yīng)運而生。?
??????hbase2.0引入In-Memory compaction技術(shù)，核心有兩點：一是使用 Segment 來替代 ConcurrentSkipListMap ，同樣的 MemStore 可以存儲更多的數(shù)據(jù)，減少flush 頻繁，從而也減輕了寫放大的問題。同時帶來的好處是減少內(nèi)存 GC 壓力。二是在 MemStore 內(nèi)存中實現(xiàn)compaction操作，盡量減少后期寫放大。?
??????先來說說其如何高效實用內(nèi)存。在默認(rèn)的MemStore中，對cell的索引使用ConcurrentSkipListMap，這種結(jié)構(gòu)支持動態(tài)修改，但是其中會存在大量小對象，內(nèi)存碎片增加，內(nèi)存浪費比較嚴(yán)重。而在CompactingMemStore中，由于pipeline里面的segment數(shù)據(jù)是只讀的，就可以使用更緊湊的數(shù)據(jù)結(jié)構(gòu)來存儲索引，這帶來兩方面好處：一方面只讀數(shù)據(jù)塊可以降低內(nèi)存碎片率，另一方面更緊湊的數(shù)據(jù)結(jié)構(gòu)減少內(nèi)存使用。代碼中使用CellArrayMap結(jié)構(gòu)來存儲cell索引，其內(nèi)部實現(xiàn)是一個數(shù)組，如下圖:

??????再來說說其如何降低寫放大。舊版Default MemStore是flush時，將active的store 進行打快照snapshot，然后把snapshot flush到磁盤。新版的CompactingMemStore是以segment為單位組織，一個memstore中包含多個segment。數(shù)據(jù)寫入時寫到active segment中，active segment到一定閾值后觸發(fā)in-memory flush 生成不可修改的segment放到pipeline中。pipeline最后會對這些多個segment進行in-memory compaction合并為一個更緊湊的大segment，在一定程度上延長數(shù)據(jù)在內(nèi)存的生命周期可以減少總的I/O，減少后期寫放大。

??????內(nèi)存compaction目前支持Basic,Eager,Adaptive 三種策略。Basic compaction策略和Eager compaction策略的區(qū)別在于如何處理cell數(shù)據(jù)。Basic compaction不會清理多余的數(shù)據(jù)版本，這樣就不需要對cell的內(nèi)存進行拷貝。而Eager compaction會過濾重復(fù)的數(shù)據(jù)，并清理多余的版本，這意味著會有額外的開銷。Adaptive策略則是根據(jù)數(shù)據(jù)的重復(fù)情況來決定是否使用Eager策略。在Adaptive策略中，首先會對待合并的segment進行評估，方法是在已經(jīng)統(tǒng)計過不重復(fù)key個數(shù)的segment中，找出cell個數(shù)最多的一個，然后用這個segment的numUniqueKeys / getCellsCount得到一個比例，如果比例小于設(shè)定的閾值，則使用Eager策略，否則使用Basic策略。

3.5 支持高效對象存儲

??????ApsaraDB for HBase2.0支持Medium-Sized Object (MOB) 主要目的是在HBase中，能高效地存儲那些100k~10M 中等大小的對象。這使得用戶可以把文檔、圖片以及適中的對象保存到HBase系統(tǒng)中。在MOB之前，常見有兩個設(shè)計方案，第一種是直接保存中等對象到HBase中，另一種是使用HBase中只保存對象數(shù)據(jù)在HDFS的路徑，中等對象以file形式存在HDFS中。這兩個現(xiàn)有方案業(yè)務(wù)方案都有弊端。?
??????通常人們直接存儲在HBase中時，分兩個列簇存儲，一個保存普通信息，另一個用來保存中等對象數(shù)據(jù)。而通常中等對象一般都是幾百KB到幾MB大小的KV，這些數(shù)據(jù)直接插入memstore，會使得flush更頻繁，可能幾百條幾千條數(shù)據(jù)就引起一次flush，產(chǎn)生更多的hfile后，compaction也會被觸發(fā)得更頻繁，I/O 也會隨之變的很大，影響到整個系統(tǒng)的運行。?
??????為了降低MOB中等對象直接存儲導(dǎo)致的split、compaction、flush問題，人們開始使用另一種方案，把MOB對象數(shù)據(jù)存儲到HDFS文件上，只在HBase保存MOB對象數(shù)據(jù)的文件路徑。如下圖：

??????這樣可以減少split/compaction的影響，但是一致性時由客戶端來保證的。另一方面，MOB對象一般是100k~10M的數(shù)據(jù)，此方案就是每個MOB對象在HDFS上保存一個文件，會產(chǎn)生非常多的小物件，很可能系統(tǒng)很快就使用完了文件句柄打開數(shù)。如果優(yōu)化一下，把許多MOB寫到HDFS序列文件上，hbase記錄保存著MOB對象的文件路徑和數(shù)據(jù)offset，確實解決了小文件問題，但是有帶來另一個問題，那就是很難維護這些MOB對象數(shù)據(jù)的一致性，并且很難維護刪除操作。?
??????HBase2.0 MOB功能類似上述的第二種功能，hbase+HDFS文件的方式實現(xiàn)。不同的是，這些都是在server端完成，不需要client去維護數(shù)據(jù)的一致性。并且保存的HDFS文件不是簡單的hdfs序列文件，而是HFile。這樣它就可以有效管理這些MOB數(shù)據(jù)，并且和普通hfile一樣處理deleted數(shù)據(jù)。?
????????MOB數(shù)據(jù)的讀流程是：?
????????????1. seek cell in HBase Table and find the MOB file path?
????????????2. find the MOB file by path?
????????????3. seek the cell by rowkey in the MOB file?
??????讀一個MOB的流程總是只open一個MOB file，所以不管有多少MOB file，是不會影響這個讀性能的。所以split、compaction也并不是必要的。當(dāng)然系統(tǒng)會設(shè)計compaction策略來定期刪除掉那些deleted的數(shù)據(jù)，以騰出空間來。MOB的實現(xiàn)，使得用戶在保存中等對象時，不必自己維護數(shù)據(jù)的一致性，更兼容了現(xiàn)在的HBase api操作MOB hfile。

3.6 異步client ——提高客戶端并發(fā)/吞吐

??????HBase?2.0?前?HBase?的?Client?是同步調(diào)用的，HBase2.0后實現(xiàn)了異步的Client。異步客戶端有兩個好處：?
????????1. 在單個線程中，異步客戶端是非阻塞的，不需要等上一個請求的返回，就可以繼續(xù)再發(fā)送多個請求，可提高客戶端吞吐。?
????????2. 可一定程度上解決故障放大問題，如因為某個業(yè)務(wù)的多個處理線程同時訪問HBase?某個卡住的?RegionServer?（GC原因，HDFS?訪問慢，網(wǎng)絡(luò)原因等）時，這部分的的業(yè)務(wù)的處理線程都會被卡住，此時業(yè)務(wù)的可用性要低于HBase?的可用性（HBase?其它的?RegionServer?可能是正常的）。

3.7 異步DFSClient——提高服務(wù)端性能

??????之前HBase?訪問HDFS?都是同步的，經(jīng)常發(fā)生因為HDFS?訪問慢，而阻塞handler的情況。例如當(dāng)前的處理HBase?RPC的handler為100個，剛好這100個handler訪問某個DataNode被阻塞。此時?RPC?Server則無法處理前端請求，只能等訪問HDFS數(shù)據(jù)返回或者超時才能釋放hanlder?響應(yīng)新的請求。而異步DFS?Client?則不需要等待。可大大提高系統(tǒng)性能以及可用性。

3.8 Region多副本——讀高可用，降低延時

??????ApsaraDB for HBase2.0引入region多副本機制，當(dāng)用戶對某個表開啟此功能時，表的每個region會被分配到多個RegionServer上，其中replicaId=0的為主region，其他的為從region，只有主region可以寫入，從region只能讀取數(shù)據(jù)。主region負(fù)責(zé) flush memstore成為hfile；從region一方面根據(jù)hfile列表類讀到數(shù)據(jù)，另一方面對于剛寫入主region但還沒有flush到hdfs上的數(shù)據(jù)，通過replication同步到從region的memstore。

??????如上圖所示，client1分別時間間隔內(nèi)寫入x=1、x=2、x=3，在同步數(shù)據(jù)的時候時，client2進行讀x的值，它是可以讀任何一臺server上的x值，這就保證了讀的高可用性，即使有n臺機器掛了(n小于一個region的副本數(shù))也可以有 99.9%延時 <20ms保證。可以看到這種架構(gòu)讀是高可用的，合適一寫多讀的場景。?
??????這里還提供了兩種讀一致性模式，分別是strong和timeline-consistent模式，strong模式下，只讀取主region的數(shù)據(jù)返回結(jié)果；timeline-consistent模式下，允許讀任何一個region replica的數(shù)據(jù)返回。

四、展望

??????ApsaraDB for?HBase2.0 是基于開源HBase2.0之上，融入了阿里HBase多年大規(guī)模實戰(zhàn)檢驗和技術(shù)積累的新一代KV數(shù)據(jù)庫產(chǎn)品。結(jié)合了廣大企業(yè)云上生產(chǎn)環(huán)境的特定需求，定制了許多商業(yè)化功能，比如：oss、公網(wǎng)、本地盤、共享存儲、冷熱分離、備份恢復(fù)、安全等等。?
??????接下來，我們在不斷完善ApsaraDB?for?HBase2.0架構(gòu)基礎(chǔ)功能上，會陸續(xù)開放與完善更統(tǒng)一高效的SQL平臺，并加強云HBase的生態(tài)建設(shè)，開放圖數(shù)據(jù)庫、時空數(shù)據(jù)庫、cube數(shù)據(jù)庫-Kylin等。

??????如上圖所示，在接入層上，ApsaraDB for HBase2.0 陸續(xù)支持更多云產(chǎn)品鏈路直通訪問，如：blink、CDP、LogService、emd、物聯(lián)網(wǎng)套件等，開放HBase上生態(tài)組件，如：圖數(shù)據(jù)庫、時空、cube數(shù)據(jù)庫等，讓企業(yè)在云上完成數(shù)據(jù)庫業(yè)務(wù)架構(gòu)閉環(huán)。?
??????網(wǎng)絡(luò)層繼續(xù)支持經(jīng)典網(wǎng)/VPC專有網(wǎng)絡(luò)選擇，并支持彈性公網(wǎng)開關(guān)服務(wù)，方便了云上生產(chǎn)/云下開發(fā)調(diào)試用戶需求。?
??????中間件層繼續(xù)支持并優(yōu)化SQL 二級索引的創(chuàng)建與使用，支持多語言服務(wù)，thrift/rest服務(wù)化；ApsaraDB for HBase2.0陸續(xù)開放更強大的檢索功能，包括全文檢索、圖檢索、空間檢索等，滿足企業(yè)更復(fù)雜的業(yè)務(wù)檢索需求。?
??????在HBase內(nèi)核層+存儲層上，ApsaraDB for HBase2.0 采用的最新版的2.0內(nèi)核，結(jié)合阿里HBase多年的技術(shù)積累經(jīng)驗，針對企業(yè)上云繼續(xù)完善、優(yōu)化更多商業(yè)化功能。例如：?
????????1. 本地盤：服務(wù)器直通本地盤讀寫，效率高，成本低，相比高效云盤降低5倍。20T起購買。?
????????2. 共享存儲：實現(xiàn)HBase共享存儲，動態(tài)添加容量包，使用靈活，成本低。?
????????3. 冷熱分離：冷熱數(shù)據(jù)分別存儲不同介質(zhì)?
????????4. 備份恢復(fù)：支持增量、全量備份恢復(fù)，支持跨集群跨機房容災(zāi)備份。?
????????5. 企業(yè)安全：基于Intel&alibaba合作Hadoop Authentication Service安全項目， 兼容hadoop/hbase生態(tài)kerberos認(rèn)證。?
????????6. 離線彈性作業(yè)：為hbase批處理業(yè)務(wù)運行離線作業(yè)的彈性計算平臺，使得hbase存儲計算分離，把系統(tǒng)compaction、備份恢復(fù)、索引構(gòu)建以及用戶作業(yè)單獨啟動彈性計算資源進行離線處理，計算完后立刻釋放，彈性伸縮。?
????????7. SQL二級索引：支持phoenix二級索引，優(yōu)化索引構(gòu)建與查詢功能。?
????????8. 全文檢索：支持solr全文索引，滿足復(fù)雜的檢索功能。?
??????綜合來說，ApsaraDB for HBase2.0是圍繞企業(yè)HBase上云的使用環(huán)境，從內(nèi)核功能到性能，從自動運維到專家坐診，從開發(fā)效率到生產(chǎn)成本，完善的HBase生態(tài)體系，都為用戶業(yè)務(wù)輕松上云穩(wěn)定保駕護航。

五、申請試用

??????ApsaraDB for HBase2.0 于2018年6月6號正式發(fā)布，并開通公測申請，歡迎大家申請試用！點擊了解更多

原文鏈接

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

總結(jié)

以上是生活随笔為你收集整理的八年磨一剑，阿里云ApsaraDB for HBase2.0正式上线的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。