Roblox 邁向每日 2 兆次分析事件之路
建置可擴展的分析資料匯入基礎架構
每天平均有 9,780 萬名用戶* 造訪 Roblox，進行交流、創作與共同遊玩。這些互動總計產生了 2 拍字節的分析事件數據。得益於一套新的可擴展資料導入系統，我們最近達成了重要里程碑：我們的系統現已每天處理超過 2 兆個事件。這套系統驅動著 Roblox 平台背後的個人化、安全與經濟演算法。
過去，雲端佇列服務會將 Roblox 產生的分析資料匯入一個名為 events_hourly 的單一邏輯資料表中。該資料表會依據日期、小時，以及 web、mobile 或 friendService 等任意定義的標籤進行區隔。 我們的資料科學家和工程師過去仰賴排程的批次工作，將特定事件提取至專用資料表中。建立並傳送新的分析事件無需預先定義資料結構。工程師會在後續的提取、轉換與載入（ETL）管線階段，自行控制其資料表的結構。
這種架構雖然靈活且能讓工程師迅速行動，但也帶來了挑戰。
- 隨著事件量增加，僅依日期、時間和標籤進行區隔的 2 兆行資料，其互動效率日益降低。
- events_hourly 表有六小時的每日結算延遲，而 events_daily 表則有 24 小時的延遲，這導致資料管道在某些時段被阻塞。
- 管理資料集層級的權限、層級、保留期限和警示變得更加複雜。
- 事件文件、歷史記錄和所有權均缺失，導致資料的可用性和可追溯性不佳。
- 使用雲端佇列服務建置的資料匯入基礎架構，產生了 23 Gbps 的雲端匯入成本。
消除昂貴的事件擷取
過去的資料分析仰賴透過眾多批次管道，從單一邏輯資料表中提取資料。此做法雖是執行大型高效能查詢的必要條件，卻也拖慢了處理速度。透過使用資料匯入後端服務，將這些事件路由至專用資料表，並預先為分析事件定義資料結構與目標資料表，即可消除批次提取管道。
我們選擇 Protobuf（proto）作為 Roblox 分析事件的資料結構語言。這是一個自然而然的選擇，因為 proto 和 gRPC 是我們首選的服務建構框架。此外，proto 對定義自訂選項提供了強大的支援，我們藉此收集額外的元資料，例如所有權、保留率、生產力軟體管道以及事件資料結構。
在選定模式語言後，我們檢視了模式更新時會發生什麼情況，以及應允許哪些更新。為了支援最多使用已發布模式的下游使用者，資料團隊採用了 Schema Registry 中所述的「向後傳遞模式」。透過此方法，允許新增及軟刪除欄位。這使得模式變更無需與下游使用者協調即可進行。
在上述範例中，我們可透過更新 proto 檔案來新增或刪除欄位。
模式雖有諸多好處，但若在前期就強制要求使用，會增加開發阻力。資料科學家與工程師需要快速行動並無障礙地進行迭代。為此，我們導入了集中式的模式儲存庫，並建置了一套工具組，旨在讓模式的編寫盡可能自動化且流程順暢。
例如，我們開發了自訂的 Proto 語法檢查工具，用以驗證每個模式是否具備必要的元資料，並符合 Roblox 的規範。 我們還開發了一個 Proto 外掛程式，用於將事件模式轉換為 Hive 資料定義語言，確保無論何時建立或更新模式，對應的 Hive 資料表都能保持同步。所有這些工具都整合到 CI/CD 管道中，並會在建立拉取請求時自動執行。這讓工程師能夠及早發現模式問題，並在模式合併前於測試 Hive 資料表中驗證事件。因此，將模式部署到生產環境就如同合併代碼般簡單。
在建立起簡化的開發者體驗後，我們檢視了事件應在資料導入管道的哪個環節進行模式化並轉換為 Proto。要求事件產生者採用並傳送序列化的 Proto 位元組，將是一項橫跨多個團隊的重大變革。為解決痛點並逐步交付價值，我們透過更新資料導入後端服務來將傳入的事件轉換為 Proto，從而將模式化工作與事件產生者解耦。 如今，轉換後的事件會被彙整為 Parquet 檔案，上傳至分散式儲存系統，並註冊為獨立的 Hive 資料表。
透過 Roblox 資料中心進行即時事件擷取
接下來，我們著重探討分析事件的傳送成本。先前，資料擷取後端是建構在雲端基礎架構上的。 分析事件會傳送至佇列服務，該服務會先進行緩衝，再將事件儲存至持久性雲端儲存中，以供後續處理與分析。雖然雲端佇列服務簡化了我們的服務架構並能實現透明的彈性擴展，但其他串流工作難以使用，且成本較高。為解決此問題，我們探索將資料擷取服務移入 Roblox 的資料中心。
我們的內部儲存團隊基於開源的分散式事件串流平台，建置了「排程即服務」（QaaS）。QaaS 是分析事件擷取的絕佳替代方案，因為事件會依照先入先出（FIFO）的順序進行尾部追蹤，並在短暫的保留期後被刪除。 在 Roblox，我們為每個已建模的事件建立專用主題，並透過分區數來擴展大型事件串流的處理能力。資料團隊還建置了專用服務，用於從 QaaS 讀取資料、建立 Parquet 檔案，並將檔案上傳至持久性雲端儲存。
在部署 QaaS 並建立專用服務來生成及儲存 Parquet 檔案後，資料團隊進行了為期六個月的影子寫入（shadow writes），以驗證資料正確性與可擴展性。最終，經過全面性的資料完整性與一致性檢查後，我們成功將分析事件的匯入作業從舊有的雲端佇列服務遷移出來。這是一項重大的里程碑。 我們從資料導入路徑中移除了雲端資源成本，並大幅縮短了事件觸發與資料落入資料湖之間的延遲。過去我們曾訂立三小時的服務水準協議，但經常無法達標；如今，我們已能穩定維持平均 15 分鐘的處理時間。
進展與未來工作
這使工程師能夠透過 QaaS 擷取結構化事件，據此編寫即時事件處理管線，以驅動安全防護與即時推薦功能。我們亦採用相同的結構化框架與 QaaS 擷取機制，推出了變更資料擷取功能，大幅減少了完整資料庫備份的需求。從即時分析與事件串流到開拓新應用場景，我們持續致力於創新，並大規模建構更智慧、更快速且更具成本效益的資料系統。
謹此感謝 Paul Mou 對本項工作的寶貴貢獻。
* 截至 2025 年 3 月 31 日止的三個月期間。
