Tạo và áp dụng quy tắc chất lượng trong Ataccama ONE
Bạn đã hiểu quy tắc chất lượng (DQ rule) là gì — giờ tới phần thực hành: làm sao để tạo ra một quy tắc và gắn nó vào dữ liệu của mình. Trang này mô tả luồng khái niệm (không kèm ảnh màn hình) để người mới hình dung được bốn cách tạo quy tắc trong Ataccama ONE, cách gán quy tắc vào đúng chỗ, và vì sao phải kiểm thử trước khi áp rộng cho toàn bộ dữ liệu.
Một quy tắc chất lượng gồm những gì?
Phần tiêu đề “Một quy tắc chất lượng gồm những gì?”Trước khi tạo, hãy nhớ một quy tắc tốt luôn trả lời rõ ba câu hỏi:
- Kiểm tra cái gì? — điều kiện hay biểu thức quyết định một giá trị là hợp lệ hay không hợp lệ. Ví dụ: “số điện thoại phải có 10 chữ số và bắt đầu bằng số 0”.
- Thuộc chiều chất lượng nào? — mỗi quy tắc nên gắn với một chiều chất lượng (dimension): đầy đủ, hợp lệ, chính xác, nhất quán, duy nhất hay kịp thời. Nhờ đó điểm chất lượng cộng dồn đúng theo từng chiều.
- Áp cho dữ liệu nào? — quy tắc sẽ chạy trên một thuộc tính (attribute) cụ thể, hoặc trên mọi dữ liệu mang một thuật ngữ nghiệp vụ (business term).
Giữ ba câu hỏi này trong đầu thì dù tạo quy tắc theo cách nào, bạn cũng không bị lạc.
Bốn cách tạo quy tắc chất lượng
Phần tiêu đề “Bốn cách tạo quy tắc chất lượng”Ataccama ONE cho phép tạo quy tắc theo nhiều cách, từ nhanh-mà-thô đến chi-tiết-mà-mạnh. Chọn cách phù hợp với độ phức tạp của thứ bạn cần kiểm.
Cách 1 — Tạo từ đầu (định nghĩa điều kiện/biểu thức)
Phần tiêu đề “Cách 1 — Tạo từ đầu (định nghĩa điều kiện/biểu thức)”Đây là cách linh hoạt nhất: bạn tự định nghĩa điều kiện hợp lệ bằng một biểu thức. Phù hợp khi quy tắc nghiệp vụ đặc thù, không có sẵn mẫu.
-
Xác định thế nào là hợp lệ bằng lời trước (ví dụ: “mã số thuế doanh nghiệp phải đủ 10 hoặc 13 chữ số, không chứa chữ cái”).
-
Chuyển điều kiện đó thành biểu thức mà Ataccama hiểu — so khớp định dạng, kiểm độ dài, kiểm khoảng giá trị, hay so sánh giữa các cột.
-
Gắn quy tắc vào một chiều chất lượng để điểm tính đúng nhóm.
-
Đặt tên rõ ràng và mô tả ngắn để người sau hiểu quy tắc kiểm gì.
Cách này mạnh nhưng đòi hỏi bạn diễn đạt logic cho chính xác. Hãy bắt đầu từ một điều kiện đơn giản rồi mở rộng dần.
Cách 2 — Tạo từ gợi ý profiling (rule suggestions)
Phần tiêu đề “Cách 2 — Tạo từ gợi ý profiling (rule suggestions)”Sau khi profiling (soi dữ liệu), Ataccama đã biết khá nhiều về một cột: tỷ lệ rỗng, các mẫu định dạng phổ biến, khoảng giá trị, giá trị lạ. Từ đó hệ thống có thể gợi ý quy tắc sẵn — bạn chỉ việc xem, chọn và tinh chỉnh.
- Ưu điểm: nhanh. Bạn không phải viết biểu thức từ con số không; gợi ý đã dựa trên dữ liệu thật.
- Cách dùng đúng: coi gợi ý là điểm khởi đầu, không phải chân lý. Máy gợi ý theo những gì nó thấy, nên đôi khi quá rộng (chấp nhận cả giá trị bạn muốn loại) hoặc quá hẹp. Luôn đọc lại và sửa cho khớp nghiệp vụ trước khi áp.
Đây là cách lý tưởng cho người mới: đi nhanh, học bằng cách quan sát quy tắc mẫu, rồi điều chỉnh.
Cách 3 — Dùng lookup (đối chiếu danh sách giá trị hợp lệ)
Phần tiêu đề “Cách 3 — Dùng lookup (đối chiếu danh sách giá trị hợp lệ)”Khi tính hợp lệ phụ thuộc vào một danh sách giá trị cho phép, hãy dùng lookup: quy tắc sẽ đối chiếu mỗi giá trị với danh sách đó, có trong danh sách thì hợp lệ, không có thì đánh dấu lỗi.
Rất hợp với dữ liệu kiểu danh mục, ví dụ ở Việt Nam:
- Danh sách 63 tỉnh/thành hợp lệ — bắt các bản ghi ghi sai tên tỉnh.
- Danh mục mã ngành nghề kinh doanh hợp lệ.
- Bộ mã chi nhánh / mã kho nội bộ được phép dùng.
Điểm hay của lookup là khi danh sách thay đổi (thêm chi nhánh mới), bạn cập nhật danh sách một chỗ thay vì sửa từng quy tắc.
Cách 4 — Dùng component (tái sử dụng logic)
Phần tiêu đề “Cách 4 — Dùng component (tái sử dụng logic)”Khi một mảnh logic được dùng đi dùng lại — ví dụ “chuẩn hóa số điện thoại” hay “kiểm tra email đúng định dạng” — bạn có thể đóng gói nó thành component rồi tái sử dụng trong nhiều quy tắc.
- Vì sao nên dùng: tránh chép-dán logic khắp nơi. Khi quy ước thay đổi, bạn sửa component một lần, mọi quy tắc dùng nó đều cập nhật theo.
- Khi nào dùng: logic phức tạp, lặp lại, hoặc cần đồng nhất giữa nhiều bộ phận. Đây là cách làm “bài bản” cho tổ chức có nhiều quy tắc.
Gán quy tắc vào đâu: thuộc tính hay thuật ngữ nghiệp vụ?
Phần tiêu đề “Gán quy tắc vào đâu: thuộc tính hay thuật ngữ nghiệp vụ?”Tạo xong, quy tắc chỉ phát huy tác dụng khi được gán vào dữ liệu. Có hai cách gán, và lựa chọn này quan trọng hơn nhiều người mới nghĩ.
- Gán vào một thuộc tính (attribute): quy tắc chạy đúng trên một cột của một bảng cụ thể. Phù hợp khi nhu cầu cục bộ, chỉ áp cho dữ liệu đó.
- Gán vào một thuật ngữ nghiệp vụ (business term): đây là cách mạnh nhất của Ataccama. Khi bạn gán quy tắc cho một thuật ngữ như “Email khách hàng”, quy tắc sẽ tự động áp cho MỌI cột trong toàn hệ thống được gắn thuật ngữ đó — bất kể nằm ở bảng nào, nguồn nào.
Ví dụ: bạn định nghĩa quy tắc kiểm email đúng định dạng và gán cho thuật ngữ “Email khách hàng”. Cột email trong CRM, trong hệ thống bán hàng, trong file nhập từ đối tác — tất cả đều được kiểm cùng một chuẩn mà bạn không phải gán thủ công từng nơi. Đây chính là điểm khiến quy tắc trở thành tài sản dùng chung thay vì việc làm thủ công lặp lại, và là cầu nối trực tiếp giữa chất lượng dữ liệu với governance.
Kiểm thử trước khi áp rộng
Phần tiêu đề “Kiểm thử trước khi áp rộng”Đừng bao giờ gán một quy tắc mới cho toàn bộ dữ liệu rồi mới xem kết quả. Hãy kiểm thử trên một mẫu trước:
-
Chạy quy tắc trên một tập nhỏ hoặc một bảng đại diện.
-
Xem bản ghi mà quy tắc đánh là lỗi — chúng có thật sự sai không? Nếu thấy bản ghi đúng bị báo lỗi, quy tắc đang quá chặt.
-
Ngược lại, kiểm vài bản ghi mà quy tắc cho là hợp lệ — có lọt giá trị xấu nào không? Nếu có, quy tắc đang quá lỏng.
-
Tinh chỉnh biểu thức/điều kiện, chạy lại, cho tới khi quy tắc bắt đúng cái cần bắt.
-
Khi đã ổn, mới gán rộng (theo thuộc tính hoặc thuật ngữ) và đưa vào giám sát.
Kiểm thử với bản ghi lỗi thật là cách nhanh nhất để biết quy tắc của bạn có đáng tin không.
Các lỗi hay gặp
Phần tiêu đề “Các lỗi hay gặp”- Quy tắc quá chặt: báo lỗi cả những bản ghi vốn hợp lệ → người dùng mất niềm tin, bỏ qua cảnh báo, điểm chất lượng tụt một cách giả tạo.
- Quy tắc quá lỏng: dữ liệu xấu vẫn lọt qua, điểm đẹp nhưng không phản ánh thực tế — nguy hiểm vì tạo cảm giác an toàn ảo.
- Quên gắn chiều chất lượng: điểm không cộng đúng nhóm, báo cáo theo chiều mất ý nghĩa.
- Không kiểm thử mà áp ngay toàn bộ: phát hiện quy tắc sai sau khi nó đã chấm điểm cho hàng triệu bản ghi, tốn công làm lại.
- Chép-dán logic thay vì dùng component/lookup: khi quy ước đổi, phải sửa rải rác nhiều nơi, dễ sót.
- Gán vào thuộc tính trong khi nên gán vào thuật ngữ: bỏ lỡ sức mạnh tái sử dụng, biến việc đáng-lẽ-làm-một-lần thành làm thủ công khắp nơi.
Tiếp theo
Phần tiêu đề “Tiếp theo”- Quy tắc chất lượng (DQ rules): khái niệm & cách hoạt động — nền tảng trước khi bắt tay tạo.
- Đánh giá chất lượng & xem bản ghi lỗi — cách đọc kết quả và bản ghi không hợp lệ để tinh chỉnh quy tắc.
- Điểm chất lượng & cách Ataccama tính — từ kết quả quy tắc thành điểm theo từng chiều và toàn tài sản.