预订应用程序中的客户重复数据删除
Customer Deduplication in Booking Application
我们有一个预订系统，每天有成千上万的预订。因为客户可以在不登录的情况下创建预订，这意味着每次预订都会创建一个新客户 id/row，即使同一位客户之前已经在系统中预订过。这导致大量客户重复。
工程团队决定，为了对客户进行重复数据删除，他们将每天 运行 一个夜间脚本，根据一些业务规则（电子邮件、地址等）检查重复项.那么去重的逻辑是：
- 如果创建了新的预订，请检查此预订的（新创建的）客户是否已有旧客户ID（通过比较电子邮件和其他方面）。
- 如果有一个或多个旧预订，将该预订与旧客户 ID 分离，然后 link 将其与新客户 ID 分离。从字面上看，通过将旧预订的客户 ID 更改为新创建的客户。
我没有太深的技术背景，但这对我来说是糟糕的设计。由于我们有多个依赖该数据的操作应用程序，因此会产生大量的同步问题。除此之外，我希望了解为什么在应用程序架构方面，这是糟糕的设计，以及什么是解决重复数据删除问题的更好解决方案（如果它甚至必须在“这个”应用程序域中解决）。
非常感谢任何帮助，以便我可以推动工程团队朝着正确的方向发展。
我不会说这是一个糟糕的设计，它只是解决这个特定问题的一种简单方法，还有一些改进的余地。这不是最优的，因为该作业的运行时间取决于当天收到的新预订，这可能每天都不同，因此依赖于它的其他工作流将受到影响。
可以通过并行处理新预订并在检查新电子邮件是否已存在时使用索引进行快速查找来改进此方法。
您还可以查看 Bloom Filters - 一种高效的数据结构，能够告诉您元素 是否不在给定集合中 。
我会这样做的方式是将预订存储在 No-SQL DB table 中，关闭用户电子邮件。在这两种情况下您都会收到用户的电子邮件 - 当它有帐户或在没有帐户的情况下进行预订时，因此您只需进行查找以通过电子邮件获取预订，这使得重复数据删除工作变得多余。
一般
您要解决的问题是什么？释放磁盘space，获得对用户行为的准确分析或更加用户友好？
感觉有点冒险，这取决于您获得 100% 正确的重新匹配有多重要。你需要问“可能发生的最坏情况是什么？”和“这是否会导致系统被滥用”——不是因为你应该偏执，而是因为不认为通过感觉有点疏忽。例如。如果您是匹配私人公民记录的政府部门，那么这种方法就太随意了。
如果可能发生的最坏情况并没有那么糟糕，并且您做对的 80% 可以让您获得所需的结果，那么也许还可以。
如果没有验证用户身份的过程，那么根据定义，您的客户id/row存储的是会话，而不是客户。
就夜间作业而言——如果您的后端系统是一个旧的遗留系统，那么我可以理解为什么夜间批处理作业可能是最简单的选择；也就是说，如果正确完成并使用正确的架构，您应该能够根据需要即时进行检查。
细节
...check if the (newly created) customer
for this reservation has already an old customer id (by comparing
email...
您是否正在验证电子邮件 - 例如通过确认电子邮件机制让用户确认？如果是，并且如果电子邮件是必填字段，那么感觉还可以，您可以专门使用电子邮件。
... and other aspects.
那些是什么？有时获取更多数据只会让事情变得更难，除非有良好的数据卫生措施。例如。如果您正在检查 phone 号码（和其他数据）并且有人在与其他客户匹配的 phone 号码上输入错误，会发生什么情况 - 因此您同时与多个客户匹配？
If it has one or more old reservations, detach that reservation from
the old customer id, and link it to a new customer id. Literally by
changing the customer ID of that old reservation to the newly created
customer.
感觉很危险。如果分离过程搞砸了怎么办？我见过这样的情况，系统没有更新增量，而是进行了完全清除，然后完全重新导入……当第二部分失败时，整个系统都是空白的。这不是您的确切情况，但您正在为类似类型的问题创造可能性。
As we have several operational applications relying on that data, this creates a massive sync issue.
...恰当的例子。
在您的情况下，在交易中进行交换是明智的。您可能需要考虑跟踪所有客户 ID 交换，以便在出现问题时可以恢复。
选项 - 基于测试的分阶段引入
你可以试试这个：
- 暂时保持系统不变。
- 添加执行您提议的检查的逻辑，但让它在一边创建试验数据 - 即不要更改真实记录，只需制作一份新数据的副本。在生产中执行此操作 - 您将获得更好的数据样本。
- 运行 对试验数据进行了广泛的测试，寻找错误的地方。更有可能的是，您可以考虑构建的是“评分”算法。如果您要检查多个数据，那么您将获得具有不同准确性可能性的不同组合。您可以使用它来衡量匹配的好坏。然后您可以决定在什么情况下进行 ID 切换是安全的，什么时候不安全。
- 一旦你满意了，就按照你认为合适的方式实施——要么只是算法和结果，要么也包括评分工具，这样你就可以随着时间的推移观察它的表现——尤其是当你引入变化时。
备选Customer/Session方法
- 将所有预订（不包括个人详细信息）视为有客户（小 c，即会话）但没有客户的预订。
- 允许用户有选择地被验证为“客户”（大 C）。
- 由经过验证的客户创建的预订，然后 link 彼此。所有预订都与 永远不会 更改的客户（会话）相关，因此您具有可追溯性。
一旦我更了解您要解决的问题 - 即您的动机是什么，我就可以调整答案。
我们有一个预订系统，每天有成千上万的预订。因为客户可以在不登录的情况下创建预订，这意味着每次预订都会创建一个新客户 id/row，即使同一位客户之前已经在系统中预订过。这导致大量客户重复。
工程团队决定，为了对客户进行重复数据删除，他们将每天 运行 一个夜间脚本，根据一些业务规则（电子邮件、地址等）检查重复项.那么去重的逻辑是：
- 如果创建了新的预订，请检查此预订的（新创建的）客户是否已有旧客户ID（通过比较电子邮件和其他方面）。
- 如果有一个或多个旧预订，将该预订与旧客户 ID 分离，然后 link 将其与新客户 ID 分离。从字面上看，通过将旧预订的客户 ID 更改为新创建的客户。
我没有太深的技术背景，但这对我来说是糟糕的设计。由于我们有多个依赖该数据的操作应用程序，因此会产生大量的同步问题。除此之外，我希望了解为什么在应用程序架构方面，这是糟糕的设计，以及什么是解决重复数据删除问题的更好解决方案（如果它甚至必须在“这个”应用程序域中解决）。
非常感谢任何帮助，以便我可以推动工程团队朝着正确的方向发展。
我不会说这是一个糟糕的设计，它只是解决这个特定问题的一种简单方法，还有一些改进的余地。这不是最优的，因为该作业的运行时间取决于当天收到的新预订，这可能每天都不同，因此依赖于它的其他工作流将受到影响。
可以通过并行处理新预订并在检查新电子邮件是否已存在时使用索引进行快速查找来改进此方法。
您还可以查看 Bloom Filters - 一种高效的数据结构，能够告诉您元素 是否不在给定集合中 。
我会这样做的方式是将预订存储在 No-SQL DB table 中，关闭用户电子邮件。在这两种情况下您都会收到用户的电子邮件 - 当它有帐户或在没有帐户的情况下进行预订时，因此您只需进行查找以通过电子邮件获取预订，这使得重复数据删除工作变得多余。
一般
您要解决的问题是什么？释放磁盘space，获得对用户行为的准确分析或更加用户友好？
感觉有点冒险，这取决于您获得 100% 正确的重新匹配有多重要。你需要问“可能发生的最坏情况是什么？”和“这是否会导致系统被滥用”——不是因为你应该偏执，而是因为不认为通过感觉有点疏忽。例如。如果您是匹配私人公民记录的政府部门，那么这种方法就太随意了。
如果可能发生的最坏情况并没有那么糟糕，并且您做对的 80% 可以让您获得所需的结果，那么也许还可以。
如果没有验证用户身份的过程，那么根据定义，您的客户id/row存储的是会话，而不是客户。
就夜间作业而言——如果您的后端系统是一个旧的遗留系统，那么我可以理解为什么夜间批处理作业可能是最简单的选择；也就是说，如果正确完成并使用正确的架构，您应该能够根据需要即时进行检查。
细节
...check if the (newly created) customer for this reservation has already an old customer id (by comparing email...
您是否正在验证电子邮件 - 例如通过确认电子邮件机制让用户确认？如果是，并且如果电子邮件是必填字段，那么感觉还可以，您可以专门使用电子邮件。
... and other aspects.
那些是什么？有时获取更多数据只会让事情变得更难，除非有良好的数据卫生措施。例如。如果您正在检查 phone 号码（和其他数据）并且有人在与其他客户匹配的 phone 号码上输入错误，会发生什么情况 - 因此您同时与多个客户匹配？
If it has one or more old reservations, detach that reservation from the old customer id, and link it to a new customer id. Literally by changing the customer ID of that old reservation to the newly created customer.
感觉很危险。如果分离过程搞砸了怎么办？我见过这样的情况，系统没有更新增量，而是进行了完全清除，然后完全重新导入……当第二部分失败时，整个系统都是空白的。这不是您的确切情况，但您正在为类似类型的问题创造可能性。
As we have several operational applications relying on that data, this creates a massive sync issue.
...恰当的例子。
在您的情况下，在交易中进行交换是明智的。您可能需要考虑跟踪所有客户 ID 交换，以便在出现问题时可以恢复。
选项 - 基于测试的分阶段引入
你可以试试这个：
- 暂时保持系统不变。
- 添加执行您提议的检查的逻辑，但让它在一边创建试验数据 - 即不要更改真实记录，只需制作一份新数据的副本。在生产中执行此操作 - 您将获得更好的数据样本。
- 运行 对试验数据进行了广泛的测试，寻找错误的地方。更有可能的是，您可以考虑构建的是“评分”算法。如果您要检查多个数据，那么您将获得具有不同准确性可能性的不同组合。您可以使用它来衡量匹配的好坏。然后您可以决定在什么情况下进行 ID 切换是安全的，什么时候不安全。
- 一旦你满意了，就按照你认为合适的方式实施——要么只是算法和结果，要么也包括评分工具，这样你就可以随着时间的推移观察它的表现——尤其是当你引入变化时。
备选Customer/Session方法
- 将所有预订（不包括个人详细信息）视为有客户（小 c，即会话）但没有客户的预订。
- 允许用户有选择地被验证为“客户”（大 C）。
- 由经过验证的客户创建的预订，然后 link 彼此。所有预订都与 永远不会 更改的客户（会话）相关，因此您具有可追溯性。
一旦我更了解您要解决的问题 - 即您的动机是什么，我就可以调整答案。