1.爱奇艺 Flink 服务现状

爱奇艺从 2012 年开始开展大数据业务，一开始只有二十几个节点，主要是 MapReduce、Hive 等离线计算任务。到 2014 年左右上线了 Storm、Spark 实时计算服务，并随后发布了基于 Spark 的实时计算平台 Europa。2017 年开始引入 Flink，用来替代部分 Spark Streaming 场景，满足更低延迟的实时计算需求。在这之后，相继推出流式 SQL 引擎、实时分析平台、实时数据生产平台等一系列工具，用来提升实时计算开发效率。

目前公司内 Flink 类型节点机器 15000 多台，主要有两种部署模式：

1. 混部模式：Flink、Spark、MapReduce 等服务混合部署，15000 多台规模
2. 独立模式：Flink 服务独立部署，用于重要业务，约 700 多台规模

Flink 作业规模达到 800 个，每日数据生产量维持在万亿级别，日均 2500 TB。

下图所示为爱奇艺实时计算服务体系：

2.Flink 改进

2.1 监控和报警

Flink 原有的监控比较简单，无法满足业务细粒度的监控报警需求。当计算过程出现问题时，无法清晰了解计算作业内部情况，不利于进一步分析。因此，我们改进了 Flink 监控报警机制，增加了很多细粒度的监控指标，主要包括三种：

• Job 级别监控指标：监控 Job 状态、Checkpoint 状态及耗时，当 Job 异常时自动通过实时计算平台重启。
• Operator 级别监控指标：监控 Flink 任务的时延、反压、Source/Sink 流量，并对每个 Operator 进行指标聚合，以便用户查看。
• TaskManager 级别监控指标：监控 CPU 使用率、内存使用率、JVM GC 等常规指标。

2.2 状态管理

由于 checkpoint 是 Flink job 内部状态，当 job 重启时，上一个 job 的状态就丢失掉，导致部分数据丢失，影响到业务。

针对上述问题，我们对 Flink 作业状态管理进行了改进。用户提交 Flink job 时，会在实时计算管理平台上配置 checkpoint 路径。通过实时计算管理平台重启 Flink job 时，先找到上一次成功的 checkpoint，从中恢复 job 丢失的状态（flink run -s :checkpointPath/chk-n/_metadata）。

改进后解决了状态丢失的问题，但带来新的缺陷。对于状态数据很大的作业，使用 RocksDBStateBackend 做增量 checkpoint，重启后，上一个 job 的 checkpoint 被依赖而无法删除。随着 Flink 作业长时间运行且发生多次 job 重启，系统中堆积大量无用的 checkpoint。

针对该问题，我们使用 savepoint 方式打断增量 checkpoint 的依赖链：

1. 主动重启：通过计算平台主动重启 Flink job 前，系统会先对 job 进行 savepoint 操作再关闭 job，然后从该 savepoint 启动（flink run -s :savepointPath）。
2. 异常重启：当平台监测到 Flink job 异常时，会自动从上次 checkpoint 开始启动该 job。一旦 job 进入到 RUNNING 状态，会先做一次 savepoint，解除对上一个 checkpoint 的依赖。

2.3 StreamingSQL

为了便于用户开发流任务，爱奇艺自研了支持 Spark、Flink 的流式 SQL 引擎 StreamingSQL。用户只需要通过编写 SQL 即可完成流计算 ETL 任务的开发。同时，我们也提供 IDE 编辑器和大量常用的预定义函数。

StreamingSQL 定义了 4 种类型数据表：

• 流表：定义计算逻辑的输入，目前支持Kafka
• 维度表：静态表，用于与流表join，比如字典映射
• 临时表：定义中间结果，简化子查询逻辑
• 结果表：定义计算逻辑的输出

数据从流表流入，通过一系列 SQL 语句描述的计算，计算结果写入结果表。对于计算逻辑比较复杂的计算，可能需要定义多层嵌套的子查询对计算逻辑进行描述，此时可以通过定义临时表，将计算逻辑进行拆分，降低子查询嵌套的深度。

下图展示了 StreamingSQL 例子：

3.实时计算平台

爱奇艺从 2015 年开始陆续推出实时计算管理、实时数据生产、实时数据分析等多个平台，满足作业开发、数据生产、数据分析等不同场景下的开发需求，提升用户的使用体验和开发效率。

3.1 实时计算管理平台

实时计算管理平台用于 Spark、Flink 任务的开发与管理。用户可以在 Web IDE 上配置相关参数进行任务的开发、上传、启动、停止等常规操作。计算管理平台提供了大量管理模块以提高用户的操作体验，主要包括以下几项：

1. 文件管理：通过平台的文件管理功能用户可以方便的管理任务的 Jar 包及依赖库。
2. 函数管理：为用户提供了丰富的系统函数，并支持用户注册 UDF。
3. 版本管理：用户可以实现任务、文件的版本对比及旧版本的回滚。
4. 系统同时提供了监控大盘、报警订阅、资源审计、异常诊断等多种功能辅助用户实时掌握作业情况。

3.2 实时数据处理平台

爱奇艺的数据处理平台经历了 3 个阶段的迭代升级，从原先的离线数据采集系统一步步演变成支撑千万 QPS 的实时数据生产平台。

■ Venus 1.0 – 数据采集系统

2015 年开始，我们推出了第一代数据采集平台 Venus 1.0。数据来源于两个方面，从客户端端收集到的用户观看视频的行为数据及后台服务的日志数据。用户数据从 PC、App 等客户端采集投递给平台后端的 Nginx 接收器，并落盘到本地文件中，再由 Venus agent 解析文件进行数据采集。服务日志数据是由机器上的 Venus agent 解析 log 文件采集。Venus 采集的数据直接上传到 HDFS 进行后续的离线 ETL 处理，生成离线报表供数据分析使用。

Venus 1.0 版本主要基于 Apache Flume 框架进行开发，并通过 tail+grep、awk、sed 等脚本进行数据过滤。在数据量较小时，该平台很好的解决了数据处理的需求。

■ Venus 2.0 – 实时数据处理平台

在 2017 年，随着数据量的增长及实时业务需求的出现，Venus 1.0 渐渐变得力不从心。众多业务需求导致 agent 上存在大量过滤规则，过多占用机器资源甚至影响到机器上服务的稳定性。同时，每次变更都需要重启所有 agents，大大提高上线成本及风险。

因此，我们设计实现了实时数据处理平台 Venus 2.0 版本，将实时过滤功能从 Venus agent 迁移到 Flink 中并采用两级 Kafka 结构。改进后的数据平台无需重启即可动态增减数据处理规则，数据处理能力也提升了 10 倍以上，大大优化了平台的实时效果。

■ Venus 3.0 – 实时数据生产平台

随着实时业务的大量增加，Venus 2.0 也带来了 Kafka 数据冗余、不方便分享等问题，我们在 2019 年进行了第三次改造，从数据处理升级到数据生产，推出了实时数据生产平台 Venus 3.0 版本。

用户可以在新平台上配置实时数据处理规则，并可自由组合 Filter、Split、Window 等常见算子，生产出来的流数据可以存储到流式数仓里。流式数仓是我们参考离线数仓概念打造的基于 Kafka 的数据仓库，用于以数据仓库的形式统一管理流数据。

借助实时数据生产平台及流式数仓，用户可以更加便捷地加工实时流数据，并通过业务线间的数据分享来减少流数据的重复生产。

3.3 实时数据分析平台

RAP（Realtime Analysis Platform）是爱奇艺基于 Apache Druid + Spark / Flink 构建的分钟级延时的实时分析平台，支持通过 web 向导配置完成超大规模实时数据的多维度分析，为用户提供一体化的 OLAP 分析操作流程，只需要几步简单的配置，即可自动建立 OLAP 模型、生成分钟级延时的可视化报表，并提供实时报警功能。

RAP 实时分析平台解决了用户在数据分析中遇到的几个困难：

1.OLAP 选型困难：爱奇艺目前提供了 Kylin、Impala、Kudu、Druid、ElasticSearch 等不同的数据存储/查询引擎，用户需要了解不同 OLAP 引擎的优缺点，花费大量精力学习，依然可能选错。RAP 帮用户屏蔽了这层，无需考虑中间数据、结果数据存到哪里、怎么查询。2. 开发成本高：用户需要写 Spark 或 Flink 代码进行实时流数据处理，并进行报表前端开发，流程冗长而复杂。在 RAP 实时分析平台上，用户无需编写Spark/Flink 程序或 SQL，只需要通过 web 配置处理规则、分析规则、报表模板、报警规则即可，大幅降低开发门槛，提升了开发效率，从以往的几天开发一张报表缩短到半小时。3. 数据实时性差：从数据产生到数据可被查询，中间存在较高时延（从数十分钟到天级别不等），且查询较慢。借助于 Flink 的实时处理能力，RAP 实现了端到端分钟级低延时的实时报表功能，且支持大规模数据亚秒级查询。

1. 维护耗费时间：数据源发生改变时，修改的范围会覆盖整个流程，从数据处理到报表配置全部需要变更，很难操作和维护。RAP 提供了自动更新功能，帮助用户免去人工维护的麻烦。

RAP 实时分析平台架构图：

4.Flink 业务案例

4.1 信息流推荐实时化

爱奇艺很早就开始了基于网格式的长视频推荐业务，近几年随着短视频的兴起，信息流形式的推荐发展迅速。信息流场景里，需要在几秒内根据用户的观看行为实时推荐相关性更高的视频，对数据的时效性要求更高。

原本基于 Spark Streaming 的实时数据处理架构无法满足这类低延迟的需求，因此，我们协助业务迁移到 Flink 平台上，消除了批量数据处理带来的延迟。单个任务的延迟从 1 分钟缩短到 1-2 秒，端到端的性能提升了 86 倍，显著提升了推荐效果。

4.2 使用 Flink 生产深度学习训练数据

深度学习大量应用于爱奇艺内部的各项业务，帮助业务更好的挖掘数据的价值。在深度学习场景中，训练数据的时效性非常关键。我们使用 Flink 帮助业务更加实时地生产训练数据。

下图所示为爱奇艺广告点击率预测训练的架构，业务原先通过 Hive/Spark 离线 ETL 方式生成训练数据，每 6 小时才能更新一次算法模型，导致用户特征关联不及时、不精确，影响到广告投放效果。

我们基于 Flink 进行了实时化改造，将最近 24 小时的用户数据实时写到 Kafka 中，通过 Flink 与存储在 HBase 中的过去 7 天的用户特征进行实时 join，实时产出包含最新用户特征的训练数据，将算法模型更新周期缩短到 1 小时以内，从而支持更加实时、精确的 CTR （Click-Through-Rate）预估，大幅提升广告投放效果。

4.3 端到端 Exactly-Once 处理

当 Kafka 节点出现故障重启或进行人工运维时，Flink 作业会重复消费数据导致数据失准，影响后续的数据处理，比如模型训练。针对该问题，我们设计实现了基于 Kafka Exactly Once Semantics 及 Flink two-phase commit 特性的端到端 Exactly-Once 处理方案。经过我们测试，该方案会带来 20% 的计算性能损耗，但数据重复率会从原先的最高 300% 降低到 0，很好地解决了节点重启带来的数据精确度问题。

关于 Exactly-once two-phase commit 的原理，可以阅读 Apache Flink Blog 上的详细介绍：

https://flink.apache.org/features/2018/03/01/end-to-end-exactly-once-apache-flink.html

5.挑战与规划

随着 Flink 在爱奇艺得到越来越广泛的应用，我们在资源管理、稳定性、实时开发等层面面临新的挑战。

接下来，我们会推进流批一体化，进一步完善和推广 StreamingSQL 技术，降低开发门槛。同时，积极尝试基于 Flink 的机器学习、Flink on Kubernetes、Flink 动态资源调整等前沿方向。