Share via

在 Azure 数据资源管理器中处理重复数据

  • 项目

将数据发送到云的设备会维护数据的本地缓存。 根据具体的数据大小，本地缓存可将数据存储数天甚至数月之久。 我们希望能够保护重新发送缓存数据，并导致分析数据库中出现重复数据的有故障设备中的分析数据库。 重复项可能会影响查询返回的记录数。 当需要精确计数记录（例如计数事件）时，这一点很重要。 本主题将概述为此类方案处理重复数据的最佳做法。

处理重复数据的最佳解决方法是防止重复。 如果可能，请解决数据管道中的旧问题，这可以节省在数据管道中移动数据的相关成本，并可避免投入资源来处理系统中引入的重复数据。 但是，在无法改造源系统的情况下，可通过多种方式来处理这种情况。

了解重复数据造成的影响

监视重复数据的百分比。 发现重复数据的百分比之后，可以分析问题范围和对业务造成的影响，然后选择适当的解决方法。

用于识别重复记录百分比的示例查询：

let _sample = 0.01; // 1% sampling
let _data =
DeviceEventsAll
| where EventDateTime between (datetime('10-01-2018 10:00') .. datetime('10-10-2018 10:00'));
let _totalRecords = toscalar(_data | count);
_data
| where rand()<= _sample
| summarize recordsCount=count() by hash(DeviceId) + hash(EventId) + hash(StationId)  // Use all dimensions that make row unique. Combining hashes can be improved
| summarize duplicateRecords=countif(recordsCount  > 1)
| extend duplicate_percentage = (duplicateRecords / _sample) / _totalRecords

用于处理重复数据的解决方法

解决方法 #1：不要删除重复数据

了解业务要求以及对重复数据的容限。 某些数据集可以处理特定百分比的重复数据。 如果重复数据不会造成重大影响，可以忽略它的存在。 不删除重复数据的优点是，在引入过程中不会产生额外的开销，也不会影响查询性能。

解决方法 #2：在查询过程中处理重复行

另一种做法是在查询过程中筛选出数据中的重复行。 使用 arg_max() 聚合函数可以筛选出重复记录，并基于时间戳（或另一列）返回最后一条记录。 使用此方法的优点是引入速度更快，因为重复数据删除是在查询期间发生的。 此外，所有记录（包括重复项）都可用于审核和故障排除。 使用 arg_max 函数的缺点是，每次查询数据都会增大查询时间和 CPU 负载。 根据查询的数据量，此解决方法可能不起作用或者消耗过多的内存，因此需要改用其他做法。

在以下示例中，我们将查询针对一组列引入的最后一条记录来确定唯一的记录：

DeviceEventsAll
| where EventDateTime > ago(90d)
| summarize hint.strategy=shuffle arg_max(EventDateTime, *) by DeviceId, EventId, StationId

也可以将此查询置于某个函数内，而不是直接查询表：

.create function DeviceEventsView
{
    DeviceEventsAll
    | where EventDateTime > ago(90d)
    | summarize arg_max(EventDateTime, *) by DeviceId, EventId, StationId
}

解决方案 #3：使用具体化视图删除重复数据

通过使用 take_any()/arg_min()/arg_max() 聚合函数，可将具体化视图用于重复数据删除（请参阅具体化视图创建命令中的示例 4）。

注意

具体化视图会带来消耗群集资源的成本，这可能无法忽略。 有关详细信息，请参阅具体化视图性能注意事项。

解决方案 4：使用软删除删除重复项

软删除支持删除单个记录，因此可用于删除重复项。 仅建议将此选项用于非经常性删除；如果需要不断对所有传入记录进行重复数据删除，则不建议使用此选项。

选择是使用具体化视图还是软删除进行重复数据删除

以下几个考虑因素可帮助你决定是使用具体化视图还是软删除进行重复数据删除：

  • 管理和编排：具体化视图是一种完全托管的解决方案。 只需定义一次视图，系统便会处理所有传入记录的重复数据删除。 软删除需要进行编排和管理。 因此，如果具体化视图适用于你的用例，则应始终选择此选项。
  • 何时对记录消除重复数据：使用软删除时，会先将重复记录添加到表中，然后进行删除；因此，在引入和软删除过程之间，该表包含重复项。 使用具体化视图时，视图中的记录始终已消除重复数据，因为它们在进入视图之前已消除重复数据。
  • 频率：如果需要不断对表进行重复数据删除，请使用具体化视图。 如果预计重复项的出现频率很低，并且可以在引入期间识别它们，那么软删除过程通常比具体化视图效果更好。 例如，如果引入数据中通常没有重复项，但偶尔会引入已知包含重复项的流。 在这种情况下，最好使用软删除来处理这些重复项，而不是定义一个不断尝试对所有记录进行重复数据删除的具体化视图。

解决方案 5：ingest-by 盘区标记

“ingest-by:”盘区标记可用于防止在引入期间出现重复项。 该标记仅适用于以下用例：保证每个引入批次都没有重复项，并且仅当多次引入同一引入批次时才会出现重复项。

总结

可以通过多种方式处理重复数据。 请评估不同的做法，同时考虑价格和性能，以确定符合业务需求的适当方法。

相关内容