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