每秒7億次請求，阿里新一代數據庫如何支撐？

時間 2019-12-21

原文原文鏈接

阿里妹導讀：Lindorm，就是雲操做系統飛天中面向大數據存儲處理的重要組成部分。Lindorm是基於HBase研發的、面向大數據領域的分佈式NoSQL數據庫，集大規模、高吞吐、快速靈活、實時混合能力於一身，面向海量數據場景提供世界領先的高性能、可跨域、多一致、多模型的混合存儲處理能力。目前，Lindorm已經全面服務於阿里經濟體中的大數據結構化、半結構化存儲場景。

注：Lindorm是阿里內部HBase分支的別稱，在阿里雲上對外售賣的版本叫作HBase加強版，以後文中出現的HBase加強版和Lindorm都指同一個產品。html

2019年以來，Lindorm已經服務了包括淘寶、天貓、螞蟻、菜鳥、媽媽、優酷、高德、大文娛等數十個BU，在今年的雙十一中，Lindorm峯值請求達到了7.5億次每秒，天吞吐22.9萬億次，平均響應時間低於3ms，總體存儲的數據量達到了數百PB。這些數字的背後，凝聚了HBase&Lindorm團隊多年以來的汗水和心血。Lindorm脫胎於HBase，是團隊多年以來承載數百PB數據，億級請求量，上千個業務後，在面對規模成本壓力，以及HBase自身缺陷下，全面重構和引擎升級的全新產品。相比HBase，Lindorm不管是性能，功能仍是可用性上，都有了巨大飛躍。本文將從功能、可用性、性能成本、服務生態等維度介紹Lindorm的核心能力與業務表現，最後分享部分咱們正在進行中的一些項目。java

極致優化，超強性能

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/docum...

TableService模型(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，作到了分鐘級推送全網用戶。

注：該模型已經在阿里雲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/docum...

雲原生，更低使用成本

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/article...

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/...

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

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上。所以，用戶在請求這些表時，發往Table一、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加強版」的形式，以及在專有云中對外輸出**（點擊瞭解詳情
)）**讓雲上的客戶可以享受到阿里巴巴的技術紅利，助力業務騰飛！

參考資料：

HBase加強版/Lindorm性能測試相關文檔

https://help.aliyun.com/docum...

如何下降90%Java垃圾回收時間？以阿里HBase的GC優化實踐爲例

https://yq.aliyun.com/article...

大數據時代的結構化存儲—HBase在阿里的應用實踐

https://yq.aliyun.com/article...

看我72變，阿里HBase數據壓縮編碼探索

https://yq.aliyun.com/article...

阿里HBase高可用8年「抗戰」回憶錄

https://developer.aliyun.com/...

高性能原生二級索引