开发者社区> apache_flink> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

从 Spark Streaming 到 Apache Flink : 实时数据流在爱奇艺的演进

简介: 本文将为大家介绍 Apache Flink 在爱奇艺的生产与实践过程。你可以借此了解到爱奇艺引入 Apache Flink 的背景与挑战,以及平台构建化流程。
+关注继续查看

作者:陈越晨

整理:刘河

本文将为大家介绍Apache Flink在爱奇艺的生产与实践过程。你可以借此了解到爱奇艺引入Apache Flink的背景与挑战,以及平台构建化流程。主要内容如下:

  1. 爱奇艺在实时计算方面的的演化和遇到的一些挑战
  2. 爱奇艺使用Flink的User Case
  3. 爱奇艺Flink平台化构建流程
  4. 爱奇艺在Flink上的改进
  5. 未来工作

爱奇艺简介

爱奇艺在2010年正式上线,于2018年3月份在纳斯达克上市。我们拥有规模庞大且高度活跃的用户基础,月活跃用户数5.65亿人,在在线视频领域名列第一。在移动端,爱奇艺月度总有效时长59.08亿小时,稳居中国APP榜第三名。

一、爱奇艺在实时计算方面的演化和遇到的一些挑战

1. 实时计算在爱奇艺的演化过程

实时计算是基于一些实时到达、速率不可控、到达次序独立不保证顺序、一经处理无法重放除非特意保存的无序时间序列的数据的在线计算。

因此,在实时计算中,会遇到数据乱序、数据延时、事件时间与处理时间不一致等问题。爱奇艺的峰值事件数达到1100万/秒,在正确性、容错、性能、延迟、吞吐量、扩展性等方面均遇到不小的挑战。

爱奇艺从2013年开始小规模使用storm,部署了3个独立集群。在2015年,开始引入Spark Streaming,部署在YARN上。在2016年,将Spark Streaming平台化,构建流计算平台,降低用户使用成本,之后流计算开始在爱奇艺大规模使用。在2017年,因为Spark Streaming的先天缺陷,引入Flink,部署在独立集群和YARN上。在2018年,构建Streaming SQL与实时分析平台,进一步降低用户使用门槛。

2. 从Spark Streaming到Apache Flink

爱奇艺主要使用的是Spark Streaming和Flink来进行流式计算。Spark Streaming的实现非常简单,通过微批次将实时数据拆成一个个批处理任务,通过批处理的方式完成各个子Batch。Spark Streaming的API也非常简单灵活,既可以用DStream的java/scala API,也可以使用SQL定义处理逻辑。但Spark Streaming受限于微批次处理模型,业务方需要完成一个真正意义上的实时计算会非常困难,比如基于数据事件时间、数据晚到后的处理,都得用户进行大量编程实现。爱奇艺这边大量使用Spark Streaming的场景往往都在于实时数据的采集落盘。

Apache Flink框架的实时计算模型是基于Dataflow Model实现的,完全支持Dataflow Model的四个问题:What,支持定义DAG图;Where:定义各类窗口(固定窗口、滑动窗口和Session窗口);When:支持灵活定义计算触发时间;How:支持丰富的Function定义数据更新模式。和Spark Streaming一样,Flink支持分层API,支持DataStream API,Process Function,SQL。Flink最大特点在于其实时计算的正确性保证:Exactly once,原生支持事件时间,支持延时数据处理。由于Flink本身基于原生数据流计算,可以达到毫秒级低延时。

在爱奇艺实测下来,相比Spark Streaming,Apache Flink在相近的吞吐量上,有更低的延时,更好的实时计算表述能力,原生实时事件时间、延时数据处理等。

二、在爱奇艺使用Flink的一些案例

下面通过三个Use Case来介绍一下,爱奇艺具体是怎么使用Flink的,包括海量数据实时ETL,实时风控,分布式调用链分析。

1. 海量数据实时ETL

在爱奇艺这边所有用户在端上的任何行为都会发一条日志到nginx服务器上,总量超过千万QPS。对于具体某个业务来说,他们后续做实时分析,只希望访问到业务自身的数据,于是这中间就涉及一个数据拆分的工作。

在引入Flink之前,最早的数据拆分逻辑是这样子的,在Ngnix机器上通过“tail -f /xxx/ngnix.log | grep "xxx"”的方式,配置了无数条这样的规则,将这些不同的数据按照不同的规则,打到不同的业务kafka中。但这样的规则随着业务线的规模的扩大,这个tail进程越来越多,逐渐遇到了服务器性能瓶颈。

于是,我们就有了这样一个设想,希望通过实时流计算将数据拆分到各个业务kafka。具体来说,就是Nginx上的全量数据,全量采集到一级Kafka,通过实时ETL程序,按需将数据采集到各个业务Kafka中。当时,爱奇艺主的实时流计算基本均是基于Spark Streaming的,但考虑到Spark Streaming延迟相对来说比较高,爱奇艺从这个case展开开始推进Apache Flink的应用。

海量数据实时ETL的具体实现,主要有以下几个步骤:

  1. 解码:各个端的投递日志格式不统一,需要首先将各个端的日志按照各种解码方式解析成规范化的格式,这边选用的是JSON
  2. 风控:实时拆分这边的数据都会过一下风控的规则,过滤掉很大一部分刷量日志。由于量级太高,如果将每条日志都过一下风控规则,延时会非常大。这边做了几个优化,首先,将用户数据通过DeviceID拆分,不同的DeviceID拆分到不同的task manager上,每个task manager用本地内存做一级缓存,将redis和flink部署在一起,用本地redis做二级缓存。最终的效果是,每秒redis访问降到了平均4k,实时拆分的P99延时小于500ms。
  3. 拆分:按照各个业务进行拆分
  4. 采样、再过滤:根据每个业务的拆分过程中根据用户的需求不同,有采样、再过滤等过程

2. 实时风控

防机器撞库盗号攻击是安全风控的一个常见需求,主要需求集中于事中和事后。在事中,进行超高频异常检测分析,过滤用户异常行为;在事后,生成IP和设备ID的黑名单,供各业务实时分析时进行防刷使用。

以下是两个使用Flink特性的案例:

  1. CEP:因为很多黑产用户是有固定的一些套路,比如刚注册的用户可能在短时间内会进行一两项操作,我们通过CEP模式匹配,过滤掉那些有固定套路的黑产行为
  2. 多窗口聚合:风控这边会有一些需求,它需要在不同的一些时间窗口,有些时间窗口要求比较苛刻,可能是需要在一秒内或亚秒内去看一下某个用户有多少次访问,然后对他进行计数,计数的结果超过某些阈值就判断他是异常用户。通过Flink低延时且支持多窗口的特点,进行超高频的异常检测,比如对同一个用户在1秒内的请求进行计数,超过某个阈值的话就会被识别成黑产。

3. 分布式追踪系统

分布式调用链追踪系统,即全链路监控,每个公司基本都会有。在一个微服务架构当中,服务间的调用关系错综复杂,往往很难排查问题,识别性能性能瓶颈,这时候就需要分布式调用链追踪系统了。

上图是一个调用链的追踪拓扑图,每个点是一个具体的一个应用,就是具体经过哪个应用,每条边是说明这个应用到下一个应用当中耗时了多久。

除了宏观分析外,业务还想去看具体某一条日志的分析,具体某一次调用它是哪里慢了,哪里快了?所以,调用链还有另外一个需求,就是对于具体某次调用,想看一下它的具体耗时。

系统简单架构如上图,上半部分偏重于埋点,下半部分偏于分析。埋点简单来讲,就是通过客户端SDK埋点以及Agent采集,将系统调用日志全部打到Kafka中,我们通过Flink对他们进行各类分析。对于统计类的分析,就是通过Flink计算存储到HBase当中,提供一些监控报警、调用链拓普查询等这种分析。针对这类需求,我们运用了Flink的多窗口聚合的特性,通过一分钟或者多分钟的窗口,从茫茫日志中寻找哪条是实际的调用链,构建APP各个应用的拓扑调用关系,第二级是基于第一级分析的一个结果,分析出那个拓普图按各个窗口、各个不同的边去算每条边的平均耗时的统计。除此之外,我们还将通过Flink将原始数据打到ES里面供用户直接去查询。

三、Flink平台化

1. 概览

接下来将主要介绍爱奇艺的大数据平台的构建。上图不限于Flink,是大数据平台的整体架构图。在爱奇艺,存储层基本是基于Hadoop生态的,比如像HDFS、HBase、Kudu等;计算层,使用YARN,支持MapReduce、Spark、Flink、Hive、Impala等这些引擎;数据开发层,主要是一些自研产品,批处理开发在爱奇艺有工作流开发,数据集成等。实时计算开发,有流计算开发、Streaming SQL、实时分析等平台工具可以使用。

接下来,我们将简单介绍爱奇艺实时计算与分析平台。

2. 实时计算平台

2.1 流任务平台

流任务平台是爱奇艺实时计算的底层平台,支持流任务的提交运行与管理。流任务平台支持YARN, Mesos, Flink独立集群等多种资源调度框架;支持Storm, Spark Streaming, Flink, Streaming SQL等计算任务的托管与运行。在功能上,我们支持用户直接打包程序上传部署流任务,也支持用户通过Streaming SQL工具编写SQL进行流计算开发。为了更好地对计算任务进行管理,流计算平台提供JAR包、函数管理,任务指标监控,以及资源审计功能。

2.2 Streaming SQL

无论对于Spark Streaming还是Flink来说,他们均有一个较好的SQL优化引擎,但均缺乏DDL、DML创建的语义。于是对于业务来说,均需要业务先编程定义Source以及Sink,才可以使用SQL进行后续开发。

因此,爱奇艺自研的Streaming SQL定义了一套DDL和DML语法。其中,我们定义了4种表:
流表:定义了输入源是什么?具体的解码方式是什么?系统支持Json的解码方式,也支持用户自定义解码函数。
维度表:主要是静态表,支持MySQL,主要是用于流表Join的。
临时表:和Hive的临时表类似,用户定义中间过程。
结果表:定义了具体输出的类型,输出的源是什么?怎么访问?这边的输出源支持,就是常见的比如Kafka、MySQL、Kudu、ES、Druid、HBase等这样一些分析型数据库。

为了更好地支持业务需求,StreamingSQL默认也支持IP库相关的预定义函数,也支持用户自定义函数。

上图是一个StreamingSQL的应用Case,将P99,P50耗时打印到Console中。

为了更好地支持业务使用Streaming SQL,StreamingSQL提供Web IDE,提供代码高亮、关键词提示、语法检查、代码调试等功能。

3. 实时分析平台

实时分析平台,是爱奇艺基于Druid构建的分钟级延时的实时分析平台,支持通过Web向导配置,完成超大规模实时数据多维度的分析,并生成分钟级延时的可视化报表。支持的功能有,接入实时数据进行OLAP分析;制作实时报警;生产实时数据接口,配置监控报警等。

产品优势:

  • 全向导配置:从实时数据到报表生成仅需向导配置即可
  • 计算存储透明:无需管理大数据处理任务与数据存储
  • 分钟级低延时: 从数据产生到报表展示只有1分钟延时
  • 秒级查询:亚秒级返回分析报表
  • 支持灵活变更需求:业务可灵活更改维度,重新上线即可生效

3.1 用户向导配置

实时分析平台,将整个分析流程抽象成数据接入,数据处理,模型配置和报表配置4个过程。其中,模型配置完全按照OLAP模型,要求实时数据符合星型模型,存在时间戳、指标、维度等字段。

3.2 数据处理配置

在数据处理层,实时分析平台提供向导配置页面,支持用户通过纯页面的方式就可以配置数据处理过程,这主要应对一些简单场景,针对部分连SQL都不熟悉的小白用户提供页面配置方案;初次之外,类似StreamingSQL,实时分析也提供用户自定义SQL方式定义数据处理过程。

四、Flink改进

在Flink平台化的时候,我们遇到了几个Flink的问题,分别对其进行了些改进。

1. 改进 - 优雅恢复checkpoint

第一个改进是关于checkpoint的优雅恢复。这个问题的出发点是,业务希望使用Spark Streaming可以通过代码控制从哪个checkpoint恢复,但对于Flink来讲,业务没法通过代码控制checkpoint恢复点,需要手动指定检查点去恢复checkpoint。于是,我们希望Flink可以像Spark Streaming一样,直接通过代码方式恢复checkpoint。

针对这个问题,我们修改源码,在Flink任务启动时,从实际的路径当中找到他最新的一个checkpoint,直接从那个checkpoint当中恢复,当然这个也是可以让用户选的,他如果还想用原生方式恢复也可以,但提供一个选项,它可以支持从最近的checkpoint恢复。

2. 改进 - Kafka Broker HA

第二个改进是关于Kafka Broker HA的一个问题,比如像Kafka Broker故障的时候,Kafka还可以正常工作,但Flink程序往往会挂掉。针对这个问题,我们处理了Flink在Kafka Broker退出之后的sockerTimeOutException,支持用户重试次数配置来解决这个问题。

五、Flink未来工作

最后,介绍一下爱奇艺在Apache Flink的未来工作。目前StreamingSQL还只支持Spark Streaming和Structured Streaming引擎,后续很快会支持Flink引擎,大幅降低业务的Flink开发成本。随着Flink任务规模不断变大,我们将重点提升Flink在爱奇艺的成熟度,完善监控报警,增加资源审计流程(目前还仅对Spark Streaming进行资源审计)。另外,我们要研究下Flink 1.6的一些新特性,尝试下Kafka 2.0,调研Exactly once方案;另外,我们将对Flink新版本进行一些尝试,推进批流统一。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Flink实战(八) - Streaming Connectors 编程(下)
Flink实战(八) - Streaming Connectors 编程(下)
0 0
Flink实战(八) - Streaming Connectors 编程(上)
Flink实战(八) - Streaming Connectors 编程(上)
0 0
Flink CDC 系列 - 构建 MySQL 和 Postgres 上的 Streaming ETL
本篇教程将展示如何基于 Flink CDC 快速构建 MySQL 和 Postgres 的流式 ETL。
0 0
Flink x Zeppelin ,Hive Streaming 实战解析
Flink 1.11 正式发布已经三周了,其中最吸引我的特性就是 Hive Streaming。正巧 Zeppelin-0.9-preview2 也在前不久发布了,所以就写了一篇 Zeppelin 上的 Flink Hive Streaming 的实战解析。
0 0
Flink 1.11 新特性之 SQL Hive Streaming 简单示例
Flink 1.11 的 Hive Streaming 功能大大提高了 Hive 数仓的实时性,对 ETL 作业非常有利,同时还能够满足流式持续查询的需求,具有一定的灵活性。
0 0
从 Spark Streaming 到 Apache Flink:bilibili 实时平台的架构与实践
本文由 bilibili 大数据实时平台负责人郑志升分享,基于对 bilibili 实时计算的痛点分析,详细介绍了 bilibili Saber 实时计算平台架构与实践。本次分享主要围绕以下四个方面:实时计算的痛点、Saber 的平台演进、结合 AI 的案例实践、未来的发展与思考。
1620 0
用Flink取代Spark Streaming!知乎实时数仓架构演进
- 实时数仓 1.0 版本,主题:ETL 逻辑实时化,技术方案:Spark Streaming。 - 实时数仓 2.0 版本,主题:数据分层,指标计算实时化,技术方案:Flink Streaming。 - 实时数仓未来展望:Streaming SQL 平台化,元信息管理系统化,结果验收自动化。
1613 0
Flink实战(八) - Streaming Connectors 编程
1 概览 1.1 预定义的源和接收器 Flink内置了一些基本数据源和接收器,并且始终可用。该预定义的数据源包括文件,目录和插socket,并从集合和迭代器摄取数据。该预定义的数据接收器支持写入文件和标准输入输出及socket。
1093 0
Structured Streaming VS Flink
Flink是标准的实时处理引擎,而且Spark的两个模块Spark Streaming和Structured Streaming都是基于微批处理的,不过现在Spark Streaming已经非常稳定基本都没有更新了,然后重点移到spark sql和structured Streaming了。
3198 0
深入理解Flink Streaming SQL
序言        时效性提升数据的价值,所以Flink这样的流式(Streaming)计算系统应用得越来越广泛。        广大的普通用户决定一个产品的界面和接口。       ETL开发者需要简单而有效的开发工具,从而把更多时间花在理业务和对口径上。  &n
18906 0
+关注
apache_flink
Apache Flink China是经过Apache Flink官方授权的中文社区。是旨在向国内宣传和普及Flink相关技术,输出技术博文、译作、资讯等内容,推动国内大数据技术发展的开源社区。
文章
问答
文章排行榜
最热
最新
相关电子书
更多
Flink Streaming SQL 2018
立即下载
任庆盛|Flink CDC + Kafka 加速业务实时化
立即下载
李劲松|Flink Table Store 典型应用场景
立即下载