Apache Fluss 项目深度分析与技术文档系列计划

版本 1.0 | 2026年8月 | 基于 Fluss 0.9.1-incubating

第一章 Apache Fluss 项目深度分析

1.1 项目概述

Apache Fluss（德语意为「河流」，发音 /flus/）是一个专为实时分析和 AI 场景构建的流式存储系统，可作为 Lakehouse 架构的实时数据层。它于 Apache 软件基金会（ASF）孵化，目前已毕业为顶级项目（TLP），最新稳定版本为 0.9.1-incubating。

Fluss 的设计哲学是「流式与湖仓统一」------它在数据流处理与数据湖仓之间架起桥梁，实现亚秒级数据新鲜度，同时无缝集成 Apache Flink、Apache Spark 等主流计算引擎，并计划支持 Trino、StarRocks 和 DuckDB。

项目核心定位：

消息队列（替代 Kafka 的数据传输角色）
在线 KV 存储（替代 Redis/HBase 的查询服务角色）
流处理状态后端（替代 RocksDB 的状态管理角色）
湖仓冷存储（替代 Iceberg/Paimon 的历史数据角色）

这四个角色在传统架构中需要 4-5 个独立系统，Fluss 将它们统一为一个底层基座，消除了系统间的同步边界和数据漂移问题。

快速链接

官网：https://fluss.apache.org/

GitHub：https://github.com/apache/fluss

Fluss vs Kafka 对比：https://fluss.apache.org/compare/kafka/

2026 路线图：https://github.com/apache/fluss/discussions/2342

1.2 核心架构

Fluss 集群由两大核心进程构成，辅以 ZooKeeper 和远程存储层。

1.2.1 CoordinatorServer（协调节点）

CoordinatorServer 是集群的「大脑」，负责：

维护全局元数据（数据库、表、Schema 信息）
管理 Tablet 分配与负载均衡
协调节点扩缩容时的数据重分布
处理节点故障时的数据迁移和服务节点切换
表管理操作（创建/删除表、更新 Bucket 数量）

1.2.2 TabletServer（数据节点）

TabletServer 负责数据存储、持久化和 I/O 服务，包含两个核心组件：

LogStore ：设计用于存储日志数据，类似于数据库 binlog。消息只能追加，不可修改。核心作用是支持低延迟流式读取，以及作为 KvStore 的 Write-Ahead Log（WAL）。每个 Segment 由 .index（偏移稀疏索引）和 .log（日志数据）文件组成。
KvStore：用于存储表数据，支持更新与删除操作。底层为嵌入式 RocksDB（LSM 引擎），实现高性能更新和点查询。同时生成全面的 changelog 以追踪数据变更。

1.2.3 ZooKeeper

当前用于集群协调、元数据存储和配置管理。根据路线图，未来将被 KvStore + Raft 协议替代，以简化部署和提升可靠性。

1.2.4 远程存储（Remote Storage）

远程存储层基于 S3 兼容对象存储，承担两个关键角色：

LogStore 的分层存储：将历史 Log 数据卸载到远程存储，降低本地存储成本，加速扩缩容
KvStore 的持久化存储：为 KvStore 数据提供持久化保障，与 LogStore 配合实现故障恢复

此外，客户端可直接对远程存储执行批量读取操作，减少对 Fluss 服务端的压力。

架构拓扑视图

复制代码

┌─────────────────────────────────────────────────────┐
│                 Flink / Spark 客户端                  │
│          (Catalog | Source | Sink | Lookup)           │
├──────────────────────┬──────────────────────────────┤
│   CoordinatorServer  │      TabletServer x N         │
│   (元数据/调度/管理)   │   ┌──────────┬──────────┐    │
│                      │   │ LogStore │  KvStore │    │
│                      │   │ (WAL/流) │ (RocksDB)│    │
│                      │   └──────────┴──────────┘    │
├──────────────────────┴──────────────────────────────┤
│            ZooKeeper (协调 / 元数据)                   │
├─────────────────────────────────────────────────────┤
│      Remote Storage (S3 / Iceberg / Paimon / Lance)  │
└─────────────────────────────────────────────────────┘

1.3 核心概念与数据模型

Fluss 的数据模型围绕 Database → Table → Partition → Bucket → Tablet 的层次结构展开。

表类型

Fluss 提供两种表类型，覆盖不同数据处理场景：

特性	Log Table	Primary Key Table
定位	仅追加写入	支持更新的业务数据表
操作	仅 INSERT	INSERT / UPDATE / DELETE
存储引擎	仅 LogStore	LogStore (WAL) + KvStore (RocksDB)
点查询	不支持	支持，亚毫秒级
典型场景	日志、事件流、点击流	维表、特征存储、CDC 管道

数据分布层次

Database：数据库，Table 对象的集合
Table：数据存储的基本单元，按行列组织
Partition：按分区列值对表数据的逻辑划分；对于 PK 表，分区列必须是主键的子集
Bucket：将表/分区数据水平切分为 N 个 Bucket，是最小的数据迁移和备份单元
Tablet：每个 Bucket 由 LogTablet 和可选的 KvTablet 组成

关键设计细节

LogTablet 支持多副本（基于配置的 replication factor），保障高可用；KvTablet 当前不支持副本
同一 bucket_id 的 LogTablet 和 KvTablet 始终分配到同一个 TabletServer
数据在 Fluss 集群中以流式 Arrow 格式存储（低延迟读写优化），在 Lakehouse 中以 Parquet 格式存储（高压缩比、分析优化）

1.4 功能特性全景

六大核心能力支柱

能力支柱	功能描述	架构基础
统一架构	一套系统替代消息队列、KV 存储和 OLAP 引擎	PK 表的双重表示（Log Store + KV Store）
流式与湖仓统一	实时与批量层共享同一 Schema，统一查询入口	Tiering Service + Union Read（Iceberg/Paimon/Lance）
计算存储分离	无状态计算，秒级恢复，成本降低 85%	状态驻留在 Fluss Leader，不在 Flink Slot
列式流分析	列裁剪 + 谓词下推 + 分区裁剪，I/O 降低数量级	Arrow 日志格式 + TabletServer 复合裁剪栈
特征与上下文存储	行/列/向量数据统一存储，ML 就绪	统一基座：结构化特征 + 向量上下文
生态开放性	Flink、Spark、Trino、StarRocks、DuckDB 均可读取	全链路开放湖格式 + ASF 治理

详细功能清单

亚秒级数据新鲜度：持续摄入并立即可用
列式流处理：基于 Apache Arrow，支持列裁剪和谓词下推
高 QPS 点查询：主键表支持亚毫秒级 Lookup
Lookup Join ：与 Flink FOR SYSTEM_TIME AS OF 深度集成
Delta Join：将 Join 状态外部化到 Fluss，计算无状态化
Aggregation Merge Engine：聚合状态外部化，支持 first_value、last_value 等策略
部分更新（Partial Update）：仅更新指定列，非全行替换
更新与删除：原生支持 UPDATE / DELETE 操作
Changelog 生成 ：内置 $changelog 和 $binlog 虚拟表
Schema Evolution：支持 ADD COLUMN 操作
分层存储（Tiered Storage）：冷热数据分离，降低存储成本
Union Read：实时数据与湖仓数据联合查询
Kafka 协议兼容：通过 fluss-kafka 模块实现
多模态存储：支持行式、列式、向量（Lance）等多种数据格式
表级统计：COUNT(*) 无需全表扫描

1.5 技术栈与模块结构

编程语言

Java：核心服务端、客户端、Flink/Spark 集成
Scala：Spark 集成模块
Rust：客户端绑定、Arrow 数据处理、Filter Pushdown

核心依赖

依赖	用途
Apache Arrow	列式数据格式，支撑列裁剪和零拷贝传输
RocksDB	嵌入式 LSM 引擎，驱动 KvStore
Protobuf	RPC 通信协议
Apache Flink (1.20.x / 2.x)	主要计算引擎集成
Apache Spark	批处理和结构化流集成
Apache Iceberg / Paimon / Lance	湖仓冷存储目标

模块架构

模块	功能
`fluss-server`	服务端核心，ISR管理、Leader选举、Bucket管理
`fluss-client`	Java 客户端，流式/批量读写、DDL、点查询
`fluss-flink`	Flink Catalog/Source/Sink/Lookup Join/Delta Join
`fluss-spark`	Spark Catalog 和 Table 支持
`fluss-kafka`	Kafka 协议兼容层
`fluss-lake`	湖仓集成，Tiering 分层存储
`fluss-rust`	Rust 客户端/绑定，Filter Pushdown
`fluss-rpc`	Protobuf RPC 通信框架
`fluss-common`	公共组件和工具类
`fluss-filesystems`	文件系统抽象层
`fluss-metrics`	监控指标模块

1.6 Fluss vs Kafka 深度对比

Fluss 和 Kafka 处于实时数据栈的不同层级------Kafka 是流式传输层 （Streaming Transport），Fluss 是流式存储层（Streaming Storage）。

根本差异

Kafka 将数据视为仅追加日志中的行（Row Log），按分区和偏移量寻址。消费端需自行实现过滤、Join、聚合、去重等逻辑，状态管理（RocksDB）在消费端，导致状态恢复慢、扩缩容受限于状态大小。
Fluss 将数据视为表（Table）。PK 表原生支持 upsert、部分更新和删除，列式 Arrow 日志 + LSM KV 索引位于同一表背后。读取操作在服务端完成（列投影、谓词下推、分区裁剪），PK Lookup 是一等公民操作。

选型指南

维度	选 Kafka	选 Fluss
主要场景	事件驱动系统、日志采集、微服务 Pub/Sub、跨语言消息传输	大规模 Flink 流处理、实时分析、AI/ML、实时湖仓、维表 Join、CDC
存储模型	仅追加行日志	列式 Arrow 日志 + KV 索引，分层至 Iceberg/Paimon/Lance
逻辑单元	Topic（仅日志）	Log Table + PK Table（原生 upsert / 部分更新 / 删除）
状态管理	状态在 Flink RocksDB 中，恢复慢	Delta Join / Aggregation Merge Engine 将状态外部化到 Fluss，秒级恢复
读取路径	无服务端裁剪，无原生 PK Lookup	列裁剪 + 分区裁剪 + 谓词下推 + 亚毫秒 PK Lookup
CDC	外部 Schema Registry + Kafka Connect / Debezium	原生 `$changelog` / `$binlog` 虚拟表，无需外部组件
湖仓集成	外部（通过 Connect Sink）	原生 Union Read（共享 Schema，统一查询）

1.7 Fluss 与 Flink 集成深度解析

Fluss 与 Flink 的集成本质上是将 Fluss 作为 Flink 的「原生存储引擎」。这种集成远比普通的 Connector 更深层：

集成层次

Catalog 层 ：Fluss 注册为 Flink Catalog（type = 'fluss'），用户直接用 Flink SQL 管理 Fluss 表
Source 层：Flink 可以从 Fluss 表进行流式和批量读取，支持列裁剪和谓词下推
Sink 层 ：Flink 可以将流计算结果写入 Fluss 表，支持 EXECUTE STATEMENT SET 批量写入
Lookup Join ：使用 FOR SYSTEM_TIME AS OF 语法，实现高效的维表关联，替代 Redis/HBase
Delta Join：将 Join 状态外部化到 Fluss，Flink 任务变为无状态，恢复时间从分钟级降至秒级
Aggregation Merge Engine：聚合状态外部化，支持 first_value、last_value 等合并策略
Union Read：Flink 可对 Fluss 表执行联合查询，自动合并实时数据（Arrow 格式）和历史数据（Iceberg/Paimon 中的 Parquet）

状态外部化的核心价值

在传统 Flink-on-Kafka 架构中，Flink 任务在本地 RocksDB 中维护 Join 状态和聚合状态。当任务失败或扩缩容时，需要从 Checkpoint 恢复，这个过程可能耗时数分钟甚至更长。

Fluss 的 Delta Join 将状态移至服务端：Flink 任务变成纯粹的计算节点，状态驻留在 TabletServer 的 KvStore 中。这带来了三个关键收益：

秒级故障恢复：计算节点无状态，重启后立即从 Fluss 获取状态
弹性扩缩容：计算和存储独立扩缩，成本优化高达 85%
状态复用：多个 Flink 任务可共享同一份状态，无需重复维护

1.8 Streaming Lakehouse 架构

Streaming Lakehouse 是 Fluss 最具差异化的架构创新。它解决了传统 Lakehouse 架构的「实时与批量矛盾」------高频写入产生大量小文件导致读取效率低下，累积写入则导致数据新鲜度不够。

架构核心

Tiering Service：持续将 Fluss 集群中的实时数据 Compaction 为 Parquet 格式写入 Lakehouse Storage
共享 Schema：流式层与湖仓层使用统一的表 Schema 和元数据
Union Read：计算引擎对表执行查询时，自动合并实时数据（Arrow，秒级新鲜度，保留数天）和历史数据（Parquet，分钟级新鲜度，保留数月）
元数据同步：Fluss 与数据湖 Catalog 保持同步，Spark、StarRocks、Trino 等外部引擎可直接连接数据湖 Catalog 读取数据

支持的 Lakehouse 存储

Apache Paimon：已完成深度集成
Apache Iceberg：已支持，路线图中计划支持 Iceberg V3
Lance：面向 AI/向量场景的列式格式，已支持
Apache Hudi：路线图中
Delta Lake：路线图中

1.9 路线图与生态展望

六大方向

方向	关键规划
实时 AI 与 ML	实时特征存储（聚合合并引擎、Schema Evolution、时间点正确性）；多模态流数据（行/列/向量/变体/图像）；高性能 Rust/Python SDK 集成 PyTorch、Ray、Pandas、PyArrow
实时 Lakehouse	Iceberg V3、Hudi、Delta Lake 集成；In-Place Lakehouse（在已有湖表上定义 Fluss 表）；原生 Union Read 支持 Spark/Trino/StarRocks
流式分析	全局二级索引（非主键查询）；Delta Join 多流 + 左/右/全 Join 支持；Flink SQL 成本优化器（基于 Fluss 表统计）；完整 Spark Structured Streaming 集成
存储引擎	列式流过滤与聚合下推；完整 Schema Evolution（表重命名、列默认值）
云原生	去除 ZooKeeper 依赖；Zero Disks（直接 S3 写入，弹性无盘存储）
生态连接	日志采集 Agent 集成；Rust / C++ / Python 客户端 SDK

第二章技术文档系列撰写计划

2.1 系列总览

本系列计划撰写 10 篇技术文档，目标读者为大数据工程师、流计算开发者、数据架构师。每篇文档约 3,000-5,000 字，包含概念讲解、架构图解、代码示例和最佳实践。系列定位为「从入门到精通」的渐进式学习路径。

系列学习路径

阶段	篇目	主题
认知基础	第 1-2 篇	是什么、为什么、怎么装
核心使用	第 3-5 篇	表设计、Flink 集成、流式读写
高级主题	第 6-8 篇	Lookup Join、状态外部化、Lakehouse
实战进阶	第 9-10 篇	运维监控、生产最佳实践

每篇文档的标准结构

开篇导语：本文解决什么问题，适合谁阅读
核心概念：关键术语和架构理念解释
动手实践：可运行的代码示例和操作步骤
架构图解：使用 Mermaid 或 ASCII 图辅助理解
深入原理：底层实现机制分析
最佳实践：生产环境使用建议
常见问题：FAQ 和故障排查指南
下一篇预告：承上启下

2.2 文档详细计划

第 1 篇：「认识 Fluss」------ 新一代流式存储系统概览

目标： 帮助读者建立对 Fluss 的整体认知，理解其定位、价值和与传统方案的差异。

大纲：

为什么需要 Fluss：实时数据栈的「多系统税」问题
Fluss 的核心设计哲学：Streaming Storage 而非 Streaming Transport
六大能力支柱全景解读
Fluss vs Kafka vs Paimon：定位差异对比
适用场景：实时分析、特征存储、CDC 管道、实时数仓
Fluss 在 Apache 生态中的位置
快速体验：Docker Compose 一键启动

特色内容：

传统五系统架构 vs Fluss 统一基座的对比图
5 分钟 Docker 体验 Demo
与 Kafka 的技术决策树

第 2 篇：「Fluss 架构深入」------ CoordinatorServer、TabletServer 与存储引擎

目标： 深入理解 Fluss 的分布式架构、核心进程职责和数据存储机制。

大纲：

架构全景：CoordinatorServer + TabletServer + ZooKeeper + Remote Storage
CoordinatorServer 详解：元数据管理、Tablet 分配、Rebalance 机制
TabletServer 详解：LogStore（Segment/.index/.log）和 KvStore（RocksDB LSM）
数据分布层次：Database → Table → Partition → Bucket → Tablet
副本机制：LogTablet 多副本与 ISR 管理
远程存储层：S3 集成、分层存储、故障恢复
客户端架构：流式读写、批量读写、DDL 操作

特色内容：

Bucket 分配策略图解
写入路径与读取路径的完整流程图
Log 段文件物理布局示意

第 3 篇：「Fluss 表设计指南」------ 主键表与日志表的最佳实践

目标： 掌握两种表类型的使用场景、DDL 设计、分区和分桶策略。

大纲：

Log Table：仅追加场景的表设计（日志、事件流、指标数据）
Primary Key Table：可更新场景的表设计（维表、特征表、聚合结果）
分区策略：分区列选择原则、PK 表的分区约束
Bucket 数量设计：并发度与负载均衡的权衡
Schema 设计：字段类型、主键设计、nullable 约束
Schema Evolution：ADD COLUMN 操作与注意事项
实战案例：电商订单表、用户画像表、实时指标表

特色内容：

Bucket 数量计算器（基于数据量/并发度）
分区与桶的组合策略矩阵
三种实战场景的完整 DDL 示例

第 4 篇：「Fluss + Flink 集成实战」------ Catalog、Source 与 Sink

目标： 掌握 Fluss 作为 Flink Catalog 的完整使用方式，实现数据的流式读写。

大纲：

Fluss Catalog 注册与配置
创建和管理 Fluss 表（DDL）
实时数据写入：INSERT INTO 与 EXECUTE STATEMENT SET
流式读取：Flink SQL 流查询模式
批量读取：Flink SQL 批查询模式
更新与删除操作（UPDATE / DELETE）
DataStream API 集成
实战案例：实时订单宽表构建

特色内容：

完整的 Maven/Gradle 依赖配置
Flink SQL Client 交互式操作演示
流批一体的查询模式切换技巧

第 5 篇：「Fluss 列式流处理」------ Arrow 格式与查询优化

目标： 理解 Fluss 列式存储的优势，掌握查询优化技术。

大纲：

Apache Arrow 列式格式基础
Fluss 的 Arrow Log 格式设计
列裁剪（Column Projection）：只读取需要的列
谓词下推（Predicate Pushdown）：服务端过滤
分区裁剪（Partition Pruning）：跳过无关分区
复合裁剪的叠加效应：I/O 降低数量级
与行式存储（Kafka）的性能对比基准

特色内容：

200 列表查询的实际 I/O 对比测算
三种裁剪技术的协同效应分析
Arrow 零拷贝机制在 Flink 集成中的应用

第 6 篇：「Fluss Lookup Join」------ 维表关联的终极方案

目标： 深入理解 Lookup Join 机制，实现高效的实时数据富化，替代 Redis/HBase 维表方案。

大纲：

Lookup Join 的业务场景与挑战
Flink FOR SYSTEM_TIME AS OF 语法详解
Fluss PK 表作为维表：亚毫秒级 Lookup
缓存机制与性能调优
多表级联 Lookup Join
与传统维表方案（Redis、HBase、MySQL）的对比
实战案例：订单流实时富化客户和国家信息

特色内容：

Lookup Join 内部执行流程图解
与 Redis 方案的延迟、成本和维护复杂度对比
Insert-If-Not-Exists 幂等写入技巧

第 7 篇：「Fluss 状态外部化」------ Delta Join 与 Aggregation Merge Engine

目标： 掌握 Fluss 最核心的创新------将 Flink 状态外部化，实现无状态计算和秒级恢复。

大纲：

Flink 状态管理痛点：RocksDB 膨胀、慢恢复、扩缩容困难
Delta Join：Join 状态外部化到 Fluss 的原理
Aggregation Merge Engine：聚合状态外部化与合并策略
stateless compute 架构：计算存储分离的极致实践
故障恢复：从分钟级到秒级的质变
实战案例：实时用户行为去重与聚合
当前限制与路线图（多流 Join、非等值 Join）

特色内容：

传统 Flink 有状态 vs Fluss 无状态架构的故障恢复时序对比
Delta Join 内部数据流图解
成本优化 ROI 测算

第 8 篇：「Streaming Lakehouse 实战」------ 构建实时湖仓统一数据层

目标： 理解和实践 Fluss 的 Streaming Lakehouse 架构，实现流批统一的数据管道。

大纲：

Lakehouse 架构的实时性困境
Streaming Lakehouse 架构详解
Tiering Service：数据从 Arrow 到 Parquet 的 Compaction 流程
Union Read：实时数据 + 历史数据的联合查询
与 Iceberg 集成：配置、Compaction、外部引擎读取
与 Paimon 集成：配置、Compaction、外部引擎读取
实战案例：构建实时用户行为分析 Lakehouse

特色内容：

Tiering Service 数据流全链路图解
Iceberg vs Paimon 作为冷存储的选型对比
Spark/Trino/StarRocks 读取 Fluss Lakehouse 数据的操作示例

第 9 篇：「Fluss 运维实战」------ 部署、监控与故障排查

目标： 掌握 Fluss 的生产部署、监控配置和常见故障排查方法。

大纲：

部署方式：Docker Compose、Kubernetes（Helm Chart）、裸机部署
集群配置：CoordinatorServer 与 TabletServer 的关键参数
监控指标：fluss-metrics 模块、Prometheus + Grafana 集成
日志管理与审计
常见故障排查：OOM、磁盘满、网络分区、数据倾斜
扩缩容操作：增加/移除节点、调整 Bucket 数量
数据备份与恢复策略

特色内容：

生产环境推荐配置清单
Grafana Dashboard 模板
Top 10 故障案例及解决方案

第 10 篇：「Fluss 实战案例集」------ 完整解决方案与最佳实践

目标： 通过多个完整的端到端案例，展示 Fluss 在不同业务场景中的最佳实践。

大纲：

案例一：电商实时大屏------订单、支付、物流全链路实时分析
案例二：实时特征存储------AI/ML 场景的特征工程与服务
案例三：CDC 数据管道------MySQL Binlog → Fluss → 下游多引擎消费
案例四：实时风控系统------用户行为实时去重、计数和规则匹配
案例五：客户 360------多源数据实时融合构建客户统一视图
从 Kafka 迁移到 Fluss：迁移策略、兼容层使用、灰度方案
性能调优总结：Bucket、分区、资源配置的系统化优化方法

特色内容：

每个案例的完整架构图、代码仓库和运行指南
Kafka 到 Fluss 的迁移 Checklist
Fluss 生产就绪评估清单

附录

A. 参考文献与资源

资源	链接
Fluss 官方网站	https://fluss.apache.org/
GitHub 仓库	https://github.com/apache/fluss
Fluss vs Kafka 对比	https://fluss.apache.org/compare/kafka/
Fluss 2026 路线图	https://github.com/apache/fluss/discussions/2342
Apache Flink 官方文档	https://nightlies.apache.org/flink/flink-docs-stable/
Apache Arrow	https://arrow.apache.org/

B. 版本说明

本分析文档基于 Fluss 0.9.1-incubating 版本。随着项目快速发展，部分功能细节可能与最新版本有所差异。建议读者以官方文档为准。

Apache Fluss 项目深度分析与技术文档系列计划