在數字化轉型的浪潮中，企業對數據處理的需求日益復雜多變，傳統的批處理和流處理架構已難以滿足日益增長的性能和時效性要求。在此背景下，YMatrix CEO 姚延棟發布了深度文章《數倉架構告別「補丁」時代！全新批流一體 Domino 架構終結“批流縫合”》應運而生，為我們揭示了數據處理領域的未來趨勢。

接下來，就讓我們一同走進這篇文章，共同探索 YMatrix Domino 架構如何引領數據處理領域的新變革。

---

前言

數字洪流沖擊下，企業實時數據需求已突破傳統架構的承載極限。當'批流縫合'架構深陷性能與時效的泥潭，Domino 以顛覆性設計直擊本質：打破批流割裂的底層邏輯，重構數據價值流動范式。這不僅是技術革新，更是認知躍遷——數據世界正以'批流一體'為核心進行板塊級重構。

誠邀你體驗 YMatrix Domino 架構的變革力量：限時開放全功能企業版，開發者可零門檻接入真實業務場景壓力測試。?告別為架構冗余支付的性能'稅款'，突破線性時鐘的決策延遲，讓數據引擎真正驅動業務創新。

“批流一體”技術緣起

在大數據技術領域，計算框架有兩大流派：批處理（Batch Processing）和 流處理（Stream Processing）。兩個框架各有優勢，各有其適應的場景：

流處理引擎經歷了從 Storm 到 Spark Streaming 再到 Flink 的三代技術迭代，大數據處理也隨之經歷了從 Lambda 架構到 Kappa 架構的演進。

1. 流處理技術的演進 Google Dataflow - Spark - Flink

Google Dataflow

2015年，Google Dataflow 為統一批處理和流處理提出了一個全新的編程模型，目標是讓開發者只需編寫一套代碼，就能既處理歷史數據，又能處理實時數據。然而，實際上 Dataflow 的底層仍然依賴于 FlumeJava 和 MillWheel 這類組件的拼接，這種方式雖然在概念上打破了批與流的壁壘，但在實現上仍然存在不少妥協：

• 數據處理管道中，離線數據和實時數據的調度、狀態管理、容錯機制等部分未能做到完美統一，導致一致性和延遲之間需要進行權衡。
• Dataflow 依賴窗口（Windowing）和水印（Watermark）機制來處理亂序和延遲數據。這些機制雖然保證了事件時間語義和正確性，但它們的參數（例如窗口大小、延遲容忍度等）需要精細調優。對于不同的業務場景，找到合適的調優參數可能非常復雜，不當配置可能導致部分數據丟失或結果不準確。

Apache Spark Structured Streaming：微批模式的局限

Spark Structured Streaming 提出了微批處理（micro-batch）的方式來近似實現實時處理，但本質上仍然是將實時流數據分割成一系列小批次進行處理：

• 實時性與延遲問題，由于微批模式的固有特性，每個微批的處理都會產生固定的延遲。Spark 在低延遲實時計算的表現仍與真正的流處理計算有差距。
• 狀態管理和容錯機制，Spark Structured Streaming 通過 checkpoint 和狀態持久化來實現容錯，但對于非常大規模和復雜的狀態管理場景，這種方式可能會帶來較高的資源消耗和管理復雜性。特別是在需要精確一次處理語義的場景中，狀態恢復和維護可能會成為瓶頸。

Apache Flink：流計算優先的批流一體

Flink 作為以流處理為主的系統，在架構上將批處理看作有界流，從而實現了統一的 API 和執行引擎。Flink將批處理視為特殊流處理的方法在理論上實現了批流一體，但是損失了一些批處理場景的性能，并且實際上的使用門檻更高。

• 對純批處理場景的優化不足，雖然統一模型大大簡化了開發，但在純批處理場景下，其性能差強人意。尤其在某些數據量極大或計算密集型的離線任務中，Flink 可能會有額外的調度和狀態管理開銷，從而影響整體性能。
• 統一 API 的復雜性，雖然 Flink 實現了統一的 API 和執行引擎，但對于開發者來說，使用統一 API 進行不同模式下的優化往往需要理解較多底層概念（如事件時間、水印、窗口機制等）。這增加了學習曲線，也使得在批處理任務中，調優變得相對復雜。

總結：十多年來的探索與現狀

從 Lambda 架構到 Dataflow，再到 Flink 和 Spark Structured Streaming，業內不斷嘗試統一批處理和流處理。盡管各家方案都有其亮點，但至今尚未有一種徹底、簡潔且優雅的解決方案能夠同時滿足低延遲、高一致性和高容錯的要求。這導致當前市場上，企業在同時需要批和流功能時，往往仍然采用類似 Lambda 架構的拼接方案，從而增加了系統的復雜性、開發維護成本以及數據不一致困擾。筆者遇到的大量客戶中，大多數批流一體方案是采用 Lambda 架構： Spark/Hive/MPP 數據庫等實現離線分析，而使用 Flink 等實現實時計算。

2. Lambda-Kappa

Lambda 架構

理解 Lambda 架構，可以從兩個名詞入手——批處理、流處理。

Lambda 架構由三層組成，具體如下：

1.?批處理層（Batch Layer）：負責存儲和管理完整的歷史數據集（不可變的數據集），并通過分布式處理系統（如 Hive）對數據進行批量處理，生成預計算視圖。

2.?速度層（Speed Layer）：實時處理新到達的數據，提供低延遲的更新，以彌補批處理層在處理最新數據時的延遲。

3.?服務層（Serving Layer）：將批處理層和速度層的結果進行合并，提供統一的查詢接口，響應用戶的查詢請求。

Lambda架構的優缺點

當以 Storm 為代表的第一代流處理引擎成熟后，一些互聯網公司為了兼顧數據的實時性和準確性，采用Lambda架構來處理數據并提供在線服務。

Lambda架構在實時性和準確性之間做了一個平衡，能夠解決很多大數據處理的問題，曾大量部署在各大互聯網公司。它的好處有：

• 批處理的準確度較高，可以反復對同批數據進行實驗。另外，批處理的容錯性和擴展性較強。
• 流處理的實時性較高，可以提供一個近似準確的結果。

Lambda 架構的缺點也比較明顯：

• 使用兩套大數據處理引擎，如果兩套大數據處理引擎的 API 不同，有任何邏輯上的改動，需要在兩邊同步更新，維護成本高，后期的迭代時間周期長。
• 早期流處理層的結果只是近似準確。
• 組件太多：Lambda 架構是非常龐大的，會使用到大量的組件來建設Lambda。例如：Hadoop、Hive、Cassandra、Oozie等）。而針對不同類型的組件去開發，非常麻煩。運維難度也很大。

Kappa 架構

Kafka 的創始人 Jay Kreps 認為在很多場景下，維護一套 Lambda 架構的大數據處理平臺耗時耗力，于是提出在某些場景下，沒有必要維護一個批處理層，直接使用一個流處理層即可滿足需求，即下圖所示的 Kappa 架構。

以流為核心來建設數據系統。并且，通過重放歷史數據來實現數據重跑。

架構特點：

• 去除批處理層：Kappa 架構刪除了 Lambda 架構中的批處理層，僅保留速度層（Speed Layer），通過流處理系統處理所有數據。
• 統一處理邏輯：采用統一的流處理引擎，使實時處理和歷史數據處理使用相同的代碼路徑，減少了系統復雜性。
• 數據重放能力：利用消息隊列（如Apache Kafka）保存數據日志，支持對歷史數據的重放，以應對業務邏輯更新或錯誤修正的需求。

Kappa架構相對更簡單，實時性更好，所需的計算資源遠小于Lambda架構，隨著實時處理的需求在不斷增長，更多的企業開始使用Kappa架構。

Kappa 架構的問題

根據上述內容，似乎 Kappa 是一個簡單，易維護的選擇。但為什么很多企業仍舊選擇 Lambda 架構呢？Kappa 架構在實際應用中，仍然存在很多問題。

歷史數據計算復雜度高，性能慢

Kappa 架構只需要維護實時處理模塊，但是強依賴消息中間件的緩存能力，歷史數據計算復雜度高，性能慢。Kappa 在拋棄了離線數據處理模塊的時候，同時拋棄了離線計算更加穩定可靠、性能更高的特點。

數據亂序問題

數據亂序問題在流處理中確實常見，尤其是在分布式系統中，數據可能因為網絡延遲、分區處理速度不同等原因導致順序錯亂。比如，一個事件A在時間上發生在事件 B 之前，但由于某種原因，事件 B 先到達處理系統，這時候系統如果按到達順序處理，就會導致錯誤的結果，比如窗口計算的錯誤。

3. YMatrix Domino 內核級創新實現“批流真一體”

無論是 Lambda 架構還是 Kappa 架構，抑或是十年來業界對于流計算技術的探索，在實現“批流一體”的進程中，總是存在多種技術或組件的拼接。開發者在使用上述結構時，往往需要具備多個組件的知識，運維也需要同時維護兩套以上的系統。

就像外賣平臺高峰期既要接實時訂單（流處理），又要統計歷史補貼數據（批處理），傳統架構如同讓騎手同時送外賣和搬倉庫，必然導致調度混亂、資源浪費。Domino 的創新相當于為數據處理打造了『智能交通中樞』，讓實時訂單走專用通道，歷史數據走重載卡車，路口卻由同一套信號系統協調。

Domino 架構通過數據庫內核級的融合，實現了批流一體的真正突破，重新定義了批流一體的數據處理范式。其核心目標是通過統一 everything 的設計與存儲計算融合，徹底消除傳統流批架構的割裂，降低技術復雜性，同時以 SQL 為核心實現“零代碼批流一體開發”。

3.1 統一數據模型：流即是表，表即是流（stream is table，table is stream）

在概念模型上，Domino 架構打破了傳統將流與表割裂的思維，將流數據和靜態表視為同一數據實體的不同表現形式。換句話說，所有流式更新可以看作是對表的連續修改，而有界批數據則是這一更新流在特定時間點的“快照”。

想象你眼前有杯永續續水的茶杯：

? 流數據是杯口持續注入的水流

? 批數據是某一秒按下暫停鍵的水位截圖

Domino 的創新，就是讓茶杯自己記住每一刻的水流軌跡，需要時隨時提取任意時刻的快照。這個魔法道具，就是其獨創的'流表（Stream Table）'。

流表可以認為是一種特殊的表（類似物化視圖），但是具有流的特質，支持實時增量計算。用戶可以使用 DDL 和 DML 對流表進行操作。

下面是一個簡單的流表（dwd_order_detail) 的示意，實現了一個基礎的擴維操作。

CREATE STREAM dwd_order_detail(id, ts, prod_id, prod_name, prod_detail)AS (    SELECT       ods_order.id,       ods_order.ts,       ods_order.prod_id,       dim_prod.prod_name,       dim_prod.prod_detail    FROM STREAMING ALL ods_order    INNERJOIN dim_prod        ON dim_prod.id = ods_order.prod_id ) PRIMARY KEY (id);

對于我們例子中創建的流表 -?dwd_order_detail， 一方面具備一般表的批的能力 - 它可以像一般的表一樣執行各類查詢，同時更重要的是它具備了流的能力 - 無論他的上游ods_order發生了 INSERT, UPDATE 還是 DELETE,dwd_order_detail都會得到實時的更新。

流表是 Domino 批流統一的基石，使得統一批流數據攝取、統一批流計算模型、統一批流存儲模型、統一批流編程接口成為可能。

3.2 統一批流數據攝取（Ingestion）

Domino 為批處理和流處理提供統一的標準的數據攝取機制，通過標準 SQL 實現流表數據的增刪改，和普通表一般無二，而無需為批流提供不一樣的攝取接口。數據攝取的統一消除了因數據格式、數據接口不統一而導致的冗余數據處理，并且降低了學習門檻。此外非常重要的一點是，統一批流，并用表作為統一的底層數據模型，使得對流表的修改和刪除變得非常簡單。

3.3 統一批流計算模型

在 Domino 架構中，批處理和流處理共用同一套基于 Pipeline 的計算引擎和執行模型。用戶創建流表時，Domino 自動為流表創建執行計劃；當流表的數據源發生變化時，執行計劃自動執行，并計算結果更新流表。這套機制和批處理共用相同的機制，也是數據庫領域幾十年沉淀的標準 vocano 執行模型。統一的計算模型，使得開發者不需關心內部實現細節，而僅需使用統一的 SQL編寫邏輯，零代碼實現批流一體。

3.4 統一批流存儲模型

由于 Domino 使用和表相同的概念模型表達流表，所以可以使用相同的存儲引擎存儲批數據（表）和流數據（流表），并保證數據的持久性和事務一致性（ACID）。這種存儲模型的統一使得 Domino 流計算實現可以有幾乎無限容量存儲數據，而無需擔憂內存容量不足或者窗口過小的問題（實際上，在 Domino 架構沒有流計算傳統意義的窗口和水印，因為有幾乎無限的存儲空間）。這種存算融合的方式降低了數據在存儲層與計算層之間轉換的開銷，從而提高了處理效率。同時內核級的事務支持確保批流處理結果始終保持一致，不再因數據分離而產生不一致風險。

3.5 統一批流編程語言 —— SQL as Streaming Processing Language

Domino 架構基于標準 SQL 擴展出流處理能力，使 SQL 不僅用于傳統的查詢和數據操作，也能描述實時流數據的變換和聚合。SQL 作為一種聲明式語言，其優勢在于易學易用，開發者只需掌握 SQL 就能完成復雜的數據處理任務。Domino讓使用者只使用SQL語句就能實現批流統一的數據查詢與分析，降低了技術門檻。比如'SELECT * FROM 訂單流 WHERE 補貼金額 >50'——這條看似普通的SQL，在Domino里既是實時風控，又是離線分析。就像用筷子既能夾菜又能攪拌咖啡，徹底告別Java/Scala/Python的多語言精分現場。

3.6 完善生態，實現多樣化數據標準方式接入，而無問批流

Domino 架構支持多種數據接入方式，具有完善的上下游生態，包括 FineDataLink、DSG、Datapipeline、Seatunnel、BluePipe、用友 IUAP、EMQ、Talend 等。Domino 能夠作為萬能連接器即插即用，無論數據來自 IoT、企業系統、日志系統還是外部 API，Domino 均能統一接入并標準化處理。

3.7 消弭對窗口和水印依賴 —— 降低流計算復雜性

傳統流計算引擎在處理無界數據時，通常依賴復雜的窗口和水印機制來保證事件時間的正確性，而這往往增加了系統設計和調試的難度。Domino 架構通過內核級的事務、統一的存儲模型、統一的計算模型，消除了對傳統窗口技術和水印機制的依賴，使得流計算實現邏輯更加簡潔優雅，而無需復雜難懂的各類概念。開發者無需再為窗口邊界、數據亂序等問題編寫額外邏輯，從而降低了編程復雜度。數據一致性和實時性由內核直接保障，用戶只需關注業務邏輯，不必深入底層細節。

通過以上內核級的創新，Domino 架構實現了批流一體的統一性和一致性，形成了“統一 everything”的設計理念——統一流和表、統一數據攝取、統一計算模型、統一存儲模型、統一查詢語言以及統一事務管理。這樣的架構不僅大幅降低了技術架構的復雜度，更使得懂 SQL 的開發者可以輕松駕馭復雜的批流處理任務，從而推動企業數據平臺向更高效、更易用的方向發展。

這種創新為企業在實時與離線數據處理間建立了一座橋梁，既滿足了業務對高實時性數據的需求，也保證了數據處理的準確性和一致性，是下一代數據處理平臺的重要發展方向。

Domino 相比 Flink / Spark 的關鍵優勢：

Domino 是目前唯一真正實現數據庫級別批流一體的架構！

現在，Domino 開啟免費試用！

Domino 通過統一存儲引擎、火山模型優化器、流表抽象層等 18 項核心專利，實現數據庫內核級批流融合，開發效率提升 10 倍以上，十億級數據量實現秒級延遲。這場數據庫內核級的范式革命，正在重新定義數據處理的游戲規則。當批流界限如冰融化，或許我們會突然發現：原來數據處理本應如水般無形，又似山岳般可靠。

承載完全版 Domino 的 YMatrix6.0 版本已于 2025 年初正式上線，從現在起正式開放免費咨詢與企業試用。（點擊“YMatrix”跳轉）

批流一體十年迷局，許多嘗試折戟沉沙。但答案在未來，長遠來看，批流一體絕不是選擇題，而是必答題！