摘要：本文整理自阿里云高级产品解决方案架构师王启华（敖北）老师在 Flink Forward Asia 2023 中闭门会的分享。内容分为以下四个部分：

1. 业务需求变化推动架构演进
2. 实时计算对于企业生产的意义
3. 从技术架构和技术场景来看发展和迭代
4. 客户做技术架构的痛点、逻辑和收益。

一、实时计算在大数据计算发展中的趋势

阿里云计算平台事业部在过去十年中，通过与百余家企业合作，积累了丰富的大数据应用经验。这些企业在使用大数据产品、搭建平台以及更新产品架构的过程中，推动了我们对不同类型企业在数字化转型和数据架构升级方面的理解。然而，近两年来，一个非常明显的趋势是，企业对实时计算的需求量迅猛增长。下面，我将分享几点感受：

1. 大数据的普及与深度应用：大数据技术已经不再是新奇事物，而是深深融入企业的生产流程中。过去，大数据主要用于生成报表和展示数据，而现在，它已经逐步渗透到实时业务的主链路中，如物联网、风控、推荐系统和用户画像等领域。线上业务对大数据的时效性要求越来越高。
2. 硬件发展与产品升级：如今，产品硬件发展迅速，不论是从 CPU 还是内存的角度看，云上产品能力的更新换代让用户觉得，通过产品升级来节省计算时间是非常划算的选择。
3. 市场竞争与高时效性需求：市场竞争的激烈使得许多企业在进行实时决策时需要高时效性的数据。因此，许多客户的业务负责人不再单纯依赖历史数据进行分析和决策，而是需要及时获取实时数据并进行分析，以指导当前的运营活动。
4. AI分析的应用：通过利用历史数据和当前的数据进行AI分析，包括推理和预测等，企业能够更好地指导未来的决策和运营。

伴随着大数据技术的演进，从离线计算到准实时计算，再到实时计算和AI计算，整个技术体系的发展促进和推动这一趋势的演进。根据第三方机构的调查，2023 年 Gartner 和 IDC 的大数据市场的发展趋势报告中，实时计算在整体大数据的占比越来越高，其增量和速度远超平均水平。因此，无论是从企业角度、客户角度还是技术角度，实时计算都已经成为当前发展的明确需求和显著趋势。

二、 实时计算对于企业生产的意义。

在探讨实时计算对企业生产的意义之前，我们可以先举一个例子：在传统制造企业的生产模式中，从作坊式生产转变为引入先进的流水线生产，这对企业来说是一个显著的跨越式升级。从企业管理的角度来看，无论是生产效率、生产质量，还是企业形象，都有明显的提升。而且这种转变也带来了人力成本的下降和员工技能的提升。通过这条流水线，再加上其他批量生产的元器件，就可以构建整个企业的全链路生产视图。

目前，许多技术型互联网公司已经成功地将实时计算链路引入到他们的业务流程中，这类似于传统制造企业引入了流水线。它改变了原本通过数据仓库、数据库等组件构成的传统数据生产链路。这样的技术架构升级，不仅提升了企业的生产效率和管理能力，还使企业能够在有限的时间内挖掘出更多的数据价值，从而支持业务提效和创新。

上图展示了一张实时计算及周边大数据核心组件的通用架构图。从左到右，分别是数据集成、数据处理和数据应用。在很多企业中，日志类数据和业务类数据通过集成工具导入到实时流水线或不同的数据仓库中进行计算和加工。生成的数据再应用于线上业务或算法库。中间过程涉及开发、优化、监控、治理、运维和管理等环节。因此，在这样的技术架构下，企业在进行升级时会产生许多需求。下面我将介绍阿里云提供的大数据产品和产品组合是如何支撑这些需求的。

三、阿里云飞天大数据产品系统架构。

上图展示了阿里云飞天大数据体系的产品大图。我们从下往上看，不同业务的公司有不同类型的数据源，比如业务日志数据、数据库数据及 binlog 数据、开源大数据存储的数据、IoT 设备等各种类型的业务数据库。这些数据通过集成工具接入到数据计算和分析层。计算和分析层的实时计算流水线会加速企业的数据处理。

阿里云实时计算引擎 Flink 已经成为业界实时流式计算的标准。它在产品能力和发展速度上都处于领先地位，特别是在阿里巴巴收购了 Flink 的母公司 Ververica 之后，Flink 在国内的技术影响力达到了前所未有的高度。目前，阿里云 Flink 主推 Serverless 模式，不仅提升了用户的易用性和便捷性，还在稳定性和弹性方面提供了更强的支持。

此外，与实时计算组件配合的还有三个部分，分别是离线数仓、实时数仓和数据开发治理平台。下面分别简要介绍一下各个部分：

1. 与实时计算配合的第一部分是离线数仓/湖仓部分。阿里云在这方面提供了两类产品：

（1）全托管产品：以 MaxCompute 为代表。MaxCompute 已有十几年的历史，为几千家客户提供离线计算服务，其稳定性和整体能力已获得良好口碑。MaxCompute 能够高效处理大规模数据，为企业提供可靠的离线计算解决方案。

（2）半托管产品：以 EMR（Elastic MapReduce）为代表。EMR 本质上是一套开源产品体系的组合，它不仅包括常用的 HDFS 存储和 YARN 调度，还提供了诸如 Hive、Spark等计算引擎。此外，EMR 还支持当前流行的一些数据湖格式，如 Paimon、Iceberg、Hudi 和 Delta Lake 等，提供灵活的数据存储和处理能力。

2 . 图右侧的实时数仓部分有两款产品：

（1）Hologres：Hologres 是一款 HSAP（Hybrid Serving and Analytical Processing）产品，与 Flink 一起经历了多年的阿里双十一大促考验。它不仅可以进行 OLAP（在线分析处理），还支持 Serving 功能，即不仅可以做数据分析，还可以提供 KV（键值）数据查询能力。

（2）EMR StarRocks：EMR StarRocks 是一款全托管的实时数仓产品，专为公有云客户提供服务。其快速发展得益于阿里云计算平台研发团队的持续投入以及开源社区的活跃度。

3 . 最后介绍的是负责数据开发与治理的平台型产品 Dataworks，负责数据集成、数据开发、任务调度、数据治理、数据血缘、数据服务等工作。它可以跨产品、跨地域、跨平台地将这些计算能力串联在一起，不仅能够完成不同类型的大数据任务的串联和调度，还能够将 AI 任务融入到工作流中，进一步提升数据处理的智能化和自动化水平。

四、实时计算的三个典型的技术场景

下面将围绕实时计算，介绍阿里云提供的这些大数据产品及组合在数据集成、实时数仓和离线数仓三个主要技术场景下，如何提升大数据处理能力，并分析以往架构和现有架构的特点、区别以及优劣势，探讨哪一个更符合未来发展的趋势。

1. 技术场景一：Flink实时计算改变传统数据集成的方式。

传统数据集成通常包括从业务数据库到数据仓库的数据迁移过程，主要涉及全量数据同步和增量数据同步两条链路。全量数据同步通常使用工具如 DataX 或 Sqoop，而增量数据同步则通过 Canal 来实现。数据同步完成后，还需要在数据仓库中将存量表和增量表合并，以离线任务的方式生成一个全量表，供下游任务消费和使用。这种传统方法存在以下几个明显的缺点：

（1）链路割裂：需要两条链路，一条是全量同步链路，另一条是增量同步链路。

（2）时效性较差：除了数据导入的时间，还需要在数仓中进行离线调度以完成数据合并，导致端到端的时间较长。

（3）组件繁多：不仅涉及业务库和数仓，还需要使用不同的集成工具，链路中维护的组件非常多，增加了系统的复杂性。

在介绍完传统数据集成之后，我们来看看新一代的一体化数据集成方案。例如，从 MySQL 到 Hive 的整个集成过程，可以实现一键式集成。这相当于使用一个产品来完成以往的离线和实时数据集成，其主要依赖于流批一体化的 Flink CDC 技术。

这种新方案的主要功能是通过一个作业（job）完成全量数据集成，利用多个子任务的并发执行，实现全量数据的快速导入。全量数据导入完成后，系统通过 Hybrid Source 能力自动切换到增量的 Binlog Source，实现无缝对接。在这个过程中，通过无锁一致性快照来确保数据的一致性。

这个方案有以下几个优点：

（1）架构简约：只有一个全托管产品，具备易运维和弹性的能力。对于客户来说，通过云上控制台进行管理，容易简单。

（2）开发简单：只需一条 SQL 语句，就能自动将全量数据转换成增量数据，对数据开发更友好。

（3）运维简便：无论能力如何，只需进行相应的资源和参数配置，配置好前后端数据源，系统就会自动完成任务。

2. 技术场景二：新一代实时数仓 Flink + Hologres

传统的实时数仓架构至少包括四个组件：Flink、Kafka/MQ、维度库或字典表的存储、以及应用层（例如提供 OLAP 和 Serving 能力的库）。其工作流程如下：

（1）数据流入：业务日志或数据流入后，先通过 Flink 进入 Kafka，形成源表层。

（2）维度加载：接下来在 DW 层，通过 Flink 任务加载维度库，进行数据的整合和处理。

（3）数据加工聚合：Flink 继续加载 kafka topic 中经过处理的数据，进行加工或者聚合，并将数据存储到应用层。

（4）应用层处理：根据需求，数据可以回归到业务库。如果需要进行交互式分析，数据会被加载到适合 OLAP 的数据库中；如果需要进行点查服务，则会加载到相应的KV存储，比如 HBase 或 Redis 数据库中。

这种架构广泛应用于传统的实时数仓场景中，以满足业务时效性和不同类型的数据服务需求。该方案具有以下三个特点：

（1）组件多、架构复杂：如前所述，至少需要四个组件（Flink、Kafka、维度库或字典表存储、应用层数据产品）。如果同时需要 Ad-hoc 或 KV 存储，那么至少需要五个组件，运维难度增加。

（2）中间结果查询难：由于 Kafka 按照时间顺序存储数据，中间结果的查询和调试变得困难。在需要进行调试或数据校对时，往往需要将 Kafka 中的数据拉到 OLAP 库中进一步分析，我们在实际工作中经常遇到这样的情况，即耗时费力，又增加了问题捕捉的难度。

（3）资源使用不灵活：实时数仓的各个阶段和层级有明确的任务划分。在业务低峰期，某一层的资源使用率下降后，想要调整该层资源比较麻烦，需要对应调整业务逻辑，这通常是一个复杂且需要多次验证的工作，因为逻辑的调整容易对数据分析结果产生影响。

这种传统方案虽然能满足业务需求，但在运维效率和资源管理上存在一定的挑战。

针对这三个特点，下面介绍新一代实时数仓产品组合解决方案 Flink+Hologres。为了大家便于理解新架构，先为大家介绍一下 Hologres 这个产品及特点：

（1）写入即可见：由于 Hologres 领先的架构设计，它可以做到写入即可见，这一点可以达到 kafka 的实效性，但有别于其他 OLAP 引擎；

（2）Binlog 支持：Hologres 拥有自己的 Binlog，Flink 可以订阅 Binlog 进行下一步的自动加工和分析任务。这一点也是在 OLAP 产品中，区别于其他实时 OLAP 的显著能力。

（2）行存与列存：Hologres 支持行存储和列存储。OLAP 分析通常使用列存储，可以快速进行实时分析；同时，Hologres 也支持行存储和行列共存，行存储主要支持 KV 查询，非常便捷高效。因此，维度库可以直接放在 Hologres 的行存表中，不需要其他存储介质。

（3）高性能实时 Serving 服务：即 Hologres 具有高性能的实时点查能力，基于自身的行存功能，可以进行高 QPS 的 KV 查询能力。

（4）强隔离性：Hologres 可以通过主从实例模式或者 Warehouse 模式实现写入和读取的资源隔离，也可以实现不同业务不同优先级的查询资源隔离，避免相互干扰。这在实时数仓中也非常关键，因为不同层的写入操作可能会导致查询速度变慢。

（5）存算分离：Hologres 具备存算分离的能力，方便运维，能够根据需求灵活扩展或缩减计算资源和存储资源。

介绍完 Hologres 的产品特点之后，我们来看一下新一代实时数仓的方案（如下图）。从左到右看，业务日志进入后通过 Flink 集成到 Hologres中 ，此时除了源表外，还会存在维度表，这些维度表直接加载到 Flink 中。Flink 在此过程中进行数据打宽合并，然后传递到下一层。

在下一层，Flink 任务可以订阅 Hologres 对应表的 Binlog，进行进一步的业务逻辑处理，并将结果存储到 Hologres 的 ADS 层表中。在 ADS 层对外提供服务时，只需要 Hologres 即可，因为它既具备 OLAP 能力，也具备 KV 查询能力，无需其他产品。此外，Hologres 还提供交互式分析能力，如果在数据处理过程中需要对 ODS、DWD、DWS 层的数据进行查验，可以随时通过 SQL 查询对应表中的结构化数据，从而轻松完成中间的调优和调试（ Debug ）。

所以总结下来，新一代实时数仓方案的优势如下：

1. 架构简约易运维：

   （1）少量产品依赖：整个方案主要依赖 Flink 和 Hologres 这两个产品，极大简化了系统架构。

   （2）全托管易运维：Flink 和 Hologres 均为全托管服务，易于运维且具有良好的弹性扩展能力。

2. 中间结果方便查询：

   （1）查询便捷：数仓中间层数据以结构化形式存在 Hologres 中，方便查询。

   （2）快速更新修改：除了查询外，还可以快速更新和修改数据，提升数据处理的灵活性。

3. 数据应用层一体化：

   （1）统一服务能力：Hologres 提供 ADS 层所有的 OLAP 和 serving 能力，减少了面向应用的繁冗组件。

   （2）简化数据服务：通过 Hologres 一体化的数据服务，减少了系统复杂性，提升了数据服务的效率。

4. 资源使用灵活：

   （1）灵活的数据处理：使用Hologres后，不需要固定各层结构，一个临时任务可以直接从 ODS 层抽取数据，迅速形成 ADS 层数据。

   （2）快速分析：对于测试、临时任务或新业务尝试，可以快速进行数据分析，只需根据业务需求灵活调整。

   （3）按需存储分配：存储可以根据业务评估按需分配，提升资源利用效率。

3. 技术场景三：Flink+Paimon 流式湖仓，让传统离线的数仓进行加速和提效。

在企业中进行实时链路计算时，通常会设置一条链路用于离线数仓。离线计算在这个场景中有两个主要作用：

（1）数据校验和更正：离线计算定期处理 Flink 传递过来的数据，用于对数据进行校验和更正。
（2）周期性统计和分析：离线计算根据业务需求，批量处理更长时间周期的统计和分析任务，比如月度、季度和年度的报表。

业务日志和 Binlog 通过 Flink 进行加工后，写入离线存储，随即进入离线数仓的加工流程。这个流程从贴源层（ODS层）到数据仓库明细层（DWD层）再到数据服务层（ADS层），每一层之间通过定时任务进行逐层加工。每一层计算的结果可以通过 Hive、Spark、Trino 等引擎进行查询或更新。

该方案有明显的几个特点：

1. 任务时效性差：每一层定时任务的调度都需要一批批计算，ODS 层算完后才可以计算 DWD 层，如果有较多的表和调度任务，根据业务逻辑会产生比较复杂的依赖关系，那么这些调度任务需要估算比较准确的完成时间以及链路关系，才能保证在要求的时间点产出结果。整个过程都是小时级或天级；

2. 技术栈差异大：在实际大数据团队管理时，实时业务和离线业务会被分为两组，实时业务在实时引擎上做，如果做校对或更正还需要离线业务团队做配合，或者掌握一些离线技术栈，对开发同学不是很友好，会花费较大精力做开发运维方面的工作以及两个团队间的协调；

3. 数据更新不便捷：以往 Hive、Spark 等存储方式都是 Insert、Overwrite 覆写方式来完成更新，新数据得到后，与老数据进行变更合并；

4. 离线实时数据对齐难：实时数据按时间流动，很难找到一个时间点与离线数据完全对齐。

针对以上方案的特点，我们一起看一下 Flink+Paimon 流式数仓的方案是否可以解决以往的痛点。为了让大家更好的理解，先简要介绍一下 Paimon。

Paimon 是一种流批一体的湖存储格式，是一个轻量级的产品，可以部署在 OSS 或 HDFS 上。

Paimon 的产品特点：

（1）区别于 Iceberg/Hudi/Delta Lake 这三个更偏向于批处理的湖格式， Paimon 是流处理演变而来的湖格式，与 Flink 是统一的 SQL 和 API，使用统一的 Flink SQL 可以直接处理湖中的数据；

（2）支持 Upsert、Delete ；

（3）可以轻量级构建在 HDFS/OSS 上，对于 Hadoop、EMR 用户更友好，不需要大幅度改变和调整技术架构，只需要在存储上轻量化部署就可以使用该层能力；

（4） Paimon 有 Changelog，Flink 可以订阅 Changelog 的变化，Changelog 的变化可以自动将上游的变化通过 Flink 任务传给下游；

（5）支持预计算，降低存储成本与下游计算压力；

（6）支持 Time Travel，可以在回溯历史版本中找到某一个节点的状态；

（7）支持表结构变更 Schema Evolution。

了解了Paimon后，我们再来看 Flink+Paimon 新方案，从左到右，业务日志和 Binlog 通过 Flink 集成后进入 Paimon 中，每一层可以通过订阅 Binlog 进行处理，逐层加工后最后形成 ADS 层，再通过 EMR 开源引擎或阿里云自研的引擎等进行查询和分析。

该方案的优势是：

（1）准实时任务效率提高，除了使用 Flink 能力、有自动 Changelog 能力外，可以通过流式任务将湖的任务串联；Paimon Changelog 与 Flink 的 Checkpoint 相关，Flink 的 Checkpoint 可以根据业务需要来设置间隔，两个 Checkpoint 之间的变化会产生一个 Changelog，会把这次变更传给下游，下游得到变化后进行进一步的处理加工；

（2）数据更新与订正的效率高，Paimon 每层支持更新和订正；

（3）开发模型统一，整体流程使用一套 Flink SQL/Table API 即可完成；

（4）数据合并预处理，Paimon 支持很多预计算操作例如去重、部分更新、预聚合等，减少了 Flink 中复杂的业务逻辑；

（5）第五多引擎接入，生态上支持很多常用的引擎，更开放的生态带来对现有大数据架构改造的成本很低，可以将以往偏离线数据的处理能力以流方式进行整体改造。

五、客户案例

在介绍完产品体系和三个主要技术场景之后，下面介绍两个客户案例。

1. 某游戏实时数仓架构的演进。

该客户是全球 Top 20 的游戏公司，运营很多游戏，每天处理的实时数据达到 pb 级。原有技术架构的痛点是 OLAP 组件很多，每个 OLAP 都有自己的特点，例如 Clickhouse 擅长大宽表、ADB 擅长较小规模数据量分析等，离线数据的查询基于传统的 Impala 方式等。整个架构流程是：数据库及日志数据进入 Kafka，Flink 消费 Kafka 中 topic 数据进行逐层的加工和分析。同时过程中 Flink 还会把数据写入离线链路，离线引擎做数据的校验和备份等。如果过程中出现问题，可以使用 Impala 做离线数据加速查询，用以排查问题和校验分析。实时链路最后将数据写入 Clickhouse 中，而为了保证实时链路的稳定性，离线数据最后加工以及与实时数据的比对采用了另外一个 OLAP 引擎 ADB。

为了解决以往架构的痛点，客户选择了升级新架构的方案：实时链路改造成了 Flink+Hologres 实时数仓模式，并引入了 MaxCompute，借助 Hologres+MaxCompute+dataworks 共享存储的能力，形成了实时离线一体化的能力。

这里先解释一下实时离线一体化，从三个层面来简要说明：第一个层面即数据开发层，通过 Dataworks 统一 IDE 入口，可以完成 Hologres 和 MaxCompute 的任务编写，并可以通过 Dataworks 形成同一个调度工作流，完成离线和实时任务的混合编排；第二个层面即计算层的联邦计算，由于 Hologres 和 MaxCompute 两个引擎的元数据可以打通，用户很容易可以通过内外表的形式来进行联合计算分析；第三个层面即存储层，由于两个引擎都是基于阿里云 Pangu 体系建立，所以 Hologres 可以便捷的为 MaxCompute 中的离线数据做加速，而且两个引擎之间传递数据速度非常快，提升了效率的同时也节省了大量数据集成的资源；

在上面介绍的架构升级方案上，客户将原来的 ADB、Clickhouse、Impala 全部替代，因为 Hologres 强大的计算和存储能力，使得以往的离线数仓分层改变，基本 ADS 层全部存储的 Hologres 中。而且 Hologres 可以做 MaxCompute 的离线加速，这些能力让客户决策可以缩减掉离线数仓中冗余的部分，使得离线部分更精炼和易于管理。

这些先进的理念和架构实现帮助客户在完成架构升级之后，有几个明显的体感：

（1）架构上比较统一，不需要维护多个组件，节省人力的同时，也不需要做很多组件联合扩缩容的规划；

（2）实时链路的可用性更强了，在过程查询和问题发现方面非常便捷，而且在支持创新业务时，也可以在不改变 source 逻辑的情况下，在实时数仓中快速形成临时的实时分析任务，支持临时决策。实时链路中个别场景的性能也有大幅提升，比如CK的Join查询可以提升一个数量级以上；

（3）实时离线一体化的能力，使得整体数据分层和治理更科学，任务编排统一化以及治理能力的提升，都让客户有能力在支持好现在和未来业务的同时，掌握了规划和控制成本的手段；

2. 某出行客户离线数仓架构演进。

该客户是一家国内知名的出行企业，月活跃用户达到千万级别，每日处理的数据量非常庞大，实时计算需求远高于离线计算需求。客户的业务痛点如下：

（1）技术线分离：采用典型的 Lambda 架构，实时和离线计算分离，导致两条线之间存在复杂的业务逻辑交互；

（2）高存储成本：实时和离线各存储一份数据。对于这个客户来说业务行为日志处理很重要，因为实时和准实时的处理都走实时计算的引擎和存储，故导致实时存储的成本占比较大；

（3）流处理中间数据查询困难：实时计算过程中，查询中间数据较为困难。

客户原有架构的实时线采用 Flink + Kafka，定期将数据 Dump 到离线 Hive 中，进行备份和进一步的离线加工分析。在离线链路中还引入了 Presto，用于查询和部分准实时业务，处理完成后供应用使用。

新架构通过 Flink + Paimon 将准实时链路和离线链路融合在一起，形成一套完整的模式。这里的准实时任务要求数据处理时限在分钟级，适用于需要人为判断的任务，例如报表生成或分钟级的应用处理逻辑。而实时任务通常要求秒级或毫秒级的处理时限，数据结果由机器或程序判断，例如风控和实时推荐等业务。

上述技术场景三中，Flink + Paimon 的使用使得可以在数据处理中通过 Flink SQL 进行查询。同时，为了应对大量的离线数据处理需求和临时任务需求，还引入了 StarRocks。StarRocks 可以直接查询 Paimon 表，性能比 Presto/Impala 高出两倍以上。

这个改造之后，对于客户的影响比较明显：第一，纯实时链路的业务复杂度明显降低，实时和离线交互的任务减少 40%+；第二，每年节省出 65% 以上的 Kafka 存储成本，而且准实时的数据不需要存两份，只需要存 HDFS 一份；由于 Kafka 使用价格较高的 SSD 存储介质，成本较高，换成 HDFS 的 HDD 后，每年综合节省近千万成本；

通过围绕实时计算产品 Flink，我们一起探讨和梳理了系统架构和技术场景，并在客户案例中提出了对架构升级的思考。希望这些经验能对您和您所在的企业有所帮助，同时期待 Flink 的新功能和特性能帮助更多企业释放数据业务的潜能。