从 Spark Streaming 到 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、爱奇艺在实时计算方面的演化和遇到的一些挑战

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在相近的吞吐量上，有更低的延时，更好的实时计算表述能力，原生实时事件时间、延时数据处理等。

2、在爱奇艺使用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里面供用户直接去查询。

3、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库相关的预约义函数，也支持用户自定义函数。

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

3. 实时分析平台

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

产品优点：

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

3.1 用户向导配置

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

3.2 数据处理配置

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

4、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，支持用户重试次数配置来解决这个问题。

5、Flink将来工做

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

原文连接 本文为云栖社区原创内容，未经容许不得转载。