基于 Apache Flink 的爱奇艺实时计算平台建设实践

导读： 随着大数据的快速发展，行业大数据服务越来越重要。同时，对大数据实时计算的要求也越来越高。今天会和大家分享下爱奇艺基于 Apache Flink 的实时计算平台建设实践。

今天的介绍会围绕下面三点展开：

• Flink 的现状与改进

• 平台化的探索和实践：实时计算平台

• Flink 业务案例

01 Flink 的现状与改进

1. Flink 现状

首先和大家分享下爱奇艺大数据服务的发展史。

我们从 2012 年到 2019 年，大数据服务经过了一系列持续的改进和发展：

• 2012 年搭建了第一个 Hadoop 集群，当时只有大概 20 几个节点，使用的计算框架是 MapReduce 和 Hive 等

• 到 2013，2014 年，开始使用 Hadoop 2.0，上线了 Storm 和 Spark，由于 Storm 的使用性和稳定性不够好，被放弃使用，转而使用 Spark

• 2015 年发布了第一个实时计算平台 Europa，上线了 Kafka

• 2017 年使用了 Flink，同时我们基于 Spark 和 Flink 打造了流式计算引擎 StreamingSQL

• 2018 年推出了自研的实时计算平台 Real-time Analytics Platform (RAP)

• 2019 年基于 Flink 达到了内部的流数据生态平台；

然后介绍一下 Flink 在爱奇艺的使用情况：

这是 Flink 在爱奇艺的一些使用情况，目前的节点规模大约 15000 多台，总的作业规模有 800 多个，每天的数据流的生产量大概在万亿级别，约 2500TB 左右。注：本数据仅代表嘉宾分享时的数据。

下面是目前爱奇艺基于 Spark，Flink 打造的实时计算平台框架：

• 底层存储使用的 HDFS，HBase，Kafka 和 OSS。

• 实时计算框架通过 Spark 和 Flink 部署，在这两个服务之上，构建了一个独立的流式系统引擎 StreamingSQL。

• 在引擎之上，打造了多种类型的平台，用来实现管理计算的任务，流数据的生产分发和实时数据分析等不同需求。

• 实时计算在爱奇艺业务上有些典型的应用场景：实时分析、报警，信息流(如广告类)推荐，内部数据在线训练，实时风控（内容追踪等）。

2. Flink 改进

Flink 改进-监控和报警：

以前只是做了简单的状态监控，在出现问题之后，不知道内部状态是怎么样的。近期做了一些改进，并和内部的监控平台 Hubble 进行集成，主要有三个级别的监控指标：

• Job 级别监控指标：Job 状态、Checkpoint 状态和耗时。如果没有进入到 running 状态，会对其进行重启操作，防止其查询卡在不健康状态下

• Operator 级别监控指标：时延、反压、Source/Sink 流量，对每个 Operator 进行指标聚合

• TaskManager 级别监控指标：CPU 使用率、内存使用率、JVM GC 等

Flink 改进-状态管理：

问题一： 长时间运行 Flink job，会因为各种原因导致它重启。Checkpoint 只在 Flink 作业内部有效，一旦主动重启或异常重启时，上一个 job 的状态会全部丢失。

解决方法：作业重启时，找到上一次运行成功的 Checkpoint，从中恢复。

缺陷：对于状态很大的作业，会使用 RockDBStateBackend 做增量 Checkpoint；上一次的 Checkpoint 被依赖而无法删除，会导致状态堆积（生产环境中的一个作业的 Checkpoint 总共多达 8TB）。

对于这个缺陷也就是：

问题二： Checkpoint 无限依赖

解决方法：使用 Savepoint 打断增量 Checkpoint 的依赖链，并与流计算平台集成。

主要有两种产品，一种是通过业务通过平台主动重启，重启之前对此 job 做一次 Savepoint 操作，启动时从 Savepoint 的路径去启动。

第二种是发生异常重启时，来不及做 Savepoint。那么会在 Checkpoint 启动起来，一旦 job 进入到 running 状态以后，立即做一次 Savepoint，解决依赖问题。

StreamingSQL：

StreamingSQL 是基于 Spark 和 Flink 构建的一个统一的流数据 ETL 工具，具有以下一些特征：

• SQL 化：业务上去写流计算任务时，不需要去写 Scala 程序，只需要编写一些 SQL 代码即可完成流计算 ETL 任务的开发。

• DDL：流表、临时表、维度表、结果表。

• UDF：系统预定义常用函数、用户自定义函数。

• 提供 SQL 编辑器。

下面是 StreamingSQL 的一个实例：

02 实时计算平台

1. 实时计算管理平台

上图是 Spark、Flink 任务开发和管理的 web IDE 的例子，用户可以在页面上配置一些参数和字段，进行任务的开发，上传，作业的重启，运行状态的查看等常规操作。

此外，还提供其他的一些管理：

• 文件管理：任务 Jar 包、依赖库。

• 函数管理：提供丰富的系统函数、支持用户注册 UDF。

• 版本管理：支持任务、文件的版本对比以及回滚。

• 常规管理：监控大盘、报警订阅、资源审计、异常诊断。

2. 实时数据处理平台

为了确保数据发挥该有的价值，让数据的流转更加通畅，让业务处理数据、使用数据和分析数据更加便捷，我们改进服务，推出了数据处理平台和数据分析平台。

以下是实时数据处理平台演进过程：

2015 – 2016

• 场景：离线报表为主，少量实时报表需求，数据生产规模 50 万 QPS；

• Venus 1.0 数据采集平台：基于 Apache Flume；在 Venus agents 上通过 tail+grep/awk/sed 等脚本过滤；

• 缺陷：不方便变更过滤规则，需重启所有 agents；不同用户需求存在大量重复处理逻辑。

2017 – 2018

• 场景：实时分析、信息流推荐等实时需求增加，500 万 QPS

• Venus 2.0 数据采集分析平台：实时过滤从 Venus agent 迁移到 Flink，采用两级 Kafka；无需重启即可动态增减处理规则

• 缺陷：Kafka 数据冗余，不方便分享 Kafka 数据

2019

• 场景：大量实时业务需求，1500 万 QPS

• Venus 3.0 流数据生产分发平台：通过 web 配置实时处理规则，可自由组合常见算子；参考离线数仓，按照数据使用场景构建流式数仓

• 优点：减少流数据重复生产，促进流数据共享

下面是一个例子，流数据处理平台的一个页面。目前平台支持 Projection、Filter、Split、Union、Window、UDF 等常见算子。

3. 实时分析平台

目前我们实时数据 OLAP 分析平台主要有两大类：一类是实时报表，主要有 A/B 测试、精细化运营等；另一类是实时报警，主要有 VV/UV、播放故障等。

下图是现在的一个架构图：

目前支持流处理平台，Kafka，Hubble 监控系统，MySQL binlog 这些数据源。用户可以通过 UI 配置处理规则，分析规则，需要展示的报表的风格，以及一些报警的规则。这些处理规则和分析规则等，后台会自动把它们的 function 对应的服务转成一个 job，然后自动把结果上传到 MySQL 里。此外，用户可以在多平台上面进行分析查看、观测报警率等，也可以方便的通过 api 对接到自己的第三方的定制化平台里。

目前，我们实时分析平台拥有以下一些优势：

• 开发门槛低：无需写程序或 SQL

• 开发效率高：由以前的几天到现在的半小时就能完成

• 报表实时：从小时级别优化到现在只需要 1 分钟

• 查询更快：支持大规模数据亚秒级查询

下面展示的是一些页面的模块。

配置处理规则：

配置 OLAP 模型：

03 Flink 业务案例

1. 信息流推荐

我们所有的数据都是通过实时收集到二级 Kafka 里面，通过 Stream 处理平台分级成点击、查看、订阅、搜索等一系列行为不同的 Kafka 里。然后再经过处理平台处理以后，生产相应的用户特征，用户画像等实时流，最后被推荐引擎去使用。

我们从 Spark Streaming 迁移到 Flink，消除了批处理延迟。目前单个任务延迟从 1 分钟缩短到 1-2 秒，端到端性能提升 86 倍，并且显著提升了推荐效果。

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

上图是一个广告推荐相关的例子，这是以前的一个架构，通过 Hive/Spark 离线 ETL 生成广告深度学习算法所需要的训练数据，算法模型更新周期为 6 小时。

从 2018 年初开始，对框架做了实时的一个改造。实时过来的用户行为数据会实时投递到 Kafka 里，通过 Flink 处理完以后，生成一些新的 Delta 数据；过去 7 天分析的广告特征、用户特征投到 Kafka，通过 Flink 处理完以后，存到 HBase 里。Kafka 实时流（最近 24 小时）和 HBase 维度表（最近 7 天）这两部分数据 Join 之后生成一个 Session 流，再给算法预测使用。

通过框架的改进，目前算法模型更新从 6 小时缩短到 1 小时，并且支持实时 CTR 预估，更好指导广告决策，提升广告收益。

3. 端到端 Exactly-Once 处理

由于目前存在一个问题：Kafka 节点故障重启或人工运维时，业务方重复消费数据。因此最近正在研究端到端 Exactly-Once 处理的一个方案：Kafka Exactly-Once Semantics + Flink two-phase commit.

但是，这个方案会造成 Flink 任务计算性能的 20%损耗，从业务方向角度来讲，这个是在可接受范围内的。

4. 挑战与规划

以下是未来的一些规划：

• 流批一体化

• SQL 化：进一步完善和推广 StreamingSQL，降低开发门槛

• 基于 Flink 的机器学习的尝试和使用

• 提高 Flink 作业的资源利用率，支持动态资源调整

• Flink on Kubernetes

作者介绍：

梁建煌，爱奇艺大数据服务负责人，2012-硕士毕业于上海交通大学后，先后在 SAP、爱奇艺工作，从 2013 年起开始负责爱奇艺大数据服务体系的建设工作，包括大数据存储、计算、OLAP 以及开发平台等。

本文来自 DataFunTalk

原文链接：

https://mp.weixin.qq.com/s?__biz=MzU1NTMyOTI4Mw==&mid=2247504067&idx=1&sn=4a0788df9bb2c0d181388ef8663b01ba&chksm=fbd762afcca0ebb958873c6d795edf269f817fc251d208b1dca57cdd0457f2edd24c401bac50&scene=27#wechat_redirect