Mở đầu — vì sao bài này quan trọng
Bạn đã dành hàng chục giờ để thiết kế một mô hình dữ liệu đẹp: entities rõ ràng, quan hệ chuẩn hóa, khóa chính hợp lý. Nhưng có một sự thật phũ phàng mà nhiều BA (Business Analyst) chỉ nhận ra khi hệ thống đã chạy thật: một schema hoàn hảo về mặt cấu trúc vẫn có thể chứa đầy dữ liệu rác. Mô hình dữ liệu quyết định dữ liệu có thể được lưu như thế nào; còn chất lượng dữ liệu (data quality) quyết định dữ liệu thực sự có đáng tin để ra quyết định hay không.
Trong vai trò một Data BA, bạn sẽ liên tục bị hỏi những câu như: "Báo cáo doanh thu này có tin được không?", "Tại sao cùng một khách hàng lại xuất hiện ba lần?", "Số điện thoại trong CRM có gọi được không?". Tất cả những câu hỏi đó đều quy về một khái niệm: các chiều đo chất lượng dữ liệu (data quality dimensions). Đây không phải chuyện của riêng đội vận hành hay DBA — nó bắt đầu ngay từ khâu thiết kế mô hình. Khi bạn hiểu sáu chiều đo này, bạn sẽ biết đặt constraint ở đâu, viết business rule nào, và thiết kế quy trình nhập liệu ra sao để dữ liệu "sạch từ trong trứng nước".
Bài này giúp bạn trả lời được: chất lượng dữ liệu gồm những khía cạnh nào, đo lường ra sao bằng con số cụ thể, và một BA có thể can thiệp ở những điểm nào trong vòng đời dữ liệu.
Khái niệm cốt lõi
Data quality không phải một con số duy nhất kiểu "dữ liệu này 80% tốt". Nó là một tập hợp nhiều chiều đo (dimension), mỗi chiều đo trả lời một câu hỏi khác nhau về dữ liệu. Giới trong ngành thường thống nhất ở sáu chiều đo cốt lõi. Ta đi qua từng chiều một cách thực dụng — kèm cách đo bằng con số, vì thứ không đo được thì không quản lý được.
1. Accuracy — Tính chính xác
Câu hỏi: Dữ liệu có phản ánh đúng thực tế không?
Một bản ghi khách hàng ghi ngày sinh 01/01/1900 về mặt kỹ thuật là hợp lệ (đúng định dạng ngày), nhưng gần như chắc chắn sai thực tế — đó là giá trị mặc định mà nhân viên nhập bừa. Accuracy đo mức độ khớp giữa giá trị lưu trong hệ thống và giá trị thật ngoài đời.
Đây là chiều khó đo nhất, vì thường phải đối chiếu với một nguồn chân lý (source of truth) bên ngoài — ví dụ đối chiếu số CCCD với cơ sở dữ liệu dân cư, hoặc gọi thử số điện thoại. Công thức đơn giản: Accuracy = số bản ghi đúng thực tế / tổng số bản ghi kiểm tra.
2. Completeness — Tính đầy đủ
Câu hỏi: Mọi dữ liệu cần có đã hiện diện chưa?
Completeness đo tỷ lệ các trường bắt buộc bị bỏ trống (NULL, chuỗi rỗng, hoặc giá trị "N/A" giả). Ví dụ: trong 100.000 hồ sơ khách hàng, có 12.000 hồ sơ thiếu email. Vậy completeness của trường email là 88%.
Lưu ý quan trọng cho BA: "đầy đủ" mang tính ngữ cảnh. Email có thể bắt buộc với khách hàng đăng ký online nhưng không bắt buộc với khách vãng lai tại quầy. Bạn phải định nghĩa "kỳ vọng" trước khi đo — nếu không, bạn sẽ báo động giả.
3. Consistency — Tính nhất quán
Câu hỏi: Cùng một dữ liệu có mâu thuẫn với chính nó ở các nơi khác nhau không?
Consistency quan tâm đến mâu thuẫn nội bộ. Ví dụ: khách hàng có status = 'đã hủy' nhưng vẫn có đơn hàng status = 'đang giao'. Hoặc cùng một mã sản phẩm nhưng tên khác nhau giữa hệ thống kho và hệ thống bán hàng. Một dạng phổ biến ở Việt Nam: tỉnh ghi "TP.HCM" ở bảng này, "Hồ Chí Minh" ở bảng kia, "HCM" ở bảng thứ ba — cùng một thực thể, ba cách biểu diễn.
4. Validity — Tính hợp lệ
Câu hỏi: Dữ liệu có tuân thủ đúng định dạng, kiểu, và miền giá trị đã quy định không?
Đây là chiều dễ đo và dễ tự động hóa nhất, vì nó kiểm tra so với quy tắc (rule) chứ không so với thực tế. Số điện thoại VN phải khớp mẫu 0[0-9]{9}; mã số thuế phải 10 hoặc 13 chữ số; giới tính phải thuộc tập {Nam, Nữ, Khác}; ngày sinh không được ở tương lai. Một giá trị có thể valid mà vẫn inaccurate: 0912345678 là số hợp lệ về định dạng nhưng có thể không phải số thật của khách.
5. Uniqueness — Tính duy nhất
Câu hỏi: Có bản ghi nào bị trùng lặp không?
Uniqueness đo mức độ mỗi thực thể ngoài đời chỉ được biểu diễn đúng một lần trong hệ thống. Trùng lặp (duplicate) là "kẻ thù" kinh điển của mọi CRM: cùng một khách hàng "Nguyễn Văn A" được nhập hai lần với hai số điện thoại khác nhau. Đo bằng: Uniqueness = số thực thể duy nhất / tổng số bản ghi.
6. Timeliness — Tính kịp thời
Câu hỏi: Dữ liệu có đủ mới để dùng cho quyết định không?
Một địa chỉ giao hàng chính xác năm 2019 nhưng khách đã chuyển nhà năm 2023 thì hôm nay là dữ liệu sai. Timeliness đo độ trễ giữa thời điểm sự kiện xảy ra ngoài đời và thời điểm nó được cập nhật vào hệ thống — và mức độ "cũ" mà dữ liệu vẫn còn dùng được. Với dữ liệu tồn kho phục vụ bán hàng, độ trễ vài giờ đã là quá muộn; với dữ liệu điều tra dân số, vài tháng vẫn chấp nhận được.
Vai trò của BA trong sáu chiều đo
Điều cần nhớ: mỗi chiều đo gắn với một điểm can thiệp trong thiết kế. Validity và Uniqueness gần như hoàn toàn có thể ép bằng constraint, CHECK, và UNIQUE ngay trong mô hình vật lý. Completeness ép bằng NOT NULL. Consistency ép bằng khóa ngoại (foreign key) và bảng tham chiếu (lookup table). Còn Accuracy và Timeliness thì phần lớn nằm ở quy trình và con người — schema chỉ hỗ trợ được một phần. Một BA giỏi biết chiều nào "chặn được ở cổng" và chiều nào cần quy trình đi kèm.
Tình huống thực tế
Ví dụ 1 — Ngân hàng số và cơn ác mộng số điện thoại
Một ngân hàng số tại Việt Nam (tạm gọi là Ngân hàng Việt Digital) triển khai chiến dịch gửi OTP và thông báo giao dịch qua SMS cho 2,3 triệu khách hàng. Sau tháng đầu, đội marketing báo cáo tỷ lệ SMS gửi thất bại lên tới 9%. Đội Data BA vào cuộc và phân tích theo từng chiều đo.
- Validity: 4,1% số điện thoại không khớp mẫu VN (thiếu số, còn đầu số +84 lẫn 0, có ký tự khoảng trắng). Đây là lỗi định dạng — chặn được bằng regex ngay khi nhập.
- Accuracy: thêm 3,2% số đúng định dạng nhưng là số ảo hoặc số cũ đã hết dùng — phát hiện qua phản hồi "thuê bao không tồn tại" từ nhà mạng.
- Timeliness: 1,7% khách đã đổi số nhưng chưa cập nhật.
Ví dụ 2 — Sàn thương mại điện tử và khách hàng "sinh đôi"
Một sàn TMĐT Đông Nam Á phát hiện chương trình khuyến mãi "giảm 50.000đ cho khách hàng mới" bị lạm dụng nghiêm trọng: chi phí khuyến mãi vượt ngân sách 34%. Điều tra cho thấy vấn đề nằm ở Uniqueness. Cùng một người dùng tạo nhiều tài khoản với email biến thể (an.nguyen@gmail.com, annguyen@gmail.com, an.nguyen+1@gmail.com — Gmail bỏ qua dấu chấm và phần sau dấu +), mỗi tài khoản đều được tính là "khách mới".
Đội Data BA đo tỷ lệ trùng: gom nhóm theo số điện thoại đã xác thực + thiết bị, họ ước tính khoảng 18% "khách hàng mới" thực chất là trùng lặp. Giải pháp gồm hai lớp: (1) ở tầng mô hình, thêm ràng buộc UNIQUE trên số điện thoại đã xác thực thay vì trên email dễ biến hóa; (2) chuẩn hóa email trước khi lưu (bỏ dấu chấm, cắt phần +... với domain gmail).
Bài học: Uniqueness không chỉ là chuyện "đặt UNIQUE constraint". Bạn phải chọn đúng thuộc tính làm căn cứ nhận dạng thực thể. Chọn nhầm email làm khóa định danh khiến toàn bộ ràng buộc trở nên vô dụng.
Ví dụ 3 — Chuỗi bán lẻ và báo cáo tồn kho lệch
Một chuỗi bán lẻ mỹ phẩm 45 cửa hàng chạy báo cáo tồn kho tập trung mỗi sáng để quyết định nhập hàng. Giám đốc vận hành phàn nàn báo cáo "lúc đúng lúc sai". Điều tra hé lộ hai chiều đo bị vi phạm cùng lúc:
- Consistency: mã sản phẩm son môi màu đỏ được nhập là
SON-DO-01ở cửa hàng miền Bắc vàSONDO01ở cửa hàng miền Nam — hệ thống coi là hai sản phẩm, làm tồn kho bị chia đôi. - Timeliness: các cửa hàng đồng bộ dữ liệu bán hàng lúc cuối ngày, nên báo cáo buổi sáng luôn thiếu doanh số của chiều hôm trước ở một số điểm mạng yếu.
Hướng dẫn từng bước
Đây là quy trình thực dụng để một BA đánh giá và cải thiện chất lượng dữ liệu cho một tập dữ liệu hoặc một bảng.
Bước 1 — Xác định phạm vi và bảng dữ liệu trọng yếu. Đừng đo tất cả. Chọn những bảng/trường ảnh hưởng trực tiếp tới quyết định kinh doanh hoặc tuân thủ pháp lý (khách hàng, giao dịch, tồn kho). Chất lượng dữ liệu tốn công, hãy ưu tiên nơi có giá trị cao.
Bước 2 — Định nghĩa kỳ vọng cho từng chiều đo. Với mỗi trường, viết rõ: định dạng hợp lệ (validity), có bắt buộc không (completeness), khóa định danh là gì (uniqueness), độ mới tối đa chấp nhận được (timeliness), quy tắc nhất quán liên bảng (consistency), nguồn đối chiếu chân lý nếu có (accuracy). Đây chính là data quality rules.
Bước 3 — Viết truy vấn đo (profiling). Chuyển mỗi kỳ vọng thành một câu SQL đếm số vi phạm. Ví dụ:
- Completeness:
SELECT COUNT(*) FROM khach_hang WHERE email IS NULL OR email = ''; - Validity:
SELECT COUNT(*) FROM khach_hang WHERE so_dt NOT REGEXP '^0[0-9]{9}$'; - Uniqueness:
SELECT so_dt, COUNT() FROM khach_hang GROUP BY so_dt HAVING COUNT() > 1;
Bước 5 — Phân loại nguyên nhân gốc (root cause). Vi phạm đến từ đâu: form nhập liệu không có kiểm tra? Import dữ liệu cũ? Tích hợp từ hệ thống bên thứ ba? Quy trình vận hành? Chiều đo cho bạn biết "cái gì sai", root cause cho bạn biết "vì sao sai".
Bước 6 — Đề xuất điểm can thiệp. Ánh xạ từng vấn đề vào lớp phù hợp: chặn ở mô hình dữ liệu (constraint, FK, UNIQUE, CHECK), chặn ở tầng ứng dụng (validate form), hay chặn ở quy trình (đào tạo, xác thực định kỳ). Ưu tiên chặn càng sớm càng tốt — chặn ở cổng nhập luôn rẻ hơn dọn dẹp về sau.
Bước 7 — Giám sát liên tục. Chất lượng dữ liệu không phải dự án một lần. Lên lịch chạy scorecard định kỳ (hằng tuần/tháng) và cảnh báo khi một chiều đo tụt dưới ngưỡng.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm lẫn Validity với Accuracy. Rất nhiều BA tưởng dữ liệu "đúng định dạng" là "đúng". Một số điện thoại 0900000000 khớp regex nhưng chẳng gọi được ai. Mẹo: luôn tách hai chiều này. Validity kiểm tra so với quy tắc; Accuracy kiểm tra so với thực tế.
Lỗi 2 — Đo completeness mà không định nghĩa kỳ vọng. Báo cáo "trường email thiếu 40%" là vô nghĩa nếu email vốn không bắt buộc với nhóm khách đó. Mẹo: luôn định nghĩa "bắt buộc trong ngữ cảnh nào" trước khi đếm NULL.
Lỗi 3 — Đặt UNIQUE trên trường dễ biến hóa. Như ví dụ email Gmail, chọn nhầm khóa định danh khiến uniqueness constraint mất tác dụng. Mẹo: chọn thuộc tính ổn định và đã được xác thực (số điện thoại đã OTP, CCCD) làm căn cứ chống trùng, và chuẩn hóa dữ liệu trước khi so.
Lỗi 4 — Bỏ qua Timeliness vì "dữ liệu vẫn có đó". Dữ liệu tồn tại không có nghĩa là dữ liệu còn dùng được. Mẹo: với mỗi trường quan trọng, hãy hỏi "dữ liệu này cũ bao lâu thì trở nên nguy hiểm?" và thêm cột updated_at để đo độ trễ.
Lỗi 5 — Coi data quality là việc của kỹ thuật. Nhiều vấn đề chất lượng bắt nguồn từ quy trình con người, không phải code. Mẹo: BA nên phối hợp cả ba lớp — mô hình, ứng dụng, quy trình — và đừng kỳ vọng constraint giải quyết mọi thứ.
Mẹo tổng quát: Ưu tiên "phòng bệnh" hơn "chữa bệnh". Một CHECK, một FOREIGN KEY, một NOT NULL đặt đúng chỗ trong mô hình vật lý sẽ ngăn hàng nghìn bản ghi rác không bao giờ được sinh ra. Đây chính là lý do data quality phải là mối quan tâm của BA ngay từ khâu thiết kế mô hình, chứ không đợi tới lúc dọn dẹp.
Bài tập thực hành
Cho bảng khach_hang của một cửa hàng online với các cột: id, ho_ten, so_dt, email, tinh_thanh, ngay_sinh, updated_at. Dữ liệu mẫu có các vấn đề: một số so_dt sai định dạng, email trùng theo biến thể dấu chấm, tinh_thanh ghi lẫn "TP.HCM"/"Hồ Chí Minh"/"HCM", vài ngay_sinh ở tương lai, nhiều updated_at từ hơn 2 năm trước.
- Với mỗi cột, gán nó vào chiều đo (hoặc các chiều đo) chất lượng dữ liệu phù hợp nhất và giải thích tại sao.
- Viết ít nhất năm câu SQL profiling, mỗi câu đo một chiều đo khác nhau (validity của
so_dt, completeness củaemail, uniqueness theo email chuẩn hóa, consistency củatinh_thanh, timeliness theoupdated_at). - Lập một scorecard giả định với con số phần trăm cho từng chiều đo, và đặt ngưỡng mục tiêu cho mỗi chiều.
- Với mỗi vấn đề tìm được, đề xuất điểm can thiệp: chặn ở mô hình (constraint nào?), ở ứng dụng, hay ở quy trình. Riêng cột
tinh_thanh, hãy mô tả cách dùng bảng tham chiếu (lookup table) để ép consistency. - Câu hỏi mở rộng: chiều đo nào trong bài này không thể chặn hoàn toàn bằng schema? Giải thích vì sao và đề xuất quy trình bù đắp.
Tóm tắt
Chất lượng dữ liệu không phải một con số duy nhất mà là tập hợp sáu chiều đo: Accuracy (khớp thực tế), Completeness (đầy đủ), Consistency (không mâu thuẫn nội bộ), Validity (đúng quy tắc/định dạng), Uniqueness (không trùng lặp), và Timeliness (đủ mới). Mỗi chiều trả lời một câu hỏi khác nhau, đo bằng một công thức cụ thể, và gắn với một điểm can thiệp riêng.
Vai trò của bạn — một Data BA — là biết chiều nào chặn được ngay trong mô hình dữ liệu (Validity, Uniqueness, Completeness, Consistency ép bằng CHECK/UNIQUE/NOT NULL/FK), và chiều nào cần quy trình con người đi kèm (Accuracy, Timeliness). Ba tình huống — ngân hàng số, sàn TMĐT, chuỗi bán lẻ — cho thấy một triệu chứng ("báo cáo sai", "SMS thất bại") thường là tổng của nhiều chiều đo bị vi phạm, và chỉ khi bóc tách theo từng chiều bạn mới xử lý đúng gốc rễ. Quy trình bảy bước — xác định phạm vi, định nghĩa kỳ vọng, profiling bằng SQL, lập scorecard, tìm root cause, đề xuất can thiệp, giám sát liên tục — là bộ khung bạn có thể áp dụng cho bất kỳ tập dữ liệu nào. Nguyên tắc vàng: phòng bệnh trong thiết kế mô hình luôn rẻ hơn chữa bệnh khi dữ liệu đã hỏng.