Fluss 都進 Apache了，你竟然還沒聽說過 Fluss, 這篇文章告訴你它和 Kafka、Paimon 有什么區別
隨著大數據技術從離線批處理向實時流處理演進，業務對數據時效性的要求已從傳統的 T+1 天級縮短至秒級。當前主流的實時數倉架構（如 Flink + Kafka）雖能滿足基礎實時需求，但在數據更新、查詢效率、成本控制等方面存在顯著瓶頸。在此背景下，阿里巴巴于 2024 年底開源了Apache Fluss（全稱“Flink Unified Streaming Storage”），定位為“面向實時分析的下一代流存儲”，旨在填補“分析型流存儲”的技術空白。
本文將深入解析 Fluss 的核心特性，并對比其與 Kafka、Paimon 的技術差異，揭示三者在實時數據架構中的定位與協同關系。
一、Apache Fluss 核心技術解析
1. 設計背景：為何需要新一代流存儲？
傳統實時數倉依賴 Kafka 作為流存儲，但 Kafka 本質是為消息傳遞設計的，而非分析場景。在大規模實時分析中，Kafka 面臨四大核心問題：
- 不支持數據更新：需存儲重復數據，導致計算引擎（如 Flink）需承擔高成本去重（如淘天集團因 Kafka 限制放棄構建 DWS 層）；
- 缺乏數據探查能力：無法直接查詢，需同步至 OLAP 系統（增加復雜性）或全表掃描（1GB 數據查詢需 1 分鐘）；
- 數據回溯困難：僅能存儲幾天數據，大規模回溯會占用 Broker 資源并污染頁面緩存；
- 網絡成本高昂：網絡成本占 Kafka 總成本的 88%，一寫多讀場景下需傳輸全量列（即使僅使用 49% 列）。
Fluss 應運而生，其設計目標是融合流存儲的實時性與列存的分析效率，填補“面向分析的流存儲”空白。
2. 核心架構與組件
Fluss 采用分布式架構，核心組件包括：
- Coordinator Server：集群控制中心，負責元數據管理、Leader 節點分配、權限控制及節點擴縮容協調；
- Tablet Server：數據存儲節點，包含 Log Store（存儲變更日志，類似 WAL）和 KV Store（基于 RocksDB 實現，支持更新與點查）；
- 湖流一體服務：通過 Compaction Service 將冷數據歸檔至 Paimon/Iceberg，支持實時數據（Fluss）與歷史數據（Paimon）的 Union Read。
3. 關鍵技術特性
(1) 流式列存儲與高效壓縮
Fluss 采用 Apache Arrow 列存格式，支持服務端列裁剪和端到端零拷貝，僅傳輸查詢所需列。例如，當裁剪 90% 列時，讀取吞吐量提升 10 倍。0.6 版本引入 ZSTD/LZ4 列壓縮，在淘寶核心日志場景測試中，存儲量降低 6 倍，且壓縮/解壓不影響列裁剪性能。
(2) 實時更新與 Merge Engine
Fluss 主鍵表支持行級更新/刪除，通過 Merge Engine 實現靈活的數據合并策略：
- FirstRow：保留主鍵第一條記錄，生成 Append-only 流，替代流式去重（如日志去重場景）；
- Versioned：基于版本號/時間戳保留最新記錄（如 ts 字段，自動忽略舊版本數據）；
- 計劃支持 Aggregate Merge Engine（如求和、計數等聚合更新）。
(3) Delta Join：解決雙流 Join 大狀態問題
傳統 Flink 雙流 Join 需在 State 中保存全量數據（如淘寶某作業狀態達 50TB，占用 2300 CU 資源）。Fluss 的 Delta Join 利用 CDC 流讀 + 索引點查能力，實現雙邊驅動的維表 Join：左右流數據到達時，通過 Join Key 實時點查 Fluss 表，無需存儲全量狀態。實踐中，淘寶作業資源降至 200 CU，回溯時間從 4 小時縮短至 0.5 小時。
(4) 湖流一體：實時與歷史數據無縫融合
Fluss 通過 彈性無狀態入湖服務將熱數據（秒級延遲）同步至 Paimon 數據湖（冷數據，分鐘級延遲），支持：
- Union Read：查詢自動合并 Fluss 實時數據與 Paimon 歷史數據，數據新鮮度達秒級；
- 湖格式插件化：支持 Paimon、Iceberg 等多種湖格式，避免廠商鎖定。
二、Fluss vs Kafka：流存儲的定位差異
Kafka 作為流消息隊列的事實標準，與 Fluss 在設計目標、存儲模型、功能特性上存在根本差異，具體對比如下表：
維度 | Apache Kafka | Apache Fluss |
核心定位 | 高吞吐消息傳遞（流消息） | 實時分析存儲（流分析） |
存儲格式 | 行存（CSV/JSON/AVRO，字節數組） | 列存（Apache Arrow，支持列裁剪/壓縮） |
數據更新 | 不支持，僅追加寫入 | 支持行級更新/刪除（基于 KV Store） |
查詢能力 | 不支持直接查詢，需全表掃描 | 支持主鍵點查、條件查詢（Data Skipping） |
數據保留 | 短期存儲（天級，依賴 Retention 配置） | 湖流一體（熱數據本地，冷數據歸檔至 Paimon） |
網絡成本 | 高（88% 成本來自網絡，需傳輸全量列） | 低（列裁剪提升 10 倍吞吐量，壓縮降 6 倍存儲） |
典型場景 | 日志收集、消息隊列、流數據傳輸 | 實時數倉、秒級分析、寬表構建、維表關聯 |
實例對比：電商訂單狀態更新場景
- Kafka：需存儲重復記錄（如 Pending→Confirmed），下游 Flink 需 State 去重（成本高）；
- Fluss：通過 Versioned Merge Engine 直接更新記錄，下游無需去重，Changelog 可直接消費。
三、Fluss vs Paimon：實時層與湖倉層的協同
Paimon（原 Flink Table Store）是流式湖倉的代表，主打分鐘級實時性與批流一體；Fluss 則作為實時數據層，提供秒級延遲，兩者協同構成“實時-歷史”完整數據鏈路。具體差異如下：
維度 | Apache Paimon | Apache Fluss |
存儲介質 | 分布式文件系統（HDFS/S3，Parquet/Orc） | 本地磁盤 + 遠程存儲（熱數據列存，冷數據歸檔） |
延遲特性 | 分鐘級（依賴文件 Compaction） | 秒級（毫秒級讀寫，實時更新） |
核心能力 | 批流一體、時間旅行、快照管理 | 實時更新、CDC 訂閱、Delta Join、列裁剪 |
數據模型 | 基于文件的表存儲（支持分區/分桶） | 基于 Tablet 的流存儲（Log Store + KV Store） |
典型場景 | 離線加速、歷史數據分析、批流一體數倉 | 實時指標計算、秒級查詢、維表關聯 |
協同案例：電商實時數倉架構
- Fluss：存儲實時訂單流（秒級更新），支持 Delta Join 構建實時寬表；
- Paimon：存儲歷史訂單數據（天級/月級），支持批量報表分析；
- Union Read：通過 Flink 查詢同時讀取 Fluss 實時數據與 Paimon 歷史數據，實現“秒級新鮮度 + 全量歷史”分析。
四、應用場景與性能實踐
1. 核心應用場景
- 實時數倉 DWD/DWS 層：替代 Kafka 作為實時中間層，支持數據更新與復用（如用戶行為寬表）；
- 秒級指標監控：如廣告點擊率（CTR）、搜索推薦相關性（列裁剪提升查詢效率）；
- 動態維表關聯：通過實時點查能力，替代 HBase 作為 Flink 維表（如商品價格、庫存實時關聯）；
- 數據回溯優化：冷數據歸檔至 Paimon，回溯時直接查詢湖倉，避免占用流存儲資源。
2. 性能數據
- 列裁剪：裁剪 90% 列時，讀取吞吐量提升 10 倍（來源：Fluss 0.6 測試報告）；
- 存儲成本：ZSTD 壓縮降低 6 倍存儲空間，CPU/內存開銷無顯著增加；
- Delta Join：淘寶成交作業資源從 2300 CU 降至 200 CU，狀態大小減少 96%；
- 表創建速度：1024 buckets 表創建時間從分鐘級降至毫秒級（Fluss 0.7 優化）。
Apache Fluss 并非替代 Kafka 或 Paimon，而是通過技術互補完善實時數據生態：
- Kafka：專注高吞吐消息傳遞，適合日志收集、系統解耦等場景；
- Fluss：聚焦實時分析存儲，解決 Kafka 在更新、查詢、成本上的痛點；
- Paimon：作為湖倉底座，承載歷史數據與批量分析，與 Fluss 形成“熱-冷”數據分層。
隨著 Fluss 0.7 版本在穩定性（50+ 關鍵問題修復）、彈性無狀態服務、湖格式插件化等方面的優化，其已具備生產級可用性。未來，Fluss 計劃支持 Kafka 協議兼容、多模態數據存儲，并捐贈至 Apache 基金會，進一步推動實時分析存儲的標準化。
對于追求秒級實時性、低查詢成本的業務（如搜索推薦、金融風控），Fluss 提供了全新的技術選型；而 Kafka + Fluss + Paimon 的組合，或將成為下一代實時數倉的主流架構。
