Pipeline Lakeflow có kiểm soát chất lượng dữ liệu: chặn, cách ly và chứng minh
Dữ liệu sai thường chỉ bị phát hiện khi đã lên báo cáo. Cách dùng expectations, bảng cách ly và event log để chặn sớm và có bằng chứng.
Phần lớn sự cố dữ liệu không bắt nguồn từ lỗi hệ thống mà từ những bản ghi sai lọt qua pipeline: một giao dịch thiếu mã tài khoản, một ngày hạch toán nằm trong tương lai, một lần tải bị thiếu một nửa số dòng. Khi bộ phận nghiệp vụ phát hiện con số trên báo cáo bất thường, dữ liệu sai đã đi qua ba tầng xử lý và được nhiều báo cáo khác sử dụng.
Pipeline có kiểm soát chất lượng phải trả lời được ba câu hỏi: bản ghi sai bị chặn ở đâu, ai được biết và biết khi nào, và khi cơ quan kiểm toán hỏi thì bằng chứng nằm ở đâu. Bài viết này trình bày cách thực hiện trên Lakeflow Spark Declarative Pipelines, công cụ xây dựng pipeline của Databricks.
1. Ba cách xử lý bản ghi không hợp lệ
Trên Lakeflow, quy tắc chất lượng được khai báo ngay trong định nghĩa bảng dưới dạng expectation: một tên, một điều kiện SQL trả về đúng hoặc sai cho từng bản ghi, và một hành động khi điều kiện không thoả mãn.
| Hành động | Cú pháp SQL | Kết quả |
|---|---|---|
| Cảnh báo (mặc định) | EXPECT |
Bản ghi vẫn được ghi vào bảng đích, số bản ghi đạt và không đạt được thống kê |
| Loại bỏ | EXPECT ... ON VIOLATION DROP ROW |
Bản ghi bị loại trước khi ghi, số bản ghi bị loại được thống kê |
| Dừng cập nhật | EXPECT ... ON VIOLATION FAIL UPDATE |
Lần cập nhật bị huỷ và hoàn tác, cần xử lý thủ công trước khi chạy lại |
Một bảng giao dịch ở tầng Silver có thể kết hợp cả ba:
CREATE OR REFRESH STREAMING TABLE silver_transactions(
CONSTRAINT valid_account EXPECT (account_id IS NOT NULL) ON VIOLATION DROP ROW,
CONSTRAINT positive_amount EXPECT (amount > 0),
CONSTRAINT valid_posting_date EXPECT (posting_date <= current_date()) ON VIOLATION FAIL UPDATE
) AS SELECT * FROM STREAM(bronze_transactions);Giao dịch thiếu mã tài khoản không thể quy về khách hàng nào nên bị loại. Giao dịch có số tiền bằng không hoặc âm vẫn được giữ lại nhưng được đếm, để đội ngũ dữ liệu xem xét xu hướng. Một ngày hạch toán trong tương lai cho thấy hệ thống nguồn đang có vấn đề nghiêm trọng, nên pipeline dừng lại thay vì ghi tiếp.
Điều kiện chỉ được dùng cú pháp SQL chuẩn, không gọi hàm Python tự viết, dịch vụ bên ngoài hay truy vấn con tới bảng khác. Quy tắc cần đối chiếu với bảng khác thì dùng bảng kiểm tra ở mục 4.
2. Đặt kiểm tra ở tầng nào
Theo bộ tài liệu triển khai lakehouse của Databricks, mỗi tầng trong kiến trúc medallion có một vai trò riêng, và quy tắc chất lượng nên bám theo vai trò đó:
- Bronze giữ dữ liệu nguyên trạng từ nguồn, kèm cột kiểm toán như ngày nạp và mã lô, để lưu trữ lịch sử và cho phép xử lý lại. Ở tầng này chỉ nên dùng hành động cảnh báo: đo lường chất lượng nguồn mà không làm mất bản gốc.
- Silver là tầng làm sạch: kiểm tra giá trị rỗng, toàn vẹn tham chiếu với bảng khác, loại bản ghi trùng. Phần lớn hành động loại bỏ và cách ly đặt ở đây.
- Gold là dữ liệu tổng hợp phục vụ báo cáo. Ở đây cần các phép kiểm tra trên toàn bảng, như tổng số dòng khớp với tầng trước hay khoá chính không trùng, với hành động dừng cập nhật.
3. Cách ly thay vì loại bỏ
Hành động loại bỏ chỉ để lại một con số: bao nhiêu bản ghi đã bị loại. Với dữ liệu tài chính, như vậy là chưa đủ, vì chuyên viên cần xem từng bản ghi để sửa ở hệ thống nguồn hoặc giải trình.
Databricks mô tả một mẫu cách ly (quarantine): thêm vào bảng trung gian một cột đánh dấu bản ghi không đạt quy tắc, phân vùng bảng theo cột đó, rồi tạo hai view riêng cho bản ghi hợp lệ và bản ghi bị cách ly. Bản ghi hợp lệ đi tiếp vào Silver; bản ghi bị cách ly nằm trong một bảng mà đội ngũ vận hành rà soát hằng ngày. Không bản ghi nào biến mất mà không để lại dấu vết.
4. Chặn tầng phía sau khi kiểm tra thất bại
Đây là điểm dễ hiểu nhầm nhất. Một bảng kiểm tra dùng FAIL UPDATE, chẳng hạn so sánh số dòng giữa hai bảng, sẽ thất bại khi phát hiện sai lệch, nhưng không ngăn các bảng khác trong cùng pipeline tiếp tục cập nhật. Expectations quyết định bản ghi nào được vào bảng, không điều phối thứ tự chạy.
Trong pipeline chạy theo lượt (triggered), một luồng thất bại chỉ hoàn tác luồng đó, các luồng song song vẫn chạy. Trong pipeline chạy liên tục (continuous), luồng thất bại dừng cùng mọi luồng phụ thuộc.
Muốn báo cáo không bao giờ được cập nhật từ dữ liệu chưa qua kiểm tra, cách làm được Databricks khuyến nghị là tách phần kiểm tra và phần phía sau thành hai pipeline, rồi điều phối bằng một job, trong đó bước phía sau chỉ chạy khi bước kiểm tra thành công.
5. Theo dõi và bằng chứng
Mọi kết quả kiểm tra được ghi vào event log của pipeline: số bản ghi đạt và không đạt theo từng expectation, số bản ghi bị loại, cùng với tiến độ, lineage và thao tác của người dùng trên pipeline. Databricks khuyến nghị truy vấn qua bảng hệ thống pipeline_events, chứa sự kiện của mọi pipeline trong cùng vùng (hiện ở giai đoạn Beta). Nhờ đó, câu hỏi “tháng trước có bao nhiêu giao dịch bị cách ly và vì sao” được trả lời bằng một truy vấn, không phải bằng một báo cáo soạn tay.
Expectations chỉ kiểm tra dữ liệu đi qua pipeline. Để phát hiện một bảng ngừng cập nhật hoặc nhận ít dòng hơn bình thường, Databricks có tính năng Data Quality Monitoring: phần anomaly detection học lịch sử của từng bảng để dự đoán thời điểm cập nhật tiếp theo và số dòng dự kiến trong 24 giờ, rồi đánh dấu bảng bị trễ hoặc thiếu dữ liệu. Tính năng này chạy trên serverless và được tính phí riêng, nên cần đưa vào dự toán chi phí.
Sancire làm gì trong việc này
Trong giai đoạn Hiện đại hoá, Sancire dựng pipeline với quy tắc chất lượng theo từng tầng, bảng cách ly cho bản ghi lỗi và biên bản đối soát với hệ thống nguồn cho mỗi đợt chuyển đổi. Gói Chuyển đổi kéo dài 4 đến 6 tuần mỗi đợt, giá từ 12.000 USD mỗi đợt. Nếu doanh nghiệp đang gặp tình trạng số liệu trên báo cáo không khớp với hệ thống nguồn, buổi khảo sát 90 phút là điểm bắt đầu phù hợp.
Nguồn: tài liệu Databricks về expectations, các mẫu kiểm tra nâng cao, event log của pipeline và Data Quality Monitoring (cập nhật ngày 11/9 và 21/9/2026, tra cứu ngày 29/9/2026). Tài liệu Databricks về quản lý chất lượng dữ liệu bằng expectations và về phát hiện bất thường trong Data Quality Monitoring. Tên và trạng thái tính năng thay đổi nhanh; cần đối chiếu tài liệu hiện hành trước khi thiết kế.