八年磨一劍，阿里雲ApsaraDB for HBase2.0正式上線

時間 2019-11-08

標籤八年 8年阿里 apsaradb hbase2.0 hbase 正式上線欄目阿里巴巴简体版

原文原文鏈接

1、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!html

2、深刻解讀雲HBase架構

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

2.1 存儲計算分離

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

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

2.2 冷熱分離/分級存儲

通常企業隨着業務數據不斷增加，數據量開始變大，這個時候就須要對數據進行冷熱程度區分對待，以優化系統總體運行效率，並下降成本。舉個例子，如：冷數據寫入一次後，可能好久才被訪問一次，可是由於和熱數據存儲在一個數據塊上，可能讀這個熱數據的時候，冷數據也被順帶讀到內存中，這多是沒有必要的，咱們更多但願被順帶讀出來的也是即將被訪問的熱數據。另外，由於熱數據的頻繁更新寫入，可能會引發系統更多得split、compaction等動做，這個時候，冷數據也被順帶一塊兒屢次讀寫磁盤了，實際上冷數據可能不須要這麼頻繁地進行這種系統動做。再從成本考慮，業務上若是廣泛能夠接受陳年舊事——冷數據被訪問延時相對高一點點，那麼就能夠考慮把這些數據存儲在成本較低的介質中。
基於這種常見的企業場景需求，ApsaraDB for HBase2.0在阿里雲基礎體系之上，設計了雲HBase冷熱分離/分級存儲架構，實現企業雲上HBase應用的冷熱分離場景需求，提升系統運行效率的同時，又下降存儲成本。apache

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

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功能，實現一寫多讀，擴充了高可用讀的能力。api

如上圖，開啓這個功能的表，region會被分配到多個RegionServer上，其中replicaId=0的爲主region，其餘的爲從region，只有主region能夠寫入，主region負責 flush memstore成爲hfile，從region一方面根據hfile列表類讀到數據，另外一方面對於剛寫入主region但尚未flush到hdfs上的數據，經過replication同步到從region的memstore。如上圖所示，client1分別時間間隔內寫入x=一、x=二、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能夠在訪問當下集羣不可用時，自動切換到備用集羣進行數據訪問業務。

3、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複雜流程：

      如上圖流程顯示，第一、二、3條線是Master進程的不一樣線程，第4條是zk，第五、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=一、x=二、x=3，在同步數據的時候時，client2進行讀x的值，它是能夠讀任何一臺server上的x值，這就保證了讀的高可用性，即便有n臺機器掛了(n小於一個region的副本數)也能夠有 99.9%延時 <20ms保證。能夠看到這種架構讀是高可用的，合適一寫多讀的場景。
這裏還提供了兩種讀一致性模式，分別是strong和timeline-consistent模式，strong模式下，只讀取主region的數據返回結果；timeline-consistent模式下，容許讀任何一個region replica的數據返回。

4、展望

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生態體系，都爲用戶業務輕鬆上雲穩定保駕護航。