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

　　

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

　　然后介绍爱奇艺中Flink的使用:

　　

　　这些是Flink在爱奇艺中的一些用法. 当前节点规模约为15,000，操作的总规模超过800. 每天的数据流生产量约为数万亿，约2500TB. 注意: 此数据仅代表来宾共享时的数据.

　　以下是爱奇艺基于Spark和Flink构建的当前实时计算平台框架:

　　

　　2. Flink改进

　　Flink改进监控和警报:

　　过去，我只做一个简单的状态监视. 发生问题后，我不知道内部状态如何. 最近，已经进行了一些改进并将其与内部监视平台Hubble集成在一起. 监控指标主要分为三个级别:

　　Flink改进状态管理:

　　

　　问题1: 长时间运行Flink作业将由于各种原因而导致其重新启动. 检查点仅在Flink作业内有效. 一旦主动或异常重新启动，先前作业的状态将丢失.

　　解决方案: 作业重新启动时，找到上次成功运行的检查点并将其还原.

　　缺陷: 对于状态非常大的作业，RockDBStateBackend将用作增量检查点；以前的检查点是从属的，不能删除，这将导致状态累积（生产环境中作业的总检查点高达8TB）.

　　对于此缺陷:

　　问题2: Checkpoint无限依赖项

　　

　　解决方案: 使用Savepoint中断增量Checkpoint的依赖链并与流计算平台集成.

　　有两种主要产品. 一种是通过平台积极重启业务. 重新启动之前，请在作业上执行保存点操作，并在启动时从保存点路径启动它.

　　第二种类型为时已晚，无法在异常重启时执行保存点. 然后它将在Checkpoint启动. 作业进入运行状态后，将立即执行保存点以解决依赖关系问题.

　　StreamingSQL:

　　StreamingSQL是基于Spark和Flink的统一流数据ETL工具. 具有以下特点:

　　以下是StreamingSQL的示例:

　　

　　02实时计算平台

　　1. 实时计算管理平台

　　

　　上图是用于Spark和Flink任务开发和管理的Web IDE的示例. 用户可以在页面上配置一些参数和字段，以进行任务开发，上载，作业重新启动和运行状态检查.

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

　　2. 实时数据处理平台

　　为了确保发挥数据的价值，使数据流更顺畅并使业务更易于处理数据，使用数据和分析数据，我们改进了服务，并推出了数据处理平台和数据分析平台.

　　以下是实时数据处理平台的演变:

　　2015年– 2016年

　　

　　2017年– 2018年

　　

　　2019

　　

　　下面是一个示例，流数据处理平台的页面. 目前，该平台支持常见的运算符，例如Projection，Filter，Split，Union，Window，UDF.

　　

　　3. 实时分析平台

　　当前，我们的实时数据OLAP分析平台主要分为两类: 一类是实时报告，主要包括A / B测试，精细化操作等；另一类是实时报告. 另一个是实时警报，主要包括VV / UV，播放失败等.

　　下图是当前的架构图:

　　

　　当前，它支持数据源，例如流处理平台，Kafka，Hubble监视系统和MySQL binlog. 用户可以通过UI配置处理规则，分析规则，要显示的报告样式以及一些警报规则. 对于这些处理规则和分析规则，后台将自动将与其功能相对应的服务转换为作业，然后将结果自动上传到MySQL. 此外，用户可以分析，查看和观察多个平台上的警报率，还可以通过API轻松连接到自己的第三方定制平台.

　　当前，我们的实时分析平台具有以下优势:

　　某些页面的模块如下所示.

　　配置处理规则:

　　

　　配置OLAP模型:

　　

　　03 Flink商业案例

　　1. 信息流推荐

　　

　　我们所有的数据都实时采集到辅助Kafka中，并通过流处理平台通过不同的行为（例如单击，查看，订阅和搜索）分类为Kafka. 然后，由处理平台进行处理后，生成诸如相应的用户特征和用户肖像之类的实时流，并最终由推荐引擎使用.

　　我们从Spark Streaming迁移到Flink，从而消除了批处理的延迟. 目前，单项任务的延迟从1分钟缩短为1-2秒，端到端性能提高了86倍，推荐效果也得到了明显改善.

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

　　

　　上图是广告推荐的示例. 这是以前的体系结构. 广告深度学习算法所需的训练数据是通过Hive / Spark离线ETL生成的. 算法模型更新周期为6小时.

　　

　　自2018年初以来，该框架已经进行了实时转换. 实时的用户行为数据将实时发送到Kafka. 通过Flink处理后，将生成一些新的增量数据. 过去7天内分析的广告特征和用户特征将传递给Kafka，并通过Flink处理后，将其存储在HBase中. 将Kafka实时流（最近24小时）和HBase维度表（最近7天）结合在一起以生成Session流，然后将其用于算法预测.

　　通过框架的改进，当前的算法模型更新从6小时缩短到1小时，并且支持实时CTR估算，从而可以更好地指导广告决策并增加广告收入.

　　3. 端到端完全一次处理

　　由于当前存在问题: 当Kafka节点无法重新启动或手动操作和维护失败时，业务侧会重复使用数据. 因此，我们目前正在研究端到端完全一次处理的解决方案: Kafka完全一次语义+ Flink两阶段提交.

　　

　　但是，此解决方案将导致Flink任务计算性能损失20％. 从业务方向的角度来看，这是可以接受的范围.

　　4. 挑战与计划

　　以下是对未来的一些计划:

　　作者简介:

　　爱奇艺大数据服务负责人梁建煌，2012年毕业于上海交通大学，获硕*敏*感*词*后，先后在SAP和爱奇艺工作. 自2013年以来，他一直负责爱奇艺大数据服务系统的建设. 包括大数据存储，计算，OLAP和开发平台.