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

star2017 1年前 ⋅ 1788 阅读

分享嘉宾:梁建煌 爱奇艺

编辑整理:张宇轩

内容来源:Flink Forward Asia

导读: 随着大数据的快速发展,行业大数据服务越来越重要。同时,对大数据实时计算的要求也越来越高。今天会和大家分享下爱奇艺基于 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 以及开发平台等。


本文地址:https://www.6aiq.com/article/1595550476879
本文版权归作者和AIQ共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出

更多内容请访问:IT源点

相关文章推荐

全部评论: 0

    我有话说: