Bỏ qua để đến nội dung

Detection rules: tự nhận diện và gắn thuật ngữ cho dữ liệu

Hãy tưởng tượng bạn có một kho dữ liệu với hàng nghìn cột, tên cột thì mỗi hệ thống đặt một kiểu — col_07, kh_email, ma_so, field3. Làm sao biết cột nào chứa email, cột nào chứa số căn cước, cột nào là mã số thuế, để còn áp đúng quy tắc kiểm tra và bảo vệ đúng dữ liệu nhạy cảm? Làm tay thì bất khả thi ở quy mô lớn. Detection rule sinh ra để giải đúng bài toán này: nó tự đọc dữ liệu, nhận ra “đây là loại gì”, rồi gắn nhãn nghiệp vụ tương ứng — tự động, trên toàn bộ kho. Trang này giải thích cho người mới detection rule là gì, khác gì DQ rule, và vì sao nó là trụ cột âm thầm của data governance.

Đây là điểm dễ nhầm nhất với người mới, nên cần phân biệt rõ ngay từ đầu. Cả hai đều là “quy tắc” chạy trên dữ liệu, nhưng mục đích trái ngược nhau:

  • DQ rule (quy tắc chất lượng) trả lời câu hỏi: “Dữ liệu này có tốt không?” — ví dụ kiểm tra email có đúng định dạng, mã số thuế có đủ số. Kết quả là đạt / không đạt và một điểm chất lượng.
  • Detection rule trả lời câu hỏi: “Dữ liệu này là loại gì?” — ví dụ nhận ra một cột chứa toàn chuỗi dạng ten@mien.com thì đây là cột email; một cột toàn dãy 12 chữ số theo khuôn căn cước thì đây là cột số CCCD. Kết quả là một nhãn / thuật ngữ nghiệp vụ được gắn vào cột.

Nói ngắn gọn: DQ rule chấm điểm, detection rule dán nhãn. Và hai việc này bổ trợ nhau — bạn phải biết một cột là email (việc của detection rule) thì mới biết đem quy tắc kiểm tra email (DQ rule) ra áp vào. Detection chạy trước, mở đường cho chất lượng chạy sau.

Detection rule gắn nhãn dựa theo điều kiện, không phải dựa vào tên cột (vì tên cột thường không tin được). Nó nhìn vào chính giá trị bên trong và đối chiếu với khuôn mẫu đã định nghĩa:

  • Theo khuôn mẫu (pattern): ví dụ chuỗi có dạng chữ@chữ.chữ thì khả năng cao là email; dãy đúng 10 hoặc 13 chữ số theo cấu trúc nhất định thì là mã số thuế Việt Nam; dãy 12 chữ số là số căn cước công dân (CCCD).
  • Theo tỷ lệ khớp: detection rule không đòi 100 phần trăm dòng phải khớp mới kết luận. Nếu phần lớn giá trị trong cột khớp khuôn email, nó vẫn tự tin gắn nhãn “email” cho cả cột — vì dữ liệu thật luôn có vài dòng rỗng hoặc sai lệch.
  • Kết hợp nhiều điều kiện: một số loại dữ liệu cần nhiều dấu hiệu cùng lúc để phân biệt (ví dụ phân biệt số điện thoại di động với số điện thoại bàn, hay phân biệt mã số thuế cá nhân với doanh nghiệp).

Vì dựa vào nội dung thật, detection rule bắt được cả những cột bị đặt tên sai hoặc đặt tên vô nghĩa — đúng kiểu tình huống hay gặp ở các hệ thống cũ tại Việt Nam.

Khám phá domain — gom dữ liệu cùng loại lại với nhau

Phần tiêu đề “Khám phá domain — gom dữ liệu cùng loại lại với nhau”

Trong Ataccama, một domain là một loại dữ liệu nghiệp vụ — ví dụ domain “Email”, domain “Số CCCD”, domain “Mã số thuế”, domain “Số tài khoản ngân hàng”. Detection rule chính là công cụ để khám phá domain: nó quét toàn bộ kho và đánh dấu mọi cột nào thuộc về domain nào.

Lợi ích rất thực tế: thay vì nhìn kho dữ liệu như một mớ cột rời rạc, bạn có một bản đồ kiểu “trong toàn doanh nghiệp, dữ liệu CCCD đang nằm rải rác ở 14 bảng thuộc 5 hệ thống”. Bản đồ này là nền tảng để bạn quản lý nhất quán: cùng một loại dữ liệu thì áp cùng một bộ quy tắc, cùng một chính sách bảo mật, dù nó nằm ở đâu.

Detection rule không phải đích đến — nó là bước đầu vào nuôi hai việc lớn hơn:

Khi đã biết mỗi cột thuộc domain nào, hệ thống có thể tự gắn nhãn phân loại cho dữ liệu trên toàn kho. Đây là cách bạn trả lời được những câu hỏi governance kiểu: “Dữ liệu cá nhân của khách hàng đang nằm ở những đâu?” mà không phải đi rà từng bảng bằng tay.

Vì cột đã được gắn thuật ngữ nghiệp vụ, bạn có thể áp quy tắc chất lượng theo thuật ngữ thay vì theo từng cột. Ví dụ: định nghĩa một lần bộ quy tắc cho thuật ngữ “Email”, rồi mọi cột nào được detection nhận là email — ở bất kỳ bảng nào — đều tự động thừa hưởng bộ quy tắc đó. Bạn viết một lần, áp dụng khắp nơi. Đây là điều khiến chất lượng dữ liệu mở rộng được ở quy mô doanh nghiệp.

  1. Detection rule quét dữ liệu và nhận ra loại của từng cột theo điều kiện.
  2. Mỗi cột được gắn thuật ngữ / domain tương ứng (email, CCCD, mã số thuế…).
  3. Kết quả feed cho phân loại dữ liệu trên toàn kho.
  4. DQ rule gắn theo thuật ngữ tự động áp lên mọi cột cùng loại.

Vai trò governance: tự động phân loại PII ở quy mô lớn

Phần tiêu đề “Vai trò governance: tự động phân loại PII ở quy mô lớn”

Đây là giá trị lớn nhất của detection rule dưới góc nhìn quản trị. Mọi doanh nghiệp đều phải bảo vệ dữ liệu cá nhân nhạy cảm (PII) — số CCCD, số điện thoại, email, số tài khoản, thông tin y tế… Nhưng bạn không thể bảo vệ thứ mình không biết đang nằm ở đâu.

Detection rule giải bài toán này tự động và ở quy mô lớn: nó quét toàn bộ kho và chỉ ra mọi vị trí có PII, kể cả ở những cột đặt tên mập mờ mà con người dễ bỏ sót. Khi đã biết “PII nằm ở đây, đây và đây”, bạn mới có thể:

  • Áp chính sách bảo mật đúng chỗ (giới hạn quyền xem, che/ẩn dữ liệu nhạy cảm).
  • Đáp ứng tuân thủ — như Nghị định bảo vệ dữ liệu cá nhân tại Việt Nam — vì bạn chứng minh được mình biết đang giữ dữ liệu cá nhân ở đâu và kiểm soát ra sao.
  • Giảm rủi ro rò rỉ do dữ liệu nhạy cảm bị bỏ quên trong một bảng cũ không ai để ý.

Làm tay với hàng nghìn cột là bất khả thi và luôn sót. Detection rule biến nó thành quy trình tự động, lặp lại được, phủ toàn bộ — đúng tinh thần governance ở quy mô doanh nghiệp.

  • Nhầm detection rule với DQ rule. Hãy nhớ: detection nhận diện loại, DQ chấm điểm chất lượng. Dùng nhầm thì kết quả vô nghĩa.
  • Tin tên cột thay vì tin nội dung. Tên cột ở hệ thống cũ thường sai hoặc viết tắt khó hiểu; sức mạnh của detection là nhìn giá trị thật, nên đừng tự lọc theo tên cột trước.
  • Bật detection rồi để đó, không rà soát. Ở các domain nhạy cảm (PII, tài chính), nên có người xác nhận lại nhãn trước khi dùng nó để áp chính sách bảo mật hoặc báo cáo tuân thủ.
Chia sẻ: