Datenportabilität freisetzen: Catalog-Lock-in verhindern mit den REGISTER- und UNREGISTER-APIs

Da Unternehmen zunehmend auf die Lakehouse-Architektur setzen, verlagern sich Daten von proprietären Data Warehouses in offene Speicher- und Tabellenformate, wo über mehrere Engines wie Spark und Trino ohne Duplizierung auf sie zugegriffen werden kann.

Offene Formate sind jedoch nur ein Teil der Gleichung für Offenheit. Echte Offenheit erfordert auch Interoperabilität und Flexibilität bei der Verwaltung und Governance von Daten. Damit ein Lakehouse sein Versprechen voll einlösen kann, benötigen Unternehmen die Freiheit, Catalogs zu wählen und zwischen ihnen zu wechseln, wenn sich ihre Architektur weiterentwickelt.

Um diese Portabilität zu unterstützen, ermöglichen es die REGISTER- und UNREGISTER-Endpunkte den Benutzern, eine Tabelle zwischen Catalogs zu übergeben, ohne eine einzige Datei neu zu schreiben, zu exportieren oder zu kopieren. REGISTER hängt eine bestehende Tabelle an einen beliebigen IRC-Catalog an. Beim Verschieben einer Tabelle können Sie diese nicht einfach aus dem alten Catalog mit DROP entfernen, da dadurch die zugrunde liegenden Daten und Metadaten gelöscht werden. Wir haben den UNREGISTER-Endpunkt zur Apache Iceberg™ REST-Catalog-Spezifikation hinzugefügt, damit Sie dem alten Catalog mitteilen können, die Tabelle zu vergessen, und genau den Pointer zurückzugeben, den der nächste Catalog zur Übernahme benötigt.

In diesem Beitrag werfen wir einen genaueren Blick darauf, wie sich das Ökosystem der offenen Tabellenformate entwickelt, welche zentralen Herausforderungen diese Ergänzungen lösen und wie REGISTER sowie der neue UNREGISTER-Befehl tatsächlich funktionieren.

Hintergrund: Die Rolle des Catalogs

Wenn eine Engine eine Tabelle abfragt, bittet sie zuerst den Catalog, die Tabelle zu laden, um sicherzustellen, dass sie den neuesten Zustand aufweist. Der Catalog gibt die aktuellen Metadaten der Tabelle zurück, einschließlich des Speicherorts der Tabellendaten im Objektspeicher. Von dort aus verwendet die Engine diese Metadaten, um das Schema zu finden, und liest die Parquet-Dateien direkt aus dem Objektspeicher.

Diese Koordinierung ist für offene Tabellenformate unerlässlich, da alle wichtigen Metadaten – Schema, Verlauf, Statistiken – und die Daten selbst im Speicher liegen, völlig entkoppelt von der Rechenleistung (Compute). Indem der Catalog als zentrale Instanz für diesen neuesten Zustand fungiert, koordiniert er Commits und stellt sicher, dass zwei Writer sich niemals unbemerkt gegenseitig überschreiben können.

Abbildung 1: Der Lesepfad

1. Die Engine bittet den Catalog, die Tabelle zu laden.
2. Der Catalog gibt die aktuellen Metadaten der Tabelle und ihren Speicherort im Objektspeicher zurück.
3. Die Engine liest die Metadaten und die Datendateien direkt aus Ihrem Bucket.

Wie der REGISTER-Endpunkt funktioniert

Das Anhängen einer vorhandenen Tabelle an einen Catalog ist einfach eine Frage der Übergabe des Metadaten-Speicherorts aus dem Laden der Tabelle. Genau das tut REGISTER über den bereits in der Iceberg-REST-Spezifikation definierten Endpunkt.

Abbildung 2: Die REGISTER-Operation

• Ein Client sendet eine POST-Anfrage mit dem gewünschten Tabellennamen und dem URI des vorhandenen Metadaten-Speicherorts.
• Nach einer grundlegenden Validierung schreibt der Catalog einen einzelnen Datensatz, der den Tabellennamen mit der vorhandenen metadata.json verknüpft. Es werden keine Datendateien kopiert, verschoben oder geändert.

Der Haken an der Sache ist, dass REGISTER allein ein „Split-Brain“-Szenario erzeugen würde, bei dem zwei Catalogs glauben, sie seien Eigentümer der Tabelle, und Commits koordinieren würden. Da Iceberg-Catalogs unabhängig sind und nicht miteinander kommunizieren, fügt REGISTER allein einen Eintrag im neuen Catalog hinzu, während der alte vollständig aktiv bleibt. Wenn beide Catalogs glauben, sie seien der alleinige Eigentümer der Tabelle, wird keiner von beiden einen Fehler ausgeben, aber der erste Schreibvorgang wird die Tabelle verzweigen (forken), was zu inkonsistenten Abfrageergebnissen und unbemerktem Datenverlust führt.

Abbildung 3: Das Split-Brain-Szenario

• Ein über Catalog A erfolgter Schreibvorgang ist für Catalog B völlig unsichtbar, was Ihre Single Source of Truth dauerhaft zerstört.

Das fehlende Puzzleteil war UNREGISTER

In der Vergangenheit fehlte dem Ökosystem eine standardisierte Methode, um die Verwaltung einer Tabelle durch einen Catalog sauber zu beenden. Das Ausführen von DROP TABLE funktioniert nicht, da dadurch die Daten und Metadaten der Tabelle gelöscht werden! Ohne UNREGISTER fehlte der Übergabegleichung für REGISTER die zweite Hälfte. Wir haben UNREGISTER zur Apache Iceberg™ REST-Catalog-Spezifikation beigesteuert, um den Eintrag der Tabelle aus dem verwaltenden Catalog zu entfernen, ohne eine einzige zugrunde liegende Datendatei anzurühren.

Entscheidend ist, dass es den neuesten Metadaten-Speicherort der Tabelle zurückgibt – genau den Pointer, den der nächste Catalog benötigt, um die Commit-Koordinierung zu übernehmen. Indem sichergestellt wird, dass der ursprüngliche Catalog die Kontrolle explizit abgibt, wird das Risiko eines Split-Brain-Szenarios eliminiert.

Die Anfrage ist ein leerer POST an die Tabellenressource:

POST <uc-iceberg-rest-base>/v1/{prefix}/namespaces/{namespace}/tables/{table}/unregister

Die Antwort ist der Pointer, den der nächste Catalog benötigt:

Abbildung 4: Der Übergabeprozess

1. UNREGISTER entfernt den Eintrag der Tabelle aus Catalog A (die Dateien bleiben genau dort, wo sie sind).
2. Die Antwort gibt den neuesten Metadaten-Speicherort der Tabelle zurück.
3. Catalog B übernimmt den Pointer über den REGISTER-Endpunkt. Catalog B ist nun der einzige verwaltende Catalog der Tabelle.

Durch die Kombination dieser drei Schritte – Unregister, Erhalt des Speicherorts und Register – stellt die Übergabe sicher, dass die Tabelle zu jedem Zeitpunkt genau einen verwaltenden Catalog hat. (Hinweis: Eine Migration in der Produktion umfasst immer noch betriebliche Schritte wie das sichere Stoppen von Writern und das Neuausrichten von Jobs, die wir in einem Folgebeitrag behandeln werden.)

Erste Schritte

Mit REGISTER und UNREGISTER haben Sie nun die Freiheit, Ihre Tabellen in andere Catalogs zu verschieben. Wir fügen diese Funktion hinzu, da Open-Source-Portabilität für unsere Kunden von entscheidender Bedeutung ist. Unity Catalog bleibt das offenste Lakehouse für die Verwaltung Ihrer Daten und bietet die einheitliche Governance, die das Zeitalter der Agenten erfordert. Er stellt die Kontextschicht für Ihre Ontologie bereit, bietet erstklassige Zugriffskontrolle und Observability über Daten und Agenten hinweg und liefert Flexibilität über Clouds, Regionen und Compute hinweg.

Um REGISTER und UNREGISTER auf Unity Catalog in der Private Preview auszuprobieren, wenden Sie sich an Ihr Account-Team.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag