Hành trình của Roblox để đạt 2 nghìn tỷ sự kiện phân tích mỗi ngày

Mỗi ngày, trung bình có 97,8 triệu người dùng* truy cập Roblox để giao tiếp, sáng tạo và chơi cùng nhau. Tổng cộng, những tương tác này tạo ra 2 petabyte dữ liệu sự kiện phân tích. Nhờ hệ thống thu thập dữ liệu có thể mở rộng mới, gần đây chúng tôi đã đạt được một cột mốc quan trọng: Hệ thống của chúng tôi hiện đang xử lý hơn 2 nghìn tỷ sự kiện mỗi ngày. Hệ thống này hỗ trợ các thuật toán cá nhân hóa, an toàn và kinh tế, là động lực cho nền tảng Roblox.

Trước đây, một dịch vụ hàng đợi đám mây đã nhập dữ liệu phân tích do Roblox tạo ra vào một bảng logic duy nhất, được gọi là events_hourly. Bảng này được phân vùng theo ngày, giờ và các thẻ được định nghĩa tùy ý như web, mobile hoặc friendService. Các nhà khoa học dữ liệu và kỹ sư của chúng tôi dựa vào các công việc hàng loạt được lên lịch để trích xuất các sự kiện cụ thể vào các bảng chuyên dụng. Việc tạo và gửi các sự kiện phân tích mới không yêu cầu lược đồ trước. Các kỹ sư kiểm soát lược đồ bảng của riêng họ ở giai đoạn cuối của quy trình trích xuất, chuyển đổi và tải (ETL).

Cấu hình này rất linh hoạt và giúp các kỹ sư làm việc nhanh chóng, nhưng nó cũng đặt ra những thách thức. 

• Khi khối lượng sự kiện tăng lên, việc tương tác với 2 nghìn tỷ hàng dữ liệu chỉ được phân vùng theo ngày, giờ và thẻ ngày càng trở nên kém hiệu quả.
• Sự chậm trễ sáu giờ vào cuối ngày đối với bảng events_hourly và 24 giờ đối với events_daily đã tạo ra những khoảng thời gian mà các đường ống dữ liệu bị chặn. 
• Việc quản lý quyền truy cập, cấp độ, thời gian lưu trữ và cảnh báo ở cấp độ tập dữ liệu trở nên phức tạp hơn. 
• Thiếu tài liệu, lịch sử và thông tin chủ sở hữu sự kiện, dẫn đến khả năng sử dụng và truy xuất nguồn gốc dữ liệu kém. 
• Cơ sở hạ tầng nhập liệu, được xây dựng bằng dịch vụ hàng đợi đám mây, đã phát sinh chi phí nhập liệu đám mây 23 Gbps.

Trước đây, phân tích dữ liệu dựa vào việc trích xuất dữ liệu từ một bảng logic duy nhất thông qua nhiều đường ống xử lý hàng loạt. Điều này là cần thiết để chạy các truy vấn lớn, hiệu suất cao — nhưng nó cũng làm chậm quá trình xử lý. Việc sử dụng dịch vụ backend nhập liệu để chuyển các sự kiện này đến các bảng chuyên dụng giúp loại bỏ các đường ống trích xuất hàng loạt bằng cách cung cấp lược đồ cho các sự kiện phân tích và xác định bảng đích trước. 

Chúng tôi đã chọn Protobuf (proto) làm ngôn ngữ lược đồ cho các sự kiện phân tích tại Roblox. Đây là một lựa chọn tự nhiên, vì proto và gRPC là các khung dịch vụ xây dựng ưa thích của chúng tôi. Ngoài ra, proto cung cấp hỗ trợ tuyệt vời cho việc xác định các tùy chọn tùy chỉnh mà chúng tôi tận dụng để thu thập siêu dữ liệu bổ sung, chẳng hạn như quyền sở hữu, lưu giữ, kênh phần mềm năng suất và lược đồ sự kiện. 

Sau khi chọn ngôn ngữ lược đồ, chúng tôi đã xem xét điều gì sẽ xảy ra khi lược đồ được cập nhật và những cập nhật nào nên được cho phép. Để hỗ trợ số lượng người dùng hạ lưu lớn nhất sử dụng lược đồ đã được công bố, nhóm dữ liệu đã áp dụng chế độ truyền ngược được mô tả tại Schema Registry. Với phương pháp này, việc thêm và xóa nhẹ một trường được cho phép. Điều này cho phép thay đổi lược đồ mà không cần phối hợp với người dùng hạ lưu. 

Trong ví dụ trên, chúng tôi có thể thêm và xóa một trường bằng cách cập nhật tệp proto.

Các lược đồ mang lại nhiều lợi ích, nhưng việc yêu cầu chúng ngay từ đầu gây ra sự cản trở. Các nhà khoa học dữ liệu và kỹ sư cần phải hành động nhanh chóng và lặp lại quy trình mà không gặp trở ngại. Để hỗ trợ điều này, chúng tôi đã giới thiệu một kho lưu trữ lược đồ tập trung và xây dựng một bộ công cụ để việc soạn thảo lược đồ trở nên tự động và hiệu quả nhất có thể. 

Ví dụ, chúng tôi đã xây dựng một công cụ kiểm tra cú pháp Proto tùy chỉnh để xác minh rằng mỗi sơ đồ có đầy đủ metadata cần thiết và tuân thủ các quy ước của Roblox. Chúng tôi cũng đã phát triển một plugin Proto để chuyển đổi sơ đồ sự kiện sang ngôn ngữ định nghĩa dữ liệu Hive, đảm bảo bảng Hive tương ứng luôn đồng bộ mỗi khi sơ đồ được tạo hoặc cập nhật. Tất cả các công cụ này được tích hợp vào quy trình CI/CD và chạy tự động khi có yêu cầu kéo (pull request). Điều này cho phép các kỹ sư phát hiện sớm các vấn đề về sơ đồ và kiểm tra sự kiện trong các bảng Hive thử nghiệm trước khi sơ đồ được hợp nhất. Kết quả là, việc triển khai sơ đồ lên môi trường sản xuất đơn giản như việc hợp nhất. 

Với trải nghiệm phát triển được tối ưu hóa, chúng tôi đã xem xét vị trí nào trong quy trình nhập liệu sự kiện nên được định nghĩa lược đồ và chuyển đổi sang proto. Yêu cầu các nhà sản xuất sự kiện áp dụng và gửi dữ liệu proto đã được serialize sẽ là một thay đổi lớn ảnh hưởng đến nhiều đội ngũ. Để giải quyết các điểm khó khăn và mang lại giá trị theo từng bước, chúng tôi đã tách biệt nỗ lực định nghĩa lược đồ khỏi các nhà sản xuất sự kiện bằng cách cập nhật dịch vụ backend nhập liệu để chuyển đổi các sự kiện đến thành proto. Giờ đây, các sự kiện đã được chuyển đổi được thu thập vào các tệp parquet, tải lên bộ lưu trữ phân tán và đăng ký dưới dạng các bảng Hive riêng lẻ.

Tiếp theo, chúng tôi tập trung vào chi phí phục vụ các sự kiện phân tích. Trước đây, hệ thống thu thập dữ liệu được xây dựng trên cơ sở hạ tầng đám mây. Các sự kiện phân tích được gửi đến dịch vụ hàng đợi, nơi chúng được lưu trữ tạm thời và sau đó được lưu trữ trong bộ nhớ đám mây bền vững để xử lý và phân tích ở các giai đoạn tiếp theo. Mặc dù dịch vụ hàng đợi đám mây đã đơn giản hóa dịch vụ của chúng tôi và cho phép mở rộng quy mô một cách minh bạch, nhưng nó khó sử dụng cho các công việc truyền phát khác và tốn kém hơn. Để giải quyết vấn đề này, chúng tôi đã xem xét việc đưa dịch vụ thu thập dữ liệu vào các trung tâm dữ liệu của Roblox. 

Đội ngũ lưu trữ nội bộ của chúng tôi đã xây dựng dịch vụ hàng đợi như một dịch vụ (QaaS), dựa trên nền tảng phát trực tuyến sự kiện phân tán mã nguồn mở. QaaS là sự thay thế tuyệt vời cho việc thu thập sự kiện phân tích vì các sự kiện được xử lý theo thứ tự vào trước ra trước (FIFO) và bị xóa sau một khoảng thời gian lưu trữ ngắn. Tại Roblox, chúng tôi tạo một chủ đề chuyên dụng cho mỗi sự kiện được định nghĩa và sử dụng số lượng phân vùng để mở rộng quy mô cho các luồng sự kiện lớn. Đội ngũ dữ liệu cũng đã xây dựng một dịch vụ chuyên dụng để tiêu thụ dữ liệu từ QaaS, tạo các tệp Parquet và tải các tệp này lên lưu trữ đám mây bền vững.

Với QaaS đã được triển khai và dịch vụ chuyên dụng để tạo và lưu trữ tệp Parquet, đội ngũ dữ liệu đã thực hiện ghi thử nghiệm trong sáu tháng để xác minh cả tính chính xác của dữ liệu và khả năng mở rộng. Cuối cùng, sau khi kiểm tra kỹ lưỡng về tính đầy đủ và tính toàn vẹn của dữ liệu, chúng tôi đã thành công trong việc di chuyển quy trình thu thập sự kiện phân tích khỏi dịch vụ hàng đợi đám mây cũ. Đây là một cột mốc quan trọng. Chúng tôi đã loại bỏ chi phí tài nguyên đám mây khỏi quy trình thu thập và giảm đáng kể độ trễ giữa thời điểm sự kiện được kích hoạt và thời điểm sự kiện đó được lưu trữ trong hồ dữ liệu của chúng tôi. Trước đây, chúng tôi có thỏa thuận cấp độ dịch vụ là ba giờ, nhưng thường không đạt được mục tiêu này. Hiện nay, chúng tôi luôn đạt được mức trung bình là 15 phút. 

Điều này cho phép các kỹ sư viết các đường ống xử lý sự kiện thời gian thực dựa trên các sự kiện được cấu trúc hóa bằng cách sử dụng QaaS để hỗ trợ các tính năng an toàn và đề xuất thời gian thực. Chúng tôi cũng đã ra mắt tính năng thu thập dữ liệu thay đổi với cùng một khung cấu trúc hóa và tính năng nhập liệu QaaS, giúp loại bỏ phần lớn việc sao chép toàn bộ cơ sở dữ liệu. Từ phân tích thời gian thực và truyền phát sự kiện đến việc mở ra các trường hợp sử dụng mới, công việc của chúng tôi vẫn tiếp tục khi chúng tôi đổi mới và xây dựng các hệ thống dữ liệu thông minh hơn, nhanh hơn, tiết kiệm chi phí hơn trên quy mô lớn. 

Chúng tôi xin cảm ơn Paul Mou vì những đóng góp quý báu của anh ấy cho công việc này.

^{* Tính đến ba tháng kết thúc vào ngày 31 tháng 3 năm 2025.}