2

本文将为大家介绍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新版本进行一些尝试,推进批流统一。



本文作者:apache_flink

阅读原文

本文为云栖社区原创内容,未经允许不得转载。


数据库知识分享者
27.8k 声望35.7k 粉丝

数据库知识分享