2024 年 Flink Forward Asia 大会上，阿里云宣布正在主导 Apache Flink 2.0 的研发。四个月后，Flink 2.0 正式发布，彼时距离奠定其流计算技术范式的 1.0 版本发布已过去整整九年。Flink 不仅完成了一次里程碑式的自我革新，更推动其核心架构向拥抱 AI 时代迈出了坚实的一步。
在 CommunityOverCode Asia 2025 的会场之外，我们有幸再次对话阿里巴巴开源委员会大数据 AI 方向副主席、阿里云计算平台事业部开源大数据平台负责人、阿里云研究员王峰（花名：莫问）。时隔一年，我们将焦点对准了 Flink 2.0 的架构蜕变、生态扩张，以及在 AI 时代的“剑锋”所向。
以下为访谈实录，为方便阅读，略有删改。
01Flink 2.0 的架构仅仅是一个基础和开始
思否：作为 Flink 的里程碑版本，Flink 2.0 在核心架构上有哪些主要的演进方向？
王峰：Flink 2.0 的核心架构演进，目前主要体现在“存算分离”上，这其实是朝彻底云原生化迈出的重要一步。
同时，我认为 Flink 2.0 的架构仅仅是一个基础和开始。它并非一次性发版就宣告结束，而是在这个最基本的架构升级之上，未来我们将持续在多个重要方向上进行演进。比如流批一体的计算能力，针对 AI 场景的一些升级，以及我们可能现在还没有提到的一些新的流式增量计算，都是需要在 Flink 2.0 的这个架构上面去演进的重要方向。这也是我们当初希望对 Flink 进行一次大的架构升级的重要原因。
但推动这一重大变革，不仅需要面向未来的洞察，还要有对过往经验的反思。我们要直面 Flink 1.0 版本之前存在的一些架构限制，以及由此产生的历史遗留问题。这确实导致我们在面向 AI 场景，包括实时数据湖计算以及增量计算等场景时受到了一些制约。
思否：您提到 Flink 2.0 在核心架构上的主要演进体现在“存算分离”上，那么请展开分享一下这一重大架构变革带来了哪些显著的优势？
王峰：如果我们能实现存算分离架构，那么 Flink 的状态，尤其是大状态，就可以与我们的计算解耦。这是 Flink 2.0 的一个重要的创新结果——分离式状态管理。优势主要有三个：
第一，实现更大规模的状态管理。随着实时计算规模和应用场景的不断扩大，Flink 的状态会越来越大，如果与计算紧密耦合，将会带来非常大的负担。包括现在的 OLAP 引擎也在做存算分离，通过将数据存储与计算解耦，解决大状态带来的问题，以支持更复杂的流计算场景。
第二，提升效率和资源利用率。状态的大小和规模，以及计算 CPU 对弹性的要求是不一样的。所以，当我们实现存算分离后，就可以将 Flink 的计算资源和状态存储的 I/O 资源分别管理，以更大的灵活性支持实时计算场景。
第三，在容灾和稳定性方面也有巨大的价值。尤其是在云厂商的场景下，我们看到越来越多的客户关注系统的稳定性和高可用性。如果我们将状态和计算分离，状态就可以存在于一个高可用的存储之上，例如支持跨可用区甚至是跨地域的架构。这样一来，当出现系统级的灾难，无论是硬件故障还是网络问题，我们都可以在另一个可用区快速恢复业务，而不会丢失数据。
思否：是不是可以这么理解，在存算分离的基础之上，Flink 2.0 还有两个主要演进方向，一个是流批一体计算，还有一个是面向 AI 场景的升级？
王峰：对的。流批一体计算和 AI 场景是我们关注的两个非常不同的方向。AI 场景的演进相对来说比较容易理解，因为现在所有项目和大数据方向都在朝着支持 AI 场景的方向发展。但是，流批一体需要落地到一个具体的场景中，就是要明确你在哪里做流批一体。
现在行业内的共识是，Lakehouse 正在逐渐成为主流。它是在云对象存储之上，构建一个开源开放格式的数据分析架构，并且融入了数仓的理念。然而，无论是基于现在比较主流的 Apache Iceberg 还是基于传统的 Apache Hive 去构建数据库，目前大多仍停留在全量计算层面，或者只能实现时效性非常低的增量计算，比如小时级别。这是因为它们难以真正实现数据湖的实时化处理。
因此，我们的目标是让流批一体能够在 Lakehouse 这个架构上实现“全增量一体”。相较于过去在 Kafka 上运行流计算，在 Hive 上运行批计算，Flink 2.0 在数据湖上创新性落地流批一体，将展现出更高的业务价值。
思否：我们注意到 Flink 2.0 的另一个特性是引入了物化表，请详细介绍一下它的价值。
王峰：物化表这个概念其实与 Snowflake 提出的 Dynamic Table ，还有 Databricks 的 Delta Live Tables (DLT)相似，都是希望通过提供一套统一的 SQL 表达方式，让用户能够以低成本、低延迟的方式实现增量计算，并支持全量数据的回刷和计算。
这让流批一体计算在 Lakehouse 上有了理想的落地场景。它可以在 Lakehouse 上加速传统的离线计算，将其从全量的离线场景升级到增量场景。用户只需编写一套 SQL，就能让它在 Lakehouse 上以不同的模式运行，满足业务需求。
尽管业务逻辑通过一套 SQL 保持统一，但用户对数据时效性的需求往往存在差异。比如白天可能需要分钟级甚至秒级的增量处理，确保数据持续不间断更新。而在晚上，出于业务逻辑变更或特殊要求，可能需要进行全量回刷或订正，以确保每日全量计算的严谨性。在这种架构下，我们定义的物化表具有两大价值：
首先，它能大幅简化架构复杂性。用户只需编写一套 SQL 并指定数据时效性，即可满足不同运行周期和时效性需求，无需进行两套或三套的重复开发。更重要的是，物化表的引擎能够支持从秒级到天级的不同时效性计算，并根据用户的需求自动选择最优的执行计划。这意味着，系统会内置这些复杂的优化逻辑，用户无需手动干预，就能确保其业务高效运行。
其次，它对业务有显著支持作用。当前，许多业务对时效性和复杂度提出了更高要求，但受限于技术，无法把全量计算高效地切换成增量或实时计算。结果要么需求直接落空，要么实现代价过高，方案难以落地推广。而物化表提供了一个让更多业务可以低成本运行实时和准实时计算的方案，助力其实现从“降本”到“增效”的正向促进，从而加速创新。
02我们认为应该更进一步
思否：Flink 社区在支持生态发展方面，涌现了哪些重要的创新项目？它们各自主要解决什么问题，扮演着怎样的角色？
王峰：Flink 生态的发展是一个从点到面的过程。回顾早期从流计算起步，Flink 一直致力于构建一个能够实现秒级乃至毫秒级响应、高吞吐量、低延迟的分布式流计算框架。凭借出色的技术性能，Flink 逐渐成为业界广泛认可的流计算标准。随着自身技术的不断发展与成熟，Flink 开始向周边领域拓展，衍生出更多相关的项目，形成了一个更为丰富的生态系统。
比如，最早我们推出的 Flink CDC。我们知道，在整个大数据生态中，数据流动至关重要，因为数据不动就无法发挥价值。所以我们基于 Flink 成熟的流式框架及强大的连接器能力，打造了 Flink CDC 这么一个实时数据同步项目，扩大了 Flink 的应用场景。
Apache Paimon 也是从 Flink 社区里孵化出来的，最早叫 Flink Table Store。其诞生源于我们在流式计算过程中发现的一个痛点：当时市面上缺乏一种能够支持流式更新和流式订阅的数据湖格式，像 Iceberg 是面向批处理场景设计的，无法满足流式计算中对高时效性、高频读写的需求，无法与 Flink 形成良好的配合。鉴于市场存在空白，我们决定自己孵化一个实时数据湖格式，随着其应用场景的不断扩大，Paimon 最终独立成为一个 Apache 顶级项目。可以看到，Paimon 的诞生也是因为发现 Flink 缺少这样一个配套设施，而我们希望借此在实时数据处理场景下提供端到端的解决方案。
最新一个是 Apache Fluss (incubating)。虽然 Fluss 不是从 Flink 社区里衍生出来的项目，但其场景与 Flink 密切相关。过去，基于 Flink 与 Kafka 构建的流式数据平台是业界的主流选择。然而，我们认为这并非是最优解。Kafka 虽然是成熟的消息中间件，但它并非专为大数据分析场景设计，缺乏 Schema 管理且不支持更新操作，仅支持追加写入 Append-Only。这使得它在流式分析场景中存在局限性。因此，我们孵化了 Fluss 项目，旨在为流式分析场景提供更优的流存储解决方案。
你会看到，这些项目都是围绕 Flink 这个核心展开的。我们发现周边数据基础设施不完善，我们就一个个去填补空白，最终构建了一个完整的流式数据处理生态，涵盖了核心数据处理、数据同步、数据分析，包括面向流式分析的结构化流存储，以及面向流式更新和实时更新的 Lakehouse 数据湖格式。通过这些基于 Apache 开源协议的项目，所有开发者都能很方便地搭建出完整的实时数据平台，或者基于流式处理的实时数据平台和流式分析解决方案。这就是我们从 Flink 开始，由点到面发展出整个生态的逻辑。
思否：Flink 2.0 强化了与 Paimon 的深度集成，共同构建了流式湖仓架构。请您详细阐述，对于构建实时数据应用，这种流式湖仓架构的价值在哪里？
王峰：我认为可以从两个方向来看。我们看到现在市场上存在两种主流架构：一种是 Flink + Kafka 的架构，可以实现纯实时的数据处理。另一种是像 Spark + Iceberg/ Hudi 的架构，这是离线的湖仓架构。这两个场景其实是两个极端。前者优势在于能够实现最高时效性，即极低延迟的实时计算，但它的问题是成本高且架构割裂，数据需要重复导入。后者数据统一，以全量计算或者小时级增量计算为主，无法支持高时效性实时应用，所以时效性是它的弱点，但胜在成本低、架构简单，数据无需反复导入。
针对这两个架构的优缺点，Flink + Paimon 的集成就是一个折中的方案。它吸收了 Flink + Kafka 的时效性优势，虽然达不到秒级，但可以达到分钟级的时效性。同时，它也吸收了传统 Lakehouse 的优点，即数据统一在一个湖里，无需来回导入，并且支持全量计算。
在实际应用中，业务需求是分等级的。其中，统计类的或者机器学习场景，它们并不需要秒级的时效性。比如生成报表，人不可能每秒都刷新去看，只需要每 3 到 5 分钟更新一次。机器学习也是，用户行为特征的更新，3 到 5 分钟的延迟在很多场景下完全可以接受，因为模型不会每秒都变。所以对于大部分应用来说，Flink + Paimon 这种能提供分钟级时效性的组合就足够了，如果低成本且大规模地应用，那就是一个价值巨大的应用场景。
思否：Flink + Paimon 在分钟级时效性上已能满足大部分应用需求。但随着非结构化数据的增多，实时处理和高效查询的需求也越来越高。那么，Paimon 与 Lance 的集成是如何突破传统数据湖的瓶颈，实现多模态数据存储的呢？
王峰：我们在做 Data + AI 的场景下，看到了非常多对 Lance 的需求，本质上都是对其能够存储和查询非结构化数据能力的需求。传统的大数据场景中，包括我们主推的 Paimon，还是一个纯结构化数据，适用于大规模、关系代数分析。但 Lance 的理念就是能够把图片、语音等非结构化数据能够高效存储、随机查询，包括在训练的时候能够随机采样。这些能力与结构化数据融合，能够产生更大的价值。
Paimon 社区也在积极探索。比如将 Lance File Format 的能力集成到 Paimon 的 Table Format 中。因为 Lance File Format 具备高效存储非结构化数据的能力，这使得 Paimon 原本面向结构化数据的 Table Format 也能支持非结构化数据。
同时，我们也可以将这种基于 Lance File Format 的多模态存储能力集成到湖表中，实现在一张表同时包含结构化数据和非结构化数据。这种能力对于满足用户在 AI 场景下进行多模态数据分析的需求至关重要。因为 AI 场景虽然通常涉及到大模型，但大模型技术本身是非常独立的。在训练大模型之前，需要先收集和清洗数据，包括结构化和非结构化数据，如语音、图片等。这些数据需要被预处理并存储起来，以支持包括多模态训练在内的各种训练需求。那怎么高效存储和访问这些数据这对于加速训练过程就变得非常关键。所以我认为结构化存储和非结构化存储的融合会是未来的一个方向。这其中会有巨大的想象空间和非常高的未来潜力，业务需求也极其旺盛。
不过，目前这在业界仍处于一个尚未标准化的阶段，大家都在积极探索如何融合处理结构化和非结构化数据，比如我们也看到像 Iceberg 和 Lance 社区之间的一些互动，大家都希望能够看到这些未来能实现更好的融合。
思否：在构建实时数仓和支持 AI 工作负载的背景下，Fluss 与 Paimon 是如何互补或区分的？开发者在什么时候会选择 Fluss，什么时候反之？
王峰：Paimon 和 Fluss 在定位上有所不同，但互为补充。Paimon 定位为流式湖仓的存储，秉承了 Lakehouse 的开放性和全面性，可覆盖分钟、小时、天级的业务场景。相比之下，Fluss 是一个纯流式存储，时效性可达毫秒级，更像一个高速缓存服务，专为毫秒级、秒级等高时效性的流式分析场景设计。最简单的区分是，对业务时效性要求为毫秒级、秒级的高时效性且要求非常稳定的低延迟的场景，Fluss 是更好的流式分析选择；而针对分钟级或小时、天级延迟可接受的场景，则推荐使用 Paimon 。
同时，两者还可以像“乐高”一样协同工作，提供更加完整的解决方案，特别是对湖流一体特性的支持。它允许 Fluss 在流表中实现毫秒级流式更新，而这些更新后的数据可以异步、自动地以分钟级时效性同步到 Paimon 中的湖表。这意味着，在 Fluss 和 Paimon 中存在两张相互 Mapping 的 Table，但在 Fluss 中的更新是即时生效的，其更新时效性达到毫秒级，而向 Paimon 中的更新可能是 5 - 10 分钟延迟。
所以，如果业务需要实时分析，就订阅 Fluss，写入数据下一秒就能够做分析，但成本会很高。如果业务对时效性的要求不是极端严格，比如需要每 5-10 分钟做一次增量，每天进行一次全量分析，那么使用 Paimon 就可以满足，成本更低。Fluss 更像 Lakehouse 架构上的一个高速缓存层，而 Paimon 则是一个相对高速、持久化的 Lakehouse 存储底座，它会保存所有的数据。当这两层系统打通并一体化运作时，它们就为用户提供了一个完整、开放的湖流一体存储方案。
思否：您提到了一个比较新的概念——湖流一体，能否请您进一步阐述这一模式在实际应用中如何为用户带来更全面的价值？同时，社区是否计划建立“流式湖存储”统一 API 标准，以进一步推动这类架构的普及？
王峰：湖流一体就是把湖和流打通了，这个打通过程是自然的，无需用户自己操作，可以将其看作一个完整的湖流一体化存储。这是我们今年新提出的一个概念。
我们观察到，许多项目通过构建一个中间数据同步层，将 Kafka 中的流式数据导入到 Iceberg，我们称之为“流式入湖”。然而，我们认为应该更进一步，将这一过程融合为一个更加完整的系统。
所以我们未来可能也会在社区中做一些尝试。比如在 Fluss 里，我们计划开放 REST API Server，这是一个与语言无关的 API 能力。用户可以通过 REST API，随时将数据推送到流式缓存中。即使是单条数据，用户也可以随时通过这个 API 发送，这些数据随后会异步地流到数据湖中。
这意味着，入湖会变得非常简单。因为入湖本身其实是一个相对繁琐的过程，自己写一个 Iceberg 文件，或者写一个 Paimon 的文件都属于重度开发。如果未来能开放这个 REST API 的标准，开发者就可以基于 Fluss 的流式管道能力，随时随地用 HTTP 协议推各种各样的数据入湖。
那么，第一个明显的价值就体现在读写方式上。首先用户可以通过多种方法写入数据，既可以一条一条实时推送消息，也可以通过 SDK 流式分钟级写入 Paimon 文件。读取数据时同样可以选择流式订阅或者批量处理，比如生产环境下微批增量处理的时间间隔可以在 5 分钟左右。
第二个价值会直观体现在 ROI 上。你如果有足够的预算，面向高优业务，可以实现秒级延迟处理。如果你预算有限，但仍想在 10 分钟内完成数据更新，那可以选择分钟级增量计算，依然能得到一个准实时的效果，但成本可以大幅降低 5-10 倍。总体来讲，通过湖流一体方案，用户在可以业务时效性和成本之间进行平衡和选择。
至于社区是否有计划建立“流式湖存储”统一 API 标准，这当然是我们希望的。标准化的价值也很明显，就是大家可以形成一个统一的规范，从而降低计算和对接成本。
思否：Paimon 和 Fluss 都获得了显著的社区贡献和采用。您认为推动这种势头的关键因素是什么？Apache 软件基金会的管理，尤其是对捐赠到基金会不久的 Fluss 而言，如何支持项目的发展？
王峰：目前情况是这样，这两个项目都已捐赠给 Apache 基金会并被接纳，Paimon 已经毕业成为顶级项目，而 Fluss 今年刚刚进入孵化器，可能明年才能毕业。
然后我想从两个角度来回答这个问题。一方面是因为市场有需求，业界需要这样的项目。就像我之前提到的，Flink 能够从核心引擎扩展到整个生态，带动这些项目的出现，就是因为市场有明确的需求。我们是因为在实际生产场景和客户需求中发现了市场空白，洞察到了真正的诉求，并且我们相信这些项目能够实实在在地解决业务问题。这是我们孵化并贡献这些项目的关键因素之一。我们认为有意义的项目应该满足大家共同的需求，然后才考虑开源。因为开源的目的是希望更多人使用和贡献项目。
另一方面，你可以看到，无论是 Paimon 还是 Fluss，至少在中国，越来越多的公司都参与到共建中，而不仅仅是阿里的员工。同时项目贡献者的多样性也持续增强，包括国内的许多大型企业，都开始贡献并将其应用到自己的生产场景中，或者在云上使用我们的商业化产品降低他们维护成本。我认为这是我们贡献这些项目的核心原因之一，即它们能够普惠广大开发者。
另外，Apache 软件基金会作为一个中立组织，为项目提供了一个建立信任的平台和机制，确保开源精神和项目不受限于单一公司在流程上的控制。这使得更多的企业和开发者愿意参与到项目中来。
同时，Apache 软件基金会的权威性为项目带来了认可，成熟的全球化推广机制也有助于项目走向国际，而不仅仅是在中国发展。我们的中长期规划是希望项目能在国内外获得广泛认可和发展，因此加入 Apache 基金会是必要的。虽然在公司平台也可以开源项目，但我个人认为直接贡献给 Apache 基金会可以得到业界更多的认可和信任。通过 Apache 基金会，项目能获得并吸引更多全球企业和开发者的使用和贡献，在我看来这是目前 Apache 软件基金会对我们开源项目最大的支持和价值。
03事件驱动的 Agents 代表了智能化数据处理的未来发展方向
思否：我们刚才聊了很多 Flink 生态面向 AI 场景的技术演进，那么面向 AI 时代，Flink 社区的长期策略是什么？
王峰：随着 AI 技术的发展，我们确实看到了更多机会和切入点。我们的核心目标，是希望 AI 技术能够真正应用到实际中，尤其是在大模型落地方面发挥作用。因此，目前我们的主要策略并非直接优化模型本身，而是希望通过将大数据与大模型技术相结合，打造智能化的数据处理系统和决策系统，从而解决实际生产中的问题。
对此，我们主要有两个思路。一是为大模型训练前提供高质量的数据，这包括对大规模数据进行处理和清洗，提升数据质量。二是能够在实时数据处理链路中集成大模型推理服务，打造基于 AI 加持的实时数据智能分析服务。在这个过程中，大数据实时计算能够与大模型实时推理进行协同，提供更加智能化的实时数据处理能力。
思否：针对支持训练和提供推理这两个机会点，Flink 生态目前的布局重点在哪里？
王峰：从 Flink 的角度来看，我们认为它与 AI 结合得最紧密、也最适合的切入点是与大模型推理阶段的集成。在线推理本质上是利用新一代大模型的能力，进行智能化的分析和决策。在这个过程中，我们可以看到，所有实时数据处理的核心和诉求，都是基于数据进行智能决策，从而产生商业价值。只不过之前这种决策更多是基于统计学或规则引擎等手段进行触发。
现在，通过将大模型能力嵌入实时处理链路，我们可以超越经典的关系代数统计模型分析，而进行更智能的数据分析和决策。我们甚至可以将非结构化数据，交给 AI 大模型进行更复杂的判断和处理，比如让模型给出风险分析、提供基于语义的总结和洞察等。
我们已经在 Flink SQL 中集成了这一功能，支持以 OpenAI 协议为标准的大模型推理服务。这使得在实时数据分析过程中，我们可以将文本、语音、图片等结构化和非结构化数据直接传递给大模型，获取分析结果，并与传统的大数据分析相结合，实现更强大的数据分析能力。可以这样理解：我们现在不仅拥有 BI 算子，还引入了 AI 算子，用户可以在流式计算过程中灵活调用。AI 算子能力的引入显著增强了 Flink 的能力，这是我们与 AI 结合的第一点。
第二点是关于 AI Agent 的应用。AI Agent 包含多种形式，不仅限于对话式交互，如 AI coding、Chatbot 和 Deep Research 等。除了这些需要人机对话的 Agent，还有一类 Agent 专注于持续监控和观测现实世界中发生的信息，并据此做出判断。
典型的例子就是 AI Ops。AI Ops 通过实时监控数据中心和 IT 系统的日志与指标，自动做出决策，例如在流量高峰时建议扩容，或在检测到不平衡时进行再均衡。它们还能分析日志，预测并报警潜在的故障和风险，甚至自动执行预设动作。
这些基于实时事件的 Agents 能够识别出各种不同类型的风险，并及时采取行动。例如，在舆情检测与分析中，Agent 可以通过监控来自论坛、客服电话等多渠道的数据，判断舆情变化，进行态势感知。在新能源车设备监控场景，当各种信息类事件涌入时，Agent 能预测出设备质量风险并发出预警和建议。这些事件驱动的 Agents 由系统而非人类触发，所要处理的数据规模更加庞大，也代表了智能化数据处理的未来发展方向。
因此，我们认为 Flink 作为一种流式、事件驱动的数据处理系统，未来有望与大模型结合，更好的支持“事件驱动型的AI Agent”发展。 这种 Agent 将具备更强大的能力，能够处理由机器或系统产生的大量事件，而不仅仅是响应用户的提问。正因如此，面对庞大的事件数量，Flink与AI 联合提供智能化的处理和分析能力也变得尤为重要。这是 Flink 和数据处理系统未来一个非常好的应用场景，也是我们发展 Flink Agents 的动力所在。
在这样的愿景下，我们希望基于 Flink 提供一个事件数据驱动的 Agent 框架，支持开发者更轻松地构建事件驱动的 Agent 应用，推动数据处理向更智能化的方向发展。
04结语
十年磨一剑。Flink 2.0 作为其加入 Apache 软件基金会后长期探索的集大成之作，其以“存算分离”为核心的架构革新，不仅解决了历史架构的桎梏，更开启了面向云原生时代的流式计算新范式。同时，以 Paimon、Fluss 等为代表的 Flink 生态组件，也正通过“湖流一体”的创新模式，推动 Flink 从单一引擎向全链路实时数据平台演进。此外， Flink 正深化面向 AI 场景的探索，持续增强智能流处理能力，并通过 AI Agents 框架引领下一代实时计算的发展方向。
显然，Flink 的“剑锋”所指，既是技术架构的云原生蜕变，更是智能化实时计算的未来。
