前言

2021 年，轉(zhuǎn)眼 Lindorm 已經(jīng)在阿里發(fā)展了十年的時間，從基于 HBase 深度改造的 Lindorm 1.0 版本，到全面重構(gòu)，架構(gòu)大幅升級的 Lindorm 2.0 版本；從單一的寬表引擎，到支持搜索、時序、文件等多種結(jié)構(gòu)化數(shù)據(jù)處理的多模引擎，Lindorm 始終保持著快速迭代和升級的速度，以滿足阿里集團(tuán)各類業(yè)務(wù)的數(shù)據(jù)存儲需求。目前，Lindorm是公司內(nèi)部數(shù)據(jù)體量最大，覆蓋業(yè)務(wù)最廣的數(shù)據(jù)庫產(chǎn)品之一。

去年，在讓廣大用戶看得見、存得起的理念下，Lindorm 再次做了品牌升級，率先提出了多模超融合數(shù)據(jù)庫概念。Lindorm 不單單是寬表、時序、搜索等引擎的簡單堆疊，而是在統(tǒng)一的分布式存儲引擎之上，各個引擎之間互通融合，并由統(tǒng)一的 SQL 入口來實(shí)現(xiàn)多模數(shù)據(jù)庫的統(tǒng)一訪問。

在 Lindorm 一個數(shù)據(jù)庫中，用戶就可以實(shí)現(xiàn)流式計(jì)算，寬表存儲，列式索引、時空索引、時序預(yù)測、數(shù)據(jù)訂閱，以及在各個模型上的復(fù)雜分析等多種功能。面對復(fù)雜多變的業(yè)務(wù)，以及百花齊放的應(yīng)用，業(yè)務(wù)不需要面臨選型和運(yùn)維多個復(fù)雜數(shù)據(jù)庫的難題，數(shù)據(jù)的整個生命周期都可以在Lindorm 內(nèi)部各個組件中完成，滿足用戶寫入，查詢，分析，監(jiān)控各種需求。

?2021年雙11，Lindorm為手淘互動營銷、智能風(fēng)控、媒體大屏、生意參謀、花唄決策、消費(fèi)記錄等核心系統(tǒng)保駕護(hù)航，提供集群水位和狀態(tài)透傳產(chǎn)品化能力，業(yè)務(wù)可自行按需伸縮，提升備戰(zhàn)效率，業(yè)務(wù)支持成本降低80%。云原生Serverless架構(gòu)升級，大促資源按需彈性伸縮，資源管理效率提升10倍+，降本增效。基于存儲池化及透明壓縮技術(shù)，最高降低53%存儲成本。分布式3AZ架構(gòu)，實(shí)現(xiàn)秒級恢復(fù)的跨機(jī)房強(qiáng)一致容災(zāi)能力，支撐金融級高可用場景。

而作為 Lindorm 多模數(shù)據(jù)庫中重要一環(huán)的寬表引擎，目前已經(jīng)完整經(jīng)歷了 Lindorm 十年的發(fā)展，其功能、性能、穩(wěn)定性等方面的諸多創(chuàng)新歷經(jīng)了長時間的大規(guī)模實(shí)踐考驗(yàn)。服務(wù)了包括淘寶、天貓、螞蟻、菜鳥、媽媽、優(yōu)酷、高德、大文娛等數(shù)十個 BU。

Lindorm 寬表融合了阿里巴巴過去十年在大規(guī)模寬表技術(shù)領(lǐng)域的技術(shù)能力和經(jīng)驗(yàn)，并在上云后，利用云基礎(chǔ)設(shè)施，實(shí)現(xiàn)了云原生化，向低成本等方向又有了一些創(chuàng)新和突破，進(jìn)一步構(gòu)建了海量數(shù)據(jù)處理場景的競爭力。十年的演進(jìn)過程中，我們實(shí)現(xiàn)了跨 AZ 容災(zāi)，支持了多一致性滿足各種業(yè)務(wù)的需求。支持一體化冷熱分離，高壓縮算法降低用戶成本。實(shí)現(xiàn)了分布式全局二級索引，并和搜索引擎結(jié)合推出 SearchIndex 滿足用戶各種復(fù)雜查詢需求。十年來，我們團(tuán)隊(duì)聚焦在寬表領(lǐng)域，不斷打磨 Lindorm 寬表引擎，可謂是十年磨一劍。今年我們又對 Lindorm 寬表的一些功能進(jìn)行了升級和改造，推陳出新，真正踐行了把簡單留給客戶，把復(fù)雜留給自己的理念。

更加易用的功能

Lindorm寬表積攢了一大批面向各類用戶的功能，比如說SQL，二級索引等等。這些功能方便了用戶的使用。但是隨著業(yè)務(wù)場景的增加，用戶對這些功能又提出了一些新的需求。比如之前SQL不支持order by等功能，用戶在使用時有比較大的局限。面對用戶這些槽點(diǎn)，Lindorm寬表對功能又做了進(jìn)一步的增強(qiáng)。

更強(qiáng)大的SQL能力

Lindorm寬表引擎在很早的時候就已經(jīng)支持了SQL訪問，相比使用API，SQL語言更加簡單容易上手，深受廣大Lindorm開發(fā)者的喜愛。并且，Lindorm的寬表引擎支持將指定列在搜索引擎中建立倒排索引，使用統(tǒng)一的SQL去訪問。但是，之前的Lindorm SQL還只支持一些簡單的SQL DML操作，像order by，group by和join等語法都不支持。今年，我們把整個SQL模塊都進(jìn)行了重構(gòu)，重構(gòu)后的SQL模塊將成為Lindorm各個引擎統(tǒng)一的SQL入口，并且通過引入了復(fù)雜執(zhí)行器（Complex Executor）模塊，把之前不支持的group by等SQL語法都已經(jīng)支持。現(xiàn)在，這套新的SQL引擎還在繼續(xù)演進(jìn)，我們的目標(biāo)是在使用統(tǒng)一的SQL接入層訪問Lindorm各個模型，將不同負(fù)載的請求路由到合適的組件中。

更加安全的數(shù)據(jù)

數(shù)據(jù)安全是企業(yè)的生命線，Lindorm上的很多客戶在Lindorm寬表內(nèi)存儲了很多敏感數(shù)據(jù)，特別是金融客戶，由于監(jiān)管需求，所有涉及到用戶和訂單的數(shù)據(jù)，都必須加密傳輸和加密存儲。因此，Lindorm在已有的用戶名密碼權(quán)限的基礎(chǔ)上，又加入了多重加密功能，以及審計(jì)日志等功能，滿足這類企業(yè)級用戶需要。

透明加密

云上客戶和集團(tuán)客戶的區(qū)別之一就在于其豐富的行業(yè)特性。金融領(lǐng)域和國家機(jī)構(gòu)這兩類客戶在進(jìn)行數(shù)據(jù)庫產(chǎn)品選型時都對數(shù)據(jù)庫的安全性表現(xiàn)出了強(qiáng)烈的興趣。并且縱觀云計(jì)算領(lǐng)域，Azure 的 cosmosDB，AWS 的 DynamoDB，阿里云的 OSS，RDS 都具備靜態(tài)數(shù)據(jù)加密的能力，缺乏安全方面的功能特性有時會直接失去進(jìn)入某個行業(yè)的入場券。

當(dāng)今數(shù)據(jù)庫面臨的安全威脅大致可以分為 8 類，而靜態(tài)數(shù)據(jù)加密并不是全家桶式的安全解決方案，其主要致力于解決眾多威脅中的一類 —— 不安全的存儲介質(zhì)。持久化數(shù)據(jù)庫中的數(shù)據(jù)最終會以文件的形式保存在硬盤等存儲介質(zhì)當(dāng)中，如果數(shù)據(jù)以明文的形式保存，通過直接解析文件可以輕易獲取用戶的業(yè)務(wù)數(shù)據(jù)。

數(shù)據(jù)庫透明加密（TDE）是實(shí)現(xiàn)靜態(tài)數(shù)據(jù)加密的一種方式，對比客戶端加密，數(shù)據(jù)庫透明加密的優(yōu)勢在于整個加密由數(shù)據(jù)庫內(nèi)部完成，數(shù)據(jù)庫的使用者不感知這一過程，因此無需改動。對比文件系統(tǒng)加密，數(shù)據(jù)庫透明加密的優(yōu)勢在于可以更細(xì)粒度的控制加密的范疇，在安全和性能之間取得一個較好的平衡。

Lindorm 在設(shè)計(jì)的過程中，兼顧考慮了實(shí)現(xiàn)復(fù)雜度，性能開銷，以及使用門檻等因素，選擇以表為顆粒度支持透明加密，同時在加密算法上，支持了國際公認(rèn)的分組加密算法 AES 和國家商密算法 SMS4。歡迎對數(shù)據(jù)安全性有需求的業(yè)務(wù)聯(lián)系我們使用。

其他加密支持

除了Lindorm寬表內(nèi)核支持的透明加密，Lindorm還支持了一些其他的加密方式，比如云盤加密，基于塊存儲對整個數(shù)據(jù)盤進(jìn)行加密，即使數(shù)據(jù)備份泄露也無法被解密，保護(hù)數(shù)據(jù)安全。另外，我們還基于Thrift協(xié)議加SSL的方式，實(shí)現(xiàn)了傳輸加密，使用戶整個訪問鏈路都是加密狀態(tài)，進(jìn)一步保證了用戶的安全。接下來，我們還會實(shí)現(xiàn)Lindorm自身協(xié)議的加密功能。

審計(jì)日志

有很多非常在意生產(chǎn)安全的企業(yè)需要記錄每一次操作Lindorm的記錄，比如建表，刪表操作，用戶授權(quán)等等。有一些存儲了敏感數(shù)據(jù)的企業(yè)，甚至要求記錄每一條記錄的訪問日志，看什么時候，什么人讀取了哪個用戶的信息，用來做合規(guī)審計(jì)和事后追查。面對這些客戶的需求，Lindorm寬表引擎研發(fā)了審計(jì)日志功能。能夠詳細(xì)記錄每個DDL，甚至DML的操作信息。目前，我們的審計(jì)日志正在與SLS打通，打通后，我們的審計(jì)日志可以通過LogTail投遞到用戶指定的SLS中，用戶可以自行定制審計(jì)日志保留時間，以及查詢需求。

更加高效的運(yùn)維

Lindorm在集團(tuán)內(nèi)有上萬臺機(jī)器，在云上也有上千個實(shí)例。運(yùn)行在這些實(shí)例上的業(yè)務(wù)千差萬別，負(fù)載和模型各不一樣，很難做到一套配置滿足所有用戶的需求。比如在寫入流量比較大的集群上，默認(rèn)的Compaction配置可能會造成Compaction積壓，小文件增多影響性能。Compaction的調(diào)參需要資深的內(nèi)核同學(xué)進(jìn)行，這項(xiàng)工作費(fèi)時費(fèi)力。另外，雖然說Lindorm是一個分布式數(shù)據(jù)庫，但用戶在設(shè)計(jì)表結(jié)構(gòu)時，或者突發(fā)流量來臨時，往往會有熱點(diǎn)問題打爆單機(jī)，這些都需要SRE手工去處理，不僅速度慢，而且會造成穩(wěn)定性問題。因此，今年Lindorm選取了線上出現(xiàn)問題比較多的Compaction積壓和熱點(diǎn)問題，進(jìn)行了專項(xiàng)優(yōu)化，讓這些問題能夠自動的解決掉，提升Lindorm的自愈能力，解放運(yùn)維人員的壓力，加強(qiáng)系統(tǒng)穩(wěn)定性。

Offload Compaction

基于 LSM-Tree 架構(gòu)的分布式數(shù)據(jù)庫，對于數(shù)據(jù)寫入并不會原地更新，而是先寫入內(nèi)存，然后周期將內(nèi)存中的數(shù)據(jù)刷新為只讀的存儲文件。因此讀取數(shù)據(jù)時往往需要遍歷多個文件找到當(dāng)前生效的正確值。隨著存儲文件不斷增加，讀性能會因?yàn)?IO 增多而下降。對此實(shí)現(xiàn)中通常會周期性執(zhí)行 Compaction 操作將多個文件合并，使文件個數(shù)基本穩(wěn)定，進(jìn)而穩(wěn)定讀取的 IO 次數(shù)，將延遲控制在一定范圍內(nèi)。

在 Lindorm 現(xiàn)有架構(gòu)中，Compaction 任務(wù)的執(zhí)行和讀寫請求服務(wù)是耦合在一個進(jìn)程當(dāng)中的，因?yàn)?Compaction 任務(wù)會產(chǎn)生很大的帶寬、IO 壓力，同時也會消耗 CPU 和內(nèi)存資源，因此容易影響讀寫請求的響應(yīng)時長。其次不同業(yè)務(wù)對 compaction 的需求存在較大差異，讀多寫少的場景，compaction 任務(wù)壓力小（元數(shù)據(jù)存儲場景），寫多讀延遲敏感的場景（風(fēng)控場景），compaction 任務(wù)壓力重。難以統(tǒng)一和管理 compaction 任務(wù)相關(guān)的參數(shù)設(shè)定。當(dāng)文件發(fā)生大量積壓時，因?yàn)轳詈系囊蛩?#xff0c;無法獨(dú)立擴(kuò)容快速消化文件來降低業(yè)務(wù)風(fēng)險(xiǎn)，展現(xiàn)了當(dāng)前設(shè)計(jì)缺乏靈活性的一面。

可以將 Compaction 任務(wù)看做周期執(zhí)行的離線任務(wù)，而讀寫服務(wù)是實(shí)時在線服務(wù)，問題的根節(jié)在于離線任務(wù)和實(shí)時在線任務(wù)強(qiáng)耦合在一起，導(dǎo)致兩者相互影響，擴(kuò)縮容不靈活。基于這個洞察，Lindorm 實(shí)現(xiàn)了 Offload Compaction 功能，支持 Compaction 任務(wù)以獨(dú)立的進(jìn)程運(yùn)行在獨(dú)立的機(jī)器上，一方面服務(wù)讀寫請求的機(jī)器不會再因?yàn)?compaction 任務(wù)的運(yùn)行產(chǎn)生抖動，另一方面運(yùn)行 Compaction 任務(wù)的機(jī)器可以充分利用機(jī)器資源，無需擔(dān)心影響在線服務(wù)，更值得一提的是，db 運(yùn)維可以搭建巨大的 Compaction 任務(wù)集群進(jìn)行統(tǒng)一管理，根據(jù)任務(wù)的多少按需擴(kuò)縮容，極大地簡化了運(yùn)維成本。

?Quota 限流

對于數(shù)據(jù)庫系統(tǒng)來說，無論是單機(jī)的 Mysql 還是分布式的 Lindorm，在底層服務(wù)器硬件規(guī)模一定的情況下，服務(wù)的能力一定是有限的，在多租戶的場景下，如果某個租戶的請求流量超過數(shù)據(jù)庫的承受極限，很可能會造成數(shù)據(jù)庫服務(wù)能力下降，影響該數(shù)據(jù)庫上的其他租戶，嚴(yán)重時甚至?xí)斐煞?wù)器宕機(jī)，這個是非常危險(xiǎn)的。因此，一般的數(shù)據(jù)庫系統(tǒng)都有對應(yīng)的限流方案，當(dāng)租戶的請求流量超過服務(wù)能力的時候，對其進(jìn)行限流，防止影響其他租戶。

在不考慮分布式的情況下，限流是比較簡單的，限流系統(tǒng)不需要在各個機(jī)器間進(jìn)行協(xié)調(diào)，只需要記錄訪問本機(jī)的請求，超過閾值就開啟限流即可。而在分布式系統(tǒng)中，限流的方案往往比較復(fù)雜，涉及到分布式協(xié)調(diào)等問題。同時，對于一個像 Lindorm 一樣的大吞吐的分布式系統(tǒng)，怎么在限流的情況下，不影響正常的請求響應(yīng)，也是一個難點(diǎn)。

Lindorm 自研了一套分布式限流體系，其具有以下獨(dú)特之處：

使用 Quota 作為限流單位，用戶請求需要處理的數(shù)據(jù)量越多，消耗 Quota 越多，因此對比 QPS，Quota 更能真實(shí)反映請求對系統(tǒng)產(chǎn)生的壓力

中心式 QuotaCenter 統(tǒng)一管理 Quota 消耗，即使用戶的流量在機(jī)器上分布不均勻也能夠正常執(zhí)行限流邏輯

Quota 消耗由 QuotaProxy 異步定期匯報(bào)，QuotaCenter 不會成為系統(tǒng)的單點(diǎn)，QuotaCenter 的壓力與用戶請求量無關(guān)

用戶請求過程中不直接與 QuotaCenter 交互，每次請求只會檢查 QuotaProxy 本地緩存的信息，不影響用戶的請求響應(yīng)時間

QuotaCenter 弱依賴，QuotaCenter 宕機(jī)，不會影響用戶請求

未來展望

我們抱著十年磨一劍的心態(tài)，從 0 開始打造 Lindorm 這個產(chǎn)品。今年是 Lindorm 在阿里的第十個年頭，Lindorm正當(dāng)壯年，業(yè)務(wù)驅(qū)動是 Lindorm 寬表引擎不變的演進(jìn)原則。我們將持續(xù)為用戶提供無縫擴(kuò)展、高吞吐、持續(xù)可用、毫秒級穩(wěn)定響應(yīng)、強(qiáng)弱一致性可調(diào)、低存儲成本、豐富索引的數(shù)據(jù)實(shí)時離線混合存取能力。未來，Lindorm 寬表引擎會在以下幾個方向繼續(xù)前進(jìn)。

更低的使用成本：?使用成本低是云原生數(shù)據(jù)庫 Lindorm 的一個關(guān)鍵特征。沒有最低的成本，只有更低的成本，我們還將繼續(xù)在低成本這方面深耕，繼我們引入 OSS 標(biāo)準(zhǔn)型存儲做為冷存后，我們還會引入 OSS 的歸檔存儲，進(jìn)一步滿足用戶對更冷數(shù)據(jù)的存儲查詢需求。另外，Lindorm 多 AZ 部署給用戶帶來了跨可用區(qū)高可用的能力，但是目前多可用區(qū)之間的分片副本數(shù)據(jù)并沒有共享，我們希望利用 Region Replica 的技術(shù)使多可用區(qū)共享底層存儲部分，進(jìn)一步降低使用成本。

更易用的使用體驗(yàn)：目前，Lindorm 已經(jīng)全面擁抱 SQL，我們希望使用 SQL 能夠給用戶帶來更加統(tǒng)一的，易用的使用體驗(yàn)。Lindorm 寬表將繼續(xù)完善 SQL 能力，將寬表已有的能力，比如 FeedStream，WideColumn 等全部接入 SQL。同時像慢請求查詢，熱點(diǎn) key 查詢，集群運(yùn)維等相關(guān)能力，也計(jì)劃通過 SQL 的方式暴露給用戶，讓Lindorm 真正成為一款面向用戶的數(shù)據(jù)庫。

更豐富的功能：隨著 Lindorm 承載業(yè)務(wù)的多元化，Lindorm 面對的業(yè)務(wù)場景也越來越復(fù)雜，面對這些業(yè)務(wù)給Lindorm 帶來的挑戰(zhàn)，我們必須不斷去豐富 Lindorm 的功能去滿足這些客戶的需求。比如說我們會實(shí)現(xiàn) Blob 存儲解決 Lindorm 之前寬表模型在大 kv 存儲場景性能不佳的問題，引入 bitmap 類型滿足用戶畫像，人群圈選等場景。支持表快照以滿足用戶一體化查詢分析的需求。

更強(qiáng)的彈性能力：Lindorm 存儲分離的架構(gòu)加上云基礎(chǔ)設(shè)施的靈活性已經(jīng)給 Lindorm 帶來了非常強(qiáng)的彈性能力，在線擴(kuò)縮容和升降配能力已經(jīng)能滿足大部分用戶需求，但是受限于 ECS 的啟停速度，云盤的擴(kuò)縮容限制，Lindorm 彈性能力并沒有達(dá)到我們心中“秒級”的標(biāo)準(zhǔn)。因此，Lindorm 在構(gòu)架新一代部署架構(gòu)，希望利用大存儲池，借助 ECI和 ACK 的力量，真正實(shí)現(xiàn)秒級的彈性能力。

另外，我在這里預(yù)告一下，Lindorm 寬表引擎即將開源，開源能夠?qū)?Lindorm 寬表的技術(shù)積累推廣到業(yè)界，讓更多人能使用到 Lindorm 先進(jìn)的技術(shù)。我們也希望能夠通過開源的方式，去吸引更多的人來共建 Lindorm，發(fā)展技術(shù)。Lindorm 即將邁入一個開源的新時代，但是 Lindorm 寬表的初心一直沒變：致力于做最好的寬表數(shù)據(jù)庫產(chǎn)品，歡迎對技術(shù)感興趣的各位通過開源的方式一起參與進(jìn)來。

結(jié)束語

梅花香自苦寒來，寶劍鋒從磨礪出，Lindorm 每一個功能研發(fā)方向都來自于業(yè)務(wù)真實(shí)的需求輸入，你們的理解和信任是我們不斷前進(jìn)的動力，沒有你們的陪伴和支持，就沒有 Lindorm 今天的成果。感謝所有幫助、支持、信任、鼓勵、鞭策過我們的同學(xué)。我們一定努力做最好的大數(shù)據(jù) NoSQL 產(chǎn)品，眾志成城、不忘初心、砥礪前行！

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

總結(jié)

以上是生活随笔為你收集整理的双11特刊｜十年磨一剑，云原生多模数据库Lindorm 2021双11总结的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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