Khớp, gộp và giữ lại

🌐 Cũng có bằng 28 ngôn ngữ khác

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Hình ảnh được tạo bằng AI

Được dịch bằng AI. Cộng đồng chưa xem xét. Đọc bằng tiếng Anh

Mô-đun 3 trong 6 của chương Dữ liệu chủ và danh tính, chương 6 của khóa học Data Architect. Mỗi mô-đun có thể đọc độc lập. Trước: Bốn cách quản lý dữ liệu chủ · Tiếp theo: Bản đồ không phải là quyết định

Câu hỏi mô-đun này trả lời: Làm sao tìm ra bản trùng, và quyết định giá trị nào được giữ lại?

Salesforce có hai liên hệ: Daniel Reyes, Dallas, d.reyes@example.com, và Dan Reyes, Dallas, d.reyes@example.com. Cùng một người? Có lẽ vậy. Chúng ta có nên gộp chúng không? Đó là một câu hỏi khác. Và nếu gộp, số điện thoại, địa chỉ và chức danh nào được giữ lại? Lại là một câu hỏi khác nữa. Kiến trúc sư cần tách bạch ba quyết định:

• Khớp: những bản ghi này có đại diện cho cùng một thứ không?
• Gộp: chúng có nên trở thành một bản ghi không?
• Giữ lại: nếu kết hợp dữ liệu, giá trị nào thắng?

Khớp đến trước

Chương 3 đã trình bày quy tắc trùng lặp và quy tắc khớp của Salesforce, nên tôi sẽ không dạy lại cơ chế. Câu hỏi kiến trúc là bằng chứng nào đủ mạnh để nói rằng những thứ này có thể là một? Với một người: email, điện thoại, tên cộng địa chỉ, mã khách hàng, hoặc một tổ hợp nào đó. Với một công ty: tên pháp lý, mã số thuế, ID khách hàng ERP, địa chỉ, tên miền web. Không phải “Salesforce có so sánh được các trường này không?” mà là “tổ hợp nào cho chúng ta đủ tự tin để hành động?”

Và chính xác không có nghĩa là chắc chắn. Một email trùng nhau là tín hiệu mạnh, không phải bằng chứng: các gia đình dùng chung địa chỉ, doanh nghiệp dùng purchasing@company.com, số điện thoại thuộc về cả hộ gia đình, tên và địa chỉ không duy nhất, và ngay cả những mã định danh mạnh cũng bị dùng lại, gõ sai hay tái sử dụng. Việc khớp không phải là so sánh chuỗi ký tự. Đó là một tuyên bố về danh tính.

Cái giá của việc sai

Khi dạy phần này, tôi đổi lĩnh vực. Trong dữ liệu marketing ô tô, chúng ta quyết định sai rằng hai Daniel Reyes là cùng một người, và người sai nhận được ưu đãi mua một chiếc SUV. Không hay, nhưng rủi ro thấp. Giờ hãy mắc cùng lỗi khớp sai đó trong dữ liệu y tế: lịch sử bệnh án của hai người khác nhau bị trộn lại. Cùng một lỗi khớp, hệ quả hoàn toàn khác. Đó là lý do không có một ngưỡng khớp “tốt” chung cho mọi trường hợp. Đôi khi rủi ro lớn hơn là bỏ sót một lần khớp; đôi khi là trộn hai người không phải là một. Ở nơi khớp sai tốn kém, tôi cố ý khớp ít.

Hài hòa hóa, rồi khớp, rồi hợp nhất

Việc khớp cũng phụ thuộc vào hình dạng của dữ liệu. AZ, Arizona, Ariz.; 6025550198, (602) 555-0198, +1 602 555 0198. Hài hòa hóa làm cho các giá trị so sánh được: định dạng chuẩn, chữ viết tắt được chuẩn hóa, mã được ánh xạ. Rồi bạn mới khớp. Chỉ sau khi biết các bản ghi thuộc về nhau, bạn mới hợp nhất thông tin của chúng thành một biểu diễn. Hài hòa hóa không phải là khớp, khớp không phải là gộp, và hợp nhất không nhất thiết là quản lý dữ liệu chủ.

Click to enlarge

Các quyết định về danh tính diễn ra theo từng giai đoạn.

Khớp không đòi hỏi phải gộp

Đây là một trong những sự phân biệt quan trọng nhất của chương. Chúng ta tự tin rằng hai bản ghi khách hàng từ hai hệ thống cũ là cùng một công ty. Chúng ta có phải gộp chúng không? Không. Mỗi bản ghi có thể mang một danh tính của hệ thống nguồn; các giao dịch lịch sử có thể trỏ đến từng bản ghi; kiểm toán viên có thể cần dấu vết; chúng ta có thể vẫn đang chuyển đổi dữ liệu; chúng ta có thể cần biết chính xác hệ thống cũ đã nói gì. Biết hai bản ghi là cùng một thứ không buộc chúng ta phải gộp chúng lại. Chúng ta có thể liên kết chúng, và đó thường là kiến trúc an toàn hơn.

Quy tắc gộp của tôi: một bên thắng rõ ràng

Lập trường của tôi: chỉ gộp khi có một bên thắng rõ ràng và bản trùng không mang thêm gì bạn cần giữ. Một nhân viên kinh doanh tạo một tài khoản trùng hôm qua; bản gốc rõ ràng là bản ghi đã được thiết lập. Ứng viên tốt để gộp. Giờ thay đổi tình huống: chúng ta đã nhập khách hàng từ một hệ thống cũ, với ID riêng, giá trị cũ hơn, có thể có giao dịch hay yêu cầu kiểm toán gắn với chúng. Tôi thận trọng hơn nhiều. Hãy giữ các bản trùng từ những lần nạp bên ngoài khi bạn có thể cần truy ngược về các giá trị cũ hơn, vì việc gộp phá hủy lịch sử đó.

Việc gộp trong Salesforce thực sự làm gì

Một liên kết nói “những thứ này thuộc về nhau”. Một lần gộp nói “những thứ này giờ là một”, và trên Salesforce đó là một thay đổi thật sự. Với tài khoản, bạn chọn tối đa ba bản ghi và chọn một làm bản ghi chính (principal); bạn chọn giữ giá trị trường nào từ các bản ghi kia, trong khi các trường ẩn và chỉ đọc lấy từ bản ghi chính. Bản ghi sau khi gộp giữ Created By và Created Date của bản ghi cũ nhất, bất kể bản nào là bản ghi chính. Các bản ghi không phải bản ghi chính vào Thùng rác. Các bản ghi liên quan như hoạt động chuyển sang bản ghi đã gộp, với một số ngoại lệ. Trong Lightning, việc gộp hoạt động trên các bản trùng mà quy tắc trùng lặp của bạn phát hiện. Và với tài khoản cá nhân, các đối tượng contact point không hỗ trợ gộp: các quan hệ của chúng bị mất (Considerations for Merging Duplicate Accounts (opens in a new tab); Merge Duplicate Accounts in Lightning Experience (opens in a new tab), tiếng Anh).

Kiến thức hay ra thi. Hãy biết một lần gộp tài khoản trong Salesforce làm gì: tối đa ba bản ghi; một bản ghi chính (principal), có các trường ẩn và chỉ-đọc được giữ lại; Created By và Created Date của bản ghi cũ nhất được giữ, bất kể bản ghi nào là bản ghi chính; các bản ghi còn lại vào Thùng rác; và với tài khoản cá nhân, các đối tượng điểm liên lạc (contact point) không được gộp.

Bạn không cần biết mọi trường hợp đặc biệt để ra quyết định. Bạn cần biết hệ quả: sau một lần gộp, các bản ghi độc lập mà bạn bắt đầu đã không còn nữa. Phép thử khả năng đảo ngược của chương 1 được áp dụng: liên kết dễ hoàn tác; gộp thì không. Và một khách hàng hiếm khi đứng một mình: liên hệ, trường hợp, cơ hội, tệp, bản ghi đồng ý, bản ghi con tùy chỉnh, ID bên ngoài, tham chiếu tích hợp. Trước khi gộp bản ghi cha, hãy hiểu chuyện gì xảy ra với mọi thứ gắn vào nó. Khi bản trùng đến cùng một đợt nạp dữ liệu, tôi cho các đội ba lựa chọn cho các bản ghi con: chuyển chúng sang bản ghi được giữ lại; hoàn toàn không nạp chúng, nếu không ai cần; hoặc giữ chúng trên bản ghi kia, đánh dấu là không hoạt động, để chúng vẫn hiện ra khi tìm kiếm. Lựa chọn đầu tiên là điều một lần gộp làm cho bạn. Hai lựa chọn còn lại giữ được dấu vết, và đó thường chính là mục đích.

Giữ lại: giá trị nào thắng?

Các bản ghi thuộc về nhau, nhưng chúng bất đồng: Salesforce và hệ thống thanh toán nói 602-555-0100, ERP nói 602-555-0188. Các quy tắc giữ lại (survivorship) chọn bên thắng. Những quy tắc phổ biến: mới nhất (lần cập nhật sau cùng), phổ biến nhất (giá trị mà nhiều nguồn đồng ý nhất), và ưu tiên nguồn (tin nguồn này hơn nguồn kia), cộng với các tổ hợp, ngưỡng, trọng số và quy tắc riêng của nghiệp vụ. Không quy tắc nào tự nó là đúng.

“Mới nhất” không phải là một thiết lập kỹ thuật. Đó là một tuyên bố về sự tin cậy: khi các hệ thống bất đồng, giá trị mới nhất có nhiều khả năng đúng hơn. Hợp lý với số di động. Tệ hại với tên pháp lý: nếu ERP sở hữu nó, tôi không quan tâm ai đó vừa thay đổi bản sao trong Salesforce năm phút trước. “Phổ biến nhất” giả định sự đồng thuận là bằng chứng, nhưng ba bản sao cũ ở phía sau không thể thắng phiếu nguồn gốc. “Ưu tiên nguồn” nói thẳng ra: chúng ta tin nguồn này hơn. Vì vậy quy tắc giữ lại thuộc về kiến trúc và quản trị, và mỗi quy tắc cần một chủ sở hữu. Ai đã quyết định địa chỉ mới nhất thắng, hay ERP xếp trên Salesforce?

Nếu bản đồ thẩm quyền của mô-đun 1 đã nói ERP sở hữu hạn mức tín dụng, việc giữ lại thật dễ: ERP thắng, không cần cách chấm điểm khéo léo nào. Những trường hợp khó là các thuộc tính có thẩm quyền được chia sẻ, không rõ ràng hay dựa trên bằng chứng thay vì một bên quản lý chủ. Đó là nơi quy tắc giữ lại chứng tỏ giá trị.

Click to enlarge

Quy tắc giữ lại là những tuyên bố về sự tin cậy.

Ngưỡng, xem xét và làm giàu dữ liệu

Một số cách khớp cân nhắc bằng chứng: khớp ID khách hàng là rất mạnh, email là mạnh, điện thoại là trung bình, tên tương tự là yếu, địa chỉ tương tự là hỗ trợ. Trên một mức điểm là khớp; dưới một mức khác là khác nhau; ở giữa thì một người xem xét. Thuật toán không phải là bài học. Ngưỡng là mức chịu đựng sai sót của bạn, và nó nên đi theo rủi ro nghiệp vụ. Và khi bằng chứng đặt ra câu hỏi mà không giải quyết được nó, đừng giả vờ hệ thống biết. Hãy chuyển nó đi xem xét. Chậm hơn, và điều đó không sao: tự động hóa chẳng có giá trị khi nó tự tin gộp hai khách hàng khác nhau.

Làm giàu dữ liệu thêm một câu hỏi về nguồn gốc. Dữ liệu tham chiếu bưu chính, mã ngành, thông tin doanh nghiệp, điểm rủi ro bên ngoài cải thiện dữ liệu chủ, nhưng mỗi giá trị đến từ đâu, nó đáng tin và mới đến đâu, chúng ta có được dùng nó cho mục đích này không, nó có chứa dữ liệu cá nhân không? “Ngành = Vận tải” từ một nhà cung cấp dữ liệu không giống với việc khách hàng tự nói với bạn. Hãy giữ sự phân biệt đó.

Steve Trucking: tương tự không phải là giống nhau

Hai Đối tác bán lẻ gửi hàng đến John Smith, 123 Main Street, Columbus, với cùng một số điện thoại. Cùng một người? Có lẽ vậy. Steve Trucking có nên hợp nhất họ không? Hãy nhớ họ là của ai: những Người nhận đó là khách hàng của các đối tác, và một đối tác không bao giờ được thấy khách hàng của đối tác khác. Một lần khớp sai sẽ trộn dữ liệu vượt qua ranh giới đó. Bỗng nhiên đó không còn là câu hỏi về chất lượng dữ liệu mà là câu hỏi về quyền riêng tư và sự cô lập, chính là lý do ngưỡng phụ thuộc vào hệ quả. Điểm kiểm tra sẽ đưa ra quyết định. Hiện tại: đừng để sự tiện lợi của việc khớp đưa ra quyết định nghiệp vụ.

Đôi khi giữ lại sự lộn xộn cho bạn biết điều gì đó. Bản ghi này đến từ hệ thống cũ, bản kia từ Salesforce, bản này từ công ty được mua lại; ID của chúng, lịch sử của chúng và việc chúng bất đồng đều có thể quan trọng. Dữ liệu sạch có giá trị. Khả năng truy vết cũng vậy. Kiến trúc sư quyết định cái nào quan trọng hơn cho mục đích sử dụng.

Ngoài kỳ thi: AI thay đổi điều gì. Một lần khớp sai trước đây có nghĩa là hai email hay một lịch sử dịch vụ bị chia tách. Giờ một tác tử tìm ra thứ nó nghĩ là khách hàng và kéo ra đơn hàng, trường hợp, địa chỉ và ghi chú của họ. Nếu hai người bị khớp sai, nó có thể hành động dựa trên thông tin của người này cho người kia. Quyết định khớp đã trở thành một phần của ranh giới bảo mật, và ở nơi việc trộn lẫn tốn kém, khớp chặt hơn là thiết kế an toàn hơn.

Kiến trúc sư quyết định gì ở đây

• Bằng chứng nào là đủ để đánh dấu một bản trùng khả dĩ trong từng miền dữ liệu.
• Một lần khớp đã xác nhận trở thành gộp, liên kết hay xem xét bởi con người.
• Giá trị nào được giữ lại khi có bất đồng, và ai sở hữu từng quy tắc giữ lại.
• Nghiệp vụ chịu đựng được bao nhiêu rủi ro khớp sai so với rủi ro bỏ sót.
• Những danh tính nguồn, lịch sử và bản ghi liên quan nào phải được giữ lại trước bất kỳ lần gộp nào.

Khớp cẩn thận, gộp có chủ ý, chọn quy tắc giữ lại có dụng ý. Một bản ghi khách hàng sạch sẽ chẳng đáng bao nhiêu nếu bạn có được nó bằng cách trộn nhầm các khách hàng.

Tìm hiểu thêm

• Salesforce Help, Considerations for Merging Duplicate Accounts (opens in a new tab) và Merge Duplicate Accounts in Lightning Experience (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.
• Salesforce Help, Things to Know About Duplicate Rules (opens in a new tab) (tiếng Anh), kiểm tra ngày 2026-10-14.