Zero-ETL mit MotherDuck: Ein technischer Deep Dive

MotherDuck, der auf DuckDB aufbauende Cloud-native Service, verändert grundlegend, wie Unternehmen mit Daten arbeiten, die in Cloud-Object-Stores abgelegt sind. Durch den Wegfall klassischer ETL/ELT-Pipelines ermöglicht MotherDuck direkte SQL-Analysen auf Formaten wie Parquet, JSON und CSV direkt aus Amazon S3, Azure Blob Storage oder Google Cloud Storage, ohne Datenvervielfältigung oder Vorverarbeitung. Dieser Ansatz markiert einen klaren Bruch mit konventionellen Data-Warehouse-Architekturen, in denen Daten vor der Analyse erst kopiert, transformiert und gespeichert werden müssen.

Der Zero-ETL-Ansatz ermöglicht es Organisationen, ihre Daten in ihrem ursprünglichen Format und an ihrem ursprünglichen Ort zu belassen, während analytische Abfragen durchführt werden. Dies eliminiert Datenverdopplung, senkt die Speicherkosten und beseitigt die Latenz, die mit traditionellen ETL-Prozessen verbunden ist. Am wichtigsten ist, dass Datenteams Daten sofort abfragen können, ohne auf Batch-Jobs oder komplexe Pipeline-Orchestrierungen warten zu müssen.

Wie MotherDuck auf Cloud-Daten zugreift

Direkter Dateizugriff

Bei der Ausführung einer Abfrage gegen einen Cloud-Object-Store stellt MotherDuck direkte Verbindungen zum Speicherdienst her und liest ausschließlich die benötigten Datensegmente. Als Beispiel nehmen wir diese Abfrage:

1SELECT customer_id, SUM(order_total) as revenue
2FROM read_parquet('s3://analytics-bucket/orders/*.parquet')
3WHERE order_date >= '2025-01-01'
4GROUP BY customer_id;

MotherDuck kopiert diese Dateien nicht in einen Staging-Bereich oder Zwischenspeicher. Stattdessen nutzt der Service die Table Functions von DuckDB, die native Cloud-Storage-Protokolle unterstützen und direkte Lesezugriffe auf Endpunkte von AWS S3, Azure Blob Storage oder Google Cloud Storage ermöglichen. Persistente HTTP-Verbindungen werden wiederverwendet, um Verbindungsaufwand zu reduzieren und sowohl Latenz als auch Durchsatz zu optimieren. Die Authentifizierung erfolgt über IAM-Rollen, Access Keys oder andere Cloud-native Sicherheitsmechanismen.

Format-Native Processing

Bei Parquet-Dateien nutzt MotherDuck die Struktur des spaltenorientierten Formats, um die Datenübertragung zu minimieren. Bei der Abfrage einer 10 GB großen Parquet-Datei mit 50 Spalten, bei der nur drei Spalten ausgewählt werden, liest MotherDuck nur diese spezifischen Spalten-Chunks direkt aus dem Speicher. Dieses spaltenweise Lesen geschieht auf der Speicherebene durch HTTP Range Requests, nicht nach dem Herunterladen der gesamten Datei. Eine Abfrage, die drei Spalten aus einem 50-Spalten-Datensatz auswählt, reduziert das Volumen der übertragenen Daten drastisch.

Für JSON-Dateien verwendet MotherDuck Stream-Parsing-Strategien, die eine direkte Abfrage von verschachtelten Strukturen ermöglichen:

1SELECT 
2    json_extract_string(data, '$.user.email') as email,
3    CAST(json_extract(data, '$.purchase.amount') AS DECIMAL(10,2)) as amount
4FROM read_json('s3://logs-bucket/events/*.json')
5WHERE json_extract_string(data, '$.event_type') = 'purchase';

Der JSON-Reader erkennt Typen und Spaltennamen automatisch und optimiert die Konvertierung in Vektoren.

Techniken zur Abfrageoptimierung

MotherDuck verwendet Predicate und Projection Pushdown, um die Abfrageleistung weiter zu verbessern. Beide Techniken werden im Folgenden anhand von Beispielen veranschaulicht.

Predicate Pushdown

Predicate Pushdown stellt eine der wirkungsvollsten Optimierungen in der Execution Engine von MotherDuck dar. Anstatt alle Daten zu lesen und danach zu filtern, verschiebt der Service Filteroperationen so nah wie möglich an die Speicherebene. Als Beispiel betrachten wir dieses Szenario mit Parquet-Dateien:

1SELECT COUNT(*) as premium_sales
2FROM read_parquet('s3://sales-data/year=2024/month=*/day=*/*.parquet')
3WHERE sale_amount > 1000 
4    AND product_category = 'Premium';

MotherDuck setzt dabei mehrere Filterebenen ein. Zunächst werden ganze Verzeichnispfade übersprungen, die nicht zu den Abfrageprädikaten passen. Anschließend nutzt die Engine Parquet-Metadaten, insbesondere Min-/Max-Statistiken und, falls verfügbar, Bloom-Filter, um Zeilengruppen zu überspringen, deren Wertebereiche die Filterbedingungen nicht erfüllen. Schließlich verzögert Late Materialization das Laden nicht benötigter Spalten, bis die Filterung abgeschlossen ist. Diese Optimierungen reduzieren das übertragene Datenvolumen erheblich, insbesondere bei sortierten Daten oder bei Abfragen aktueller Partitionen in Zeitreihen.

Projection Pushdown

Projection Pushdown stellt sicher, dass nur die benötigten Spalten aus dem Speicher gelesen werden. Der Execution Planner von MotherDuck identifiziert alle Spalten, die für die Abfrage erforderlich sind, einschließlich jener, die in Filtern, Joins, Aggregationen oder der finalen Projektion verwendet werden.:

1SELECT customer_name, order_date, total_amount, shipping_address, payment_method
2FROM read_parquet('s3://orders-archive/2024/*.parquet')
3WHERE order_status = 'completed'
4    AND total_amount > 100;

Der Optimierer stellt fest, dass er sechs Spalten lesen muss: die fünf in der SELECT-Klausel plus order_status für die Filterung. Er konfiguriert den Parquet-Reader so, dass nur die relevanten Spalten-Chunks per HTTP-Range-Requests geladen werden. Alle übrigen Spalten werden ignoriert, was Netzwerk-Traffic und Speicherverbrauch deutlich reduziert.

Hybrid Execution: Intelligentes Query Routing

Die hybride Architektur von MotherDuck bestimmt automatisch den optimalen Ausführungsort der Abfrage basierend auf Datenlokalität und Rechenanforderungen. Wenn eine Verbindung von einer lokalen DuckDB-Instanz zu MotherDuck hergestellt wird, leitet die Engine Operationen intelligent weiter:

1SELECT 
2    l.product_id,
3    l.local_price,
4    AVG(c.cloud_price) as avg_cloud_price
5FROM read_csv('local_prices.csv') l
6JOIN read_parquet('s3://pricing-data/historical/*.parquet') c
7  ON l.product_id = c.product_id
8GROUP BY l.product_id, l.local_price;

Die Execution Engine führt S3-Lesezugriffe in der Cloud-Umgebung von MotherDuck durch. Lokale CSV-Operationen werden auf dem Client-Rechner ausgeführt. Die Join-Strategie richtet sich nach den relativen Datengrößen: Kleine lokale Tabellen können zur Verarbeitung in die Cloud verschoben werden, während aggregierte Cloud-Ergebnisse für den finalen Join lokal zusammengeführt werden. Auf diese Weise werden unnötige Datenverschiebungen vermieden, ohne die Abfrageleistung zu beeinträchtigen.

Multi-Format Query Federation

MotherDuck kann Daten über verschiedene Formate und Speicherorte hinweg in einer einzigen Abfrage verknüpfen. Parquet-, JSON- und CSV-Quellen lassen sich nahtlos kombinieren:

1SELECT 
2    p.customer_id,
3    p.purchase_amount,
4    json_extract_string(s.session_data, '$.duration') as session_duration
5FROM read_parquet('s3://purchases/2025/*.parquet') p
6JOIN read_json('s3://sessions/2025/*.json') s
7  ON p.session_id = json_extract_string(s.session_data, '$.session_id')
8WHERE p.purchase_date >= '2025-01-01';

Jedes Format wird mit seinem optimalen Zugriffsmuster verarbeitet, während MotherDuck die effizienteste Join-Strategie basierend auf Datengröße und -verteilung auswählt..

Einschränkungen und Überlegungen

Trotz der Vorteile des Zero-ETL-Ansatzes sollten bestimmte Szenarien sorgfältig bewertet werden. Sehr komplexe Transformationen mit mehreren Windowing- und Aggregationsstufen profitieren häufig von materialisierten Zwischenergebnissen. Echtzeit-Streaming-Anwendungsfälle mit sehr niedriger Latenz erfordern weiterhin spezialisierte Streaming-Infrastrukturen. Zudem können regulatorische Anforderungen, etwa zu Datenresidenz oder Audit-Trails von Transformationen, Grenzen für Zero-ETL-Modelle setzen.

Auch das Dateiformat spielt eine entscheidende Rolle. Parquet bietet durch sein spaltenorientiertes Design und umfangreiche Metadaten das größte Optimierungspotenzial, während JSON-Dateien weniger Metadaten enthalten und daher höhere Scan-Volumina verursachen können.

Unternehmen sollten außerdem die Kosten für Netzwerkbandbreite berücksichtigen, insbesondere bei häufigen Abfragen großer Datensätze über Regionen hinweg. Für stark genutzte, transformierte Datensätze kann eine selektive Materialisierung zusätzlich zum Zero-ETL-Ansatz sinnvoll sein, um Performance und Kosten in Balance zu halten, während Ad-hoc-Abfragen weiterhin direkt auf den Rohdaten ausgeführt werden.

Fazit

Die Zero-ETL-Fähigkeiten von MotherDuck stellen eine interessante Alternative für die Cloud-Datenanalyse-Architektur dar. Indem Cloud-Speicher als direkt abfragbare Datenquelle behandelt werden und Pushdown-Optimierungen integriert sind, verschwimmen die Grenzen zwischen Datenspeicherung und Datenverarbeitung. Durch Predicate Pushdown, Projection Pushdown und hybride Ausführung entsteht ein System, in dem große Datensätze nahezu so zugänglich sind wie lokale Datenbanken.

Für Unternehmen, die ihre Datenarchitektur neu bewerten, bietet MotherDuck eine Alternative zu traditionellen ETL-Pipelines. Die Fähigkeit, Daten direkt dort abzufragen, wo sie sich befinden, in ihrem nativen Format, mit vollen SQL-Fähigkeiten und automatischen Optimierungen, vereinfacht den gesamten Analyse-Stack. Dies bietet eine Möglichkeit, die Datenarchitektur zu überdenken und Analysen unmittelbarer, flexibler und für das gesamte Unternehmen zugänglicher zu machen. Da die Datenmengen weiter wachsen und Echtzeit-Analysen immer wichtiger werden, kann der Zero-ETL-Ansatz helfen, künftige Skalierungsanforderungen ohne die Komplexität klassischer Pipeline-Architekturen zu bewältigen.