双11特刊｜十年磨一剑，云原生多模数据库Lindorm 2021双11总结
前言
2021 年，轉(zhuǎn)眼 Lindorm 已經(jīng)在阿里發(fā)展了十年的時(shí)間，從基于 HBase 深度改造的 Lindorm 1.0 版本，到全面重構(gòu)，架構(gòu)大幅升級(jí)的 Lindorm 2.0 版本；從單一的寬表引擎，到支持搜索、時(shí)序、文件等多種結(jié)構(gòu)化數(shù)據(jù)處理的多模引擎，Lindorm 始終保持著快速迭代和升級(jí)的速度，以滿足阿里集團(tuán)各類業(yè)務(wù)的數(shù)據(jù)存儲(chǔ)需求。目前，Lindorm是公司內(nèi)部數(shù)據(jù)體量最大，覆蓋業(yè)務(wù)最廣的數(shù)據(jù)庫(kù)產(chǎn)品之一。
去年，在讓廣大用戶看得見、存得起的理念下，Lindorm 再次做了品牌升級(jí)，率先提出了多模超融合數(shù)據(jù)庫(kù)概念。Lindorm 不單單是寬表、時(shí)序、搜索等引擎的簡(jiǎn)單堆疊，而是在統(tǒng)一的分布式存儲(chǔ)引擎之上，各個(gè)引擎之間互通融合，并由統(tǒng)一的 SQL 入口來(lái)實(shí)現(xiàn)多模數(shù)據(jù)庫(kù)的統(tǒng)一訪問(wèn)。
在 Lindorm 一個(gè)數(shù)據(jù)庫(kù)中，用戶就可以實(shí)現(xiàn)流式計(jì)算，寬表存儲(chǔ)，列式索引、時(shí)空索引、時(shí)序預(yù)測(cè)、數(shù)據(jù)訂閱，以及在各個(gè)模型上的復(fù)雜分析等多種功能。面對(duì)復(fù)雜多變的業(yè)務(wù)，以及百花齊放的應(yīng)用，業(yè)務(wù)不需要面臨選型和運(yùn)維多個(gè)復(fù)雜數(shù)據(jù)庫(kù)的難題，數(shù)據(jù)的整個(gè)生命周期都可以在Lindorm 內(nèi)部各個(gè)組件中完成，滿足用戶寫入，查詢，分析，監(jiān)控各種需求。
?2021年雙11，Lindorm為手淘互動(dòng)營(yíng)銷、智能風(fēng)控、媒體大屏、生意參謀、花唄決策、消費(fèi)記錄等核心系統(tǒng)保駕護(hù)航，提供集群水位和狀態(tài)透?jìng)鳟a(chǎn)品化能力，業(yè)務(wù)可自行按需伸縮，提升備戰(zhàn)效率，業(yè)務(wù)支持成本降低80%。云原生Serverless架構(gòu)升級(jí)，大促資源按需彈性伸縮，資源管理效率提升10倍+，降本增效。基于存儲(chǔ)池化及透明壓縮技術(shù)，最高降低53%存儲(chǔ)成本。分布式3AZ架構(gòu)，實(shí)現(xiàn)秒級(jí)恢復(fù)的跨機(jī)房強(qiáng)一致容災(zāi)能力，支撐金融級(jí)高可用場(chǎng)景。
而作為 Lindorm 多模數(shù)據(jù)庫(kù)中重要一環(huán)的寬表引擎，目前已經(jīng)完整經(jīng)歷了 Lindorm 十年的發(fā)展，其功能、性能、穩(wěn)定性等方面的諸多創(chuàng)新歷經(jīng)了長(zhǎng)時(shí)間的大規(guī)模實(shí)踐考驗(yàn)。服務(wù)了包括淘寶、天貓、螞蟻、菜鳥、媽媽、優(yōu)酷、高德、大文娛等數(shù)十個(gè) BU。
Lindorm 寬表融合了阿里巴巴過(guò)去十年在大規(guī)模寬表技術(shù)領(lǐng)域的技術(shù)能力和經(jīng)驗(yàn)，并在上云后，利用云基礎(chǔ)設(shè)施，實(shí)現(xiàn)了云原生化，向低成本等方向又有了一些創(chuàng)新和突破，進(jìn)一步構(gòu)建了海量數(shù)據(jù)處理場(chǎng)景的競(jìng)爭(zhēng)力。十年的演進(jìn)過(guò)程中，我們實(shí)現(xiàn)了跨 AZ 容災(zāi)，支持了多一致性滿足各種業(yè)務(wù)的需求。支持一體化冷熱分離，高壓縮算法降低用戶成本。實(shí)現(xiàn)了分布式全局二級(jí)索引，并和搜索引擎結(jié)合推出 SearchIndex 滿足用戶各種復(fù)雜查詢需求。十年來(lái)，我們團(tuán)隊(duì)聚焦在寬表領(lǐng)域，不斷打磨 Lindorm 寬表引擎，可謂是十年磨一劍。今年我們又對(duì) Lindorm 寬表的一些功能進(jìn)行了升級(jí)和改造，推陳出新，真正踐行了把簡(jiǎn)單留給客戶，把復(fù)雜留給自己的理念。
更加易用的功能
Lindorm寬表積攢了一大批面向各類用戶的功能，比如說(shuō)SQL，二級(jí)索引等等。這些功能方便了用戶的使用。但是隨著業(yè)務(wù)場(chǎng)景的增加，用戶對(duì)這些功能又提出了一些新的需求。比如之前SQL不支持order by等功能，用戶在使用時(shí)有比較大的局限。面對(duì)用戶這些槽點(diǎn)，Lindorm寬表對(duì)功能又做了進(jìn)一步的增強(qiáng)。
更強(qiáng)大的SQL能力
Lindorm寬表引擎在很早的時(shí)候就已經(jīng)支持了SQL訪問(wèn)，相比使用API，SQL語(yǔ)言更加簡(jiǎn)單容易上手，深受廣大Lindorm開發(fā)者的喜愛(ài)。并且，Lindorm的寬表引擎支持將指定列在搜索引擎中建立倒排索引，使用統(tǒng)一的SQL去訪問(wèn)。但是，之前的Lindorm SQL還只支持一些簡(jiǎn)單的SQL DML操作，像order by，group by和join等語(yǔ)法都不支持。今年，我們把整個(gè)SQL模塊都進(jìn)行了重構(gòu)，重構(gòu)后的SQL模塊將成為L(zhǎng)indorm各個(gè)引擎統(tǒng)一的SQL入口，并且通過(guò)引入了復(fù)雜執(zhí)行器（Complex Executor）模塊，把之前不支持的group by等SQL語(yǔ)法都已經(jīng)支持。現(xiàn)在，這套新的SQL引擎還在繼續(xù)演進(jìn)，我們的目標(biāo)是在使用統(tǒng)一的SQL接入層訪問(wèn)Lindorm各個(gè)模型，將不同負(fù)載的請(qǐng)求路由到合適的組件中。
更加安全的數(shù)據(jù)
數(shù)據(jù)安全是企業(yè)的生命線，Lindorm上的很多客戶在Lindorm寬表內(nèi)存儲(chǔ)了很多敏感數(shù)據(jù)，特別是金融客戶，由于監(jiān)管需求，所有涉及到用戶和訂單的數(shù)據(jù)，都必須加密傳輸和加密存儲(chǔ)。因此，Lindorm在已有的用戶名密碼權(quán)限的基礎(chǔ)上，又加入了多重加密功能，以及審計(jì)日志等功能，滿足這類企業(yè)級(jí)用戶需要。
透明加密
云上客戶和集團(tuán)客戶的區(qū)別之一就在于其豐富的行業(yè)特性。金融領(lǐng)域和國(guó)家機(jī)構(gòu)這兩類客戶在進(jìn)行數(shù)據(jù)庫(kù)產(chǎn)品選型時(shí)都對(duì)數(shù)據(jù)庫(kù)的安全性表現(xiàn)出了強(qiáng)烈的興趣。并且縱觀云計(jì)算領(lǐng)域，Azure 的 cosmosDB，AWS 的 DynamoDB，阿里云的 OSS，RDS 都具備靜態(tài)數(shù)據(jù)加密的能力，缺乏安全方面的功能特性有時(shí)會(huì)直接失去進(jìn)入某個(gè)行業(yè)的入場(chǎng)券。
當(dāng)今數(shù)據(jù)庫(kù)面臨的安全威脅大致可以分為 8 類，而靜態(tài)數(shù)據(jù)加密并不是全家桶式的安全解決方案，其主要致力于解決眾多威脅中的一類 —— 不安全的存儲(chǔ)介質(zhì)。持久化數(shù)據(jù)庫(kù)中的數(shù)據(jù)最終會(huì)以文件的形式保存在硬盤等存儲(chǔ)介質(zhì)當(dāng)中，如果數(shù)據(jù)以明文的形式保存，通過(guò)直接解析文件可以輕易獲取用戶的業(yè)務(wù)數(shù)據(jù)。
數(shù)據(jù)庫(kù)透明加密（TDE）是實(shí)現(xiàn)靜態(tài)數(shù)據(jù)加密的一種方式，對(duì)比客戶端加密，數(shù)據(jù)庫(kù)透明加密的優(yōu)勢(shì)在于整個(gè)加密由數(shù)據(jù)庫(kù)內(nèi)部完成，數(shù)據(jù)庫(kù)的使用者不感知這一過(guò)程，因此無(wú)需改動(dòng)。對(duì)比文件系統(tǒng)加密，數(shù)據(jù)庫(kù)透明加密的優(yōu)勢(shì)在于可以更細(xì)粒度的控制加密的范疇，在安全和性能之間取得一個(gè)較好的平衡。
Lindorm 在設(shè)計(jì)的過(guò)程中，兼顧考慮了實(shí)現(xiàn)復(fù)雜度，性能開銷，以及使用門檻等因素，選擇以表為顆粒度支持透明加密，同時(shí)在加密算法上，支持了國(guó)際公認(rèn)的分組加密算法 AES 和國(guó)家商密算法 SMS4。歡迎對(duì)數(shù)據(jù)安全性有需求的業(yè)務(wù)聯(lián)系我們使用。
其他加密支持
除了Lindorm寬表內(nèi)核支持的透明加密，Lindorm還支持了一些其他的加密方式，比如云盤加密，基于塊存儲(chǔ)對(duì)整個(gè)數(shù)據(jù)盤進(jìn)行加密，即使數(shù)據(jù)備份泄露也無(wú)法被解密，保護(hù)數(shù)據(jù)安全。另外，我們還基于Thrift協(xié)議加SSL的方式，實(shí)現(xiàn)了傳輸加密，使用戶整個(gè)訪問(wèn)鏈路都是加密狀態(tài)，進(jìn)一步保證了用戶的安全。接下來(lái)，我們還會(huì)實(shí)現(xiàn)Lindorm自身協(xié)議的加密功能。
審計(jì)日志
有很多非常在意生產(chǎn)安全的企業(yè)需要記錄每一次操作Lindorm的記錄，比如建表，刪表操作，用戶授權(quán)等等。有一些存儲(chǔ)了敏感數(shù)據(jù)的企業(yè)，甚至要求記錄每一條記錄的訪問(wèn)日志，看什么時(shí)候，什么人讀取了哪個(gè)用戶的信息，用來(lái)做合規(guī)審計(jì)和事后追查。面對(duì)這些客戶的需求，Lindorm寬表引擎研發(fā)了審計(jì)日志功能。能夠詳細(xì)記錄每個(gè)DDL，甚至DML的操作信息。目前，我們的審計(jì)日志正在與SLS打通，打通后，我們的審計(jì)日志可以通過(guò)LogTail投遞到用戶指定的SLS中，用戶可以自行定制審計(jì)日志保留時(shí)間，以及查詢需求。
更加高效的運(yùn)維
Lindorm在集團(tuán)內(nèi)有上萬(wàn)臺(tái)機(jī)器，在云上也有上千個(gè)實(shí)例。運(yùn)行在這些實(shí)例上的業(yè)務(wù)千差萬(wàn)別，負(fù)載和模型各不一樣，很難做到一套配置滿足所有用戶的需求。比如在寫入流量比較大的集群上，默認(rèn)的Compaction配置可能會(huì)造成Compaction積壓，小文件增多影響性能。Compaction的調(diào)參需要資深的內(nèi)核同學(xué)進(jìn)行，這項(xiàng)工作費(fèi)時(shí)費(fèi)力。另外，雖然說(shuō)Lindorm是一個(gè)分布式數(shù)據(jù)庫(kù)，但用戶在設(shè)計(jì)表結(jié)構(gòu)時(shí)，或者突發(fā)流量來(lái)臨時(shí)，往往會(huì)有熱點(diǎn)問(wèn)題打爆單機(jī)，這些都需要SRE手工去處理，不僅速度慢，而且會(huì)造成穩(wěn)定性問(wèn)題。因此，今年Lindorm選取了線上出現(xiàn)問(wèn)題比較多的Compaction積壓和熱點(diǎn)問(wèn)題，進(jìn)行了專項(xiàng)優(yōu)化，讓這些問(wèn)題能夠自動(dòng)的解決掉，提升Lindorm的自愈能力，解放運(yùn)維人員的壓力，加強(qiáng)系統(tǒng)穩(wěn)定性。
Offload Compaction
基于 LSM-Tree 架構(gòu)的分布式數(shù)據(jù)庫(kù)，對(duì)于數(shù)據(jù)寫入并不會(huì)原地更新，而是先寫入內(nèi)存，然后周期將內(nèi)存中的數(shù)據(jù)刷新為只讀的存儲(chǔ)文件。因此讀取數(shù)據(jù)時(shí)往往需要遍歷多個(gè)文件找到當(dāng)前生效的正確值。隨著存儲(chǔ)文件不斷增加，讀性能會(huì)因?yàn)?IO 增多而下降。對(duì)此實(shí)現(xiàn)中通常會(huì)周期性執(zhí)行 Compaction 操作將多個(gè)文件合并，使文件個(gè)數(shù)基本穩(wěn)定，進(jìn)而穩(wěn)定讀取的 IO 次數(shù)，將延遲控制在一定范圍內(nèi)。
在 Lindorm 現(xiàn)有架構(gòu)中，Compaction 任務(wù)的執(zhí)行和讀寫請(qǐng)求服務(wù)是耦合在一個(gè)進(jìn)程當(dāng)中的，因?yàn)?Compaction 任務(wù)會(huì)產(chǎn)生很大的帶寬、IO 壓力，同時(shí)也會(huì)消耗 CPU 和內(nèi)存資源，因此容易影響讀寫請(qǐng)求的響應(yīng)時(shí)長(zhǎng)。其次不同業(yè)務(wù)對(duì) compaction 的需求存在較大差異，讀多寫少的場(chǎng)景，compaction 任務(wù)壓力小（元數(shù)據(jù)存儲(chǔ)場(chǎng)景），寫多讀延遲敏感的場(chǎng)景（風(fēng)控場(chǎng)景），compaction 任務(wù)壓力重。難以統(tǒng)一和管理 compaction 任務(wù)相關(guān)的參數(shù)設(shè)定。當(dāng)文件發(fā)生大量積壓時(shí)，因?yàn)轳詈系囊蛩?#xff0c;無(wú)法獨(dú)立擴(kuò)容快速消化文件來(lái)降低業(yè)務(wù)風(fēng)險(xiǎn)，展現(xiàn)了當(dāng)前設(shè)計(jì)缺乏靈活性的一面。
可以將 Compaction 任務(wù)看做周期執(zhí)行的離線任務(wù)，而讀寫服務(wù)是實(shí)時(shí)在線服務(wù)，問(wèn)題的根節(jié)在于離線任務(wù)和實(shí)時(shí)在線任務(wù)強(qiáng)耦合在一起，導(dǎo)致兩者相互影響，擴(kuò)縮容不靈活。基于這個(gè)洞察，Lindorm 實(shí)現(xiàn)了 Offload Compaction 功能，支持 Compaction 任務(wù)以獨(dú)立的進(jìn)程運(yùn)行在獨(dú)立的機(jī)器上，一方面服務(wù)讀寫請(qǐng)求的機(jī)器不會(huì)再因?yàn)?compaction 任務(wù)的運(yùn)行產(chǎn)生抖動(dòng)，另一方面運(yùn)行 Compaction 任務(wù)的機(jī)器可以充分利用機(jī)器資源，無(wú)需擔(dān)心影響在線服務(wù)，更值得一提的是，db 運(yùn)維可以搭建巨大的 Compaction 任務(wù)集群進(jìn)行統(tǒng)一管理，根據(jù)任務(wù)的多少按需擴(kuò)縮容，極大地簡(jiǎn)化了運(yùn)維成本。
?Quota 限流
對(duì)于數(shù)據(jù)庫(kù)系統(tǒng)來(lái)說(shuō)，無(wú)論是單機(jī)的 Mysql 還是分布式的 Lindorm，在底層服務(wù)器硬件規(guī)模一定的情況下，服務(wù)的能力一定是有限的，在多租戶的場(chǎng)景下，如果某個(gè)租戶的請(qǐng)求流量超過(guò)數(shù)據(jù)庫(kù)的承受極限，很可能會(huì)造成數(shù)據(jù)庫(kù)服務(wù)能力下降，影響該數(shù)據(jù)庫(kù)上的其他租戶，嚴(yán)重時(shí)甚至?xí)斐煞?wù)器宕機(jī)，這個(gè)是非常危險(xiǎn)的。因此，一般的數(shù)據(jù)庫(kù)系統(tǒng)都有對(duì)應(yīng)的限流方案，當(dāng)租戶的請(qǐng)求流量超過(guò)服務(wù)能力的時(shí)候，對(duì)其進(jìn)行限流，防止影響其他租戶。
在不考慮分布式的情況下，限流是比較簡(jiǎn)單的，限流系統(tǒng)不需要在各個(gè)機(jī)器間進(jìn)行協(xié)調(diào)，只需要記錄訪問(wèn)本機(jī)的請(qǐng)求，超過(guò)閾值就開啟限流即可。而在分布式系統(tǒng)中，限流的方案往往比較復(fù)雜，涉及到分布式協(xié)調(diào)等問(wèn)題。同時(shí)，對(duì)于一個(gè)像 Lindorm 一樣的大吞吐的分布式系統(tǒng)，怎么在限流的情況下，不影響正常的請(qǐng)求響應(yīng)，也是一個(gè)難點(diǎn)。
Lindorm 自研了一套分布式限流體系，其具有以下獨(dú)特之處：
未來(lái)展望
我們抱著十年磨一劍的心態(tài)，從 0 開始打造 Lindorm 這個(gè)產(chǎn)品。今年是 Lindorm 在阿里的第十個(gè)年頭，Lindorm正當(dāng)壯年，業(yè)務(wù)驅(qū)動(dòng)是 Lindorm 寬表引擎不變的演進(jìn)原則。我們將持續(xù)為用戶提供無(wú)縫擴(kuò)展、高吞吐、持續(xù)可用、毫秒級(jí)穩(wěn)定響應(yīng)、強(qiáng)弱一致性可調(diào)、低存儲(chǔ)成本、豐富索引的數(shù)據(jù)實(shí)時(shí)離線混合存取能力。未來(lái)，Lindorm 寬表引擎會(huì)在以下幾個(gè)方向繼續(xù)前進(jìn)。
更低的使用成本：?使用成本低是云原生數(shù)據(jù)庫(kù) Lindorm 的一個(gè)關(guān)鍵特征。沒(méi)有最低的成本，只有更低的成本，我們還將繼續(xù)在低成本這方面深耕，繼我們引入 OSS 標(biāo)準(zhǔn)型存儲(chǔ)做為冷存后，我們還會(huì)引入 OSS 的歸檔存儲(chǔ)，進(jìn)一步滿足用戶對(duì)更冷數(shù)據(jù)的存儲(chǔ)查詢需求。另外，Lindorm 多 AZ 部署給用戶帶來(lái)了跨可用區(qū)高可用的能力，但是目前多可用區(qū)之間的分片副本數(shù)據(jù)并沒(méi)有共享，我們希望利用 Region Replica 的技術(shù)使多可用區(qū)共享底層存儲(chǔ)部分，進(jìn)一步降低使用成本。
更易用的使用體驗(yàn)：目前，Lindorm 已經(jīng)全面擁抱 SQL，我們希望使用 SQL 能夠給用戶帶來(lái)更加統(tǒng)一的，易用的使用體驗(yàn)。Lindorm 寬表將繼續(xù)完善 SQL 能力，將寬表已有的能力，比如 FeedStream，WideColumn 等全部接入 SQL。同時(shí)像慢請(qǐng)求查詢，熱點(diǎn) key 查詢，集群運(yùn)維等相關(guān)能力，也計(jì)劃通過(guò) SQL 的方式暴露給用戶，讓Lindorm 真正成為一款面向用戶的數(shù)據(jù)庫(kù)。
更豐富的功能：隨著 Lindorm 承載業(yè)務(wù)的多元化，Lindorm 面對(duì)的業(yè)務(wù)場(chǎng)景也越來(lái)越復(fù)雜，面對(duì)這些業(yè)務(wù)給Lindorm 帶來(lái)的挑戰(zhàn)，我們必須不斷去豐富 Lindorm 的功能去滿足這些客戶的需求。比如說(shuō)我們會(huì)實(shí)現(xiàn) Blob 存儲(chǔ)解決 Lindorm 之前寬表模型在大 kv 存儲(chǔ)場(chǎng)景性能不佳的問(wèn)題，引入 bitmap 類型滿足用戶畫像，人群圈選等場(chǎng)景。支持表快照以滿足用戶一體化查詢分析的需求。
更強(qiáng)的彈性能力：Lindorm 存儲(chǔ)分離的架構(gòu)加上云基礎(chǔ)設(shè)施的靈活性已經(jīng)給 Lindorm 帶來(lái)了非常強(qiáng)的彈性能力，在線擴(kuò)縮容和升降配能力已經(jīng)能滿足大部分用戶需求，但是受限于 ECS 的啟停速度，云盤的擴(kuò)縮容限制，Lindorm 彈性能力并沒(méi)有達(dá)到我們心中“秒級(jí)”的標(biāo)準(zhǔn)。因此，Lindorm 在構(gòu)架新一代部署架構(gòu)，希望利用大存儲(chǔ)池，借助 ECI和 ACK 的力量，真正實(shí)現(xiàn)秒級(jí)的彈性能力。
另外，我在這里預(yù)告一下，Lindorm 寬表引擎即將開源，開源能夠?qū)?Lindorm 寬表的技術(shù)積累推廣到業(yè)界，讓更多人能使用到 Lindorm 先進(jìn)的技術(shù)。我們也希望能夠通過(guò)開源的方式，去吸引更多的人來(lái)共建 Lindorm，發(fā)展技術(shù)。Lindorm 即將邁入一個(gè)開源的新時(shí)代，但是 Lindorm 寬表的初心一直沒(méi)變：致力于做最好的寬表數(shù)據(jù)庫(kù)產(chǎn)品，歡迎對(duì)技術(shù)感興趣的各位通過(guò)開源的方式一起參與進(jìn)來(lái)。
結(jié)束語(yǔ)
梅花香自苦寒來(lái)，寶劍鋒從磨礪出，Lindorm 每一個(gè)功能研發(fā)方向都來(lái)自于業(yè)務(wù)真實(shí)的需求輸入，你們的理解和信任是我們不斷前進(jìn)的動(dòng)力，沒(méi)有你們的陪伴和支持，就沒(méi)有 Lindorm 今天的成果。感謝所有幫助、支持、信任、鼓勵(lì)、鞭策過(guò)我們的同學(xué)。我們一定努力做最好的大數(shù)據(jù) NoSQL 產(chǎn)品，眾志成城、不忘初心、砥礪前行！
原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?
總結(jié)
以上是生活随笔為你收集整理的双11特刊｜十年磨一剑，云原生多模数据库Lindorm 2021双11总结的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： V8 编译浅谈
- 下一篇： PostgreSQL数据目录深度揭秘