摘要：本文整理自阿里云高级产品专家黄鹏程和阿里云技术专家陈婧敏在 FFA 2023 平台建设专场中的分享。内容主要为以下五部分：
- 阿里云实时计算 Flink 简介
- 产品化思考
- 产品化实践
- SQL 产品化思考及实践
- 展望
该主题由黄鹏程和陈婧敏共同完成，前半程由黄鹏程分享，主要分为四个部分：第一部分，阿里云实时计算 Flink 简介；第二部分，结合自身产品化的经验谈产品化的思考；第三部分，分享产品化的实践，即阿里云在产品化思考的基础上进行的实践；第四部分，对 Flink 未来进行展望。
中间由陈婧敏老师分享阿里云 Flink 在 SQL 层面做的深入优化和产品化相关的功能。
一、阿里云实时计算 Flink 简介
1、阿里云推动 Flink 技术进步和繁荣的过程
2016 年起，阿里巴巴集团便在流计算领域（非 Flink 技术）开始了相关的研发工作。随后的 2017 年和 2018 年，市场上出现了广为人知的 Flink 产品/技术，该技术是在阿里巴巴集团通过收购 Flink 创始公司 Ververica 之前，阿里云团队内部开发的版本。到了 2019 年左右，阿里云团队正式完成对 Flink 的创始公司 Ververica 的收购，此次合作由中德双方的团队共同推进，旨在推动 Flink 技术在云计算平台上的商业化项目。从 2020 年起至今，约三年的时间里，Flink 技术的社区活跃度显著提升。无论是在中国大陆地区还是之前在西雅图举办的全球会议上，都可以观察到越来越多的用户开始采用 Flink 技术，逐步取代了storm、jstorm、spark streaming 等过去的流计算框架。
2、阿里云推动 Flink 在阿里集团大规模使用
阿里云不仅致力于相关技术的发展，同时也为阿里巴巴集团提供服务，支撑了集团众多业态的运营。在诸多计算规模和服务场景中，可以观察到集团各业态对 Flink 实时计算任务的依赖。
3、阿里云 Flink 对外提供云服务
这部分分为两大部分：首先是平台层面，阿里云的 Flink 服务在其控制台具备多项功能，旨在简化客户的开发和运维过程；其次是企业级 Flink 引擎，该引擎以 Apache Flink 的开源核心为基础，保证与开源版本的完全兼容，并在此基础上新增更多特色功能。接下来的分享将深入介绍阿里云团队所开发的功能、我们的产品落地考量以及整个行业现状的思考。
二、产品化思考
1、实时数据处理的应用场景
尽管各个公司的具体业务形态和所在行业存在明显差异，但它们总体上可归纳至以下几个主要范畴中：
2、实时数据处理的技术场景
上图中抽取了一部分概念或技术性的场景，这涉及到以下几个问题：首先是数据的基本流式处理 ETL/ELT，包括更细分的 CDC（变更数据捕获）、实时元数据的管理、实时数据分析、实时数据的存储和查询（对实时数据的存储，以及进一步供给 Online Service 查询）、实时数据的可视化。
3、现代实时数据流的必备要素
阿里云作为一家对外提供云服务的厂商，面对众多的应用场景、技术场景以及各种不同的技术方向，我们应该如何应对呢？以下，我将概述六个核心要素，这些是构建现代实时数据流系统所必需的：
3.1 大规模数据处理能力
这构成了将传统离线业务转变为实时操作的基础。
3.2 数据无障碍流动
为了实现业务的实时化处理，必须确保数据能够从 A 点顺利迁移到 B 点。这包括处理异构数据和跨地域数据的迁移。为了达到这一目的，我们需要有效地整合这些数据流。Apache Flink，作为一个生态丰富的开源项目，为我们在多个方面的开发与优化提供了坚实的基础。
3.3 数据处理连续性
在个人看来，Flink 主要覆盖两大领域。首先是数据领域，涉及到实时数据的处理与分析；其次是应用领域，主要关注于实时数据业务的处理。这里提到的“连续性” 更多地指向应用领域，寓意其功能相似于数据库，能够实现在线、始终在线的操作能力。这也是 Serverless 的根本产品形态要求和用户侧的最终诉求。
3.4 技术民主化
主要关注的是大众通常提到的应用性或门槛问题。由于在不同场景中，并不是每家公司的每个成员都能在特定技术领域有深入的了解和掌握，因此，该领域的用户对此有着强烈的需求。
3.5 实时数据可观测性
这里面的可观测性，除了基本的监控告警，还包含如何帮助用户深入理解数据及作业间的相互关系。
3.6 实时离线一体化
我们期望将实时与离线一体化的开发推广为一种标准范式，以便用户能够直接采用。在早期发展中， Flink 的崛起与流批一体理念是紧密相关联，我们希望在这个理念的引领下做出用户可快速上手的产品能力。
三、产品化实践
该部分围绕前面提到的六个必备要素展开，包括在某一部分具有怎样的能力，以及为什么要这样做。
1、大规模数据处理能力
这一部分主要讨论性能问题，因为性能直接关联到成本。阿里云 Flink 的性能优势主要源自两个方面的实践：
1.1 强劲的性能——SQL
相关内容将在后续分享中由陈婧敏老师详细介绍，敬请关注。
1.2 强劲的性能——Gemini
除了在 SQL 领域的应用外，我们亦在自研状态存储方面投入了大量精力。Gemini 是我们近期开发的状态后端系统，它受到了广泛关注（注：这个与 Google 最新发布的大模型无关，仅仅是名称相同）。作为我们自主研发的成果，其工作的位置相当于 Apache Flink 主要采用的 RocksDB。我们的云服务客户群体包括阿里巴巴集团内部，在使用 Gemini 时体现出了其强大的功能性，特别适合云计算环境。无论是在存储计算分离还是在多流场景下，Gemini 均能够提供性能优化。此外，其分层存储（tiered storage）功能也优化了状态管理。Gemini 还具备多种自适应参数设置，可以根据实际流量自动进行调整，从而免去了手动调节的需要。
上述两项关键实践的基础上，云上 Flink 的内核性能得到了显著提升。下图展示了 Flink 1.15 版本与云上对应版本在 Nexmark 测试下的性能比较。另外，相较之下，1.17 版本在此测试框架下的平均性能比开源 Flink 版本快约两倍。
2、数据无障碍流动
2.1 丰富的上下游数据连接器
连接器可分为四个主要类别：消息中间件、数据库、数据仓库以及数据湖。在我们的云产品中可以构建超过 30 种不同的上游及下游存储连接器。此外，平台还支持用户根据自身需求自定义连接器。生态的建设尤其关键，因为在构建这些连接器时，不仅需要深入理解上下游的事件，还需投入大量的人力和物力资源来进行优化和功能提升，通过我们的投入帮助用户省时省力的直接用起来。
2.2 Flink CDC 数据实时入湖入仓
这部分为我特别要强调的重点内容。这个项目作为阿里云 Flink 团队发起并主导的开源项目，通过单一的 SQL 实现在 Flink 作业中对变化数据进行分布式实时捕获，以便进一步在下游进行数据传输和计算处理。
Flink CDC 相较于其他的 CDC 框架以及过去的工具，有如下特点：
- Flink CDC 能力更强大
从 CDC 的机制上来讲，它分为日志和查询两种。在最左侧的列中列举出了其相关的能力：
可以看到 Flink CDC 在各方面都能够较好地应对这些场景。另外，在分布式上，Flink CDC 嫁接在整个 Flink 的架构之上，因此，其分布式能力非常强。
- Flink CDC 架构更加优雅
之前，当 CDC 过程完成后，如有计算需求，首先需要访问 Kafka，紧接着才是 Flink或其他相关操作。如今，我们可以直接读取数据进行 Flink 处理。在数据复用需求不高，但追求更优雅架构的场景下，这种方法提供了更简洁的流程和更少的组件。
- Flink CDC 表结构变更迁移
除了基础的 Flink CDC 功能之外，我们还可以利用 Catalog 来实现元数据的自动发现与管理。在进行分库分表或整体库同步的数据同步过程中，能够自动识别并捕获到表结构的变动。如上图所示的案例，左侧展示的是使用 MySQL 的业务场景，中间通过一个Flink CDC 任务将数据同步至 Hologres（阿里云提供的一个数据仓库产品），这一过程实质上是从业务领域到数据领域的数据同步过程。在这个过程中，如果在 MySQL 中增加了一个列，该列也会自动地添加到 Hologres，并将相关数据同步过去。
- Flink CDC 分库分表同步与整库同步
面对基于分布式数据库架构设计的大规模在线库表时，我们提供了两种功能：分库分表同步和整库同步
首先，我们介绍 CTAS 功能，其核心作用是实现分库分表的合并。这一功能特别适用于那些业务数据被分散储存在不同分片的数据库架构设计，现在我们需要将这些分散的数据合并到一张表中，以便进行统一的数据汇总、计算和深入分析的场景。CTAS 不仅能够轻松地将数据合并至阿里云的数据仓库中，还支持数据迁移至采用 Apache Paimon 湖格式的湖仓中。
接下来是 CDAS 功能，它的主要目标是实现整库同步。当有需求要将所有表的数据统一放入一个业务库中进行数据分析时，CDAS 提供了一个高效的解决方案。用户可以通过编写一个 SQL 语句，这个 SQL 不仅可以同步数据，还可以处理加表、schema 变更等操作，确保数据的全面同步。
3、数据处理连续性
鉴于 Flink 作业具备实时处理的能力，我们期望它能够持续稳定运行较长时间，以便能够支撑更多的业务流程运作在该框架上。
3.1 Flink CDC 全增量一体化+并发读取
Flink CDC，作为一种增量一体化框架，针对数据同步进行了巧妙设计。在全量数据同步阶段，它通过分块（chunk）的方法实现了数据的并行读取，从而加速了数据同步的基础阶段。这是因为同步一个数据库表需要先有历史数据的备份，而 Flink CDC 能够并行处理数据提取，显著提高了效率。进入增量同步阶段时，Flink CDC 能实现无锁一致性的平滑转换，而且这个切换过程无需停止当前作业，也不需要大量的 Binlog offset 进行操作，实现了一次性、无缝的切换。在处理增量数据时，由于它是基于单一序列（single series）读取 Binlog，这个机制保证了处理的连续性和高效性。目前，我们正研发一个实验性功能，虽然还未在云服务上推出，但该功能将使得 Slot 在不再需要时能够自动释放资源，从而在数据同步或集成的场景下显著提高资源利用效率，确保过程中无断点。
3.2 实时计算 Flink 版：同步作业动态加表
上述内容介绍了我们在云上实现方式。实际上，在进行整库同步的过程中，业务数据库会持续发展，不断创建新的表。尽管如此，我们仍然期望同步任务能够适应这种变化，动态地添加新表以实现整库的同步。
这一流程中，当前新表的添加需要通过创建检查点并重启作业来实现加载全部的新表数据，而旧数据则会继续从上次的同步点开始同步。未来，我们将允许作业在不重启的情况下运行，并且当业务数据库中产生新表时，能够确保数据的连续同步。
3.3 参数动态更新
要确保数据被连续处理，很多人会考虑调整参数，特别是在涉及性能、问题诊断及资源相关参数的修改时，他们关注的是如何迅速使这些调整生效，这也是 Serverless 的一个基础就是作业级别的动态调整能力。
在图中最左侧是重启作业更新，使用开源 Flink 的时候需要完全暂停重启作业。如果没有新的检查点，则还需要手动打作业快照。重启又涉及加载 Checkpoint 或者 Savepoint 的过程。而在右侧的阿里云 Flink 中，我们可以调整并发度和 Checkpoint 参数（间隔、超时时间等），通过点击“动态应用”按钮快速重启，实现参数的动态更新和资源的横向扩缩容。请参考下图以了解详细过程和结果。
左侧的红色区域展示了开源 Flink 参数调整的全过程，它涵盖了完整的重启流程。在阿里云 Flink 的应用场景中，在作业初始化阶段，即工作节点开始启动时，我们可以优先进行参数调整。而在蓝色区域中，我们致力于减少开销，并实现新旧作业的平滑切换，有效缩短整体的服务中断时间，并降低中断带来的成本。
对 100 个并发作业进行扩缩容操作的断流时间进行比较时，发现当扩容至 150 倍并发度时，若采用参数的动态更新，其耗时与原先相比将会有显著差异。我们后续计划推出对 SQL 进行动态更新的功能，这意味着，如果用户需要修改其 SQL 语句，而且这些修改与现有状态兼容，我们能够助力用户实现 SQL 逻辑的动态更新，这意味着阿里云 Flink 迈向更加贴合用户使用场景的 Serverless 能力。
3.4 失败快速恢复
前文提及的内容属于计划范畴内。至于计划之外的部分，也就是 Task 失败的切换场景，我们可以以更细致、更迅速的方式进行响应和恢复。
此过程受到语义限制，我们必须在至少一次 (At-least-once) 语义的条件下实施，采取快速失败恢复机制，从而缩短恢复时间。
3.5 动态规则的复杂事件处理 (CEP）
这项功能在社区中早已出现，被称为复杂事件处理（Complex Event Processing, CEP）。设想一下，如果我们拥有一串流数据，并希望依据特定模式进行匹配：比如，首先发生 A 事件，在接下来的 10 秒内又发生 B 事件，那么一旦在数据流中识别出这一模式，就可以将其视为一个警报或事件。在开源实现中，CEP 基本上是静态的，即其匹配的模式是固定的，并编码于程序之中。然而，在实际业务流程中，运营或策略人员可能会调整规则，每次更改模式时，都需数据人员进行代码修改、上线申请等繁复过程。如果能将这些规则外置到如 MySQL 这样的存储系统中，并能够动态地应用这些规则变化在线上系统中，只要系统资源充足，在不太复杂的情况下，这种调整便可以实时生效。这不仅可以解放数据平台人员，让他们专注于业务需求，还可以仅通过监测资源使用情况来实现。当然，在面对特别复杂的情况时，仍然可以通过调整资源，例如改变并发度，来进行处理。总之，在资源充足的条件下，CEP 的动态调整是可行的，而阿里云 Flink 就针对这个场景推出了动态 CEP 的能力。
以某电梯制造商的案例为例，该公司利用了一系列实时规则，为其物联网传感器数据配备了 CEP 规则，以匹配电梯是否存在故障的场景。在这一实施方案中，大量规则被存放在 RDS 数据库中，并通过一个后台应用进行规则的增删改查，进而通过一个前端界面供策略人员使用。所有规则的增加、删除、修改和查询皆可在实时的 Flink CEP 作业中得到动态实施。所有的传感器数据通过 Kafka 流式处理加以同步。Flink CEP 的作业会持续与 Kafka 的数据流摄取，一旦检测到新的规则，就会采用新规则进行匹配。匹配成功的结果会被记录在结果库中。整个过程能够最大限度的使作业保持持续运行。
后续内容请关注Flink的产品化思考与实践【下篇】
