Data Mesh at Grab (Part III): Operationalizing data reliability with automated DPIs

Grab · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Phần 3 của series Data Mesh; hai phần trước (Signals Marketplace, công cụ chứng nhận) chưa có trong wiki.

Bối cảnh

• Grab chuyển từ một đội Data Engineering trung tâm sang data mesh: các team tự publish data product, được chứng nhận (chủ sở hữu, tài liệu, lineage, kiểm chất lượng) qua Hubble (metadata, lineage), Genchi (quan sát chất lượng dữ liệu) và Data Contract Registry (hợp đồng có phiên bản giữa producer và consumer: schema, độ tươi, độ đầy đủ).
• Chứng nhận không ngăn được lỗi lúc chạy: bảng đến trễ, metric hỏng vì dependency, stream Kafka vi phạm độ tươi.

Thay đổi chính

• Data Production Issue (DPI): biến tín hiệu chất lượng thành một quy trình sự cố, thiết kế tự động từ đầu, ít người can thiệp. Orchestrator sự cố Kinabalu chỉ hỏi "test của hợp đồng có khoẻ không" qua Test Health API, không cần biết từng nền tảng tính độ tươi ra sao.
• Triage: alert của nền tảng (Airflow trễ, test lỗi, job chết) chưa phải DPI; chỉ vi phạm hợp đồng mới thành DPI. Phân biệt một lần chạy test với sức khoẻ của test: test đầy đủ của partition T-1 hỏng hai ngày trước vẫn tính là chưa khoẻ tới khi partition đó được backfill và kiểm lại. Khử trùng: tín hiệu mới cập nhật DPI đang mở; DPI cùng nguyên nhân được gom.
• Chẩn đoán và giao chủ: Data Health API với phân loại lỗi nhỏ có chủ ý: UPSTREAM_ERROR, PLATFORM_ERROR, JOB_ERROR, DATA_ERROR. Nền tảng vẫn giữ catalog lỗi chi tiết riêng; orchestrator chỉ tiêu thụ hợp đồng API ổn định. Lỗi upstream thì DPI hạ nguồn được nối vào DPI của upstream và thừa kế chủ sở hữu, không đổ lên chủ bảng hạ nguồn.
• Hugo (nền tảng ingest) chẩn đoán ba tầng: thu tín hiệu → phân loại và chuyển tới bộ chẩn đoán chuyên biệt (ví dụ replica DB nguồn bị trễ) → lưu kết quả kèm cách sửa đề xuất.
• Tự sửa trước, người sau: lỗi thường gặp và phục hồi được (compute bị ngắt, timeout kết nối DB, S3 throttle, upstream chỉ trễ) được xử lý tự động (retry, chờ upstream, resolver riêng), rồi kiểm cả sức khoẻ pipeline lẫn tính đúng của dữ liệu; dữ liệu hỏng, bản ghi sai, lỗi code thì chuyển cho người. Mọi lần thử đều được ghi để audit.
• Kết quả (theo Grab, 2026): 86,9% DPI tự giải quyết; hơn 95% DPI do hệ tự mở; MTTR của DPI tự động nhanh gấp 6 lần DPI do người mở. Thời gian sống của DPI được dùng làm thước đo data downtime.

Vì sao

• Data mesh đẩy quyền sở hữu ra các team; muốn giữ được tin cậy cần một quy trình sự cố chung, đo được, ít nhiễu, không phụ thuộc chi tiết từng nền tảng.

Bài học cho SWE

• Coi dữ liệu như service: hợp đồng (độ tươi, đầy đủ, schema) là SLO, vi phạm hợp đồng mới là sự cố, alert nền tảng chỉ là tín hiệu (Pipeline dữ liệu và analytics).
• Phân loại lỗi thô nhưng ổn định ở tầng điều phối, chi tiết để lại cho từng nền tảng; nhờ đó tự giao đúng chủ (Xử lý sự cố và on-call).
• Auto-remediation chỉ cho lớp lỗi đã hiểu, luôn kiểm lại kết quả, phần còn lại giao người (Tự động hoá vận hành và auto-remediation).
• So với LinkedIn 2019 (2019): cùng hướng đo theo dataset thay vì pass/fail của job, Grab đi thêm tới vòng đời sự cố và tự sửa.

Liên quan

• Cùng công ty: Grab 2016 · Grab 2017 · Grab 2018 · Grab 2019 · Grab 2022 · Grab 2022 · Grab 2024 · Grab 2025 · Grab 2026
• Pipeline dữ liệu và analytics · Tự động hoá vận hành và auto-remediation · Xử lý sự cố và on-call