阿里妹導讀：Lindorm，就是云操作系統(tǒng)飛天中面向大數(shù)據(jù)存儲處理的重要組成部分。Lindorm是基于HBase研發(fā)的、面向大數(shù)據(jù)領(lǐng)域的分布式NoSQL數(shù)據(jù)庫，集大規(guī)模、高吞吐、快速靈活、實時混合能力于一身，面向海量數(shù)據(jù)場景提供世界領(lǐng)先的高性能、可跨域、多一致、多模型的混合存儲處理能力。目前，Lindorm已經(jīng)全面服務(wù)于阿里經(jīng)濟體中的大數(shù)據(jù)結(jié)構(gòu)化、半結(jié)構(gòu)化存儲場景。

注：Lindorm是阿里內(nèi)部HBase分支的別稱，在阿里云上對外售賣的版本叫做HBase增強版，之后文中出現(xiàn)的HBase增強版和Lindorm都指同一個產(chǎn)品。

2019年以來，Lindorm已經(jīng)服務(wù)了包括淘寶、天貓、螞蟻、菜鳥、媽媽、優(yōu)酷、高德、大文娛等數(shù)十個BU，在今年的雙十一中，Lindorm峰值請求達到了7.5億次每秒，天吞吐22.9萬億次，平均響應(yīng)時間低于3ms，整體存儲的數(shù)據(jù)量達到了數(shù)百PB。這些數(shù)字的背后，凝聚了HBase&Lindorm團隊多年以來的汗水和心血。Lindorm脫胎于HBase，是團隊多年以來承載數(shù)百PB數(shù)據(jù)，億級請求量，上千個業(yè)務(wù)后，在面對規(guī)模成本壓力，以及HBase自身缺陷下，全面重構(gòu)和引擎升級的全新產(chǎn)品。相比HBase，Lindorm無論是性能，功能還是可用性上，都有了巨大飛躍。本文將從功能、可用性、性能成本、服務(wù)生態(tài)等維度介紹Lindorm的核心能力與業(yè)務(wù)表現(xiàn)，最后分享部分我們正在進行中的一些項目。

極致優(yōu)化，超強性能

Lindorm比HBase在RPC、內(nèi)存管理，緩存、日志寫入等方面做了深度的優(yōu)化，引入了眾多新技術(shù)，大幅提升了讀寫性能，在相同硬件的情況下，吞吐可達到HBase的5倍以上，毛刺更是可以達到HBase的1/10。這些性能數(shù)據(jù)，并不是在實驗室條件下產(chǎn)生的，而是在不改動任何參數(shù)的前提下，使用開源測試工具YCSB跑出來的成績。我們把測試的工具和場景都公布在阿里云的幫助文件中，任何人都可以依照指南自己跑出一樣的結(jié)果。

取得這么優(yōu)異的性能的背后，是Lindorm中積攢多年的“黑科技”，下面，我們簡單介紹下Lindorm內(nèi)核中使用到的部分“黑科技”。

Trie Index

Lindorm 的文件LDFile（類似HBase中的HFile）是只讀 B+ 樹結(jié)構(gòu)，其中文件索引是至關(guān)重要的數(shù)據(jù)結(jié)構(gòu)。在 block cache 中有高優(yōu)先級，需要盡量常駐內(nèi)存。如果能降低文件索引所占空間大小，我們可以節(jié)省 block cache 中索引所需要的寶貴內(nèi)存空間。或者在索引空間不變的情況下，增加索引密度，降低 data block 的大小，從而提高性能。而HBase中的索引block中存的是全量的Rowkey，而在一個已經(jīng)排序好的文件中，很多Rowkey都是有共同前綴的。

數(shù)據(jù)結(jié)構(gòu)中的Trie (前綴樹) 結(jié)構(gòu)能夠讓共同前綴只存一份，避免重復存儲帶來的浪費。但是傳統(tǒng)前綴樹結(jié)構(gòu)中，從一個節(jié)點到下一個節(jié)點的指針占用空間太多，整體而言得不償失。這一情況有望用 Succinct Prefix Tree 來解決。SIGMOD2018年的最佳論文 Surf 中提出了一種用 Succinct Prefix Tree 來取代 bloom filter，并同時提供 range filtering 的功能。我們從這篇文章得到啟發(fā)，用 Succinct Trie 來做 file block index。

我們在線上的多個業(yè)務(wù)中使用了Trie index實現(xiàn)的索引結(jié)構(gòu)。結(jié)果發(fā)現(xiàn)，各個場景中，Trie index可以大大縮小索引的體積，最多可以壓縮12倍的索引空間！節(jié)省的這些寶貴空間讓內(nèi)存Cache中能夠存放更多的索引和數(shù)據(jù)文件，大大提高了請求的性能。

ZGC加持，百GB堆平均5ms暫停

ZGC(Powerd by Dragonwell JDK)是下一代Pauseless GC算法的代表之一，其核心思想是Mutator利用內(nèi)存讀屏障(Read Barrier)識別指針變化，使得大部分的標記(Mark)與合并(Relocate)工作可以放在并發(fā)階段執(zhí)行。 這樣一項實驗性技術(shù)，在Lindorm團隊與AJDK團隊的緊密合作下，進行了大量的改進與改造工作。使得ZGC在Lindorm這個場景上實現(xiàn)了生產(chǎn)級可用，主要工作包括：

Lindorm內(nèi)存自管理技術(shù)，數(shù)量級減少對象數(shù)與內(nèi)存分配速率。(比如說阿里HBase團隊貢獻給社區(qū)的CCSMap)。

AJDK ZGC Page緩存機制優(yōu)化(鎖、Page緩存策略)。

AJDK ZGC 觸發(fā)時機優(yōu)化，ZGC無并發(fā)失敗。AJDK ZGC在Lindorm上穩(wěn)定運行兩個月，并順利通過雙十一大考。其JVM暫停時間穩(wěn)定在5ms左右，最大暫停時間不超過8ms。ZGC大大改善了線上運行集群的RT與毛刺指標，平均RT優(yōu)化15%～20%，P999 RT減少一倍。在今年雙十一螞蟻風控集群中，在ZGC的加持下，P999時間從12ms降低到了5ms。

注：圖中的單位應(yīng)該為us，平均GC在5ms

LindormBlockingQueue

上圖是HBase中的RegionServer從網(wǎng)絡(luò)上讀取RPC請求并分發(fā)到各個Handler上執(zhí)行的流程。HBase中的RPC Reader從Socket上讀取RPC請求放入BlockingQueue，Handler訂閱這個Queue并執(zhí)行請求。而這個BlockingQueue，HBase使用的是Java原生的JDK自帶的LinkedBlockingQueue。

LinkedBlockingQueue利用Lock與Condition保證線程安全與線程之間的同步，雖然經(jīng)典易懂，但當吞吐增大時，這個queue會造成嚴重的性能瓶頸。因此在Lindorm中全新設(shè)計了LindormBlockingQueue，將元素維護在Slot數(shù)組中。維護head與tail指針，通過CAS操作對進隊列進行讀寫操作，消除了臨界區(qū)。并使用Cache Line Padding與臟讀緩存加速，同時可定制多種等待策略(Spin/Yield/Block)，避免隊列為空或為滿時，頻繁進入Park狀態(tài)。LindormBlockingQueue的性能非常突出，相比于原先的LinkedBlockingQueue性能提升4倍以上。

VersionBasedSynchronizer

LDLog是Lindorm中用于系統(tǒng)failover時進行數(shù)據(jù)恢復時的日志，以保障數(shù)據(jù)的原子性和可靠性。在每次數(shù)據(jù)寫入時，都必須先寫入LDLog。LDLog寫入成功之后，才可以進行后續(xù)的寫入memstore等操作。因此Lindorm中的Handler都必須等待WAL寫入完成后再被喚醒以進行下一步操作，在高壓條件下，無用喚醒會造成大量的CPU Context Switch造成性能下降。針對這個問題，Lindorm研發(fā)了基于版本的高并發(fā)多路線程同步機制(VersionBasedSynchronizer)來大幅優(yōu)化上下文切換。

VersionBasedSynchronizer的主要思路是讓Handler的等待條件被Notifier感知，減少Notifier的喚醒壓力。經(jīng)過模塊測試VersionBasedSynchronizer的效率是JDK自帶的ObjectMonitor和J.U.C(java util concurrent包)的兩倍以上。

全面無鎖化

HBase內(nèi)核在關(guān)鍵路徑上有大量的鎖，在高并發(fā)場景下，這些鎖都會造成線程爭搶和性能下降。Lindorm內(nèi)核對關(guān)鍵鏈路上的鎖都做了無鎖化處理，如MVCC，WAL模塊中的鎖。另外，HBase在運行過程中會產(chǎn)生的各種指標，如qps，rt，cache命中率等等。而在記錄這些Metrics的“不起眼”操作中，也會有大量的鎖。面對這樣的問題，Lindorm借鑒了tcmalloc的思想，開發(fā)了LindormThreadCacheCounter，來解決Metrics的性能問題。

Handler協(xié)程化

在高并發(fā)應(yīng)用中，一個RPC請求的實現(xiàn)往往包含多個子模塊，涉及到若干次IO。這些子模塊的相互協(xié)作，系統(tǒng)的ContextSwitch相當頻繁。ContextSwitch的優(yōu)化是高并發(fā)系統(tǒng)繞不開的話題，各位高手都各顯神通，業(yè)界有非常多的思想與實踐。其中coroutine(協(xié)程)和SEDA(分階段事件驅(qū)動)方案是我們著重考察的方案。基于工程代價，可維護性，代碼可讀性三個角度考慮，Lindorm選擇了協(xié)程的方式進行異步化優(yōu)化。我們利用了阿里JVM團隊提供的Dragonwell JDK內(nèi)置的Wisp2.0功能實現(xiàn)了HBase Handler的協(xié)程化，Wisp2.0開箱即用，有效地減少了系統(tǒng)的資源消耗，優(yōu)化效果比較客觀。

全新Encoding算法

從性能角度考慮，HBase通常需要將Meta信息裝載進block cache。如果將block大小較小，Meta信息較多，會出現(xiàn)Meta無法完全裝入Cache的情況, 性能下降。如果block大小較大，經(jīng)過Encoding的block的順序查詢的性能會成為隨機讀的性能瓶頸。針對這一情況，Lindorm全新開發(fā)了Indexable Delta Encoding，在block內(nèi)部也可以通過索引進行快速查詢，seek性能有了較大提高。Indexable Delta Encoding原理如圖所示：

通過Indexable Delta Encoding， HFile的隨機seek性能相對于使用之前翻了一倍，以64K block為例，隨機seek性能基本與不做encoding相近（其他encoding算法會有一定性能損失）。在全cache命中的隨機Get場景下，相對于Diff encoding RT下降50%

其他

相比社區(qū)版HBase，Lindorm還有多達幾十項的性能優(yōu)化和重構(gòu)，引入了眾多新技術(shù)，由于篇幅有限，這里只能列舉一部分，其他的核心技術(shù)，比如：

• CCSMap
• 自動規(guī)避故障節(jié)點的并發(fā)三副本日志協(xié)議 (Quorum-based write)
• 高效的批量組提交(Group Commit)
• 無碎片的高性能緩存—Shared BucketCache
• Memstore Bloomfilter
• 面向讀寫的高效數(shù)據(jù)結(jié)構(gòu)
• GC-Invisible內(nèi)存管理
• 在線計算與離線作業(yè)架構(gòu)分離
• JDK/操作系統(tǒng)深度優(yōu)化
• FPGA offloading Compaction
• 用戶態(tài)TCP加速
• ……

豐富的查詢模型，降低開發(fā)門檻

原生的HBase只支持KV結(jié)構(gòu)的查詢，雖然簡單，但是在面對各項業(yè)務(wù)的復雜需求時，顯的有點力不從心。因此，在Lindorm中，我們針對不同業(yè)務(wù)的特點，研發(fā)了多種查詢模型，通過更靠近場景的API和索引設(shè)計，降低開發(fā)門檻。

WideColumn 模型（原生HBase API）

WideColumn是一種與HBase完全一致的訪問模型和數(shù)據(jù)結(jié)構(gòu)，從而使得Lindrom能100%兼容HBase的API。用戶可以通過Lindorm提供的高性能原生客戶端中的WideColumn API訪問Lindorm，也可以通過alihbase-connector這個插件，使用HBase客戶端及API(無需任何代碼改造)直接訪問Lindorm。同時，Lindorm使用了輕客戶端的設(shè)計，將大量數(shù)據(jù)路由、批量分發(fā)、超時、重試等邏輯下沉到服務(wù)端，并在網(wǎng)絡(luò)傳輸層做了大量的優(yōu)化，使得應(yīng)用端的CPU消耗可以大大節(jié)省。像下表中，相比于HBase，使用Lindorm后的應(yīng)用側(cè)CPU使用效率提升60%，網(wǎng)絡(luò)帶寬效率提升25%。

注：表中的客戶端CPU代表HBase/Lindorm客戶端消耗的CPU資源，越小越好。

在HBase原生API上，我們還獨家支持了高性能二級索引，用戶可以使用HBase原生API寫入數(shù)據(jù)過程中，索引數(shù)據(jù)透明地寫入索引表。在查詢過程中，把可能全表掃的Scan + Filter大查詢，變成可以先去查詢索引表，大大提高了查詢性能。

TableService模型(SQL、二級索引)

HBase中只支持Rowkey這一種索引方式，對于多字段查詢時，通常效率低下。為此，用戶需要維護多個表來滿足不同場景的查詢需求，這在一定程度上既增加了應(yīng)用的開發(fā)復雜性，也不能很完美地保證數(shù)據(jù)一致性和寫入效率。并且HBase中只提供了KV API，只能做Put、Get、Scan等簡單API操作，也沒有數(shù)據(jù)類型，所有的數(shù)據(jù)都必須用戶自己轉(zhuǎn)換和儲存。對于習慣了SQL語言的開發(fā)者來說，入門的門檻非常高，而且容易出錯。

為了解決這一痛點，降低用戶使用門檻，提高開發(fā)效率，在Lindorm中我們增加了TableService模型，其提供豐富的數(shù)據(jù)類型、結(jié)構(gòu)化查詢表達API，并原生支持SQL訪問和全局二級索引，解決了眾多的技術(shù)挑戰(zhàn)，大幅降低普通用戶的開發(fā)門檻。通過SQL和SQL like的API，用戶可以方便地像使用關(guān)系數(shù)據(jù)庫那樣使用Lindorm。下面是一個Lindorm SQL的簡單示例。

-- 主表和索引DDL create table shop_item_relation (shop_id varchar,item_id varchar,status varchar constraint primary key(shop_id, item_id)) ; create index idx1 on shop_item_relation (item_id) include (ALL); -- 對第二列主鍵建索引，冗余所有列 create index idx2 on shop_item_relation (shop_id, status) include (ALL); -- 多列索引，冗余所有列 -- 寫入數(shù)據(jù)，會同步更新2個索引 upsert into shop_item_relation values('shop1', 'item1', 'active'); upsert into shop_item_relation values('shop1', 'item2', 'invalid'); -- 根據(jù)WHERE子句自動選擇合適的索引執(zhí)行查詢 select * from shop_item_relation where item_id = 'item2'; -- 命中idx1 select * from shop_item_relation where shop_id = 'shop1' and status = 'invalid'; -- 命中idx2

相比于關(guān)系數(shù)據(jù)庫的SQL，Lindorm不具備多行事務(wù)和復雜分析(如Join、Groupby)的能力，這也是兩者之間的定位差異。相比于HBase上Phoenix組件提供的二級索引，Lindorm的二級索引在功能、性能、穩(wěn)定性上遠遠超過Phoenix，下圖是一個簡單的性能對比。

注：該模型已經(jīng)在阿里云HBase增強版上內(nèi)測，感興趣的用戶可以聯(lián)系云HBase答疑釘釘號或者在阿里云上發(fā)起工單咨詢。

FeedStream模型

現(xiàn)代互聯(lián)網(wǎng)架構(gòu)中，消息隊列承擔了非常重要的職責，可以極大的提升核心系統(tǒng)的性能和穩(wěn)定性。其典型的應(yīng)用場景有包括系統(tǒng)解耦，削峰限流，日志采集，最終一致保證，分發(fā)推送等等。常見的消息隊列包括RabbitMq，Kafka以及RocketMq等等。這些數(shù)據(jù)庫盡管從架構(gòu)和使用方式和性能上略有不同，但其基本使用場景都相對接近。然而，傳統(tǒng)的消息隊列并非完美，其在消息推送，feed流等場景存在以下問題：

• 存儲：不適合長期保存數(shù)據(jù)，通常過期時間都在天級
• 刪除能力：不支持刪除指定數(shù)據(jù)entry
• 查詢能力：不支持較為復雜的查詢和過濾條件
• 一致性和性能難以同時保證：類似于Kafka之類的數(shù)據(jù)庫更重吞吐，為了提高性能存在了某些狀況下丟數(shù)據(jù)的可能，而事務(wù)處理能力較好的消息隊列吞吐又較為受限。
• Partition快速拓展能力：通常一個Topc下的partition數(shù)目都是固定，不支持快速擴展。
• 物理隊列/邏輯隊列：通常只支持少量物理隊列(如每個partition可以看成一個隊列)，而業(yè)務(wù)需要的在物理隊列的基礎(chǔ)上模擬出邏輯隊列，如IM系統(tǒng)中為每個用戶維護一個邏輯上的消息隊列，用戶往往需要很多額外的開發(fā)工作。

針對上述需求，Lindorm推出了隊列模型FeedStreamService，能夠解決海量用戶下的消息同步，設(shè)備通知，自增ID分配等問題。

FeedStream模型在今年手機淘寶消息系統(tǒng)中扮演了重要角色，解決了手機淘寶消息推送保序，冪等等難題。在今年雙十一中，手淘的蓋樓和回血大紅包推送都有Lindorm的身影。手淘消息的推送中，峰值超過了100w/s，做到了分鐘級推送全網(wǎng)用戶。

注：該模型已經(jīng)在阿里云HBase增強版上內(nèi)測，感興趣的用戶可以聯(lián)系云HBase答疑釘釘號或者在阿里云上發(fā)起工單咨詢。

全文索引模型

雖然Lindorm中的TableService模型提供了數(shù)據(jù)類型和二級索引。但是，在面對各種復雜條件查詢和全文索引的需求下，還是顯得力不從心，而Solr和ES是優(yōu)秀的全文搜索引擎。使用Lindorm+Solr/ES，可以最大限度發(fā)揮Lindorm和Solr/ES各自的優(yōu)點，從而使得我們可以構(gòu)建復雜的大數(shù)據(jù)存儲和檢索服務(wù)。Lindorm內(nèi)置了外部索引同步組件，能夠自動地將寫入Lindorm的數(shù)據(jù)同步到外部索引組件如Solr或者ES中。這種模型非常適合需要保存大量數(shù)據(jù)，而查詢條件的字段數(shù)據(jù)僅占原數(shù)據(jù)的一小部分，并且需要各種條件組合查詢的業(yè)務(wù)，例如：

• 常見物流業(yè)務(wù)場景，需要存儲大量軌跡物流信息，并需根據(jù)多個字段任意組合查詢條件
• 交通監(jiān)控業(yè)務(wù)場景，保存大量過車記錄，同時會根據(jù)車輛信息任意條件組合檢索出感興趣的記錄
• 各種網(wǎng)站會員、商品信息檢索場景，一般保存大量的商品/會員信息，并需要根據(jù)少量條件進行復雜且任意的查詢，以滿足網(wǎng)站用戶任意搜索需求等。

全文索引模型已經(jīng)在阿里云上線，支持Solr/ES外部索引。目前，索引的查詢用戶還需要直接查詢Solr/ES再來反查Lindorm，后續(xù)我們會用TableService的語法把查詢外部索引的過程包裝起來，用戶全程只需要和Lindorm交互，即可獲得全文索引的能力。

更多模型在路上

除了上述這些模型，我們還會根據(jù)業(yè)務(wù)的需求和痛點，開發(fā)更多簡單易用的模型，方便用戶使用，降低使用門檻。像時序模型，圖模型等，都已經(jīng)在路上，敬請期待。

零干預、秒恢復的高可用能力

從一個嬰兒成長為青年，阿里HBase摔過很多次，甚至頭破血流，我們在客戶的信任之下幸運的成長。在9年的阿里應(yīng)用過程中，我們積累了大量的高可用技術(shù)，而這些技術(shù)，都應(yīng)用到了HBase增強版中。

MTTR優(yōu)化

HBase是參照Gooogle著名論文BigTable的開源實現(xiàn)，其中最核心特點是數(shù)據(jù)持久化存儲于底層的分布式文件系統(tǒng)HDFS，通過HDFS對數(shù)據(jù)的多副本維護來保障整個系統(tǒng)的高可靠性，而HBase自身不需要去關(guān)心數(shù)據(jù)的多副本及其一致性，這有助于整體工程的簡化，但也引入了"服務(wù)單點"的缺陷，即對于確定的數(shù)據(jù)的讀寫服務(wù)只有發(fā)生固定的某個節(jié)點服務(wù)器，這意味著當一個節(jié)點宕機后，數(shù)據(jù)需要通過重放Log恢復內(nèi)存狀態(tài)，并且重新派發(fā)給新的節(jié)點加載后，才能恢復服務(wù)。

當集群規(guī)模較大時，HBase單點故障后恢復時間可能會達到10-20分鐘，大規(guī)模集群宕機的恢復時間可能需要好幾個小時！而在Lindorm內(nèi)核中，我們對MTTR（平均故障恢復時間）做了一系列的優(yōu)化，包括故障恢復時先上線region、并行replay、減少小文件產(chǎn)生等眾多技術(shù)。將故障恢復速度提升10倍以上！基本上接近了HBase設(shè)計的理論值。

可調(diào)的多一致性

在原來的HBase架構(gòu)中，每個region只能在一個RegionServer中上線，如果這個region server宕機，region需要經(jīng)歷Re-assgin，WAL按region切分，WAL數(shù)據(jù)回放等步驟后，才能恢復讀寫。這個恢復時間可能需要數(shù)分鐘，對于某些高要求的業(yè)務(wù)來說，這是一個無法解決的痛點。另外，雖然HBase中有主備同步，但故障下只能集群粒度的手動切換，并且主和備的數(shù)據(jù)只能做到最終一致性，而有一些業(yè)務(wù)只能接受強一致，HBase在這點上望塵莫及。

Lindorm內(nèi)部實現(xiàn)了一種基于Shared Log的一致性協(xié)議，通過分區(qū)多副本機制達到故障下的服務(wù)自動快速恢復的能力，完美適配了存儲分離的架構(gòu), 利用同一套體系即可支持強一致語義，又可以選擇在犧牲一致性的前提換取更佳的性能和可用性，實現(xiàn)多活，高可用等多種能力。

在這套架構(gòu)下，Lindorm擁有了以下幾個一致性級別，用戶可以根據(jù)自己的業(yè)務(wù)自由選擇一致性級別：

注：該功能暫時未在阿里云HBase增強版上對外開放

客戶端高可用切換

雖然說目前HBase可以組成主備，但是目前市面上沒有一個高效地客戶端切換訪問方案。HBase的客戶端只能訪問固定地址的HBase集群。如果主集群發(fā)生故障，用戶需要停止HBase客戶端，修改HBase的配置后重啟，才能連接備集群訪問。或者用戶在業(yè)務(wù)側(cè)必須設(shè)計一套復雜地訪問邏輯來實現(xiàn)主備集群的訪問。阿里HBase改造了HBase客戶端，流量的切換發(fā)生在客戶端內(nèi)部，通過高可用的通道將切換命令發(fā)送給客戶端，客戶端會關(guān)閉舊的鏈接，打開與備集群的鏈接，然后重試請求。

?

云原生，更低使用成本

Lindorm從立項之初就考慮到上云，各種設(shè)計也能盡量復用云上基礎(chǔ)設(shè)施，為云的環(huán)境專門優(yōu)化。比如在云上，我們除了支持云盤之外，我們還支持將數(shù)據(jù)存儲在OSS這種低成本的對象存儲中減少成本。我們還針對ECS部署做了不少優(yōu)化，適配小內(nèi)存規(guī)格機型，加強部署彈性，一切為了云原生，為了節(jié)省客戶成本。

ECS+云盤的極致彈性

目前Lindorm在云上的版本HBase增強版均采用ECS+云盤部署（部分大客戶可能采用本地盤），ECS+云盤部署的形態(tài)給Lindorm帶來了極致的彈性。

最開始的時候，HBase在集團的部署均采用物理機的形式。每個業(yè)務(wù)上線前，都必須先規(guī)劃好機器數(shù)量和磁盤大小。在物理機部署下，往往會遇到幾個難以解決的問題：

• 業(yè)務(wù)彈性難以滿足：當遇到業(yè)務(wù)突發(fā)流量高峰或者異常請求時，很難在短時間內(nèi)找到新的物理機擴容。
• 存儲和計算綁定，靈活性差：物理機上CPU和磁盤的比例都是一定的，但是每個業(yè)務(wù)的特點都不一樣，采用一樣的物理機，有一些業(yè)務(wù)計算資源不夠，但存儲過剩，而有些業(yè)務(wù)計算資源過剩，而存儲瓶頸。特別是在HBase引入混合存儲后，HDD和SSD的比例非常難確定，有些高要求的業(yè)務(wù)常常會把SSD用滿而HDD有剩余，而一些海量的離線型業(yè)務(wù)SSD盤又無法利用上。
• 運維壓力大：使用物理機時，運維需要時刻注意物理機是否過保，是否有磁盤壞，網(wǎng)卡壞等硬件故障需要處理，物理機的報修是一個漫長的過程，同時需要停機，運維壓力巨大。對于HBase這種海量存儲業(yè)務(wù)來說，每天壞幾塊磁盤是非常正常的事情。而當Lindorm采用了ECS+云盤部署后，這些問題都迎刃而解。

ECS提供了一個近似無限的資源池。當面對業(yè)務(wù)的緊急擴容時，我們只需在資源池中申請新的ECS拉起后，即可加入集群，時間在分鐘級別之內(nèi)，無懼業(yè)務(wù)流量高峰。配合云盤這樣的存儲計算分離架構(gòu)。我們可以靈活地為各種業(yè)務(wù)分配不同的磁盤空間。當空間不夠時，可以直接在線擴縮容磁盤。同時，運維再也不用考慮硬件故障，當ECS有故障時，ECS可以在另外一臺宿主機上拉起，而云盤完全對上層屏蔽了壞盤的處理。極致的彈性同樣帶來了成本的優(yōu)化。我們不需要為業(yè)務(wù)預留太多的資源，同時當業(yè)務(wù)的大促結(jié)束后，能夠快速地縮容降低成本。

一體化冷熱分離

在海量大數(shù)據(jù)場景下，一張表中的部分業(yè)務(wù)數(shù)據(jù)隨著時間的推移僅作為歸檔數(shù)據(jù)或者訪問頻率很低，同時這部分歷史數(shù)據(jù)體量非常大，比如訂單數(shù)據(jù)或者監(jiān)控數(shù)據(jù)，降低這部分數(shù)據(jù)的存儲成本將會極大的節(jié)省企業(yè)的成本。如何以極簡的運維配置成本就能為企業(yè)極大降低存儲成本，Lindorm冷熱分離功能應(yīng)運而生。Lindorm為冷數(shù)據(jù)提供新的存儲介質(zhì)，新的存儲介質(zhì)存儲成本僅為高效云盤的1/3。

Lindorm在同一張表里實現(xiàn)了數(shù)據(jù)的冷熱分離，系統(tǒng)會自動根據(jù)用戶設(shè)置的冷熱分界線自動將表中的冷數(shù)據(jù)歸檔到冷存儲中。在用戶的訪問方式上和普通表幾乎沒有任何差異，在查詢的過程中，用戶只需配置查詢Hint或者TimeRange，系統(tǒng)根據(jù)條件自動地判斷查詢應(yīng)該落在熱數(shù)據(jù)區(qū)還是冷數(shù)據(jù)區(qū)。對用戶而言始終是一張表，對用戶幾乎做到完全的透明。

ZSTD-V2，壓縮比再提升100%

早在兩年前，我們就把集團內(nèi)的存儲壓縮算法替換成了ZSTD，相比原來的SNAPPY算法，獲得了額外25%的壓縮收益。今年我們對此進一步優(yōu)化，開發(fā)實現(xiàn)了新的ZSTD-v2算法，其對于小塊數(shù)據(jù)的壓縮，提出了使用預先采樣數(shù)據(jù)進行訓練字典，然后用字典進行加速的方法。我們利用了這一新的功能，在Lindorm構(gòu)建LDFile的時候，先對數(shù)據(jù)進行采樣訓練，構(gòu)建字典，然后在進行壓縮。在不同業(yè)務(wù)的數(shù)據(jù)測試中，我們最高獲得了超過原生ZSTD算法100%的壓縮比，這意味著我們可以為客戶再節(jié)省50%的存儲費用。

HBase Serverless版，入門首選

阿里云HBase Serverless 版是基于Lindorm內(nèi)核，使用Serverless架構(gòu)構(gòu)建的一套新型的HBase 服務(wù)。阿里云HBase Serverless版真正把HBase變成了一個服務(wù)，用戶無需提前規(guī)劃資源，選擇CPU，內(nèi)存資源數(shù)量，購買集群。在應(yīng)對業(yè)務(wù)高峰，業(yè)務(wù)空間增長時，也無需進行擴容等復雜運維操作，在業(yè)務(wù)低谷時，也無需浪費閑置資源。

在使用過程中，用戶可以完全根據(jù)當前業(yè)務(wù)量，按需購買請求量和空間資源即可。使用阿里云HBase Serverless版本，用戶就好像在使用一個無限資源的HBase集群，隨時滿足業(yè)務(wù)流量突然的變化，而同時只需要支付自己真正使用的那一部分資源的錢。

面向大客戶的安全和多租戶能力

Lindorm引擎內(nèi)置了完整的用戶名密碼體系，提供多種級別的權(quán)限控制，并對每一次請求鑒權(quán)，防止未授權(quán)的數(shù)據(jù)訪問，確保用戶數(shù)據(jù)的訪問安全。同時，針對企業(yè)級大客戶的訴求，Lindorm內(nèi)置了Group，Quota限制等多租戶隔離功能，保證企業(yè)中各個業(yè)務(wù)在使用同一個HBase集群時不會被相互影響，安全高效地共享同一個大數(shù)據(jù)平臺。

用戶和ACL體系

Lindorm內(nèi)核提供一套簡單易用的用戶認證和ACL體系。用戶的認證只需要在配置中簡單的填寫用戶名密碼即可。用戶的密碼在服務(wù)器端非明文存儲，并且在認證過程中不會明文傳輸密碼，即使驗證過程的密文被攔截，用以認證的通信內(nèi)容不可重復使用，無法被偽造。

Lindorm中有三個權(quán)限層級。Global，Namespace和Table。這三者是相互覆蓋的關(guān)系。比如給user1賦予了Global的讀寫權(quán)限，則他就擁有了所有namespace下所有Table的讀寫權(quán)限。如果給user2賦予了Namespace1的讀寫權(quán)限，那么他會自動擁有Namespace1中所有表的讀寫權(quán)限。

Group隔離

當多個用戶或者業(yè)務(wù)在使用同一個HBase集群時，往往會存在資源爭搶的問題。一些重要的在線業(yè)務(wù)的讀寫，可能會被離線業(yè)務(wù)批量讀寫所影響。而Group功能，則是HBase增強版（Lindorm）提供的用來解決多租戶隔離問題的功能。 通過把RegionServer劃分到不同的Group分組，每個分組上host不同的表，從而達到資源隔離的目的。

例如，在上圖中，我們創(chuàng)建了一個Group1，把RegionServer1和RegionServer2劃分到Group1中，創(chuàng)建了一個Group2，把RegionServer3和RegionServer4劃分到Group2。同時，我們把Table1和Table2也移動到Group1分組。這樣的話，Table1和Table2的所有region，都只會分配到Group1中的RegionServer1和RegionServer2這兩臺機器上。

同樣，屬于Group2的Table3和Table4的Region在分配和balance過程中，也只會落在RegionServer3和RegionServer4上。因此，用戶在請求這些表時，發(fā)往Table1、Table2的請求，只會由RegionServer1和RegionServer2服務(wù)，而發(fā)往Table3和Table4的請求，只會由RegionServer3和RegionServer4服務(wù)，從而達到資源隔離的目的。

Quota限流

Lindorm內(nèi)核中內(nèi)置了一套完整的Quota體系，來對各個用戶的資源使用做限制。對于每一個請求，Lindorm內(nèi)核都有精確的計算所消耗的CU（Capacity Unit），CU會以實際消耗的資源來計算。比如用戶一個Scan請求，由于filter的存在，雖然返回的數(shù)據(jù)很少，但可能已經(jīng)在RegionServer已經(jīng)消耗大量的CPU和IO資源來過濾數(shù)據(jù)，這些真實資源的消耗，都會計算在CU里。在把Lindorm當做一個大數(shù)據(jù)平臺使用時，企業(yè)管理員可以先給不同業(yè)務(wù)分配不同的用戶，然后通過Quota系統(tǒng)限制某個用戶每秒的讀CU不能超過多少，或者總的CU不能超過多少，從而限制用戶占用過多的資源，影響其他用戶。同時，Quota限流也支持Namesapce級別和表級別限制。

最后

全新一代NoSQL數(shù)據(jù)庫Lindorm是阿里巴巴HBase&Lindorm團隊9年以來技術(shù)積累的結(jié)晶，Lindorm在面向海量數(shù)據(jù)場景提供世界領(lǐng)先的高性能、可跨域、多一致、多模型的混合存儲處理能力。對焦于同時解決大數(shù)據(jù)(無限擴展、高吞吐)、在線服務(wù)(低延時、高可用)、多功能查詢的訴求，為用戶提供無縫擴展、高吞吐、持續(xù)可用、毫秒級穩(wěn)定響應(yīng)、強弱一致可調(diào)、低存儲成本、豐富索引的數(shù)據(jù)實時混合存取能力。Lindorm已經(jīng)成為了阿里巴巴大數(shù)據(jù)體系中的核心產(chǎn)品之一，成功支持了集團各個BU上千個業(yè)務(wù)，也多次在天貓雙十一“技術(shù)大團建”中經(jīng)受住了考驗。阿里CTO行癲說過，阿里的技術(shù)都應(yīng)該通過阿里云輸出，去普惠各行各業(yè)數(shù)百萬客戶。

雙12來襲！500元淘寶紅包、iPhone11等你拿。
https://www.aliyun.com/1212/2019/home?utm_content=g_1000092611

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

?

?

總結(jié)

以上是生活随笔為你收集整理的每秒7亿次请求，阿里新一代数据库如何支撑？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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