Monitoring Projects: giám sát chất lượng dữ liệu theo thời gian

Đo chất lượng dữ liệu một lần chỉ cho bạn một bức ảnh chụp tại một thời điểm. Nhưng dữ liệu thì thay đổi mỗi ngày: hệ thống nguồn cập nhật, người dùng nhập thêm bản ghi, một quy trình ETL âm thầm hỏng. Trang này dành cho người mới, giải thích cách Ataccama ONE dùng Monitoring Projects để biến phép đo một lần thành một camera giám sát chạy liên tục — chấm điểm chất lượng theo lịch hoặc tức thời, báo cáo kết quả, và “gõ cửa” đúng người ngay khi chất lượng tụt dốc.

Vì sao phải giám sát chất lượng liên tục

Hãy hình dung bạn vừa làm sạch xong bảng khách hàng: 98 phần trăm bản ghi đạt, mọi người vỗ tay. Ba tháng sau, một tích hợp mới đổ dữ liệu từ chi nhánh khác vào — định dạng số điện thoại khác, thiếu mã số thuế. Điểm chất lượng tụt xuống 80 phần trăm, nhưng không ai biết, vì không ai chạy lại phép đo.

Đó là vấn đề cốt lõi: chất lượng dữ liệu không đứng yên. Nếu chỉ đo theo kiểu thủ công, thi thoảng mới chạy, thì:

Lỗi tích tụ âm thầm trong nhiều tuần, đến khi người dùng cuối phát hiện sự cố (báo cáo lệch, đơn giao nhầm) thì đã muộn và tốn kém để truy ngược.
Không ai biết chất lượng đang tốt lên hay xấu đi — vì không có chuỗi số liệu theo thời gian để so sánh.
Sự cố trở thành “chữa cháy” thay vì được phát hiện sớm và xử lý gọn.

Monitoring Projects đảo ngược thế trận: thay vì con người phải nhớ đi kiểm tra dữ liệu, hệ thống tự kiểm tra và chủ động báo cho con người. Triết lý ở đây giống camera an ninh — bạn không cần ngồi nhìn màn hình 24/7, chỉ cần được báo động khi có chuyện.

Monitoring Project là gì?

Một Monitoring Project (dự án giám sát) là một “gói công việc giám sát” mà bạn cấu hình một lần rồi để nó chạy lặp lại. Trong gói đó bạn khai báo ba thứ chính:

Giám sát cái gì — chọn các tài sản quan trọng: những bảng, cột, tập dữ liệu mà doanh nghiệp thật sự dựa vào để ra quyết định (bảng khách hàng, bảng giao dịch, danh mục sản phẩm…). Không phải mọi thứ đều cần giám sát chặt — bạn chủ đích chọn cái đáng giá.
Đo bằng cách nào — gắn các quy tắc chất lượng (DQ rules) và chiều chất lượng cần kiểm; mỗi lần chạy sẽ chấm lại điểm chất lượng (DQ score).
Chạy khi nào — đặt lịch (mỗi đêm, mỗi tuần) hoặc chạy tức thời (on-demand) khi cần kiểm gấp sau một đợt nạp dữ liệu lớn.

Điểm hay là tài sản nào đã được giám sát thì kết quả mới nhất hiển thị thẳng trong danh mục dữ liệu (catalog) — người dùng mở bảng ra là thấy ngay điểm chất lượng hiện tại, không cần đi tìm.

Chạy theo lịch hay tức thời

Hai chế độ chạy phục vụ hai tình huống khác nhau:

Theo lịch (scheduled): phù hợp cho giám sát thường xuyên, ổn định. Ví dụ cho bảng giao dịch ngân hàng chạy lúc 2 giờ sáng mỗi ngày — sau khi pipeline đêm nạp xong, trước giờ làm việc. Sáng ra đội dữ liệu đã có kết quả tươi mới.
Tức thời (on-demand): chạy ngay khi bạn cần. Ví dụ vừa migrate dữ liệu từ hệ thống cũ sang, bạn muốn kiểm chất lượng ngay lập tức thay vì chờ tới đêm.

Trong thực tế, doanh nghiệp thường dùng cả hai: lịch định kỳ làm xương sống, và tức thời cho các thời điểm rủi ro cao (sau sáp nhập dữ liệu, sau khi sửa quy tắc lớn).

Kết quả và báo cáo

Mỗi lần Monitoring Project chạy, nó tạo ra một kết quả (result) — về bản chất là một báo cáo chất lượng tại thời điểm đó, gồm:

Điểm chất lượng tổng và điểm theo từng chiều chất lượng (đầy đủ, hợp lệ, chính xác…).
Quy tắc nào đạt / không đạt, bao nhiêu bản ghi vi phạm.
Truy cập tới bản ghi lỗi (invalid samples) để xem cụ thể dòng nào sai và sai ở đâu.

Vì các lần chạy được lưu lại theo thời gian, bạn không chỉ thấy “hôm nay tốt hay xấu” mà thấy xu hướng: đường điểm chất lượng đang đi lên hay đang dốc xuống. Đây chính là cái biến giám sát từ “báo động đơn lẻ” thành “công cụ quản trị” — bạn chứng minh được với lãnh đạo rằng chất lượng dữ liệu đang cải thiện qua từng quý.

Thông báo (notification): để hệ thống tự gõ cửa

Báo cáo đẹp đến mấy mà không ai mở ra xem thì cũng vô ích. Vì vậy phần quan trọng nhất của giám sát là thông báo — khi kết quả vượt ngưỡng bạn đặt (ví dụ điểm chất lượng tụt dưới 90 phần trăm, hoặc số bản ghi lỗi vượt mốc), hệ thống chủ động báo ngay.

Ataccama ONE gửi thông báo qua nhiều kênh quen thuộc:

Email — phù hợp cho cảnh báo cần lưu vết, gửi tới data steward hoặc trưởng nhóm dữ liệu.
Microsoft Teams — đẩy thẳng vào kênh chat của đội, ai cũng thấy ngay.
Slack — tương tự, hợp với các đội đã quen làm việc trên Slack.

Cách làm này khớp với thực tế nhiều doanh nghiệp Việt Nam: đội dữ liệu sống trong group chat cả ngày. Một cảnh báo “Điểm chất lượng bảng khách_hàng vừa tụt còn 82 phần trăm” hiện ngay trong kênh Teams sẽ được xử lý nhanh hơn nhiều so với một email lọt thỏm giữa hàng trăm email khác. Bạn nên đặt ngưỡng cảnh báo vừa đủ nhạy — quá nhạy thì nhiễu (báo động giả liên tục, đội bắt đầu phớt lờ), quá ít nhạy thì bỏ sót sự cố thật.

Retention: lưu lịch sử bao lâu

Retention (chính sách lưu giữ) quyết định bạn giữ lịch sử kết quả giám sát trong bao lâu trước khi hệ thống dọn bớt. Đây tưởng là chuyện kỹ thuật nhỏ nhưng lại quan trọng:

Giữ đủ dài thì mới phân tích được xu hướng dài hạn (“chất lượng có theo mùa không?”, “đợt nào sạch nhất trong năm?”) và phục vụ kiểm toán / tuân thủ — nhiều quy định yêu cầu chứng minh được dữ liệu đã được kiểm soát liên tục.
Giữ quá nhiều thì tốn dung lượng lưu trữ một cách không cần thiết.

Lời khuyên cho người mới: cân nhắc retention theo nhu cầu nghiệp vụ và yêu cầu tuân thủ của riêng bạn, đừng để mặc định mà chưa nghĩ tới. Với dữ liệu nhạy cảm (tài chính, khách hàng), khả năng truy lại lịch sử chất lượng nhiều tháng thường là yêu cầu bắt buộc.

Lỗi hay gặp khi mới triển khai giám sát

Giám sát quá nhiều thứ một lúc — gắn DQ rule cho mọi bảng ngay từ đầu, kết quả là một biển cảnh báo không ai đọc nổi. Hãy bắt đầu từ vài tài sản quan trọng nhất.
Đặt ngưỡng sai dẫn tới báo động giả triền miên, đội mất niềm tin và tắt thông báo. Tinh chỉnh ngưỡng theo thực tế dữ liệu.
Không gắn thông báo với người chịu trách nhiệm rõ ràng — cảnh báo bay vào một kênh chung không ai sở hữu thì cũng như không có.

Data Observability — giám sát tự động toàn nguồn Khác Monitoring Projects ở chỗ tự động quét cả nguồn dữ liệu bằng bộ quy tắc đóng gói sẵn, bắt cả schema drift.

Phát hiện bất thường bằng AI (Anomaly Detection) — bổ sung cho giám sát: bắt những bất thường mà quy tắc cứng bỏ sót.
Đánh giá chất lượng & xem bản ghi lỗi (đang cập nhật) — hiểu kết quả mỗi lần chạy giám sát đến tận từng dòng dữ liệu sai.