“我们查询了超过 2 PB 的分析数据和数 TB 的事务数据，每天处理 10 亿个事件。Apache Beam 使我们能够并行化数据处理，最大限度地提高吞吐量，并加速这些数据集的移动/ETL。”
Booking.com 的 Beam 大规模广告竞价
背景
Booking.com 通过投资于消除旅行摩擦的技术，将数百万旅行者与难忘的体验无缝连接，让每个人都能更轻松地体验世界。Booking.com 是 Booking Holdings 的品牌，Booking Holdings 是全球最大的在线旅行和相关服务提供商，为消费者和本地合作伙伴提供服务。为了帮助人们发现 220 多个国家和地区的目的地，Booking Holdings 整体在 2022 年花费了 $5.99 十亿美元用于营销，其中 Booking.com 是 Google 付费点击 (PPC) 搜索广告 的领先旅行广告商。
Booking.com 营销技术部门的 PPC 团队负责运行此规模的 PPC 广告所需的的基础设施和内部工具。PPC 团队的主要目标是可靠高效地优化其跨所有搜索引擎提供商的 PPC，衡量和分析广告效果数据，管理广告层级结构，以及调整广告条件。Apache Beam 通过提供有效的抽象来支持这一目标，该抽象有助于构建可靠、高性能且成本效益高的数据处理基础设施，规模非常大。
Beam 之旅
PPC 广告是 Booking.com 营销的关键业务推广渠道。搜索引擎每天有数十亿次搜索，他们使用 PPC 搜索广告来确保用户在搜索结果中获得最相关的产品。在幕后，PPC 团队管理着处理广告效果反馈、评估历史效果、支持生成竞价的机器学习操作以及将竞价传达回搜索引擎提供商的操作基础设施。
Booking.com 大规模广告竞价的早期实现是一个自定义堆栈批处理管道，使用 MySQL 数据存储、cron 调度和 Perl 脚本来实现业务逻辑。该设计最终遇到了性能瓶颈，难以跟上每秒竞价的不断增长的吞吐量需求。失去的机会成本加上维护复杂性的成本，最终超过了完全重写的成本。
在大规模竞价基础设施中，Apache Beam 出现之前已经进行过几次重写。PPC 团队最新的基于 Apache Beam 的数据生态系统实现背后的核心思想起源于 2020 年后期。参加 Beam 峰会 和 Beam 学院 社区活动帮助团队了解了开源 Apache Beam 抽象模型，该模型也作为 Dataflow 运行器 的托管服务提供。
将这个想法介绍给团队的其他成员很简单 - Apache Beam 模型易于理解，因为它隔离了业务逻辑并有助于建立思维模型。
PPC 团队决定通过创建一个新的原型 Java 管道来下载广告效果报告，对该框架进行试点。
使用 Apache Beam，我们在开发时间上实现了多倍加速。我们实际上可以在 3 周内交付一个管道。如果我们必须使用任何其他框架来实现该管道，我们将花费整整三个月的时间。
第一个 POC 证明成功后，PPC 团队将 Apache Beam 放在了其数据基础设施的核心位置。旋转 Dataflow 托管服务提供了一个机会，可以专注于新功能，而不是维护自己的计算和存储基础设施。从运行时实现细节中抽象出来的 Apache Beam 使 PPC 团队能够专注于业务逻辑，并利用并行性轻松进行水平扩展。作为各种 GCP 产品的重度用户，他们还利用 Apache Beam I/O 连接器 与各种接收器和源进行原生集成，例如 BiqQuery、Firestore 和 Spanner。
Apache Beam 为我们的数据基础设施和处理提供了有效的抽象。使用 Dataflow 运行器，我们也不需要担心维护运行时和存储基础设施，以及云提供商锁定。
文档的质量以及充满活力的 Apache Beam 开源社区、邮件列表中的热烈讨论以及大量用户创建的内容，使得接入新的用例变得非常容易。
在设计和实施新的生态系统时，Apache Beam 开源社区、文档和 YouTube 内容非常有帮助。
目前，Apache Beam 为 PPC 团队的大规模广告竞价基础设施提供批处理和流管道。
大规模广告竞价
从概念上讲，大规模广告竞价基础设施接受广告竞价请求和资产，并提供用于提交到多个服务的暂存，以大规模处理广告效果结果。广告竞价基础设施依赖于 Apache Beam 批处理和流管道来与 Big Query、Spanner、Firestore、Pub/Sub 源和接收器进行交互，并使用 Beam 的有状态处理来进行广告服务 API 调用。
在设计数据基础设施时，PPC 团队的主要目标是最大限度地提高每秒竞价的吞吐量，同时仍然遵守搜索引擎的 Ads API 在帐户级别施加的请求速率限制。PPC 团队实现了利用键控 PCollections 将传出的 Ads 修改按帐户 ID 进行聚类、分组到批处理 以及并行执行数据处理的流式 Apache Beam 管道。这种方法有助于优化团队数千个 Ads 帐户的吞吐量，并实现规模化的性能和可靠性改进。
Apache Beam 使我们能够并行化数据处理，并在非常大的规模上最大限度地提高吞吐量。
PPC 团队使用内部 API 接口向大规模竞价基础设施提交查询，该基础设施将查询路由到相应的 Google 和 Bing 广告竞价管道。对于 Google 分支，API 调用 Invoker 云函数，该函数从 BigQuery 读取数据，聚合数据并执行分析，然后将中间结果存储在 BigQuery 的暂存表中。Invoker 然后调用 Ingestor Apache Beam 批处理管道，该管道将数据发布到 Pub/Sub 中。
另一方面，Google Ad Mutator Apache Beam 流管道监听每天超过 10 亿个 Pub/Sub 事件，并将相应的请求发送到 Google Ads API。该作业的设计考虑了背压，确保最佳性能，同时还考虑了 分区、并行性和密钥排序交付保证 等因素。结果随后被写入 BigQuery 中的结果表和 Spanner 中的库存，每天处理超过 100 GB 的数据。
最后，Daily Importer Apache Beam 批处理管道获取库存数据并将其传播到下游任务，每天也处理 100 GB 的数据。数据分析师随后将传入的酒店预订流与广告库存数据进行匹配，并评估 PPC 广告的成效。
Apache Beam 框架的多功能性和灵活性是整个过程的关键，因为它允许将批处理和流式处理组合到一个统一的流中，同时还支持与各种具有不同特征和语义的源和目标进行集成。该框架还提供了交付和排序保证，所有这些都在规模上完成，并且对流式处理进行了最佳权衡。
Google Ads Mutator 和 Bing Ads Mutator 管道是大规模竞价基础设施的组成部分。这些流式 Apache Beam 管道处理所有来自搜索引擎 Ads API 的数据以及发往搜索引擎 Ads API 的数据，并将大量广告效果报告写入 Cloud Spanner 的库存中。Apache Beam 内置的 Cloud Spanner SpannerIO。Write 变换允许通过 将变异分组 到批处理中，以更有效地写入数据，从而最大限度地提高吞吐量，同时仍然遵守 Spanner 的每个事务限制。通过 Apache Beam 减少变异的键范围，PPC 团队能够在 Spanner 中实现成本优化，并提高处理性能。
同样，为了保持在 Ads API 速率限制级别内，PPC 团队利用 Apache Beam 及时 和 有状态处理 以及基于 Redis 的微服务，该微服务维护竞价的速率限制。PPC 团队有一个自定义的“聚合和发送”函数，该函数在缓冲区填满之前会累积传入的变异命令。该函数从速率限制器请求变异配额，并将请求发送到 Ads API。如果内部速率限制器或 Ads API 请求等待，该函数会启动重试计时器并继续缓冲传入的命令。如果没有等待请求，该函数会清除命令缓冲区并将查询发布到 Pub/Sub 中。
Apache Beam 提供窗口化聚合来预聚合变异命令，并通过使用 计时器 和有状态操作来确保交付保证。通过使用 BagState，Apache Beam 可以将元素添加到集合中以累积一组无序的变异。另一方面，ValueState 存储用于批处理、批处理大小和缓冲区大小的类型化值，这些值可以在 DoFn 的 ProcessElement 和 OnTimer 方法中读取和修改。
支持分页读取的运行器可以处理大于可用内存的单个包。Apache Beam 重试计时器用于在经过一定数量的处理时间后输出缓冲在状态中的数据。刷新计时器用于防止命令在缓冲区中停留过长时间，特别是在命令不频繁且无法填满缓冲区的情况下。
Beam 模型的有状态功能使我们能够通过缓冲传入数据直到可以消费它来获得对每秒竞价的细粒度控制，并保持比其他潜在解决方案更高的处理性能。
为了提升可观察性并为用户提供一种监控其提交状态的方式，PPC 团队还开发了一个自定义函数，该函数使用自定义键生成指标来统计收到的请求和发送的请求数量。Apache Beam 的可扩展性使 PPC 团队能够将这种补充监控工具作为附加模块直接在 Ad Mutator 管道中实现。
结果
Apache Beam 为 Booking.com 的大型性能营销“飞轮”提供数据物流支持，该“飞轮”每月处理 100 多万个查询，用于跨多个数据系统的广告竞价工作流程，每天扫描 2PB+ 的分析数据和 TB 级别的交易数据，在峰值时处理超过 10 亿个事件，每秒处理数千条消息。
Apache Beam 提供了急需的并行处理、连接和分区功能，以及强大的键有序传递保证，可以并行处理 Booking.com 数千个广告账户，优化成本，并确保大规模广告竞价处理的性能和可靠性。
Apache Beam 将流式管道处理时间从 6 小时缩短至 10 分钟，这相当于运行时间缩短了 36 倍，令人叹为观止。高性能且快速的 PPC 广告竞价基础设施现在每天推动来自搜索广告的 200 多万个预订。Apache Beam 抽象化简化了新团队成员的加入，使编写和维护管道变得更容易，并将从设计文档到生产上线的时间缩短了 4 倍。
PPC 团队计划扩展 Apache Beam 统一处理能力的使用范围，将多个批处理和流式管道合并到单个管道中。
Apache Beam 作为一种模型使我们能够以非常声明式的方式编写业务逻辑。在接下来的开发迭代中，我们计划将多个 Ads Mutator 管道合并到单个流式管道中。
这些信息是否有用？