Deduplizierungsstrategien für Datensätze: exakte Zeilen, Keep-latest nach Schlüssel und begrenzte Zeitfenster

Worum es geht

Hinter „Duplikaten" verbergen sich drei unterschiedliche Probleme. Exakte Duplikate sind Zeilen, die in jeder Spalte identisch sind, meist erzeugt durch einen erneuten Lauf, der angehängt hat, oder einen Retry, der zweimal erfolgreich war. Versionen sind Zeilen, die einen fachlichen Schlüssel teilen, sich aber in anderen Spalten unterscheiden, erzeugt durch Change Feeds oder wiederholte Extrakte einer veränderlichen Tabelle; gewünscht ist nur eine davon, normalerweise die neueste. Erneute Zustellungen sind dieselbe Nachricht, die mehr als einmal von einem At-least-once-Transport empfangen wird. Jede braucht eine andere Regel. Die PostgreSQL-Dokumentation (zitiert) beschreibt DISTINCT ON (expressions), das nur die erste Zeile jeder Menge von Zeilen behält, bei denen die Ausdrücke gleich ausgewertet werden, und warnt, dass „erste" unvorhersehbar ist, sofern ORDER BY nicht die gewünschte Zeile an erste Stelle setzt. Amazon-SQS-FIFO-Queues (zitiert) deduplizieren anhand einer MessageDeduplicationId, sodass innerhalb eines Fensters von 5 Minuten nur eine Instanz einer Nachricht mit dieser ID zugestellt wird. Das dropDuplicates von PySpark (zitiert) verwirft doppelte Zeilen in einem Batch, hält bei einem Streaming-DataFrame aber alle Daten über Trigger hinweg als Zustand, sofern kein Watermark begrenzt, wie spät ein Duplikat eintreffen darf.

Warum es wichtig ist

Eine Dedup-Regel ohne Sortierung wählt stillschweigend zufällig eine Version aus und verändert die Ergebnisse zwischen Läufen. Ein zu kurzes Dedup-Fenster lässt Duplikate durch; ein unbegrenztes lässt den Zustand wachsen, bis der Job scheitert. Am falschen Ort zu deduplizieren verbirgt einen vorgelagerten Fehler (einen Producer, der ohne Schlüssel erneut versucht), der anderswo weiterhin Kosten verursacht.

So wird es angewendet

• Exakte Duplikate: SELECT DISTINCT oder ein Group-by über alle Spalten; besser, das Anhängen so korrigieren, dass daraus ein Partitionsersatz wird.
• Versionen: DISTINCT ON (key) ... ORDER BY key, updated_at DESC, ingest_id DESC oder ROW_NUMBER() OVER (PARTITION BY key ORDER BY ...) = 1, mit einem deterministischen Tie-Breaker nach dem Zeitstempel.
• Erneute Zustellungen: jeder Nachricht beim Producer einen stabilen Idempotenzschlüssel geben, ihn beim Consumer mit einer Unique Constraint speichern und einen Konflikt als „bereits verarbeitet" behandeln.
• Streaming: innerhalb eines durch ein Watermark begrenzten Fensters anhand des Schlüssels deduplizieren und die Grenze dokumentieren; Duplikate, die älter als die Grenze sind, werden durch einen periodischen Batch-Durchlauf behandelt.
• Unscharfe Treffer (dieselbe Kundschaft, andere Schreibweise) sind Record Linkage, nicht Deduplizierung: normalisieren, mit expliziten Regeln abgleichen und beide Originale mit einer Verknüpfung behalten.

Stolpersteine

Die gesamte Zeile als Schlüssel zu hashen ändert den Hash, sobald eine Spalte hinzukommt. Keep-latest nach updated_at versagt, wenn sich die Uhren zwischen Quellen unterscheiden; eine Sequenznummer der Quelle vorziehen. Vor einem Join zu deduplizieren verbirgt, welche Seite aufgefächert hat.