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

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

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

二、深入解讀云HBase架構

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

2.1 存儲計算分離

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

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

2.2 冷熱分離/分級存儲

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

??????如圖所示，架構分兩階段，第一階段實現分級存儲，用戶可以清晰的按照不同訪問頻度將數據存儲到不同冷熱級別的表上，從表級別上區分冷熱數據，實現分級存儲。第二階段是同表數據冷熱數據自動分離，用戶可以按照訪問頻率或者創建時間等條件，指定冷熱數據判斷標準依據，最終后端自動分離冷熱數據分別存儲。

2.3 一寫多讀/讀高可用

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

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

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

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

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

2.5 安全體系

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

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

2.6 備份恢復

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

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

三、2.0版本內核解讀

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

3.1 新版Region分配器AMv2——穩定性提高

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.5 支持高效對象存儲

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

??????這樣可以減少split/compaction的影響，但是一致性時由客戶端來保證的。另一方面，MOB對象一般是100k~10M的數據，此方案就是每個MOB對象在HDFS上保存一個文件，會產生非常多的小物件，很可能系統很快就使用完了文件句柄打開數。如果優化一下，把許多MOB寫到HDFS序列文件上，hbase記錄保存著MOB對象的文件路徑和數據offset，確實解決了小文件問題，但是有帶來另一個問題，那就是很難維護這些MOB對象數據的一致性，并且很難維護刪除操作。?
??????HBase2.0 MOB功能類似上述的第二種功能，hbase+HDFS文件的方式實現。不同的是，這些都是在server端完成，不需要client去維護數據的一致性。并且保存的HDFS文件不是簡單的hdfs序列文件，而是HFile。這樣它就可以有效管理這些MOB數據，并且和普通hfile一樣處理deleted數據。?
????????MOB數據的讀流程是：?
????????????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也并不是必要的。當然系統會設計compaction策略來定期刪除掉那些deleted的數據，以騰出空間來。MOB的實現，使得用戶在保存中等對象時，不必自己維護數據的一致性，更兼容了現在的HBase api操作MOB hfile。

3.6 異步client ——提高客戶端并發/吞吐

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

3.7 異步DFSClient——提高服務端性能

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

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

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

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

四、展望

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

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

五、申請試用

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

原文鏈接

本文為云棲社區原創內容，未經允許不得轉載。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。