深度乾貨 | 讓資料存得起 看得見，雲原生多模資料庫Lindorm技術解析

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

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

2.1 多樣化的資料需求

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

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

除了通用資料處理需求的多樣化之外，在部分垂直場景下，業務期待專用的資料處理能力，使得在開發效率、執行成本等方面能有數量級的提升，以應對更大規模的資料增長。比如，在監控場景，公司內部的監控系統大部分都基於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架構環境，走向雲基礎設施；從整租式的資料庫服務，走向彈性按需使用；從阿里私有協議介面，走向業界開放標準生態。透過集團雲原生上雲戰役，全面完成一套產品同時服務好內外客戶，重點打造以下能力：

3.3 冷熱資料一體化儲存

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

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

3.4 引擎垂直化

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

除了多模混合場景之外，在面對垂直場景的獨立資料儲存與處理時，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面向海量資料場景而生，低成本是業務的普遍需求和產品的持續追求。在儲存上，將新上線三大核心能力：

a) 支援透明儲存到低成本介質，目前預設為OSS標準型，後續將支援低頻型、歸檔型。同時，系統內建緩衝加速層，讓查詢實時性仍有較大的保障，適合讀併發不大的資料；

b) 支援智慧冷熱分離，針對資料隨著時間線逐漸熱變冷的場景，典型如監控、社交聊天、交易賬單等，Lindorm內部將自動識別資料的冷熱，並進行分離儲存到高效能介質和低成本介質（兩者之間的單價成本差可高達10:1），而使用者讀寫訪問保持完全透明，並且熱資料的訪問效能還能有所加速。

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支援四種軟體定義的儲存資源形態，分別滿足不同場景下的效能與成本差異需求：

a) 效能型，透過DBFS的共享儲存技術，一塊雲盤可以被掛載到多個ECS節點，並同時讀寫雲盤上的資料，從而在ECS節點當機時，保障資料的高可用訪問。相比基於普通雲盤叢集的至少儲存6個副本（雲盤本身底下是3副本，基於雲盤部署的分散式儲存系統仍然需要設定2副本），資料的總副本數可以減少50%，有效消除上雲之後的儲存膨脹問題。但受限於DBFS的設計，其本身並不是無限擴充套件的，單個DBFS的磁碟空間、IOPS、可掛載節點數存在上限，並且由於分散式鎖與通訊的關係，共享掛載節點數越少則效能越好。所以，LindormStore負責將多個DBFS融合，重點解決檔案分塊、資料塊分配及共享、均衡排程等問題，形成統一目錄的、無限擴充套件的分散式儲存，提供HDFS協議的資料服務。基於此技術，採用ESSD作為介質，Lindorm對外向使用者提供效能型儲存形態。

b) 標準型，整體技術方案與效能型一致，其儲存介質採用高效雲盤。

c) 容量型，針對海量資料低成本儲存的訴求，我們透過分散式Buffer+OSS的方式，構建了彈性、低成本的容量型儲存形態。其核心思想是資料同步寫入到分散式Buffer層，然後非同步遷移到OSS儲存，可按需設定一定的讀快取。分散式Buffer層可以保障資料的持久化和可靠性，並具備Log Sync語義，所以其寫入能力與效能型/標準型一致，特別適合海量資料下的低成本儲存、高吞吐寫入、弱查詢要求的場景需求。

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

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

5.2 寬表引擎

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

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

a) 強一致模式，只有主副本提供讀寫，資料會非同步回放到從副本,主副本所在節點故障，從副本晉升為主（晉升之前會保障資料同步完成，從副本擁有所有最新資料，整體過程由Master協調負責）

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、智慧化等技術方向持續重點突破，向著“讓企業資料存得起，看得見”的使命，全力以赴，做到最好。