Stratégies de déduplication des enregistrements : lignes identiques, conservation de la plus récente par clé et fenêtres bornées

Ce que c'est

Trois problèmes différents se cachent sous le mot « doublons ». Les doublons exacts sont des lignes identiques sur toutes les colonnes, généralement produites par une réexécution qui a ajouté des lignes ou par une nouvelle tentative réussie deux fois. Les versions sont des lignes partageant une clé métier mais différant sur d'autres colonnes, produites par des flux de changement ou des extractions répétées d'une table mutable ; une seule d'entre elles est souhaitée, normalement la plus récente. Les redistributions correspondent au même message reçu plus d'une fois via un transport « au moins une fois ». Chacun a besoin d'une règle différente. La documentation de PostgreSQL (citée) décrit DISTINCT ON (expressions), qui ne conserve que la première ligne de chaque ensemble de lignes où les expressions s'évaluent de façon égale, et avertit que « première » est imprévisible à moins qu'un ORDER BY ne place la ligne voulue en premier. Les files FIFO d'Amazon SQS (citées) dédupliquent sur un MessageDeduplicationId, de sorte que dans une fenêtre de 5 minutes une seule instance d'un message portant cet identifiant est distribuée. Le dropDuplicates de PySpark (cité) supprime les lignes en double dans un lot, mais sur un DataFrame en flux continu, il conserve toutes les données entre les déclenchements comme état, à moins qu'un filigrane (watermark) ne borne le retard avec lequel un doublon peut arriver.

Pourquoi c'est important

Une règle de déduplication sans ordre choisit une version silencieusement au hasard et change les résultats d'une exécution à l'autre. Une fenêtre de déduplication trop courte laisse passer des doublons ; une fenêtre non bornée fait grossir l'état jusqu'à ce que le job échoue. Dédupliquer au mauvais endroit masque un défaut en amont (un producteur qui retente sans clé) dont le coût continue de se répercuter ailleurs.

Comment l'appliquer

• Doublons exacts : SELECT DISTINCT ou un regroupement sur toutes les colonnes ; mieux encore, corriger l'ajout pour qu'il devienne un remplacement de partition.
• Versions : DISTINCT ON (key) ... ORDER BY key, updated_at DESC, ingest_id DESC ou ROW_NUMBER() OVER (PARTITION BY key ORDER BY ...) = 1, avec un départage déterministe après l'horodatage.
• Redistributions : donner à chaque message une clé d'idempotence stable dès le producteur, la stocker avec une contrainte d'unicité chez le consommateur, et traiter un conflit comme « déjà traité ».
• Flux continu : dédupliquer sur la clé dans une fenêtre bornée par un filigrane et documenter cette borne ; les doublons plus anciens que la borne sont traités par une passe par lots périodique.
• Les correspondances approximatives (même client, orthographe différente) relèvent de la résolution d'entités (record linkage), pas de la déduplication : normaliser, faire correspondre avec des règles explicites, et conserver les deux originaux avec un lien.

Pièges

Hacher la ligne entière comme clé change le hachage dès qu'une colonne est ajoutée. La conservation de la plus récente selon updated_at échoue lorsque les horloges diffèrent entre les sources ; préférer un numéro de séquence de la source. Dédupliquer avant une jointure masque de quel côté se trouvait l'éclatement (fan-out).