Flink 十周年专访莫问：存算分离 2.0 架构的探索与展望

采访嘉宾 ｜ 王峰（莫问）

编辑 ｜ Tina

Flink 从 2014 年诞生之后，已经发展了将近 10 年，尤其是最近这些年得到了飞速发展。在全球范围内，Flink 已经成为了实时流计算的事实标准，成为大数据技术栈中不可或缺的一部分。在 2023 年终盘点之际，InfoQ 有幸采访了 Apache Flink 中文社区发起人、阿里云开源大数据平台负责人王峰（莫问），了解他对大数据技术栈的看法，以及 Flink 的进展和未来规划。

完整年终盘点文章：挑战 Spark 和 Flink？大数据技术栈的突围和战争｜年度技术盘点与展望

InfoQ：如果以“数据流”的逻辑来看大数据基础设施的演进，比如：从存储和处理到分析，再到提供 ML/AI 模型并构建面向用户的、人工智能驱动或数据驱动的应用程序，那么在这些环节中，您观察到有哪些重要更新或变化？

王峰（莫问）：在最近几年的数据技术趋势演进的路线中，我们可以清晰的看到两个趋势变化，一是数据分析的实时化，二是数据架构的云原生化。

1. 数据分析实时化本质是业务发展驱动的。在 BI 场景，各行业的业务运营人员和决策者都希望能到实时的数据分析报表来及时进行业务决策，从而提升公司运营效率；在 AI 场景，各种推荐广告等场景都希望能够及时将用户行为反馈信息合并到 AI 模型中，从而进行更加个性化精准的推送，提升业务转化率。在技术上，数据的“实时化”包括了两个因素：一是数据的新鲜度，二是数据的查询速度。为了解决这 2 个问题，我们可以看到最近几年 Streaming 和 OLAP 两种引擎成为了大数据技术领域的热点，SIGMOD 把今年的 Systems Award 搬给了 Flink，Clickhouse 、Doris 和 StarRocks 几款 OLAP 引擎也不断争夺市场的焦点。
2. 在云端构建数据基础设施日益成为主流，云的弹性能力让存算分离架构可以发挥出极致的效果，在云端基于数据湖构建开放的数据中心，不同类型的计算引擎可以围绕统一数据存储构建繁荣的融合计算生态。以 Snowflake 和 Dataricks 为代表，几乎所有的大数据公司都选择了拥抱云原生，推出了基于多云的 PaaS/SaaS 计算服务，从 Serverless 到 BYOC，为用户提供了在云上不同类型的托管服务，随着云计算规模效应的提升，未来一定会有更多的数据计算迁移到云上运行。

InfoQ：今年我们看到不止一家企业声称实现了比 Flink 有 10-1000 倍的效率提升，那么在 Flink 的资源效率方面有什么进展？增量引擎 +Apache Paimon 方案是否是一方面？

王峰（莫问）：

1. 我也非常期待能看到真正能够有 “比 Flink 快 100-1000 倍”的新技术出现，这样类似阿里、腾讯、抖音这些公司大概每年可以节省数十亿的机器成本了，不过目前好像没有看到那家公司真的在生产环境做到了个效果。几个月前，大家通过开放的方式进行过一些相关讨论，Flink 社区的几位核心成员也通过基准测试成绩以及技术分析进行了回复，有兴趣的同学可以去网上搜索下相关文章。
2. 良性的技术竞争是有利于开源生态的发展和演进，目前 Flink 也在不断学习和自我革新，明年 2024 年将是 Flink 项目的第一个十周年，Flink 社区也会发布 Flink-2.0 新的里程碑，彻底的云原生存算分离架构，业界一流的批处理能力，完整的流批融合能力都会是全新的亮点。此外，阿里云之前独立开源的 Flink CDC 实时数据集成项目也已经正式开启捐献工作，明年 Flink CDC 将正式成为 Apache Flink 官方子项目。
3. Apache Paimon 是从 Flink 社区中孵化出来的新项目，定位就是流批一体实时数据湖格式，解决 Lakehouse 数据实时化的问题。基于 Flink + Paimon 可以构建出新一代的 Streaming Lakehouse 架构，让 Lakehouse 上的数据可以全链路实时流动起来。此外，基于计算和存储端到端流批一体的特性，也更加方便用户在 Lakehouse 架构上实现实时离线一体化的数据分析体验。

InfoQ：您认为流处理引擎未来进化方向是什么？***

王峰（莫问）：

方向 1：全面 SQL 化，提升体验，降低门槛。 大数据处理从离线向实时升级的趋势已经确立，大量行业已经开始实时化升级，并取得非常好的业务收益。为了让更多用户能够享受到实时流计算带来的价值，流处理引擎需要进一步提升端到端的易用性，全面 SQL 化 ，提升用户体验，降低使用门槛，让流计算能够在更多场景和行业中被生产使用起来。

方向 2：流批一体，流批融合。 流、批数据处理的边界正在逐步模糊，越来越多用户希望一套 API 来统一开发业务逻辑，但可以基于不同的频率来运行，例如可以让其每天 / 小时 / 5 分钟运行一次，或者持续不停在运行，并得到一致性的业务结果。因此流批一体，流批融合计算能力会是下一步的演进方向。

方向 3：存算分离，云原生架构。Cloud 正在成为大数据和 AI 计算新的运行底座，因此流计算引擎需要在运行部署架构上完全融入云原生环境，彻底实现存算分离架构，基于云的优势提供秒级弹性扩缩容和系统容错恢复能力。

方向 4：流式湖仓新场景 。 目前大部分用户都是将流计算引擎和消息队列配套使用，构建流式处理链路。但这个并未真正解放流计算的潜力，随着开放的 Lakehouse 架构出现，越来越多数据会进入到数据湖中，流计算引擎和 Lakehouse 架构的结合将开启新的实时数据湖分析架构。目前流计算已经和主流湖存储技术完成对接，接下来流计算引擎将继续完善自身使其更好的和 Lakehouse 架构进行深度融合。

InfoQ：对当前大数据平台来说，生成式 AI 将对数据和分析产生什么影响？

王峰（莫问）： 大数据和 AI 一体化是一个谈论了很久的话题，在 AIGC 出现之前，大数据和 AI 最经典的结合场景是搜、推、广，用户个性化模型的生成和更新离不开海量用户行为数据的预处理，包括特征工程和样本拼接等经典流程。在很多大型互联网公司中，这部分 AI 数据预处理工作的计算量甚至已经超过了经典 BI 数据分析类应用。

在进入 AIGC 时代后，LLM 的训练依然需要前期的海量数据预处理，随着越来越多超级 AIGC APP 的出现，依然会产生大量的用户交互数据，为了更好的将这些数据效果反馈给 LLM，AI 场景依然会继续需要大数据计算技术来协助发展。

此外，随着行业大模型的逐步丰富，AI 技术红利也会助力大数据的发展，目前已经有不少公司开始推出利用 AI 大模型技术进行自动生成 SQL 的技术，这背后需要 AI 大模型能够更加深入的理解数仓体系，从而根据用户需求产生更加高效的 SQL。总而言之，未来大数据和 AI 技术的融合会更加深入，相互支持，相互促进。

InfoQ：在您看来，当今现代数据堆栈还有哪些局限性？

王峰（莫问）： 近些年各种不同的大数据基础设施雨后春笋般的涌出，一方面为用户提供了多样化的选择，但另一方面也为用户带来了幸福的烦恼。通常情况下，用户要搭建一套大数据业务系统，需要非常多的核心技术组件才能完成，少则三到五种，多则五到十种，这主要带来以下几方面的问题：

1. 技术组件繁多，必然提升系统架构的复杂度。通常来讲，系统稳定性风险和系统复杂度成正比，过于复杂的体系必然带来更大的稳定性隐患；
2. 每一项技术组件都需要有对应的专家来运维管理以及客户支持，对于中小企业来说，这必然带来高昂的人力资源成本；
3. 过多的同质化组件存在，也会为用户带来选择的困扰，并行保留多个同质化组件不仅给运维团队带来了额外的运维负担，也给开发者带来了额外的学习成本。

因此，未来数据技术的演进会逐渐出现一些整合的趋势，走向更加简洁的架构，核心目标不仅是让每个组件运行的更快，还需要考虑为用户提供更加简单、一致性的开发体验，以及全局最优的运维成本。

InfoQ：请展望未来的大数据架构是什么样子？

王峰（莫问）：

1. 目前业界主流的几款 Streaming，Batch 和 OLAP 引擎都开始相互渗透，例如：Flink 在发力流批一体、流批融合计算能力，Databricks 也基于 Spark 和 Delta 推动了 Delta Live Table 淡化流批的差异，StarRocks 在提供 OLAP 极致查询能力的同时，也开始通过物化视图形态提供对数据湖上数据的 ETL 处理能力。本质上各大主流计算引擎都在不断扩展自己的能力边界，淡化流、批、OLAP 边界，希望为用户提供全场景一致性的数据分析体验。我个人认为这也是技术发展的必然趋势，各家都会逐渐补齐短板，但也都有各自核心的优势。
2. 随着云原生概念的逐步普及，未来主流的计算负载一定是运行在 cloud 上，全球范围内都是这个趋势，因此大数据架构也需要更好的适配云底座，利用好云的弹性优势。存算分离将会是未来大数据架构的标配，不过存算分离在带来了诸多好处的同时也带来了额外的性能挑战，目前看在对 latency 敏感的场景下，多级缓存和冷热分层将是对存算分离架构的有益补充，2024 年将发布的 Flink-2.0 也会采用这套最新的架构。
3. 云原生架构的不断发展，也同步推动了数据湖存储方案的加速落地。数据湖具备的开放和成本优势，必然使得越来越多的数据流入湖中，从而成为天然的数据中心，湖上建仓的 lakehouse 架构正在成为主流，下一步客户一定是希望数据在 lakehouse 中能够更加实时的流动起来。
4. 在实时流处理这条链路上，我觉得也存在一些新的机会和变化。众所周知，Flink 和 Kafka 目前已经分别成为流计算和流存储的事实标准，但 Kafka 真的是最适合流分析的存储方案吗？Kafka 和很多消息队列类似，都是一种消息中间件，而非为大数据分析而生。例如：Kafka 并未对数据提供结构化的 Schema 描述，也无法提供完整的 Changelog 语义，且 Kafka 中的数据时无法进行实时更新和探查分析的。但以上这些缺陷，都是实时流分析需要的特性和能力，我们也正在思考这个问题，并探索新的解决方案，希望能够在明年发布一款更加适合流分析的流存储技术。