随着大数据的快速生长，行业大数据服务越来越重要。同时，对大数据实时盘算的要求也越来越高。今天会和大家分享下爱奇艺基于Apache Flink的实时盘算平台建设实践。今天的先容会围绕下面三点展开：Flink的现状与革新平台化的探索和实践：实时盘算平台Flink业务案例01Flink的现状与革新1. Flink现状首先和大家分享下爱奇艺大数据服务的生长史。

我们从2012年到2019年，大数据服务经由了一系列连续的革新和生长：2012年搭建了第一个Hadoop集群，其时只有或许20几个节点，使用的盘算框架是MapReduce和Hive等到2013，2014年，开始使用Hadoop 2.0，上线了Storm和Spark，由于Storm的使用性和稳定性不够好，被放弃使用，转而使用Spark2015年公布了第一个实时盘算平台Europa，上线了Kafka2017年使用了Flink，同时我们基于Spark和Flink打造了流式盘算引擎StreamingSQL2018年推出了自研的实时盘算平台Real-time Analytics Platform (RAP)2019年基于Flink到达了内部的流数据生态平台；然后先容一下Flink在爱奇艺的使用情况：这是Flink在爱奇艺的一些使用情况，现在的节点规模约莫15000多台，总的作业规模有800多个，天天的数据流的生产量或许在万亿级别，约2500TB左右。注：本数据仅代表嘉宾分享时的数据。下面是现在爱奇艺基于Spark，Flink打造的实时盘算平台框架：底层存储使用的HDFS，HBase，Kafka和OSS。

实时盘算框架通过Spark和Flink部署，在这两个服务之上，构建了一个独立的流式系统引擎StreamingSQL。在引擎之上，打造了多种类型的平台，用来实现治理盘算的任务，流数据的生产分发和实时数据分析等差别需求。实时盘算在爱奇艺业务上有些典型的应用场景：实时分析、报警，信息流(如广告类)推荐，内部数据在线训练，实时风控（内容追踪等）。

2. Flink革新Flink革新-监控和报警：以前只是做了简朴的状态监控，在泛起问题之后，不知道内部状态是怎么样的。近期做了一些革新，并和内部的监控平台Hubble举行集成，主要有三个级此外监控指标：Job级别监控指标：Job状态、Checkpoint状态和耗时。

如果没有进入到running状态，会对其举行重启操作，防止其查询卡在不康健状态下Operator级别监控指标：时延、反压、Source/Sink流量，对每个Operator举行指标聚合TaskManager级别监控指标：CPU使用率、内存使用率、JVM GC等Flink革新-状态治理：问题一：长时间运行Flink job，会因为种种原因导致它重启。Checkpoint只在Flink作业内部有效，一旦主动重启或异常重启时，上一个job的状态会全部丢失。解决方法：作业重启时，找到上一次运行乐成的Checkpoint，从中恢复。

缺陷：对于状态很大的作业，会使用RockDBStateBackend做增量Checkpoint；上一次的Checkpoint被依赖而无法删除，会导致状态聚集（生产情况中的一个作业的Checkpoint总共多达8TB）。对于这个缺陷也就是：问题二：Checkpoint无限依赖解决方法：使用Savepoint打断增量Checkpoint的依赖链，并与流盘算平台集成。主要有两种产物，一种是通过业务通过平台主动重启，重启之前对此job做一次Savepoint操作，启动时从Savepoint的路径去启动。

第二种是发生异常重启时，来不及做Savepoint。那么会在Checkpoint启动起来，一旦job进入到running状态以后，立刻做一次Savepoint，解决依赖问题。StreamingSQL：StreamingSQL是基于Spark和Flink构建的一个统一的流数据ETL工具，具有以下一些特征：SQL化：业务上去写流盘算任务时，不需要去写Scala法式，只需要编写一些SQL代码即可完成流盘算ETL任务的开发。DDL：流表、暂时表、维度表、效果表。

UDF：系统预界说常用函数、用户自界说函数。提供SQL编辑器。下面是StreamingSQL的一个实例：02实时盘算平台1. 实时盘算治理平台上图是Spark、Flink任务开发和治理的web IDE的例子，用户可以在页面上设置一些参数和字段，举行任务的开发，上传，作业的重启，运行状态的检察等通例操作。此外，还提供其他的一些治理：文件治理：任务Jar包、依赖库。

函数治理：提供富厚的系统函数、支持用户注册UDF。版本治理：支持任务、文件的版本对比以及回滚。通例治理：监控大盘、报警订阅、资源审计、异常诊断。

2. 实时数据处置惩罚平台为了确保数据发挥该有的价值，让数据的流转越发通畅，让业务处置惩罚数据、使用数据和分析数据越发便捷，我们革新服务，推出了数据处置惩罚平台和数据分析平台。以下是实时数据处置惩罚平台演进历程：2015 – 2016场景：离线报表为主，少量实时报表需求，数据生产规模50万QPS；Venus 1.0数据收罗平台：基于Apache Flume；在Venus agents上通过tail+grep/awk/sed等剧本过滤；缺陷：不利便变换过滤规则，需重启所有agents；差别用户需求存在大量重复处置惩罚逻辑。2017 – 2018场景：实时分析、信息流推荐等实时需求增加，500万QPSVenus 2.0数据收罗分析平台：实时过滤从Venus agent迁移到Flink，接纳两级Kafka；无需重启即可动态增减处置惩罚规则缺陷：Kafka数据冗余，不利便分享Kafka数据2019场景：大量实时业务需求，1500万QPSVenus 3.0流数据生产分发平台：通过web设置实时处置惩罚规则，可自由组合常见算子；参考离线数仓，根据数据使用场景构建流式数仓优点：淘汰流数据重复生产，促进流数据共享下面是一个例子，流数据处置惩罚平台的一个页面。

现在平台支持Projection、Filter、Split、Union、Window、UDF等常见算子。3. 实时分析平台现在我们实时数据OLAP分析平台主要有两大类：一类是实时报表，主要有A/B测试、精致化运营等；另一类是实时报警，主要有VV/UV、播放故障等。

下图是现在的一个架构图：现在支持流处置惩罚平台，Kafka，Hubble监控系统，MySQL binlog这些数据源。用户可以通过UI设置处置惩罚规则，分析规则，需要展示的报表的气势派头，以及一些报警的规则。

这些处置惩罚规则和分析规则等，后台会自动把它们的function对应的服务转成一个job，然后自动把效果上传到MySQL里。此外，用户可以在多平台上面举行分析检察、观察报警率等，也可以利便的通过api对接到自己的第三方的定制化平台里。

现在，我们实时分析平台拥有以下一些优势：开发门槛低：无需写法式或SQL开发效率高：由以前的几天到现在的半小时就能完成报表实时：从小时级别优化到现在只需要1分钟查询更快：支持大规模数据亚秒级查询下面展示的是一些页面的模块。设置处置惩罚规则：设置OLAP模型：03Flink业务案例1. 信息流推荐我们所有的数据都是通过实时收集到二级Kafka内里，通过Stream处置惩罚平台分级成点击、检察、订阅、搜索等一系列行为差别的Kafka里。

然后再经由处置惩罚平台处置惩罚以后，生产相应的用户特征，用户画像等实时流，最后被推荐引擎去使用。我们从Spark Streaming迁移到Flink，消除了批处置惩罚延迟。现在单个任务延迟从1分钟缩短到1-2秒，端到端性能提升86倍，而且显著提升了推荐效果。2. 使用Flink生产深度学习训练数据上图是一个广告推荐相关的例子，这是以前的一个架构，通过Hive/Spark离线ETL生成广告深度学习算法所需要的训练数据，算法模型更新周期为6小时。

从2018年头开始，对框架做了实时的一个革新。实时过来的用户行为数据会实时投递到Kafka里，通过Flink处置惩罚完以后，生成一些新的Delta数据；已往7天分析的广告特征、用户特征投到Kafka，通过Flink处置惩罚完以后，存到HBase里。

Kafka实时流（最近24小时）和HBase维度表（最近7天）这两部门数据Join之后生成一个Session流，再给算法预测使用。通过框架的革新，现在算法模型更新从6小时缩短到1小时，而且支持实时CTR预估，更好指导广告决议，提升广告收益。3. 端到端Exactly-Once处置惩罚由于现在存在一个问题：Kafka节点故障重启某人工运维时，业务方重复消费数据。

因此最近正在研究端到端Exactly-Once处置惩罚的一个方案：Kafka Exactly-Once Semantics + Flink two-phase commit. 可是，这个方案会造成Flink任务盘算性能的20%损耗，从业务偏向角度来讲，这个是在可接受规模内的。4. 挑战与计划以下是未来的一些计划：流批一体化SQL化：进一步完善和推广StreamingSQL，降低开发门槛基于Flink的机械学习的实验和使用提高Flink作业的资源使用率，支持动态资源调整Flink on Kubernetes作者：梁建煌，爱奇艺大数据服务卖力人，2012-硕士结业于上海交通大学后，先后在 SAP、爱奇艺事情，从 2013 年起开始卖力爱奇艺大数据服务体系的建设事情，包罗大数据存储、盘算、OLAP 以及开发平台等。

本文来源：开云app官网入口-www.kzqjwl.cn