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