Partage via

Traiter des données en double dans Azure Data Explorer

  • Article

Les appareils qui envoient des données dans le cloud gèrent un cache local des données. Selon la taille des données, le cache local peut stocker des données pendant plusieurs jours ou même plusieurs mois. Vous souhaitez protéger vos bases de données analytiques des appareils défectueux qui renvoient les données mises en cache et entraînent une duplication des données dans la base de données analytique. Les doublons peuvent affecter le nombre d’enregistrements retournés par une requête. Cela est utile lorsque vous avez besoin d’un nombre précis d’enregistrements, notamment lors du comptage d’événements. Cette rubrique décrit les bonnes pratiques pour la gestion des données en double pour ces types de scénarios.

La meilleure solution pour la duplication des données est d’empêcher cette duplication. Si possible, corrigez le problème plus tôt dans le pipeline de données, ce qui permet d’économiser les coûts associés au déplacement des données dans le pipeline de données et évite de consommer des ressources pour copier des données en double ingérées par le système. Cependant, dans les situations où le système source ne peut pas être modifié, il existe différentes façons de traiter ce scénario.

Comprendre l’impact des données en double

Surveillez le pourcentage de données en double. Une fois que le pourcentage de données en double est déterminé, vous pouvez analyser l’étendue du problème et de l’impact sur l’activité, puis choisir la solution appropriée.

Exemple de requête pour identifier le pourcentage d’enregistrements en double :

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

Solutions pour la gestion des données en double

Solution n° 1 : ne pas supprimer les données en double

Comprenez les exigences de votre activité et la possibilité de tolérer la présence de données en double. Certains jeux de données peuvent s’accommoder d’un certain pourcentage de données en double. Si les données en double n’ont pas d’impact majeur, vous pouvez ignorer leur présence. L’avantage de ne pas supprimer les données en double est qu’aucune charge supplémentaire ne pèse sur le processus d’ingestion ou sur les performances des requêtes.

Solution n° 2 : gérer les lignes en double lors des requêtes

Une autre option consiste à éliminer par filtrage les lignes en double dans les données lors des requêtes. La fonction d’agrégation arg_max() peut être utilisée pour éliminer par filtrage les enregistrements en double et retourner le dernier enregistrement en fonction de l’horodatage (ou d’une autre colonne). L’avantage de cette méthode est une ingestion plus rapide, dans la mesure où la déduplication se produit au moment des requêtes. En outre, tous les enregistrements (y compris les doublons) sont disponibles pour l’audit et la résolution des problèmes. L’inconvénient de l’utilisation de la fonction arg_max est la durée plus longue des requêtes et la charge supplémentaire sur l’UC chaque fois que des données sont recherchées. Selon la quantité de données interrogées, cette solution peut devenir non fonctionnelle ou gourmande en mémoire, et nécessiter de passer à d’autres options.

Dans l’exemple suivant, nous interrogeons le dernier enregistrement ingéré pour un ensemble de colonnes qui déterminent l’unicité des enregistrements :

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

Cette requête peut également être placée à l’intérieur d’une fonction, au lieu d’interroger directement la table :

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

Solution n° 3 : utiliser des vues matérialisées pour la déduplication

Les vues matérialisées peuvent servir pour la déduplication, en utilisant les fonctions d’agrégation take_any()/arg_min()/arg_max() (consultez l’exemple 4 de la commande de création d’une vue matérialisée).

Remarque

Les vues matérialisées présentent un coût lié à la consommation des ressources du cluster, qui peut ne pas être négligeable. Pour plus d’informations, consultez les considérations relatives aux performances des vues matérialisées.

Solution n° 4 : utiliser la suppression réversible pour supprimer les doublons

La suppression réversible prend en charge la possibilité de supprimer des enregistrements individuels et peut donc être utilisée pour supprimer les doublons. Cette option est recommandée uniquement pour les suppressions peu fréquentes. Si vous devez constamment dédupliquer tous les enregistrements entrants, ne l’utilisez pas.

Choisir entre les vues matérialisées et la suppression réversible pour la déduplication des données

Il existe plusieurs considérations qui peuvent vous aider à choisir entre les vues matérialisées ou la suppression réversible pour la déduplication :

  • Gestion et orchestration : les vues matérialisées sont une solution complètement managée. Une vue est définie une seule fois et le système traite la déduplication de tous les enregistrements entrants. La suppression réversible nécessite une orchestration et une gestion. Par conséquent, si les vues matérialisées fonctionnent pour votre cas d’usage, choisissez toujours cette option.
  • Quand les enregistrements sont dédupliqués : avec la suppression réversible, les enregistrements dupliqués sont d’abord ajoutés à une table et sont ensuite supprimés. Par conséquent, entre les processus d’ingestion et de suppression réversible, la table contient des doublons. Avec les vues matérialisées, les enregistrements de la vue sont toujours dédupliqués, car ils sont dédupliqués avant d’entrer dans la vue.
  • Fréquence : si une table doit être dédupliquée en permanence, utilisez des vues matérialisées. Si vous pensez que vous aurez rarement des doublons et que vous pouvez les identifier pendant l’ingestion, le processus de suppression réversible est généralement plus performant que les vues matérialisées. Par exemple, vous êtes dans une situation où vos ingestions n’ont normalement pas de doublons, mais vous ingérez parfois un flux connu pour contenir des doublons. Dans ce scénario, mieux vaut traiter ces doublons avec la suppression réversible plutôt que de définir une vue matérialisée qui tentera constamment de dédupliquer tous les enregistrements.

Solution n° 5 : étiquettes d’étendue ingest-by

Les étiquettes d’étendue « ingest-by: » peuvent être utilisées pour empêcher les doublons pendant l’ingestion. Cela s’applique uniquement aux cas d’usage où chaque lot d’ingestion est garanti sans doublon et que des doublons sont attendus seulement si le même lot d’ingestion est ingéré plusieurs fois.

Résumé

La déduplication des données peut être gérée de plusieurs façons. Évaluez les options avec soin, en tenant compte des prix et des performances pour déterminer la méthode correcte pour votre entreprise.

Contenu connexe