从Spark Streaming到Apache Flink: 实时数据流在爱奇艺的演进
本文将为大家介绍Apache Flink在爱奇艺的生产与实践过程。你可以借此了解到爱奇艺引入Apache Flink的背景与挑战，以及平台构建化流程。主要内容如下：
爱奇艺在实时计算方面的的演化和遇到的一些挑战
爱奇艺使用Flink的User Case
爱奇艺Flink平台化构建流程
爱奇艺在Flink上的改进
未来工作
爱奇艺简介
爱奇艺在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的具体实现，主要有以下几个步骤：
①. 解码：各个端的投递日志格式不统一，需要首先将各个端的日志按照各种解码方式解析成规范化的格式，这边选用的是JSON
②. 风控：实时拆分这边的数据都会过一下风控的规则，过滤掉很大一部分刷量日志。由于量级太高，如果将每条日志都过一下风控规则，延时会非常大。这边做了几个优化，首先，将用户数据通过DeviceID拆分，不同的DeviceID拆分到不同的task manager上，每个task manager用本地内存做一级缓存，将redis和flink部署在一起，用本地redis做二级缓存。最终的效果是，每秒redis访问降到了平均4k，实时拆分的P99延时小于500ms。
③. 拆分：按照各个业务进行拆分
④. 采样、再过滤：根据每个业务的拆分过程中根据用户的需求不同，有采样、再过滤等过程
2. 实时风控
防机器撞库盗号攻击是安全风控的一个常见需求，主要需求集中于事中和事后。在事中，进行超高频异常检测分析，过滤用户异常行为；在事后，生成IP和设备ID的黑名单，供各业务实时分析时进行防刷使用。
以下是两个使用Flink特性的案例：
CEP：因为很多黑产用户是有固定的一些套路，比如刚注册的用户可能在短时间内会进行一两项操作，我们通过CEP模式匹配，过滤掉那些有固定套路的黑产行为
多窗口聚合：风控这边会有一些需求，它需要在不同的一些时间窗口，有些时间窗口要求比较苛刻，可能是需要在一秒内或亚秒内去看一下某个用户有多少次访问，然后对他进行计数，计数的结果超过某些阈值就判断他是异常用户。通过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新版本进行一些尝试，推进批流统一。
参考阅读：
本文由刘河整理。转载本文请注明出处，欢迎更多小伙伴加入翻译及投稿文章的行列，详情请戳公众号菜单「联系我们」。
GIAC全球互联网架构大会深圳站将于2019年6月举行，届时有更多Flink、ClickHouse等“大数据前沿”相关演讲。参加2019年GIAC深圳站，可以了解业界动态，和业界专家近距离接触。
参加 GIAC，盘点2019年最新技术，目前购买8折优惠 ，多人购买有更多优惠。识别二维码了解大会更多详情。