Apache Fluss 湖流一体架构解析：实时数仓与 AI Agent 数据底座

1. 项目概述从 Flink 的“表弟”到 Apache 的“新星”如果你最近在关注大数据和实时计算领域那么“Apache Fluss”这个名字一定在你的时间线上高频出现。就在不久前Apache 软件基金会正式宣布 Fluss 从孵化器毕业成为顶级项目Top-Level Project, TLP。这标志着一个新的里程碑但很多朋友可能还是一头雾水Fluss 到底是什么它和我们已经熟知的 Flink 是什么关系所谓的“湖流一体”和“Agentic Lake”又意味着什么今天我就从一个一线架构师的视角结合我跟踪这个项目近两年的观察和近期的一些技术预研来给大家彻底拆解一下 Fluss 的核心价值以及它为何能开启一个所谓的“全面实时化时代”。简单来说你可以把 Apache Fluss 理解为 Apache Flink 在数据湖Data Lake领域的“亲表弟”但它解决的是一系列 Flink 不那么擅长、或者说设计初衷不同的问题。Flink 的核心是“有状态流计算”它擅长处理无界数据流保证精确一次Exactly-Once的状态一致性。而 Fluss 的核心是“湖流一体”Lakehouse Streaming它关注的是如何将数据湖如 Iceberg、Hudi、Delta Lake变成一个实时、可增量处理、并且能高效支持智能体Agent等新型负载的“活性”数据存储。它的毕业意味着这套理念和技术栈得到了开源社区的广泛认可已经足够成熟和稳定可以投入生产环境去解决那些让我们头疼已久的“实时数仓”、“实时特征工程”和“AI 应用数据新鲜度”问题了。2. 核心需求解析为什么我们需要“湖流一体”要理解 Fluss 的价值我们必须先看看当前数据架构面临的几个核心痛点。我称之为“数据湖的三大尴尬”。2.1 痛点一批流割裂的“精分”体验这是最经典的问题。过去几年Lambda 架构大行其道一条批处理管道通常用 Spark 写 T1 的数据到 Hive 或 Iceberg一条流处理管道用 Flink 写实时数据到 Kafka 或 ClickHouse。结果就是业务方要查实时数据得找流处理团队要查历史明细或做复杂分析得找批处理团队。同一份业务逻辑比如用户画像的标签计算要写两套代码维护两套资源数据口径还经常对不上。开发效率低运维成本高数据一致性难以保障。Kappa 架构试图用全流处理解决但对海量历史数据的复杂扫描查询OLAP又力不从心成本高昂。2.2 痛点二数据湖的“静默”瓶颈数据湖Iceberg/Hudi/Delta解决了 Hive 的诸多问题如 ACID 事务、模式演进、时间旅行等让大数据平台进入了“湖仓一体”Lakehouse时代。但是传统的数据湖写入和读取本质上还是基于“快照”Snapshot的批处理范式。即使流式写入如 Flink Streaming File Sink下游消费者读取时往往也需要等待一个完整的快照提交或者自己处理复杂的增量扫描逻辑。这导致了数据新鲜度Freshness的延迟从数据产生到可查询可能有分钟甚至十分钟级的滞后。对于风控、实时推荐、监控告警等场景这是不可接受的。数据湖像一个大水库但水龙头写入和取水口读取都不够“流畅”。2.3 痛点三AI Agent 对数据的“高渴求”这是最新的、也是最迫切的驱动因素。大模型和 AI Agent 的爆发对底层数据系统提出了前所未有的要求。一个智能体Agent在决策时可能需要实时获取用户最新的点击流、订单状态、库存变化并结合历史行为模式进行分析。这要求底层存储既能提供低延迟毫秒到秒级的点查Point Lookup和增量数据获取又能支持对海量历史数据的复杂向量检索或OLAP 分析。传统的数据湖在低延迟点查上性能不佳对象存储的延迟高而传统的 KV 数据库或实时数仓又难以承载 PB 级的历史数据和复杂的分析查询。我们需要一个既能“流”又能“湖”既能“快”又能“大”的统一存储层。这就是“Agentic Lake”概念的核心——一个为 AI Agent 时代设计的、具备实时能力的数据湖。Fluss 瞄准的正是解决以上三大痛点。它不是一个取代 Flink 的计算引擎而是一个专注于数据湖实时化的存储与服务层。它让数据湖“流”了起来。3. 技术架构深度拆解Fluss 如何实现“湖流一体”Fluss 的架构设计非常精巧其核心思想可以概括为以增量Change为核心统一批流读写接口并提供低延迟的服务化能力。下面我们分层来看。3.1 核心抽象Change Log 作为一等公民这是 Fluss 与以往方案最根本的不同。在传统数据湖中核心抽象是“表”Table由一系列数据文件Data Files和元数据Metadata组成。而在 Fluss 中核心抽象是“变更日志”Change Log。它将表上的每一次插入INSERT、更新UPDATE、删除DELETE都建模为一条不可变的变更记录。这些变更记录被持久化存储并赋予一个全局有序的序列号Sequence Number。注意这里说的 Change Log 不同于数据库的 Binlog。它是在数据湖文件格式Parquet/ORC之上的一层逻辑抽象记录了行级别的变更并且是幂等和可重放的。这是实现流式读取和端到端一致性的基石。所有对 Fluss 表的写入无论是来自批处理作业Spark还是流处理作业Flink都首先被转化为 Change Log 并追加存储。然后Fluss 的后台合并Compaction进程会定期将一批 Change Log 合并成新的数据文件并更新元数据快照。这个过程类似于 LSM-Tree 的 Compaction但发生在对象存储S3/OBS上。带来的好处统一的增量源下游消费者无论是流作业还是批作业都可以通过订阅从某个序列号开始的 Change Log来获取精确的增量数据无需自己解析文件差异。简化一致性由于变更有序且幂等实现类 CDCChange Data Capture的端到端 Exactly-Once 语义变得更容易。支持时间旅行与回滚因为每条变更都被记录可以轻松回溯到历史上任意一个时间点的数据状态。3.2 读写路径剖析让流式成为默认选项写入路径 当一个 Flink 作业向 Fluss 表写入数据时流程如下Flink 的FlussSink会将数据缓冲区中的记录在 Checkpoint 周期内批量打包成一批 Change Log 条目。在一个 Checkpoint 屏障Barrier触发时Sink 会将这些 Change Log 作为一个事务原子性地提交到 Fluss 的元数据中并生成一个新的快照版本。提交成功后这批数据立即对下游消费者可见。下游无需等待文件合并完成。读取路径 - 流式读取 这是 Fluss 的亮点。下游 Flink 作业可以通过FLINK SQL像查询 Kafka 一样查询 Fluss 表-- 从 Fluss 表中读取增量数据就像读一个 Kafka Topic SELECT * FROM fluss_table /* OPTIONS(scan.modeincremental, start-snapshot-id123) */;Fluss Connector 会内部追踪消费的序列号自动从 Change Log 中拉取新的变更并转换成 Flink 的Changelog流包含I, -U, U, -D 消息。这彻底替代了以前需要自己用StreamingFileSink加CREATE TABLE ... WITH (connectorfilesystem)然后手动处理watermark和scan模式的复杂配置。读取路径 - 批式读取与点查 对于批处理或即席查询Fluss 完全兼容原有数据湖格式。Spark/Trino/Presto 可以直接通过 Iceberg/Hudi 的原生 Connector 读取合并后的数据文件享受数据湖的所有能力。同时Fluss 提供了额外的“索引服务”和“行级缓存”选件可以将热点行的最新版本缓存在内存或本地 SSD 中从而实现毫秒级的点查满足 Agent 对实时数据拉取的需求。3.3 与 Flink 的共生关系明确的分工很多人会问有了 Fluss还要 Flink 吗答案是绝对需要而且两者是绝配。Flink 是强大的“流计算大脑”负责复杂的业务逻辑处理、窗口计算、状态管理、多流 Join 等。Fluss 是专业的“流式存储枢纽”负责将 Flink 处理后的结果以流式、可增量消费的方式持久化到数据湖中并管理其生命周期。你可以这样类比Flink 是工厂里高效的生产线而 Fluss 是一个高度自动化、带有传送带Change Log的智能仓库。生产线Flink把产品数据制造出来直接放到传送带写入 Fluss上。传送带立刻将新产品运送到仓库的“新到货区”增量可见同时后台机器人Compaction慢慢把新货整理到正式的货架上合并成列存文件。其他生产线或配送车下游作业既可以从传送带上直接取新货流读也可以从整理好的货架上大批量取货批读。4. 实操指南快速搭建一个 Fluss Flink 的实时数仓 demo理论说了这么多我们来点实际的。下面我将演示如何用最短的时间在本地搭建一个基于 Fluss 和 Flink 的简易实时数仓体验从 Kafka 接入数据流式写入 FlussIceberg 格式再流式读出的全过程。4.1 环境准备与组件部署我们采用 Docker Compose 来一键拉起所有服务包括Flink 1.18(Standalone Session Cluster)Apache Kafka(作为数据源)Apache Fluss(使用 LocalFileSystem 作为存储模拟 S3)Flink Web UI(用于提交作业和监控)首先创建一个docker-compose.yml文件。这里的关键是配置 Fluss 的元数据存储我们使用嵌入式 Derby 简化和文件存储路径。version: 2.2 services: jobmanager: image: flink:1.18-scala_2.12 ports: - 8081:8081 command: jobmanager environment: - | FLINK_PROPERTIES jobmanager.rpc.address: jobmanager taskmanager.numberOfTaskSlots: 4 state.backend: hashmap execution.checkpointing.interval: 10s execution.checkpointing.externalized-checkpoint-retention: RETAIN_ON_CANCELLATION volumes: - ./fluss-jars:/opt/flink/usrlib - ./data:/data taskmanager: image: flink:1.18-scala_2.12 depends_on: - jobmanager command: taskmanager environment: - | FLINK_PROPERTIES jobmanager.rpc.address: jobmanager taskmanager.numberOfTaskSlots: 4 volumes: - ./fluss-jars:/opt/flink/usrlib - ./data:/data kafka: image: confluentinc/cp-kafka:latest depends_on: - zookeeper ports: - 9092:9092 environment: KAFKA_BROKER_ID: 1 KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181 KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092 KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1 zookeeper: image: confluentinc/cp-zookeeper:latest environment: ZOOKEEPER_CLIENT_PORT: 2181 ZOOKEEPER_TICK_TIME: 2000接下来我们需要下载 Fluss 的 Flink Connector Jar 包。目前 Fluss 刚毕业你可以从 Apache 官方仓库或项目 GitHub Release 页面下载fluss-flink-connector-*.jar。假设我们下载了fluss-flink-connector-0.1.0.jar将其放入./fluss-jars目录下这样 Flink 集群启动时就能加载到。4.2 创建 Fluss Catalog 与表启动所有服务docker-compose up -d。等待片刻后通过 Flink SQL Client 或编写一个简单的 Java 程序来执行以下 SQL。首先我们需要创建一个 Fluss Catalog它指向本地的文件系统路径/data/fluss_warehouse。-- 在 Flink SQL 中创建 Fluss Catalog CREATE CATALOG fluss_catalog WITH ( type fluss, warehouse file:///data/fluss_warehouse ); USE CATALOG fluss_catalog; -- 创建一个数据库 CREATE DATABASE IF NOT EXISTS realtime_dw; USE realtime_dw; -- 创建一张 Fluss 表底层格式为 Iceberg CREATE TABLE user_behavior ( user_id BIGINT, item_id BIGINT, category_id INT, behavior STRING, ts TIMESTAMP(3), -- 定义事件时间和水位线 WATERMARK FOR ts AS ts - INTERVAL 5 SECOND ) WITH ( connector fluss, format iceberg, -- 指定底层文件格式 location file:///data/fluss_warehouse/realtime_dw.db/user_behavior );实操心得在早期版本中Fluss 表的配置参数可能变化较快。务必查阅你所用版本的最新官方文档。location参数是必须的它决定了表数据在文件系统中的具体存储位置。4.3 构建端到端实时管道现在我们模拟一个经典场景从 Kafka 实时读取用户行为日志进行简单清洗例如过滤无效数据然后实时写入 Fluss 表最后再启动一个流作业实时消费 Fluss 表中的增量变化。步骤1向 Kafka 写入模拟数据我们可以用一个小程序或者直接在另一个终端用kafka-console-producer模拟数据。假设 Kafka 有一个 topic 叫user_behavior_topic。步骤2创建 Kafka 源表并写入 Fluss-- 创建 Kafka 源表 CREATE TABLE kafka_user_behavior ( user_id BIGINT, item_id BIGINT, category_id INT, behavior STRING, timestamp BIGINT, ts AS TO_TIMESTAMP(FROM_UNIXTIME(timestamp / 1000)), PROC_TIME AS PROCTIME() ) WITH ( connector kafka, topic user_behavior_topic, properties.bootstrap.servers localhost:9092, properties.group.id fluss-test, format json, scan.startup.mode earliest-offset ); -- 将 Kafka 数据实时写入 Fluss 表 INSERT INTO user_behavior SELECT user_id, item_id, category_id, behavior, ts FROM kafka_user_behavior WHERE user_id IS NOT NULL AND behavior IS NOT NULL;提交这个 INSERT 作业后Flink 就会开始工作。你可以去 Flink Web UI (localhost:8081) 查看运行中的作业。步骤3流式读取 Fluss 表的变化这是体验“湖流一体”魔力的时刻。在另一个 SQL 会话中或者新提交一个作业-- 以增量模式流式读取 user_behavior 表 SELECT * FROM user_behavior /* OPTIONS(scan.modeincremental) */;你会看到这个 SELECT 查询会作为一个流作业持续运行并打印出每一批新写入 Fluss 表的数据。即使后台的 Compaction 还没发生你也能立刻读到新数据。这就是“流式读取”的核心体验。4.4 关键配置与性能调优要点在生产环境中以下几个配置对性能和稳定性至关重要Checkpoint 间隔与 Fluss 提交Flink Checkpoint 间隔直接决定了 Fluss 提交变更的延迟和吞吐量。间隔太短如1s会给存储系统如S3的元数据操作带来巨大压力间隔太长如5分钟则会导致数据可见延迟高。建议从10-30秒开始调整并观察 Fluss 元数据存储如RDS的负载。Change Log 的保留与合并Fluss 需要管理 Change Log 的生命周期。关键参数是change-log.retention.duration默认7天和compaction.interval默认1小时。如果写入流量巨大会产生大量小 Change Log 文件影响读取性能。需要根据数据量和查询模式调整合并策略。对于几乎只有追加INSERT操作的表可以调大合并间隔对于频繁更新UPDATE的表则需要更频繁的合并来优化点查性能。索引服务与点查加速如果业务有大量基于主键如user_id的点查需求务必启用 Fluss 的索引服务。这通常需要部署一个额外的Fluss Index Server组件它会将主键到最新文件位置的映射保存在 RocksDB 或类似存储中。配置index.enabled true并指定index.server.address。写入并行度与文件大小Flink Sink 的并行度会影响生成的数据文件数量。并行度太高会产生大量小文件影响后续批查询性能。可以通过设置 Fluss Sink 的sink.parallelism和target-file-size-bytes如256MB来控制输出文件的大小在流式写入延迟和批查询性能之间取得平衡。5. 典型应用场景与架构升级理解了 Fluss 是什么和怎么用之后我们来看看它能在哪些具体场景中带来架构上的革新。5.1 场景一实时数仓Real-time Data Warehouse的简化这是最直接的应用。传统的实时数仓链路Kafka - Flink ETL - Kafka/Kudu/ClickHouse。Kudu/ClickHouse 容量有限成本高且与离线 Hive 数仓是两套系统。升级为 Fluss 架构Kafka - Flink ETL - Fluss(Iceberg)。优点一套存储实时层和离线层都统一到 Iceberg 表上彻底消除数据不一致。成本降低对象存储S3/OBS的成本远低于专用 OLAP 数据库。灵活性提升下游既可以流式消费最新数据做实时大盘也可以用 Trino/Doris 对全量数据做即席分析。回溯与修正利用 Fluss 的 Change Log可以轻松重放历史某段时间的数据用于数据回溯或错误修正这在旧架构中非常困难。5.2 场景二实时特征平台Real-time Feature Store这是 AI 工程化的核心。模型训练需要历史特征批特征在线推理需要最新特征实时特征。传统方案需要维护两套特征管道。升级为 Fluss 架构将特征表统一存储在 Fluss 中。批特征Spark 任务每天全量/增量计算特征写入 Fluss。实时特征Flink 任务处理实时事件以流的方式更新/追加 Fluss 特征表中的行。特征服务在线推理服务通过 Fluss 提供的低延迟点查接口需启用索引毫秒级读取用户的最新特征向量。同时特征平台可以直接基于 Fluss 表做特征监控和数据质量校验。5.3 场景三CDC 入湖与实时同步将 MySQL、PostgreSQL 等业务数据库的变化实时同步到数据湖是一个强需求。传统上用 Flink CDC 读取 Binlog写入 Kafka再由另一个作业写入 Hudi/Iceberg。链路长延迟高。升级为 Fluss 架构Flink CDC - Fluss。Flink CDC Connector 直接作为 Source将INSERT/UPDATE/DELETE事件转换成 Flink 的Changelog流。使用 Fluss Sink 直接消费这条 Changelog 流。Fluss 内部会完美处理这些变更操作将其转化为自己的 Change Log。下游其他系统可以直接从 Fluss 流式消费这些变更或者查询合并后的快照。链路从两条减为一条端到端延迟显著降低运维复杂度也大幅下降。5.4 面向 Agentic Lake 的展望“Agentic Lake” 不是一个具体的产品而是一种架构范式。Fluss 是构建这种范式的关键拼图。在一个典型的 Agentic Lake 架构中统一存储层Fluss 管理的 Iceberg/Hudi 表存储所有结构化和半结构化数据。实时摄入层Flink Fluss 处理所有实时事件流和 CDC 数据确保数据在秒级内可见。向量化与索引层在 Fluss 表之上通过额外的进程如 Spark 作业将文本字段转换为向量并建立向量索引如 HNSW写入到同一张表的特定列中或关联的向量索引表中。智能体查询层AI Agent 在决策时通过统一的查询接口可能是一个封装了 Fluss SDK 的微服务同时发起请求点查通过 Fluss 索引服务获取用户当前的最新状态如购物车商品、账户余额。向量检索通过向量索引从历史数据中寻找相似案例或内容。OLAP 分析通过 Trino 等引擎对宽表进行复杂聚合获取群体统计信息。 所有这些查询都基于同一份实时更新的数据保证了 Agent 决策依据的一致性和新鲜度。6. 生产落地考量与避坑指南技术很美好但上线有风险。根据我对类似系统如早期 Hudi/Flink 集成的落地经验以下是几个必须提前规划和测试的关键点。6.1 元数据存储的选型与高可用Fluss 的核心是元数据记录了所有表、快照、Change Log 的指针和 schema 信息。社区版默认可能推荐使用 MySQL/PostgreSQL。在生产环境这必须是高可用的。避坑指南切勿使用单实例数据库。必须部署为高可用模式如 MySQL Group Replication, PostgreSQL Patroni。并做好定期备份。同时要监控数据库的连接数、CPU 和 IOPSFluss 在频繁提交时会对元数据库产生较大压力。6.2 对象存储的性能与一致性Fluss 的数据文件存储在 S3、OSS、HDFS 等对象存储或分布式文件系统上。对象存储的“最终一致性”模型和请求速率限制如 S3 的 3500 PUT/秒是需要重点关注的。实操心得小文件问题流式写入极易产生小文件。除了调整 Flink 并行度和目标文件大小一定要启用并合理配置 Fluss 的Compaction服务将其作为一个常驻后台进程运行定期合并小文件。清单Listing性能数据湖的很多操作如时间旅行、增量扫描需要列出目录下的文件。对象存储的 List 操作是昂贵的。确保 Fluss 的元数据缓存配置得当并考虑使用像Alluxio这样的缓存层来加速热点数据的访问尤其是对频繁点查的场景。一致性保证确保 Fluss 版本与你使用的对象存储的语义兼容。例如某些版本的 S3 可能对原子重命名有特定要求。6.3 监控与运维体系的构建一个没有完善监控的系统等于盲人骑马。需要监控至少以下几个层面Flink 作业层面Checkpoint 时长与成功率、反压情况、算子延迟。Fluss Sink 的pending-commits指标如果持续增长说明提交可能遇到瓶颈。Fluss 服务层面Change Log 的生成速率和积压量、Compaction 任务的成功率与耗时、元数据库的查询延迟。数据质量层面端到端延迟从数据产生到可查询、数据行数的准确性与源库对比、schema 变更的处理是否正常。建议将 Fluss 暴露的 Metrics通常通过 JMX 或 HTTP接入到你的 Prometheus Grafana 监控体系中。6.4 成本评估与优化引入新技术总会带来新的成本项计算成本运行 Flink 作业和 Fluss Compaction 服务的资源。存储成本对象存储的费用。注意 Change Log 会额外占用存储空间尽管是压缩的需要根据保留策略评估。元数据存储成本RDS 的费用。网络成本跨可用区或跨区域的数据传输费用如果计算和存储分离。优化方向根据数据冷热程度配置生命周期规则将冷数据从标准存储转移到低频或归档存储。调整 Compaction 策略在查询性能和存储/计算成本之间取得平衡。过于频繁的合并节省了查询时间但增加了计算成本。对于点查需求强烈的表启用索引服务这虽然增加了少量存储和计算开销但换来了百倍千倍的查询性能提升总体成本可能是下降的。Apache Fluss 的毕业标志着“湖流一体”从一个美好的愿景走向了可大规模工程实践的阶段。它并不是要颠覆现有的 Flink 或数据湖生态而是作为一块关键的“连接器”和“加速器”填补了流处理与数据湖存储之间的鸿沟。对于正在被批流融合、实时智能需求折磨的架构师和工程师来说Fluss 提供了一个优雅且强有力的新选项。当然任何新技术在生产环境的规模化应用都需要一个谨慎的验证过程从核心场景试点开始逐步完善监控、运维和容灾体系才是稳妥之道。我个人的体会是它的设计理念非常契合云原生时代对数据系统“弹性、实时、统一”的诉求值得投入精力深入研究和跟进。