Traiter des données en double dans Azure Data Explorer

Les appareils qui envoient des données au cloud gèrent un cache local des données. Selon la taille des données, le cache local peut stocker des données pendant des jours ou même des mois. Vous souhaitez protéger vos bases de données analytiques contre le dysfonctionnement des appareils qui renvoient les données mises en cache et provoquent 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. Ce problème est pertinent lorsque vous avez besoin d’un nombre précis d’enregistrements, par exemple lors du comptage d’événements. Cet article décrit les meilleures pratiques pour la gestion des données dupliquées 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. Cette approche permet d’économiser les coûts associés au déplacement des données le long du pipeline de données et évite de dépenser des ressources pour gérer les données en double ingérées dans le système. Toutefois, dans les situations où vous ne pouvez pas modifier le système source, vous pouvez utiliser différentes méthodes pour résoudre ce scénario.

Comprendre l’impact des données en double

Surveillez le pourcentage de données en double. Une fois que vous avez découvert le pourcentage de données en double, vous pouvez analyser l’étendue du problème et l’impact métier et 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 1 : Ne supprimez pas les données dupliquées

Comprendre les exigences et la tolérance de votre entreprise pour les données dupliquées. Certains jeux de données peuvent s’accommoder d’un certain pourcentage de données en double. Si les données dupliquées n’ont pas d’impact majeur, vous pouvez ignorer sa présence. L’avantage de ne pas supprimer les données dupliquées est qu’il n’ajoute aucune surcharge supplémentaire sur le processus d’ingestion ou les performances des requêtes.

Solution 2 : Gérer les lignes dupliquées pendant la requête

Une autre option consiste à éliminer par filtrage les lignes en double dans les données lors des requêtes. Vous pouvez utiliser la arg_max() fonction d’agrégation pour filtrer les enregistrements dupliqués et retourner le dernier enregistrement en fonction de l’horodatage (ou d’une autre colonne). L’avantage de l’utilisation de cette méthode est une ingestion plus rapide, car la déduplication se produit pendant le temps de la requête. 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 arg_max fonction est le temps de requête supplémentaire et la charge sur l’UC chaque fois que les données sont interrogées. Selon la quantité de données interrogées, cette solution peut devenir non fonctionnelle ou consommatrice de mémoire et nécessiter un basculement vers 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

Vous pouvez également placer cette requête à 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 3 : Utiliser des vues matérialisées pour dédupliquer

Vous pouvez utiliser des vues matérialisées pour la déduplication à l’aide des fonctions d’agrégation take_any()/arg_min()/arg_max() (voir l’exemple #4 dans la commande create de vue matérialisée).

Remarque

Les vues matérialisées consomment des ressources de cluster, ce qui peut ne pas être négligeable. Pour plus d’informations, consultez les considérations relatives aux performances des vues matérialisées.

Solution 4 : Utiliser la suppression réversible pour supprimer les doublons

La suppression réversible prend en charge la possibilité de supprimer des enregistrements individuels. Vous pouvez donc l’utiliser pour supprimer des doublons. Utilisez cette option uniquement pour les suppressions peu fréquentes, et non si vous devez constamment dédupliquer tous les enregistrements entrants.

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

Tenez compte des facteurs suivants lors du choix entre les vues matérialisées et la suppression réversible pour la déduplication :

  • Gestion et orchestration : les vues matérialisées sont une solution complètement managée. Vous définissez une vue une seule fois, et le système gère la déduplication pour tous les enregistrements entrants. La suppression réversible nécessite une orchestration et une gestion. Si les vues matérialisées fonctionnent pour votre cas d’usage, choisissez cette option.
  • Lorsque les enregistrements sont dédupliqués : avec la suppression réversible, vous ajoutez d’abord des enregistrements dupliqués à une table, puis supprimez-les. Ainsi, entre les processus d’ingestion et de suppression temporaire, la table contient des doublons. Avec les vues matérialisées, les enregistrements de la vue sont toujours dédupliqués, car le système les dédupe avant que celles-ci ne soient intégrées dans la vue.
  • Fréquence : si vous devez dédupliquer constamment une table, utilisez des vues matérialisées. Si les doublons sont peu fréquents et que vous pouvez les identifier pendant l’ingestion, le processus de suppression réversible est généralement plus efficace que les vues matérialisées. Par exemple, si vos ingestions n’ont pas normalement de doublons, mais incluent occasionnellement un flux connu pour contenir des doublons, il est préférable de gérer ces doublons avec suppression réversible plutôt que de définir une vue matérialisée qui tente constamment de dédupliquer tous les enregistrements.

Solution 5 : ingest-by balises d’étendue

Vous pouvez utiliser des balises d’extension « ingestion par : » pour empêcher les doublons pendant l’ingestion. Cette solution est pertinente uniquement dans les cas d’usage où chaque lot d’ingestion n’a pas de doublons, et les doublons ne se produisent que si le même lot d’ingestion est ingéré plusieurs fois.

Résumé

Vous pouvez gérer la duplication des données de plusieurs façons. Évaluez attentivement les options, en tenant compte des prix et des performances, pour déterminer la meilleure méthode pour votre entreprise.

Contenu connexe

  • Last updated on