Yelp 发布大规模管理 S3 服务器访问日志的方案

在这篇工程实践文章中，Yelp 详细介绍了他们如何构建一套可扩展且具备成本效率的日志处理流水线，用于在全公司范围内处理 Amazon S3 的服务器访问日志（SAL），并成功突破了原始日志在高规模场景下面临的存储成本高、查询效率低等传统瓶颈。文章系统性地梳理了 Yelp 在日志体量、存储开销以及查询性能方面遇到的挑战，以及他们如何通过工程手段让对象级日志在大规模场景下变得可行。

目前，Yelp 每天都会产生 TB 级别的访问日志。这些日志虽然最初以纯文本形式写入，但随后会被转换为紧凑的 Parquet 格式归档文件，从而可以被 Amazon Athena 等查询工具高效分析。通过定期执行的“压缩”流程，原本分散的大量纯文本日志对象会被合并为数量更少、体积更大的 Parquet 文件，这一过程将整体存储空间减少了约 85%，同时将对象数量削减了 99.99% 以上。在显著降低存储成本的同时，也让权限排查、成本归因、事故调查以及数据保留分析等查询场景变得快速而经济。

在底层架构上，这套系统使用 AWS Glue Data Catalog 来统一管理跨多个 AWS 账号的日志 schema，并结合定时批处理作业、Lambda 函数以及基于分区投影的表设计，实现稳定且高度自动化的日志摄取流程。考虑到 SAL 本身允许延迟或重复投递日志，系统在写入时采用幂等设计，从而避免数据重复。同时，一旦日志内容被安全归档，原始对象就会被打上生命周期管理标签，按策略自动过期清理。

这套访问日志系统也支撑了多种关键的运维和治理场景。工程师可以查询某个具体对象在特定时间点是否被访问或被拒绝，用于权限和安全排查；也可以按 IAM 角色聚合 API 调用情况，从而分析不同服务或团队的访问成本；在数据治理层面，通过将访问日志与 S3 inventory 结合，团队能够识别长期未被访问的对象，并在确保安全的前提下进行清理。

Yelp 的这项工作具有双重意义。一方面，它证明了长期以来被认为“过于昂贵或难以运维”的 S3 对象级访问日志，在合理的架构设计下完全可以实现规模化落地；另一方面，它为希望提升云存储环境中可观测性、合规能力和审计能力的组织，提供了一套可参考的工程范式。随着企业对数据治理、审计以及成本可视化需求的持续增强，Yelp 的实践展示了一种在不显著推高存储成本的前提下，仍能保持良好查询能力的现实路径。

与 Yelp 的实践相呼应，业界也存在多种采用这种被 Yelp 称作是“大规模 S3 服务器访问日志”的类似设计模式方案。

例如，Upsolver 作为一款数据湖与 ETL 平台，内置了对 S3 访问日志的摄取支持，可将日志转换为面向分析的格式并针对查询引擎进行优化，其 S3 访问日志的处理流程与 Yelp 的方案高度相似，均围绕日志摄取、格式转换以及通过 Amazon Athena 等 SQL 引擎进行查询展开。这种方案让团队能跳过手搓自定义日志访问流水线的同时，仍能获得规模化日志分析的好处。

AWS 官方同样发布过一套基于 Glue 作业处理 S3 服务器访问日志的参考架构，尤其在与 Ray 结合用于可扩展的 Python 处理场景中具有参考价值。该方案通过对日志进行分区、转换为 Parquet 格式并注册到数据目录中，再使用 Athena 或可视化处理工具 Amazon QuickSight 进行分析，本质上复现了 Yelp 所采用的“压缩 + 表结构 + 数据目录 + 查询”的整体模式，只不过是以 AWS 托管方案的形式提供。

此外，在更通用的日志和事件型数据湖场景中，诸如 Apache Druid，以及 Presto/Trino 等系统，常被用作包括 S3 对象存储的底层查询引擎。当日志被转换为列式存储格式（如 Parquet、ORC，或通过 Apache Iceberg 等湖表格式进行管理）后，这些引擎可以作为可扩展、低延迟的查询层，为访问日志、审计日志或事件日志提供支撑。

对于需要近实时搜索与告警能力的场景（例如安全分析或异常检测），AWS 的博文中还提到了将 S3 访问日志通过 Lambda 和摄取管道导入 OpenSearch，并使用 Kibana 进行可视化分析的方案。虽然这种方式在长期存储效率上不如 Parquet + Athena 的组合，但在安全、合规或运维监控等场景中，可以提供更即时的调查与响应能力。

原文链接：

https://www.infoq.com/news/2025/12/yelp-s3-server-access-logs/