摘要： 數據庫發展有三個明顯的趨勢：1. 越來越多的數據庫會做雲原生(CloudNative)；2. NoSQL正在解決BigData領域的問題；3. 越來越多的公司或者產品都是融合多個能力。 阿里雲HBase經過公共雲兩年（單獨的HBase在阿里內部已經發展快9年）的發展，融合開源Apache HBase、Apache Phoenix、Apache Spark、Apache Solr等開源項目，再加上一系列自研特性，滿足 【一體化數據處理平臺，提供一站式能力】。

一、引言

時間到了2019年，數據庫也發展到了一個新的拐點，有三個明顯的趨勢：

1. 越來越多的數據庫會做雲原生(CloudNative)，會不斷利用新的硬件及雲本身的優勢打造CloudNative數據庫，國內以阿里雲的Cloud HBase、POLARDB為代表，此塊文章會有一定的引述，但不是本文的重點。
2. NoSQL正在解決BigData領域的問題。根據Forrester NoSQL的報告，BigData NoSQL是提供 存儲、計算處理、支持水平擴展、Schemaless以及靈活的數據模型，特別提到需要支持複雜計算，一般通過集成Spark或者實現單獨的計算引擎實現。Cassandra商業化公司Datastax提供的產品是直接在Cassandra之上集成了Spark，另外ScyllaDB公司首頁的宣傳語就是The Real-Time Big Data Database。大數據的5V特性，包括 Volume：數據量大，包括採集、存儲和計算的量都非常大；Variety：種類和來源多樣化，包括結構化、半結構化和非結構化數據；Value：數據價值密度相對較低，或者說是浪裡淘沙卻又彌足珍貴；Velocity：數據增長速度快，處理速度也快，時效性要求高；Veracity：數據的準確性和可信賴度，即數據的質量需要高。5V特性可以使用BigData NoSQL數據庫很好的滿足，且又能滿足實時的寫入，分析及展現。
3. 越來越多的公司或者產品都是融合多個能力，Strapdata公司把Cassandra及ElasticSearch的能力融合在一起；Datastax直接在Cassandra之上集成了Spark；SQLServer也是融合了Spark，打造Native Spark滿足DB計算能力外延的商業訴求。

阿里雲HBase經過公共雲兩年（單獨的HBase在阿里內部已經發展快9年）的發展，融合開源Apache HBase、Apache Phoenix、Apache Spark、Apache Solr等開源項目，再加上一系列自研特性，滿足 【一體化數據處理平臺，提供一站式能力】 , 基本架構如下：

我們是站在Apache巨人的肩膀上，自研了 ApsaraDB Filesystem、HBase冷熱分離、SearchIndex、SparkOnX、BDS等模塊，優化了HBase、Phoenix、Spark等內核一些patch，並反饋到社區，維護打造了多模服務、數據工作臺等一些列的平臺能力。自研部分是我們平臺核心的核心競爭力，每一層每一個組件都是我們精心打造，滿足客戶數據驅動業務的實際需求。為了降低客戶的准入門檻，我們在Github上提供了Demo支持：aliyun-apsaradb-hbase-demo，歡迎大家關注，並貢獻代碼。接下來筆者會介紹各層，力求簡單通俗，文中有大量的鏈接以衍生閱讀。

二、業務視角及數據流

作為一個存儲計算平臺，價值在滿足不同的業務需求。見下圖：

此圖描述了數據的來源、通道到沉澱到雲HBase平臺，再通過平臺提供的Spark引擎去挖掘價值反饋給業務系統。此類似一個循環系統，在阿里內部形象稱為【業務數據化，再數據業務化】。

結合架構圖及業務圖，此平臺融合了 存儲（包括實時存儲及離線存儲）、計算、檢索等技術。整個系統都打造在ApsaraDB Filesystem統一文件層之上，把檢索通過Phoenix的SearchIndex包裝以降低易用性，打造領域引擎滿足領域的需求，內置BDS(數據通道)實時歸檔數據到列存，再通過Spark引擎挖掘價值。

詳細參考：【選擇阿里雲數據庫HBase版十大理由】

三、統一文件訪問層

ApsaraDB Filesystem（簡稱ADB FS）以Hadoop FileSystem API為基礎構建了雲HBase生態文件層底座。面向HBase生態提供了無感知的混合存儲能力，極大簡化了HBase生態接入雲端多存儲形態的複雜環境。支持OSS、阿里雲HDFS、基於雲盤或者本地盤構建的HDFS以及基於共享雲盤構建的系統。每種分佈式文件系統所用的硬件不同、成本不同、延遲不同、吞吐量不同（這裡不展開）。我們可以不斷擴展，只要添加一個實現xxxFileSystem即可。基於OSS直接實現的FS是無法具備原子性的元數據管理能力的，實現方案是在HDFS的namenode存元數據，實際的存儲存放在OSS之上。對Rename操作只需要移動元數據，所以非常輕量。

四、HBase KV層

HBase是基於Bigtable在hadoop社區的開源實現，提供瞭如：稀疏寬表、TTL、動態列等特性。HBase在阿里已經發展9年，已經有數位PMC及Committer，可以說在國內阿里在HBase的影響力還是數一數二的。社區也有不少的Patch也是阿里貢獻。在18年，雲HBase首家商業化了HBase2.0，並貢獻了數十個BugFix給社區。有不少客戶單獨使用HBase API滿足業務需求，也有不少客戶使用Phoenix NewSQL層，NewSQL層提升易用性及提供了很多好用的功能。在HBase層面，除了修復社區的Bug以外，也做了幾個較大的特性。

在對比關係型數據方面，HBase也有天然的優勢，參考：對比MySQL，一文看透HBase的能力及使用場景

• 冷熱分離
• 冷熱分離可以降低存儲成本66%左右。廣泛應用於車聯網、冷日誌等場景下。我們把冷數據存放到OSS之上，且用戶還可以使用HBase的API訪問。基本原理是：把Hlog存在HDFS之上，再把冷的HFile存放在OSS之上。

• GC優化
• GC一直是Java應用中討論的一個熱門話題，尤其在像HBase這樣的大型在線存儲系統中，大堆下(百GB)的GC停頓延遲產生的在線實時影響，成為內核和應用開發者的一大痛點。平臺實現了CCSMap新的內存存儲結構，結合offheap及新的ZenGC等一列的優化，在生產環境young GC時間從120ms減少到15ms，在實驗室進一步降低到5ms左右。可以參考文章：如何降低90%Java垃圾回收時間？以阿里HBase的GC優化實踐為例

五、檢索層

HBase底層基於LSM，擅長前綴匹配和範圍查找，數據模型上屬於行存，大範圍掃描數據對系統影響很大。我們知道，用戶的需求往往是各式各樣，不斷變化的。對於要求高TPS，高併發，查詢業務比較固定且簡單的場景，HBase可以很好滿足。更復雜一些，當用戶對同一張表的查詢條件組合有固定多個時，可以通過二級索引的方式來解決，但是二級索引有寫放大問題，索引數量不能太多，一般建議不超過10個。當面對更復雜的查詢模式，比如自由條件組合，模糊查詢，全文查詢等，用當前的索引技術是無法滿足的，需要尋求新的解決方案。我們容易想到，搜索引擎，比如Lucene、Solr以及ElasticSearch，是專門面向複雜查詢場景的。為了應對各種複雜的查詢需求，搜索引擎運用到了大量跟LSM Tree十分不同的索引技術，比如倒排、分詞、BKD Tree做數值類型索引、roaring bitmap實現聯合索引、DocValues增強聚合和排序等。使用搜索引擎的技術來增強HBase的查詢能力是一個十分值得深入探索的技術方向。

當前用戶要想實現，複雜查詢，只能重新購買新的搜索集群，通過導數據的方式將數據導入到新的搜索服務中。這種方式存在很多這樣那樣的問題：維護成本比較高，需要購買在線數據庫，分析數據庫和數據傳輸服務；學習門檻高，需要同時熟悉至少上訴三種服務；無法保證實時性，在線庫入庫和檢索庫入庫效率不匹配；數據冗餘存儲，在線庫索引數據和結果數據設計的所有數據都需要導入；數據一致性難保證，數據亂序問題十分常見，特別是對於分佈式在線庫更是如此。雲HBase引入Solr，並在產品和內核上做了一系列工作，將其打造成統一的產品體驗，一攬子解決了前述所有問題。用戶在控制檯上一鍵可以開通檢索服務，參考文章：雲HBase發佈全文索引服務,輕鬆應對複雜查詢。

檢索服務的架構如上圖所示，最底層是分佈式文件系統的統一抽象，HBase的數據和Solr中的數據都會存儲在分佈式文件系統中。最上層是分佈式協調服務Zookeeper，HBase、Indexer、Solr都是基於其實現分佈式功能。Indexer實現了存量HBase數據的批量導入功能，有針對性地實現了數據批量導入的分佈式作業機制。Indexer服務也實現了實時數據的異步同步功能，利用HBase的後臺Replication機制，Indexer實現了Fake HBase功能，接收到HBase的數據後，將其轉換為Solr的document，並寫入solr。針對HBase寫入速度比Solr快的問題，我們設計並實現了反壓機制，可以將Solr中數據的延遲控制在用戶設定的時間範圍內，該機制同時也避免了HLog消費速度過慢的堆積問題。實時同步和批量導入可以同時運行，我們通過保序的時間戳保證了數據的最終一致性。為了提高產品的易用性，我們還基於Phoenix 實現了檢索服務的SQL封裝，並在存儲查詢等方面做了一系列優化升級，該部分在下個章節將會介紹。

六、NewSQL Phoenix

Phoenix是HBase之上的SQL層，Phoenix讓HBase平臺從NoSQL直接進化到了NewSQL。在HBase的基礎之上，再支持了Schema、Secondary Indexes、View 、Bulk Loading(離線大規模load數據)、Atomic upsert、Salted Tables、Dynamic Columns、Skip Scan等特性。目前雲上最大客戶有200T左右，且50%+的客戶都開通了Phoenix SQL服務。我們修復了社區數十個Bug及提了不少新特性，團隊也擁有1位Committer及數位contributor。在18年我們在充分測試的基礎上，先於社區正式商業化了Phoenix5.0，並支持了QueryServer,支持輕量的JDBC訪問。同時，社區的5.0.1也將由我們推動發佈。

Phoenix本身我們做了一系列穩定性，性能等方面的優化升級，主要有：客戶端優化MetaCache機制，大數據量簡單查詢性能提升一個數量級；索引表回查主表，使用lookupjoin的方式優化，性能提升5到7倍；輕客戶端優化batch commit，性能提升2到3倍；解決Phoenix時區問題，提高易用性，降低數據一致性問題概率；禁用DESC，掃全表等有風險功能；實現大批量數據導入的Bulkload功能；等等。這些穩定性和性能方面的提升，在用戶側得到了很好的反饋。

Phoenix目前基本的架構如圖所示，我們讓Phoenix支持了HBase和Solr雙引擎，用戶可以使用SQL實現對HBase和Solr數據的管理和查詢，大大提高了系統的易用性。Solr和HBase之間的同步機制可以參考上節。在支持複雜查詢方面，我們設計並實現了一種新的索引：Search Index，使用方式跟Phoenix的Global Index類似，主要區別在於Search Index的索引數據存儲在Solr裡面，而Global Index的索引數據是一張單獨的HBase表。直接通過SQL管理Search Index的生命週期、數據同步和狀態，自動映射數據字段類型，並通過SQL支持複雜查詢，這極大降低了用戶的使用門檻。Search Index可以統一根據HBase和Solr的特性做優化，由於原表在HBase中可以通過RowKey高效查詢，Solr中只需要存儲作為查詢條件的字段的索引數據，查詢字段的原數據不需要存儲在Solr中，表中的非查詢字段則完全不需要存儲到Solr中。相對於用戶單獨購買檢索產品，並同步數據的方案，Search Index可以大大降低存儲空間。同時，根據索引特性，Phoenix在做執行計劃優化時，可以動態選擇最優的索引方案。

我們還打造了一個系列的文章，這些文章是很多國內用戶熟悉和學習Phoenix的入門資料，在社區裡面也收穫了較高的影響力，參考 Phoenix入門到精通

七、多模領域層

數據類型有表格、文檔、寬表、圖、時序、時空等不同的類型。雲HBase之上打造了 HGraphDB分佈式圖層、OpenTSDB分佈式時序層、Ganos分佈式空間層，分別滿足3大子場景的訴求。每個都是分佈式的組件，具備PB級別的存儲、高併發讀寫及無限擴展的能力。

• HGraphDB
• HGraphDB是雲HBase完全自研的組件。HGraphDB基於Tinker pop3實現，支持集成Tinker pop3全套軟件棧以及Gremlin語言。HGraphDB是一個OLTP圖庫，支持schema以及頂點和邊的增刪改查還有圖的遍歷。圖數據庫HGraphDB介紹
• OpenTSDB
• OpenTSDB是社區在HBase的基礎之上提供的時序引擎，以HBase為底座，滿足PB級別的時序存儲需求。團隊做了大量優化，為了提升穩定性，其中【時間線壓縮優化】是一個比較重要的優化，見：雲HBase之OpenTSDB時序引擎壓縮優化
• Ganos
• Ganos取名於大地女神蓋亞（Gaea）和時間之神柯羅諾斯（Chronos），代表著“時空” 結合。Ganos空間算子增強、時空索引增強、GeoSQL擴展等，與Spark結合支持大規模遙感空間數據在線分析與管理。詳細參考文章：阿里雲時空數據庫引擎HBase Ganos上線，場景、功能、優勢全解析

八、列式存儲

行列混合HTAP一直是各大數據庫夢寐追求大統一的技術，類似於M理論想統一量子力學與萬有引力。目前看起來一份存儲難以滿足各種訴求，通用的做法是行存與列存的數據分開存，實現手段一種是通過同步的方案把行存的數據再轉存一份列存，另一種是通過raft等變種協議的手段實現行列副本同時存在。

HBase擅長在線查詢場景，底層的HFile格式實際還是行存，直接Spark分析HBase表在大範圍查詢的情況下性能一般(Spark On HBase也有很多優化點)。在這樣的背景下我們構建了HBase的實時HLog增量同步歸檔到列存的鏈路，來有效滿足用戶對於HBase數據分析的需求。列存的壓縮比比行存高，增加部分存儲成本，有效的增強分析能力，用戶是能夠接受的。HBase搭配列存可以有效的驅動用戶業務的發展，列存分析後的結果數據迴流到HBase支持業務，讓用戶業務在HBase平臺中快速迭代。在列存之中，也有類似LSM的 Delta+全量的，比如Kudu以及 Delta Lake。雲HBase參考了Delta Lake及Parquet技術，提供更加高效的一體化分析。

• Parquet
• Parquet的靈感來自於2010年Google發表的Dremel論文，文中介紹了一種支持嵌套結構的存儲格式，並且使用了列式存儲的方式提升查詢性能，目前Parquet已經是大數據領域最有代表性的列存方式，廣泛應用於大數據數據倉庫的基礎建設。
• Delta
• Delta原本是Spark的商業公司Databriks在存儲方面做的閉源特性，偏向實時讀寫，已於近期開源，核心是解決了大數據分析場景中常見的數據更新的問題。具體做法按列式格式寫數據加快分析讀，增量更新數據 delta 則採取行式寫入支持事務和多版本，然後系統通過後臺不斷地進行合併。
• 一鍵同步

用戶可以根據自身的業務需求進行轉存，對於對實時性要求比較高的用戶，可以選擇實時同步的方式，BDS服務會實時解析HLog並轉存到Delta，用戶可以通過Spark對Delta直接進行查詢；而對於離線場景的轉存，用戶可以在控制檯上根據自身業務需要進行配置，可以自定義在業務低峰期進行轉存，也可以選擇是否進行增量和全量合併，後臺調度系統會自動觸發轉存邏輯。

九、分析層

在雲HBase平臺裡面沉澱了不少數據，或者在進入雲HBase平臺的數據需要流ETL，參考業界的通用做法，目前最流行的計算引擎是Spark，我們引入Apache Spark來滿足平臺的數據處理需求。Spark採取的是DAG的執行引擎，支持SQL及編程語言，比傳統的MR快100倍，另外支持流、批、機器學習、支持SQL&Python&Scala等多種編程語言。雲HBase平臺提供的能力有流式的ETL、Spark on HBase(也包括其它數據庫)及HBase數據轉為列存後的分析。為了滿足Spark低成本運行的需求，我們即將支持Serverless的能力。Spark在數據庫之間，處於一個膠水的作用，平臺通過Spark打造數據處理的閉環系統以核心客戶的核心問題，比如點觸科技的遊戲大數據平臺

• 支持流式處理
• 大部分的系統之中，數據經過中間件之後需要一些預處理再寫入到HBase之中，一般需要流的能力。Spark Streaming提供秒級別的流處理能力，另外Structured Streaming可以支持更低時延。平臺支持Kafka、阿里雲LogHub、DataHub等主要的消息通道。關於很多從業者關心的Spark跟Flink對比的問題，其一，Flink基於pipeline模式的流比Spark基於mini batch的流在延遲上要低，功能上也更強大，但是大部分用戶很難用到毫秒級和高階功能，Spark的流滿足了大部分場景；其二，Spark生態要比Flink成熟，影響力也更大。
• Spark On X
• 分析層不僅僅支持HBase、Phoenix以外，也包括POALRDB、MySQL、SQLServer、PG、Redis、MongoDB等系統。比如：歸檔POLARDB數據做分析，Spark On X支持schema映射、算子下推、分區裁剪、列裁剪、BulkGet、優先走索引等優化。算子下推可以減少拉取DB的數據量，以及減少DB的運算壓力，從而提高Spark On X的運算性能。HBase一般存儲海量數據，單表可達千億、萬億行數據，Spark On HBase的rowkey過濾字段下推到HBase，查詢性能可達毫秒級別。

十、數據工作臺

在線DB一般是業務系統連接DB的，但離線的作業與在線的平臺不一樣，需要提供Job的管理及離線定時運行，另外還需要支持交互式運行。在雲HBase平臺上，我們提供了 【數據工作臺】來滿足這一需求。數據工作臺能力有：資源管理、作業管理、工作流、回話管理、交互式查詢、及作業的告警。作業可以是jar包、python腳本、SQL腳本等；工作流可以把多個作業關聯在一起，並可以週期性或者指定固定時間運行；回話管理可以啟動一個在線的交互式Spark回話滿足交互式查詢的訴求；交互式查詢可以滿足在線運行 sql腳本、python及scala腳本。

十一、DBaaS

雲HBase構建了一整套的管理系統，支持全球部署、監控報警(包括雲監控及原生自帶監控頁面)、在線擴容、安全白名單、VPC網絡隔離、在線修改配置、公網訪問、小版本在線一鍵升級、分階段低峰期MajorCompaction優化、自動檢測集群可用狀態緊急報警人工干預、磁盤容量水位報警等等運維操作及自動化優化。 平臺提供7*24小時人工答疑及諮詢，可直接諮詢釘釘號 雲HBase答疑。除此之外，打造了2大企業級特性，備份恢復、BDS服務

• 備份恢復
• HBase的數據也是客戶的核心資產，為了保障客戶的數據不被意外刪除（經常是用戶自己誤刪）時，我們內置了備份恢復的服務。此服務是直接獨立於HBase內核，單獨進程保障的。基本原理是全量數據拉HFile，增量數據拉Hlog。滿足了數百TB數據的備份恢復，實時備份的延遲時間在數分鐘以內。數據恢復可以滿足按照時間點恢復，數百TB規模的集群基本在2天內完成恢復。不管是備份還是恢復都不影響原來的集群繼續提供服務。其中細節點也較多，可以參考訪問：雲HBase備份恢復，為雲HBase數據安全保駕護航
• BDS服務
• 數據遷移是一個重的事項，尤其當類似如HBase數十TB數據的遷移。我們專門為雲HBase打造數據遷移的服務，命名為BDS。此服務滿足各類數據遷移及同步的場景，包括自建HBase集群遷移上阿里雲HBase、跨地域遷移，例如從青島機房遷移到北京機房、HBase1.x升級HBase2.x、網絡環境經典網絡切換成VPC等

十二、後記

存儲、檢索、分析是BigData三大核心的能力，也是BigData NoSQL著力打造的核心能力，通過深度整合，更好解決客戶風控、畫像等數據驅動業務的問題。阿里云云HBase團隊，基於雲上環境的種種特性，打造了Native的眾多優勢，目前服務了數千家中小型企業。另外，為了服務中國廣大的開發者，自從18年5月，發起成立了【中國HBase技術社區】，舉辦線下meetup 9場次，邀請內外部嘉賓數十人，報名2801人，公眾號1.1w人，直播觀看2.1+w人，影響數萬企業。特別為開發者提供免費版新人1個月的免費試用，以方便其開發學習以及交流。

未來，我們將繼續緊緊貼合雲上用戶需求打磨產品，打造核心競爭力，提升易用性，保障系統穩定性，以及引入Serverless特性以進一步降低成本。

If not now, when? If not me, who?

作者：明朔