关于flink:Disney-流媒体广告-Flink-的应用实践

摘要：本文整顿自 Disney 广告智能执行总监郝又超、Disney 广告智能实时计算负责人李丁哲，在 FFA 的分享。本篇内容次要分为四个局部：

1. Disney 流媒体广告与实时利用
2. 业务场景实现
3. 实时平台构建
4. 将来瞻望

点击查看直播回放 & 演讲 PPT

一、Disney 流媒体广告与实时利用

说到 Disney 流媒体业务包含 Hulu，大家可能并不相熟，因为咱们在国内的业务并没有落地。Hulu 是在 15 年前由 Disney、福克斯和 NBC 独特发动成立的，当初曾经在美国外乡是一家头部的流媒体平台了。

2019 年，Disney 收买了福克斯从而失去的 Hulu 的经营控制权，因而也失去了 Hulu 上的广告平台这样一个优质资源。因为作为传统的流媒体公司，Disney 原来并没有本人的技术广告平台，而在 2019 年之后，Disney 也陆续的发力线上流媒体，推出了 Disney+，ESPN+，Star+ 等多个流媒体品牌。上面来具体看一下 Disney 和 Hulu 的流媒体以及广告业务的数据。

2.35 亿，是截止到往年十月份，Disney 流媒体包含 Disney+，Hulu，ESPN+，Star+ 在寰球的订阅用户。这是一个什么概念呢？Netflix 曾经在寰球经营了超过十年，咱们在往年 7 月份就曾经超过了它寰球的订阅用户数，且咱们的订阅用户数是以家庭为单位的，所以理论触达的个人用户可能有 7 -10 亿。

Hulu 是以后 Disney 流媒体广告业务的次要起源，每天投放数亿 15 秒、30 秒长的视频广告，而每抉择一个广告都会产生几十甚至上百个事件，对数据平台有着极高的挑战，随着 Disney+ 上 12 月份行将上线广告，这种挑战预期将数倍增长。

接下来给大家略微介绍一下 Disney 的流媒体广告数据平台。大略分为两层，一层是底层的数据和算法，另一层是利用和服务。

数据和算法次要包含三局部：

• 用户数据。次要通过以用户和用户身份为次要维度来汇聚用户的行为数据，从而对数据交换以及广告所须要的定向进行人群圈选的外围能力。

• 经营数据。次要包含两局部：

  • 一部分是通过以广告的曝光为外围，汇聚所有的广告曝光、投放、转化以及用户交互的数据，造成 Event Store。
  • 另一方面是通过对 Event Store 在广告的订单维度上进行进一步聚合，提供各种的 KPI。这些聚合通常是实时的，这就是 Flink 在咱们广告平台上次要的利用场景。
• 机器学习平台。次要通过咱们丰盛的数据，从用户、广告商以及 Disney 的外围的业务指标进行优化。

能够说数据和算法提供的利用和服务，驱动着咱们整个广告生命周期的各个环节。比方:

• 售卖和布局阶段，咱们提供库存预测，用户洞察；
• 投放和交易阶段，咱们提供实时的定向、实时的决策、实时的监控和故障定位；
• 报告分析阶段，咱们有商务智能、广告的归因和面向广告商的各种报表。

从具体实时利用的角度，咱们目前应用 Flink 次要尝试了三个场景，别离是广告决策漏斗、广告曝光监控、广告零碎大屏，这三个环节将在前面做具体论述。

二、业务场景实现

大略在两年前，咱们对流计算框架做了一个对立的选型，之前有用到多种的流计算框架，为了实现下面提到的业务需要，最终抉择了 Flink。起因有以下几点：

• 应用 Flink，能够比拟灵便的应用它的 vp 的解决或者流式的解决，从而达到咱们对于时效性的多种需要。
• Flink 它有流批对立的 API，咱们能够用 Datastream 对无限流做 Batch 解决，或者对有限流做流式的解决。而且它能够让咱们应用同一套代码，大大减少了咱们保护代码的压力。
• Flink 反对 Exactly Once 语义，联合咱们的上下游，能够达到一个从端到端的 Exactly Once 的保障。
• Flink 有很多十分好用的编程的接口，比方 Window Functions。

从整个大数据平台上来看，Flink 的定位次要如下图所示。首先从零碎及用户侧去把数据收集到多个音讯队列中，而后在下面这条 Flink 对立做一个流式计算，计算出业务所需的一些指标，通过数据接口裸露给实时的业务平台、实时的运维平台，以及其余一些零碎如广告服务器。在批处理的这一条链路上，除了会用 Spark 生成一些离线的业务报表、离线的对外数据输入，还会用 Flink Batch 做一些指标回填的操作。

上面分享下第一局部最初提到的三个场景。第一个场景是广告决策漏斗，次要面向的是保护人员和开发者。对于广告的决策零碎来讲，广告决策是一个绝对比较复杂的过程。当用户登录到流媒体平台的时候，咱们须要从一个宏大的广告池子里，通过粗排、精排等多个过滤条件，最终给用户抉择出一个最适宜他的广告。

因而在这么简单的业务场景中，就萌发出了运维同学、开发同学对谬误排查能力的需要。咱们把广告决策的整个流程，形象成了一个广告决策漏斗。咱们心愿通过前端给运维人员、开发人员展现一些具体的信息，比方在漏斗里是否有投放的机会、广告是否定向胜利、是否被过滤掉、最终有没有投放给用户，如果没有投放给用户，失败起因是什么等等。对于这个业务场景咱们次要有三个十分须要关注的点。

• 数据品质。作为一个须要供大家去做 debug 的平台，咱们心愿咱们的数据品质可能得以保障，要不然这个平台将毫无意义，甚至会误导运维人员、开发人员，使他们做出一些谬误的判断。
• 零碎时效。咱们不仅心愿广告零碎在呈现问题时，能够及时发现，心愿在运维人员更改配置后，或者开发人员修复一些代码 bug 后，能够及时在广告平台上看到变动，来判断是否胜利修复了问题。
• 开销代价。决策漏斗是一个监控平台，咱们不心愿它耗费太多的计算资源。那么在整体的架构中，首先须要咱们的广告服务器将一些决策信息进行一些动静的编码压缩，而后发送到音讯队列当中。Flink 从音讯队列中对立做拉取，在窗口框架中将它们 Join 起来，还原出决策漏斗。在这之前也做了一些解码的工作，最终将决策漏斗放在前端进行展现。

这一条实时链路在实现的时候，咱们应用了 Exactly Once 语义。上下游都是应用的 Kafka，利用 Kafka 的能力取得 Exactly Once 的保障。OLAP 这一套插入数据的零碎也是保障了 Exactly Once 从 Kafka 读取到数据库中，最终胜利的实现了从端到端的 Exactly Once。

上面这一条离线的批处理链路，只把它当作一个纠错的链路，当咱们实时链路有一些 bug，造成局部数据品质问题时候的一个数据重填以及纠错。在这个离线链路上，咱们也是尝试应用了流批一体，应用同一套代码去做这个数据的回填。

总结一下，方才提到的三点咱们最关怀的外围问题；

• 在数据品质方面，咱们从业务角度上看，实现了脏数据收集旁路。一旦发现上游传输的数据不对，运维人员就能够及时失去告诉，去进行问题排查。而后这一条链路从底层是用 Exactly Once 做的数据品质的保障，保障都是可以信赖的数据。
• 在开销代价方面，Exactly Once+ 流批一体也实现了一个 Kappa 的架构。传统 lambda 架构须要做一个常驻的回填纠错。在 Kappa 的架构下，这一部分的计算资源能够被节省下来。

• 在零碎时效方面，咱们也做了一些优化，比方优化了 Flink 自身工作的一些性能。像决策信息是由压缩、动静的编码来发送到咱们后端的，这里就波及了一些比较复杂的数据模型，因为它的原生正反序列化比拟迟缓，所以咱们进行了一个针对性的优化，进步了整体链路的吞吐率。

可能比拟相熟的同学晓得，如果应用 Exactly Once，音讯的 Transaction Commit 和 Checkpoint 的生成是非亲非故的。只有当 Checkpoint 生成的时候，才会把音讯 Transaction Commit 到 Kafka 上，所以时效性也跟 Checkpoint 的速度或者 Checkpoint 距离的大小严密相干，咱们也对此进行了一些针对性的优化。

不同于个别状况下的 Hadoop 生态系统，Hadoop 在 HDFS 做 Checkpoint。在咱们这个利用场景下，咱们应用的是 AWS 的 S3 存储。Flink on S3 的 Checkpoint，咱们是对于这个场景进行一些深度的优化。

除了时效性以外，咱们在稳定性方面也解决了一些问题。比方在比拟大的被压场景下，可能会有 Checkpoint 过于迟缓，甚至 Kafka Transaction 生效的问题；在 Flink 1.14 版本，Kafka 的 Producer 可能有 Transaction ID 重用的问题；在同时应用 Transaction，也就是 Exactly Once 和流批一体的时候，面临了这两者不是百分百兼容的问题；比方 Checkpoint 和 Transaction Commit 严密的关系，在 Batch 的状况下咱们没有 Transaction 的概念，须要对算子的外部状况和整体的 Flush 做一些非凡的解决。

在这套零碎上线后，咱们胜利的反对了 20 亿 / 秒的指标生成，2 分钟左右的端到端提早，数据取用方面毫秒级响应。

第二个场景是广告曝光监控，次要面向的是用户方和广告主。广告主在签订广告合同的时候，通常会有一些定向投放的限度，比方我是一个母婴用品的广告，那就心愿投放的人群是妈妈或者女性，还会有一些动静的规定，比方在投放次数上，不心愿在同一时间内投放给同一个用户超过多少次；或在同一个用户的会话窗口下，不心愿跟竞品广告呈现在一起等等需要。

因而咱们研发了广告曝光的监控平台，广告主能够在咱们的广告曝光监控平台上看到本人广告投放的一些信息。比方广告的投放区域、面向人群、或者当更改了一些定向规定后，广告服务器有没有反映出这些变动等等需要。

那么广告监控具体是如何实现的呢？首先从咱们的零碎和客户端收集到一些广告抉择的上下文信息、用户和广告的一些交互信息到音讯队列中。而后应用 Flink 进行流和流的 join，再加上维度表做维度的加强，从而生成了一系列的事实指标。这些事实指标能够包含广告的曝光、独立访客的数量、用户观看频率等等。

基于这些根底的事实指标和一些特定的广告业务规定，咱们计算出一些衍生指标，比方广告投递的情况。在离线咱们也生成了一些，可能实时比拟不容易生成的指标，比方特地多维度的 UV 指标等等。咱们把这一系列的指标，对立通过咱们的数据接口向外裸露。这个数据呢，一方面给前端应用，另一个方面也会被广告零碎应用。

咱们当初的广告零碎，更多的是由根底和简略的广告曝光计数器和算法，来管制广告投放的速率。如果咱们应用有更加丰盛维度的曝光信息，能够反对 AB 测试、更加细腻的广告曝光速率管制等场景。所以在整个数据链路中，咱们最关怀的就是数据的可用性。

对于数据可用性咱们次要做了两点。

• 尝试让 Flink 和咱们正在应用的一个元信息系统进行买通，而后咱们的其余利用，比方 Spark，Hive 等利用就能够间接应用 Flink 生成的数据了。
• 咱们提供了一个对立的指标接口。那么不同的上游、前端、后端就能够灵便取用咱们的指标了。

第三个场景是广告零碎大屏。前两个场景更多的是关注某一个广告投放的一个部分，而广告零碎大屏更多的是面向管理层，须要对广告零碎和广告投放有一个全局的洞察力。

咱们应用 Flink 对一些数据源进行解决，而后通过指标接口裸露进去，再基于不同的业务规定，每 5 分钟、每小时、每天的批式解决，最终投放给前端做广告实时大屏展现。

三、实时平台构建

咱们的 Flink 实时平台是基于云上开发的，应用 K8s 作为容器的管理系统，Flink Operator 治理 Flink 集群。咱们本人研发了 Job submitter 的角色去帮忙用户，让他们以本人相熟的姿态去提交 Flink 工作。

对于在计算平台呈现的一些经典问题，咱们也都一一解决了。比方当集群资源无限的状况下，有很多大工作，且每个工作都须要大量的资源，咱们同时提交每个工作都能拿到肯定的资源，但都没能拿到应该拿到资源的时候，会造成工作和工作之间的互锁，这个时候咱们应用了 Gang scheduler 就能够将其解决。

除此之外咱们还进行了流批作业混部，这样能够最优化资源的利用率。

为了利用云上弹性缩扩容的能力，咱们次要创立了三种类型的队列。

• 常驻工作队列，它次要面向 Flink Streaming 这样的工作，这样的工作通常它的资源应用更加趋于稳定。所以咱们为它次要抉择了 Reserved 节点，以一个更长的租期去租用这些设施，而后达到更低的应用费率。
• 批处理工作队列，它次要面向 Flink Batch，Spark Batch 这样的工作。咱们次要应用 On demand 节点，以保障咱们对 SLA 的要求。
• 长期工作队列，它次要面向一些低优先级的工作。咱们次要应用 Spot 计算节点，这个节点有比拟低 SLA 保障。比方在工作运行的过程中，Spot 节点可能会随时撤出，在每次取用 Spot 节点时，也不能齐全满足即取即用的需要，因而咱们用 SLA 换取了一个更低的费率。

总体来说，这个计算平台也是依据咱们不同队列的一个负载去进行一个弹性的一个扩 / 缩容。

对于用户侧，咱们也有相应的平台，比方工作治理、工作详情，能够让用户看到提交到实时平台上的工作情况。

除此之外还提供了日志的管理系统，包含日志收集、日志查问，满足用户 debug 的需要。

当然咱们也有给运维同学的一些平台，比方集群总体指标查看平台以及对每一个工作运行状况、工作指标查问的窗口。

四、将来瞻望

咱们十分关注 Flink 社区的一些技术倒退。Flink 将来在咱们产品上的一些实用场景，能够演绎为以下几个方面。

• 全流批一体。目前 Flink 在咱们产品上的应用只在部分环节，次要是一些实时 KPI 的生成，这造成了在存储和计算上的资源节约。因为咱们不得不借助 Lambda 的构造来保障流批之间数据的一致性。如果能借助流批一体，心愿能够升高咱们在存储和计算上的双重老本。
• OLAP。目前咱们的实时 KPI 返回还是有独自的 OLAP 引擎，将来心愿能够通过对立引擎来进步咱们开发的效率。
• 实时归因。对于广告来说，归因是十分重要的一个环节。目前咱们所有的归因都还是离线来实现的，但从业务需要上，咱们心愿可能更快的晓得用户转化的起因，所以利用 Flink 在实时归因上对咱们也十分重要。
• 流式机器学习。在数据平台和计算引擎全副迁到实时计算上后，咱们也很想尝试流式机器学习。包含在线特征提取、在线模型训练等等。

点击查看直播回放 & 演讲 PPT

更多内容

流动举荐

阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
99 元试用 实时计算 Flink 版（包年包月、10CU）即有机会取得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！
理解流动详情：https://www.aliyun.com/produc…