Flink Forward Asia 2022 主论坛概览

2022 年 11 月 26-27 日，Flink Forward Asia（FFA）峰会成功举行。Flink Forward Asia 是由 Apache 软件基金会官方授权、由阿里云承办的技术峰会，是目前国内最大的 Apache 顶级项目会议之一，也是 Flink 开发者和使用者的年度盛会。由于疫情原因，本届峰会仍采用线上形式。此外，本次峰会上还举行了第四届天池实时计算 Flink 挑战赛的颁奖仪式，4346 支参赛队伍中共有 11 支队伍经过层层角逐脱颖而出，最终收获了奖项。

FFA 大会照例总结了 Apache Flink 过去一年的发展情况。2022 年，Apache Flink 社区继续保持快速发展：Github Star 数突破 2 万；代码贡献者总人数超过 1,600 人；单月下载量突破 1,400 万次。其中，Apache Flink 中文社区的发展尤为蓬勃：据 ossinsight.io 统计截至目前 Apache Flink 项目所有 PR 中有 45% 来自中国开发者；由 Apache 软件基金会授权、Apache Flink PMC 管理的官方微信公众号，2022年 共发布了 130+ 篇技术分享文章，累计订阅用户数突破 6 万；新开通的微信视频号发布了36 篇视频，目前已有近 4,000 订阅用户。

我们欣喜地看到，Apache Flink 已成为实时流计算全球范围事实标准。Flink 凭借强大的实时化大数据计算能力，与众多开源社区生态项目的强强联合，形成了实时大屏展示、实时数据集成、实时湖仓分析、实时个性化推荐、实时风控监控等一系列实时化大数据场景的解决方案，成为了推动各行各业数据分析实时化升级的核心推动力。

本文接下来将对本次 FFA 峰会主论坛几个 Keynotes 议题进行简单的归纳总结，感兴趣的小伙伴可以到​​官网​​观看大会全部议题的视频回放。

云与开源，共植数字世界的根

在 Keynotes 议题开始之前，阿里巴巴集团副总裁、阿里巴巴开源技术委员会负责人、阿里云智能计算平台负责人贾扬清老师作为开场嘉宾，分享了他对云与开源关系的理解。

在产业数字化、数字产业化的今天，云和开源已经共生、共长、共筑了一个数字世界的根。开源与商业化如何更好地结合，我们认为云是其中最重要的一环。 云为开源软件的部署和获取提供了更好的环境，在云提供的弹性环境中，用户可以一键获得开源软件与平台的能力。云和开源软件的共生，也使得用户能有更加广阔和灵活的选择，每个人都能够寻找到最适合的开源软件组合来解决自身业务问题。在这个发展的过程中，逐渐形成了云原生的概念。

在过去的十几年中，阿里巴巴一直是开源软件和社区的坚定拥护者和实践者，形成了 “三位一体” 的策略：开源社区的技术、阿里巴巴内部应用的技术以及在阿里云上通过商业化形式提供给客户的技术是统一的。开源提供了非常好的用户体验，在阿里巴巴这样的大规模场景中能够产生很多个性化或系统化的需求，二者的关注点形成互补。阿里巴巴将自己的最佳实践贡献回开源社区，使得社区的易用性与大规模企业所使用的稳定性、弹性能够很好地结合。

以 Apache Flink 为例，阿里巴巴在 2016 年开始采用 Flink 作为内部实时计算的一条技术路线，并基于 Flink 建设了 Blink 这样一个内部体系。从 16 年开始，我们逐渐将 Blink 贡献回社区，至 18 年已成为 Flink 社区最大的贡献者。今天我们欣喜地看到，Apache Flink 项目管理委员会中有 1/4 的成员来自阿里巴巴，通过阿里巴巴的推动以及整个社区的合作，Flink 已经被中国绝大多数的互联网企业作为流计算的事实标准来采用，Flink 也连续两年蝉联 Apache 社区最活跃项目。

今天云与开源的迭代，也使得人们在开源软件的方向上有了新的探索。以 Flink 为例，最初是一个以 Java API 实现流计算的平台，在阿里巴巴内部及阿里云上的应用中逐渐生长出了像 SQL 这样的能力。近几年，阿里巴巴也在根据自身使用 Flink 的需求不断探索新的方向，例如在数据集成方向发展非常快的 Flink CDC 项目、和机器学习结合的 Flink ML 项目、与传统数仓相结合的流式数仓概念以及在此概念下推出的 Flink Table Store 项目等。此外，在整个大数据领域也有很多共性的技术，例如大规模分布式计算在存算分离环境中的 Remote Shuffle Service，在 Flink、Spark、Hive 等引擎中都有类似的需求。我们也很高兴地向大家宣布，阿里云已经将自身云场景中孕育的 Remote Shuffle Service 项目捐献给了 Apache 软件基金会，命名为 Apache Celeborn。

阿里巴巴不仅是开源软件的受益者，同时也是贡献者。开源已经成为阿里巴巴工程师文化中不可或缺的一部分，越来越多的工程师在开源社区汲取知识，在积极地参与开源软件和社区建设，同时也在适当的时候将我们自己建设的项目贡献给开源社区。我相信在未来我们会继续和开源社区一起，基于云这样一个底座，给用户提供更加容易触达和使用软件的平台和方式，同时以我们和社区的技术实力共同建设更加繁荣的开源社区。

Flink Towards Streaming Data Warehouse

主论坛 Keynotes 议题照例由 Apache Flink 中文社区发起人、阿里云开源大数据平台负责人王峰老师开启，介绍了 Apache Flink 社区在 2022 年取得的主要技术创新与成果，以及未来的发展方向。

Apache Flink 2022 - 数据实时化技术创新不止

2022 年，Apache Flink 发布了两个大版本。在 Flink 1.15 版本中，社区集中解决了许多长期存在的历史难题，包括 SQL 作业的跨版本升级、状态快照的所属权语义与生命周期管理、跨数据源的 Watermark 进度同步、批作业自适应算子并发设置等。在 Flink 1.16 版本中，社区进行了更多新的创新与尝试，包括分布式一致性快照架构升级、创新流批自适应融合 Shuffle、基于异步与缓存技术的流式 SQL 维表 Join 改进、完整兼容 Hive 生态、PyFlink 功能及性能全面生产可用等。

分布式一致性快照架构全新升级

Apache Flink 作为一款有状态的流式计算引擎，分布式一致性快照是其非常核心的一项技术。Flink 在流计算过程中，定期对状态做快照并持久化，当作业出现异常时可以从最近一次快照进行恢复，以保证业务连续性。因此，能够以更高的频次、更低的成本进行快照，让业务更加流畅，是 Flink 用户的共同诉求。然而在真实生产环境中，特别大规模复杂生产环境中，分布式一致性快照面临着诸多挑战：一方面在反压状态下，网络缓冲拥塞，用于做分布式快照的 Barrier 无法沿数据流向下传输，无法及时触发快照；另一方面，即使能触发快照，需要持久化到远程存储系统的本地状态数据的数据量和上传时间均不可控。上述原因导致用户时常遇到无法在规定时间内生成分布式快照的情况，严重影响业务的稳定性。

针对上述问题，Flink 在最近几个版本中对整个分布式一致性快照架构进行了全方面的升级，主要内容包括：

• Unaligned Checkpoint：当 Barrier 对齐时间达到一定阈值后，自动转化为 Unaligned Checkpoint，兼顾 Checkpoint 的数据量与 Barrier 对齐时间。
• Buffer Debloating：只缓存下游算子 1s 内可以处理的数据量，在避免网络传输影响算子性能的前提下，最大限度降低算子间缓存的数据量。
• Log-based Checkpoint：状态表与增量日志解耦，异步上传，大幅降低生成快照的成本。

随着上述技术在 Flink 1.16 落地，Flink 形成了新一代的分布式一致性快照架构。

面向云原生的新一代状态存储管理体系

云原生时代已经到来，各个基础软件项目都需要考虑如何去适应这样一个时代，Apache Flink 也不例外。对于 Flink 而言，云原生时代带来的最显著的变化是对于资源弹性扩缩容的诉求，这要求 Flink 作业的并发度能够随着业务量和资源不断改变。在并发度改变时，Flink 的状态存储也需要快速地重新分配，即状态存储的分裂与合并。因此，Flink 状态存储的分裂、合并性能，直接关系到 Flink 弹性扩缩容的体验。

在 Flink 1.16 版本中，社区对 RocksDB State Backend 的状态重建算法进行了大量优化，取得了 2-10 倍的性能提升，使得 Flink 的弹性扩缩容更加平滑、更加适应云原生时代。

此外，社区还计划将 Flink 状态存储管理体系进一步升级为彻底的存算分离架构，以适应云原生环境。目前 Flink 的状态存储管理体系并非真正的存算分离架构，所有状态数据依然存储在本地 RocksDB 实例中，只有在分布式快照时将增量数据拷贝到远程存储，保证远程存储中存有全量的状态数据。未来，Flink 的状态数据将全部原生于远程存储之上，本地磁盘与内存只用作缓存加速，形成分层存储体系，我们称之为分层状态存储（Tired State Backend）架构。

流批融合的 Hybrid Shuffle 创新技术

流批一体、流批融合是 Apache Flink 非常有特色的一个技术理念，而 Shuffle 则是分布式计算系统中一项非常核心的、与性能高度相关的技术。Flink 1.16 创新推出了流批融合的 Hybrid Shuffle 技术。

在此之前，Apache Flink 在流模式和批模式下分别采取了两种不同的 Shuffle 技术：

• 流式 Pipelined Shuffle：上下游任务通过网络直接连接，数据通过内存和网络进行传输，无需磁盘 IO，性能更好。
• 批式 Blocking Shuffle：上游任务先将中间数据写到磁盘或其他存储服务，下游再从磁盘或存储服务读取中间数据，需要磁盘 IO，性能稍差。

那么能否将流式 Shuffle 也应用在批执行模式下，加速批的 Shuffle 呢？从技术本身来说是可以的，但在生产环境下会面临比较大的约束。流式 Shuffle 要求所有彼此联通的任务同时拉起，这就需要更多的资源，而在生产环境下是否能有这么多资源是无法保证的，甚至可能会有死锁的情况发生。如果能只在资源充足的情况下将彼此联通的任务同时拉起进行流式 Shuffle 加速，同时在资源不足的情况下退化为批式 Shuffle，就可以更加合理地利用资源来进行 Shuffle 的加速。这也就是 Hybrid Shuffle 的背景和思路。

Flink 1.16 中完成了第一版 Hybrid Shuffle，初步评测相比传统的 Blocking Shuffle 取得了不错的性能提升。在后续版本中，社区也会对这项技术做进一步的完善与优化。

Flink CDC 全增量一体化数据同步

Flink CDC，即基于 Apache Flink 的全增量一体化数据同步技术，是近两年提出的一个新概念。

为什么要基于 Flink 打造一款全增量一体化数据同步引擎？Flink 本质上是一款流式分布式计算引擎，事实上已经成为连接不同存储的数据管道。Flink 拥有丰富的 Connector 生态能够连接各种主流存储系统，具有优秀的分布式架构支持分布式快照、流批融合等机制，这些都是一款全增量一体数据集成引擎所需要的特性。因此，基于 Flink 打造全增量一体化数据同步引擎是非常适合的，这也就是 Flink CDC 项目的由来。

去年我们推出了 Flink CDC 1.0，得到了来自开发者生态非常好的反馈。因此今年我们加大投入，推出了更加成熟完善的 Flink CDC 2.0。Flink CDC 2.0 的主要特性包括：

• 通用的增量快照框架抽象，降低了新数据源的接入成本，使 Flink CDC 能够快速接入更多的数据源。
• 支持高性能的并行读取。
• 基于 Flink 的分布式快照机制，实现数据同步的断点续传，提高可靠性。
• 对数据源全程无锁，数据同步对在线业务无任何影响。

Flink CDC 创新项目成长非常迅速，正在成为新一代数据集成引擎。目前 Flink CDC 已支持了包括 MySQL 家族、PolarDB、Oracle、MongoDB 等主流数据库且接入了增量快照框架，另外还支持了像 DB2、SQLServer、PostgreSQL、TiDB、OceanBase 等耳熟能详的数据库，相信今后也会有更多的数据源接入 Flink CDC 框架。该项目也获得了开源生态中开发者们的一致好评，Github  Star 数已经超过 3,000。

新一代迭代计算框架助力 Flink ML-2.0

在老版本的 Flink 中有一个 Flink ML 模块，是一套基于 DataSet API 实现的机器学习算法库。随着 Flink 基础 API 层全部统一到流批一体的 DataStream API，原本的 Flink ML 模块也和 DataSet API 一同被废弃了。今年，Flink 社区基于 DataStream API 重新建设 Flink ML 成为一个新的子项目，目前已经发布了两个版本。

众所周知，机器学习算法库运算的核心是迭代计算框架。Flink ML 2.0 基于 Flink DataStream API 重建了一套流批一体的迭代计算框架，能够支持无限流上的在线训练、训练中断恢复以及高性能的异步训练。Flink ML 2.0 仍处于起步阶段，第一批数十种算法已经由阿里云实时计算和机器学习团队完成了贡献，能够覆盖常见的特征工程场景，支持低延迟的近线推理计算。期待未来有更多公司和开发者能够参与进来，为 Flink ML 贡献更多经典的机器学习算法，让 Flink 优秀的计算能力在机器学习场景中发挥更大的作用。

Apache Flink Next - Streaming Data Warehouse

在去年的 FFA 峰会上，我们提出了 Apache Flink 社区下一步技术演进的方向——Streaming Data Warehouse。

我们首先来回顾一下 Flink 历史上核心技术理念演进的过程，这有助于理解为什么我们认为 Streaming Data Warehouse 是 Flink 下一步的演进方向。

• Stateful Streaming：Flink 在诞生之初，能够受到开发者的青睐，取代上一代流式计算引擎 Storm，成为新一代流式计算引擎，关键在于其有状态的流计算这一定位。通过将流计算与状态存储有机融合，Flink 可以在保持高吞吐低延迟的同时，在框架层支持有状态流计算的精准数据一致性。
• Streaming SQL：早期 Flink 开发必须写 Java 程序，使得 Flink 项目在快速发展几年之后遇到了推广门槛过高的瓶颈。在数据分析师的世界里，事实标准的语言是 SQL。于是在 2019 年，阿里云将内部积累的 Blink SQL 贡献给了 Flink 社区，大幅降低了 Flink 的开发门槛，使得 Flink 在各行各业的应用得到了爆炸式的增长。
• Streaming Data Warehouse：Flink 的流批一体 SQL 能够实现计算层全量增量开发一体化的体验，但无法解决存储层割裂的问题。流式存储中的数据很难对其进行查询分析，而批式存储中数据的时效性又比较差。因此，我们认为下一阶段 Flink 社区新的机会点就在于继续提升一体化体验，通过流批一体 SQL + 流批一体存储构建一体化体验的流式数仓。

Flink 社区推出的全新子项目 Flink Table Store，其定位就是实现流批一体的存储能力，能够实现高性能的流读、流写、批读、批写。Flink Table Store 的设计遵循存算分离理念，数据存放在主流的云存储之上，其核心存储格式由 LakeStore 和 LogStore 两部分组成。LakeStore 应用了经典的 LSM、ORC 及其他索引技术，适合大规模、高性能的数据更新与读取。LogStore 提供了完整 CDC 语义的 ChangeLog，配合 Flink Streaming SQL 可以增量订阅 Table Store 进行流式数据分析。此外，Flink Table Store 采用开放的数据格式体系，除了默认对接 Flink 之外，也可以对接 Spark、 Hive、Trino 等主流开源计算引擎。

Flink Table Store 诞生一年来，共推出了两个版本，完成了从 0 到 1 的孵化落地。目前除了阿里云之外，也有来自字节跳动等公司的开发者在参与共建和试用。我们对 Flink Table Store 和目前主流的数据湖存储 Hudi 进行了性能对比，结果显示 Flink Table Store 的更新性能明显领先 Hudi，查询性能明显领先 Hudi MOR 模式、接近 Hudi COW 模式，综合表现更佳。

Apache Flink 实时计算在美的多业务场景下的应用与实践

第二场 Keynotes 议题是由美的集团实时数据负责人、资深数据架构师董奇老师带来的，她从家电行业的视角分享了 Apache Flink 实时计算在美的传统及新兴业务场景的应用与实践。

董奇老师首先介绍了实时生态体系在美的的发展和建设现状。美的的实时数仓体系建设主要围绕时效性、稳定性、灵活性三个要素。时效性方面，设计了以 Flink 为核心的时效性保障架构；稳定性方面，包括开发阶段针对数据源连通性、元数据参数格式等的一系列校验和运行阶段的集群资源、任务状态等监控告警；灵活性方面，包括统一的元数据、UDF、Connector 等资源管理和对任务模板、公用逻辑等任务管理功能的支持。

Flink 在美的核心传统业务场景的数字化转型中发挥了重要的作用，董奇老师分享了其中三个场景。

• B 端长周期场景：具体业务场景包括美云销 App 看板和全链路订单可视。传统行业的采购、营销、库存分析以及长周期订单的跟踪，都需要对过去很长一段时间的数据进行回溯，这对实时计算的挑战是比较大的。在我们的架构中，历史全量数据是通过 Flink 自动加载 Hive 分区表来引入的，与 Kafka 增量数据相结合，做进一步计算加工。
• 工厂生产进度：工厂的管理人员和员工可以通过实时大屏看到每个小时的生产进度，对于更好地完成每天的生产任务具有很大的实用价值。
• 抢单活动大屏：面向代理商、运营商、零售商的抢单活动，涉及到价格、供货、新品首发等方面的权益，是非常关键的。活动现场的实时大屏对于指导运营人员调整运营策略、代理商和零售商开展零售和抢单活动具有重要意义。

在美的新兴业务场景中，同样有许多基于 Flink 的实时数字化应用实践，在这方面董奇老师也分享了三个场景。

• 家居设备实时智能调控：冰箱云管家、洗地机云管家、电热云管家等产品都具有分析用户行为、调整控制智能家电行为以达到节能节水目的的功能。Flink 消费 Kafka 中的设备数据，与 Redis / HBase 用户、产品、第三方数据以及算法模型、规则相关联，将结果再写出到 Kafka 中，最终通过 IoT 云完成设备指令的下发。此外，在这套链路中 Flink 还承担了实时监控的职能。
• HI 服务实时消息推送：智能家居产品除了自动调控功能之外，还有许多需要通过人机交互、人为操控完成的功能，例如故障提醒、完成提醒、耗材提醒等。这套链路与家居设备实时智能调控很像，只是最终的数据会写出到第三方的推送平台。
• 电商活动监控大屏：业务数据化，将运营人员手工收集录入的业务数据落入数据库，通过 CDC 技术捕捉增量变化数据，再由 Flink 进行加工，通过 StarRocks + QuibkBI 搭建实时大屏，以供快速直观的运营决策。

董奇老师指出，美的集团接下来的实时生态体系建设将重点围绕降本提效与工具赋能，包括云原生部署、热点均衡、任务报错根因与修复提示等基础运维能力，以及平台与业务侧的可视化配置集成工具、细粒度资源配置、流批一体实践等。

Apache Flink 在米哈游的应用实践

接下来是来自米哈游大数据实时计算团队负责人张剑老师的分享。

张剑老师首先介绍了 Flink 在米哈游的发展历程和平台建设情况。米哈游实时计算平台建立之初就选择了 Apache Flink，这是基于 Flink 毫秒延迟、窗口计算、状态存储、容错恢复等优异特性以及背后蓬勃发展的社区。最初的实时计算平台是完全基于 Flink DataStream API 的，初步具备任务的管理与运维能力。随着业务的增长，米哈游实时计算平台在 2020 年开始迈入高速发展阶段，着手打造以 SQL 为主的一站式开发平台，推进了多云跨区域的任务管理、SQL 及连接器、指标和日志体系、元数据和血缘等能力的建设，极大提高了研发效率。今年，米哈游实时计算平台开始朝着新的目标迈进，着手推进一站式开发平台的功能深化与场景覆盖，包括静态和动态调优、自动扩缩容、资源弹性、近实时数仓等能力的建设。

在应用方面，张剑老师分享了米哈游内部四个重要的应用场景。

• 全球游戏日志标准化采集加工：Flink 承担着米哈游全游戏业务每天近百亿的日志处理，峰值流量过千万。通过 Filebeat 采集和日志上报服务接收到的日志传输到 Kafka 实时数据总线，经过 Flink SQL 处理加工，写入下游 Clickhouse、Doris、Iceberg 等存储，提供给客服查询系统、运营实时分析、离线数仓等应用场景。

• 实时报表及实时大屏：我们会根据业务需求，对重要的指标提供实时大屏服务，同时针对运营基于 BI 报表提供实时指标的应用查看。在社区帖子排序的场景中，数据来源一是客户端埋点上报到 Kafka，二是通过 Flink CDC 抓取业务库的增量数据。为了不引入额外的 KV 存储，同时解决维表更新不及时导致关联失败的问题，我们将 Flink 流式消费 Kafka 的任务和 Flink CDC 抓取业务库的任务合并成了同一个任务，采用 RegularJoin 进行关联。这里我们对 Flink SQL 进行了拓展，能够控制底层状态细化的生存周期，避免维表状态过期。关联后的数据再经过指标计算，提供给帖子排序服务。
• 近实时数仓：我们通过 Flink SQL 实时写入 Iceberg 的方式，实现了日志离线入仓近实时化，数据入仓时效从小时级缩短到了分钟级，离线存储 IO 的波动性也平稳了很多。通过 Flink CDC 对 MySQL 数据库进行全量、增量的同步，结合平台的一键任务生成、自动调优扩缩容、自动提交运行等能力，实现了数据库一键入湖，大幅提高了开发效率、降低了对数据库的压力。近实时数仓的一个典型应用场景是玩家战绩查询。

• 实时风控：在米哈游，风控团队和实时计算团队联系密切。风控团队提供了良好的风控引擎，实时计算团队基于风控引擎构建了一套相对自动化的 API 及任务管理方式，让实时计算平台服务化。具体的应用场景包括登录校验、游戏反作弊、人机校验等。

张剑老师介绍，米哈游在实时计算领域未来的工作主要包括三个方面：一是平台能力建设，包括 Flink SQL、资源调优、自动化运维、资源弹性等；二是使用场景的探索，比如延迟消息服务、基于 Flink CDC 的 Binlog 服务、应用级别指标服务等；三是数据湖和 TableStore 的不断实践，包括流批一体与近实时数仓的实践与探索。

Disney 流媒体广告 Flink 的应用实践

最后一场 Keynotes 议题是由 Disney 广告智能执行总监郝又超老师和 Disney 广告智能实时计算负责人李丁哲老师联合带来的。

郝又超老师首先介绍了 Disney 流媒体广告业务。Hulu 作为美国本土头部的流媒体平台，最早是由 Disney、Fox、NBC 共同发起成立的。随着 2019 年对 Fox 的收购，Disney 得到了 Hulu 的运营控制权与广告平台的优质资源，开始发力线上流媒体，陆续推出 Disney+、ESPN+、Star+ 等品牌。目前，Disney 流媒体在全球有 2.35 亿订阅用户（以家庭为单位），已超过 Netflix。Hulu是当前 Disney 流媒体广告业务的主要来源，每天投放数亿15秒、30秒长的视频广告，而每选择一个广告都会产生几十甚至上百个事件，对数据平台有着极高的挑战，随着Disney+上12月份即将上线广告，这种挑战预期将数倍增长。Disney 流媒体广告数据平台分为数据算法和应用服务两层，其中 Apache Flink 主要应用于数据算法层，对运营数据中的关键指标做实时聚合。

接下来，李丁哲老师分享了 Disney 流媒体广告数据平台中实时数据部分的具体情况。在实时链路中，从系统及用户侧收集到的数据，由 Flink 进行统一的流式计算，计算出的指标通过数据接口暴露给业务平台、运维平台、广告服务器等。在离线链路中，使用 Spark 生成离线报表和对外数据输出，使用 Flink 进行指标回填等处理。

李丁哲老师还分享了 Disney 流媒体广告使用 Flink 的三个实时应用场景。

• 广告决策漏斗：广告决策是一个复杂的过程，需要从庞大的广告池中，通过粗排、精排以及一系列过滤条件，选择出最适合用户的广告。为了对这个复杂的过程进行错误排查，我们将其抽象成漏斗模型，对广告的投放机会、定向成功与否、是否被过滤、最终是否投放成功、投放失败原因等信息进行展示。我们使用 Flink 将从广告服务器获取到的决策信息进行解码、关联，还原出决策漏斗并交由前端展示。在离线链路中我们实践了 Flink 的流批一体，使用同一套代码在实时数据出现问题时进行纠错与数据回填。

• 广告曝光监控：广告主通常会提出一些广告投放的要求，比如针对特定人群投放、限制同用户同时间段内的投放次数、避免和竞品广告同时出现等。针对这些需求，我们研发了广告曝光监控平台，让广告主可以查看其广告投放的相关信息。在这个场景中，我们使用 Flink 对来自广告系统和客户端的上下文信息和用户行为进行关联和维度增强，生成一系列的事实指标，并基于特定规则计算出更多衍生指标。
• 广告系统大屏：面相管理层与业务方，提供关于广告系统与广告投放情况的全局洞察能力。来自事实数据源的数据，经过 Flink 的处理，通过指标接口暴露出来，再根据不同的业务规则进行聚合，最终投放给前端做大屏展示。

李丁哲老师介绍，Disney 流媒体广告的实时数据平台搭建在云上，部署在 Kubernetes 容器编排系统上，使用 Flink Operator 管理 Flink 集群，实践了 Gang Scheduler、流批作业混部、基于队列的弹性扩缩容等技术。

在议题的最后，郝又超老师分享了 Flink 未来在 Disney 流媒体广告平台上的一些应用场景规划，包括全流批一体、OLAP、实时归因、流式机器学习等。

总结

本次大会上，我们欣喜地看到 Apache Flink 社区仍在持续繁荣地向前发展：社区建设方面，全球与中文社区规模与活跃度均屡创新高；技术成长方面，状态、容错、Shuffle、数据集成、机器学习等方向都在持续创新，面向未来流式数仓的流批一体存储 Flink Table Store 也取得了喜人的进展；行业应用方面，正有越来越多不同行业的公司加入到 Flink 生产实践的队伍中，将技术积累与新的需求源源不断地回馈到社区。让我们共同期待 Apache Flink 越来越好~！