Zero-Copy: Das Ende von ETL und die Zukunft der KI

Das ist das schmutzige Geheimnis des KI-Booms: Die Modelle sind brillant, aber die Installationen sind uralt.

Sie bauen ein hochmodernes Transformatormodell. Sie sichern H100-GPU-Cluster. Aber dann warten Sie 24 Stunden, bis die ETL-Pipeline (Extrahieren, Transformieren, Laden) ausgeführt wird, damit Ihr Modell die neuen Verkaufsdaten tatsächlich sehen kann. Zum Zeitpunkt der Ausführung der Schlussfolgerung ist der Kunde bereits abgewandert.

Dies ist die „Datenreibungssteuer“, die den KI-ROI vernichtet.

Im Jahr 2025 repariert die Branche endlich die Sanitäranlagen. Entwicklungsteams bewegen sich von der Ära des Data Warehousing zur Ära der Unified Data Platforms, insbesondere Architekturen, die auf der „Zero-Copy“-Philosophie basieren. Wenn Sie KI-Systeme erstellen, müssen Sie verstehen, warum das Kopieren von Daten zu einem architektonischen Anti-Pattern wird.

Die Physik des Problems: Warum ETL schlecht skaliert

Um zu verstehen, warum Zero-Copy wichtig ist, muss man sich die Ineffizienz herkömmlicher Stacks ansehen.

In einem Standardunternehmen leben Daten effektiv in „Schwerkraftbrunnen“ – Salesforce für CRM, SAP für ERP, AWS S3 für Protokolle. Um diese Daten zu analysieren, haben Ingenieure in der Vergangenheit Pipelines erstellt, um sie physisch von Quelle A nach Ziel B zu kopieren (normalerweise ein Data Warehouse wie Redshift oder Snowflake).

Dies führt eine grundlegende Latenzgleichung ein:

$$\text{Latency} = T_{extract} + T_{transfer} + T_{load} + T_{indexing}$$

Jedes Mal, wenn Sie Daten kopieren, führen Sie Folgendes ein:

1. Latenz: Das Problem der „veralteten Daten“. Wenn die Pipeline jede Nacht läuft, ist die KI immer 24 Stunden hinter der Realität zurück.
2. Kosten: Unternehmen zahlen spezifische Speicherkosten für das Duplikat. Das Speichern von 1 PB Daten ist überschaubar; Die Lagerung von 5 Exemplaren davon (Roh, Bronze, Silber, Gold, Lager) ist exorbitant.
3. Serialisierungsaufwand: Die CPU-Kosten für die Standardisierung von JSON/CSV in Parquet/Avro (SerDes) verbrauchen enorme Rechenmengen, die für Rückschlüsse verwendet werden könnten.
4. Drift: Das Schema in Quelle A ändert sich (z. B. ein Entwickler benennt user_id in uuid um), wodurch die Pipeline zu Ziel B unterbrochen wird.

Dataversity warnt davor, dass eine schlechte Datenqualität, die oft auf diese fragilen Pipelines zurückzuführen ist, dazu führen könnte, dass 60 % der KI-Projekte im kommenden Jahr abgebrochen werden. Die Lösung sind nicht schnellere Pipelines; es sind keine Pipelines.

Die Entwicklung der Datengravitation

Um die Zero-Copy-Revolution zu würdigen, ist es hilfreich, die Entwicklung der Datenarchitektur in den letzten zwei Jahrzehnten abzubilden. Die Branche schwankt zwischen Kopplung und Entkopplung.

Phase 1: Der Monolith (1990-2010)

Am Anfang war die Oracle-Datenbank. Speicher und Rechenleistung waren eng miteinander verbunden. Wenn Sie eine schnellere Abfrage ausführen wollten, kauften Sie eine größere Box. Es war konsistent und schnell (ACID-konform), konnte jedoch nicht horizontal skaliert werden. Es erstickte an der Menge an Web-Scale-Daten.

Phase 2: Der Data Lake / Der „Sumpf“ (2010-2018)

Die Hadoop-Ära führte HDFS ein. Die Philosophie lautete „Schema on Read“. Legen Sie einfach alle JSON-Protokolle in einem billigen Speicher ab und finden Sie es später heraus. Dadurch wurde das Problem der Lagerkosten gelöst, es entstand jedoch ein „Sumpf“. Die Abfrageleistung war schrecklich und ohne Transaktionen ging die Datenintegrität verloren. KI-Modelle, die auf diesen Daten trainiert wurden, halluzinierten häufig, weil die Eingabedaten fehlerhaft oder unvollständig waren.

Phase 3: Das Cloud Warehouse (2018–2023)

Snowflake und BigQuery trennten den Speicher (S3/GCS) von der Rechenleistung. Das war ein Durchbruch. Sie könnten den Speicher unbegrenzt skalieren und Rechencluster bei Bedarf einrichten. Das Format war jedoch immer noch proprietär. Um Snowflake verwenden zu können, mussten Sie Snowflake COPY INTO. Die Daten waren in ihren Mikropartitionen gesperrt. Sie mussten immer noch die Bytes verschieben.

Phase 4: Das Zero-Copy Lakehouse (2024+)

Dies ist der aktuelle Wendepunkt. Die Daten bleiben in S3, aber in offenen Formaten (wie Apache Iceberg). Die Rechenmaschine (Snowflake, Spark, Trino, Dremio) besucht die Daten dort, wo sie sich befinden. Es gibt kein COPY INTO. Es gibt nur SELECT * FROM.

Technischer Deep Dive: Wie Zero-Copy tatsächlich funktioniert

„Zero-Copy“ ist eine falsche Bezeichnung. Die Bits sind irgendwo auf einer Festplatte vorhanden. Architektonisch bedeutet dies jedoch, dass das System die Bytes nicht auf die Recheneinheit verschiebt; Es überträgt die Rechenberechtigungen auf die Bytes (oder teilt insbesondere die Zeiger).

Moderne „Open Table Formate“ wie Apache Iceberg, Delta Lake und Apache Hudi sind hier die Möglichmacher. Sie ermöglichen es verschiedenen Computer-Engines, dieselben Dateien im Objektspeicher anzusehen, ohne sie „besitzen“ zu müssen.

Die Metadatenschicht

Die Magie geschieht in den Metadaten. Anstatt eine 10-TB-Tabelle zu kopieren, teilt ein Zero-Copy-System eine Manifestdatei: eine Liste von Zeigern auf die Parquet-Dateien in S3.

Wenn ein Ingenieur eine Datenbank in Snowflake „klont“ oder einen Zweig in Dremio Arctic erstellt, dupliziert das System die 10 TB nicht. Es dupliziert die Metadaten (Kilobyte) und verweist sie auf dieselben zugrunde liegenden Speicherblöcke.

Die Mechanismen der Isolation: Zero-Copy verlässt sich stark auf Snapshot Isolation.

1. Die Manifestliste verweist auf einen bestimmten „Snapshot“ (z. B. Snapshot S1).
2. Snapshot S1 zeigt auf eine Reihe von Manifestdateien.
3. Manifestdateien verweisen auf die tatsächlichen Datendateien (Parkett).

Wenn ein KI-Modell um 10:00 Uhr mit dem Training beginnt, greift es auf Snapshot S1 zurück. Wenn ein ETL-Job die Tabelle um 10:05 Uhr aktualisiert, erstellt er Snapshot S2 (schreibt neue Parquet-Dateien und ein neues Manifest). Das KI-Modell liest S1 ungestört weiter. Es gibt keine Sperren und keine Leser, die Autoren blockieren.

Abfrage-Pushdown-Optimierung: Die Analyse-Engine überträgt Filter an die Quelldatenbank. Wenn die Abfrage nach SELECT * WHERE region = 'Western-Region' fragt, verwendet das Quellsystem die Metadaten, um zu identifizieren, welche spezifischen Mikropartitionen Daten der „Westlichen Region“ enthalten. Es werden nur diese spezifischen Blöcke zurückgegeben. Dadurch wird die Netzwerkübertragung im Vergleich zu einem vollständigen Tabellenscan effektiv um Größenordnungen reduziert.

Das „Unistore“-Konzept

Das ultimative Ziel von Zero-Copy ist die Vereinheitlichung transaktionaler (OLTP) und analytischer (OLAP) Workloads, ein Konzept, das oft als HTAP (Hybrid Transactional/Analytical Processing) bezeichnet wird.

Die Unistore-Paradigmen von Snowflake und das Lakehouse-Paradigma von Databricks zielen darauf ab, diese Lücke zu schließen. Stellen Sie sich eine Einzelhandelsanwendung vor, bei der ein Kauf in einen Transaktionsreihenspeicher geschrieben wird. In einer herkömmlichen Welt würde diese Zeile erst beim nächtlichen Batch-Job im Analytics Warehouse erscheinen. In einer Zero-Copy-Unistore-Welt ist diese Zeile über eine einheitliche Tabellenabstraktion sofort für die Analyse-Engine sichtbar.

Für die KI ist dies bahnbrechend. Empfehlungssysteme können auf den Klick eines Benutzers innerhalb derselben Sitzung reagieren, nicht erst am nächsten Tag.

Die Realität 2026: „Lebende Ökosysteme“

Bei diesem architektonischen Wandel geht es nicht nur darum, Speicherplatz zu sparen. Es geht um organisatorische Agilität.

Slaloms Financial Services Outlook 2026 prognostiziert einen Wandel von „statischen, isolierten Lösungen“ hin zu „lebenden, adaptiven Ökosystemen“, in denen Daten frei fließen. Als Voraussetzung dafür identifizieren sie Unified Data Foundations. Wenn die Betrugserkennungs-KI einer Bank auf einen nächtlichen Batch-Job warten muss, ist sie gegen Echtzeit-Bedrohungen im Jahr 2026 nutzlos. Der Bericht betont, dass „Governance sowohl Geschwindigkeit als auch Vertrauen ermöglicht“, was darauf hindeutet, dass die Metadatenschicht zur neuen Kontrollebene werden wird.

McKinsey’s Tech Trends unterstreichen dies und verdeutlichen, dass die „Ausführungslücke“ in der KI größtenteils ein Problem der Datenverfügbarkeit ist. Ihre Analyse legt nahe, dass Unternehmen, die in der Lage sind, auf Erkenntnisse in Echtzeit zu reagieren, 1,6-mal wahrscheinlicher ein zweistelliges Wachstum verzeichnen. Die Möglichkeit, Daten „vor Ort“ abzufragen, ermöglicht die Erstellung von Datenprodukten, die von anderen Teams sofort genutzt werden können, ohne den Aufwand, neue Pipelines einzurichten.

Der Aufstieg der „kopflosen“ Datenarchitektur

Im Laufe des Jahres 2026 erwarten Analysten die Dominanz von „Headless“-Datenarchitekturen. In diesem Modell sind der Speicher und die semantische Schicht vollständig vom Konsumtool entkoppelt.

• Speicher: S3/Azure Blob (günstig, unbegrenzt).
• Format: Iceberg/Delta (Offen, Transaktional).
• Katalog: Nessie/Unity-Katalog (Das „Gehirn“, das Zeiger verfolgt).
• Compute: Was auch immer der Benutzer will. Der Data Scientist verwendet PySpark; der Analyst verwendet SQL; Der CEO nutzt ein Dashboard. Sie treffen alle auf dieselbe einzige Quelle der Wahrheit.

Fazit: Die Plattform ist die Pipeline

Für den Dateningenieur verändern sich die Fähigkeiten. Das Schreiben effizienter PySpark-ETL-Skripte zum Verschieben von Daten von A nach B wird immer weniger wertvoll als das Entwerfen robuster Metadaten-Governance-Strategien. Der Wert liegt nicht im Verschieben von Daten; Es geht darum, Daten zugänglich zu machen, ohne sie zu verschieben.

Die Pipeline ist im herkömmlichen Sinne tot. Es lebe die Plattform.

Quellen (5)

• engineering.salesforce.com Zero Copy Revolutionizes Data Cloud
• slalom.com Financial Services Outlook 2026
• dataversity.net Data Management Trends 2026
• mckinsey.com Top Trends in Tech 2025
• arcadia.io Zero-Copy Data Lake