Kiểm tra Chất lượng Dữ liệu là gì? Quy tắc, Chỉ số và Ví dụ

Kiểm tra Chất lượng Dữ liệu là gì?

Scrapeless Web Unlocker truy xuất nội dung web mà ứng dụng của bạn có thể kiểm tra và xác thực trước khi chấp nhận các bản ghi đã trích xuất vào một tập dữ liệu.

Kiểm tra Chất lượng Dữ liệu là gì?

Một kiểm tra chất lượng dữ liệu là một phép kiểm thử rõ ràng xem dữ liệu có đáp ứng một yêu cầu cho mục đích sử dụng dự kiến hay không. Yêu cầu có thể liên quan đến một trường, một mối quan hệ giữa các bản ghi, hoặc phạm vi bao phủ của cả tập dữ liệu. Một kiểm tra tạo ra bằng chứng: quy tắc nào đã chạy, đầu vào nào được đánh giá, nó quan sát điều gì, và liệu kết quả có đáp ứng điều kiện chấp nhận hay không.

Đối với một catalog được thu thập, một kiểm tra trường có thể yêu cầu mã định danh sản phẩm. Một kiểm tra quan hệ có thể yêu cầu mỗi quan sát tham chiếu đến một sản phẩm đã biết. Một kiểm tra tập dữ liệu có thể yêu cầu mọi danh mục đã được phê duyệt phải có kết quả thu thập được ghi nhận. Vượt qua kiểm tra thứ nhất không nói lên điều gì về hai kiểm tra còn lại. Chất lượng là tập hợp các quyết định gắn với cách sử dụng, chứ không phải một điểm số chung duy nhất.

Tóm tắt

  • Các kiểm tra chất lượng cần một yêu cầu được đặt tên rõ ràng. Một quy tắc không có người chịu trách nhiệm hoặc hệ quả thì khó vận hành.
  • Tính hợp lệ không chứng minh được tính chính xác. Một giá tiền dạng số có thể đúng định dạng nhưng vẫn mô tả sai mặt hàng.
  • Tính đầy đủ bao gồm cả phạm vi nguồn. Các dòng được điền đầy đủ không thể cho thấy những trang chưa bao giờ được thu thập.
  • Các bản ghi lỗi cần một cách xử lý rõ ràng. Cách ly, loại trừ, hoặc điều tra chúng mà không âm thầm thay đổi ý nghĩa của chúng.

Bạn có thể kiểm tra những khía cạnh chất lượng nào?

Các khía cạnh (dimension) chất lượng mô tả những cách khác nhau mà dữ liệu có thể không đáp ứng được mục đích. Tính đầy đủ hỏi liệu thông tin bắt buộc có hiện diện hay không. Tính hợp lệ hỏi liệu một giá trị có tuân theo cấu trúc hoặc quy tắc đã thống nhất hay không. Tính nhất quán hỏi liệu các biểu diễn có liên quan có đồng nhất hay không. Tính duy nhất hỏi liệu khóa dự kiến có xuất hiện như mong đợi hay không. Tính kịp thời hỏi liệu dữ liệu có sẵn trong một khoảng thời gian hữu ích hay không. Tính chính xác hỏi liệu giá trị có tương ứng với đối tượng mà nó tuyên bố mô tả hay không.

Các khía cạnh này chồng lấn, nhưng không thể thay thế cho nhau. Một danh sách đầy đủ các địa chỉ sai thì không chính xác. Một quan sát hiện thời có thể chứa mã tiền tệ không hợp lệ. Một khóa sản phẩm duy nhất có thể trỏ đến một hình ảnh không liên quan. Hãy đặt tên cho khía cạnh để người xử lý biết kiểm tra cung cấp loại bằng chứng nào.

Từ vựng Chất lượng Dữ liệu (Data Quality Vocabulary) phân biệt một khía cạnh chất lượng với một chỉ số đo lường nó. Ở khía cạnh vận hành, tính đầy đủ là mối quan tâm; tỷ lệ mã định danh bắt buộc có mặt trong một lô được định nghĩa là một chỉ số. Ngưỡng và phản ứng nghiệp vụ vẫn là các quyết định thuộc về chủ sở hữu tập dữ liệu.

Khía cạnhKiểm tra catalogGiới hạn
Tính đầy đủCác khóa sản phẩm bắt buộc hiện diệnKhông thể chứng minh mọi trang nguồn đều đã được truy cập
Tính hợp lệSố tiền và đơn vị tiền tệ đáp ứng hợp đồngKhông thể xác nhận ưu đãi được quảng cáo đã được chọn
Tính duy nhấtKhông có khóa quan sát trùng lặpPhụ thuộc vào mức độ chi tiết (grain) của quan sát đã chọn
Tính kịp thờiDữ liệu được chấp nhận đáp ứng hạn chót về độ mớiThu thập gần đây có thể chứa nội dung nguồn cũ
Tính chính xácCác bản ghi đã chọn khớp với bằng chứng nguồnMột mẫu chỉ hỗ trợ phạm vi mà nó nêu rõ

Bạn chuyển một yêu cầu thành một kiểm tra như thế nào?

Một kiểm tra hữu ích chỉ rõ phạm vi, cách tính, điều kiện chấp nhận và hệ quả. Bắt đầu với một yêu cầu đơn giản như: mọi quan sát giá được chấp nhận phải nhận diện được sản phẩm và đơn vị tiền tệ của nó. Sau đó xác định những dòng nào đủ điều kiện, cách biểu diễn giá trị thiếu, và những trường nào tạo thành khóa quan sát.

Phạm vi kiểm soát mẫu số. Nếu một trường chỉ bắt buộc cho các mặt hàng đang được bán, các tin rao đã rút không nên tự động bị tính là lỗi. Ngược lại, loại bỏ mọi dòng khó khỏi mẫu số có thể làm chỉ số trông lành mạnh trong khi giảm tính hữu ích của tập dữ liệu. Hãy giữ quy tắc đủ điều kiện hiển thị cùng với kết quả.

Ngưỡng cần một lý do. Một khóa chính bắt buộc có thể biện minh cho việc từ chối mọi bản ghi bị ảnh hưởng. Một thay đổi nhỏ về phạm vi ảnh được chọn thêm có thể chỉ biện minh cho một cuộc điều tra thay vì dừng cả một lần nạp. Tách biệt các vi phạm hợp đồng nghiêm trọng khỏi tín hiệu bất thường, và ghi rõ ai có thể phê duyệt ngoại lệ.

Một kết quả nên nhận diện phiên bản quy tắc và ranh giới đầu vào. Khi một ngưỡng thay đổi, kết quả lịch sử phải vẫn có thể diễn giải được. Nếu không, một cải thiện có vẻ như vậy có thể phản ánh một quy tắc nới lỏng hơn chứ không phải dữ liệu tốt hơn.

Các kiểm tra nên chạy ở đâu trong quy trình scraping?

Đặt các kiểm tra ở nơi chúng có thể ngăn cách diễn giải sai khỏi việc lan rộng. Ở bước thu thập, xác minh trang hoặc phản hồi dự kiến có hiện diện. Ở bước trích xuất, xác minh các bản ghi ứng viên chứa các mã định danh và nội dung như mong đợi. Ở bước chuẩn hóa, xác minh kiểu dữ liệu, đơn vị, và các giá trị liệt kê. Trước khi giao, xác minh khóa, quan hệ, và phạm vi lô dữ liệu.

Scrapeless Web Unlocker hỗ trợ giai đoạn truy cập trang; nó không thay thế các quy tắc chấp nhận nghiệp vụ của bạn. Các khả năng thu thập nội dung web giúp truy xuất tài liệu để kiểm tra. Ứng dụng của bạn vẫn phải phân biệt một danh mục với một màn hình xin chấp thuận, một bản ghi nguồn với một thẻ điều hướng, và một giá trị vắng mặt với một lỗi bộ phân tích.

Đối với các bộ dữ liệu văn bản, làm sạch văn bản web cho các pipeline truy xuất minh họa lý do tại sao truy xuất trang thành công chỉ là khởi đầu. Menu và thông báo truy cập là văn bản hợp lệ. Chúng trở thành tài liệu huấn luyện hoặc truy xuất tệ khi bị coi như bài viết được định hướng.

Đánh giá chất lượng minh họa trông như thế nào?

Một đánh giá chất lượng kết nối các lỗi quan sát được với một rủi ro cụ thể cho người dùng cuối. Hãy xét một bộ dữ liệu so sánh giá mang tính minh họa, không phải kết quả dịch vụ đã đo đạc. Mỗi bản ghi chứa định danh sản phẩm nguồn, số tiền, loại tiền tệ, tình trạng sẵn có và ngữ cảnh quan sát. Người dùng so sánh các đề nghị cho cùng một mặt hàng trong cùng một thị trường.

Lần đánh giá đầu tiên hỏi liệu định danh có ổn định giữa các lần thu thập hay không. Lần tiếp theo kiểm tra xem số tiền có ở dạng số và loại tiền tệ có được ghi rõ ràng không. Một quy tắc liên trường đánh dấu một giá bán lớn hơn giá thường cho việc kiểm tra nếu điều đó mâu thuẫn với cách hiểu nguồn đã thống nhất. Một kiểm tra độ phủ đối chiếu các danh mục đã phê duyệt với các kết quả duyệt ghi nhận được.

Giả sử một danh mục không cho ra bản ghi nào. Hãy coi đó là một kết quả chưa được giải quyết cho đến khi bằng chứng phân biệt được một danh mục trống với một phản hồi bị chặn hoặc một bộ chọn đã thay đổi. Đừng điền một số 0 lành mạnh chỉ vì bộ trích xuất trả về danh sách rỗng. Một số lượng bằng 0 là một khẳng định về nguồn; một lỗi trích xuất là một khẳng định về quy trình.

Cuối cùng, hãy kiểm tra các bản ghi đã chọn so với bằng chứng được giữ lại khi được phép giữ lại. Các ràng buộc tự động có thể phát hiện những hình dạng không thể xảy ra, nhưng chúng không thể tự mình xác định liệu số tiền thuộc về sản phẩm chính, một mặt hàng gợi ý hay một khoản trả góp tài chính. Ghi lại sự phân biệt mang tính diễn giải đó trong hợp đồng bộ phân tích.

Kiểm tra lược đồ khác gì so với kiểm tra nghiệp vụ?

Kiểm tra lược đồ đánh giá cấu trúc và kiểu được phép, trong khi kiểm tra nghiệp vụ đánh giá ý nghĩa trong phạm vi trường hợp sử dụng. Một bản ghi có thể đáp ứng lược đồ yêu cầu một khóa sản phẩm dạng chuỗi và một số tiền dạng số, nhưng lại trộn các trường từ những sản phẩm khác nhau. Bản ghi đó vượt qua xác thực cấu trúc và thất bại ở phần diễn giải nghiệp vụ.

Các ràng buộc về khóa và mối quan hệ cung cấp một lớp khác. Các quy tắc xác thực của mô hình dữ liệu dạng bảng mô tả các lỗi như khóa chính trùng lặp và tham chiếu khóa ngoại không được giải quyết. Các quy tắc này hữu ích khi các hàng được trích xuất được lắp ráp thành các bảng liên kết, nhưng chúng phụ thuộc vào việc chọn đúng đơn vị hạt và dữ liệu tham chiếu.

Đối với các bộ dữ liệu dạng đồ thị, xác thực hình dạng SHACL có thể biểu diễn các ràng buộc trên các nút và thuộc tính của chúng. Một đồ thị tuân thủ đáp ứng các hình dạng được kiểm tra; tính tuân thủ không phải là bằng chứng rằng mọi phát biểu đều đúng. Giới hạn tương tự áp dụng cho các trình xác thực dạng bảng và lược đồ API.

Các lỗi nên được xử lý và báo cáo như thế nào?

Một kiểm tra thất bại nên dẫn đến một quyết định được ghi lại nhằm bảo vệ người dùng cuối dự kiến. Cô lập các bản ghi bị ảnh hưởng khi các bản ghi khác vẫn hợp lệ và người dùng có thể chấp nhận độ phủ một phần. Giữ toàn bộ phân vùng khi độ phủ bị thiếu có thể khiến so sánh trở nên sai lệch. Giữ lại lý do để các hệ thống hạ lưu không diễn giải một loại trừ như là vắng mặt ở nguồn.

Kho lưu trữ cách ly cần các kiểm soát riêng. Nội dung bị từ chối có thể chứa thông tin cá nhân không cần thiết hoặc bí mật bị ghi lại do vô tình từ một đầu vào. Chỉ giữ những gì phục vụ điều tra, giới hạn quyền truy cập và đặt chính sách xóa. Chẩn đoán chất lượng không nên trở thành một bản sao không hạn chế của mọi phản hồi nguồn.

Các báo cáo nên hiển thị các bản ghi đã được đánh giá, các bản ghi bị ảnh hưởng, danh tính quy tắc, phạm vi nguồn và kết luận xử lý. Một tỷ lệ phần trăm không có mẫu số che giấu quy mô. Một dashboard màu xanh lá không có tuyên bố về độ phủ che giấu các đầu vào bị thiếu. Giữ tách biệt các kết quả được chấp nhận, bị loại trừ, chưa được giải quyết và không khả dụng.

Theo dõi thay đổi theo thời gian theo nguồn và quy tắc thay vì chỉ dựa vào một giá trị trung bình toàn cục. Một tổng hợp có thể che giấu một danh mục bị hỏng khi một danh mục khác tăng trưởng. Gán một người chịu trách nhiệm và một quy trình xem xét trước khi tăng khối lượng thu thập.

Làm thế nào để giữ một bộ kiểm tra hữu ích?

Một bộ kiểm tra vẫn hữu ích khi các quy tắc của nó theo sát yêu cầu thực tế của người dùng và các tín hiệu của nó vẫn có thể giải thích được. Loại bỏ cảnh báo dư thừa, điều chỉnh giả định khi hành vi nguồn thay đổi, và giữ lại các lỗi có ý nghĩa như các ca hồi quy bằng những ví dụ đã được phê duyệt, tối thiểu hóa. Kiểm tra cả quy tắc và đường xử lý kết luận của nó.

Chi phí thu thập chỉ là một phần của bức tranh vận hành. Giá của Scrapeless giúp ước tính chi phí truy cập, trong khi thời gian đánh giá và đầu ra bị từ chối ảnh hưởng đến chi phí trên mỗi bản ghi được chấp nhận. Các quy tắc chấp nhận chặt chẽ khiến phép so sánh đó trở nên khả thi vì mẫu số đại diện cho dữ liệu hữu ích.

Kết luận

Bắt đầu với những lỗi sẽ thay đổi quyết định của người dùng. Biểu đạt mỗi lỗi thành một quy tắc có phạm vi, ghi lại bằng chứng và quyết định ý nghĩa của một thất bại trước khi tải được chạy. Mở rộng bộ kiểm tra khi một kiểu lỗi mới biện minh cho một kiểm tra mới.

Đưa Tầng Thu Thập vào Thực Tiễn

Chọn khả năng thu thập Scrapeless phù hợp với nguồn của bạn, rồi áp dụng các quyết định về xác thực và vận hành được mô tả ở trên.

Đăng ký hôm nay và nhận $5 tín dụng miễn phí — không cần thẻ tín dụng.

Nhận $5 tín dụng của bạn →

FAQ

Xác thực lược đồ có đảm bảo dữ liệu chính xác không?

Không. Xác thực lược đồ xác nhận các yêu cầu cấu trúc được kiểm tra. Độ chính xác cũng phụ thuộc vào việc chọn đúng giá trị nguồn và ghép chúng với thực thể thế giới thực đúng đắn.

Mỗi kiểm tra thất bại có phải đều dừng pipeline không?

Không. Hệ quả phụ thuộc vào rủi ro với người dùng và phạm vi quy tắc. Một hợp đồng định danh bị hỏng có thể biện minh cho việc giữ cả lượt tải, trong khi một bất thường ở trường tùy chọn có thể chỉ biện minh cho việc xem xét.

Một bộ dữ liệu trống có phải là một thất bại về chất lượng không?

Một tập dữ liệu trống cần có lời giải thích cụ thể theo từng nguồn. Nó có thể thể hiện một nguồn thực sự trống, một phạm vi bị loại trừ hoặc một vấn đề thu thập; những kết quả đó nên có các trạng thái được ghi nhận khác nhau.

Sự khác biệt giữa profiling và checking là gì?

Profiling mô tả các đặc điểm quan sát được, trong khi checking đánh giá các đặc điểm đó so với một yêu cầu. Một profile có thể cho thấy một tỷ lệ null bất ngờ; một check quyết định xem tỷ lệ đó có chấp nhận được hay không.

Tài liệu tham khảo