用戶福利

阿里雲最新發布業界首款雲原生多模數據庫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 數據庫全文搜索方案