Khử trùng là gì?

Khử trùng được định nghĩa mà không cần phun tay

Khử trùng là quá trình xác định các hồ sơ đại diện cho cùng một mục, sự kiện hoặc thực thể trong thế giới thực và sau đó áp dụng một chính sách rõ ràng để giữ lại, liên kết, gộp hoặc từ bỏ chúng. Chính sách quan trọng như phương pháp khớp vì hai hàng tương tự không tự động thay thế cho nhau.

Khử trùng chính xác so sánh các giá trị ổn định hoặc dấu vân tay. Khử trùng theo khóa sử dụng một hoặc nhiều trường để xác định thực thể. Các phương pháp mờ so sánh tên, địa chỉ, mô tả, hoặc các thuộc tính không hoàn hảo khác và tạo ra một điểm số phải được diễn giải so với chi phí của một khớp sai. Ranh giới chính thức tương thích với ràng buộc tính duy nhất của PostgreSQL, điều này hữu ích khi cùng một thuật ngữ được sử dụng một cách lỏng lẻo trong các cuộc thảo luận về sản phẩm.

Khử trùng không có nghĩa là xóa mọi giá trị lặp lại. Hai đơn hàng hợp lệ có thể chia sẻ một khách hàng và tổng, hai trang có thể lặp lại một tiêu đề sản phẩm, và hai sự kiện có thể mang cùng một payload ở những thời điểm khác nhau. Danh tính, thời gian quan sát, và quy mô kinh doanh quyết định xem sự lặp lại có phải là trùng lặp hay không. Việc đặt tên ranh giới ngăn các nhóm yêu cầu khái niệm cung cấp các bảo đảm thuộc về lưu trữ, lập lịch, bảo mật, hoặc chính sách kinh doanh.

Cách các ứng viên trùng lặp biến thành một hồ sơ

Một con đường khử trùng đáng tin cậy tách biệt việc tạo ứng viên, so sánh, quyết định, và sự tồn tại. Việc gộp những giai đoạn đó thành một chức năng không rõ ràng làm cho việc chẩn đoán các gộp sai trở nên khó khăn và ngăn cản các nhà xem xét thấy bằng chứng nào đã dẫn đến kết quả.

1. Chỉ chuẩn hóa các trường cần thiết cho việc so sánh trong khi bảo tồn các giá trị gốc. Giai đoạn này nên phơi bày đầu vào, quyết định, đầu ra, và chủ sở hữu của nó để một cuộc điều tra sau này có thể phân biệt giữa vấn đề nguồn và vấn đề xử lý.
2. Tạo ứng viên với các khóa chặn để các hồ sơ không liên quan không được so sánh một cách toàn diện. Giai đoạn này nên phơi bày đầu vào, quyết định, đầu ra, và chủ sở hữu của nó để một cuộc điều tra sau này có thể phân biệt giữa vấn đề nguồn và vấn đề xử lý.
3. Chấm điểm mỗi cặp ứng viên bằng bằng chứng chính xác, phát âm, mã thông báo, khoảng cách, hoặc bằng chứng cụ thể theo miền. Giai đoạn này nên phơi bày đầu vào, quyết định, đầu ra, và chủ sở hữu của nó để một cuộc điều tra sau này có thể phân biệt giữa vấn đề nguồn và vấn đề xử lý.
4. Phân loại cặp là khớp, không khớp, hoặc xem xét theo các ngưỡng đã được tài liệu hóa. Giai đoạn này nên phơi bày đầu vào, quyết định, đầu ra, và chủ sở hữu của nó để một cuộc điều tra sau này có thể phân biệt giữa vấn đề nguồn và vấn đề xử lý.
5. Áp dụng chính sách giữ, liên kết, hoặc gộp và giữ lại dòng dõi nguồn phía sau hồ sơ sống sót. Giai đoạn này nên phơi bày đầu vào, quyết định, đầu ra, và chủ sở hữu của nó để một cuộc điều tra sau này có thể phân biệt giữa vấn đề nguồn và vấn đề xử lý.

Các ràng buộc cơ sở dữ liệu có thể ngăn chặn các bản sao chính xác mới, nhưng chúng không giải quyết các hồ sơ lịch sử, biến thể chính tả, định danh đã thay đổi, hoặc các hồ sơ bị chia nhỏ qua các hệ thống. Giải quyết thực thể xử lý các bằng chứng rộng hơn trong khi một ràng buộc duy nhất thực thi một bất biến chặt chẽ hơn tại thời điểm ghi. Một cái nhìn kỹ thuật thứ hai xuất hiện trong API dropDuplicates của Apache Spark. Tham chiếu đó mô tả một mô hình cụ thể thay vì dựa vào phép ẩn dụ.

Khử trùng chính xác, theo khóa và mờ

Các phương pháp chính xác dễ giải thích hơn, trong khi các phương pháp không rõ ràng bao phủ danh tính rối rắm. Nhiều hệ thống sử dụng một chuỗi: định danh xác định trước, khóa chuẩn hóa chính xác sau, và so sánh điểm chỉ cho các ứng viên chưa được giải quyết.

So sánh là một phương tiện hỗ trợ quyết định, không phải là một bậc thang trưởng thành. Một tùy chọn nhỏ hơn hoặc đơn giản hơn có thể đúng khi hợp đồng của nó khớp với khối lượng công việc, trong khi một tùy chọn phức tạp hơn tạo ra chi phí nếu đội ngũ không thể vận hành hoặc kiểm tra nó.

Nơi mà Kiểm Soát Trùng Lặp Có Lợi

Giá trị xuất hiện khi người dùng downstream cần một cái nhìn thực thể ổn định, một số sự kiện, hoặc một danh sách hiện tại. Chi phí xuất hiện khi một sự hợp nhất giả mạo xóa một sự phân biệt hợp pháp, vì vậy chính sách khớp phải tuân theo ngữ cảnh kinh doanh. Mỗi trường hợp sử dụng cần một người tiêu dùng được đặt tên, một nguồn được chấp nhận, và một điều kiện thành công có thể đo lường. Nếu thiếu ba chi tiết đó, công việc thực hiện có xu hướng tối ưu hóa hoạt động thay vì kết quả.

Chọn Khóa Khớp và Quy Tắc Sinh Tồn

Bắt đầu với danh tính và hệ quả. Định nghĩa thực thể, liệt kê các định danh đáng tin cậy, mô tả các khuyết điểm cụ thể của nguồn, và quyết định xem một cặp không chắc chắn có nên giữ riêng biệt hay không hoặc vào đánh giá.

• Khai báo ngữ cảnh. Nêu rõ liệu một hồ sơ có nghĩa là một thực thể, phiên bản, sự kiện, danh sách, hay quan sát.
• Giữ lại các định danh nguồn. Một hồ sơ vàng không nên xóa các khóa cần thiết để truy tìm hoặc hoàn tác một sự hợp nhất.
• Tách biệt việc khớp với việc hợp nhất. Một khớp có khả năng có thể được liên kết mà không ngay lập tức ghi đè lên bất kỳ hồ sơ nào.
• Chỉnh sửa trên các cặp được gán nhãn. Ngưỡng nên phản ánh chi phí thực tế của các trường hợp dương tính giả và âm tính giả.
• Làm cho quyết định có thể đảo ngược. Lưu giữ lịch sử hợp nhất và đủ bằng chứng để tách một cụm xấu.

Đánh giá cấp cụm là quan trọng vì các cặp khớp có thể tạo ra chuỗi. Nếu A khớp với B và B khớp với C, hệ thống vẫn cần quyết định liệu cả ba có thuộc về một thực thể. Các ràng buộc liên quan trong RFC 8785 chuẩn hóa JSON cung cấp một tham chiếu chính khác cho khả năng tương tác, dữ liệu, hoặc giả định thực thi đằng sau sự lựa chọn.

Một thiết kế sản xuất nên tài liệu hóa trạng thái ổn định và con đường thay đổi. Các đội ngũ cần biết cách một trường mới, công nhân, triển khai, lịch trình, hoặc người tiêu dùng vào hệ thống; cách tương thích được đánh giá; và bằng chứng nào cho phép một sự thay đổi được chấp nhận hoặc từ chối.

Lỗi Deduplịch Làm Hỏng Dữ Liệu

Hầu hết các khuyết tật gây hại đến từ việc giả định một trường tiện lợi là một định danh vĩnh viễn. Tên, tiêu đề, địa chỉ, và URL có thể thay đổi hoặc được chia sẻ, trong khi một khóa nguồn được cho là duy nhất có thể thiếu hoặc được tái chế.

• Xóa bỏ trước khi xác định danh tính. Một trường lặp lại được coi là một hồ sơ trùng lặp mà không xem xét ngữ cảnh.
• Việc chuẩn hóa quá mức văn bản so sánh. Các biến thể sản phẩm hoặc con người khác nhau lại sụp đổ thành cùng một token.
• Một ngưỡng toàn cầu. Các nguồn khác nhau và các loại thực thể nhận cùng một chính sách rủi ro.
• Không có trạng thái không chắc chắn. Mỗi cặp bị ép buộc vào khớp hoặc không khớp mặc dù bằng chứng yếu.
• Mất nguồn gốc. Hàng còn sống không thể được truy tìm đến các nguồn đóng góp của nó.

Khi số lượng thay đổi bất ngờ, hãy xem xét việc tạo ứng viên, bằng chứng cặp, phiên bản ngưỡng, tạo cụm, và sinh tồn một cách riêng biệt. Bắt đầu với lớp có trách nhiệm nhỏ nhất, so sánh trạng thái mong đợi và quan sát, và giữ hành động khắc phục liên kết với bằng chứng. Cách tiếp cận đó tránh các hướng dẫn mơ hồ để thêm năng lực hoặc nới lỏng xác thực.

Deduplik hóa Hồ Sơ Web Đã Thu Thập

Dữ liệu web đã thu thập thường lặp lại vì các trang chồng chéo, URL mang các tham số theo dõi, danh sách xuất hiện trong nhiều danh mục, và các lần ghi lại theo lịch quan sát cùng một thực thể theo thời gian.

Đối với đầu vào web công khai, hồ sơ thu thập nên bao gồm URL đã yêu cầu, URL cuối, thời gian thu thập, chế độ phản hồi, và một kiểm tra nội dung trước khi quá trình downstream bắt đầu. Scrapeless Agent Browser xử lý phiên trình duyệt được quản lý; ứng dụng vẫn nắm quyền phê duyệt nguồn, bộ chọn, giới hạn khối lượng công việc, mức giữ, và ý nghĩa của trường.

Chỉ chuẩn hóa các phần URL đã được tài liệu, giữ thời gian thu thập và phân biệt một thực thể lặp lại với một quan sát lặp lại. Một bảng trạng thái hiện tại có thể giữ một hàng cho mỗi danh sách, trong khi một bảng quan sát giữ mọi trạng thái có thời gian có ý nghĩa. Giữ chứng cứ thô tách biệt với đại diện được biên soạn khi tình huống sử dụng yêu cầu có thể kiểm tra.

Lớp thu thập chứng minh trang nào đã được lấy; lớp loại bỏ trùng lặp xác định danh tính; người sử dụng chọn xem các bản ghi liên kết có trở thành một cái nhìn hiện tại hay giữ lại chứng cứ lịch sử riêng biệt. Sự tách biệt này cũng làm cho chi phí và sự thất bại trở nên rõ ràng. Thu thập, chuyển đổi, xác thực, lưu trữ và giao hàng có thể được đo lường độc lập thay vì bị ẩn trong một trạng thái công việc.

Danh sách kiểm tra sẵn sàng loại bỏ trùng lặp

Sử dụng những câu hỏi này trong quá trình xem xét thiết kế. Các câu trả lời viết ra làm lộ sự bất đồng sớm và cung cấp cho người xem xét một cơ sở ổn định để kiểm tra việc thực hiện.

• Một hàng đại diện cho điều gì trong thế giới thực?
• Những định danh nào ổn định trong mỗi nguồn?
• Những trường nào có thể thay đổi mà không tạo ra một thực thể mới?
• Chi phí của việc hợp nhất sai là bao nhiêu?
• Cặp nào cần xem xét?
• Các cụm được hình thành như thế nào từ các quyết định của cặp?
• Có thể đảo ngược một lần hợp nhất không?
• Những chỉ số nào được tính từ sự thật được gán nhãn?

Quá trình sẵn sàng khi người xem xét có thể tái tạo một sự khớp, giải thích một sự không khớp và phục hồi các bản ghi sau một lần hợp nhất sai sót. Xem lại các câu trả lời khi khối lượng, hành vi của nguồn, mong đợi của người tiêu dùng hoặc ranh giới dịch vụ thay đổi. Một thiết kế phù hợp với một lô thí nghiệm có thể không phù hợp với một con đường sản xuất liên tục.

Kết luận: Loại bỏ trùng lặp cần một hợp đồng danh tính

Loại bỏ trùng lặp biến các bản ghi lặp lại hoặc mâu thuẫn thành một quyết định danh tính rõ ràng. Hệ thống an toàn bắt đầu với hạt, sử dụng chứng cứ xác định khi có thể, cô lập các trường hợp không chắc chắn, bảo tồn nguồn gốc và đánh giá kết quả dựa trên các ví dụ được gán nhãn. Mục tiêu không phải là số hàng nhỏ nhất; đó là sự đại diện chính xác nhất của các thực thể và quan sát.

Bước thực tế tiếp theo là viết hợp đồng nhỏ nhất có thể kiểm tra cho một khối lượng công việc thực tế, thu thập chứng cứ tại mỗi ranh giới và mở rộng chỉ sau khi hành vi đo lường phù hợp với hợp đồng đó.

Tài liệu tham khảo

• Tài liệu tích hợp Trình duyệt Agent Scrapeless
• Tổng quan sản phẩm Trình duyệt Agent Scrapeless
• Quy trình văn bản web sạch Scrapeless cho RAG
• Dự án mã nguồn mở Scrapeless trên GitHub