作者 | Craig Risi

譯者 | 馬可薇

在這篇 工程實(shí)踐文章 中，Yelp 詳細(xì)介紹了他們?nèi)绾螛?gòu)建一套可擴(kuò)展且具備成本效率的日志處理流水線(xiàn)，用于在全公司范圍內(nèi)處理 Amazon S3 的服務(wù)器訪(fǎng)問(wèn)日志（SAL），并成功突破了原始日志在高規(guī)模場(chǎng)景下面臨的存儲(chǔ)成本高、查詢(xún)效率低等傳統(tǒng)瓶頸。文章系統(tǒng)性地梳理了 Yelp 在日志體量、存儲(chǔ)開(kāi)銷(xiāo)以及查詢(xún)性能方面遇到的挑戰(zhàn)，以及他們?nèi)绾瓮ㄟ^(guò)工程手段讓對(duì)象級(jí)日志在大規(guī)模場(chǎng)景下變得可行。

目前，Yelp 每天都會(huì)產(chǎn)生 TB 級(jí)別的訪(fǎng)問(wèn)日志。這些日志雖然最初以純文本形式寫(xiě)入，但隨后會(huì)被轉(zhuǎn)換為緊湊的 Parquet 格式歸檔文件，從而可以被 Amazon Athena 等查詢(xún)工具高效分析。通過(guò)定期執(zhí)行的“壓縮”流程，原本分散的大量純文本日志對(duì)象會(huì)被合并為數(shù)量更少、體積更大的 Parquet 文件，這一過(guò)程將整體存儲(chǔ)空間減少了約 85%，同時(shí)將對(duì)象數(shù)量削減了 99.99% 以上。在顯著降低存儲(chǔ)成本的同時(shí)，也讓權(quán)限排查、成本歸因、事故調(diào)查以及數(shù)據(jù)保留分析等查詢(xún)場(chǎng)景變得快速而經(jīng)濟(jì)。

在底層架構(gòu)上，這套系統(tǒng)使用 AWS Glue Data Catalog 來(lái)統(tǒng)一管理跨多個(gè) AWS 賬號(hào)的日志 schema，并結(jié)合定時(shí)批處理作業(yè)、Lambda 函數(shù)以及基于分區(qū)投影的表設(shè)計(jì)，實(shí)現(xiàn)穩(wěn)定且高度自動(dòng)化的日志攝取流程?？紤]到 SAL 本身允許延遲或重復(fù)投遞日志，系統(tǒng)在寫(xiě)入時(shí)采用冪等設(shè)計(jì)，從而避免數(shù)據(jù)重復(fù)。同時(shí)，一旦日志內(nèi)容被安全歸檔，原始對(duì)象就會(huì)被打上生命周期管理標(biāo)簽，按策略自動(dòng)過(guò)期清理。

這套訪(fǎng)問(wèn)日志系統(tǒng)也支撐了多種關(guān)鍵的運(yùn)維和治理場(chǎng)景。工程師可以查詢(xún)某個(gè)具體對(duì)象在特定時(shí)間點(diǎn)是否被訪(fǎng)問(wèn)或被拒絕，用于權(quán)限和安全排查；也可以按 IAM 角色聚合 API 調(diào)用情況，從而分析不同服務(wù)或團(tuán)隊(duì)的訪(fǎng)問(wèn)成本；在數(shù)據(jù)治理層面，通過(guò)將訪(fǎng)問(wèn)日志與 S3 inventory 結(jié)合，團(tuán)隊(duì)能夠識(shí)別長(zhǎng)期未被訪(fǎng)問(wèn)的對(duì)象，并在確保安全的前提下進(jìn)行清理。

Yelp 的這項(xiàng)工作具有雙重意義。一方面，它證明了長(zhǎng)期以來(lái)被認(rèn)為“過(guò)于昂貴或難以運(yùn)維”的 S3 對(duì)象級(jí)訪(fǎng)問(wèn)日志，在合理的架構(gòu)設(shè)計(jì)下完全可以實(shí)現(xiàn)規(guī)?；涞兀涣硪环矫?，它為希望提升云存儲(chǔ)環(huán)境中可觀測(cè)性、合規(guī)能力和審計(jì)能力的組織，提供了一套可參考的工程范式。隨著企業(yè)對(duì)數(shù)據(jù)治理、審計(jì)以及成本可視化需求的持續(xù)增強(qiáng)，Yelp 的實(shí)踐展示了一種在不顯著推高存儲(chǔ)成本的前提下，仍能保持良好查詢(xún)能力的現(xiàn)實(shí)路徑。

與 Yelp 的實(shí)踐相呼應(yīng)，業(yè)界也存在多種采用這種被 Yelp 稱(chēng)作是“大規(guī)模 S3 服務(wù)器訪(fǎng)問(wèn)日志”的類(lèi)似設(shè)計(jì)模式方案。

例如，Upsolver 作為一款數(shù)據(jù)湖與 ETL 平臺(tái)，內(nèi)置了對(duì) S3 訪(fǎng)問(wèn)日志的攝取支持，可將日志轉(zhuǎn)換為面向分析的格式并針對(duì)查詢(xún)引擎進(jìn)行優(yōu)化，其 S3 訪(fǎng)問(wèn)日志的處理流程與 Yelp 的方案高度相似，均圍繞日志攝取、格式轉(zhuǎn)換以及通過(guò) Amazon Athena 等 SQL 引擎進(jìn)行查詢(xún)展開(kāi)。這種方案讓團(tuán)隊(duì)能跳過(guò)手搓自定義日志訪(fǎng)問(wèn)流水線(xiàn)的同時(shí)，仍能獲得規(guī)?；罩痉治龅暮锰?。

AWS 官方同樣 發(fā)布 過(guò)一套基于 Glue 作業(yè)處理 S3 服務(wù)器訪(fǎng)問(wèn)日志的參考架構(gòu)，尤其在與 Ray 結(jié)合用于可擴(kuò)展的 Python 處理場(chǎng)景中具有參考價(jià)值。該方案通過(guò)對(duì)日志進(jìn)行分區(qū)、轉(zhuǎn)換為 Parquet 格式并注冊(cè)到數(shù)據(jù)目錄中，再使用 Athena 或可視化處理工具 Amazon QuickSight 進(jìn)行分析，本質(zhì)上復(fù)現(xiàn)了 Yelp 所采用的“壓縮 + 表結(jié)構(gòu) + 數(shù)據(jù)目錄 + 查詢(xún)”的整體模式，只不過(guò)是以 AWS 托管方案的形式提供。

此外，在更通用的日志和事件型數(shù)據(jù)湖場(chǎng)景中，諸如 Apache Druid，以及 Presto/Trino 等系統(tǒng)，常被用作包括 S3 對(duì)象存儲(chǔ)的底層查詢(xún)引擎。當(dāng)日志被轉(zhuǎn)換為列式存儲(chǔ)格式（如 Parquet、ORC，或通過(guò) Apache Iceberg 等湖表格式進(jìn)行管理）后，這些引擎可以作為可擴(kuò)展、低延遲的查詢(xún)層，為訪(fǎng)問(wèn)日志、審計(jì)日志或事件日志提供支撐。

對(duì)于需要近實(shí)時(shí)搜索與告警能力的場(chǎng)景（例如安全分析或異常檢測(cè)），AWS 的博文 中還提到了將 S3 訪(fǎng)問(wèn)日志通過(guò) Lambda 和攝取管道導(dǎo)入 OpenSearch，并使用 Kibana 進(jìn)行可視化分析的方案。雖然這種方式在長(zhǎng)期存儲(chǔ)效率上不如 Parquet + Athena 的組合，但在安全、合規(guī)或運(yùn)維監(jiān)控等場(chǎng)景中，可以提供更即時(shí)的調(diào)查與響應(yīng)能力。

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

聲明：本文為 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。