作者 | 正研
2019年以來，Lindorm已經服務了包括淘寶、天貓、螞蟻、菜鳥、媽媽、優酷、高德、大文娛等數十個BU，在今年的雙十一中，Lindorm峰值請求達到了7.5億次每秒，天吞吐22.9萬億次，平均響應時間低于3ms，整體存儲的資料量達到了數百PB。
這些數字的背後，凝聚了HBase&Lindorm團隊多年以來的汗水和心血。Lindorm脫胎于HBase，是團隊多年以來承載數百PB資料，億級請求量，上千個業務後，在面對規模成本壓力，以及HBase自身缺陷下，全面重構和引擎更新的全新産品。相比HBase，Lindorm無論是性能，功能還是可用性上，都有了巨大飛躍。本文将從功能、可用性、性能成本、服務生态等次元介紹Lindorm的核心能力與業務表現，最後分享部分我們正在進行中的一些項目。
極緻優化，超強性能
Lindorm比HBase在RPC、記憶體管理，緩存、日志寫入等方面做了深度的優化，引入了衆多新技術，大幅提升了讀寫性能，在相同硬體的情況下，吞吐可達到HBase的5倍以上，毛刺更是可以達到HBase的1/10。這些性能資料，并不是在實驗室條件下産生的，而是在不改動任何參數的前提下，使用開源測試工具YCSB跑出來的成績。我們把測試的工具和場景都公布在阿裡雲的幫助檔案中，任何人都可以依照指南自己跑出一樣的結果。
取得這麼優異的性能的背後，是Lindorm中積攢多年的“黑科技”，下面，我們簡單介紹下Lindorm核心中使用到的部分“黑科技”。
Trie Index
Lindorm 的檔案LDFile（類似HBase中的HFile）是隻讀 B+ 樹結構，其中檔案索引是至關重要的資料結構。在 block cache 中有高優先級，需要盡量常駐記憶體。如果能降低檔案索引所占空間大小，我們可以節省 block cache 中索引所需要的寶貴記憶體空間。或者在索引空間不變的情況下，增加索引密度，降低 data block 的大小，進而提高性能。而HBase中的索引block中存的是全量的Rowkey，而在一個已經排序好的檔案中，很多Rowkey都是有共同字首的。
資料結構中的Trie (字首樹) 結構能夠讓共同字首隻存一份，避免重複存儲帶來的浪費。但是傳統字首樹結構中，從一個節點到下一個節點的指針占用空間太多，整體而言得不償失。這一情況有望用 Succinct Prefix Tree 來解決。SIGMOD2018年的最佳論文 Surf 中提出了一種用 Succinct Prefix Tree 來取代 bloom filter，并同時提供 range filtering 的功能。我們從這篇文章得到啟發，用 Succinct Trie 來做 file block index。
我們線上上的多個業務中使用了Trie index實作的索引結構。結果發現，各個場景中，Trie index可以大大縮小索引的體積，最多可以壓縮12倍的索引空間！節省的這些寶貴空間讓記憶體Cache中能夠存放更多的索引和資料檔案，大大提高了請求的性能。
ZGC加持，百GB堆平均5ms暫停
ZGC(Powerd by Dragonwell JDK)是下一代Pauseless GC算法的代表之一，其核心思想是Mutator利用記憶體讀屏障(Read Barrier)識别指針變化，使得大部分的标記(Mark)與合并(Relocate)工作可以放在并發階段執行。
這樣一項實驗性技術，在Lindorm團隊與AJDK團隊的緊密合作下，進行了大量的改進與改造工作。使得ZGC在Lindorm這個場景上實作了生産級可用，主要工作包括：
Lindorm記憶體自管理技術，數量級減少對象數與記憶體配置設定速率。(比如說阿裡HBase團隊貢獻給社群的CCSMap)。
AJDK ZGC Page緩存機制優化(鎖、Page緩存政策)。
AJDK ZGC 觸發時機優化，ZGC無并發失敗。AJDK ZGC在Lindorm上穩定運作兩個月，并順利通過雙十一大考。其JVM暫停時間穩定在5ms左右，最大暫停時間不超過8ms。ZGC大大改善了線上運作叢集的RT與毛刺名額，平均RT優化15%～20%，P999 RT減少一倍。在今年雙十一螞蟻風控叢集中，在ZGC的加持下，P999時間從12ms降低到了5ms。
注：圖中的機關應該為us，平均GC在5ms
LindormBlockingQueue
上圖是HBase中的RegionServer從網絡上讀取RPC請求并分發到各個Handler上執行的流程。HBase中的RPC Reader從Socket上讀取RPC請求放入BlockingQueue，Handler訂閱這個Queue并執行請求。而這個BlockingQueue，HBase使用的是Java原生的JDK自帶的LinkedBlockingQueue。
LinkedBlockingQueue利用Lock與Condition保證線程安全與線程之間的同步，雖然經典易懂，但當吞吐增大時，這個queue會造成嚴重的性能瓶頸。是以在Lindorm中全新設計了LindormBlockingQueue，将元素維護在Slot數組中。維護head與tail指針，通過CAS操作對進隊列進行讀寫操作，消除了臨界區。并使用Cache Line Padding與髒讀緩存加速，同時可定制多種等待政策(Spin/Yield/Block)，避免隊列為空或為滿時，頻繁進入Park狀态。LindormBlockingQueue的性能非常突出，相比于原先的LinkedBlockingQueue性能提升4倍以上。
VersionBasedSynchronizer
LDLog是Lindorm中用于系統failover時進行資料恢複時的日志，以保障資料的原子性和可靠性。在每次資料寫入時，都必須先寫入LDLog。LDLog寫入成功之後，才可以進行後續的寫入memstore等操作。是以Lindorm中的Handler都必須等待WAL寫入完成後再被喚醒以進行下一步操作，在高壓條件下，無用喚醒會造成大量的CPU Context Switch造成性能下降。針對這個問題，Lindorm研發了基于版本的高并發多路線程同步機制(VersionBasedSynchronizer)來大幅優化上下文切換。
VersionBasedSynchronizer的主要思路是讓Handler的等待條件被Notifier感覺，減少Notifier的喚醒壓力。經過子產品測試VersionBasedSynchronizer的效率是JDK自帶的ObjectMonitor和J.U.C(java util concurrent包)的兩倍以上。
全面無鎖化
HBase核心在關鍵路徑上有大量的鎖，在高并發場景下，這些鎖都會造成線程争搶和性能下降。Lindorm核心對關鍵鍊路上的鎖都做了無鎖化處理，如MVCC，WAL子產品中的鎖。另外，HBase在運作過程中會産生的各種名額，如qps，rt，cache命中率等等。而在記錄這些Metrics的“不起眼”操作中，也會有大量的鎖。面對這樣的問題，Lindorm借鑒了tcmalloc的思想，開發了LindormThreadCacheCounter，來解決Metrics的性能問題。
Handler協程化
在高并發應用中，一個RPC請求的實作往往包含多個子子產品，涉及到若幹次IO。這些子子產品的互相協作，系統的ContextSwitch相當頻繁。ContextSwitch的優化是高并發系統繞不開的話題，各位高手都各顯神通，業界有非常多的思想與實踐。其中coroutine(協程)和SEDA(分階段事件驅動)方案是我們着重考察的方案。基于工程代價，可維護性，代碼可讀性三個角度考慮，Lindorm選擇了協程的方式進行異步化優化。我們利用了阿裡JVM團隊提供的Dragonwell JDK内置的Wisp2.0功能實作了HBase Handler的協程化，Wisp2.0開箱即用，有效地減少了系統的資源消耗，優化效果比較客觀。
全新Encoding算法
從性能角度考慮，HBase通常需要将Meta資訊裝載進block cache。如果将block大小較小，Meta資訊較多，會出現Meta無法完全裝入Cache的情況, 性能下降。如果block大小較大，經過Encoding的block的順序查詢的性能會成為随機讀的性能瓶頸。針對這一情況，Lindorm全新開發了Indexable Delta Encoding，在block内部也可以通過索引進行快速查詢，seek性能有了較大提高。Indexable Delta Encoding原理如圖所示：
通過Indexable Delta Encoding， HFile的随機seek性能相對于使用之前翻了一倍，以64K block為例，随機seek性能基本與不做encoding相近（其他encoding算法會有一定性能損失）。在全cache命中的随機Get場景下，相對于Diff encoding RT下降50%
其他
相比社群版HBase，Lindorm還有多達幾十項的性能優化和重構，引入了衆多新技術，由于篇幅有限，這裡隻能列舉一部分，其他的核心技術，比如：
CCSMap
自動規避故障節點的并發三副本日志協定 (Quorum-based write)
高效的批量組送出(Group Commit)
無碎片的高性能緩存—Shared BucketCache
Memstore Bloomfilter
面向讀寫的高效資料結構
GC-Invisible記憶體管理
線上計算與離線作業架構分離
JDK/作業系統深度優化
FPGA offloading Compaction
使用者态TCP加速
……
豐富的查詢模型，降低開發門檻
原生的HBase隻支援KV結構的查詢，雖然簡單，但是在面對各項業務的複雜需求時，顯的有點力不從心。是以，在Lindorm中，我們針對不同業務的特點，研發了多種查詢模型，通過更靠近場景的API和索引設計，降低開發門檻。
WideColumn 模型（原生HBase API）
WideColumn是一種與HBase完全一緻的通路模型和資料結構，進而使得Lindrom能100%相容HBase的API。使用者可以通過Lindorm提供的高性能原生用戶端中的WideColumn API通路Lindorm，也可以通過alihbase-connector這個插件，使用HBase用戶端及API(無需任何代碼改造)直接通路Lindorm。同時，Lindorm使用了輕用戶端的設計，将大量資料路由、批量分發、逾時、重試等邏輯下沉到服務端，并在網絡傳輸層做了大量的優化，使得應用端的CPU消耗可以大大節省。像下表中，相比于HBase，使用Lindorm後的應用側CPU使用效率提升60%，網絡帶寬效率提升25%。
注：表中的用戶端CPU代表HBase/Lindorm用戶端消耗的CPU資源，越小越好。
在HBase原生API上，我們還獨家支援了高性能二級索引，使用者可以使用HBase原生API寫入資料過程中，索引資料透明地寫入索引表。在查詢過程中，把可能全表掃的Scan + Filter大查詢，變成可以先去查詢索引表，大大提高了查詢性能。關于高性能原生二級索引，大家可以參考：
https://help.aliyun.com/document_detail/144577.htmlTableService模型(SQL、二級索引)
HBase中隻支援Rowkey這一種索引方式，對于多字段查詢時，通常效率低下。為此，使用者需要維護多個表來滿足不同場景的查詢需求，這在一定程度上既增加了應用的開發複雜性，也不能很完美地保證資料一緻性和寫入效率。并且HBase中隻提供了KV API，隻能做Put、Get、Scan等簡單API操作，也沒有資料類型，所有的資料都必須使用者自己轉換和儲存。對于習慣了SQL語言的開發者來說，入門的門檻非常高，而且容易出錯。
為了解決這一痛點，降低使用者使用門檻，提高開發效率，在Lindorm中我們增加了TableService模型，其提供豐富的資料類型、結構化查詢表達API，并原生支援SQL通路和全局二級索引，解決了衆多的技術挑戰，大幅降低普通使用者的開發門檻。通過SQL和SQL like的API，使用者可以友善地像使用關系資料庫那樣使用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); -- 多列索引，備援所有列
-- 寫入資料，會同步更新2個索引
upsert into shop_item_relation values('shop1', 'item1', 'active');
upsert into shop_item_relation values('shop1', 'item2', 'invalid');
-- 根據WHERE子句自動選擇合适的索引執行查詢
select * from shop_item_relation where item_id = 'item2'; -- 命中idx1
select * from shop_item_relation where shop_id = 'shop1' and status = 'invalid'; -- 命中idx2
相比于關系資料庫的SQL，Lindorm不具備多行事務和複雜分析(如Join、Groupby)的能力，這也是兩者之間的定位差異。
相比于HBase上Phoenix元件提供的二級索引，Lindorm的二級索引在功能、性能、穩定性上遠遠超過Phoenix，下圖是一個簡單的性能對比。
注：該模型已經在阿裡雲HBase增強版上内測，感興趣的使用者可以聯系雲HBase答疑釘釘号或者在阿裡雲上發起工單咨詢。
FeedStream模型
現代網際網路架構中，消息隊列承擔了非常重要的職責，可以極大的提升核心系統的性能和穩定性。其典型的應用場景有包括系統解耦，削峰限流，日志采集，最終一緻保證，分發推送等等。
常見的消息隊列包括RabbitMq，Kafka以及RocketMq等等。這些資料庫盡管從架構和使用方式和性能上略有不同，但其基本使用場景都相對接近。然而，傳統的消息隊列并非完美，其在消息推送，feed流等場景存在以下問題：
存儲：不适合長期儲存資料，通常過期時間都在天級
删除能力：不支援删除指定資料entry
查詢能力：不支援較為複雜的查詢和過濾條件
一緻性和性能難以同時保證：類似于Kafka之類的資料庫更重吞吐，為了提高性能存在了某些狀況下丢資料的可能，而事務處理能力較好的消息隊列吞吐又較為受限。
Partition快速拓展能力：通常一個Topc下的partition數目都是固定，不支援快速擴充。
實體隊列/邏輯隊列：通常隻支援少量實體隊列(如每個partition可以看成一個隊列)，而業務需要的在實體隊列的基礎上模拟出邏輯隊列，如IM系統中為每個使用者維護一個邏輯上的消息隊列，使用者往往需要很多額外的開發工作。
針對上述需求，Lindorm推出了隊列模型FeedStreamService，能夠解決海量使用者下的消息同步，裝置通知，自增ID配置設定等問題。
FeedStream模型在今年手機淘寶消息系統中扮演了重要角色，解決了手機淘寶消息推送保序，幂等等難題。在今年雙十一中，手淘的蓋樓和回血大紅包推送都有Lindorm的身影。手淘消息的推送中，峰值超過了100w/s，做到了分鐘級推送全網使用者。
全文索引模型
雖然Lindorm中的TableService模型提供了資料類型和二級索引。但是，在面對各種複雜條件查詢和全文索引的需求下，還是顯得力不從心，而Solr和ES是優秀的全文搜尋引擎。使用Lindorm+Solr/ES，可以最大限度發揮Lindorm和Solr/ES各自的優點，進而使得我們可以建構複雜的大資料存儲和檢索服務。Lindorm内置了外部索引同步元件，能夠自動地将寫入Lindorm的資料同步到外部索引元件如Solr或者ES中。這種模型非常适合需要儲存大量資料，而查詢條件的字段資料僅占原資料的一小部分，并且需要各種條件組合查詢的業務，例如：
常見物流業務場景，需要存儲大量軌迹物流資訊，并需根據多個字段任意組合查詢條件
交通監控業務場景，儲存大量過車記錄，同時會根據車輛資訊任意條件組合檢索出感興趣的記錄
各種網站會員、商品資訊檢索場景，一般儲存大量的商品/會員資訊，并需要根據少量條件進行複雜且任意的查詢，以滿足網站使用者任意搜尋需求等。
全文索引模型已經在阿裡雲上線，支援Solr/ES外部索引。目前，索引的查詢使用者還需要直接查詢Solr/ES再來反查Lindorm，後續我們會用TableService的文法把查詢外部索引的過程包裝起來，使用者全程隻需要和Lindorm互動，即可獲得全文索引的能力。
更多模型在路上
除了上述這些模型，我們還會根據業務的需求和痛點，開發更多簡單易用的模型，友善使用者使用，降低使用門檻。像時序模型，圖模型等，都已經在路上，敬請期待。
零幹預、秒恢複的高可用能力
從一個嬰兒成長為青年，阿裡HBase摔過很多次，甚至頭破血流，我們在客戶的信任之下幸運的成長。在9年的阿裡應用過程中，我們積累了大量的高可用技術，而這些技術，都應用到了HBase增強版中。
MTTR優化
HBase是參照Gooogle著名論文BigTable的開源實作，其中最核心特點是資料持久化存儲于底層的分布式檔案系統HDFS，通過HDFS對資料的多副本維護來保障整個系統的高可靠性，而HBase自身不需要去關心資料的多副本及其一緻性，這有助于整體工程的簡化，但也引入了"服務單點"的缺陷，即對于确定的資料的讀寫服務隻有發生固定的某個節點伺服器，這意味着當一個節點當機後，資料需要通過重放Log恢複記憶體狀态，并且重新派發給新的節點加載後，才能恢複服務。
當叢集規模較大時，HBase單點故障後恢複時間可能會達到10-20分鐘，大規模叢集當機的恢複時間可能需要好幾個小時！而在Lindorm核心中，我們對MTTR（平均故障恢複時間）做了一系列的優化，包括故障恢複時先上線region、并行replay、減少小檔案産生等衆多技術。将故障恢複速度提升10倍以上！基本上接近了HBase設計的理論值。
可調的多一緻性
在原來的HBase架構中，每個region隻能在一個RegionServer中上線，如果這個region server當機，region需要經曆Re-assgin，WAL按region切分，WAL資料回放等步驟後，才能恢複讀寫。這個恢複時間可能需要數分鐘，對于某些高要求的業務來說，這是一個無法解決的痛點。另外，雖然HBase中有主備同步，但故障下隻能叢集粒度的手動切換，并且主和備的資料隻能做到最終一緻性，而有一些業務隻能接受強一緻，HBase在這點上望塵莫及。
Lindorm内部實作了一種基于Shared Log的一緻性協定，通過分區多副本機制達到故障下的服務自動快速恢複的能力，完美适配了存儲分離的架構, 利用同一套體系即可支援強一緻語義，又可以選擇在犧牲一緻性的前提換取更佳的性能和可用性，實作多活，高可用等多種能力。
在這套架構下，Lindorm擁有了以下幾個一緻性級别，使用者可以根據自己的業務自由選擇一緻性級别：
注：該功能暫時未在阿裡雲HBase增強版上對外開放
用戶端高可用切換
雖然說目前HBase可以組成主備，但是目前市面上沒有一個高效地用戶端切換通路方案。HBase的用戶端隻能通路固定位址的HBase叢集。如果主叢集發生故障，使用者需要停止HBase用戶端，修改HBase的配置後重新開機，才能連接配接備叢集通路。或者使用者在業務側必須設計一套複雜地通路邏輯來實作主備叢集的通路。阿裡HBase改造了HBase用戶端，流量的切換發生在用戶端内部，通過高可用的通道将切換指令發送給用戶端，用戶端會關閉舊的連結，打開與備叢集的連結，然後重試請求。
如果需要使用此項功能，請參考高可用幫助文檔：
https://help.aliyun.com/document_detail/140940.html雲原生，更低使用成本
Lindorm從立項之初就考慮到上雲，各種設計也能盡量複用雲上基礎設施，為雲的環境專門優化。比如在雲上，我們除了支援雲盤之外，我們還支援将資料存儲在OSS這種低成本的對象存儲中減少成本。我們還針對ECS部署做了不少優化，适配小記憶體規格機型，加強部署彈性，一切為了雲原生，為了節省客戶成本。
ECS+雲盤的極緻彈性
目前Lindorm在雲上的版本HBase增強版均采用ECS+雲盤部署（部分大客戶可能采用本地盤），ECS+雲盤部署的形态給Lindorm帶來了極緻的彈性。
最開始的時候，HBase在集團的部署均采用實體機的形式。每個業務上線前，都必須先規劃好機器數量和磁盤大小。在實體機部署下，往往會遇到幾個難以解決的問題：
業務彈性難以滿足：當遇到業務突發流量高峰或者異常請求時，很難在短時間内找到新的實體機擴容。
存儲和計算綁定，靈活性差：實體機上CPU和磁盤的比例都是一定的，但是每個業務的特點都不一樣，采用一樣的實體機，有一些業務計算資源不夠，但存儲過剩，而有些業務計算資源過剩，而存儲瓶頸。特别是在HBase引入混合存儲後，HDD和SSD的比例非常難确定，有些高要求的業務常常會把SSD用滿而HDD有剩餘，而一些海量的離線型業務SSD盤又無法利用上。
運維壓力大：使用實體機時，運維需要時刻注意實體機是否過保，是否有磁盤壞，網卡壞等硬體故障需要處理，實體機的報修是一個漫長的過程，同時需要停機，運維壓力巨大。對于HBase這種海量存儲業務來說，每天壞幾塊磁盤是非常正常的事情。而當Lindorm采用了ECS+雲盤部署後，這些問題都迎刃而解。
ECS提供了一個近似無限的資源池。當面對業務的緊急擴容時，我們隻需在資源池中申請新的ECS拉起後，即可加入叢集，時間在分鐘級别之内，無懼業務流量高峰。配合雲盤這樣的存儲計算分離架構。我們可以靈活地為各種業務配置設定不同的磁盤空間。當空間不夠時，可以直接線上擴縮容磁盤。同時，運維再也不用考慮硬體故障，當ECS有故障時，ECS可以在另外一台主控端上拉起，而雲盤完全對上層屏蔽了壞盤的處理。極緻的彈性同樣帶來了成本的優化。我們不需要為業務預留太多的資源，同時當業務的大促結束後，能夠快速地縮容降低成本。
一體化冷熱分離
在海量大資料場景下，一張表中的部分業務資料随着時間的推移僅作為歸檔資料或者通路頻率很低，同時這部分曆史資料體量非常大，比如訂單資料或者監控資料，降低這部分資料的存儲成本将會極大的節省企業的成本。如何以極簡的運維配置成本就能為企業極大降低存儲成本，Lindorm冷熱分離功能應運而生。Lindorm為冷資料提供新的存儲媒體，新的存儲媒體存儲成本僅為高效雲盤的1/3。
Lindorm在同一張表裡實作了資料的冷熱分離，系統會自動根據使用者設定的冷熱分界線自動将表中的冷資料歸檔到冷存儲中。在使用者的通路方式上和普通表幾乎沒有任何差異，在查詢的過程中，使用者隻需配置查詢Hint或者TimeRange，系統根據條件自動地判斷查詢應該落在熱資料區還是冷資料區。對使用者而言始終是一張表，對使用者幾乎做到完全的透明。詳細介紹請參考：
https://yq.aliyun.com/articles/718395 ZSTD-V2，壓縮比再提升100%
早在兩年前，我們就把集團内的存儲壓縮算法替換成了ZSTD，相比原來的SNAPPY算法，獲得了額外25%的壓縮收益。今年我們對此進一步優化，開發實作了新的ZSTD-v2算法，其對于小塊資料的壓縮，提出了使用預先采樣資料進行訓練字典，然後用字典進行加速的方法。我們利用了這一新的功能，在Lindorm建構LDFile的時候，先對資料進行采樣訓練，建構字典，然後在進行壓縮。在不同業務的資料測試中，我們最高獲得了超過原生ZSTD算法100%的壓縮比，這意味着我們可以為客戶再節省50%的存儲費用。
HBase Serverless版，入門首選
阿裡雲HBase Serverless 版是基于Lindorm核心，使用Serverless架構建構的一套新型的HBase 服務。阿裡雲HBase Serverless版真正把HBase變成了一個服務，使用者無需提前規劃資源，選擇CPU，記憶體資源數量，購買叢集。在應對業務高峰，業務空間增長時，也無需進行擴容等複雜運維操作，在業務低谷時，也無需浪費閑置資源。
在使用過程中，使用者可以完全根據目前業務量，按需購買請求量和空間資源即可。使用阿裡雲HBase Serverless版本，使用者就好像在使用一個無限資源的HBase叢集，随時滿足業務流量突然的變化，而同時隻需要支付自己真正使用的那一部分資源的錢。
關于HBase Serverless的介紹和使用，可以參考：
https://developer.aliyun.com/article/719206面向大客戶的安全和多租戶能力
Lindorm引擎内置了完整的使用者名密碼體系，提供多種級别的權限控制，并對每一次請求鑒權，防止未授權的資料通路，確定使用者資料的通路安全。同時，針對企業級大客戶的訴求，Lindorm内置了Group，Quota限制等多租戶隔離功能，保證企業中各個業務在使用同一個HBase叢集時不會被互相影響，安全高效地共享同一個大資料平台。
使用者和ACL體系
Lindorm核心提供一套簡單易用的使用者認證和ACL體系。使用者的認證隻需要在配置中簡單的填寫使用者名密碼即可。使用者的密碼在伺服器端非明文存儲，并且在認證過程中不會明文傳輸密碼，即使驗證過程的密文被攔截，用以認證的通信内容不可重複使用，無法被僞造。
Lindorm中有三個權限層級。Global，Namespace和Table。這三者是互相覆寫的關系。比如給user1賦予了Global的讀寫權限，則他就擁有了所有namespace下所有Table的讀寫權限。如果給user2賦予了Namespace1的讀寫權限，那麼他會自動擁有Namespace1中所有表的讀寫權限。
Group隔離
當多個使用者或者業務在使用同一個HBase叢集時，往往會存在資源争搶的問題。一些重要的線上業務的讀寫，可能會被離線業務批量讀寫所影響。而Group功能，則是HBase增強版（Lindorm）提供的用來解決多租戶隔離問題的功能。
通過把RegionServer劃分到不同的Group分組，每個分組上host不同的表，進而達到資源隔離的目的。
例如，在上圖中，我們建立了一個Group1，把RegionServer1和RegionServer2劃分到Group1中，建立了一個Group2，把RegionServer3和RegionServer4劃分到Group2。同時，我們把Table1和Table2也移動到Group1分組。這樣的話，Table1和Table2的所有region，都隻會配置設定到Group1中的RegionServer1和RegionServer2這兩台機器上。
同樣，屬于Group2的Table3和Table4的Region在配置設定和balance過程中，也隻會落在RegionServer3和RegionServer4上。是以，使用者在請求這些表時，發往Table1、Table2的請求，隻會由RegionServer1和RegionServer2服務，而發往Table3和Table4的請求，隻會由RegionServer3和RegionServer4服務，進而達到資源隔離的目的。
Quota限流
Lindorm核心中内置了一套完整的Quota體系，來對各個使用者的資源使用做限制。對于每一個請求，Lindorm核心都有精确的計算所消耗的CU（Capacity Unit），CU會以實際消耗的資源來計算。比如使用者一個Scan請求，由于filter的存在，雖然傳回的資料很少，但可能已經在RegionServer已經消耗大量的CPU和IO資源來過濾資料，這些真實資源的消耗，都會計算在CU裡。在把Lindorm當做一個大資料平台使用時，企業管理者可以先給不同業務配置設定不同的使用者，然後通過Quota系統限制某個使用者每秒的讀CU不能超過多少，或者總的CU不能超過多少，進而限制使用者占用過多的資源，影響其他使用者。同時，Quota限流也支援Namesapce級别和表級别限制。
最後
全新一代NoSQL資料庫Lindorm是阿裡巴巴HBase&Lindorm團隊9年以來技術積累的結晶，Lindorm在面向海量資料場景提供世界領先的高性能、可跨域、多一緻、多模型的混合存儲處理能力。對焦于同時解決大資料(無限擴充、高吞吐)、線上服務(低延時、高可用)、多功能查詢的訴求，為使用者提供無縫擴充、高吞吐、持續可用、毫秒級穩定響應、強弱一緻可調、低存儲成本、豐富索引的資料實時混合存取能力。
Lindorm已經成為了阿裡巴巴大資料體系中的核心産品之一，成功支援了集團各個BU上千個業務，也多次在天貓雙十一“技術大團建”中經受住了考驗。阿裡CTO行癫說過，阿裡的技術都應該通過阿裡雲輸出，去普惠各行各業數百萬客戶。是以Lindorm從今年開始，已經在阿裡雲上以“HBase增強版”的形式，以及在專有雲中對外輸出（詳情點選文末“閱讀原文”或長按下方二維碼了解）讓雲上的客戶能夠享受到阿裡巴巴的技術紅利，助力業務騰飛！