Datenabgleich: Nachweisen, dass Ihre Migration korrekt funktioniert hat

Sie haben gerade eine Datenmigration abgeschlossen. Das Skript lief ohne Fehler. Die Logs sehen sauber aus. Das Team ist bereit, weiterzumachen. Aber tief in Ihnen nagt das Gefühl: Hat wirklich alles geklappt? Ist jede Zeile angekommen? Wurden irgendwelche Werte still und leise korrumpiert?

In diesem Moment wird den meisten Teams klar, dass eine erfolgreiche Migration nicht dasselbe ist wie eine korrekte Migration. Ein Skript kann mit Exit-Code Null beenden und trotzdem falsche Daten produzieren. Ein Filter könnte Zeilen ausschließen, die er hätte einschließen sollen. Eine Typkonvertierung könnte Werte abschneiden, ohne einen Fehler zu werfen. Die Datenbank wird Ihnen nichts über diese Probleme verraten, es sei denn, Sie fragen explizit danach.

Deshalb gibt es den Datenabgleich (Reconciliation). Es ist der Prozess, Daten vor und nach einer Migration zu vergleichen, um zu beweisen, dass nichts verloren gegangen, verändert oder korrumpiert wurde. Es ist der letzte Kontrollpunkt, bevor Sie die Migration für abgeschlossen erklären.

Warum fehlerfreie Skripte nicht ausreichen

Die unangenehme Wahrheit über Datenmigrationen ist, dass Korrektheit und fehlerfreie Ausführung zwei verschiedene Dinge sind. Ein Migrationsskript kann aus technischer Sicht einwandfrei laufen und trotzdem falsche Ergebnisse liefern.

Betrachten Sie ein häufiges Szenario: Sie migrieren eine Tabelle mit einer WHERE-Klausel, die inaktive Benutzer herausfiltert. Das Skript läuft, die Zeilen werden erfolgreich eingefügt, und die alte Tabelle wird stillgelegt. Wochen später stellt jemand fest, dass eine Gruppe aktiver Benutzer fehlt. Der Filter war zu aggressiv, oder die Bedingung war falsch. Das Skript ist nie fehlgeschlagen, aber die Daten sind falsch.

Fehler in Logs erfassen diese Art von Problem nicht. Die Datenbank-Engine weiß nicht, dass eine fehlende Zeile ein Fehler ist. Sie weiß nur, dass die INSERT-Anweisung erfolgreich ausgeführt wurde. Der einzige Weg, diese stillen Fehler zu erkennen, ist der direkte Vergleich der Quelldaten mit den Zieldaten.

Der praktische Ansatz für den Datenabgleich

Der Datenabgleich muss nicht kompliziert sein. Die einfachste und effektivste Methode ist der Checksummen-Vergleich. Anstatt Dateien zu checksummen, checksummen Sie Batches von Daten.

So funktioniert es für eine Tabellenmigration:

  1. Lesen Sie einen Batch von Zeilen aus der Quelltabelle.
  2. Berechnen Sie einen Hash des gesamten Batches (z.B. mit MD5 oder SHA256 über eine Verkettung aller Spaltenwerte).
  3. Lesen Sie denselben Batch aus der Zieltabelle mit derselben Sortierung und berechnen Sie denselben Hash.
  4. Vergleichen Sie die beiden Hashes.

Wenn die Hashes übereinstimmen, ist der Batch identisch. Wenn nicht, wissen Sie genau, welcher Batch ein Problem hat, und Sie können diesen spezifischen Zeilenbereich untersuchen.

Bei großen Tabellen ist die Verarbeitung in Batches unerlässlich. Sie wollen nicht Millionen von Zeilen auf einmal in den Speicher laden. Eine Batch-Größe von 1.000 bis 10.000 Zeilen funktioniert für die meisten Datenbanken gut. Sie können diese Vergleiche parallel über mehrere Batches laufen lassen, um die Sache zu beschleunigen.

Das folgende Flussdiagramm veranschaulicht den batchweisen Abgleichsprozess:

flowchart TD A[Start] --> B[Batch aus Quelltabelle extrahieren] B --> C[Hash des Batches berechnen] C --> D[Gleichen Batch aus Zieltabelle extrahieren] D --> E[Hash des Batches berechnen] E --> F{Hashe vergleichen} F -- Übereinstimmung --> G[Batch als verifiziert markieren] F -- Abweichung --> H[Batch zur Untersuchung markieren] G --> I{Weitere Batches?} H --> I I -- Ja --> B I -- Nein --> J[Zeilenanzahlen vergleichen] J --> K{Zeilenanzahlen gleich?} K -- Ja --> L[Bericht erstellen: Migration verifiziert] K -- Nein --> M[Abweichung melden und untersuchen] L --> N[Ende] M --> N

Hier ist eine konkrete SQL-Abfrage, die diesen Ansatz für zwei Tabellen implementiert:

-- Vergleicht Zeilenanzahlen und Checksummen zwischen Quell- und Zieltabelle
WITH source_checksums AS (
    SELECT
        COUNT(*) AS row_count,
        MD5(STRING_AGG(CAST(column1 AS TEXT) || '|' || CAST(column2 AS TEXT) || '|' || CAST(column3 AS TEXT), ',' ORDER BY id)) AS batch_hash
    FROM source_table
),
target_checksums AS (
    SELECT
        COUNT(*) AS row_count,
        MD5(STRING_AGG(CAST(column1 AS TEXT) || '|' || CAST(column2 AS TEXT) || '|' || CAST(column3 AS TEXT), ',' ORDER BY id)) AS batch_hash
    FROM target_table
)
SELECT
    'Zeilenanzahl stimmt nicht überein' AS problem
FROM source_checksums, target_checksums
WHERE source_checksums.row_count <> target_checksums.row_count
UNION ALL
SELECT
    'Checksumme stimmt nicht überein' AS problem
FROM source_checksums, target_checksums
WHERE source_checksums.batch_hash <> target_checksums.batch_hash;

Diese Abfrage berechnet eine einzige Checksumme über alle Zeilen in jeder Tabelle (mit einer stabilen Sortierung) und vergleicht sowohl die Zeilenanzahl als auch den Hash. Wenn eines davon abweicht, gibt die Abfrage einen klaren Hinweis darauf, was schiefgelaufen ist.

Was Sie außer Checksummen noch prüfen sollten

Checksummen fangen die meisten Probleme ab, aber sie sind nicht das Einzige, was Sie überprüfen sollten. Ein paar zusätzliche Checks erhöhen die Sicherheit ohne großen Mehraufwand.

Zeilenanzahl. Das ist der einfachste Check. Die Anzahl der Zeilen in der Zieltabelle sollte mit der Anzahl der Zeilen in der Quelltabelle übereinstimmen. Wenn die Zahlen abweichen, ist bei der Migrationslogik etwas schiefgelaufen.

NULL-Werte. Migrationen ändern manchmal NULL-Spalten in Standardwerte oder umgekehrt. Vergleichen Sie die Anzahl der NULL-Werte pro Spalte zwischen Quelle und Ziel. Eine Abweichung hier deutet oft auf ein Problem mit der Typkonvertierung oder einer falsch angewendeten Standardwert-Constraint hin.

Werteverteilung. Wählen Sie ein paar wichtige Spalten aus und vergleichen Sie deren Werteverteilungen. Wenn die Quelltabelle zum Beispiel 1.000 Benutzer mit Status "aktiv" und 500 mit Status "inaktiv" hat, sollte die Zieltabelle dieselben Zahlen aufweisen. Eine signifikante Abweichung deutet auf einen Fehler im Migrationsfilter oder in der Transformationslogik hin.

Grenzfälle. Testen Sie spezifische Zeilen, die bekanntermaßen knifflig sind: Zeilen mit Sonderzeichen, sehr langen Zeichenketten, Daten in der Nähe von Grenzwerten oder negativen Zahlen. Wenn Ihre Migration diese korrekt behandelt hat, ist das ein gutes Zeichen dafür, dass die allgemeine Logik solide ist.

Den Datenabgleich in Ihre Pipeline integrieren

Der Datenabgleich sollte keine einmalige manuelle Aufgabe sein, an die sich jemand nach einer nächtlichen Migration erinnert. Er sollte automatisiert und in Ihre Deployment-Pipeline integriert sein.

Schreiben Sie ein Abgleichsskript, das nach Abschluss der Migrations- und Backfill-Schritte läuft. Das Skript sollte:

  • Eine Verbindung sowohl zur Quell- als auch zur Zieldatenbank herstellen.
  • Den batchweisen Checksummen-Vergleich durchführen.
  • Zeilenanzahlen, NULL-Anzahlen und Werteverteilungen prüfen.
  • Einen detaillierten Bericht über etwaige Abweichungen erstellen.
  • Eine Benachrichtigung (E-Mail, Slack oder was auch immer Ihr Team verwendet) mit den Ergebnissen senden.

Wenn der Abgleich bestanden wird, kann die Pipeline mit dem nächsten Schritt fortfahren. Wenn er fehlschlägt, sollte die Pipeline anhalten und das Team alarmieren. Dies verhindert, dass falsche Daten unbemerkt in die Produktion gelangen.

Die Automatisierung des Datenabgleichs macht ihn auch wiederholbar. Jede Migration durchläuft denselben Verifizierungsprozess. Sie müssen sich nicht darauf verlassen, dass jemand daran denkt, ein Skript auszuführen oder die richtigen Dinge zu überprüfen. Die Pipeline erzwingt es.

Was der Datenabgleich nicht ist

Der Datenabgleich ist kein Ersatz für Probeläufe (Dry Runs) oder Backfill-Strategien. Jeder Schritt dient einem anderen Zweck.

  • Probeläufe verifizieren, dass die Migrationslogik funktioniert, ohne Produktionsdaten zu beeinträchtigen.
  • Backfill übernimmt die eigentliche Datenübertragung in handhabbaren Blöcken, um die Auswirkungen zu minimieren.
  • Datenabgleich beweist, dass der Backfill korrekte Ergebnisse geliefert hat.

Betrachten Sie den Datenabgleich als das finale Qualitätsgate. Er bestätigt, dass alle vorherigen Schritte wie beabsichtigt funktioniert haben. Wenn der Abgleich bestanden wird, können Sie sicher sein, dass die Daten bereit sind. Wenn er fehlschlägt, gehen Sie zurück, beheben das Problem und führen die Migration von Anfang an erneut durch.

Eine praktische Checkliste für den Datenabgleich

Wenn Sie den Datenabgleich für Ihre nächste Migration einrichten, hier eine kurze Checkliste als Leitfaden:

  • Checksummen-Vergleich pro Batch (1.000-10.000 Zeilen pro Batch)
  • Übereinstimmung der Zeilenanzahl zwischen Quelle und Ziel
  • Übereinstimmung der NULL-Anzahl pro Spalte
  • Übereinstimmung der Werteverteilung für Schlüsselspalten
  • Verifizierung von Grenzfällen (Sonderzeichen, Grenzwerte)
  • Automatisiertes Skript, das in die Pipeline integriert ist
  • Benachrichtigung bei Fehlschlag mit detailliertem Abweichungsbericht

Das Fazit

Eine Migration ist erst abgeschlossen, wenn Sie die Korrektheit der Daten nachgewiesen haben. Eine fehlerfreie Ausführung reicht nicht aus. Der Datenabgleich liefert Ihnen diesen Nachweis, indem er Quell- und Zieldaten direkt vergleicht. Automatisieren Sie ihn, führen Sie ihn jedes Mal aus, und behandeln Sie einen fehlgeschlagenen Abgleich genauso wie einen fehlgeschlagenen Test: Anhalten, untersuchen und beheben, bevor Sie fortfahren.