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還有多達幾十項的效能最佳化和重構，引入了眾多新技術，由於篇幅有限，這裡只能列舉一部分，其他的核心技術，比如：
- 自動規避故障節點的併發三副本日誌協議 (Quorum-based write)
- 無碎片的高效能快取—Shared BucketCache
- FPGA offloading Compaction
豐富的查詢模型，降低開發門檻
原生的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的簡單示例。-- 主表和索引DDLcreate table shop_item_relation ( shop_id varchar, item_id varchar, status varcharconstraint 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'; -- 命中idx1select * 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流等場景存在以下問題：- 一致性和效能難以同時保證：類似於Kafka之類的資料庫更重吞吐，為了提高效能存在了某些狀況下丟資料的可能，而事務處理能力較好的訊息佇列吞吐又較為受限。
- Partition快速擴充能力：通常一個Topc下的partition數目都是固定，不支援快速擴充套件。
- 物理佇列/邏輯佇列：通常只支援少量物理佇列(如每個partition可以看成一個佇列)，而業務需要的在物理佇列的基礎上模擬出邏輯佇列，如IM系統中為每個使用者維護一個邏輯上的訊息佇列，使用者往往需要很多額外的開發工作。
針對上述需求，Lindorm推出了佇列模型FeedStreamService，能夠解決海量使用者下的訊息同步，裝置通知，自增ID分配等問題。
FeedStream模型在今年手機淘寶訊息系統中扮演了重要角色，解決了手機淘寶訊息推送保序，冪等等難題。在今年雙十一中，手淘的蓋樓和回血大紅包推送都有Lindorm的身影。手淘訊息的推送中，峰值超過了100w/s，做到了分鐘級推送全網使用者。
注：該模型已經在阿里雲HBase增強版上內測，感興趣的使用者可以聯絡雲HBase答疑釘釘號或者在阿里雲上發起工單諮詢。
全文索引模型
雖然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增強版”的形式，以及在專有云中對外輸出（詳情點選文末“閱讀原文”或長按下方二維碼瞭解）讓雲上的客戶能夠享受到阿里巴巴的技術紅利，助力業務騰飛！