Chất lượng dữ liệu trong MDM: làm sạch trước khi gộp

Nhiều doanh nghiệp kỳ vọng MDM (quản lý dữ liệu chủ) sẽ tự động dọn dẹp đống dữ liệu khách hàng lộn xộn của họ. Nhưng MDM không phải là phép màu: nó chỉ tốt bằng đúng dữ liệu được nạp vào. Nếu dữ liệu đầu vào còn bẩn — tên viết sai chính tả, địa chỉ mỗi nơi một kiểu, số điện thoại sai định dạng — thì bước đối sánh (matching) sẽ nhận diện nhầm, và bản ghi vàng (golden record) sinh ra cũng sai theo. Đây chính là lý do chất lượng dữ liệu (data quality — DQ) và MDM luôn đi cùng nhau như hai mặt của một việc.

Vì sao chất lượng dữ liệu và MDM gắn chặt

Hãy hình dung MDM như một dây chuyền: bản ghi từ nhiều hệ thống (CRM, kế toán, bán hàng, chăm sóc khách hàng) chảy vào, được so khớp để tìm xem những bản ghi nào cùng nói về một thực thể (chẳng hạn cùng một khách hàng), rồi gộp lại thành một bản ghi vàng tin cậy duy nhất.

Vấn đề nằm ở chỗ: máy quyết định “hai bản ghi này có phải cùng một người không” dựa trên chính các giá trị trong dữ liệu. Nếu giá trị đó méo mó, máy không có cơ sở đáng tin để phán đoán.

Trong ngành dữ liệu có một câu rất quen: “rác vào, rác ra” (garbage in, garbage out). Với MDM, câu này đặc biệt đúng:

Dữ liệu bẩn → đối sánh sai. Hai bản ghi của cùng một người nhưng tên viết khác kiểu có thể không được nhận ra là một (gọi là bỏ sót, under-matching) → khách hàng bị tách thành hai. Ngược lại, hai người khác nhau nhưng thông tin thiếu và na ná nhau có thể bị gộp nhầm làm một (gộp thừa, over-matching).
Đối sánh sai → bản ghi vàng sai. Bản ghi vàng được tạo ra bằng cách lấy giá trị tốt nhất từ nhóm bản ghi đã khớp. Nếu nhóm đó vốn đã sai, thì dù quy tắc sống sót (survivorship) có khéo đến đâu cũng chỉ chọn ra một giá trị sai mà thôi.
Bản ghi vàng sai → cả tổ chức tin nhầm. Vì bản ghi vàng được xuất ngược về các hệ thống nguồn và dùng cho báo cáo, một bản ghi vàng sai sẽ lan lỗi ra khắp nơi.

Nói ngắn gọn: chất lượng dữ liệu là điều kiện để MDM hoạt động đúng, không phải việc làm thêm cho vui.

Một ví dụ Việt Nam

Giả sử một chuỗi bán lẻ có ba bản ghi của cùng một khách hàng ở ba hệ thống:

CRM: Nguyễn Văn An — 0901234567 — 12 Lê Lợi, Q.1, TP.HCM
Kế toán: Nguyen Van An — +84 901 234 567 — 12 Le Loi, Quan 1, Ho Chi Minh
Web bán hàng: NGUYEN VAN AN — 84901234567 — (địa chỉ để trống)

Với con người, rõ ràng đây là một người. Nhưng nếu nạp thẳng vào MDM mà chưa làm sạch, máy thấy ba chuỗi ký tự khác nhau hoàn toàn ở cả tên, số điện thoại lẫn địa chỉ. Rủi ro là hệ thống tạo ra ba khách hàng riêng biệt thay vì một — và thế là sai ngay từ nền móng.

Chuẩn hóa và làm sạch — làm TRƯỚC khi đối sánh

Cách xử lý đúng là đặt một lớp chuẩn hóa (standardization) và làm sạch (cleansing) ở phía trước bước đối sánh. Mục tiêu là đưa các giá trị về cùng một dạng thống nhất để máy có thể so khớp công bằng.

Một vài việc chuẩn hóa thường gặp:

Chuẩn hóa tên: bỏ dấu hoặc thống nhất cách bỏ dấu, đưa về cùng kiểu hoa/thường, gỡ khoảng trắng thừa. Khi đó Nguyễn Văn An, Nguyen Van An, NGUYEN VAN AN quy về cùng một dạng → khớp tốt hơn rất nhiều.
Chuẩn hóa số điện thoại: đưa về một định dạng chuẩn (ví dụ luôn dạng +84... hoặc luôn 0...), bỏ dấu cách và dấu gạch. Ba số ở ví dụ trên trở thành cùng một giá trị.
Chuẩn hóa địa chỉ: thống nhất viết tắt (Q.1 ↔ Quận 1, TP.HCM ↔ Thành phố Hồ Chí Minh), tách thành phần (số nhà, đường, quận, tỉnh/thành) cho rõ ràng.
Làm sạch giá trị rác: xử lý ô để trống, ô điền linh tinh (kiểu khong co, n/a), ngày tháng sai định dạng.

Vì sao thứ tự làm sạch trước, đối sánh sau lại quan trọng đến vậy? Vì sau khi chuẩn hóa, ba bản ghi khách hàng ở trên gần như trùng khít nhau ở tên và số điện thoại. Thuật toán đối sánh — kể cả so khớp mờ (fuzzy matching) vốn cho phép sai khác nhỏ — giờ có một nền sạch để làm việc, nên tỷ lệ nhận diện đúng tăng vọt và sai sót giảm hẳn. Làm sạch trước không chỉ giúp khớp đúng hơn mà còn khiến quy tắc đối sánh đơn giản và dễ bảo trì hơn.

DQ rule kiểm tra ngay cả bản ghi vàng

Chất lượng dữ liệu không dừng lại ở đầu vào. Một thực hành tốt là tiếp tục dùng quy tắc chất lượng (DQ rule) để kiểm bản ghi vàng sau khi đã gộp — coi bản ghi vàng như một sản phẩm cần được giám sát chứ không phải kết quả “xong là xong”.

Một số phép kiểm thường đặt lên bản ghi vàng:

Đầy đủ (completeness): bản ghi vàng của khách hàng có thiếu trường bắt buộc nào không (ví dụ thiếu số điện thoại lẫn email thì không liên hệ được)?
Hợp lệ (validity): mã số thuế, email, số điện thoại trong bản ghi vàng có đúng định dạng không?
Nhất quán (consistency): các trường có mâu thuẫn nhau không (ví dụ quận thuộc một tỉnh/thành khác với tỉnh/thành đã ghi)?
Không trùng lặp (uniqueness): sau khi gộp, có còn sót cặp bản ghi vàng nào thực ra vẫn là một thực thể nhưng chưa được nhận ra không?

Những phép kiểm này cho ta một vòng phản hồi: nếu bản ghi vàng vẫn còn lỗi, đó là tín hiệu để chỉnh lại bước làm sạch hoặc quy tắc đối sánh, hoặc để data steward vào xem và xử lý ngoại lệ. Khâu xử lý các lỗi phát hiện được — sửa, bổ sung, hoặc đẩy về đúng người chịu trách nhiệm — thuộc về phần khắc phục dữ liệu (remediation).

Trong Ataccama ONE, DQ và MDM nằm trên cùng một nền

Điểm mạnh đáng chú ý của Ataccama ONE là chất lượng dữ liệu và MDM được xây trên cùng một nền tảng, thay vì là hai sản phẩm rời rạc phải ghép nối thủ công. Điều này mang lại vài lợi ích thực tế:

Tái sử dụng quy tắc: các quy tắc chuẩn hóa và làm sạch xây cho dự án chất lượng dữ liệu có thể dùng lại ngay trong luồng MDM, không phải làm lại từ đầu.
Liền mạch trong một dòng chảy: dữ liệu được làm sạch rồi đi thẳng vào đối sánh và gộp, không phải xuất ra rồi nhập lại qua nhiều công cụ — bớt rủi ro và bớt độ trễ.
Cùng một “ngôn ngữ” về chất lượng: điểm chất lượng, chiều chất lượng, và định nghĩa thuật ngữ được chia sẻ chung, nên đội ngũ nhìn dữ liệu chủ và chất lượng dữ liệu bằng cùng một thước đo.

Với người làm data governance, đây là điều rất giá trị: bạn không chỉ có một bản ghi vàng, mà còn biết được bản ghi vàng đó sạch tới mức nào và dựa trên dữ liệu đáng tin ra sao — đúng tinh thần tạo niềm tin vào dữ liệu chủ.

Tổng quan chất lượng dữ liệu trong Ataccama ONE Hiểu nền tảng chất lượng dữ liệu — thứ cấp dữ liệu sạch cho MDM hoạt động đúng.

Đối sánh và nhận diện trùng lặp (matching) Cách MDM tìm các bản ghi cùng một thực thể — và vì sao nó cần dữ liệu đã được làm sạch.

Khắc phục dữ liệu (remediation) Xử lý các lỗi mà DQ rule phát hiện trên bản ghi vàng: sửa, bổ sung, giao đúng người.