• Das Datenerfassungssystem von Meta, das unsere Ingenieurteams für aktuelle Schnappschüsse des Social Graph nutzen, wurde kürzlich einer umfassenden Überarbeitung unterzogen, um seine Zuverlässigkeit im großen Maßstab zu verbessern.
• Der Wechsel von unserem Altsystem zu unserer neuen Architektur erforderte eine groß angelegte Migration unseres gesamten Datenerfassungssystems.
• Wir teilen die Lösungen und Strategien, die eine erfolgreiche groß angelegte Systemmigration ermöglicht haben, sowie die Schlüsselfaktoren, die unsere Architekturentscheidungen beeinflusst haben.

---

Bei Meta, unserem soziales Diagramm wird von einem der angetrieben größte MySQL-Bereitstellungen der Welt. Jeden Tag kratzt unser Datenerfassungssystem inkrementell mehrere Petabytes an Social-Graph-Daten von MySQL in das Data Warehouse, um die Analysen, Berichte und nachgelagerten Datenprodukte zu unterstützen, die Teams im gesamten Unternehmen für Aufgaben nutzen, die von der täglichen Entscheidungsfindung bis hin zum Training von Modellen für maschinelles Lernen und der Produktentwicklung reichen.

Wir haben kürzlich die Architektur unseres Datenerfassungssystems überarbeitet, um dessen Effizienz und Zuverlässigkeit deutlich zu verbessern. Die neue Architektur geht weg von kundeneigenen Pipelines, die im kleinen Maßstab effektiv funktionierten, hin zu einem einfacheren selbstverwalteten Data-Warehouse-Service, der auch im Hyperscale-Bereich immer noch effizient arbeitet.

Wir haben 100 % der Arbeitslast erfolgreich umgestellt und das Altsystem vollständig eingestellt. Die Migration eines Datenerfassungssystems dieser Größenordnung war jedoch eine große Herausforderung. Mehrere wichtige Lösungen und Strategien haben dazu beigetragen, dass eine Migration in diesem Bereich erfolgreich war.

Die Migrationsherausforderung

Als unser Betrieb wuchs, zeigte unser altes Datenerfassungssystem Anzeichen von Instabilität aufgrund der immer strengeren Anforderungen an die Datenlandezeit. Wir wussten, dass wir auf ein neues System migrieren mussten. Aber wir wussten auch, dass dies nicht nur Herausforderungen bedeutete, wie wir sicherstellen konnten, dass jeder Auftrag ordnungsgemäß ausgeführt werden konnte nahtlos migriert aber auch wie man eine groß angelegte Migration selbst durchführt.

Gewährleistung eines nahtlosen Übergangs

Um eine nahtlose Migration sicherzustellen, mussten wir den Migrationslebenszyklus für Tausende von Jobs effektiv verfolgen und robuste Rollout- und Rollback-Kontrollen einrichten, um Probleme zu bewältigen, die während des Migrationsprozesses auftreten könnten.

Der Migrationslebenszyklus

Unser erster Schritt bestand darin, einen klaren Lebenszyklus für den Migrationsauftrag festzulegen, um die Datenintegrität und Betriebszuverlässigkeit während des gesamten Prozesses sicherzustellen.

Jeder Job musste auf Korrektheit überprüft werden und definierte Erfolgskriterien erfüllen, bevor mit dem nächsten Schritt des Migrationslebenszyklus fortgefahren werden konnte:

• Keine Probleme mit der Datenqualität. Es gibt keinen Unterschied zwischen den vom alten System und dem neuen System gelieferten Daten. Wir überprüfen dies, indem wir sowohl die Zeilenanzahl als auch die Prüfsumme der Daten vergleichen und so eine vollständige Konsistenz zwischen den beiden Systemen gewährleisten.
• Es wird keine Regression der Landelatenz beobachtet. Die vom neuen System gelieferten Daten sollten eine verbesserte Landelatenz aufweisen oder zumindest der Leistung des alten Systems entsprechen.
• Es wird keine Regression der Ressourcennutzung beobachtet. Die Rechen- und Speichernutzung des im neuen System ausgeführten Jobs sollte verbessert oder zumindest mit der des alten Systems vergleichbar sein.
• Für die Migration kritischer Tabellen haben wir zusätzliche Migrationskriterien definiert und mit den Teams vereinbart, die auf den Service angewiesen waren.

Phase 1: Die Schattenphase

Im ersten Schritt des Lebenszyklus richten wir Schattenjobs in der Vorproduktionsumgebung ein, die über das neue System bereitgestellt werden. Hierbei handelt es sich im Wesentlichen um einen produktionsrealistischen Test, bei dem jeder Schattenjob dieselbe Quelle wie der Produktionsjob verbraucht, aber Daten an eine andere Tabelle, die sogenannte Schattentabelle, liefert. Dieses Setup kann dabei helfen, Probleme aufzudecken, da es das neue System echten Produktionsdaten und -verhalten aussetzt und gleichzeitig einen isolierten Ort bietet, an dem Ergebnisse überprüft und Korrekturen schnell bereitgestellt werden können.

Wir haben die Zeilenanzahl und Prüfsummenabweichungen zwischen den Produktionsjobs und den Schattenjobs kontinuierlich überwacht. Wenn Abweichungen auftraten, untersuchten wir schnell die Grundursache, stellten Korrekturen in der Vorproduktionsumgebung bereit und stellten dann sicher, dass die Abweichungen behoben wurden.

Während dieses Schritts haben wir auch die Rechen- und Speicherkontingente für die Schattenjobs gemessen, um sicherzustellen, dass die Produktionsumgebung über ausreichende Ressourcen verfügt, bevor wir fortfahren.

Wenn der Schattenjob die oben genannten Kriterien erfüllte, wurde er in die Produktionsumgebung verschoben und sichergestellt, dass der Job weiterhin zuverlässig in der Produktionsumgebung ausgeführt werden konnte, bevor mit dem nächsten Schritt fortgefahren wurde.

Phase 2: Die umgekehrte Schattenphase

Sobald der Produktionsjob und der Schattenjob in der Produktionsumgebung zuverlässig liefen, begannen wir mit der umgekehrten Schattenphase. In dieser Phase wurden die Daten des Schattenjobs in die Produktionstabelle geschrieben, wodurch der Schattenjob effektiv zum neuen Produktionsjob wurde. In der Zwischenzeit wurden die Daten des Produktionsauftrags in die Schattentabelle geschrieben, sodass der ursprüngliche Produktionsauftrag dann als Schattenauftrag fungierte.

Dieser Ansatz bot zwei wesentliche Vorteile. Erstens könnten wir nach der Einführung weiterhin kontinuierliche Datenqualitätssignale erhalten, indem wir weiterhin die Ergebnisse der beiden Systeme vergleichen. Zweitens konnten wir bei festgestellten Unstimmigkeiten schnell ein Rollback durchführen, ohne den alten Systemjob neu erstellen oder konfigurieren zu müssen.

Phase 3: Migrationsbereinigung

Wir haben die von beiden Jobs gelieferten Daten weiterhin überwacht und verglichen. Wenn keine Unstimmigkeiten festgestellt wurden, wurde der jetzt auf dem alten System laufende Schattenjob entfernt. Das neue System übernahm dann die Aufgabe und lieferte weiterhin Daten während des Produktionsauftrags, was den Abschluss der Migration markierte.

Benutzerdefinierte Tools zur Datenqualitätsanalyse

Wir haben außerdem eine umfassende Reihe von Debugging-Tools entwickelt, um Teammitgliedern dabei zu helfen, Probleme, die während der Migration auftreten könnten, effizient zu identifizieren und zu lösen.

Wir haben ein Tool zur Datenqualitätsanalyse entwickelt, um sicherzustellen, dass Randfälle auftragsübergreifend effektiv erfasst und bearbeitet werden. Für jede gelandete Schattentabellenpartition würde das System die entsprechende Produktionstabellenpartition lesen und sowohl die Zeilenanzahl als auch die Prüfsumme vergleichen. Alle Abweichungen wurden protokolliert TauchenMetas Datenmanagementsystem für Echtzeitanalysen. Das Datenqualitätsanalysetool las stündlich die Protokolle von Scuba, führte Abfragen durch, um Beispielzeilen zu identifizieren, die Nichtübereinstimmungen verursachten, und protokollierte detaillierte Debugging-Informationen zurück an Scuba. Dieser Prozess ermöglichte es den Teammitgliedern, schnell die Grundursache von Problemen zu ermitteln und zu beurteilen, ob sie bereits bekannt waren und behoben wurden.

Dasselbe Tool zur Datenqualitätsanalyse wird auch nach der Migration im Rahmen des Release-Validierungsprozesses weiterhin verwendet.

Abwicklung von Rollout und Rollback

Sowohl unsere alten als auch unsere neuen Datenerfassungssysteme verwendeten Change Data Capture (CDC), um Daten inkrementell in die Zieltabelle aufzunehmen. Jeder Datenaufnahmejob verfügt über eine eigene interne Tabelle für einen vollständigen Dump der Quelldatenbanken (vollständiger Dump), eine interne Tabelle zum Erfassen von Änderungen der Quelldatenbanken (Delta) und die von den Datenkunden genutzte Zieltabelle. Alle Informationen zu Jobentitäten, einschließlich Tabellennamen und Tabellenschemata, werden vom zentralen Verwaltungsdienst gespeichert und verwaltet.

Da es sich um einen CDC-Prozess handelt, werden die vom System generierten Daten erneut verwendet, um die neuen Daten zu generieren. Das heißt, wenn bei früheren Landedaten Probleme auftreten, werden die problematischen Daten an die neuen Landedaten übergeben. Sollten nach der Migration Probleme auftreten, müssten wir ein Rollback durchführen, um die gelandeten Daten zu reparieren und das Bluten zu stoppen.

Um das Risiko zu reduzieren, haben wir uns auf zwei Lösungen konzentriert:

1. Frühzeitige Signale, bevor problematische Daten beim Datenkunden landen.
2. So stoppen Sie die Blutung beim Rollback schnell.

Erste Signale nach dem Rollout

Anstatt darauf zu warten, dass Datenkonsumenten Probleme mit problematischen Daten entdecken, erhielten wir frühzeitig Signale, die uns anzeigen, ob die Migration erfolgreich ist. Wie bereits erwähnt, trat die Migration nach dem Rollout in die umgekehrte Schattenphase ein. Dies bedeutete, dass die Daten des Schattenjobs in die Produktionstabelle geschrieben wurden, wodurch der Schattenjob effektiv zum neuen Produktionsjob wurde. Und die Daten des Produktionsauftrags wurden in die Schattentabelle geschrieben, sodass der ursprüngliche Produktionsauftrag nun als Schattenauftrag fungiert.

Um frühe Signale zu erhalten, haben wir Backfill sowohl für Produktions- als auch für Schattenjobs ausgelöst. Wenn die Backfill-Ergebnisse weiterhin übereinstimmen, bedeutet dies, dass die Migration erfolgreich war. Wenn das Ergebnis nicht übereinstimmt, wird der Job sofort zurückgesetzt und die Datenkonsumenten sind nicht betroffen.

Schnelles Stoppen der Verbreitung fehlerhafter Daten während des Rollbacks

Wie bereits erwähnt, besteht ein Merkmal des CDC-Prozesses darin, dass problematische Daten auf neu generierte Daten übertragen werden können. Das schnelle Stoppen der Verbreitung fehlerhafter Daten macht die Migration nicht nur robuster, sondern verbessert auch die Zuverlässigkeit nach Abschluss der Migration.

Wenn während der Reverse-Shadow-Phase in einer bestimmten Partition Probleme mit der Datenqualität festgestellt wurden, wurde diese Partition in ihren Metadaten als Partition mit schlechter Datenqualität markiert. Wenn diese Partition eine Delta-Partition wäre, würden keine neuen Daten mehr landen und eine Warnung würde an ein Teammitglied gesendet werden. Wenn diese Partition eine Zielpartition wäre, würde das System stattdessen eine ältere Partition auswählen und diese mit mehr Deltas zusammenführen.

Auf diese Weise konnten wir die Verbreitung fehlerhafter Daten schnell stoppen. Für ein Rollback könnten wir die Metadaten schnell abfragen, um alle Partitionen zu finden, die mit schlechter Datenqualität gekennzeichnet waren, und diese mit Backfill beheben.

Wie wir die groß angelegte Migration durchgeführt haben

Nachdem wir eine kleine Menge Jobs erfolgreich migriert hatten, waren wir zuversichtlich, dass wir die vollständige Migration durchführen würden. Die Herausforderungen dabei ließen sich grob in zwei Bereiche einteilen:

1. So überwachen und migrieren Sie eine große Anzahl von Jobs automatisch. (Diese Herausforderung wird durch die schiere Menge an Arbeitsplätzen, die migriert werden müssen, noch verschärft.)
2. So führen Sie effektive Schattentests mit begrenzter Kapazität durch.

Überwachung mit automatisierten Werkzeugen

Da Zehntausende von Aufnahmejobs migriert werden mussten, haben wir Tools entwickelt, die den gesamten Prozess automatisiert und Reibungsverluste minimiert haben.

Das Ausführen von Schattentests und das Behandeln von Grenzfällen bei einem derart großen Auftragssatz erfordert eine robuste Automatisierung und eine gründliche Validierung, um Zuverlässigkeit und Korrektheit sicherzustellen.

Da wir einen klaren Migrations-Job-Lebenszyklus und Job-Förderkriterien festgelegt haben, sendete das System kontinuierlich Job-Statussignale an Scuba, einschließlich Daten zu den Lebenszyklus-Förderkriterien und der aktuellen Phase des Jobs im Migrations-Lebenszyklus. Wir haben externe Migrationstools entwickelt, die die Signale jedes Jobs kontinuierlich überwachten und Jobs zwischen den Phasen des Migrationslebenszyklus automatisch hoch- oder herabgestuft haben, je nachdem, ob sie die Migrationskriterien erfüllten (oder nicht mehr erfüllten). Wir haben auch Dashboards auf System- und Jobebene erstellt, damit Ingenieure den gesamten Migrationsfortschritt schnell verfolgen sowie einzelne Jobs überwachen und debuggen können.

Planung mit begrenzter Kapazität

Da die Migrationskapazität begrenzt war, konnten wir nicht alle Schattenjobs gleichzeitig ausführen. Stattdessen haben wir die Jobs stapelweise migriert. Die Migrationseffizienz hängt stark davon ab, wie Jobs für jeden Migrationsbatch ausgewählt werden.

Wir haben Aufträge nach verschiedenen Merkmalen wie Durchsatz, Priorität und Sonderfällen kategorisiert. Die Technikteams arbeiteten daran, sicherzustellen, dass die Umgebung ordnungsgemäß vorbereitet wurde, bevor eine Charge erstellt wurde. Sie legten beispielsweise Auswahlkriterien fest, um Jobs mit bekannten Problemen, die noch gelöst werden mussten, auszuschließen und so den durch doppelte Probleme verursachten Lärm zu reduzieren. Aufträge wurden auch nach Geschäftsbedarf priorisiert und Teams, die auf den Service angewiesen waren, wurden vor der Migration benachrichtigt.

Wir haben die Erstellung neuer Schattenjobs mit bekannten Problemen vermieden, bis diese Probleme behoben waren. Wenn ein Problem erkannt wurde, haben wir alle potenziell betroffenen Jobs aus der Migrationsliste entfernt und sie zurückgehalten, bis eine Lösung gefunden wurde.

Wie oben erwähnt, wurde der erste Snapshot eines neuen Jobs aufgrund des CDC-Designs des Systems über einen vollständigen Dump abgerufen, was normalerweise langsam und teuer ist. Wenn wir in einem gelandeten Snapshot Datenqualitätsprobleme festgestellt haben, haben wir auch einen weiteren vollständigen Dump ausgelöst, um einen korrigierten Snapshot zu landen, nachdem die zugrunde liegenden Fehler behoben wurden. Das Erstellen von Schattenjobs, während bekannte Probleme noch vorhanden waren, würde daher viele unnötige vollständige Dumps auslösen, sowohl bei der Joberstellung als auch bei der Wiederherstellung der Datenqualität. Indem wir die Schaffung dieser Arbeitsplätze vermieden haben, haben wir große Mengen zusätzlicher Full-Dump-Arbeit vermieden und die Migrationseffizienz verbessert. Wir haben auch kreative Lösungen entwickelt, wie die Wiederverwendung von Snapshot-Partitionen, die vom alten System zunächst als Snapshot bereitgestellt wurden, um die vollständige Dump-Last zu reduzieren.

Danksagungen

Wir möchten allen Teammitgliedern und der Führung danken, die zum Erfolg dieses Projekts in Meta beigetragen haben.