BigData NoSQL —— ApsaraDB HBase數據存儲與分析平臺概覽

1、引言

時間到了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，歡迎你們關注，並貢獻代碼。接下來筆者會介紹各層，力求簡單通俗，文中有大量的連接以衍生閱讀。

2、業務視角及數據流

做爲一個存儲計算平臺，價值在知足不一樣的業務需求。見下圖：
此圖描述了數據的來源、通道到沉澱到雲HBase平臺，再經過平臺提供的Spark引擎去挖掘價值反饋給業務系統。此相似一個循環系統，在阿里內部形象稱爲【業務數據化，再數據業務化】。

結合架構圖及業務圖，此平臺融合了 存儲（包括實時存儲及離線存儲）、計算、檢索等技術。整個系統都打造在ApsaraDB Filesystem統一文件層之上，把檢索經過Phoenix的SearchIndex包裝以下降易用性，打造領域引擎知足領域的需求，內置BDS(數據通道)實時歸檔數據到列存，再經過Spark引擎挖掘價值。
詳細參考：【選擇阿里雲數據庫HBase版十大理由】

3、統一文件訪問層

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

4、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優化實踐爲例

5、檢索層

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封裝，並在存儲查詢等方面作了一系列優化升級，該部分在下個章節將會介紹。

6、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入門到精通

7、多模領域層

數據類型有表格、文檔、寬表、圖、時序、時空等不一樣的類型。雲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上線，場景、功能、優點全解析

8、列式存儲

行列混合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直接進行查詢；而對於離線場景的轉存，用戶能夠在控制檯上根據自身業務須要進行配置，能夠自定義在業務低峯期進行轉存，也能夠選擇是否進行增量和全量合併，後臺調度系統會自動觸發轉存邏輯。

9、分析層

在雲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，查詢性能可達毫秒級別。

10、數據工做臺

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

11、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等

12、後記

存儲、檢索、分析是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?

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。