Ibis: Die richtige Execution-Engine wählen, ohne Logik neu zu schreiben

Ibis: Die richtige Ausführungs-Engine wählen, ohne Logik neu zu schreiben

In unseren bisherigen Benchmarks hat DuckDB bei großen analytischen Workloads Polars und Pandas durchgängig übertroffen. Doch reine Performancevergleiche übersehen eine entscheidende Frage: Was passiert, wenn Sie von lokaler DuckDB-Entwicklung in eine BigQuery-Produktionsumgebung wechseln müssen oder eine komplette Datenplattform von Spark zu Snowflake migrieren? Transformationslogik neu zu schreiben, nur weil sich die Infrastruktur ändert, ist teuer – und vermeidbar.

Moderne analytische Engines sind äußerst leistungsfähig. Sobald jedoch mehrere Tools sich in der Praxis als „schnell genug“ erweisen, verschiebt sich die eigentliche technische Herausforderung von reiner Geschwindigkeit hin zu Flexibilität. Datenteams prototypisieren lokal, deployen in Cloud-Warehouses und migrieren später Plattformen aus Kosten-, Skalierungs- oder Betriebsgründen. Ist analytische Logik eng an eine bestimmte Engine gekoppelt, verschlingen solche Übergänge Hunderte von Engineering-Stunden – selbst dann, wenn die zugrunde liegende Berechnung konzeptionell identisch bleibt.

Dieser Artikel zeigt, wie Ibis analytische Intention von der Ausführungs-Engine entkoppelt. So können Teams Transformationslogik einmal schreiben und über verschiedene Backends hinweg ausführen, ohne kostspielige Neuschreibungen. Anstatt ausschließlich über Performance zu konkurrieren, setzt Ibis auf Portabilität, Wartbarkeit und architektonische Anpassungsfähigkeit.

Das Portabilitätsproblem: Wenn Datenbanken nicht dieselbe Sprache sprechen

Data Engineering bewegt sich in zwei dominanten Paradigmen: Python-DataFrames und SQL. Beide leiden unter demselben strukturellen Problem: Jedes Datenbanksystem stellt eigene APIs und eigene SQL-Dialekte bereit. Diese Fragmentierung schafft konkrete Portabilitätshürden.

Solche Unterschiede summieren sich schnell. Ein Team, das mehrere SQL-Pipelines migriert, verbringt möglicherweise Wochen damit, dialektspezifische Abfragen umzuschreiben, Edge Cases zu testen und subtile semantische Unterschiede zu debuggen. Ibis begegnet diesem Problem, indem es eine konsistente Schnittstelle zur Formulierung analytischer Intention bietet und diese automatisch in backend-spezifische Implementierungen übersetzt.

Historischer Kontext

Pandas wurde 2008 für interaktive In-Memory-Analysen von Datensätzen entwickelt, die in den Arbeitsspeicher passen. Mit dem Wachstum analytischer Workloads hin zu Multi-Terabyte-Daten und verteilter Ausführung wurde die enge Kopplung von Pandas-API und eager Execution zunehmend zur Einschränkung.

Ibis wurde entwickelt, um genau dieses Problem zu adressieren, indem analytische Intention von der Ausführungsstrategie getrennt wird – ein Ansatz, der von dplyr und dem R-Ökosystem inspiriert ist, aus dem die DataFrame-Abstraktion ursprünglich stammt.

Warum die Entkopplung von Logik und Ausführung wichtig ist

Ibis basiert auf einem zentralen architektonischen Prinzip: Analytische Intention sollte unabhängig von der Ausführungs-Engine definiert werden. Diese Trennung liefert konkreten technischen und geschäftlichen Mehrwert. Logik, die eng an die Produktionsinfrastruktur gekoppelt ist, lässt sich lokal nur schwer testen. Engineers warten auf CI/CD-Pipelines oder entwickeln gegen teure Cloud-Sandboxes.

Portable Abfragen laufen identisch auf lokalem DuckDB und in produktivem BigQuery. Das ermöglicht schnelle Iteration mit der Sicherheit, dass lokale Ergebnisse dem Produktionsverhalten entsprechen. Gleichzeitig erlaubt portable Abfragelogik Teams, Infrastrukturentscheidungen hinsichtlich Kosten, Performance, Skalierung oder Compliance zu optimieren, ohne analytische Workflows zu unterbrechen – selbst wenn Systeme sich über lokale Rechner, Cloud-Warehouses und verteilte Compute-Plattformen erstrecken.

Ibis: Eine backend-agnostische DataFrame-API

Ibis stellt eine DataFrame-ähnliche API bereit, die unabhängig von einer konkreten Ausführungs-Engine konzipiert ist. Die Syntax ähnelt Pandas, die Operationen werden jedoch nicht eager ausgeführt. Stattdessen baut Ibis eine symbolische Repräsentation der Abfrage auf.

In vielen lokalen Setups nutzt Ibis standardmäßig DuckDB als eingebettetes Backend, was Experimente und Prototyping erleichtert. Dieselbe Abfragelogik kann später mit minimalen Änderungen auf verteilten Systemen oder Cloud-Warehouses ausgeführt werden.

1import ibis
2
3con = ibis.connect("duckdb://")
4t = con.read_csv("data.csv")
5
6expr = (
7    t.filter(t.value > 100)
8     .group_by(t.category)
9     .aggregate(total=t.value.sum())
10)
11
12expr.execute()

Ibis führt Operationen nicht eager aus. Es findet keine Berechnung statt, bis execute() aufgerufen wird. Bis dahin erstellt Ibis lediglich eine symbolische Darstellung der beabsichtigten Transformation.

Ausführungsmodell: Was Ibis tut – und was nicht

Ibis führt Abfragen nicht selbst aus. Es fungiert als Abfrage-Compiler, der DataFrame-Operationen in backend-spezifisches SQL übersetzt und die Ausführung vollständig an die Ziel-Engine delegiert. Query Planning, Optimierung und Ausführung übernimmt das Backend (DuckDB, BigQuery, Spark usw.).

Die Performance von Ibis ist damit effektiv die Performance von DuckDB (oder BigQuery, oder Snowflake). Die Übersetzungsschicht verursacht nur minimalen Overhead. Sobald das SQL generiert ist, hängt die Ausführungsgeschwindigkeit vollständig von den Fähigkeiten des Backends ab.

Nicht alle Backends unterstützen alle Operationen. Ibis pflegt eine Kompatibilitätsmatrix, die zeigt, welche Operationen auf welchen Engines verfügbar sind. In der Praxis werden gängige analytische Operationen (Filter, Aggregationen, Joins, Window Functions) von den meisten großen Backends gut unterstützt.

Portabilität als Kernfeature

Der Wechsel der Ausführungs-Engine erfordert lediglich eine Anpassung der Verbindungs­konfiguration:

1ibis.connect("duckdb://")
2ibis.connect("polars://")
3ibis.connect("pyspark://")
4ibis.connect("bigquery://")

Der Reifegrad der Backends variiert, die Abstraktion bleibt jedoch konsistent. Ein Workflow kann lokal mit DuckDB entwickelt und später ohne Neuschreiben der Transformationslogik auf BigQuery oder Spark ausgeführt werden.

SQL-Generierung und Dialektübersetzung

Die meisten Ibis-Backends generieren SQL und nutzen SQLGlot für die Übersetzung zwischen SQL-Dialekten. SQLGlot passt Abfragen an die Syntax der Ziel-Engine an, während die eigentliche Optimierung Aufgabe der Datenbank bleibt.

Zur Transparenz und zum Debugging erlaubt Ibis die Inspektion des generierten SQL:

1print(ibis.to_sql(expr))

DataFrame-Ausdrücke lassen sich bei Bedarf mit rohem SQL kombinieren und bieten so „Escape Hatches“, wenn die Abstraktion für spezielle Anwendungsfälle nicht ausreicht.

Apache Arrow und Interoperabilität

Die Unterstützung mehrerer Backends wäre ohne Apache Arrow deutlich schwieriger. Arrow ist ein standardisiertes In-Memory-Spaltenformat, das einen effizienten Datenaustausch zwischen Engines und Client-Bibliotheken ermöglicht.

Arrow erlaubt Zero-Copy-Konvertierungen, wenn Engines kompatible Speicherlayouts verwenden, etwa DuckDB ↔ Polars oder PyArrow ↔ DuckDB. Daten können zwischen Systemen übergeben werden, ohne serialisiert oder kopiert zu werden, was den Overhead drastisch reduziert.

Konvertierungen nach Pandas erfordern aufgrund des auf NumPy basierenden Speicher­modells oft weiterhin Kopien. Die Pandas-2.x-Serie führte optionale Arrow-basierte Datentypen (pd.ArrowDtype) ein, die Zero-Copy-Interoperabilität ermöglichen, jedoch ein explizites Opt-in erfordern.

Für Endnutzer meist unsichtbar, ist Arrow ein grundlegender Baustein, der es Ibis ermöglicht, Daten effizient zwischen Backends zu bewegen.

Developer Experience

Ibis integriert sich nahtlos in gängige Python-Workflows:

• Tabellen lassen sich mit .to_pandas(), .to_polars() oder .to_pyarrow() konvertieren
• Abfragen sind standardmäßig lazy; .execute() startet die Berechnung
• DataFrame-Ausdrücke lassen sich frei mit rohem SQL über die .sql()-Methode kombinieren
• Python-Testframeworks (pytest, unittest) können analytische Logik lokal validieren

Reifegrad und Ökosystem

Ibis ist ein ausgereiftes, produktions­taugliches Projekt mit Unterstützung durch Voltron Data (das Unternehmen hinter Apache Arrow). Ursprünglich 2015 von Wes McKinney (dem Erfinder von Pandas) geschaffen, wird Ibis seit fast einem Jahrzehnt aktiv weiterentwickelt.

• Unternehmensunterstützung: Voltron Data stellt dedizierte Engineering-Ressourcen
• Community: Aktive Entwicklergemeinschaft, responsive Maintainer, regelmäßige Releases
• Produktionseinsatz: Genutzt u. a. von Bloomberg, RStudio/Posit und verschiedenen Datenteams
• Backend-Support: 20+ Backends mit unterschiedlichem Reifegrad (DuckDB, BigQuery, Snowflake, Postgres, Spark sind gut unterstützt)

Ibis bietet damit produktionsreife Stabilität und ein ausgereiftes Ökosystem und ist eine verlässliche Wahl für Anforderungen an analytische Portabilität.

Fazit

Unsere Benchmarks zeigten, dass DuckDB bei großen analytischen Workloads Polars und Pandas durchgängig übertrifft. Doch Performance allein entscheidet nicht über den architektonischen Erfolg.

Datenteams prototypisieren lokal, deployen in Cloud-Warehouses und migrieren Plattformen aus Kosten-, Skalierungs- oder Betriebsgründen. Ist analytische Logik eng an Ausführungs-Engines gekoppelt, verschlingen diese Übergänge Hunderte von Engineering-Stunden – selbst wenn die zugrunde liegende Berechnung identisch bleibt.

Ibis begegnet diesem Problem durch die Entkopplung analytischer Intention von der Ausführungslogik. Es bietet eine ausgereifte, backend-agnostische DataFrame-API mit Unterstützung durch Voltron Data, mit der Teams Transformationslogik einmal schreiben und über mehr als 20 verschiedene Backends ausführen können – von lokalem DuckDB bis hin zu produktivem BigQuery, Snowflake oder Spark-Clustern.

Ibis ersetzt DuckDB, Polars oder Spark nicht – es erweitert deren Nutzen. Es ermöglicht Engineers zu entscheiden, wann und wo diese Engines laufen. Dieselbe lokal auf DuckDB entwickelte Abfragelogik kann ohne Änderungen nach BigQuery deployt werden. Analytische Anwendungen können mehrere Kundenumgebungen unterstützen, ohne separate Codebasen für jede Plattform pflegen zu müssen.