Migrating Data Ingestion Systems at Meta Scale

Bài tóm tắt Meta 2026 4. Điều chỉnh Độ khó: Nâng cao

Meta · 2026 · 4. Điều chỉnh · Độ khó: Nâng cao — bài gốc

Bối cảnh

  • Mỗi ngày, hệ ingestion của Meta cào tăng dần vài petabyte dữ liệu social graph từ MySQL (một trong những cụm MySQL lớn nhất thế giới) vào data warehouse để phục vụ analytics và training model.
  • Hệ cũ gồm các pipeline do từng team khách hàng sở hữu: chạy tốt ở quy mô nhỏ, nhưng mất ổn định khi yêu cầu về thời điểm dữ liệu có mặt (landing time) ngày càng chặt.
  • Hệ mới là một dịch vụ do data warehouse tự quản.
  • Hai hệ đều dùng CDC: một bảng full dump, một bảng delta và bảng đích. Dữ liệu đã land được dùng để sinh dữ liệu mới, nên lỗi lan truyền sang các lần sau.

Thay đổi chính

  • Tiêu chí chuyển giai đoạn cho từng job:
    • không lệch dữ liệu (so số dòng và checksum);
    • landing latency không tệ hơn;
    • tài nguyên dùng không tệ hơn;
    • bảng quan trọng có thêm tiêu chí riêng do team phụ thuộc đặt ra.
  • Ba pha:
    1. Shadow: job mới đọc cùng nguồn, ghi vào bảng shadow; liên tục so số dòng và checksum, sửa lỗi ở pre-production; đo quota compute/storage trước khi lên production.
    2. Reverse shadow: đảo vai. Job mới ghi bảng production, job cũ ghi bảng shadow. Vẫn có tín hiệu so sánh sau rollout, và rollback ngay mà không phải dựng lại job cũ.
    3. Dọn dẹp: không còn lệch thì bỏ job cũ.
  • Tín hiệu sớm: sau rollout chạy backfill trên cả hai job; lệch thì rollback trước khi người dùng dữ liệu bị ảnh hưởng.
  • Chặn lỗi lan truyền: partition lỗi được đánh dấu trong metadata.
    • Partition delta lỗi: dừng land và báo động.
    • Partition đích lỗi: lấy partition cũ hơn rồi merge thêm delta.
    • Khi rollback: truy metadata để tìm và backfill mọi partition bị đánh dấu.
  • Tự động hoá cho hàng chục nghìn job: job gửi trạng thái lên Scuba; công cụ ngoài tự thăng/hạ giai đoạn theo tiêu chí; có dashboard cấp hệ thống và cấp job.
  • Năng lực có hạn nên chạy theo lô:
    • phân loại job theo throughput, độ ưu tiên;
    • không tạo shadow job khi còn lỗi đã biết, vì mỗi lần tạo hoặc sửa đều phải full dump (đắt);
    • dùng lại snapshot của hệ cũ làm snapshot đầu.

Kết quả

Đã chuyển 100% workload và gỡ hẳn hệ cũ. Công cụ so chất lượng dữ liệu được giữ lại làm bước kiểm tra mỗi lần release.

Bài học cho SWE

  • Reverse shadow là bước nên có sau shadow: đảo vai để vẫn so được và rollback ngay.
  • Với pipeline có trạng thái nối tiếp (CDC), rủi ro lớn nhất là lỗi lan truyền; cần đánh dấu partition hỏng và cơ chế cầm máu.
  • Migration hàng chục nghìn đơn vị cần máy trạng thái tự động (tiêu chí → thăng/hạ), giống migrator service của Monzo (Monzo 2022).
  • Pipeline do từng team sở hữu hợp lúc nhỏ; lớn lên thì gom về một dịch vụ do nền tảng quản lý.

Liên quan