存的起，看得見—雲原生多模資料庫Lindorm技術解析

使用者福利

阿裡雲最新釋出業界首款雲原生多模資料庫Lindorm，幫助企業一站式存儲處理海量資料，降低80%成本，技術交流釘釘群：35977898，更多内容請

參考連結

一、背景

作為面向大資料場景的半結構化、結構化存儲系統，Lindorm已經在阿裡發展了近十年，并始終保持着快速的能力更新和技術更新，是目前支撐阿裡經濟體業務的核心資料庫産品之一。在過去的歲月，伴随着經濟體内部對于海量結構資料存儲處理的需求牽引，其在功能、性能、穩定性等方面的諸多創新曆經了長時間的大規模實踐考驗，被全面應用于阿裡集團、螞蟻集團、菜鳥、大文娛等各個業務闆塊，成為目前為止公司内部資料體量最大、覆寫業務最廣的資料庫産品。

與此同時，面對技術商業化、集團雲化的推進，我們看到了更多百花齊放的應用資料需求和開放生态，以及Lindorm在此過程中的問題與挑戰。如何适應雲原生、5G/IoT時代的發展趨勢，如何解決一套産品同時服務好内外客戶，讓以内養外成為産品商業化的競争力源泉，是Lindorm在過去一年的主要思考和發展方向，希望通過本文向大家做一個綜合介紹，分享我們過去面臨的問題挑戰、解決思路及Lindorm的新定位、新演進，文章有點長，感謝大家的閱讀和建議。

二、問題與挑戰

2.1 多樣化的資料需求

Lindorm的架構起源于Bigtable，其核心是LSM引擎+存儲計算分離，并融入了類CosmosDB的多副本多一緻性設計和二級索引、資料Schema等能力，适合于網際網路通用場景的海量半結構、結構化資料的線上存儲與簡單處理。

然而，現代應用場景的玩法和功能越來越豐富，除了高擴充、低延時、高可用、低成本等核心需求之外，簡單分析、多元檢索等進階資料處理正在成為越來越多應用的基本需求。為此，我們看到lindorm之上的使用者，通常會有兩個選擇：

1. a) 直接基于Lindorm進行資料檢索或分析，通過系統本身的擴充并發能力，來保障處理效率滿足應用需求。這種方式最大的優點是使用簡單、開發便捷，但不可避免在規模和成本制約下，會存在瓶頸；
2. b) 通過資料通道，部分資料轉存到搜尋系統(如ES、Solr等)，滿足多元檢索的需求；部分資料轉到OLAP或數倉系統，滿足統計分析的需求。這種方式最大的優點，是集合各個系統的優勢能力，在擴充性上可以支撐很大的業務規模，但不可避免帶來維護的複雜和資料的備援。并且，對于異構系統之間的資料模型差異和一緻性問題，通常需要業務層做針對性處理，再加上多套系統的學習了解，使得應用開發成本大幅升高，讓中小規模企業的使用者群體望而卻步。

除了通用資料處理需求的多樣化之外，在部分垂直場景下，業務期待專用的資料處理能力，使得在開發效率、運作成本等方面能有數量級的提升，以應對更大規模的資料增長。比如，在監控場景，公司内部的監控系統大部分都基于lindorm進行建構，應用期望将名額資料的降采樣、預聚合、預測分析等常見能力可以下沉到資料庫系統，是以，TSDB、OpenTSDB、InfluxDB等時序資料庫應運而生，專注于解決如Metric名額的時序資料存儲問題，大幅提升了監控/IoT場景中的裝置時序資料處理能力。但是，應用也面臨着新的煩惱，專用時序資料庫的引入，提升了名額Metric資料的處理能力，但并不能去除系統中的其他資料庫，如Log、Tracing、裝置中繼資料庫等通用資料仍需要存儲在Lindorm中，部分場景可能還需要引入搜尋系統來加速查詢，系統的架構和維護變得越來越複雜。

類似情景還有不少，比如社交場景的消息推送、内容存儲、聊天搜尋等，遊戲場景的道具、聊天、關系、錄像等存儲，廣告場景的畫像、點選日志、物料等存儲，這些資料的多樣化需求帶動了多類型的存儲系統的發展，在面對複雜場景時，相比于傳統的單一存儲選型，基于多套系統的存儲解決方案大幅提升了系統的運作效率。但為此所付出的是，複雜資料庫組合選型以及多系統架構維護下的業務時間成本和人力成本，我們不禁想問，下一站的架構該是什麼？

2.2 業務流量的不可預測

網際網路場景中業務流量的快速變化和不可預測是資料庫維護者一直以來的痛點，在過去的日子裡，我們面對的生産穩定性問題，很多是可以擴容解決的，但由于成本的限制，又不得不限制容量，使得成本與穩定性這兩個問題被耦合在一起。這種計劃式的資源管理模式，不僅浪費大量時間精力去進行容量規劃預測、資源排程搬遷等工作，也無法保障資源的充分利用，更時刻承受着資源不足導緻問題的穩定性風險。

雲計算的興起，喚醒了業務對于資源按需即時擷取的強烈需求，彈性能力(差別于擴充性)也成為雲上開發者對于雲産品的預設了解，Lindorm需要重新思考這個方向的解決思路和挑戰，我們期望在不久的某一天，大家不用再時刻擔心容量水位，隻需要異步地去統計和控制資源使用量，讓資源使用率提升和系統穩定性風險成為兩個互相獨立的問題。

2.3 面向成本的存儲碎片化

資料驅動是網際網路業務的基礎特征，通過資料進行拉新、推廣、統計等幾乎是所有應用的正常需求，讓我們看到了資料給業務帶來的價值，但另一方面，業務資料化過程中依賴的海量資料的存儲成本，使得業務不得不仔細權衡資料維護的經濟效益。如何降低資料的機關存儲成本，是過去所有資料化應用都在考慮的核心問題，并逐漸形成了冷溫熱的多系統異構混合方案。比如，常見的是熱資料存于MySQL，溫資料存于HBase，全量冷資料歸檔到對象存儲OSS或數倉中，由此産生的資料同步、查詢維護、生命周期管理、冷熱資料的業務差異化等給所有應用帶來了很大的痛苦。

低成本存儲是使用者選擇Lindorm的重要因素，也是持續不斷的要求，但我們在過去也看到了部分業務因成本壓力而分拆極冷資料轉存OSS的應用複雜改造，甚至是業務側自身的結構化資料編碼壓縮和緩存加速等，給系統維護和資料正確定障帶來了複雜的挑戰。這種因資料價值差異産生的異構化資料存儲是一種通用的訴求，如何原生解決好這個問題，不讓使用者在低成本和複雜之間做糾結的選擇，是Lindorm面對成本訴求的一個重要挑戰。

2.4 開放的标準接口

從去年開始，Lindorm以"HBase企業增強版"的方式服務于阿裡雲上的企業客戶，憑借其多年内部實踐沉澱出的性能、成本、穩定性等企業級優勢，快速形成了阿裡雲HBase産品與友商、開源自建的差異化競争力。通過相容開源标準接口，使得Lindorm快速切入商業化，但同時也面臨着能力被限制的瓶頸，比如使用者無法很好用到Lindorm的二級索引、多一緻性、資料Schema等能力，使得整體産品的能力定位和市場規模很大程度上取決于開源的發展，而Hadoop和HBase社群這幾年處于較為明顯的下坡趨勢，我們需要一個相對獨立的發展思路和市場方向，來解決開源紅利變現後期的市場挑戰。

但這并不意味着，我們要去推出Lindorm在公司内部使用的私有标準接口。相反，存量業務上雲仍然是很長一段時間内的主節奏，應用平滑遷移是上雲過程中的核心訴求，私有标準無疑于背離市場。是以，如何包容更多的開放标準接口，如何無縫對接開放技術生态，如何兼顧内部使用的私有标準，是Lindorm自研技術商業化過程面臨的又一大挑戰。

三、趨勢與思路

3.1 融合的多模資料管理

随着業務的多樣化，應用對于資料的多類型處理能力提出了新的要求，而傳統多套系統組合解決方案又有架構複雜、維護成本、起步門檻高等痛點，使得使用者對于資料庫系統提供Multi-model能力的訴求越來越明顯。同時，Multi-model也作為一個技術趨勢熱詞，頻繁出現在近幾年的Gartner等前沿報告中。通過db-engines網站，我們可以看到已經有大量流行的資料庫系統打上了Multi-model的能力标簽，反映了各個廠商和市場在此領域的實質性響應。

雖然大家普遍認為支援多模型是資料庫，尤其是NoSQL資料庫的重要趨勢，但是對其具體的技術了解和實施卻不盡相同。大部分系統基于通用KV/Table模型，建構出更多的垂直模型，如HBase基礎之上的OpenTSDB，進而在資料庫開發與運作效率之間取得一個折中，但受限于資料引擎的唯一性，無法在各個垂直場景取得最佳效率，是以無法從本質上替換多套系統組合的解決方案，更多是去減緩使用。還有部分雲廠商的産品，在資料庫平台和産品宣傳側形成統一，而在應用開發側，各個模型獨立資源、獨立部署、獨立使用，更多是一種對多套系統組合方案的體驗優化。

與現有多模資料庫的部分解決不同，Lindorm希望通過多模能力的建構，即滿足應用資料的多樣化處理需求，又擁有簡單統一的應用開發體驗，還具備垂直場景的高效運作效率，進而真正釋放使用者所需要的多模優勢。與傳統分庫分表方案更新到分布式資料庫内置Sharding能力相似，Lindorm希望将應用在面對多套系統組合方案中的複雜資料處理下沉到資料庫，如多模資料同步、多模關聯查詢、統一讀寫接口等，并提供簡單、高效、穩定的一體化多模能力。

Lindorm期望探索和實踐一種真正的多模原生的資料庫，基于融合的多模資料管理思想，面向使用者提供統一的産品體驗、統一的資料存儲、統一的查詢通路、統一的系統架構、統一的資料交換，内置垂直專用的資料引擎，猶如内置CPU、GPU、 NPU等多處理器的計算機，取得高效、簡單的雙赢。

3.2 雲原生

在過去幾年，雲原生技術和理念得到了廣泛接受和快速發展，雖然相關定義更新很快和對其了解也不盡相同，但從開發者角度而言，雲原生是一種最大化享受雲計算紅利的技術理念，包括但不限于彈性伸縮、按量付費、開放标準、Serverless化等能力，将推動軟體重塑生命周期。

Lindorm的未來是全面擁抱雲原生，逐漸從建構于傳統IT架構環境，走向雲基礎設施；從整租式的資料庫服務，走向彈性按需使用；從阿裡私有協定接口，走向業界開放标準生态。通過集團雲原生上雲戰役，全面完成一套産品同時服務好内外客戶，重點打造以下能力：

1. a) Serverless，Serverless是展現雲計算的按需使用、極緻彈性的最好表現形式，使用者可以通聲明式API定義對資料庫資源的要求，包括可用性、延遲、一緻性、部署位置等，并且不再需要為不确定的業務流量去評估存儲、請求等資源，完全收斂精力到業務的開發，加速資料應用創新。實作真正的資料庫Serverless能力的核心關鍵是隔離和排程，前者需要解決共享資源下的穩定性問題，確定租戶之間不會産生影響；後者需要解決資源的按需供應和高效利用，確定叢集負載均衡，并能根據業務流量快速彈性伸縮。
2. b) IaaS雲化，通過雲基礎設施的共池資源，不僅可以解決庫存與成本的問題，免除基礎IaaS的維護開銷，為彈性Serverless提供關聯的實體資源；同時，其永不下線和按需取用的特點，也将促使軟體架構進化，打破節點當機不可恢複和資源固定的假設，借助于可擴容、可重新開機的外力，軟體的穩定性體系建設将擁有更多的手段和政策。最後，雲上豐富的基礎資源形态，如多類型算力(CPU/GPU/FPGA)、多樣化存儲(ESSD/高效雲盤/OSS)，使得Lindorm針對資料的存儲處理可以更加多元化，比如冷熱分層、Compaction Offload等。
3. c) 開放标準，資料庫領域的标準接口主要是兩類，一類是開源資料庫的事實标準，另一個就是通用的SQL标準。Lindorm将同時提供兩種方式，即承載好外部存量業務的平滑遷移，也具備差異化能力的輸出視窗。
4. d) 智能化，雖然智能與雲原生是兩個平行的詞，但智能是實作雲原生技術理念的重要手段，彈性伸縮、無人運維、按需使用、低成本等能力的建設都離不開智能化，比如基于流量的統計分析和預測，做更加準确的資源排程，進而提供更好的彈性；比如資料冷熱的智能識别，進而分離存儲降低成本；比如通過智能診斷、智能索引，大幅提升系統自我穩定性，減少運維投入。是以，雲原生的Lindorm，一定是内置智能。

3.3 冷熱資料一體化存儲

面對資料價值的差異化和海量資料的存儲成本壓力，冷熱分離是過去時間裡業界解決此問題的主要思路，雖然在各個系統和解決方案中的實施各有差異和不足，但我們看到了業務對于冷熱資料底層分離和上層統一的思想認可和強烈需求，使用者希望獲得一種理論可行的最低存儲成本，而無需擔心冷熱的界定和雙向轉換、冷資料的查詢降級、一緻性語義等問題。

Lindorm期望原生提供冷熱資料的一體化存儲，并確定冷資料存儲成本達到業界最低标準，讓業務不再疲于資料的搬挪騰轉，重點建構以下能力：

1. a) 統一讀寫通路，冷熱溫資料的差異隻存在于存儲側，而在與業務對接的查詢寫入側保持一緻。不同資料之間擁有不同的性能和成本，但擁有相同的資料視圖和功能，進而使得終端使用者保持一緻的資料體驗。
2. b) 冷熱自動識别，對于随着時間流逝、資料逐漸由熱轉冷的常見場景，系統将根據實體時間點自動識别和分離冷熱資料；對于沒有時間屬性的場景，系統将借助于機器學習，判斷資料的冷熱特征和通路預測。無論哪種方式，資料的冷熱轉換都是雙向的，進而比對業務的靈活變化。
3. c) 冷熱異構處理，針對冷資料系統将使用更高壓縮比的算法、更低成本的存儲媒體和更加懶惰的資料清理政策等，使得冷資料的綜合存儲成本僅有1/10以下。
4. d) 自由的冷存儲媒體，如何建構極低成本的冷存儲是一件需要軟硬體+機房設施協同的大工程，而這并不是Lindorm的重心方向，是以在具體的冷存儲媒體上，我們Lindorm選擇聚焦于此的OSS存儲(在部分環境受限的場景，則繼續使用傳統的HDD磁盤），并結合面向資料結構的高壓縮、資料緩存、生命周期管理等，其整體性能、成本會遠優于業務直存OSS。
5. e) 冷溫熱多層，雖然冷熱是大部分業務對資料的快速分離政策，但也存在冷、溫、熱、極速等更多層次的需求，系統支援使用者定義多層存儲和異構處理方式，進一步滿足業務的靈活性。

3.4 引擎垂直化

在上文中，我們提到基于通用KV引擎建構多模的解決方案，這是一種快速實作多模能力的擴充方式，但卻是一種相對中間的狀态。面向表、時序、時空、圖等各個垂直場景，其資料的特點和應用需求差異明顯，比如對于時序場景，資料生而自帶時間屬性，并且沿着時間線生成新資料，是以通過時間次元進行資料分區的方式就顯得非常簡單高效，并且資料的組織設計也可以去比對這些特點。目前時序和圖資料庫的Top1産品(InfluxDB、Neo4j)都是運用了時序原生引擎、圖原生引擎的思想，來打造各自在垂直領域的技術優勢，我們也認為這是垂直模型被規模化應用的趨勢選擇。

除了多模混合場景之外，在面對垂直場景的獨立資料存儲與處理時，Lindorm期望具備不亞于任何專用資料庫的能力，是以，多模型的Lindorm，選擇引擎垂直化的架構，進而使得各個資料引擎均擁有優秀的可創新性和靈活性，在專用場景也保持技術競争力。

四、雲原生多模資料庫Lindorm

面對多模資料管理的應用需求和雲原生的技術趨勢，着眼于集團雲原生戰略、5G/IoT時代的未來發展，我們正式更新

Lindorm為雲原生多模資料庫

，融合原Lindorm和TSDB過去的技術積累，支援多類型、任意規模資料的低成本存儲處理和自适應彈性伸縮，服務于網際網路、IoT、車聯網、廣告、社交、監控、遊戲、風控等場景。

新Lindorm将重點圍繞雲原生、多模型、低成本持續打造海量資料存儲處理場景的競争力，并通過集團雲原生上雲戰役，實作一套産品同時服務好内外客戶，提供更穩定、更高效、更經濟的基礎資料庫服務，在以下能力獲得新的飛躍：

4.1 融合多模

系統支援寬表、時序、搜尋、檔案四種模型，提供統一聯合查詢和獨立開源接口兩種方式，模型之間資料互融互通，幫助應用開發更加靈活、靈活、高效。多模型的核心能力由四大資料引擎提供，包括：

寬表引擎，面向海量KV、表格資料，具備全局二級索引、多元檢索、動态列、TTL等能力，适用于中繼資料、訂單、賬單、畫像、社交、feed流、日志等場景，相容HBase、Phoenix(SQL)、Cassandra(CQL)等開源标準接口。

時序引擎，面向IoT、監控等場景存儲和處理量測資料、裝置運作資料等時序資料。提供HTTP API接口(相容OpenTSDB API)、支援SQL查詢。針對時序資料設計的壓縮算法，壓縮率最高為15:1。支援海量資料的多元查詢和聚合計算，支援降采樣和預聚合。

搜尋引擎，面向海量文本、文檔資料，具備全文檢索、聚合計算、複雜多元查詢等能力，同時可無縫作為寬表、時序引擎的索引存儲，加速檢索查詢，适用于日志、賬單、畫像等場景，相容開源Solr标準接口。

檔案引擎，提供共享存儲底座的服務化通路能力，進而加速多模引擎底層資料檔案的導入導出及計算分析效率，相容開源HDFS标準接口

對于目前使用類HBase+ElasticSearch或HBase+OpenTSDB+ES的應用場景，比如監控、社交、廣告等，利用Lindorm的原生多模能力，将很好地解決架構複雜、查詢痛苦、一緻性弱、成本高、功能不對齊等痛點，讓業務創新更高效。

4.2 雲原生彈性

Lindorm基于存儲計算分離的架構，支援計算資源、存儲資源的獨立彈性伸縮，并将全新提供Serverless服務，實作按需即時彈性、按使用量付費的能力。Lindorm Serverless基于多租戶隔離、智能排程、彈性IaaS底座建構，具備企業級SLA保障，滿足内部大部分業務的可用性要求，進而讓一線同學大幅降低容量管理的運維負擔，消除因流量波動導緻的穩定性風險。

面對網際網路場景的持續波動和不可預測的業務流量，彈性是Lindorm渴望已久的能力，也将是未來持續重點聚焦的方向。

4.3 極緻成本效益

Lindorm面向海量資料場景而生，低成本是業務的普遍需求和産品的持續追求。在存儲上，将新上線三大核心能力：

1. a) 支援透明存儲到低成本媒體，目前預設為OSS标準型，後續将支援低頻型、歸檔型。同時，系統内置緩沖加速層，讓查詢實時性仍有較大的保障，适合讀并發不大的資料；
2. b) 支援智能冷熱分離，針對資料随着時間線逐漸熱變冷的場景，典型如監控、社交聊天、交易賬單等，Lindorm内部将自動識别資料的冷熱，并進行分離存儲到高性能媒體和低成本媒體(兩者之間的單價成本差可高達10:1)，而使用者讀寫通路保持完全透明，并且熱資料的通路性能還能有所加速。

3. c) 支援自适應壓縮，針對資料的不同類型和特點，系統将自動選擇混合的字典、字首、Delta、熵編碼等壓縮算法，相比業界通用算法，整體壓縮率提升10%~30%。

   在性能上，Lindorm寬表引擎在吞吐延遲上做了非常多的突破，其基準性能是開源HBase的7倍(

   參考報告 )；Lindorm時序引擎面向資料天然順序寫入和近線通路的特點，融入了許多創新型的高性能結構設計，其基準性能在目前的信通院榜單中處于第一的位置，大幅領先于其他專用時序資料庫。

4.4 豐富檢索

資料的多條件查詢檢索正在成為越來越多應用的基本需求，新Lindorm将大幅增強索引能力，滿足面向海量資料的快速查詢檢索需求，提供

全局二級索引

(支援全局分布式、強一緻、按需索引和備援等特性，完美相容Schemaless模型，并可以自動利用索引加速非主鍵查詢)、

全文檢索

(通過反向索引的方式，支援多條件随機組合查詢，應用側透明查詢，自動索引優化)、全文索引(支援分詞、搜尋、排序等)、時序索引(支援時序資料的高效查詢、聚合)等功能。

4.5 智能化服務

面向服務自助化、運維智能化、營運資料化的目标，Lindorm全新LDInsight工具，具備資訊透視、系統管理、智能診斷等功能，幫助應用開發者/DBA輕松掌握系統運作狀态，白屏化完成常見系統管理和資料通路操作，以及自動診斷使用過程中的常見問題，比如慢請求、熱點、性能診斷、Schema設計、索引推薦等，讓使用者和維護者更加簡單、高效地使用Lindorm，減少服務對人的依賴。

4.6 開放資料生态

作為資料全域處理的一環，如何與關系資料庫、批流計算平台、日志采集平台等系統無縫打通和一體化使用是Lindorm重點建設的方向。新Lindorm原生提供LTS(Lindorm Tunnel Service，原BDS)，支援簡單易用的資料交換、處理、訂閱等能力，滿足使用者的資料遷移、實時訂閱、數湖轉存、數倉回流、單元化多活、備份恢複等需求，實作面向Lindorm的一站式資料生态服務。

除此之外，Lindorm将繼續完善多一緻性、跨機房容災、擴充性、穩定性等能力，成為雲計算時代的"大多數選擇"。

五、架構解析

Lindorm系統基于存儲計算分離架構設計，以适應雲計算時代資源解耦和彈性伸縮的訴求。其中雲原生存儲引擎LindormStore為統一的存儲底座，向上建構各個垂直專用的多模引擎，包括寬表引擎、時序引擎、搜尋引擎、檔案引擎。在多模引擎之上，Lindorm既提供統一的SQL通路，支援跨模型的聯合查詢，又提供多個開源标準接口(HBase/Phoenix/Cassandra、OpenTSDB、Solr、HDFS)，滿足存量業務無縫遷移的需求。最後，統一的資料Stream總線負責引擎之間的資料流轉和資料變更的實時捕獲，以實作資料遷移、實時訂閱、數湖轉存、數倉回流、單元化多活、備份恢複等能力。下文，我們将對各個元件的關鍵技術和能力做一個簡單介紹。

5.1 存儲引擎

LindormStore是面向公共雲基礎存儲設施(如雲盤、DBFS、OSS)設計、相容HDFS協定的分布式存儲系統，并同時支援運作在本地盤環境，以滿足部分專有雲、專屬大客戶的需求，向多模引擎和外部計算系統提供統一的、與環境無關的标準接口，其整體架構如下：

LindormStore支援四種軟體定義的存儲資源形态，分别滿足不同場景下的性能與成本差異需求：

1. a) 性能型，通過 DBFS 的共享存儲技術，一塊雲盤可以被挂載到多個ECS節點，并同時讀寫雲盤上的資料，進而在ECS節點當機時，保障資料的高可用通路。相比基于普通雲盤叢集的至少存儲6個副本(雲盤本身底下是3副本，基于雲盤部署的分布式存儲系統仍然需要設定2副本)，資料的總副本數可以減少50%，有效消除上雲之後的存儲膨脹問題。但受限于DBFS的設計，其本身并不是無限擴充的，單個DBFS的磁盤空間、IOPS、可挂載節點數存在上限，并且由于分布式鎖與通信的關系，共享挂載節點數越少則性能越好。是以，LindormStore負責将多個DBFS融合，重點解決檔案分塊、資料塊配置設定及共享、均衡排程等問題，形成統一目錄的、無限擴充的分布式存儲，提供HDFS協定的資料服務。基于此技術，采用ESSD作為媒體，Lindorm對外向使用者提供性能型存儲形态。
2. b) 标準型，整體技術方案與性能型一緻，其存儲媒體采用高效雲盤。
3. c) 容量型，針對海量資料低成本存儲的訴求，我們通過分布式Buffer+OSS的方式，建構了彈性、低成本的容量型存儲形态。其核心思想是資料同步寫入到分布式Buffer層，然後異步遷移到OSS存儲，可按需設定一定的讀緩存。分布式Buffer層可以保障資料的持久化和可靠性，并具備Log Sync語義，是以其寫入能力與性能型/标準型一緻，特别适合海量資料下的低成本存儲、高吞吐寫入、弱查詢要求的場景需求。

4. d) 本地型，針對部分無法提供雲基礎存儲設施的環境，LindormStore也支援基于本地盤建構，通過資料的三副本機制保障資料的高可靠，适合于專有雲、輕量化輸出場景。

   面對真實場景的資料冷熱特點，LindormStore支援性能型/标準型、容量型多種存儲混合使用的形态，結合多模引擎的冷熱分離能力，以及雲基礎存儲OSS/DBFS的按需彈性特點，實作冷熱存儲空間的自由配比，讓使用者的海量資料進一步享受雲計算的低成本紅利。

5.2 寬表引擎

LindormTable是面向海量半結構化、結構化資料設計的分布式NoSQL系統，相容HBase、Phoenix(SQL)、Cassandra等開源标準接口。其基于資料自動分區+分區多副本+LSM的架構思想，具備全局二級索引、多元檢索、動态列、TTL等查詢處理能力，支援單表百萬億行規模、千萬級并發、毫秒級響應、跨機房強一緻容災等，高效滿足業務大規模資料的線上存儲與查詢需求，整體架構如下：

LindormTable的資料持久化存儲在LindormStore中，表的資料通過自動Sharding分散到叢集中的多台伺服器上，并且每一個Parition可以擁有1至N個副本，這N個副本擁有主、從兩種角色，主從副本可以加載在不同的Zone，進而保障叢集的高可用和強一緻。針對不同的一緻性模式，主從副本之間的資料同步和讀寫模式如下：

1. a) 強一緻模式，隻有主副本提供讀寫，資料會異步回放到從副本,主副本所在節點故障，從副本晉升為主(晉升之前會保障資料同步完成，從副本擁有所有最新資料，整體過程由Master協調負責)
2. b) 最終一緻模式，主從副本都提供讀寫，資料會互相同步，保證副本之間的資料最終一緻。

LindormTable的多副本架構基于PACELC理念設計，每一個資料表都支援單獨支援設定一緻性模式，進而擁有不同的可用性和性能。在最終一緻模式下，服務端會對每一個讀寫請求在一定條件下觸發多副本并發通路，進而大幅提升請求的成功率和減少響應毛刺。該并發機制建立在内部的異步通路架構上，相比于啟動多線程，額外資源消耗可以忽略不計。對于并發通路的觸發條件，主要包括兩個類型：其一是限時觸發，對于每一個請求，都可以單獨設定一個GlitchTimeout，當請求運作時間超過該值未得到響應後，則并發一個請求到其他N-1個副本，最終取最快的那個響應；其二是黑名單規避，服務端内部會基于逾時、抛錯、檢測等機制，主動拉黑存在慢、Hang、死等問題的副本，使得請求能夠主動繞開受軟硬體缺陷的節點，讓服務最大可能保持平滑。對于像掉電Kill這樣的Hang死場景，在節點不可服務至失去網絡心跳往往會存在一兩分鐘的延遲，利用LindormTable的這種多副本協同設計，可以将影響控制在10秒以内，大幅提升服務的可用性。

LindormTable的LSM結構面向冷熱分離設計，支援使用者的資料表在引擎内自動進行冷熱分層，并保持透明查詢，其底層結合LindormStore的冷熱存儲混合管理能力，大幅降低海量資料的總體存儲成本。

LindormTable提供的資料模型是一種支援類型的松散表結構。相比于傳統關系模型，LindormTable除了支援預定義字段類型外，還可以随時動态添加列，而無需提前發起DDL變更，以适應大資料靈活多變的特點。同時，LindormTable支援全局二級索引、反向索引，系統會自動根據查詢條件選擇最合适的索引，加速條件組合查詢，特别适合如畫像、賬單場景海量資料的查詢需求。

5.3 時序引擎

LindormTS是面向海量時序資料設計的分布式時序引擎，相容開源OpenTSDB标準接口，其基于時序資料特點和查詢方式，采用Timerange+hash結合的分區算法，時序專向優化的LSM架構和檔案結構，支援海量時序資料的低成本存儲、預降采樣、聚合計算、高可用容災等，高效滿足IoT/監控等場景的測量資料、裝置運作資料的存儲處理需求，整體架構如下：

TSCore是時序引擎中負責資料組織的核心部分，其整體思想與LSM結構相似，資料先寫入Memchunk，然後Flush到磁盤，但由于時序資料天然的順序寫入特征，定向專用的時序檔案TSFile的結構設計為以時間視窗進行切片，資料在實體和邏輯上均按時間分層，進而大幅減少Compaction的IO放大，并使得資料的TTL、冷熱分離等實作非常高效。

TSCompute是負責時序資料實時計算的元件，重點解決監控領域常見的降采樣轉換、時間線聚合、時序值預測等需求，其通過Lindorm Stream進行資料訂閱，并完全基于記憶體計算，是以，整體非常的輕量、高效，适合系統已預置的計算功能。針對部分靈活複雜的分析需求，使用者仍可以通過對接Spark、Flink等系統實作，進而支撐更多場景和适應業務變化。

5.4 搜尋引擎

LindormSearch是面向海量資料設計的分布式搜尋引擎，相容開源Solr标準接口，同時可無縫作為寬表、時序引擎的索引存儲，加速檢索查詢。其整體架構與寬表引擎一緻，基于資料自動分區+分區多副本+Lucene的結構設計，具備全文檢索、聚合計算、複雜多元查詢等能力，支援水準擴充、一寫多讀、跨機房容災、TTL等，滿足海量資料下的高效檢索需求，具體如下：

LindormSearch的資料持久化存儲在LindormStore中，通過自動Sharding的方式分散到多台SearchServer中，每一個分片擁有多個副本，支援一寫多讀，提升查詢聚合的效率，同時這些副本之間共享存儲，有效消除副本之間的存儲備援。

在Lindorm系統中，LindormSearch既可以作為一種獨立的模型，提供半結構化、非結構化資料的松散文檔視圖，适用于日志資料分析、内容全文檢索；也可以作為寬表引擎、時序引擎的索引存儲，對使用者保持透明，即寬表/時序中的部分字段通過内部的資料鍊路自動同步搜尋引擎，而資料的模型及讀寫通路對使用者保持統一，使用者無需關心搜尋引擎的存在，跨引擎之間的資料關聯、一緻性、查詢聚合、生命周期等工作全部由系統内部協同處理，用簡單透明的方式發揮多模融合的價值。

5.5 檔案引擎

LFS是基于LindormStore輕量封裝的分布式檔案模型服務，其核心是提供安全認證、限流保護、多網絡通路等服務化能力，進而使得外部系統可以直接通路多模引擎的底層檔案，大幅提升備份歸檔、計算分析等場景的效率。同時，使用者可以在離線計算系統直接生成底層資料格式的實體檔案，通過LFS入口，将其快速導入到LindormStore中，以減少對線上服務的影響。對于部分存儲計算的混合場景，使用者可以将計算前的源檔案存在LFS，計算後的資料結果存在LindormTable，結合Spark/DLA等大規模計算引擎，實作簡單高效的資料湖分析能力。

六、總結展望

從網際網路&大資料時代的分布式，到雲計算、5G/IoT時代的雲原生多模，業務驅動是Lindorm不變的演進原則。面對資源按需彈性和資料多樣化處理的新時代需求，Lindorm以統一存儲、統一查詢、多模引擎的架構進行全新更新，并借助雲基礎設施紅利，重點發揮雲原生彈性、多模融合處理、極緻成本效益、企業級穩定性的優勢能力，全力承載好經濟體内部和企業客戶的海量資料存儲處理需求。下一步，我們将在多模融合查詢、Serverless隔離排程、低成本海量存儲、實時Stream、智能化等技術方向持續重點突破，向着“讓企業資料存得起，看得見”的使命，全力以赴，做到最好。

七、最後: 使用Lindorm

雲原生多模資料庫Lindorm已在阿裡雲正式釋出，歡迎大家關注和使用，技術交流釘釘群：35977898

如果你目前業務架構中，有用到hbase、phoenix、cassandra、hdfs、solr等資料庫，那都可以考慮無縫更新到Lindorm，幫助業務享受雲原生的紅利。

7.1 基于Lindorm的HDFS上雲解決方案

7.2 資料庫全文搜尋方案