Quy tắc chất lượng (DQ rules): cách Ataccama 'đo' dữ liệu tốt hay xấu

Sau khi đã profiling để hiểu dữ liệu, bước tiếp theo là đo xem dữ liệu tốt hay xấu. Công cụ để đo đó là DQ rule (quy tắc chất lượng). Trang này giải thích cho người mới: quy tắc chất lượng là gì, cho ra kết quả như thế nào, các loại quy tắc, và làm sao một quy tắc có thể dùng lại khắp tổ chức — kèm ví dụ quen thuộc ở doanh nghiệp Việt Nam.

Quy tắc chất lượng là gì?

Nói thật đơn giản: một quy tắc chất lượng là một điều kiện định nghĩa thế nào là dữ liệu hợp lệ. Bạn viết ra mong đợi của mình về dữ liệu, rồi hệ thống kiểm tra từng bản ghi xem có thỏa điều kiện đó không.

Vài ví dụ rất đời thường:

“Email phải đúng định dạng ten@mien.com.”
“Mã số thuế không được rỗng.”
“Ngày sinh phải nằm trong khoảng hợp lý (không phải năm 1850, cũng không phải tương lai).”
“Số tiền đơn hàng phải lớn hơn 0.”

Mỗi quy tắc trả lời một câu hỏi cụ thể về dữ liệu. Gộp nhiều quy tắc lại, bạn biến câu hỏi mơ hồ “dữ liệu có tốt không?” thành điều đo được và theo dõi được theo thời gian.

Kết quả: hợp lệ hay không hợp lệ

Khi chạy một quy tắc trên tập dữ liệu, mỗi bản ghi được gắn một trong hai kết quả: hợp lệ (valid) hoặc không hợp lệ (invalid).

Hợp lệ: bản ghi thỏa điều kiện. Ví dụ email an.nguyen@congty.vn qua được quy tắc định dạng email.
Không hợp lệ: bản ghi vi phạm. Ví dụ email an.nguyen(at)congty bị đánh “không hợp lệ”.

Từ tỷ lệ hợp lệ trên tổng số, Ataccama tính ra điểm chất lượng (DQ score) — ví dụ “cột Email đạt 92 phần trăm hợp lệ”. Quan trọng không kém: hệ thống giữ lại danh sách bản ghi không hợp lệ (invalid samples) để bạn xem chính xác dòng nào sai và sai ra sao — từ đó mới sửa được. Đo mà không chỉ ra được chỗ sai thì khó hành động; Ataccama cho bạn cả con số lẫn danh sách cụ thể.

Quy tắc đơn vs quy tắc tổng hợp

Không phải vấn đề chất lượng nào cũng nằm gọn trong một dòng. Vì thế có hai cấp độ quy tắc:

Quy tắc đơn (kiểm ở mức từng bản ghi)

Đây là loại phổ biến nhất: quy tắc xét từng dòng độc lập. “Email này có đúng định dạng không?”, “Mã số thuế của dòng này có rỗng không?” — câu trả lời chỉ phụ thuộc vào chính dòng đó. Phần lớn quy tắc bạn dùng hằng ngày thuộc loại này.

Quy tắc tổng hợp (aggregation — kiểm ở mức tập dữ liệu)

Một số điều kiện chỉ có ý nghĩa khi nhìn cả tập dữ liệu, không phải từng dòng. Đó là lúc cần quy tắc tổng hợp (aggregation). Ví dụ:

“Tỷ lệ khách hàng thiếu số điện thoại không được vượt quá 5 phần trăm.”
“Mã khách hàng phải là duy nhất trong toàn bảng (không trùng).”
“Tổng doanh thu theo chi nhánh không được lệch quá X so với hệ thống kế toán.”

Những câu hỏi này không thể trả lời bằng cách nhìn một dòng — chúng cần đếm, gộp, so sánh trên toàn bộ tập dữ liệu. Nhớ phân biệt: quy tắc đơn xét một dòng, quy tắc tổng hợp xét cả bảng.

DQ rule khác detection rule như thế nào?

Người mới rất hay nhầm hai khái niệm này, nên hãy phân biệt nhanh:

DQ rule (quy tắc chất lượng): mục đích là đo dữ liệu tốt hay xấu — chấm hợp lệ/không hợp lệ, ra điểm chất lượng. Đây là chủ đề của trang này.
Detection rule (quy tắc phát hiện): mục đích là nhận diện / phân loại dữ liệu — ví dụ “cột này trông giống mã số thuế”, “trường này có vẻ chứa thông tin cá nhân”. Nó không chấm tốt/xấu, mà giúp gắn nhãn và tự gán thuật ngữ.

Cách nhớ gọn: DQ rule hỏi “dữ liệu có tốt không?”, còn detection rule hỏi “đây là loại dữ liệu gì?”. Hai việc khác nhau, bổ trợ cho nhau.

Gắn quy tắc theo thuật ngữ nghiệp vụ — viết một lần, dùng khắp nơi

Đây là điểm khiến cách làm của Ataccama mạnh hơn nhiều so với kiểm tra dữ liệu thủ công.

Thay vì gắn quy tắc trực tiếp vào một cột của một bảng cụ thể, bạn gắn quy tắc vào thuật ngữ nghiệp vụ (business term). Ví dụ bạn định nghĩa thuật ngữ “Email khách hàng” và gắn cho nó quy tắc kiểm tra định dạng email. Sau đó, mọi cột trong mọi hệ thống được gắn nhãn “Email khách hàng” — dù nằm ở CRM, ở hệ thống bán hàng, hay ở kho dữ liệu — đều tự động được áp cùng quy tắc đó.

Lợi ích cho doanh nghiệp rất lớn:

Nhất quán: “email hợp lệ” được hiểu giống nhau ở mọi nơi, không mỗi phòng một chuẩn.
Tái sử dụng: viết quy tắc một lần, áp cho hàng chục bảng.
Dễ bảo trì: khi cần đổi định nghĩa, bạn sửa ở một chỗ — thay vì đi sửa từng bảng và chắc chắn sẽ bỏ sót.

Đây cũng là lý do quy tắc chất lượng gắn liền với data governance: nó kết nối định nghĩa nghiệp vụ (thuật ngữ) với kiểm tra kỹ thuật (quy tắc) thành một thể thống nhất.

Hai trợ thủ nên biết: lookup và component

Khi xây quy tắc, bạn sẽ sớm gặp hai khái niệm tiện lợi này:

Lookup (danh sách giá trị hợp lệ): thay vì viết logic phức tạp, bạn cung cấp một danh sách các giá trị được chấp nhận rồi quy tắc chỉ cần kiểm tra “giá trị này có nằm trong danh sách không”. Ví dụ một lookup chứa danh mục 63 tỉnh thành chuẩn của Việt Nam — mọi giá trị Tinh_thanh không khớp danh sách sẽ bị đánh không hợp lệ. Rất hợp cho dữ liệu kiểu danh mục.
Component (logic tái dùng): một mảnh logic kiểm tra mà bạn dựng sẵn để lắp vào nhiều quy tắc khác nhau. Ví dụ một component “chuẩn hóa số điện thoại Việt Nam” có thể dùng chung cho nhiều quy tắc liên quan tới điện thoại, thay vì viết lại logic mỗi lần.

Hai công cụ này giúp bộ quy tắc của bạn gọn, sạch và dễ mở rộng khi quy mô lớn dần.

Ví dụ Việt Nam: bộ quy tắc cho bảng khách hàng

Sau khi profiling bảng KHACH_HANG, một doanh nghiệp có thể dựng bộ quy tắc như sau:

Quy tắc đơn: Email đúng định dạng; MST (mã số thuế) không rỗng và đủ số; Ngay_sinh trong khoảng từ năm 1920 tới hôm nay; Tinh_thanh nằm trong lookup 63 tỉnh thành chuẩn.
Quy tắc tổng hợp: Ma_KH (mã khách hàng) duy nhất toàn bảng; tỷ lệ thiếu So_dien_thoai dưới 10 phần trăm.
Gắn theo thuật ngữ: các quy tắc trên gắn vào những thuật ngữ “Email khách hàng”, “Mã số thuế”, “Tỉnh thành” — để khi hệ thống bán hàng và CRM cùng có các trường này, chúng được kiểm tra y hệt mà không phải dựng lại.

Kết quả: thay vì “cảm giác dữ liệu hơi bẩn”, lãnh đạo có một điểm chất lượng cụ thể cho từng cột và một danh sách bản ghi cần sửa — sẵn sàng để hành động.

Tạo và áp dụng DQ rule trong thực tế — bắt tay dựng quy tắc từng bước.
Chiều chất lượng & cách tính điểm chất lượng — kết quả hợp lệ/không hợp lệ biến thành điểm số ra sao.
Detection rules & tự gán thuật ngữ/domain — phân biệt rõ với DQ rule và xem khi nào dùng cái nào.