Ein Schreibpfad, mehrere Einträge: Wie Rippling von Unity Catalog verwaltetes Apache Iceberg™ nutzt

Dies ist ein Gastbeitrag von Tae Lee, Staff Engineer, Data Platform bei Rippling

Bei Rippling ist die Engine, die eine Tabelle schreibt, nicht immer dieselbe Engine, die sie liest. Ein Databricks-Job erstellt vielleicht eine Tabelle, aber der nachgelagerte Consumer ist möglicherweise der Trino-basierte Query-Layer der Rippling Data Cloud, Snowflake oder ein anderer Lakehouse-Reader. Das macht die Entscheidung für einen Catalog zu mehr als nur einem Metadaten-Detail: Sie bestimmt, wer die Tabelle schreiben kann, wer sie pflegt und wie andere Engines sie lesen.

Das bedeutet, dass das Ziel nicht darin besteht, jeden Workload in eine einzige Engine oder einen einzigen Catalog zu zwingen. Das Ziel ist es, jedem Producer die Plattform nutzen zu lassen, auf der er am besten läuft, und gleichzeitig governed Tabellen zu veröffentlichen, die nachgelagerte Systeme ohne Duplizierung konsumieren können.

Von Unity Catalog verwaltete Iceberg-Tabellen sind das Pattern, das wir für den von Databricks erstellten Teil dieser Architektur verwenden.

Die Catalog-Inhaberschaft folgt dem Writer

Unsere Catalog-Strategie beginnt mit einer einfachen Regel: Der Catalog sollte dem Writer folgen.

Für AWS-native Compute-Ressourcen verwenden wir den AWS Glue Data Catalog. Das ist die natürliche Lösung für Workloads, die von AWS-Engines wie Glue, Athena, EMR oder verwandten Infrastrukturen geschrieben werden.

Für von Databricks erstellte Workloads verwenden wir den Unity Catalog. Dies ist besonders wichtig für Apache Iceberg™. Databricks kann externe Iceberg-Tabellen über Föderation lesen, aber diese Tabellen sind nicht dasselbe wie von Unity Catalog verwaltete Iceberg-Tabellen. Wenn Databricks die Tabelle schreiben muss oder wenn der Workload stark von der Performance und Governance von Databricks abhängt, sollte die Tabelle UC-verwaltet sein.

Für von Snowflake erstellte Daten, die plattformübergreifend geteilt werden müssen, verwenden wir den Snowflake Horizon Catalog mit von Snowflake verwalteten Iceberg-Tabellen. Das ist eine separate Catalog-Entscheidung, die von Snowflake als Producer ausgeht.

Das ist der wichtige Unterschied: Iceberg bietet uns ein offenes Tabellenformat, aber der Catalog besitzt weiterhin die Metadaten-Commits, Berechtigungen und den Tabellen-Lebenszyklus. Format-Portabilität und Catalog-Inhaberschaft hängen zusammen, sind aber nicht dasselbe.

Warum verwaltetes Iceberg für Databricks-Workloads

Vor diesem Pattern bedeutete ein von Databricks erstellter Output, der an anderer Stelle konsumiert werden musste, meist eine zusätzliche Übergabe: der Export einer zweiten Kopie nach dem Databricks-Schreibvorgang oder das direkte Schreiben in das konsumierende System und das Zurücklesen über einen Connector oder Föderationspfad, wenn Databricks ihn wieder benötigte. Beide Ansätze funktionieren, führen jedoch zu doppelter Materialisierung, zusätzlichem Compute-Aufwand und Connector-spezifischen Einschränkungen. 

Von Unity Catalog verwaltetes Iceberg bietet uns eine klarere Abgrenzung.

Databricks schreibt die Tabelle nativ. Unity Catalog besitzt die Tabellenmetadaten, das Zugriffsmodell und den Lebenszyklus. Die Tabellendaten und Iceberg-Metadaten werden im S3-Speicher von Rippling gespeichert. 

Externe Engines verbinden sich über die Iceberg REST Catalog API oder Catalog-Föderation. Durch Credential Vending erhalten diese Engines einen eingeschränkten Zugriff auf den zugrunde liegenden Speicher. Die Engines lesen dann die Parquet-Dateien mithilfe ihrer eigenen Compute-Ressourcen direkt aus S3. 

Das ist für uns die Schlüsseleigenschaft. Ein Databricks-Job kann die Tabelle einmal erstellen, und eine nachgelagerte Engine wie Trino, Snowflake, Spark, Athena oder EMR kann dieselbe Tabelle über Standard-Iceberg-Zugriffsmuster konsumieren. Der Consumer muss nicht jede Abfrage über den SQL-Dialekt oder den Execution-Layer einer anderen Engine leiten. Dies verringert die Abhängigkeit von Engine-übergreifender Übersetzung, Pushdown-Verhalten, Throttling und Producer-seitigem Compute für nachgelagerte Lesevorgänge. 

Es ist kein Databricks-Export. Es ist eine offene Iceberg-Tabelle mit einem Databricks-nativen Producer.

Von ML-Outputs zur Data Cloud

Das Pattern ist am nützlichsten, wenn ein von Databricks erstellter Output Teil eines größeren Produkts oder einer größeren Analyseoberfläche werden soll.

Bei Rippling wählen ML- und AI-Workloads immer noch das Ziel, das zum Anwendungsfall passt: Delta-Tabellen, Vektordatenbanken, OpenSearch, oder andere speziell entwickelte Ziele. Verwaltetes Iceberg ist ein ausgewähltes Veröffentlichungsmuster, nicht das Standardziel für jeden ML-Output.

Wo verwaltetes Iceberg eine Rolle spielt, ist die Übergabe. Für ausgewählte Outputs kann ein Databricks-Job eine von Unity Catalog verwaltete Iceberg-Tabelle einmal veröffentlichen. Die Rippling Data Cloud kann dann dieselbe Tabelle über ihren Query-Layer konsumieren, einschließlich Trino-basierter Zugriffsmuster, und sie in nachgelagerten Transformationen, Dashboards und AI-gesteuerten Produktfunktionen verwenden.

Die Architektur sieht so aus:

Das gibt uns eine einzige governed Tabelle und einen einzigen Schreibpfad. Nachgelagerte Consumer benötigen keine doppelte physische Kopie, und Lakeflow-Jobs müssen nicht separat in jedes konsumierende System schreiben.

Der Betrieb ist ebenso wichtig wie die Offenheit

Offene Tabellenformate sind nur die halbe Miete. Iceberg-Tabellen müssen weiterhin gewartet werden: Dateikomprimierung, Ablauf von Snapshots, Bereinigung verwaister Dateien und Statistiken.

Bei in Glue katalogisierten Iceberg-Tabellen gehört diese Wartung zum AWS-nativen Plattformpfad. Glue verfügt über Funktionen zur Tabellenoptimierung, aber es ist immer noch ein separates Betriebsmodell: Wir müssen entscheiden, wo wir diese Funktionen aktivieren, wie wir sie überwachen und wie wir das Verhalten für die Workloads validieren, die Glue verwenden.

Bei von Unity Catalog verwaltetem Iceberg übernimmt Databricks einen größeren Teil dieses Lebenszyklus durch Predictive Optimization, einschließlich automatischer Tabellenwartung, Dateioptimierung und -komprimierung, Erfassung von Statistiken und Optimierung des Datenlayouts für verwaltete Tabellen. Das ist nützlich, da dieselbe Plattform, die die Tabelle schreibt, auch einen Großteil der Pflege übernimmt, die für ihre Performance erforderlich ist.

Dies ist ein Grund, warum wir UC-verwaltetes Iceberg nicht nur als Interoperabilitätsfunktion betrachten. Es ist auch ein Betriebsmodell. Bei von Databricks erstellten Tabellen ist der Wartungspfad ebenso wichtig wie der Lesepfad.

Präzise Betrachtung des Lock-in-Effekts

Diese Architektur reduziert den Daten-Lock-in, beseitigt jedoch nicht alle Abhängigkeiten.

Der Daten-Lock-in ist gering. Die Tabelle ist Iceberg über Parquet im S3-Speicher von Rippling.

Nachgelagerte Engines können die Daten direkt über offene Iceberg-Pattern lesen.

Die Abhängigkeit von Catalog und Governance is real. Unity Catalog bleibt die Control Plane für Metadaten, Berechtigungen, Lineage und das Verhalten verwalteter Tabellen. Wenn wir uns von Databricks verabschieden würden, wären die Daten zwar portabel, aber wir müssten den Catalog und das Wartungssystem ersetzen.

Das ist ein akzeptabler Kompromiss für diese Klasse von Tabellen. UC verdient seinen Platz, wenn Databricks der Producer ist und die Tabelle governed, gewartet und für andere Engines lesbar sein muss.

Das praktische Ergebnis

Der Wert von Unity Catalog-verwaltetem Iceberg besteht nicht darin, dass wir einen einzigen Catalog für jede Tabelle erhalten. Das tut es nicht, und das ist auch nicht unser Ziel.

Der Wert liegt darin, dass wir einen einzigen Schreibpfad für von Databricks erstellte Tabellen erhalten, die nachgelagert offen konsumiert werden müssen. Databricks erhält den nativen Schreib- und Optimierungspfad. Nachgelagerte Systeme erhalten direkten Zugriff auf offene Daten in S3. 

Engines, die über den REST-Catalog auf die Tabelle zugreifen, nutzen dieselbe Metadaten- und Zugriffsschicht, anstatt die Governance zu umgehen

über rohe Speicherpfade. Das ist das praktische Ergebnis:

„Unity Catalog und verwaltetes Iceberg bieten uns das Beste aus beiden Welten: native Performance für unsere AI- und ML-Pipelines und offene Interoperabilität für jeden nachgelagerten Consumer. Ein Schreibpfad, null Duplizierung und eine Governance-Schicht, die jede Engine respektiert, einschließlich der AI-gesteuerten Produkte, die wir für die Data Cloud von Rippling entwickeln.“

Für Rippling geht es bei der Interoperabilität nicht darum, jede Engine austauschbar zu machen. Es geht darum, jede Engine die Arbeit machen zu lassen, in der sie gut ist, während die veröffentlichte Tabelle portabel, governed und für die Systeme nutzbar bleibt, die sie benötigen.

Um mehr über Unity Catalog und die Iceberg-Unterstützung zu erfahren, besuchen Sie die Unity Catalog- Produktseite. 

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