stream平台 trade api_基于Apache Flink的爱奇艺实时计

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

01 Flink的现状与改进

1.Flink现状

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

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

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

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

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

2. Flink改进

Flink改进-监控和报警：

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

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工具，具有以下一些特征：

下面是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配置处理规则，分析规则，需要展示的报表的风格，以及一些报警的规则。这些处理规则和分析规则等，后台会自动把它们的function对应的服务转成一个job，然后自动把结果上传到MySQL里。此外，用户可以在多平台上面进行分析查看、观测报警率等，也可以方便的通过api对接到自己的第三方的定制化平台里。

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

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

配置处理规则：

配置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. 挑战与规划

以下是未来的一些规划：

作者介绍：

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

（编辑：92站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!