作者 | 關濤 雲器科技CTO
數據平台領域發展 20 年，逐漸成為每個企業的基礎設施。作為一個進入「普惠期」的領域，當下的架構已經完美了嗎，主要問題和挑戰是什麼？在 2023 年 AI 躍變式爆發的大背景下，數據平台又該如何演進，以適應未來的數據使用場景？
本文將從上述問題的出發，盤點和整理技術演進的趨勢，並提出一體化架構將是下一代技術趨勢的方向。新架構通過創新的「通用增量計算」範式來統一數據分析中流、批、交互不同的計算形式，通過「湖倉一體」統一存儲形態，真正實現一體化 Kappa 架構。同時，新架構以湖倉存儲為基礎，具備開放性和擴展性，能夠對接支撐 AI，具備進一步疊代和擴展能力。
1當下數據平台的典型架構和主要痛點
大數據領域發展20年，不同的典型場景均沉澱出針對性的引擎或者平台。國內市場，當前主流的數據平台架構是：計算部分採用Lamdba架構，存儲層由數據湖或者數據倉庫構建。AI等基礎設施尚在發展成熟中。
以下通過三個不同場景數據架構的實例，總結當前數據平台的典型架構：
圖1 目前典型的大數據系統的流程
自下而上是數據的整個流動過程，從數據採集開始，到多種不同的存儲體系，再向上形成了「離線計算」和「實時計算」的兩種計算模式，最上層是數據的消費部分，且帶有交互分析的場景。
圖2 醫療大數據的數據架構
與前面例子的差異點在於，醫療系統中會存有大量圖像與視頻數據，因此整個架構的底部會有一層面向非結構化數據存儲的存儲體系，以及右側還有面向醫療領域機器學習的智能圖片識別能力，這便是在前一個例子數據分析系統的基礎上疊代了一些 AI 的能力。
圖 3 第三種典型的大數據系統架構
與前者融合的架構不同，Data 和 AI 拆分為二，左側是大數據處理部分，右側為 AI 的部分。AI 部分比較完善，從最基礎的 Model-training，到 Serving，也具有特徵工程等等一系列能力。
More
我們將當前數據平台簡化為如下典型架構圖，其中「不變」的部分用黑底來表示，「變」的部分用灰底來表示，如圖下可見。
圖 4: 當前數據平台典型架構圖（簡化版）
數據源
- 標準場景：
- 關係型資料庫：通過 CDC 等方式採集結構化數據。
- 操作類日誌：通過 APP 或是 Webservice 採集的海量日誌。
- 新場景：
- IoT、智能設備數據：在物聯網普及之前，大多數據都是用人的行為數據。隨 IoT 類技術發展，設備的數據會逐步成為另外一個主要的數據來源。
- 半結構化和非結構化數據：隨著 AI 能力的增強，這部分數據開始被加速地採集上來。
- 關係型資料庫：通過 CDC 等方式採集結構化數據。
- 操作類日誌：通過 APP 或是 Webservice 採集的海量日誌。
- IoT、智能設備數據：在物聯網普及之前，大多數據都是用人的行為數據。隨 IoT 類技術發展，設備的數據會逐步成為另外一個主要的數據來源。
- 半結構化和非結構化數據：隨著 AI 能力的增強，這部分數據開始被加速地採集上來。
數據處理
- 標準場景：
- 數據分析引擎分為「批處理」、「流計算」、「實時分析」，也都有各自比較固定的數據處理和分析的場景，通過組合的方式滿足不同業務需求，這個架構通常稱之為 Lambda 架構。
- 數據存儲架構分為「數據倉庫」與「數據湖」，二者都不算新概念，使用場景也比較固定，大多數企業選擇其一。例如 hadoop 體系就是一種典型的數據湖架構。
- 新場景：
- AI 相關的場景和架構還在發展中，場景差異大，尚未標準化。而最近火熱發展的 LLM 又帶來額外的變化：部分企業會選擇，由一個特徵工程開始到 Training 到 Serving 的端到端的 Pipeline；另一部分企業不再做特別多的 AI 訓練，而是在 Huggingface 上下載一些已有模型 ，只做基礎的 AI 處理。
- 數據分析引擎分為「批處理」、「流計算」、「實時分析」，也都有各自比較固定的數據處理和分析的場景，通過組合的方式滿足不同業務需求，這個架構通常稱之為 Lambda 架構。
- 數據存儲架構分為「數據倉庫」與「數據湖」，二者都不算新概念，使用場景也比較固定，大多數企業選擇其一。例如 hadoop 體系就是一種典型的數據湖架構。
- AI 相關的場景和架構還在發展中，場景差異大，尚未標準化。而最近火熱發展的 LLM 又帶來額外的變化：部分企業會選擇，由一個特徵工程開始到 Training 到 Serving 的端到端的 Pipeline；另一部分企業不再做特別多的 AI 訓練，而是在 Huggingface 上下載一些已有模型 ，只做基礎的 AI 處理。
2Lambda數據架構的主要問題
綜合上述，總結市面上大部分數據平台通常會選用組裝式的 Lambda 架構，而其需要多個 API 接口與多種數據組件，數據冗餘度高，開發維護複雜度高。面向未來，我們認為結構化數據處理分析的趨勢會是，由一個一體化的引擎，統一「流」、「批」和「交互分析」，進而提供統一接口、統一處理邏輯，提供多種優化指標的高覆蓋度和靈活調整的能力。
圖 5: 數據分析架構圖，一種典型的 Lamdba 架構
Lambda 組裝式架構普遍存在的三點問題：
但要解決這些問題，統一成一體化架構，並非數據架構師們不想，而是確有幾處難點，後文有詳細論述。
3從組裝式（Lambda）架構到一體化引架構難點在哪裡？
組裝式 Lambda 架構存在的問題是業界普遍有深刻體感的，也有很多技術 / 產品試圖解決 Lambda 架構的問題，但都不是很成功，為什麼實現「一體化」的架構（也稱Kappa架構）那麼難？這主要有兩個原因：批、流、交互計算的計算形態不同，優化方向也不同。
圖 6: 批、流、交互三種計算形態的差異
一、有不同的計算形態
將數據狀態分靜態數據與動態數據兩類。所謂靜態數據就是當 Query 下發的一瞬間，計算是在數據的一個版本（稱為 snapshot）上進行；而動態數據是指在持續變化中的數據，由數據主動驅動計算。數據 Query 也可分成靜態 Query 和動態 Query兩類。所謂靜態 Query 的意思是像天報表或者小時報表一樣，我們知道它在某一個時間點上會發生。動態 Query 是指，用戶動態下發的，很難被預測。
由以上兩個維度，可以劃分出四個象限區間，可以看出批處理、流計算、交互式分析分屬不同象限：批處理是典型的靜態數據加靜態 Query 的流程，通常是一個 Pipeline 過程；交互分析是靜態數據加動態 Query，高並發低延遲；批處理和交互分析，通常是計算向數據去，是主動計算處理被動數據的過程。流計算是動態數據加靜態計算的過程，當 Plan 發起之後，就一直等待數據進入，是一個主動數據驅動被動計算的過程。
二、有不同的優化方向
上圖三角為數據平台不可能三角，即一個平台不可能同時實現數據新鮮度、低成本和高性能三個目標。如流計算優化的是數據的新鮮度，引擎等數據，為了使得下一條數據進來時計算的足夠快，引擎是一直拉起的狀態，Reserve 了大量資源。實時數倉系統是面向性能的，也需要等待數據，需要一個非常快的數據。批處理計算面向的是 Throughput ，即 Latency 延遲，能夠提供很高的 Throughput，帶來很低的 Cost。不同的優化方向使得三個引擎也不同。
Lambda 架構流行的核心原因是，流、批和交互計算，剛好覆蓋了此三角，三個不同的引擎，每一個引擎的優化方向剛好是在一個角上。通過組合的方式滿足不同業務的需求。下圖更細節地比較批處理、流計算、交互式的異同。
表 1: 批、流、交互三種計算形態的差異
上圖從 6 個不同角度對比，在此僅選兩個例子具體展開：
對比流計算和批計算的存儲系統：
批處理的存儲是通用存儲，採用數倉分層建模的方式，數據的中間表格可以被共享，可以被其他查詢優化。
而流計算是單獨的內置存儲，不可被共享，僅面向該計算模式優化；其中流計算兩個作業之間的存儲也不同，通常用 Kafka 做，是純粹增量化的存儲，且僅支持某一段時間的查詢，不能做全量數據 Query。
所以存儲模式的不同和計算模式的不同，使得流和批都很難統一彼此。
對比批處理和交互計算的調度模型和資源模型：
批處理通常選擇 Bulk Synchronous Parallel（BSP）調度模型，是一種逐層調度模式。批處理通常作業下發後，動態向 Yarn/Kubernetes 申請資源，具有極佳的資源使用效率，能夠降低成本。缺點是會造成資源排隊。
而交互分析為了更好的性能，通常採用 Massive Parallel Processing（MPP）調度模型，資源需要保持預置，數據被靜態劃分好，面向低延遲和高性能優化，但有很高的成本。
調度 / 資源模型的不同使得批處理和實時分析引擎也很難統一。
綜上可以看出由於流、批、交互三種計算引擎的計算模型、數據驅動方式、存儲系統設計、調度系統設計、資源模型等均不相同，都很難覆蓋另外兩個的場景，他們三者本身難以完成統一計算模式。
4新「通用增量計算」模式統一批、流、交互三種計算模式
鑒於流、批、交互三種計算模式都不能完成模式的統一，我們提出第四種計算模式：增量計算。
增量計算定義：指的是將所有計算抽象成增量的形態，實現數據的一次計算、累次使用，節省計算資源，同時能提供靈活調整的「增量時間間隔」，達成批處理或者流處理效果。因增量方式顯著降低資源使用，也能大幅提升交互分析的性能並降低延遲。
圖 7：通過增量計算的方式，實現批、流、交互三種計算模式的統一
通用增量計算的原理：
如左圖所示，x 軸時間軸代表 T0、T1 和 T2，當 Query 下發時，T0 動態生成 Plan，基於當前最優數據和計算情況，在 T0 數據里得到結果集 ResultSet T0；當在 T1 時間下發同一個 Query 時，該 Query 的計算不再從 0 開始，而是在 T0 結果集的基礎上，結合 T0 到 T1 這一階段的數據，融合起來做增量計算，得到 ResultSet T1，同時在為 T2 計算做狀態準備。
針對批處理，可以將其作為當 T0 為 0，從 T0 到 T1 的增量計算模式的特例，是一種從頭開始的增量計算。在最佳實踐里，用戶通常不再保持按天的批處理，而是降低調度間隔來達成更好的近實時性。
針對流計算，流計算是天然的增量計算模型，可以通過縮短 T0 與 T1 中間間隔的時間來達成。
針對交互分析，與批處理類似，交互分析也可以抽象為增量化形態，並且更簡單，因為沒有後續，所以不需要再為下一階段計算做準備。同時，因為部分交互分析的數據是持續寫入的，部分之前的計算結果也可以被後來的作業利用，大幅降低計算量。
調度增量計算的時間間隔，是由用戶根據需要調整設定的。當把調度時間間隔調整的很短，例如調整為分鐘或者秒級，整個計算模式就愈接近流計算，而如果把間隔調整天，計算模式就等同於批處理。也就是說，計算模式的改變，只需要調整調度就能實現！
總結，增量計算模式有幾點優勢：
第一，統一計算模式，進而能夠統一引擎，從根本上解決 Lambda 的痛點。
第二，每次 Query 在下發的時候，可以根據 T0、T1 中間的時間間隔做動態 Plan，找到其中最優 Plan 的調節流程。能夠實現數據平台不可能三角的平衡點，基於數據新鮮度、性能、成本的動態平衡，靈活地在三者之間找到多種多樣的平衡。
第三，結果集 ResultSet 均公開可用，能夠支持所有其他引擎或者平台使用，更符合數倉建模設計邏輯，也更具開放性。
5基於「增量計算」實現一體化 Lakehouse 數據平台
雲器科技是「通用增量計算」提出者，也是最早的踐行者。因此雲器科技以增量計算為基礎，進一步提出Single-Engine的數據平台設計理念。並將Single-Engine能力產品化形成雲器Lakehouse服務。
圖 8：基於增量計算實現一體化 Lakehouse 數據平台
基於增量計算數據計算新範式，雲器科技實現了 Single-Engine 一體化平台，包含如下三部分：
至此，通過統一的計算模式、統一的增量存儲，並將數據、計算和資源 Share Everything 化，最終構成了雲器 Lakehouse 的 Single-Engine 一體化架構。
雲器 Lakehouse 具備以下關鍵能力：
6雲器實踐並驗證了一體化引擎的性能指標超過國際頂級水平
雲器 Lakehouse 作為一體化數據平台，橫跨實時、離線、交互分析等多個場景，為了客觀地衡量數據集在不同場景下的表現，我們用業界標準的測試集在對應場景上，進行性能評估。特別的，雲器 Lakehouse 由於採用了存算分離 share-everything 的系統架構，會通過限制 virtual cluster（虛擬計算集群 abbr. VC）計算資源的規格來保證測試數據與其他產品的規格一致。儘管這樣的限制不利於發揮計算資源彈性伸縮的優勢，雲器 Lakehouse 仍然在多個場景下同時表現出優異的性能，如圖 11 所示：
圖 9: 雲器 Lakehouse 離線和實時分析場景性能指標
- 圖 11- 左 1：大數據分析場景，TPC-DS 10TB 是 TPC 發布的針對大數據系統的標準測試數據集，適合用於評估大數據處理及 ETL 處理過程，測試集包含對大數據集的統計、報表生成、聯機查詢、數據挖掘等複雜應用。以相同規格配置的處理時間評估，雲器 Lakehouse 處理速度比 Snowflake 快 30%，是 Spark 處理的 9 倍；
- 圖 11- 左 2: 即時分析場景，TPC-H 100GB 是由面向業務的臨時查詢和並發數據修改組成，適合用於對 Ad-hoc 臨時查詢評估。雲器 Lakehouse 不僅在處理速度上達到了 Spark 的 7 倍，且比 Snowflake 還要快 4 倍。
- 圖 11- 右 1: 在實時分析場景，SSB-FLAT 100GB 是以星型數據結構為主的數據測試集，適用於評估實時查詢性能，我們對比了 Spark 和 Clickhouse，Snowflake。由於 Spark 是對批處理做優化的，實時分析會比較慢。而 Clickhouse 是專向實時分析優化的，它會更有優勢。測試結果顯示，雲器 Lakehouse 比 Clickhouse 的快 20%，是 Snowflake 的 3 倍。
在流計算領域，我們選取了 4 個典型場景做性能對比：
- Process 場景：是單表下，單行的數據處理 json 展開的場景；
- 單流 join 場景：是雙表下，左表是一個固定的維表，Join 右表是流動的實時表數據，這是一個標準的維表擴展場景；
- 單表聚合場景：是單表做 aggregation，流動數據的聚合分析場景；
- 雙流 join 場景：是雙表流動數據的 join 場景。
圖 10: 流計算細分場景的資源消耗對比
在每個場景以某流引擎做參照對比分析，由於其是一個「主動數據被動計算」的過程，會有占用資源和實際使用資源的區別。如圖12所示，每張圖的前兩個數據柱狀圖指標是參照流引擎，第一個柱子代表其資源占用，第二個代表實際資源使用。而雲器使用增量計算的模式，沒有資源占用和使用差異。6個深藍色柱子代表雲器Lakehouse在不同的時間間隔的資源使用情況。
在Process場景和單流join場景（圖12-左1左2）屬於「無狀態計算」，雲器基於自研的向量化引擎實現，比行式處理引擎的方式快至少10倍以上，此外可以看到無論調度間隔是10秒或間隔8小時，雲器流計算資源消耗差異不大。
單表聚合場景和雙流join場景，由於要考慮歷史數據/狀態，屬於「帶歷史狀態計算」，調度間隔時間的調整會很大程度上影響計算資源的消耗，從圖12右1右2兩張圖可見，雲器Lakehouse在10秒調度間隔下做到持平，在30秒或調至1小時的准實時調度間隔，性能的節省可以達到百倍甚至千倍。
上述測試表明，雲器Lakehouse在流處理場景上，比常規流式引擎有10x-1000x的資源消耗節省。並且，基於增量計算在「流」和「批」兩個極端場景中間，讓數據新鮮度和處理成本可以被精益平衡；讓用戶既可以獲得「流」的實時性，又可以得到「批」的低成本。
7總結
基於增量計算的新計算範式表現出卓越的性能，雲器科技基於此提出統一流、批、交互三種計算模式，實現 Single-Engine 的架構，覆蓋數據不可能三角，將為企業帶來數據平台領域的新一輪技術紅利——為用戶提供靈活的多種性能成本平衡點。
此外，新架構平台與 AI 更好結合，無論是 All data 開放數據的技術理念和實現——可以更好支持 BI 和 AI 的 Workload；還是 AI4D 的新能力——通過 AI 的方式更好地優化平台效率。隨著 AI 時代的到來，數據平台領域的變革者 / 挑戰者時刻已悄然臨近。
圖 11: 總結，雲器科技基於增量計算打造一體化平台的最佳實踐
頭髮絲 1/60 的精度，中國每 10 輛新能源汽車就有 6 輛用這家齒輪
語雀突發 P0 級事故！宕機 8 小時被網友怒噴，運維又背鍋？
智譜 AI「超 25 億融資」的背後
是時候徹底放棄「高分低能」的 Leetcode了：AI 時代的面試需要大變革！