阿裡雲資料庫已連續多年穩定支撐天貓雙11，曆經極端流量場景淬煉。除了保障穩定順阿滑的基本盤，今年大促期間資料庫通過全面雲原生化，大幅提升使用者體驗，讓技術幫助業務産生更有價值的消費者體驗，持續通過技術創新賦能使用者，引領技術發展路徑。
雙11已圓滿落幕，但技術的探索，仍未止步。“阿裡雲資料庫” 公衆号特此推出《好科技的新起點——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 自研了一套分布式限流體系，其具有以下獨特之處：
- 使用 Quota 作為限流機關，使用者請求需要處理的資料量越多，消耗 Quota 越多，是以對比 QPS，Quota 更能真實反映請求對系統産生的壓力
- 中心式 QuotaCenter 統一管理 Quota 消耗，即使使用者的流量在機器上分布不均勻也能夠正常執行限流邏輯
- Quota 消耗由 QuotaProxy 異步定期彙報，QuotaCenter 不會成為系統的單點，QuotaCenter 的壓力與使用者請求量無關
- 使用者請求過程中不直接與 QuotaCenter 互動，每次請求隻會檢查 QuotaProxy 本地緩存的資訊，不影響使用者的請求響應時間
- 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 寬表的初心一直沒變：緻力于做最好的寬表資料庫産品，歡迎對技術感興趣的各位通過開源的方式一起參與進來。
6
結束語
梅花香自苦寒來，寶劍鋒從磨砺出，Lindorm 每一個功能研發方向都來自于業務真實的需求輸入，你們的了解和信任是我們不斷前進的動力，沒有你們的陪伴和支援，就沒有 Lindorm 今天的成果。感謝所有幫助、支援、信任、鼓勵、鞭策過我們的同學。我們一定努力做最好的大資料 NoSQL 産品，衆志成城、不忘初心、砥砺前行！
如果您對Lindorm有任何問題，歡迎釘釘掃碼加入“Lindorm技術交流群”，或搜尋群号：35977898加入群組。