在經歷了 27 天對流處理技術的深度探索後，今天讓我們將目光投向更遠的未來，探討流處理領域的兩項前沿技術：Apache Flink 2.0 和 Apache Fluss。

雖然這些技術還在快速發展中，但它們代表了流處理技術發展的重要方向。作為技術工作者，了解這些前沿動向有助於我們更好地規劃未來的技術路線圖。

Apache Flink 2.0

2025年3月，Apache Flink 2.0.0 正式發布，代表了 Flink 架構的重大演進。

核心突破：分離式狀態管理

1. 狀態與計算的徹底分離

傳統 Flink 的狀態管理限制：

Flink 1.x 架構:
┌─────────────────────────────────────┐
│         Task Manager                │
│                                     │
│ ┌─────────────┐ ┌─────────────────┐ │
│ │ Computation │ │ RocksDB State   │ │
│ │   Logic     │◄┤   (Local)       │ │
│ └─────────────┘ └─────────────────┘ │
│                         │           │
│                         ▼           │
│                 ┌─────────────────┐ │
│                 │  Periodic       │ │
│                 │  Checkpoint     │ │
│                 └─────────────────┘ │
└─────────────────────────────────────┘

問題：
• 狀態與計算緊耦合
• Checkpoint 期間會阻塞處理
• 本地磁盤容量限制
• 恢復時間長

Flink 2.0 分離式狀態架構：

Flink 2.0 Disaggregated State:
┌─────────────────┐      ┌─────────────────────┐
│ Compute Layer   │      │   State Storage     │
│                 │      │                     │
│ ┌─────────────┐ │async │ ┌─────────────────┐ │
│ │ Computation │ │◄────►│ │ ForSt Backend   │ │
│ │   Logic     │ │ API  │ │ (Disaggregated) │ │
│ └─────────────┘ │      │ └─────────────────┘ │
└─────────────────┘      └─────────────────────┘

優勢：
• 非阻塞狀態訪問
• 無本地存儲限制
• 快速故障恢復

2. ForSt 後端引擎

ForSt (For Streaming) 是 Flink 2.0 專門為流處理設計的分離式狀態後端：

技術特性：

• 雲原生設計：狀態存儲與計算資源完全分離
• 高並發 I/O：支援並行多路 I/O 操作
• 彈性擴展：突破本地磁盤容量限制
• 非阻塞架構：Checkpoint 期間不影響數據處理

Apache Fluss：為 Flink 而生的流式存儲

Apache Fluss（正在 Apache 基金會孵化中）是專門為實時分析構建的流式存儲引擎，可以理解為 Apache Flink 的分離式表存儲引擎。

Fluss 的設計理念

名稱的含義

多重寓意：

• 技術含義：Flink Unified Streaming Storage 的縮寫
• 自然含義：德語中的「河流」，象徵數據的持續流動
• 使命體現：為 Apache Flink 構建統一的流式存儲基礎

解決的核心問題

Paimon 的局限性：
雖然 Apache Paimon 在流式攝取和物化視圖方面表現出色，但在需要低延遲流處理的場景下存在不足

核心技術特性

1. 列式流存儲

存儲架構：

• Apache Arrow IPC Streaming Format：底層文件存儲格式
• 列式優化：流式讀取性能提升高達 10 倍
• 內存友好：針對實時查詢優化的內存佈局

2. 超低延遲性能

性能指標：

• 流式讀寫：支援毫秒級的流式讀寫操作
• 點查詢：超高 QPS 的主鍵點查詢能力
• 端到端延遲：亞秒級的端到端處理延遲

3. 靈活的表類型與 Partial Update

支援多種表模式：

Fluss Table Types:
┌─────────────────────────────────────────────────────┐
│ Log Tables (Append-Only)                            │
│ • Pure append mode                                  │
│ • Suitable for event log scenarios                  │
│                                                     │
│ PrimaryKey Tables (Updatable)                       │
│ • Support update operations                         │
│ • Support partial updates for wide tables           │
└─────────────────────────────────────────────────────┘

Partial Update：解決大寬表問題

傳統多流 JOIN 的困境：

Traditional Multi-Stream JOIN:
Stream A ──┐
Stream B ──┼──► Flink Multi-Way JOIN ──► Wide Table
Stream C ──┘
           ▲
    Problems:
    • 巨大的 JOIN 狀態
    • 長時間狀態保留
    • 高計算開銷

Fluss Partial Update 解決方案：

Fluss Partial Update Architecture:
Stream A ──► Partial Update (Column 1-3) ──┐
                                           ▼
Stream B ──► Partial Update (Column 4-6) ──► Fluss PK Table
                                           ▲  (Auto Merge)
Stream C ──► Partial Update (Column 7-9) ──┘
                    │
                    ▼
            Real-time Changelog

核心優勢：

• 狀態下沉：將 JOIN 狀態從計算層下沉到存儲層
• 自動合併：基於主鍵自動合併不同流的部分更新
• 實時 Changelog：生成完整的變更日誌供下游消費
• 成本效益：避免昂貴的多路 JOIN 操作

這個設計與我們在 Day 26 討論的 Paimon Partial Update 相似，但 Fluss 提供更低的延遲和更高的更新頻率。

4. Delta Join：狀態分離的創新

Flink 團隊開發了創新的 Delta Join 算子：

Traditional Flink JOIN vs Delta Join:

Traditional JOIN:
┌─────────────────────────────────────────────────────┐
│ Flink TaskManager                                   │
│ ┌─────────────┐  ┌─────────────────────────────┐    │
│ │ Stream A    │  │ Large JOIN State            │    │
│ │ Stream B    │──┤ (RocksDB Local)             │    │
│ │ Stream C    │  │ • State-Compute Coupling    │    │
│ └─────────────┘  └─────────────────────────────┘    │
└─────────────────────────────────────────────────────┘

Delta JOIN with Fluss:
┌─────────────────────┐    ┌──────────────────────────────┐
│ Flink Compute       │    │ Fluss Storage                │
│ ┌─────────────────┐ │    │ ┌──────────────────────────┐ │
│ │ Delta JOIN      │ │◄──►│ │ Shared State             │ │
│ │ (Stateless)     │ │    │ │ • State-Compute Separated│ │
│ └─────────────────┘ │    │ │ • Multi-Job Sharing      │ │
└─────────────────────┘    │ │ • Efficient Backfill     │ │
                           │ └──────────────────────────┘ │
                           └──────────────────────────────┘

Delta Join 的核心創新在於它是一個雙邊觸發的 Lookup Join，這與傳統的單向 Lookup Join 有根本性的差異：

傳統 Lookup Join（單向觸發）：

Traditional Lookup JOIN:
┌─────────────────────────────────────────────────────┐
│ Stream A → Lookup → Dimension Table → Output        │
│                      ▲                              │
│                      │                              │
│                 Only triggered                      │
│                 by Stream A                         │
└─────────────────────────────────────────────────────┘

Delta Join（雙邊觸發）：

Delta JOIN (Dual-Trigger):
┌─────────────────────────────────────────────────────┐
│              Fluss Storage                          │
│ ┌─────────────┐     ┌─────────────────────────────┐ │
│ │ Stream A    │────►│ Shared State Table          │ │
│ │ (Events)    │     │ (Key-Value Store)           │ │
│ └─────────────┘     └─────────────────────────────┘ │
│                              │                      │
│ ┌─────────────┐              ▼                      │
│ │ Stream B    │────► ┌─────────────────────────────┐│
│ │(Dimensions) │      │ Delta Join Processor        ││
│ └─────────────┘      │ (Triggered by both sides)   ││
│                      └─────────────────────────────┘│
└─────────────────────────────────────────────────────┘

雙邊觸發的工作原理：

1. Stream A 觸發：當事件流有新數據時

   • 根據 Join Key 查詢 Fluss 中的維度數據
   • 如果找到匹配的維度，產生 JOIN 結果
   • 如果找不到，暫存事件到 Fluss 等待維度數據

2. Stream B 觸發：當維度流有新數據/更新時

   • 更新 Fluss 中的維度數據
   • 主動查詢 Fluss 中等待該維度的事件數據
   • 對所有匹配的事件產生 JOIN 結果
   • 處理延遲到達的維度數據場景

核心優勢：

• 狀態大幅減少：相比傳統多路 JOIN，Delta Join 只需維護少量查詢狀態，大幅降低內存使用
• 數據完整性：解決了傳統 Lookup Join 中維度數據延遲到達的問題
• 狀態自動管理：無需手動設置狀態 TTL，Fluss 自動管理
• 實時響應：任意一側的數據更新都能立即觸發 JOIN 計算
• 多 Job 共享：多個 Job 可以共享同一份狀態數據
• 高效 Backfill：狀態數據在 Fluss 中持久化，支援高效的歷史數據回填
• 靈活修改：修改 Job 邏輯無需重建狀態

實際應用場景：

電商訂單處理:
訂單事件 ───┐
            ├──► Delta JOIN ──► 豐富的訂單數據
商品維度 ───┘

這種雙邊觸發機制讓 Fluss 的 Delta Join 在處理複雜的實時數據關聯場景時表現出色

5. 湖倉架構整合與多引擎支援

統一數據生態：

• 流式數據層：作為湖倉架構的實時數據層
• 橋接角色：連接「流數據」與「湖倉」架構
• 數據匯流：如河流般讓流數據持續匯聚、分發並流入數據湖

多引擎查詢支援：

Fluss Multi-Engine Architecture:
┌─────────────────────────────────────────────────────┐
│                   Fluss                             │
│ ┌─────────────┐    ┌─────────────────────────┐      │
│ │ Log Table   │    │ PrimaryKey Table        │      │
│ │ (Append)    │    │ (Updatable)             │      │
│ └─────┬───────┘    └─────┬───────────────────┘      │
└───────┼──────────────────┼──────────────────────────┘
        │                  │
        ▼                  ▼
┌─────────────────────────────────────────────────────┐
│              Auto Export to                         │
│                 PAIMON                              │
└─────────────────────────────────────────────────────┘
                         │
                         ▼
┌─────────────────────────────────────────────────────┐
│          Multi-Engine Query Support                 │
│                                                     │
│ Apache Flink • Apache Spark • StarRocks             │
└─────────────────────────────────────────────────────┘

核心優勢：

• 原生 Flink 整合：與 Apache Flink 深度整合，提供最佳性能
• 直接 SQL 查詢：支援通過 Flink SQL 直接查詢 Fluss 表，類似 RisingWave 的查詢體驗
• 未來多引擎支援：規劃支援 Apache Spark 和 StarRocks 等主流引擎
• 自動數據導出：Log Table 和 PrimaryKey Table 都可自動導出到 Paimon
• 熱冷分層：Fluss 負責熱數據的低延遲訪問，Paimon 處理冷數據的大規模分析
• 統一查詢視圖：為整個湖倉生態提供統一的數據視圖

6. 解決 Kafka 的查詢限制

傳統 Kafka 作為流存儲的根本限制：

Kafka Query Limitations:
┌─────────────────────────────────────────────────────┐
│                    Kafka                            │
│                                                     │
│ • Only Sequential Read Support                      │
│ • No Key-based Point Query                          │
│ • No Complex Analytical Query Support               │
│                                                     │
└─────────────────────────────────────────────────────┘

Fluss Query Capabilities:
┌─────────────────────────────────────────────────────┐
│                    Fluss                            │
│                                                     │
│ • Key-Value Point Query Support                     │
│ • SQL Range Query Support                           │
│ • Secondary Index Support                           │
└─────────────────────────────────────────────────────┘

核心差異總結：

• Kafka：純流存儲，無良好查詢能力
• Fluss：可查詢流存儲，支援點查詢和 SQL

Fluss 在現代架構中的定位

技術棧互補關係

Modern Streaming Architecture:
┌─────────────────────────────────────────────────────┐
│                Flink 2.0                            │
│         (Enhanced Compute Engine)                   │
└─────────────────┬───────────────────────────────────┘
                  │
                  ▼
┌─────────────────────────────────────────────────────┐
│                Apache Fluss                         │
│           (Low-Latency Storage)                     │
└─────────────────┬───────────────────────────────────┘
                  │
                  ▼
┌─────────────────────────────────────────────────────┐
│            Apache Paimon/Iceberg                    │
│          (Large-Scale Lakehouse)                    │
└─────────────────────────────────────────────────────┘

分層協作：

• Flink 2.0：提供強大的流處理計算能力
• Fluss：提供低延遲的流式存儲和實時查詢
• Paimon/Iceberg：提供大規模的湖倉存儲能力

總結

通過對 Flink 2.0 和 Apache Fluss 的深入了解，我們可以看到流處理技術正朝著以下方向發展：

技術發展的三大趨勢：

1. 架構雲原生化：從單體架構向微服務、存算分離的雲原生架構演進
2. 接口標準化：從複雜 API 向標準 SQL 和聲明式接口轉變
3. 場景細分化：不同延遲需求的場景有了更專業化的解決方案

對技術選擇的啟示：

雖然這些前沿技術令人興奮，但在實際選擇時仍需保持理性：

• 成熟度考量：新技術往往意味著更多的未知風險
• 團隊能力：評估團隊是否有能力駕馭新技術
• 業務需求：技術服務於業務，而非為了技術而技術
• 遷移成本：考慮從現有方案遷移的成本和收益

未來的學習建議：

1. 持續關注：定期關注流處理領域的技術發展
2. 小範圍試驗：在非關鍵業務上嘗試新技術
3. 社群參與：積極參與開源社群，獲得第一手資訊
4. 知識更新：保持學習心態，及時更新技術知識體系

技術的發展永無止境，但理解問題本質、選擇合適工具的能力是永恆的。希望這 28 天的學習之旅能夠幫助大家建立起對流處理技術的全面認知，在面對未來的技術選擇時更加從容自信。

Day 29 預告：學術前沿 - DBSP 與 Timely Dataflow 的理論突破

在探索了工業界的最新技術後，讓我們將視野拓展到學術研究前沿。明天我們將深入探討具有革命性潛力的理論創新。