​前言

2021 年，轉眼 Lindorm 已經在阿里發展了十年的時間，從基於 HBase 深度改造的 Lindorm 1.0 版本，到全面重構，架構大幅升級的 Lindorm 2.0 版本；從單一的寬表引擎，到支援搜尋、時序、檔案等多種結構化資料處理的多模引擎，Lindorm 始終保持著快速迭代和升級的速度，以滿足阿里集團各類業務的資料儲存需求。目前，Lindorm是公司內部資料體量最大，覆蓋業務最廣的資料庫產品之一。

去年，在讓廣大使用者看得見、存得起的理念下，Lindorm 再次做了品牌升級，率先提出了多模超融合資料庫概念。Lindorm 不單單是寬表、時序、搜尋等引擎的簡單堆疊，而是在統一的分散式儲存引擎之上，各個引擎之間互通融合，並由統一的 SQL 入口來實現多模資料庫的統一訪問。

在 Lindorm 一個數據庫中，使用者就可以實現流式計算，寬表儲存，列式索引、時空索引、時序預測、資料訂閱，以及在各個模型上的複雜分析等多種功能。面對複雜多變的業務，以及百花齊放的應用，業務不需要面臨選型和運維多個複雜資料庫的難題，資料的整個生命週期都可以在Lindorm 內部各個元件中完成，滿足使用者寫入，查詢，分析，監控各種需求。

​

2021年雙11，Lindorm為手淘互動營銷、智慧風控、媒體大屏、生意參謀、花唄決策、消費記錄等核心系統保駕護航，提供叢集水位和狀態透傳產品化能力，業務可自行按需伸縮，提升備戰效率，業務支援成本降低80%。雲原生Serverless架構升級，大促資源按需彈性伸縮，資源管理效率提升10倍+

而作為 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 自研了一套分散式限流體系，其具有以下獨特之處：

1. 使用 Quota 作為限流單位，使用者請求需要處理的資料量越多，消耗 Quota 越多，因此對比 QPS，Quota 更能真實反映請求對系統產生的壓力
2. 中心式 QuotaCenter 統一管理 Quota 消耗，即使使用者的流量在機器上分佈不均勻也能夠正常執行限流邏輯
3. Quota 消耗由 QuotaProxy 非同步定期彙報，QuotaCenter 不會成為系統的單點，QuotaCenter 的壓力與使用者請求量無關
4. 使用者請求過程中不直接與 QuotaCenter 互動，每次請求只會檢查 QuotaProxy 本地快取的資訊，不影響使用者的請求響應時間
5. QuotaCenter 弱依賴，QuotaCenter 宕機，不會影響使用者請求

​

未來展望

我們抱著十年磨一劍的心態，從 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 產品，眾志成城、不忘初心、砥礪前行！

原文連結
本文為阿里雲原創內容，未經允許不得轉載。

​