全部產品
Search
文件中心

Lindorm:產品架構

更新時間:Jul 06, 2024

本文介紹Lindorm的產品架構,包括業務背景和總體結構。

業務背景

伴隨著資訊技術的飛速發展,各行各業在業務生產中產生的資料種類越來越多,有結構化的業務中繼資料、業務運行資料、裝置或者系統的量測資料,也有半結構化的業務運行資料、日誌、圖片或者檔案等。按照傳統方案,為了滿足多種類型資料的儲存、查詢和分析需求,在設計IT架構時,需要針對不同種類的資料,採用不同的儲存分析技術,如下圖:

這種技術方案,是一種典型的技術片段化的處理方案。針對不同的資料,使用不同的資料庫來處理。有如下幾個弊端:

  • 涉及的技術組件多且雜

  • 技術選型複雜

  • 資料存取、資料同步的鏈路長

這些弊端會對資訊系統建設帶來巨大的問題,對技術人員要求高、業務上線周期長、故障率高、維護成本高。更進一步,技術片段化導致技術架構割裂,不利於技術架構的演化和發展,最終導致技術架構無法跟進業務前進的步伐。舉個簡單的例子,當業務發展,需要支援跨可用性區域高可用、全球同步或者降低儲存成本時,各技術組件都需要獨立演化和發展,耗時耗人耗力,是一件非常痛苦的事情。並且隨著業務的發展,資料的類型會越來越多,對不同種類資料的差異化處理需求會日漸增加,會導致資料存放區片段化更加嚴重。

當前資訊化技術發展面臨的一個主要矛盾是"日益多樣的業務需求帶來的多種類型資料與資料存放區技術架構日趨複雜成本快速上升之間的矛盾"。伴隨5G、IoT、智能網聯車等新一代資訊技術的逐步普及應用,這個矛盾會越來越突出。為瞭解決這個問題,阿里雲自研了雲原生多模資料庫Lindorm,滿足多模型資料的統一儲存、查詢和分析需求。如下圖所示,與傳統方案相比,Lindorm系統極大地簡化資料存放區技術架構設計,大幅度提升系統穩定性,降低建設成本投入。

總體架構

Lindorm創新性地使用儲存計算分離、多模共用融合的雲原生架構,以適應雲端運算時代資源解耦和Auto Scaling的訴求。其中雲原生Distributed File SystemLindormDFS為統一的儲存底座,向上構建各個垂直專用的多模資料引擎,包括寬表引擎、時序引擎、搜尋引擎、流引擎等。在多模引擎之上,Lindorm既提供統一的SQL訪問,支援跨模型的聯集查詢,又提供多個開源標準介面(HBase/Cassandra、OpenTSDB/InfluxDB、Kafka、HDFS),滿足存量業務無縫遷移的需求。最後,資料通道服務(LTS)負責引擎之間的資料流轉和資料變更的即時捕獲,以實現資料移轉、即時訂閱、數湖轉存、數倉迴流、單元化多活、備份恢複等能力。

Distributed File System

LDFS(Lindorm DFS)是面向雲基礎儲存設施設計、相容HDFS協議的分布式儲存系統,並同時支援運行在本地碟環境,以滿足部分大客戶的需求,向多模引擎和外部計算系統提供統一的、與環境無關的標準介面,整體架構如下:

LDFS提供效能型、標準型、容量型等多種規格,並且面對真實情境的資料冷熱特點,支援效能型/標準型、容量型多種儲存混合使用的形態,以適應真實情境的資料冷熱特點,可結合多模引擎的冷熱分離能力,實現冷熱儲存空間的自由配比,讓使用者的海量資料進一步享受雲端運算的低成本紅利。

在計算分析、備份歸檔、資料匯入等情境,Lindorm支援外部系統通過LDFS直接存取多模資料引擎的底層檔案,從而大幅提升資料的讀寫效率。例如使用者可以在離線計算系統直接產生底層資料格式的物理檔案,匯入至Lindorm中,以減少對線上服務的影響。

寬表引擎

LindormTable是面向海量半結構化、結構化資料設計的分布式NoSQL系統,適用於中繼資料、訂單、賬單、畫像、社交、feed流、日誌等情境,相容HBase、Cassandra等開源標準介面。其基於資料自動分區+分區多副本+LSM的架構思想,具備全域二級索引、多維檢索、動態列、TTL等查詢處理能力,支援單表百萬億行規模、高並發、毫秒級響應、跨機房強一致容災,高效滿足業務大規模資料的線上儲存與查詢需求。面向海量半結構化、結構化資料設計的分布式NoSQL系統,能夠相容HBase、Cassandra等開源標準介面。整體架構如下:

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

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

  • 最終一致模式。主從副本都提供讀寫,資料會相互同步,保證副本之間的資料最終一致。

LindormTable的多副本架構基於PACELC理念設計,每一個資料表都支援單獨支援設定一致性模式,從而擁有不同的可用性和效能。在最終一致模式下,服務端會對每一個讀寫請求在一定條件下觸發多副本並發訪問,從而大幅提升請求的成功率和減少響應毛刺。該並發機制建立在內部的非同步訪問架構上,相比於啟動多線程,額外資源消耗可以忽略不計。對於並發訪問的觸發條件,主要包括兩個類型:

  • 限時觸發,對於每一個請求,都可以單獨設定一個GlitchTimeout,當請求已耗用時間超過該值未得到響應後,則並發一個請求到其他N-1個副本,最終取最快的那個響應。

  • 黑名單規避,服務端內部會基於逾時、拋錯、檢測等機制,主動拉黑存在慢、停止回應等問題的副本,使得請求能夠主動繞開受軟硬體缺陷的節點,讓服務最大可能保持平滑。比如在掉電斷開的情境下,在節點不可服務至失去網路心跳往往會存在一兩分鐘的延遲,利用LTable的這種多副本協同設計,可以大幅提升服務的可用性。

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

LindormTable提供的資料模型是一種支援資料類型的鬆散表結構。相比於傳統關聯式模式,LindormTable除了支援預定義欄位類型外,還可以隨時動態添加列,而無需提前發起DDL變更,以適應巨量資料靈活多變的特點。同時,LindormTable支援全域二級索引、倒排索引,系統會自動根據查詢條件選擇最合適的索引,加速條件組合查詢,特別適合如畫像、賬單情境海量資料的查詢需求。

時序引擎

LindormTSDB是面向海量時序資料設計的分布式時序引擎,相容開源OpenTSDB等標準介面,其基於時序資料特點和查詢方式,採用Timerange+hash結合的分區演算法,時序專向最佳化的LSM架構和檔案結構,支援海量時序資料的低成本儲存、預降採樣、彙總計算、高可用容災等,高效滿足IoT/監控等情境的測量資料、裝置運行資料的儲存處理需求,整體架構如下:

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

TSCompute是負責時序資料Realtime Compute的組件,重點解決監控領域常見的降採樣轉換和時間軸彙總需求,通過Lindorm Stream進行資料訂閱,並完全基於記憶體計算,所以,整體非常的輕量、高效,適合系統已預置的計算功能。針對部分靈活複雜的分析需求,使用者仍可以通過對接Spark、Flink等系統實現,從而支撐更多情境和適應業務變化。

搜尋引擎

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

LindormSearch的資料持久化儲存在LDFS中,通過自動Sharding的方式分散到多台SearchServer中,每一個分區擁有多個副本,支援一寫多讀,提升查詢彙總的效率,同時這些副本之間共用儲存,有效消除副本之間的儲存冗餘。

在Lindorm系統中,LindormSearch既可以作為一種獨立的模型,提供半結構化、非結構化資料的鬆散文檔視圖,適用於日誌資料分析、內容全文檢索索引;也可以作為寬表引擎、時序引擎的索引儲存,對使用者保持透明,即寬表/時序中的部分欄位通過內部的資料鏈路自動同步搜尋引擎,而資料的模型及讀寫訪問對使用者保持統一,使用者無需關心搜尋引擎的存在,跨引擎之間的資料關聯、一致性、查詢彙總、生命週期等工作全部由系統內部協同處理,用簡單透明的方式發揮多模融合的價值。

流引擎

LindormStream是面向流式資料處理的引擎,提供了流式資料的儲存和輕計算功能,相容Kafka API和Flink SQL,協助業務基於Lindorm快速構建基於流式資料的處理和應用。

LindormStream內部包含流儲存、Realtime Compute兩大組件,通過兩者的一體化部署和深度融合,支援流資料的高效能即時處理。其中,流儲存負責訊息日誌資料的寫入和訂閱,相容開源Kafka API,並且資料持久化儲存在底層LDFS中,具備高吞吐、低成本、彈性等優勢。Realtime Compute負責訊息日誌的即時處理,相容Flink SQL文法,計算結果資料可以同步至Lindorm寬表引擎、時序引擎等。

計算引擎

計算引擎是雲端式原生架構提供的分散式運算服務,計算節點運行在阿里雲Serverless Kubernetes(簡稱ASK)Container Service中。計算引擎支援社區版計算模型以及編程介面,同時深度融合Lindorm儲存引擎特性,充分利用底層資料存放區特徵以及索引能力,高效地完成分布式作業任務。在資料生產、互動式分析和機器學習等情境中,提供高效能運算服務。Spark作業執行中,計算引擎提供了作業管理介面,您可以通過Spark Web UI(簡稱SparkUI)介面對Spark作業進行完整的監控營運。