Tulip: Modernisierung der Datenplattform von Meta

Migrationen sind schwierig. Darüber hinaus werden sie bei Meta viel schwieriger, weil:

Bevor wir auf die Details der Migrationsgeschichte eingehen, möchten wir einen Schritt zurücktreten und versuchen, die Motivation und den Grund für diese Migration zu erklären.

Im Laufe der Zeit hat sich die Datenplattform in verschiedene Formen verwandelt, da die Anforderungen des Unternehmens gewachsen sind. Was in den Anfängen eine bescheidene Datenplattform war, hat sich zu einer Plattform im Exabyte-Bereich entwickelt. Einige Systeme, die einen kleineren Maßstab bedienten, zeigten Anzeichen dafür, dass sie den gestiegenen Anforderungen, die an sie gestellt wurden, nicht mehr genügten. Vor allem sind wir auf einige konkrete Zuverlässigkeits- und Effizienzprobleme im Zusammenhang mit der (De-)Serialisierung von Daten gestoßen, was uns dazu veranlasst hat, die Art und Weise, wie wir Daten protokollieren, zu überdenken und die Ideen der Grundprinzipien zu überdenken, um diese dringenden Probleme anzugehen.

Logger ist das Herzstück der Datenplattform. Das System wird verwendet, um Analyse- und Betriebsdaten über Scribe in Scuba-, Hive- und Stream-Processing-Pipelines zu protokollieren. Jedes Produkt- und Datenplattformteam interagiert mit der Protokollierung. Das Datenformat für die Protokollierung war aus alten Gründen entweder Hive Text Delimited oder JSON. Die Einschränkungen dieser Formate werden in unserem vorherigen Artikel über Tulip beschrieben.

Um diese Einschränkungen zu beheben, wurde das Tulip-Serialisierungsformat entwickelt, das die alten zielspezifischen Serialisierungsformate ersetzt.

Die folgenden Diagramme stellen den Migrationsweg für die Konvertierung des Serialisierungsformats in Tulip grafisch dar, um den Fortschritt in verschiedenen Phasen und Meilensteinen zu zeigen.

Wir können sehen, dass die Anzahl der Protokollierungsschemata zwar ungefähr gleich blieb (oder ein gewisses organisches Wachstum verzeichnete), die protokollierten Bytes jedoch aufgrund der Änderung des Serialisierungsformats deutlich zurückgingen. Die Details zu formatspezifischen Byteeinsparungen sind im folgenden Abschnitt tabellarisch aufgeführt.

Hinweis: Die Zahlen in Diagramm 2 werden (auf den Gesamtverkehr) hochgerechnet, basierend auf den tatsächlichen Einsparungen, die für die fünf größten Protokollierungsschemata (nach Volumen) beobachtet wurden.

Wir möchten unsere Migrationsreise als zwei unterschiedliche Phasen mit jeweils eigenen Perspektiven darstellen.

Wenn Sie das System unter Berücksichtigung der Migration entwerfen, wird die Migration wesentlich einfacher. Die folgenden technischen Lösungen wurden entwickelt, um sicherzustellen, dass das Team mit den notwendigen Werkzeugen und Infrastrukturunterstützung ausgestattet ist, um das Kabelformat sicher umzustellen und Probleme, die während der Migrationsphase auftreten können, auf skalierbare Weise zu beheben.

Die Lösungen fielen grob in die folgenden Kategorien:

Herausforderung: Wie kann man die Migration erleichtern und das Risiko verringern, indem man nicht verlangt, dass die Datenproduzenten und -konsumenten die Serialisierungsformate atomar wechseln?

Lösung: Bei der Umstellung eines einzelnen Protokollierungsschemas auf die Verwendung des neuen Tulip-Serialisierungsprotokolls zum Schreiben von Nutzlasten war die Unterstützung von Nutzlasten im gemischten Modus auf einem einzelnen Scribe-Stream erforderlich, da es unmöglich wäre, alle Datenproduzenten „atomar“ auf die Verwendung des neuen Formats umzustellen . Dies ermöglichte es dem Team auch, die Einführung der neuen Formatserialisierung zu begrenzen.

Das Mixed-Mode-Drahtformat war wichtig für die Unterstützung des Konzepts der Shadow-Logger, die vor einer groß angelegten Einführung ausgiebig für End-to-End-Abnahmetests eingesetzt wurden.

Die größte Herausforderung für das Wire-Format im gemischten Modus bestand darin, dass die bestehende Serialisierung von Nutzdaten weder im Hive-Text- noch im JSON-Format geändert werden konnte. Um diese Einschränkung zu umgehen, wird jeder serialisierten Nutzlast von Tulip die 2-Byte-Sequenz 0x80 0x00 vorangestellt, bei der es sich um eine ungültige UTF-8-Sequenz handelt.

Herausforderung: In einigen Systemen war das Serialisierungsformat Hive Text (oder JSON) in den Anwendungscode eingedrungen, der schließlich auf dieses Format für die Nutzung von Nutzdaten angewiesen war. Dies ist darauf zurückzuführen, dass Verbraucher die Abstraktion des Serialisierungsformats durchbrechen.

Lösung: Zwei Lösungen bewältigten diese Herausforderung.

Reader (Logger-Gegenstück zur Deserialisierung von Daten)

Reader ist eine Bibliothek, die eine serialisierte Nutzlast in ein strukturiertes Objekt umwandelt. Reader (wie Logger) gibt es in zwei Varianten: (a) durch Code generiert und (b) generisch. Ein Reader-Objekt konsumiert Daten in einem der drei Formate – Tulip, Hive Text oder JSON – und erzeugt ein strukturiertes Objekt. Dies ermöglichte es dem Team, Verbraucher vor Beginn der Migration auf Lesegeräte umzustellen. Der Anwendungscode musste aktualisiert werden, um dieses strukturierte Objekt anstelle einer rohen serialisierten Zeile zu verwenden. Dadurch wurde das Wire-Format von den Verbrauchern der Daten abstrahiert.

Konvertierung in ältere Formate bei Verbrauchern

Für Anwendungsfälle, in denen die Aktualisierung des Anwendungscodes zur Nutzung eines strukturierten Objekts nicht durchführbar oder zu teuer war (aus Sicht der technischen Kosten), haben wir das verbrauchende System mit einem Formatkonverter ausgestattet, der die serialisierte Tulip-Nutzlast konsumiert und in einen Hive-Text konvertiert (oder JSON) serialisierte Nutzlast. Dies war im Hinblick auf die CPU-Auslastung ineffizient, ermöglichte es dem Team jedoch, die Migration für eine lange Reihe von Anwendungsfällen voranzutreiben.

„Das Debuggen ist doppelt so schwierig wie das Schreiben des Codes. Wenn Sie also den Code so geschickt wie möglich schreiben, sind Sie per Definition nicht schlau genug, um ihn zu debuggen.“ — Brian W. Kernighan

Herausforderung: Einfaches visuelles Testen und Validieren von Daten nach der Migration in einem Protokollierungsschema ermöglichen.

Lösung: Das Loggertail-CLI-Tool wurde entwickelt, um die Validierung von Daten nach der Migration in der Scribe-Warteschlange eines bestimmten Protokollierungsschemas zu ermöglichen. Loggertail verwendet einen generischen Deserialisierer. Es fragt das Serialisierungsschema nach einem benannten Protokollierungsschema ab und verwendet es zum Dekodieren der Eingabenachricht. Anschließend wird eine für Menschen lesbare Liste von Paaren (Feldname, Feldwert) erstellt und die Daten als JSON-Objekt gedruckt.

„Waren Sie derjenige, der in die Box ging, oder derjenige, der wieder herauskam? Wir wechselten uns ab. Der Trick ist, wo wir tauschen würden.“ - "Das Prestige"

Herausforderung: End-to-End-Test und Verifizierung der über das neue Format protokollierten Daten.

Lösung: Shadow-Logger ahmten das ursprüngliche Protokollierungsschema nach, mit der Ausnahme, dass sie Daten in Tabellen protokollierten, die das Logger-Team überwachte. Dabei handelte es sich um einen umfassenden Abnahmetest.

Zusätzlich zu den vom Benutzer angegebenen Spalten verfügte ein Schattenprotokollierungsschema über zwei zusätzliche Spalten.

Die Shadow-Logger protokollierten jedes Mal einen kleinen Teil der Zeilen in einer Shadow-Tabelle, wenn die Protokollierung im ursprünglichen Protokollierungsschema angefordert wurde. Mithilfe eines Spark-Jobs wurden die Zeilen in diesen Tabellen analysiert und sichergestellt, dass die Inhalte für Zeilen mit derselben ID, aber einem anderen Serialisierungsformat identisch waren. Diese Validierung gab dem Team vor dem Rollout hohes Vertrauen.

Herausforderung: Wie können wir den Blutverlust im Falle eines Problems während der Einführung der Tulip-Serialisierung in ein Protokollierungsschema schnell eindämmen?

Lösung: Obwohl für jedes zu migrierende Protokollierungsschema eine Validierung über Shadow-Logger durchgeführt wurde, mussten wir uns auf unvorhergesehene Probleme während der Migration einstellen. Wir haben einen Geschwindigkeitsbegrenzer entwickelt, um das Risiko zu verringern und es dem Team zu ermöglichen, die Blutung schnell zu stoppen.

Da noch über 30.000 Protokollierungsschemata übrig waren, konzentrierte sich die Skalierungsphase der Migration auf die Durchführung der Migration, wobei diese in Selbstbedienung und mit Automatisierung erfolgte. Ein weiterer wichtiger Aspekt der Skalierungsphase bestand darin, sicherzustellen, dass die Ingenieure möglichst wenig Reibung erleben.

Herausforderung: Wie wählt man die zu migrierenden Schemata basierend auf den Datenkonsumenten des entsprechenden Scribe-Streams aus?

Lösung: Jedes Protokollierungsschema wurde basierend auf den Downstream-Konsumenten des entsprechenden Scribe-Streams kategorisiert. Nur die Protokollierungsschemata, die alle unterstützten Downstream-Konsumenten hatten, wurden als bereit für die Nutzung des Tulip-Formats angesehen.

Mithilfe dieser Daten wurde ein Tool erstellt, sodass ein Techniker lediglich ein Skript ausführen musste, das automatisch nicht migrierte Protokollierungsschemata zur Konvertierung ansteuert. Wir haben auch Tools entwickelt, um potenzielle Datenverluste für die Zielprotokollierungsschemata zu erkennen.

Schließlich wurde dieses Tool täglich von einem Cron-ähnlichen Planungssystem ausgeführt.

Herausforderung: Das Team musste sich bei der Migration mit zahlreichen nichttechnischen Aspekten befassen. Beispielsweise die Motivation der Endbenutzer, tatsächlich zu migrieren, und ihnen Unterstützung zu bieten, damit sie die Migration sicher und einfach durchführen können.

Lösung: Da die Migration von Fall zu Fall unterschiedlich groß und komplex war, haben wir zunächst den Entwicklungsteams durch Aufgaben Vorlaufzeit für die Planung der Migration gegeben. Wir haben einen Live-Migrationsleitfaden zusammen mit einem Demovideo erstellt, in dem einige Logger migriert wurden, um Endbenutzern zu zeigen, wie dies durchgeführt werden sollte. Anstelle eines Migrationsleitfadens, der einmal geschrieben und nie (oder nur selten) aktualisiert wurde, wurde beschlossen, diesen Leitfaden am Leben zu halten und ständig weiterzuentwickeln. Es wurden eine Selbsthilfegruppe und Sprechzeiten eingerichtet, um Benutzern zu helfen, wenn sie auf Blocker stoßen. Diese waren besonders nützlich, da Benutzer ihre Erfahrungen und die Art und Weise, wie sie entsperrt wurden, gepostet haben, was anderen Benutzern geholfen hat, die Dinge in Gang zu bringen, wenn sie auf ähnliche Probleme gestoßen sind.

Große Einsätze zu tätigen, etwa die Transformation von Serialisierungsformaten auf der gesamten Datenplattform, stellt kurzfristig eine Herausforderung dar, bietet jedoch langfristige Vorteile und führt im Laufe der Zeit zu einer Weiterentwicklung.

Für den Erfolg ist es wichtig, Lösungen zu entwerfen und zu entwickeln, die sowohl die technischen als auch die nichttechnischen Aspekte einer Migration dieser Größenordnung berücksichtigen. Wir hoffen, dass wir einen Einblick in die Herausforderungen geben konnten, mit denen wir konfrontiert waren, und in die Lösungen, die wir in diesem Prozess eingesetzt haben.

Wir möchten den Mitgliedern des Datenplattform-Teams danken, die mit dem Logger-Team zusammengearbeitet haben, um dieses Projekt zu einem Erfolg zu machen. Ohne die funktionsübergreifende Unterstützung dieser Teams und die Unterstützung der Benutzer (Ingenieure) bei Meta wären dieses Projekt und die anschließende Migration nicht möglich gewesen.