预订应用程序中的客户重复数据删除

我们有一个预订系统，每天有成千上万的预订完成。由于客户无需登录即可创建预订，这意味着每次预订都会创建一个新的客户 ID/行，即使该客户之前已经在系统中进行了预订。这会导致大量客户重复。

工程团队决定，为了对客户进行重复数据删除，他们将每天运行一个夜间脚本，根据某些业务规则（电子邮件、地址等）检查这些重复项。重复数据删除的逻辑是：

我没有很强的技术背景，但这对我来说闻起来像是糟糕的设计。由于我们有几个操作应用程序依赖于这些数据，这会产生大量的同步问题。除此之外，我希望了解为什么在应用程序架构方面，这是一个糟糕的设计，以及什么是解决重复数据删除问题的更好解决方案（如果它甚至必须在“这个”应用程序域中解决）。

我非常感谢任何帮助，以便我可以推动工程团队朝着正确的方向发展。

我不会说这是一个糟糕的设计，它只是解决这个特定问题的一种简单方法，还有一些改进的空间。这不是最佳选择，因为该作业的运行时间取决于当天收到的新预订，这些预订可能每天都不同，因此其他依赖于此的工作流程会受到影响。

可以通过并行处理新预订来改进这种方法，并在检查新电子邮件是否已存在时使用索引进行快速查找。

您还可以查看 Bloom Filters - 一种高效的数据结构，它能够告诉您某个元素是否不在给定集合中。

我的做法是将预订存储在以用户电子邮件为键的 No-SQL DB 表中。在这两种情况下，您都会收到用户电子邮件 - 当它有帐户时或在没有帐户的情况下进行预订时，因此您只需进行查找即可通过电子邮件获取预订，这使得重复数据删除工作变得多余。

一般情况

您要解决的问题是什么？释放磁盘空间、获得用户行为的准确分析或更加用户友好？

感觉有点冒险，这取决于重新匹配 100% 正确的重要性。你需要问“可能发生的最坏情况是什么？”和“这是否会导致系统被滥用”——不是因为你应该偏执，而是因为不认为这有点疏忽。例如。如果你是一个匹配私人公民记录的政府部门，那么这种方法就太傲慢了。

如果可能发生的最坏情况还不错，并且您正确的 80% 可以让您获得所需的结果，那么也许没问题。

如果没有用于验证用户身份的过程，那么根据定义，您的客户 ID/行将存储会话，而不是客户。

就夜间作业而言 - 如果您的后端系统是旧系统，那么我可以理解为什么夜间批处理作业可能是最简单的选择；也就是说，如果正确完成并使用正确的架构，您应该能够根据需要即时进行检查。

规格

...检查（新创建的）客户是否对于此预订，已经有一个旧客户 ID（通过比较电子邮件...

您是否正在验证电子邮件 - 例如通过让用户通过确认电子邮件机制进行确认？如果是，并且如果电子邮件是必填字段，那么感觉没问题，您可能可以专门使用电子邮件。

...以及其他方面。

那些是什么？有时，除非有良好的数据卫生，否则获取更多数据只会使其变得更加困难。例如。如果您正在检查电话号码（和其他数据）并且有人在与其他客户匹配的电话号码上打错了字 - 所以您同时与多个客户匹配，会发生什么情况？

如果它有一个或多个旧保留，则将该保留从旧客户 ID，并将其链接到新客户 ID。从字面上看将该旧预订的客户 ID 更改为新创建的客户。

感觉很危险。如果分离过程搞砸了怎么办？我见过这样的情况，系统没有更新增量，而是完全清除然后完全重新导入......当第二部分失败时，整个系统是空白的。这不是您的确切情况，但您正在为类似类型的问题创造可能性。

由于我们有多个操作应用程序依赖于这些数据，因此会产生大量同步问题。

...举个例子。

在您的情况下，在交易中进行交换是明智的。您可能需要考虑跟踪所有客户 ID 交换，以便在出现问题时可以恢复。

选项 - 基于测试的分阶段引入

你可以试试这个：

暂时保持系统原样。
添加执行您提议的检查的逻辑，但让它在侧面创建试验数据 - 即不要更改真实记录，只需复制新数据即可。在生产中执行此操作 - 您将获得更好的数据样本。
对试验数据进行大量测试，寻找出错的地方。更有可能的是，您可以考虑构建的是“评分”算法。如果您正在检查多个数据，那么您将获得具有不同准确性可能性的不同组合。您可以使用它来衡量您的匹配程度。然后，您可以决定在哪些情况下进行 ID 切换是安全的，以及何时不安全。
一旦您感到满意，就按照您认为合适的方式实施 - 无论是算法和结果，还是评分工具，以便您可以随着时间的推移观察其性能 - 特别是在您进行更改时。

替代客户/会话方法

一旦我更了解您要解决的问题（即您的动机是什么），我就可以调整答案。