Những lỗi dữ liệu tiềm ẩn vượt qua mọi quy trình làm sạch

--> Những lỗi dữ liệu tiềm ẩn vượt qua mọi quy trình làm sạch - KDnuggets --> Blog Bài viết hàng đầu Giới thiệu Chuyên mục AI Tư vấn nghề nghiệp Thị giác máy tính Kỹ thuật dữ liệu Khoa học dữ liệu Mô hình ngôn ngữ Học máy MLOps Xử lý ngôn ngữ tự nhiên (NLP) Lập trình Python SQL Tập dữ liệu Sự kiện Tài nguyên Bảng tra cứu tóm tắt Khuyến nghị Tóm tắt công nghệ Quảng cáo Đăng ký nhận bản tin Những lỗi dữ liệu tiềm ẩn vượt qua mọi quy trình làm sạch Bốn lỗi vượt qua mọi bước kiểm tra giá trị rỗng (null), trùng lặp và lược đồ dữ liệu. Tác giả: Nate Rosidi, Chuyên viên Xu hướng thị trường & Nội dung SQL tại KDnuggets, ngày 30/10/2026, chuyên mục Khoa học dữ liệu --> Theo kết quả nghiên cứu của Forrester được IBM trích dẫn trong báo cáo về chất lượng dữ liệu, 25% số tổ chức cho biết chất lượng dữ liệu kém gây thiệt hại hơn 5 triệu USD mỗi năm, và 7% ghi nhận con số này vượt mức 25 triệu USD. Phần lớn những thiệt hại này không bao giờ hiển thị trên các bảng điều khiển theo dõi dữ liệu (dashboard). Các quy trình làm sạch tiêu chuẩn có khả năng phát hiện giá trị rỗng (null), các hàng trùng lặp và sự sai lệch kiểu dữ liệu. Các bước kiểm tra này vận hành nhanh chóng, xử lý được các vấn đề thực tế, nhưng lập tức dừng lại ngay khi mọi cột dữ liệu đều đạt yêu cầu. Tuy nhiên, vẫn có 4 lỗi vượt qua các khâu kiểm tra này và tiếp tục làm sai lệch mô hình, bảng theo dõi hoặc các báo cáo tài chính ở các bước xử lý tiếp theo: các thực thể bị trùng lặp dù không hoàn toàn giống nhau về mặt ký tự, các giá trị nằm trong phạm vi cho phép nhưng phi lý về ngữ cảnh, các mốc thời gian làm rò rỉ thông tin từ tương lai, và mẫu số tính toán loại bỏ những đối tượng có thể làm thay đổi kết quả cuối cùng. Mỗi trường hợp đều xuất hiện trong các câu hỏi phỏng vấn thực tế trên StrataScratch. Dưới đây là những điểm thường bị bỏ sót khi tiếp cận câu hỏi một cách đơn thuần, cùng các nội dung cần kiểm tra thay thế. Khoảng cách giữa Cú pháp, Ngữ nghĩa và Ngữ dụng Các phép kiểm tra chất lượng dữ liệu có thể được phân chia thành ba tầng, dựa theo các khái niệm của ngôn ngữ học. Tầng cú pháp xác định tính chuẩn mực về hình thức của giá trị: mã bưu chính có đủ 5 chữ số hay không, định dạng ngày tháng có thể phân tích được không, cột dữ liệu có mang giá trị rỗng hay không. Tầng ngữ nghĩa xác định tính hợp lý của giá trị đối với đối tượng phản ánh: khách hàng 214 tuổi có thực tế không, việc đăng nhập vào hệ thống lúc 3 giờ sáng từ một cửa hàng đóng cửa lúc 22 giờ có đáng tin cậy hay không. Tầng ngữ dụng xác định liệu cùng một loại giá trị có cần tiêu chí kiểm tra khác nhau tùy thuộc vào đối tượng sử dụng hay không: ví dụ, tại một doanh nghiệp dược phẩm, nhóm nghiên cứu phát triển thuốc và nhóm sản xuất cùng theo dõi một bản ghi nhưng không thống nhất về tiêu chuẩn hợp lệ của dữ liệu. Phần lớn các đường ống dữ liệu (data pipeline) trong môi trường sản xuất hiện nay chỉ dừng lại ở tầng cú pháp. Các phép kiểm tra của Pandera và dbt (các truy vấn SQL dùng để kiểm tra chất lượng dữ liệu) mặc định tập trung vào kiểm tra kiểu dữ liệu, giá trị rỗng và phạm vi giá trị. Đây là các tiêu chí mà một thư viện lập trình thông thường có thể thiết lập mà không cần hiểu biết về nghiệp vụ kinh doanh. Trong khi đó, việc kiểm tra ngữ nghĩa đòi hỏi sự thấu hiểu về bản chất của dữ liệu. Bốn lỗi dưới đây xuất phát từ chính khoảng cách này. Lỗi dữ liệu tiềm ẩn số 1: Trùng lặp thực thể Phép kiểm tra trùng lặp chỉ xác định xem 2 hàng dữ liệu có đồng nhất hoàn toàn về mặt ký tự hay không. Lệnh drop_duplicates() có thể loại bỏ bản ghi "John Smith, 123 Main St" xuất hiện 2 lần, nhưng không thể nhận diện "John Smith, 123 Main St" và "J. Smith, 123 Main Street": đây là 2 hàng dữ liệu có cách viết khác nhau cho cùng một khách hàng, khiến mô hình tính toán giá trị vòng đời khách hàng (lifetime-value) vẫn ghi nhận đây là 2 cá nhân riêng biệt. Phép kiểm tra vẫn đạt yêu cầu do hàng dữ liệu không bị trùng lặp về hình thức, dù thực thể thực tế đã bị nhân đôi. Câu hỏi phỏng vấn của Amazon yêu cầu thực hiện điều ngược lại một cách có chủ đích: từ bảng dữ liệu nhân viên, kết xuất thông tin tên và phòng ban của mỗi nhân viên thuộc bộ phận nhân sự (HR) lặp lại hai lần. Dữ liệu: Bảng nhân viên (worker) gồm 13 nhân viên thuộc các bộ phận HR (Nhân sự), Admin (Hành chính) và Account (Kế toán). Mã nguồn: SELECT first_name, department FROM worker WHERE department LIKE 'HR' UNION ALL SELECT first_name, department FROM worker WHERE department LIKE 'HR'; Output: Câu trả lời chính thức là toán tử UNION ALL. Đó cũng là hiện tượng xảy ra ngoài ý muốn khi hai hệ thống nguồn chuyển cùng một bảng dữ liệu vào kho lưu trữ (warehouse) mà không qua bước khử trùng lặp (dedup) trước khi thực hiện phép liên kết (join). Mọi phép tính tổng (SUM) hoặc đếm (COUNT) ở các bước xử lý sau đều bị nhân đôi, trong khi không có quy trình kiểm tra giá trị rỗng (null check) nào đưa ra cảnh báo. Lỗi này còn phát sinh theo hai cách khác trên nền tảng; ba ví dụ trong phần này sẽ khái quát các phương thức khiến sự trùng lặp xâm nhập vào những chỉ số phân tích đầu ra: các hàng bị trùng lặp, một thực thể bị tính hai lần ở mức độ chi tiết thô hơn, và các hàng bị khớp dư thừa do phép liên kết lỏng. Một câu hỏi từ Microsoft, Apple và Dell yêu cầu sử dụng hàm COUNT(DISTINCT user_id) để xác định lượng người dùng hoạt động hằng tháng: nếu thay bằng COUNT(*) trên cùng một bảng, con số sẽ thay đổi, bởi một người dùng tạo ra 10 sự kiện sẽ bị ghi nhận thành 10 người. Biện pháp khắc phục lỗi này Giải pháp xử lý được triển khai theo cả hai hướng: chuẩn hóa chuỗi ký tự (chuyển sang chữ thường, loại bỏ dấu câu, chuẩn hóa địa chỉ), tính điểm tương đồng thay vì so sánh bằng tuyệt đối, và chuyển các trường hợp nghi vấn vào hàng đợi xét duyệt. Lỗi dữ liệu ngầm số 2: Các giá trị hợp lệ về kỹ thuật nhưng phi thực tế Một giá trị có thể hoàn toàn phù hợp với kiểu dữ liệu của cột, nằm trong phạm vi đã khai báo, nhưng vẫn sai lệch trong ngữ cảnh của hàng dữ liệu đó. Khách hàng 214 tuổi vẫn vượt qua kiểm tra kiểu số nguyên; số lượng hàng giao nhận giá trị âm vẫn vượt qua kiểm tra định dạng số. Để phát hiện được các lỗi này, hệ thống cần áp dụng quy tắc nắm bắt được ý nghĩa nghiệp vụ của số liệu, thay vì chỉ kiểm tra kiểu dữ liệu thuần túy. Câu hỏi từ Amazon, Walmart và Best Buy yêu cầu trích xuất danh sách quản lý có mức lương thấp hơn hai lần mức lương trung bình của các nhân viên cấp dưới trực tiếp, qua đó chỉ ra phương thức lỗi dữ liệu ẩn sâu bên trong một phép tổng hợp thông thường. Dữ liệu: Bảng dim_employee lưu trữ 9 nhân viên, và bảng map_employee_hierarchy đối chiếu từng mã manager_empl_id với mã empl_id của nhân viên báo cáo trực tiếp. Tại đây, hệ thống chỉ sử dụng một phần dữ liệu từ bảng dim_employee: Code: SELECT h.manager_empl_id, managers.salary AS manager_salary, AVG(employees.salary) AS avg_employee_salary FROM map_employee_hierarchy h JOIN dim_employee managers ON h.manager_empl_id = managers.empl_id JOIN dim_employee employees ON h.empl_id = employees.empl_id GROUP BY 1, 2 HAVING managers.salary < 2 * AVG(employees.salary); Output: Truy vấn này không có bất kỳ lỗi cú pháp nào. Chỉ cần một giá trị lương sai sót trong bảng dim_employee — bằng không, mang giá trị âm, hoặc bị nhập theo đơn vị cent thay vì dollar — sẽ làm lệch mức trung bình, từ đó âm thầm loại bỏ hoặc bổ sung thêm các nhà quản lý vào kết quả. Truy vấn đã vượt qua mọi bước kiểm tra cú pháp đầu vào. Lỗi chỉ nằm tại một ô dữ liệu duy nhất. Biện pháp khắc phục lỗi này Giải pháp là áp dụng các ràng buộc gắn liền với nghiệp vụ và các bước kiểm tra tính hợp lý theo nhóm tương đồng, được áp dụng tại i