Data Mesh at Grab (Part II): The foundational tools behind certification

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

Phần 2 của series Data Mesh. Phần 1: Grab 2025 (tổ chức, chỉ số); phần 3: Grab 2026 (DPI).

Bối cảnh

Phần 1 đặt nguyên tắc (sở hữu, hợp đồng, chứng nhận). Theo Grab, văn hoá chỉ đổi khi công cụ đổi thói quen hằng ngày, nên phần này kể ba nền tảng làm việc chứng nhận chạy được trên hàng trăm nghìn dataset, stream, thuộc tính và metric.

Xây trên DataHub mã nguồn mở, dùng từ 2022, mở rộng nhiều nhưng liên tục rebase lên bản mới của upstream thay vì fork hẳn.
Có search, domain và chủ sở hữu, hợp đồng và tài liệu dạng metadata có cấu trúc, lineage tới mức cột và metric (trả lời "đổi cái này thì gãy gì"), và trạng thái chứng nhận (dấu tick xanh, xem được tiêu chí nào đạt, tiêu chí nào thiếu).
Metadata vào bằng hai đường: hệ nguồn đẩy khi có thay đổi, hoặc job Airflow kéo định kỳ. Mọi thay đổi được phát lên Kafka thành event (change log mức thấp cho indexer và audit, event ngữ nghĩa mức cao cho workflow).
Chứng nhận được tính, không gán tay: một engine dựa trên DataHub Actions nghe event metadata và tính lại trạng thái mỗi khi có thay đổi. Bốn trạng thái: Uncertified, Certified, CertifiedPlus (cả tài sản lẫn mọi upstream đều đạt), Revoked. Tài sản mất chứng nhận thì các tài sản phía dưới được tính lại. Lịch sử chứng nhận lưu dạng time-series.
Tiêu chí: có domain và chủ; có tài liệu; có lineage và upstream đáng tin (với CertifiedPlus); có hợp đồng kèm test bắt buộc (độ tươi, khối lượng, schema, kiểm tra nghiệp vụ); không vi phạm chính sách (ví dụ thiếu phân loại dữ liệu nhạy cảm).

Test theo bốn trụ: độ tươi, đầy đủ/khối lượng (so với mốc lịch sử hoặc nguồn), ổn định schema, giá trị hợp lệ (unique, khoảng, đối chiếu chéo bảng, phát hiện bất thường số dòng và tỉ lệ null).
Điều phối bằng Temporal, phát kết quả qua Kafka.
Sync with Pipeline (SWP): trước đây test chạy theo cron riêng, team phải tự chép cron của pipeline và tính offset để trỏ đúng batch, nên test hay chạy sớm, muộn hoặc nhầm batch, sinh alert nhiễu và DPI báo sai. Nay Genchi nghe event từ Lighthouse (dịch vụ theo dõi lần chạy Airflow: bắt đầu, xong, khoảng dữ liệu) và chạy test ngay khi pipeline xong, trên đúng lát dữ liệu đó. Độ tươi của pipeline là loại chạy riêng: theo lịch của pipeline, báo khi chạy quá thời gian dự kiến.

Nơi giữ hợp đồng (bảng data lake, stream Kafka, metric). Chỉ tài sản có hợp đồng hợp lệ mới được chứng nhận; Kinabalu (điều phối vòng đời sự cố) dùng hợp đồng để mở và giao DPI; Ouroboros (quản lý vòng đời bảng) đọc điều khoản thời gian lưu.
Khi hợp đồng đổi (schema, SLA độ tươi mới, sắp khai tử), registry tìm đúng người bị ảnh hưởng (chủ của bảng phía dưới, người query nhiều, phụ thuộc sâu với tài sản quan trọng) và nhắn Slack có mục tiêu.
Hợp đồng là JSON (lấy cảm hứng từ Data Contract Specification công khai), chỉ chứa tham chiếu tới quy tắc (id + version + health URL), không chép cấu hình test. Mỗi quy tắc có một URL sức khoẻ, nên Kinabalu xác định vi phạm bằng cách gọi URL thay vì tự định nghĩa "khoẻ" là gì (ví dụ test đầy đủ chỉ khoẻ khi N ngày gần nhất đều đủ, không chỉ lần chạy cuối pass).

Theo Grab, sau một năm (từ 2024) số bảng P80 giảm hơn 58% (cùng số liệu với phần 1).

Metadata đổi nhanh hơn tổ chức (bảng dời chỗ, pipeline viết lại, domain đổi), nên chứng nhận phải tự tính lại theo event, không thể rà tay định kỳ.

Trạng thái dẫn xuất nên được tính từ event, không gán tay: chứng nhận ở đây giống một view materialized trên luồng metadata, có lan truyền xuống phía dưới khi upstream hỏng (Event-driven, message queue và Kafka).
Test chất lượng dữ liệu phải gắn với lần chạy thật của pipeline, không đoán bằng cron. Đây là cùng bài học "alert nhiễu đến từ tín hiệu xấp xỉ" trong giám sát dịch vụ (Pipeline dữ liệu và analytics).
Hợp đồng giữ tham chiếu thay vì chép cấu hình giúp tránh lệch giữa các hệ; "khoẻ" được định nghĩa bởi hệ sở hữu quy tắc, qua một URL.
Dùng nền tảng mã nguồn mở nhưng rebase liên tục là cách mở rộng mà không thành fork phải tự nuôi.