作者：陈越晨
整理：刘河
本文将为大家介绍Apache Flink在爱奇艺的生产与实践过程。你可以借此了解到爱奇艺引入Apache Flink的背景与挑战，以及平台构建化流程。主要内容如下：
- 爱奇艺在实时计算方面的的演化和遇到的一些挑战
- 爱奇艺使用Flink的User Case
- 爱奇艺Flink平台化构建流程
- 爱奇艺在Flink上的改进
- 未来工作
cdn.xitu.io/2019/5/22/16ade66402c6f94d?w=1034&h=386&f=png&s=136360">
爱奇艺在2010年正式上线，于2018年3月份在纳斯达克上市。我们拥有规模庞大且高度活跃的用户基础，月活跃用户数5.65亿人，在在线视频领域名列第一。在移动端，爱奇艺月度总有效时长59.08亿小时，稳居中国APP榜第三名。
实时计算是基于一些实时到达、速率不可控、到达次序独立不保证顺序、一经处理无法重放除非特意保存的无序时间序列的数据的在线计算。
因此，在实时计算中，会遇到数据乱序、数据延时、事件时间与处理时间不一致等问题。爱奇艺的峰值事件数达到1100万/秒，在正确性、容错、性能、延迟、吞吐量、扩展性等方面均遇到不小的挑战。
爱奇艺从2013年开始小规模使用storm，部署了3个独立集群。在2015年，开始引入Spark Streaming，部署在YARN上。在2016年，将Spark Streaming平台化，构建流计算平台，降低用户使用成本，之后流计算开始在爱奇艺大规模使用。在2017年，因为Spark Streaming的先天缺陷，引入Flink，部署在独立集群和YARN上。在2018年，构建Streaming SQL与实时分析平台，进一步降低用户使用门槛。
爱奇艺主要使用的是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在相近的吞吐量上，有更低的延时，更好的实时计算表述能力，原生实时事件时间、延时数据处理等。
下面通过三个Use Case来介绍一下，爱奇艺具体是怎么使用Flink的，包括海量数据实时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的具体实现，主要有以下几个步骤：
防机器撞库盗号***是安全风控的一个常见需求，主要需求集中于事中和事后。在事中，进行超高频异常检测分析，过滤用户异常行为；在事后，生成IP和设备ID的黑名单，供各业务实时分析时进行防刷使用。
以下是两个使用Flink特性的案例：
分布式调用链追踪系统，即全链路监控，每个公司基本都会有。在一个微服务架构当中，服务间的调用关系错综复杂，往往很难排查问题，识别性能性能瓶颈，这时候就需要分布式调用链追踪系统了。
上图是一个调用链的追踪拓扑图，每个点是一个具体的一个应用，就是具体经过哪个应用，每条边是说明这个应用到下一个应用当中耗时了多久。
除了宏观分析外，业务还想去看具体某一条日志的分析，具体某一次调用它是哪里慢了，哪里快了？所以，调用链还有另外一个需求，就是对于具体某次调用，想看一下它的具体耗时。
系统简单架构如上图，上半部分偏重于埋点，下半部分偏于分析。埋点简单来讲，就是通过客户端SDK埋点以及Agent采集，将系统调用日志全部打到Kafka中，我们通过Flink对他们进行各类分析。对于统计类的分析，就是通过Flink计算存储到HBase当中，提供一些监控报警、调用链拓普查询等这种分析。针对这类需求，我们运用了Flink的多窗口聚合的特性，通过一分钟或者多分钟的窗口，从茫茫日志中寻找哪条是实际的调用链，构建APP各个应用的拓扑调用关系，第二级是基于第一级分析的一个结果，分析出那个拓普图按各个窗口、各个不同的边去算每条边的平均耗时的统计。除此之外，我们还将通过Flink将原始数据打到ES里面供用户直接去查询。
接下来将主要介绍爱奇艺的大数据平台的构建。上图不限于Flink，是大数据平台的整体架构图。在爱奇艺，存储层基本是基于Hadoop生态的，比如像HDFS、HBase、Kudu等；计算层，使用YARN，支持MapReduce、Spark、Flink、Hive、Impala等这些引擎；数据开发层，主要是一些自研产品，批处理开发在爱奇艺有工作流开发，数据集成等。实时计算开发，有流计算开发、Streaming SQL、实时分析等平台工具可以使用。
接下来，我们将简单介绍爱奇艺实时计算与分析平台。
流任务平台是爱奇艺实时计算的底层平台，支持流任务的提交运行与管理。流任务平台支持YARN, Mesos, Flink独立集群等多种资源调度框架；支持Storm, Spark Streaming, Flink, Streaming SQL等计算任务的托管与运行。在功能上，我们支持用户直接打包程序上传部署流任务，也支持用户通过Streaming SQL工具编写SQL进行流计算开发。为了更好地对计算任务进行管理，流计算平台提供JAR包、函数管理，任务指标监控，以及资源审计功能。
无论对于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，提供代码高亮、关键词提示、语法检查、代码调试等功能。
实时分析平台，是爱奇艺基于Druid构建的分钟级延时的实时分析平台，支持通过Web向导配置，完成超大规模实时数据多维度的分析，并生成分钟级延时的可视化报表。支持的功能有，接入实时数据进行OLAP分析；制作实时报警；生产实时数据接口，配置监控报警等。
产品优势：
实时分析平台，将整个分析流程抽象成数据接入，数据处理，模型配置和报表配置4个过程。其中，模型配置完全按照OLAP模型，要求实时数据符合星型模型，存在时间戳、指标、维度等字段。
在数据处理层，实时分析平台提供向导配置页面，支持用户通过纯页面的方式就可以配置数据处理过程，这主要应对一些简单场景，针对部分连SQL都不熟悉的小白用户提供页面配置方案；初次之外，类似StreamingSQL，实时分析也提供用户自定义SQL方式定义数据处理过程。
在Flink平台化的时候，我们遇到了几个Flink的问题，分别对其进行了些改进。
第一个改进是关于checkpoint的优雅恢复。这个问题的出发点是，业务希望使用Spark Streaming可以通过代码控制从哪个checkpoint恢复，但对于Flink来讲，业务没法通过代码控制checkpoint恢复点，需要手动指定检查点去恢复checkpoint。于是，我们希望Flink可以像Spark Streaming一样，直接通过代码方式恢复checkpoint。
针对这个问题，我们修改源码，在Flink任务启动时，从实际的路径当中找到他最新的一个checkpoint，直接从那个checkpoint当中恢复，当然这个也是可以让用户选的，他如果还想用原生方式恢复也可以，但提供一个选项，它可以支持从最近的checkpoint恢复。
第二个改进是关于Kafka Broker HA的一个问题，比如像Kafka Broker故障的时候，Kafka还可以正常工作，但Flink程序往往会挂掉。针对这个问题，我们处理了Flink在Kafka Broker退出之后的sockerTimeOutException，支持用户重试次数配置来解决这个问题。
最后，介绍一下爱奇艺在Apache Flink的未来工作。目前StreamingSQL还只支持Spark Streaming和Structured Streaming引擎，后续很快会支持Flink引擎，大幅降低业务的Flink开发成本。随着Flink任务规模不断变大，我们将重点提升Flink在爱奇艺的成熟度，完善监控报警，增加资源审计流程（目前还仅对Spark Streaming进行资源审计）。另外，我们要研究下Flink 1.6的一些新特性，尝试下Kafka 2.0，调研Exactly once方案；另外，我们将对Flink新版本进行一些尝试，推进批流统一。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
