Mở đầu — vì sao bài này quan trọng
Bạn từng nghe câu "Garbage in, garbage out" chưa? Trong thế giới data-driven, đây không phải là một câu nói đùa mà là quy luật sắt. Dù bạn có Snowflake xịn nhất, dbt pipeline gọn gàng nhất, hay dashboard Looker đẹp long lanh, nếu dữ liệu bên dưới sai, mọi quyết định dựa trên nó đều sai. Và điều nguy hiểm nhất không phải là data sai — mà là data sai nhưng trông rất đẹp, rất đáng tin, khiến cả tổ chức tự tin đi sai đường.
Ở Bài 11, chúng ta đã xây dựng khung Data Governance — ai sở hữu data, ai chịu trách nhiệm, quy tắc ra sao. Bài 12 này đi sâu vào phần "thịt" của governance: làm sao đo lường được chất lượng dữ liệu bằng con số cụ thể, và làm sao giám sát (monitoring) liên tục để phát hiện sự cố trước khi sếp phát hiện qua một báo cáo tài chính lệch 30%.
Tôi muốn bạn ghi nhớ một điều: chất lượng dữ liệu không phải là trạng thái "đạt được một lần rồi thôi". Nó là một chỉ số sống, dao động mỗi ngày theo từng dòng dữ liệu mới chảy vào. Người làm data trưởng thành là người coi data quality như một sản phẩm cần theo dõi SLA, chứ không phải một dự án dọn dẹp làm một lần.
Khái niệm cốt lõi
6 chiều đo lường chất lượng dữ liệu (DAMA)
Hiệp hội quản trị dữ liệu DAMA đưa ra 6 chiều (dimensions) kinh điển để đánh giá data quality. Đây là bộ khung bạn nên thuộc lòng vì nó giúp biến câu hỏi mơ hồ "data này tốt không?" thành sáu câu hỏi cụ thể có thể đo bằng SQL.
1. Accuracy (Độ chính xác) — Dữ liệu có phản ánh đúng thực tế không? Ví dụ: một khách hàng thật sự sống ở Đà Nẵng nhưng hệ thống ghi là Hà Nội thì đó là lỗi accuracy. Đây là chiều khó đo nhất vì cần đối chiếu với "sự thật gốc" (source of truth) bên ngoài hệ thống.
2. Completeness (Độ đầy đủ) — Có bị thiếu field, thiếu bản ghi không? Đo bằng tỷ lệ giá trị NULL hoặc rỗng. Ví dụ: 18% khách hàng không có số điện thoại thì completeness của trường phone chỉ đạt 82%.
3. Consistency (Tính nhất quán) — Cùng một thông tin nhưng ở hai nơi lại mâu thuẫn. Ví dụ điển hình: bảng orders ghi tổng doanh thu tháng 6 là 5 tỷ, nhưng bảng payments cộng lại chỉ ra 4,7 tỷ. Cùng một sự thật, hai con số khác nhau.
4. Timeliness (Tính kịp thời) — Dữ liệu có được cập nhật đúng lúc cần dùng không? Một dashboard doanh thu lẽ ra refresh mỗi giờ nhưng đang hiển thị số của 3 ngày trước là lỗi timeliness. Đo bằng "data freshness" — độ trễ giữa thời điểm sự kiện xảy ra và thời điểm nó xuất hiện trong warehouse.
5. Uniqueness (Tính duy nhất) — Không có bản ghi trùng lặp. Ví dụ: một khách hàng bị tạo thành 3 tài khoản do đăng ký nhiều lần bằng email khác nhau, khiến số liệu "tổng khách hàng" bị thổi phồng.
6. Validity (Tính hợp lệ) — Dữ liệu có tuân theo định dạng và quy tắc nghiệp vụ không? Ví dụ: ngày sinh năm 2099, email không có ký tự @, số điện thoại có chữ cái, hoặc age = -5. Về mặt kỹ thuật có giá trị, nhưng về mặt nghiệp vụ là vô lý.
Một mẹo để nhớ: Accuracy hỏi "có đúng thực tế không", Validity hỏi "có đúng định dạng không". Một số điện thoại 0000000000 là valid (đủ 10 số) nhưng không accurate (không phải số thật).
Từ chiều đo lường đến Data Quality Score
Đo riêng lẻ từng chiều là chưa đủ; tổ chức trưởng thành thường quy về một Data Quality Score tổng hợp cho từng bảng hoặc từng data product. Cách làm phổ biến:
- Mỗi chiều được viết thành một hoặc nhiều check (kiểm tra) trả về tỷ lệ pass.
- Gán trọng số cho từng check tùy mức độ quan trọng nghiệp vụ (ví dụ completeness của trường
customer_idquan trọng hơnmiddle_name). - Tính điểm tổng hợp, ví dụ 0–100, và đặt ngưỡng: trên 95 là xanh, 85–95 là vàng, dưới 85 là đỏ.
Data profiling — bước khám sức khỏe ban đầu
Trước khi viết check, bạn cần profiling: quét qua dữ liệu để hiểu phân phối, tỷ lệ NULL, giá trị min/max, cardinality (số giá trị phân biệt), pattern phổ biến. Profiling giống như xét nghiệm máu tổng quát trước khi kê đơn. Nó cho bạn biết đâu là ngưỡng "bình thường" để sau này phát hiện bất thường.
Monitoring: từ kiểm tra thủ công đến giám sát tự động
Có ba cấp độ trưởng thành:
- Reactive (bị động) — chờ ai đó báo lỗi rồi mới đi sửa. Đây là nơi phần lớn tổ chức Việt Nam đang đứng.
- Proactive testing (chủ động kiểm thử) — chạy các test tự động sau mỗi lần pipeline chạy (ví dụ
dbt test), fail thì chặn dữ liệu xấu lại. - Data observability (quan sát dữ liệu) — hệ thống tự học "trạng thái bình thường" và cảnh báo khi có bất thường về khối lượng (volume), độ tươi (freshness), schema, và phân phối — kể cả những lỗi bạn chưa từng nghĩ tới. Chủ đề observability sâu hơn sẽ nằm ở Bài 54, nên ở đây ta tập trung vào testing và monitoring nền tảng.
Tình huống thực tế
Ví dụ 1 — Tiki và cú "bốc hơi" doanh thu do lỗi timeliness
Giả định một tình huống rất hay gặp ở các sàn thương mại điện tử như Tiki. Đội BI có một dashboard "GMV realtime" mà ban lãnh đạo nhìn mỗi sáng. Một buổi sáng thứ Hai sau đợt sale 6.6, dashboard hiển thị GMV ngày Chủ nhật chỉ bằng 40% so với dự kiến. Cả phòng kinh doanh hoảng loạn, họp khẩn.
Sau hai tiếng điều tra, hóa ra không phải bán hàng sụt giảm. Một job đồng bộ dữ liệu từ hệ thống đơn hàng vào warehouse bị treo lúc 2 giờ sáng, nên phần lớn đơn của Chủ nhật chưa chảy vào. Đây thuần túy là lỗi timeliness/freshness, không phải lỗi kinh doanh.
Bài học: Nếu đội đã đặt một freshness check đơn giản — "bảng orders phải có bản ghi mới trong vòng 60 phút gần nhất" — hệ thống đã cảnh báo lúc 3 giờ sáng, và số liệu trên dashboard đã được gắn nhãn "dữ liệu chưa đầy đủ" thay vì để lãnh đạo hiểu lầm. Một dòng cảnh báo tự động rẻ hơn rất nhiều so với hai tiếng họp khẩn của cả ban giám đốc.
Ví dụ 2 — Ngân hàng số và bài toán uniqueness trong Customer 360
Một ngân hàng số tại Việt Nam (bối cảnh giả định) xây dựng "Single View of Customer" để chạy chiến dịch cross-sell. Đội marketing gửi email ưu đãi vay tiêu dùng và nhận phản hồi giận dữ: nhiều khách nhận cùng một email tới 3 lần, có người nhận ưu đãi "khách hàng mới" dù đã dùng dịch vụ 5 năm.
Nguyên nhân: dữ liệu khách hàng đến từ ba nguồn — app, chi nhánh, và tổng đài — mỗi nguồn tạo một bản ghi riêng cho cùng một người. Lỗi uniqueness. Con số "2,1 triệu khách hàng" mà ban lãnh đạo tự hào thực chất chỉ là khoảng 1,4 triệu người thật sau khi khử trùng lặp — sai lệch 50%.
Đội data đã xử lý bằng cách: (1) thêm uniqueness check trên khóa nghiệp vụ ghép số CMND/CCCD + ngày sinh; (2) xây một bảng monitoring đếm số bản ghi trùng mỗi ngày; (3) đặt cảnh báo khi tỷ lệ trùng vượt 2%.
Bài học: Một chỉ số "tăng trưởng ấn tượng" có thể chỉ là lỗi uniqueness được tô vẽ. Đo lường chất lượng đôi khi làm con số đẹp xẹp xuống — nhưng đó là con số thật, và quyết định dựa trên nó mới đáng tin.
Ví dụ 3 — Chuỗi F&B và validity của dữ liệu nhập tay
Một chuỗi cà phê 80 cửa hàng nhập doanh thu ngày qua form Google Sheet do quản lý ca điền tay. Khi đội phân tích tổng hợp, họ thấy một cửa hàng báo doanh thu 450 triệu/ngày — cao gấp 30 lần bình thường. Hóa ra quản lý gõ nhầm, thêm một số 0. Lỗi validity (giá trị vượt ngoài khoảng hợp lý nghiệp vụ).
Vấn đề là con số này đã chảy vào báo cáo tuần gửi cho nhà đầu tư trước khi ai đó phát hiện. Sau sự cố, đội thêm validity check: doanh thu mỗi cửa hàng phải nằm trong khoảng [trung bình 30 ngày × 0,3, trung bình 30 ngày × 3], ngoài khoảng thì pipeline giữ lại và gửi cảnh báo Telegram cho người phụ trách xác nhận.
Bài học: Dữ liệu nhập tay là nguồn lỗi validity lớn nhất. Đặt các "ngưỡng hợp lý nghiệp vụ" (business rule check) ngay tại điểm dữ liệu vào là cách rẻ và hiệu quả nhất để chặn lỗi ngớ ngẩn nhưng đắt giá.
Hướng dẫn từng bước
Đây là quy trình triển khai một hệ thống đo lường và giám sát data quality từ con số 0, áp dụng được cho một team nhỏ.
Bước 1 — Chọn bảng ưu tiên, đừng ôm hết. Đừng cố đo mọi bảng. Chọn 3–5 bảng "critical" mà nếu sai sẽ ảnh hưởng trực tiếp đến quyết định hoặc tiền bạc: bảng đơn hàng, bảng khách hàng, bảng doanh thu. Đây là nguyên tắc 80/20.
Bước 2 — Profiling để hiểu trạng thái bình thường. Với mỗi bảng, chạy profiling: tỷ lệ NULL từng cột, min/max, số giá trị phân biệt, phân phối. Ghi lại các ngưỡng bình thường. Đây là baseline để so sánh về sau.
Bước 3 — Ánh xạ từng cột quan trọng vào 6 chiều DAMA. Với mỗi cột, tự hỏi: cột này cần accurate, complete, unique, valid tới mức nào? Ví dụ customer_id: phải unique 100%, không NULL. email: phải valid định dạng, completeness kỳ vọng 90%.
Bước 4 — Viết check dưới dạng test tự động. Mỗi kỳ vọng ở Bước 3 biến thành một test SQL trả về số dòng vi phạm. Nếu bạn đã dùng dbt (Bài 9), tận dụng ngay các test có sẵn: not_null, unique, accepted_values, relationships, và các package như dbt_utils, dbt_expectations cho các check phức tạp hơn (freshness, khoảng giá trị, phân phối).
Bước 5 — Gắn test vào pipeline và đặt hành động khi fail. Quyết định trước: test fail thì (a) chặn dữ liệu (block), (b) cảnh báo nhưng vẫn cho chạy (warn), hay (c) cách ly bản ghi xấu (quarantine). Lỗi nghiêm trọng (customer_id trùng) nên block; lỗi nhẹ (thiếu middle_name) chỉ warn.
Bước 6 — Dựng bảng theo dõi và cảnh báo. Ghi kết quả mỗi lần chạy test vào một bảng data_quality_results (thời gian, bảng, check, tỷ lệ pass). Từ đó dựng một dashboard xu hướng và nối cảnh báo tới Slack/Telegram/email. Việc thấy xu hướng quan trọng hơn thấy một điểm — completeness giảm dần từ 98% xuống 91% trong hai tuần là tín hiệu sớm của một nguồn đang hỏng.
Bước 7 — Thiết lập SLA và người chịu trách nhiệm. Mỗi data product cần một SLA rõ: "freshness dưới 1 giờ, completeness trên 95%", và một owner (liên kết với governance ở Bài 11). Khi vi phạm SLA, ai được ping, ai xử lý, trong bao lâu — phải có sẵn.
Lỗi thường gặp & mẹo
Lỗi 1 — Đo tất cả mọi thứ ngay từ đầu. Kết quả là hàng trăm cảnh báo mỗi ngày, không ai đọc, và "alert fatigue" (mệt mỏi vì cảnh báo) khiến người ta tắt luôn hệ thống. Mẹo: bắt đầu nhỏ với vài check quan trọng, mở rộng dần.
Lỗi 2 — Nhầm lẫn giữa validity và accuracy. Nhiều team dựng đủ validity check rồi tự tin "data sạch", trong khi số điện thoại đúng định dạng nhưng sai người. Mẹo: với accuracy, phải có cơ chế đối chiếu nguồn thật (ví dụ callback xác thực, đối soát với hệ thống lõi).
Lỗi 3 — Chỉ kiểm tra tại cuối pipeline. Khi phát hiện lỗi ở lớp báo cáo, dữ liệu bẩn đã lan khắp nơi. Mẹo: đặt check ngay tại điểm ingest (đầu vào) — "shift left". Chặn rác ở cửa rẻ hơn dọn rác trong nhà.
Lỗi 4 — Ngưỡng cứng nhắc. Đặt "doanh thu phải trên 100 triệu" rồi mùa thấp điểm cảnh báo kêu liên tục. Mẹo: dùng ngưỡng động dựa trên đường trung bình lịch sử (ví dụ ±3 độ lệch chuẩn) thay vì con số cố định.
Lỗi 5 — Đo nhưng không ai chịu trách nhiệm. Dashboard đỏ rực nhưng không ai được giao sửa. Mẹo: mỗi check phải gắn với một owner và một quy trình xử lý. Data quality là môn thể thao đồng đội có tên người trên áo.
Mẹo vàng: Hãy coi data quality là một sản phẩm có "khách hàng" là những người ra quyết định. Hỏi họ: "Con số nào mà nếu sai sẽ khiến anh/chị ra quyết định tồi tệ nhất?" Bắt đầu đo từ đúng con số đó.
Bài tập thực hành
- Chọn một bảng thật. Lấy một bảng quan trọng trong công ty bạn (hoặc dữ liệu mẫu về đơn hàng). Với mỗi cột, điền vào bảng 6 chiều DAMA: chiều nào áp dụng, kỳ vọng bao nhiêu phần trăm.
- Viết 6 check. Với mỗi chiều DAMA, viết ít nhất một câu SQL đếm số dòng vi phạm. Ví dụ completeness:
SELECT COUNT(*) FROM orders WHERE customer_id IS NULL. Chạy thử và ghi lại tỷ lệ pass thực tế — bạn có thể sẽ bất ngờ.
- Tính Data Quality Score. Gán trọng số cho 6 check (tổng bằng 100%), tính điểm tổng hợp cho bảng. Bảng của bạn đang xanh, vàng hay đỏ?
- Thiết kế một cảnh báo. Chọn một check quan trọng nhất và mô tả: điều kiện nào kích hoạt cảnh báo, gửi cho ai, qua kênh nào, người đó phải làm gì trong bao lâu. Viết thành một đoạn SLA ngắn 3–4 dòng.
- Suy ngẫm. Nhớ lại một lần công ty bạn ra quyết định dựa trên số liệu sau đó phát hiện sai. Lỗi đó thuộc chiều DAMA nào? Một check nào lẽ ra đã bắt được nó?
Tóm tắt
Chất lượng dữ liệu không phải là cảm giác mà là con số đo được. Bộ khung 6 chiều DAMA — Accuracy, Completeness, Consistency, Timeliness, Uniqueness, Validity — cho bạn ngôn ngữ chung để biến câu hỏi mơ hồ "data tốt không?" thành các check SQL cụ thể. Từ các check đó, bạn tổng hợp thành Data Quality Score để giao tiếp với lãnh đạo.
Nhưng đo lường một lần là vô nghĩa. Sức mạnh nằm ở monitoring liên tục: chạy test tự động sau mỗi pipeline, theo dõi xu hướng, đặt cảnh báo thông minh với ngưỡng động, và quan trọng nhất — gắn mỗi vấn đề với một người chịu trách nhiệm và một SLA rõ ràng.
Ba câu chuyện Tiki (timeliness), ngân hàng số (uniqueness) và chuỗi F&B (validity) cho thấy cùng một bài học: lỗi data không được đo lường sẽ âm thầm dẫn cả tổ chức đi sai đường, và cái giá phải trả luôn lớn hơn nhiều lần chi phí dựng một hệ thống giám sát. Hãy bắt đầu nhỏ, đo đúng con số quan trọng nhất, và mở rộng dần. Ở Bài 13 tiếp theo, chúng ta sẽ bước sang một khía cạnh khác của việc "làm chủ dữ liệu": quyền riêng tư và tuân thủ PDPL Việt Nam.