官宣 | Fluss 0.7 发布公告：稳定性与架构升级

我们很高兴地宣布，Fluss 0.7 版本现已正式发布！本次版本围绕稳定性、架构升级、性能优化及安全性等方面进行了深入打磨，进一步夯实了其在生产环境中的可用性与可靠性。这一版本历时 3 个月的开发，累计完成 250+ 次代码提交 ，是 Fluss 迈向成熟生产级流处理平台演进的重要里程碑。

1、稳定性全面增强

在本版本中，我们投入了大量精力提升系统的稳定性。通过构建覆盖全链路、多场景故障模拟的稳定性测试，并结合真实业务数据的大规模压测，以及经历了阿里巴巴生产场景的高强度稳定性考验。在此过程中，我们累计修复并解决了 50+ 个关键问题 ，显著提升了 Fluss 核心模块的稳定性和系统整体的健壮性。主要改进包括：

• 机器上下线优化：重构了 ISR（In-Sync Replica）更新机制与副本同步逻辑，并增强了幂等性保障，有效提升了节点上下线时的稳定性，降低了因异常切换导致数据丢失的风险。

• Server 元数据缓存机制：引入了一致性的 Server 端 metadata 缓存机制，Client 获取 Metadata 请求不再全部依赖 ZooKeeper，而是优先从本地缓存获取，大幅减少了请求延迟，同时也显著减轻了 ZooKeeper 的负载压力。

• Server 机架感知支持：新增了对 Server 机架感知的支持，在副本分配过程中会自动避免将多个副本部署在同一"机架"（如可用区或物理机）下，从而显著提升了系统的容灾能力和高可用性。该特性在跨可用区部署以及大规模数据中心容灾场景中尤为适用。

• 表创建加速：通过引入元数据批量更新机制，大幅缩短了表的初始化时间。以 1024 buckets 的表为例，创建时间从原先的分钟级降低至毫秒级，性能提升了数十倍。

• 读写链路优化：

  • 引入主键表自动基于 bucket id 的 shuffle 机制，提升了写入吞吐；

  • 实现了写入时根据流量动态估算 batch size 的功能，提高内存池利用率，提高了写入吞吐；

  • 优化 Arrow 内存释放逻辑，进一步提升了读写作业的稳定性。

这些优化显著增强了 Fluss Server 与 Client 的稳定性表现，使得 Fluss 0.7 在多数场景下已具备了生产可用能力。

2、湖流一体架构升级

在 Fluss 0.5 版本中，我们首次引入了湖流一体的能力，实现了与 Lakehouse 系统的深度集成，并通过 Union Read 的功能显著降低了流存储成本，同时提升了 Lakehouse 中数据的时效性。然而，在早期实现中，该架构存在一定的局限性，影响了其在生产环境中的可扩展性和运维友好性。在 0.7 版本中，我们对湖流一体的整体架构进行了重构和升级，解决了这些问题。

弹性无状态服务

在之前的实现中，入湖服务（Lake Tiering Service）本质上是一个封装了 Fluss Source 和 Paimon Sink 的 Flink 同步作业。该作业依赖 Flink State 来记录同步的表信息及位点进度，因此是一个有状态服务。这种设计在实际运维中暴露出以下几个关键问题：

1. 单点故障风险高：每张表的生命周期绑定到具体的 Flink 同步作业上，一旦作业异常，该作业所承载的所有表的同步进度都会被阻塞。

2. 扩展能力单一：无法通过横向增加 Flink 作业数量来提升服务能力，只能通过纵向扩容提升单个作业的并发度和资源。

3. 调度不灵活：在大促等高负载场景下，难以区分不同表的同步优先级，也难以通过不同资源保障等级的 Flink 集群来保障高优表的同步延迟。

4. 同步进度不可见：由于同步位点进度存储在 Flink State 中，而 Flink State 是"黑盒"的，不方便查询和分析，给监控、排障以及一致性校验带来了较大困难。

为了解决上述问题，我们在 Fluss 0.7 将入湖服务重构升级成了一个弹性无状态服务。在设计上，一方面是无状态化 ，不再使用 Flink State 存储同步位点，而是将位点信息持久化在 Fluss 元数据中，并计划在下一版本中持久化到 Paimon v1.2 引入的快照属性中。另一方面是微批处理模型，Flink 作业不再持续订阅所有表，而是每次只处理一张表，处理完成后再主动请求下一个待同步的表，这有效降低 Fluss 端的连接压力和资源消耗，同时提升了攒批效率和吞吐表现。

通过上述优化，我们实现了真正意义上的弹性无状态入湖服务 。集群运维人员现在可以：

• **健壮的服务保障：**启动多个 Flink 作业，有效避免单点故障；

• **更好的资源效率：**可横向纵向扩展Flink资源，可随时停止部分作业以回收闲置资源；

• **灵活的任务调度：**每张表的每次同步任务能根据当前系统负载动态调度到最合适的作业中执行；

• **透明的进度追踪：**同步位点信息可查询可分析，便于异常排查；

所有操作均保证端到端的数据一致性，而且无状态的设计使我们不再强依赖 Flink 框架，为未来使用更轻量、更弹性的资源提供了可能，例如 运行在 FaaS (Function as a Service) 之上。

湖格式插件化

早期的湖流一体实现过于绑定 Paimon 湖格式，这在接入其他湖格式（如 Apache Iceberg）时带来了较大的适配成本和耦合风险。在新版本中，我们将所有与湖格式交互的地方进行了接口抽象和组件化设计，使得 Iceberg 等其他湖格式能方便地通过插件化方式接入。

原生 Flink 命令提交

在以前，用户需要通过 Fluss 提供的 lakehouse.sh脚本启动入湖服务。虽然脚本简化了启动流程，但也在一定程度上限制了部署的灵活性，特别是在面对多种 Flink 部署模式和产品化平台时，兼容性和易用性面临挑战。新版本中移除了lakehouse.sh启动脚本，转而支持通过标准的 Flink 原生命令flink run直接拉起入湖服务，能原生兼容不同的 Flink 部署模式，以及降低用户的学习成本和企业的对接成本。

3、流式分区裁剪

在数仓和 Lakehouse 架构中，分区（Partition） 是优化数据存储与查询性能的核心机制之一。其核心作用在于通过将大规模数据集按特定维度（如时间、地域、业务逻辑等）划分为更小的独立单元，并结合分区字段上的查询条件下推，减少扫描的分区数，从而显著提升查询效率。

Fluss 0.7 首次将这一理念和能力引入到了流存储中，实现了流读时的分区裁剪。当 Flink SQL 中指定了分区键的过滤条件，如 nation_key = 'US'，Fluss Source 只会订阅符合这一条件的分区，显著减少网络传输与计算开销。除此之外，我们还支持了如下的高级分区功能，让分区裁剪更加易用：

• 多级分区支持：支持多维度组合分区策略（如"时间/地域/业务"的嵌套结构），提升数据组织灵活性。

• 动态分区创建：根据写入数据自动识别并创建所需的分区，无需手动预创建。

• 自动分区发现：Fluss Source 会实时订阅新创建的分区，并自动将符合分区条件的分区加入到读取任务中。同时，在分区被清理或删除时，也会自动停止对该分区的读取。

我们基于淘宝真实业务数据，对多级分区表的写入与读取性能进行了系统性压测，验证了分区裁剪能力的实际效果。测试对比了非分区表与分区表（共自动创建 20 个分区）在流式写入场景下的吞吐表现。结果显示：两者在写入吞吐和资源消耗上差异极小。表明多级分区与动态分区创建机制并未对写入性能造成明显影响。

同时在相同数据规模下，我们压测了非分区表和分区表的流式读取性能，分别测试了三种分区条件下的流式读取性能：无条件 、中等匹配 （命中5个分区）、精确匹配（命中1个分区）。从结果可见，在分区条件仅匹配 1/20 的分区时，网络流量减少了约 20 倍 ，处理耗时降低了近 9 倍 ，展现出分区裁剪在流式读取中的巨大性能优势。

Fluss 致力于成为最适合流式分析的存储引擎。流式分区裁剪是 Fluss 继支持流式列裁剪之后引入的又一查询下推的能力，在未来的版本中我们还将引入条件下推的功能，实现 Arrow Batch 粒度的 I/O 裁剪能力。

4、企业级安全

为满足企业在生产环境的安全需求，Fluss 0.7 完整地支持了认证与鉴权机制。认证 是确认客户端身份的过程，Fluss 支持了插件化的认证机制，并内置支持了 SASL/PLAIN 认证机制，支持使用 JAAS（Java身份验证和授权服务）配置服务端和客户端的身份凭证。鉴权 是在身份确认之后，控制该身份可以访问哪些资源、执行哪些操作，Fluss 通过 ACL（Access Control List）机制实现了细粒度的权限控制，支持Cluster、Database、Table 多级的访问控制。我们还集成了 Flink SQL 的 CALL 命令，方便用户管理 ACL 权限。例如，如下命令对用户Tim赋予了mydb数据库的读取权限：

CALL admin_catalog.sys.add_acl(
    resource => 'cluster.mydb', 
    permission => 'ALLOW',
    principal => 'User:Tim', 
    operation => 'READ',
    host => '*'
);

如需了解更多细节，请参考 Fluss 官方文档 - 安全模块。

5、Flink DataStream Connector

Fluss 0.7 正式发布 DataStream Connector ，支持以 Source 和 Sink 的形式对接 Flink DataStream API，可读写日志表和主键表。通过该功能，用户可以将 Fluss 表无缝接入 Flink 流处理作业，实现端到端的实时数据处理流程。以下是一个从 Fluss 表读取数据并转换为 Flink DataStream 的代码示例：

FlussSource<Order> source = FlussSource.<Order>builder()
    .setBootstrapServers("localhost:9092")
    .setDatabase("mydb")
    .setTable("orders")
    // 列裁剪
    .setProjectedFields("orderId", "amount")
    .setStartingOffsets(OffsetsInitializer.earliest())
    .setDeserializationSchema(new OrderDeserializationSchema())
    .build();

DataStreamSource<Order> stream = env.fromSource(
    source,
    WatermarkStrategy.noWatermarks(),
    "Fluss Source"
);

如需了解更多使用方式与配置参数，请参考 Fluss 官方文档 - DataStream 模块。

6、Fluss Java Client

在这一版本我们也正式推出了 Fluss Java Client，为开发者提供了一套面向结构化流表的客户端。该 Client 构建了两个核心 API 模块：

• Table API：以表（Table）为核心的数据交互接口，支持流式读写、更新删除、点查询等能力；

• Admin API：以元数据管理为核心的管控接口，可用于集群管理、表生命周期操作及权限控制等运维场景。

此外，Fluss Java Client 具备良好的 向前兼容与向后兼容能力，能够适配不同版本的 Fluss 集群，保障用户在升级过程中服务的平滑过渡。借助 Fluss Java Client，开发者既可以构建基于 Fluss 的在线业务应用和数据采集服务，也可以开发 Fluss 管控平台、运维监控系统等企业级组件。如需了解详细使用方式，请参考官方文档 Fluss Java Client 使用指南。

Fluss 的底层数据存储基于 Apache Arrow 构建，具备跨语言扩展的良好基础。我们计划在后续版本中推出 Fluss Python Client ，结合 PyArrow 强大的生态支持，打通与 Pandas、DuckDB 等主流数据分析工具的连接路径，进一步降低实时数据探索与分析的门槛。

后续规划

在下一个版本中，我们将持续提升系统的稳定性与运维能力，计划引入 滚动升级 和 集群扩缩容 等关键运维功能。此外，我们将基于湖流一体的插件式架构，进一步扩展对主流数据湖格式的支持，重点推进对 Apache Iceberg 的集成。同时，我们将探索 Fluss 在 AI 多模态数据场景下的应用可能性，支持多模态数据的实时摄入，以及湖流一体框架对 Lance 格式的集成支持。

值得一提的是，Fluss 0.7 是我们在 Alibaba 组织下发布的最后一个版本。下一版本将正式在 Apache 孵化器中与大家见面！欢迎更多开发者加入社区共建，一起打造下一代的实时数据架构！

---

贡献者列表

Fluss 社区感谢对此版本做出贡献的每一位贡献者（按首字母排序）：

Benchao Li, CaoZhen, Feng Wang, Giannis Polyzos, HZY, Hongshun Wang, Jark Wu, Junbo wang, Kerwin, Leonard Xu, MehulBatra, Michael Koepf, Min Zhao, Nicholas Jiang, Radek Grebski, Rohan Dubey, Xiaojian Sun, Yang Guo, dao-jun, gkatzioura, luoyuxia, majialong, xiaozhou, yunhong, yuxia Luo, yx9o, zhangmang, 道君

关于 Fluss

GitHub：github.com/alibaba/flu... 关注项目和参与社区，欢迎 star 🌟

官网：alibaba.github.io/fluss-docs 查看文档和试用