Roblox 如何实现每日 2 万亿次分析事件

每天，平均有 9780 万用户* 访问 Roblox，进行交流、创作和共同游戏。这些互动共同产生了 2 拍字节的分析事件数据。得益于一个新的可扩展数据采集系统，我们最近达成了一项重大里程碑：我们的系统现在每天处理超过 2 万亿个事件。该系统支持驱动 Roblox 平台的个性化、安全性和经济性算法。

此前，云队列服务将 Roblox 生成的分析数据摄入到一个名为 events_hourly 的单一逻辑表中。该表按日期、小时以及 web、mobile 或 friendService 等任意定义的标签进行分区。 我们的数据科学家和工程师依赖于预先安排的批处理任务，将特定事件提取到专用表中。创建和发送新的分析事件无需预先定义模式。工程师在提取、转换和加载（ETL）管道阶段，可以自主控制下游表的模式。

这种架构虽然灵活，能让工程师快速推进工作，但也带来了挑战。 

• 随着事件量的增长，仅按日期、小时和标签对 2 万亿行数据进行分区，交互效率越来越低。
• events_hourly 表有 6 小时的日终延迟，events_daily 表有 24 小时的延迟，这导致数据管道在某些时段被阻塞。 
• 数据集级别的权限、分层、保留和警报的管理变得更加复杂。 
• 事件文档、历史记录和所有权缺失，导致数据可用性和可追溯性较差。 
• 使用云队列服务构建的数据摄取基础设施产生了 23 Gbps 的云摄取成本。

此前，数据分析依赖于通过多个批处理管道从单个逻辑表中提取数据。虽然这对于运行大型、高性能的查询是必要的，但也拖慢了处理速度。利用数据摄取后端服务将这些事件路由到专用表中，通过为分析事件预先定义模式和目标表，从而消除了批处理提取管道。 

在 Roblox，我们选择 Protobuf（proto）作为分析事件的模式语言。这是一个自然的选择，因为 proto 和 gRPC 是我们首选的构建服务框架。此外，proto 还提供了强大的自定义选项定义支持，我们利用这些选项来收集额外的元数据，例如所有权、保留策略、生产力软件渠道以及事件模式。 

在选定模式语言后，我们研究了模式更新时会发生什么，以及应允许哪些更新。为了支持尽可能多的下游用户使用已发布的模式，数据团队采用了模式注册表中描述的向后传递模式。采用这种方法，允许添加和软删除字段。这使得模式变更无需与下游用户协调即可进行。 

在上例中，我们可以通过更新 proto 文件来添加或删除字段。

模式虽有诸多优势，但若在前期强制要求使用，会增加开发阻力。数据科学家和工程师需要快速行动并无障碍地进行迭代。为此，我们引入了集中式的模式存储库，并构建了一套工具，旨在尽可能实现模式编写的自动化和流程优化。 

例如，我们开发了一个自定义的 proto 代码检查工具，用于验证每个模式是否包含必需的元数据并符合 Roblox 的规范。 我们还开发了一个 Proto 插件，用于将事件模式转换为 Hive 数据定义语言，确保无论何处创建或更新模式，对应的 Hive 表都能保持同步。所有这些工具都集成在 CI/CD 管道中，并在创建拉取请求时自动运行。这使工程师能够在模式合并前尽早发现问题，并在测试 Hive 表中验证事件。因此，将模式部署到生产环境只需简单地进行合并操作。 

在优化了开发者体验后，我们开始研究事件应在数据摄取管道的哪个环节进行模式化处理并转换为 Proto。要求事件生产方采用并发送序列化的 Proto 字节流将是一项涉及多个团队的重大变更。为解决痛点并逐步交付价值，我们通过更新数据摄取后端服务（使其将传入事件转换为 Proto）的方式，将模式化工作与事件生产方解耦。 如今，转换后的事件会被收集到 Parquet 文件中，上传至分布式存储，并注册为独立的 Hive 表。

接下来，我们关注了分析事件的处理成本。此前，数据采集后端是基于云基础设施构建的。 分析事件会被发送到队列服务，该服务先进行缓冲，随后将其存储在持久性云存储中，以供下游处理和分析。虽然云队列服务简化了我们的架构并支持透明的弹性扩展，但其他流式处理任务难以使用该服务，且成本更高。为解决这一问题，我们探索将数据采集服务迁移至 Roblox 的数据中心。 

我们的内部存储团队基于开源分布式事件流平台构建了“队列即服务”（QaaS）。QaaS 是分析事件采集的理想替代方案，因为事件按先入先出（FIFO）顺序处理，并在短暂的保留期后被删除。 在 Roblox，我们为每个已建模的事件创建专用主题，并通过分区计数来扩展大型事件流的处理能力。数据团队还构建了一个专用服务，用于从 QaaS 消费数据、生成 Parquet 文件，并将文件上传至持久性云存储。

借助 QaaS 以及用于构建和存储 Parquet 文件的专用服务，数据团队进行了为期六个月的影子写入，以验证数据的准确性和可扩展性。最终，经过全面的数据完整性和一致性检查，我们成功将分析事件采集从旧的云队列服务迁移出来。这是个重要的里程碑。 我们消除了采集路径中的云资源成本，并显著降低了事件触发与数据落入数据湖之间的延迟。此前我们的服务级别协议（SLA）为三小时，但经常无法达标；如今，我们已能稳定保持平均15分钟的处理时效。 

这使工程师能够基于QaaS获取数据，针对模式化事件编写实时事件处理管道，从而支持安全监控和实时推荐功能。我们还基于相同的模式化框架和QaaS数据摄取功能推出了变更数据捕获（CDC），从而基本消除了对完整数据库导出的需求。从实时分析和事件流处理到开辟新的应用场景，我们持续创新，致力于构建更智能、更快速、更具成本效益的大规模数据系统。 

我们谨此感谢 Paul Mou 对本项工作的宝贵贡献。

^{* 截至 2025 年 3 月 31 日的三个月期间。}