Giám sát chất lượng dữ liệu: từ dbt test đến anomaly detection cho pipeline phân tích

Một pipeline ELT chạy xanh mỗi sáng — DAG hoàn thành, không có task nào fail — dễ tạo cảm giác an toàn giả. Nhưng "chạy xong" và "dữ liệu đúng" là hai việc khác nhau: một job có thể hoàn thành thành công trong khi nạp 0 dòng vì API nguồn đổi định dạng response, hoặc nạp đủ dòng nhưng với một cột bị shift sai do thay đổi schema không được thông báo. Phát hiện những lỗi này thường đến muộn — khi ai đó hỏi tại sao doanh thu trên dashboard giảm 90% qua đêm — và lúc đó dữ liệu sai đã lan vào báo cáo, có thể đã lan vào quyết định.

Bài viết này mô tả lớp giám sát chất lượng dữ liệu mà chúng tôi thêm vào sau khi pipeline ELT cơ bản đã chạy ổn định (xem bài viết về xây pipeline ELT với dbt và Airflow) — không phải một công cụ riêng cần mua, mà một tập hợp các lớp kiểm tra được thêm dần, từ rẻ và đơn giản đến phức tạp hơn khi cần.

Bốn loại lỗi chất lượng dữ liệu phổ biến nhất

• **Freshness** — dữ liệu trễ so với kỳ vọng. Job vẫn chạy đúng giờ nhưng nguồn đã ngừng cập nhật từ vài ngày trước, nên "dữ liệu mới nhất" trong warehouse thực ra đã cũ
• **Completeness** — thiếu bản ghi. API trả về phân trang nhưng job chỉ lấy trang đầu, hoặc một filter trong query loại bỏ nhầm một nhóm bản ghi hợp lệ
• **Schema drift** — nguồn đổi tên cột, đổi kiểu dữ liệu, hoặc thêm/bỏ field mà không thông báo — phổ biến nhất khi nguồn là một service do team khác hoặc bên thứ ba vận hành
• **Bất thường phân phối (distribution anomaly)** — dữ liệu vẫn đúng cấu trúc, đủ dòng, nhưng giá trị bất thường so với lịch sử: một đơn hàng với số lượng âm, doanh thu một ngày cao gấp 50 lần trung bình do lỗi double-count

Ba loại đầu bắt được bằng test cấu trúc. Loại thứ tư — bất thường phân phối — cần một lớp khác, vì dữ liệu "hợp lệ" về cấu trúc vẫn có thể sai về ý nghĩa kinh doanh.

Lớp test có sẵn trong dbt — điều kiện cần, chưa đủ

dbt test (not_null, unique, relationships, accepted_values, cùng các test tùy biến) là lớp rẻ nhất và nên là lớp đầu tiên trên mọi model staging và mart quan trọng. Chạy trong CI bắt lỗi trước khi merge; chạy lại mỗi lần pipeline production thực thi bắt lỗi dữ liệu thực tế phát sinh sau đó. dbt source freshness — kiểm tra timestamp mới nhất của một nguồn so với ngưỡng kỳ vọng — là phần mở rộng tự nhiên, bắt được loại lỗi "job chạy nhưng nguồn đã im lặng" mà test cấu trúc thông thường bỏ lỡ.

Hạn chế: các test này chỉ biết về cấu trúc và ràng buộc đã khai báo trước — not_null không phát hiện được một cột luôn có giá trị nhưng giá trị đó sai. Một bảng có thể pass 100% test dbt trong khi doanh thu bị tính trùng do một join sai gây nhân bản dòng.

Anomaly detection thống kê — lớp bổ sung cho thứ test cấu trúc không thấy

Lớp tiếp theo giám sát các metric kinh doanh theo thời gian, không phải cấu trúc bảng:

• **Volume check** — so sánh số dòng nạp hôm nay với trung bình động (rolling average) 7 hoặc 14 ngày gần nhất, có biên độ cho phép theo ngày trong tuần (cuối tuần thường ít đơn hàng hơn, đây không phải bất thường)
• **Z-score trên metric chính** — doanh thu, số đơn hàng, số người dùng hoạt động theo ngày — gắn cờ khi giá trị lệch quá N độ lệch chuẩn so với phân phối lịch sử của chính metric đó
• **Ngưỡng động, không phải ngưỡng cứng** — một ngưỡng cố định ("báo nếu < 100 đơn/ngày") nhanh chóng lỗi thời khi business tăng trưởng hoặc có tính mùa vụ; rolling window tự điều chỉnh theo xu hướng gần nhất

Lợi ích thực tế: số đơn hàng giảm 80% so với trung bình 7 ngày được gắn cờ tự động trong vòng vài giờ sau khi pipeline chạy — trước khi một người ở team kinh doanh nhận ra qua báo cáo cuối tuần và hỏi ngược lại team dữ liệu.

Biến lỗi thành tín hiệu có thể hành động — alerting và quality score

Phát hiện lỗi không có giá trị nếu không ai biết để xử lý kịp thời, nhưng alert quá nhiều và thiếu context dẫn đến alert fatigue — đến lúc bị bỏ qua hoàn toàn. Một số nguyên tắc khi định tuyến alert:

• Mỗi alert phải nêu rõ: bảng nào, test/check nào fail, từ khi nào, và mart/dashboard nào phụ thuộc bảng đó — người nhận alert không nên phải tự tra lineage để biết mức độ nghiêm trọng
• Phân loại severity theo tầm ảnh hưởng — lỗi ở một mart đang được nhiều dashboard khách hàng dùng nên route khác (page ngay) so với lỗi ở bảng intermediate nội bộ ít người truy cập (ghi log, xem hàng ngày)
• Tổng hợp toàn bộ kết quả test, freshness, và anomaly check vào một dashboard "quality score" theo bảng/nguồn — cho phép team dữ liệu nhìn thấy xu hướng chất lượng theo thời gian, không chỉ xử lý từng alert đơn lẻ

Nguyên tắc thiết kế: lỗi nên được phát hiện gần nguồn nhất

Đây là phần mở rộng của khái niệm data contract đã đề cập trong bài viết về ELT: một lỗi dữ liệu phát hiện tại staging layer — trước khi lan vào intermediate và mart — rẻ hơn rất nhiều để xử lý so với lỗi phát hiện tại dashboard, vì tại staging chưa có báo cáo nào dựa trên dữ liệu sai. Quy giám sát chất lượng dữ liệu về càng gần nguồn, thời gian từ lúc lỗi xảy ra đến lúc được phát hiện càng ngắn — và đó là chỉ số quan trọng hơn số lượng test đã viết.

Nguyên tắc này áp dụng trực tiếp cho các hệ thống phụ thuộc dữ liệu sạch để ra quyết định tự động, như mô hình dự báo nhu cầu nguyên liệu cho 240 cửa hàng F&B mà chúng tôi đã triển khai — một anomaly không được phát hiện ở dữ liệu đầu vào sẽ lan thành một dự báo sai, rồi thành quyết định nhập hàng sai, trước khi ai nhận ra nguyên nhân gốc nằm ở một ngày dữ liệu lỗi nhiều bước phía trước.

Kết luận

Giám sát chất lượng dữ liệu không cần một công cụ lớn để bắt đầu — dbt test và source freshness đã bắt được phần lớn lỗi vận hành phổ biến với chi phí gần như bằng không. Lớp anomaly detection thống kê là bước tiếp theo khi pipeline đã ổn định và rủi ro chuyển từ "job fail" sang "job chạy nhưng dữ liệu sai về ý nghĩa". Đây là cách chúng tôi tiếp cận giám sát trong lớp Data Analytics của mỗi Pilot Build — không chờ đến khi một con số sai xuất hiện trên dashboard mới biết có vấn đề.