Die Zero-Copy-Illusion: Warum Ihre Multi-Plattform-Iceberg-Strategie zum Scheitern verurteilt ist

Zusammenfassung

Das falsche Versprechen: Ein populärer Mythos suggeriert: Wenn alle Ihre Datenplattformen (Databricks, Snowflake, SAP usw.) Apache Iceberg nutzen, könnten Sie Zero-Copy-Abfragen über sie hinweg ausführen. Das ist technisch und physikalisch unmöglich.

Iceberg ist ein Format, kein Netzwerk: Iceberg ist ein leistungsstarkes offenes Tabellenformat, das Speicherung und Schema-Evolution löst. Es löst nicht die Netzwerklatenz, die Egress-Kosten oder die physische Notwendigkeit, Daten für die Berechnung (etwa JOINs) zu kolokalisieren.

Zero-Copy hat eine einzige Regel: Nähe. Echte Zero-Copy-Analytics funktioniert nur, wenn die Compute-Engine direkt zu den Daten gebracht wird („Compute-to-Data"). Das ist nur innerhalb eines einzigen, physisch kolokalisierten Systems möglich (z. B. innerhalb einer Databricks-Umgebung in einer Cloud-Region).

Die unausweichliche Wahrheit über JOINs: Jede Abfrage, die große Tabellen mit hoher Kardinalität aus getrennten Plattformen verbindet (z. B. Kunden in Databricks und Aufträge in SAP), muss Daten über ein Netzwerk in den Speicher einer Engine bewegen. In diesem Moment endet Zero-Copy.

Die echte Lösung ist ein Knowledge Layer: Statt der Zero-Copy-Illusion nachzujagen, akzeptiert die korrekte Architektur die Notwendigkeit selektiver Datenbewegung. Ein Knowledge Layer (Wissensschicht) vereinheitlicht die Bedeutung (Semantik, Identitäten, Beziehungen) Ihrer Daten – nicht die Rohdaten selbst – und bietet so ein stabiles Fundament für Analytics und KI, das dem Chaos einer Multi-Plattform-Realität standhält.

Einleitung: der architektonische Trugschluss, der das Unternehmen erfasst

In den Kreisen der Enterprise-Architektur wird eine verführerische Geschichte erzählt. Sie geht so: „Weil all unsere großen Plattformen – Databricks, Azure Fabric, SAP Datasphere, Snowflake – nun eine gemeinsame Sprache namens Apache Iceberg sprechen, können wir endlich eine echte Zero-Copy-Datenlandschaft erreichen. Keine Replikation mehr, kein ETL mehr, nur noch ein einziger, einheitlicher Abfrageraum."

Diese Vision ist mächtig. Sie ist auch eine gefährliche Fehldeutung dessen, was Iceberg und Zero-Copy tatsächlich leisten können.

Die unbequeme Wahrheit ist: Ein gemeinsames Tabellenformat löscht physische Grenzen nicht auf magische Weise aus. Ihre Multi-Plattform-Iceberg-Strategie wird keine Zero-Copy-Utopie liefern. Tatsächlich wird sie bei den wichtigsten Unternehmensabfragen – jenen, die Domänen überspannen – scheitern. Das ist keine Frage der Meinung; es ist eine Frage der Physik.

Sezieren wir die technische Realität, Stück für Stück.

Was Zero-Copy wirklich ist (und wann es funktioniert)

Bei Zero-Copy geht es nicht darum, null Datenbewegung zu haben. Es geht darum, die Notwendigkeit persistenter, redundanter Datenkopien zu beseitigen. Der einzige Weg, auf dem das in der Praxis funktioniert, führt über ein Muster namens Compute-to-Data:

Anstatt Petabytes an Daten zu einer zentralen Engine zu bewegen, schiebt die Abfrage-Engine ihre Logik dorthin, wo die Daten physisch liegen.

Das funktioniert hervorragend unter einer nicht verhandelbaren Bedingung: Nähe. Der Compute-Cluster und die Speicherschicht müssen innerhalb derselben logischen und physischen Grenze leben – derselben Cloud-Region, demselben virtuellen Netzwerk und idealerweise derselben Plattform.

Innerhalb einer einzigen Databricks- oder Snowflake-Umgebung ist das hochwirksam. Die Engine kann Parquet-Dateien direkt in einem S3-Bucket in derselben Region scannen, Filter anwenden und nur die winzige Ergebnismenge zurückbewegen. Das ist echte Zero-Copy-Analytics.

Das Problem entsteht, wenn Architekten annehmen, dieser Vorteil ließe sich über Plattformen hinweg ausdehnen.

Wo die Illusion zerbricht: die Physik von Daten-JOINs

Eine JOIN-Operation ist das Arbeitspferd der Analytics; sie kombiniert Daten aus mehreren Tabellen. Und genau hier stirbt der plattformübergreifende Zero-Copy-Traum. Jeder JOIN erfordert, dass die Zeilen beider Tabellen im selben Speicherbereich zusammengeführt werden, um verglichen zu werden.

Liegen Tabellen auf verschiedenen Plattformen, in verschiedenen Storage-Accounts oder in verschiedenen Clouds, bleibt der Engine keine Wahl, als Daten über das Netzwerk zu ziehen. Besonders schmerzhaft ist das bei Joins mit hoher Kardinalität.

Der Bruchpunkt: hohe Kardinalität „für Einsteiger"

Nutzen wir eine Analogie: die zwei Telefonbücher.

Stellen Sie sich vor, Sie haben zwei riesige Telefonbücher – eines für Berlin und eines für Hamburg.

• Ein Join mit niedriger Kardinalität: Ihre Aufgabe ist es, jede Person namens „Anna Schmidt" zu finden, die in beiden Telefonbüchern vorkommt. Das ist einfach. Eine Person in Berlin kann „Anna Schmidt" nachschlagen und die wenigen Treffer am Telefon einer Kollegin in Hamburg vorlesen, die dasselbe tut. Sie vergleichen die kurzen Listen und finden die Übereinstimmungen. Das entspricht einem Join über ein Feld mit wenigen eindeutigen Werten. Es ist per Föderation handhabbar.
• Ein Join mit hoher Kardinalität: Nun ist Ihre Aufgabe, jede einzelne Person zu finden, die in beiden Telefonbüchern aufgeführt ist. Das ist ein „many-to-many"-Join (m:n) über ein Feld mit Millionen eindeutiger Werte (dem Namen der Person). Der Versuch, das am Telefon zu erledigen, ist unmöglich. Sie können nicht Millionen von Namen hin und her vorlesen. Der einzig vernünftige Weg ist, ein Telefonbuch physisch in die andere Stadt zu verschicken (Replikation/Materialisierung). Mit beiden Büchern im selben Raum können Sie sie effizient nebeneinander vergleichen.

Unternehmens-JOINs – etwa der Abgleich von Millionen Kunden-IDs mit Milliarden Transaktionsereignissen – sind das Problem des zweiten Telefonbuchs. Sie müssen die Daten zusammenbringen. Es gibt keinen magischen Zero-Copy-JOIN am Himmel.

Die moderne Realität: Iceberg-Dateninseln

„Aber", wendet der Architekt ein, „unsere Daten liegen doch gar nicht mehr im ERP oder CRM. Wir haben sie bereits in Datenprodukte auf unseren verschiedenen Lakehouse-Plattformen repliziert!"

Das stimmt, und es ist ein guter erster Schritt. Aber es löst das Kernproblem nicht. Es verschiebt nur die Inseln. Ihre Landschaft sieht nun so aus:

• SAP-Daten landen als Iceberg-Tabellen in einer SAP-Datasphere-Umgebung.
• Salesforce- und Weblog-Daten landen als Iceberg-Tabellen in einer Databricks-on-AWS-Umgebung.
• Finanzdaten landen als Iceberg-Tabellen in einer Azure-Fabric-Umgebung.

Sie haben weiterhin drei physisch getrennte Dateninseln. Eine Abfrage, die Kundenaktivitäten aus Databricks mit Finanzdaten aus Azure Fabric verbinden muss, muss nach wie vor Daten über ein Netzwerk verschicken. Das Format ist dasselbe, aber die physischen Standorte sind verschieden. Das Zero-Copy-Versprechen ist weiterhin gebrochen.

Die wahre architektonische Antwort: ein Knowledge Layer

Wenn plattformübergreifendes Zero-Copy ein Mythos ist – was ist dann die Lösung?

Sie hören auf, gegen die Physik zu kämpfen, und beginnen, die Realität zu managen. Das Ziel sollte nicht sein, Datenbewegung zu beseitigen, sondern sie intelligent, minimal und bedeutungsvoll zu machen. Das ist die Rolle eines Enterprise Knowledge Layer.

Ein Knowledge Layer, aufgebaut auf einer formalen Ontologie, zielt nicht darauf ab, Rohdaten zu vereinheitlichen. Er sitzt oberhalb Ihrer Datenprodukt-Inseln und vereinheitlicht das Wissen über die Daten:

• Er kopiert Semantik, nicht Daten. Er materialisiert die kritischen Identitäten, Beziehungen und Geschäftsregeln, die Ihr Unternehmen definieren. Das sind typischerweise weniger als 1 % Ihres gesamten Datenvolumens.
• Er bietet einen stabilen Bezugspunkt. Systeme und Plattformen können sich ändern, doch die semantische Definition von „Kunde" bleibt im Knowledge Graph stabil.
• Er ermöglicht intelligente Abfragen. Anstatt Joins zu erraten, fragt ein KI-Assistent oder ein BI-Werkzeug zuerst den Knowledge Graph ab, um den semantischen Kontext zu verstehen, und erzeugt dann einen effizienten Plan, um nur die nötigen Daten zu holen – mit Föderation für kleine Tabellen und selektiver Materialisierung für große Joins mit hoher Kardinalität.

Fazit: Hören Sie auf, der Illusion nachzujagen

Zero-Copy-Analytics ist ein reales und wertvolles Muster – aber nur innerhalb der Mauern einer einzigen, homogenen Plattform. Die Vorstellung, dass eine Standardisierung auf Iceberg diesen Vorteil über Ihr gesamtes, heterogenes Unternehmen ausdehnt, ist ein Trugschluss.

Selbst wenn Ihre Daten in modernen Iceberg-Datenprodukten liegen, existieren diese Produkte auf physisch getrennten Plattformen. Ein gemeinsames Format schafft keine gemeinsame Architektur. Die erfolgreiche Strategie besteht darin, diese physische Realität anzunehmen und eine stabile, semantische Wissensschicht aufzubauen, um sie zu steuern. So verwandeln Sie eine Ansammlung von Dateninseln in ein wirklich vernetztes Unternehmen.