Apache DataFusion: Rust-Abfrage-Engine auf Arrow-Basis zum Einbauen

DataFusion als Rust-Bibliothek über dem Arrow-Speicherformat

DataFusion ist eine erweiterbare Abfrage-Engine, geschrieben in Rust, mit Apache Arrow als In-Memory-Format. Das Repository apache/datafusion führt Rust als Hauptsprache, steht unter Apache-2.0 und entwickelt auf dem Branch main. In den Metadaten sind weder Topics noch Releases noch ein Zeitpunkt der letzten Aktivität eingetragen, eine Version lässt sich daraus also nicht ablesen.

Die Zielrichtung ist im README unmissverständlich formuliert. Das Crate stellt Bibliotheken und Binärprogramme bereit, und zwar für Entwickler, die schnelle und funktionsreiche Datenbank- und Analysesysteme bauen, zugeschnitten auf bestimmte Arbeitslasten. DataFusion ist damit kein Datenbankserver, den man installiert und benutzt, sondern ein Unterbau, in den man seine eigenen Entscheidungen einträgt.

Als Einsatzfelder nennt das Material domänenspezifische Abfrage-Engines, neue Datenbankplattformen, Datenpipelines und Abfragesprachen. Die Begründung liegt auf der Hand: Wer eine dieser Sachen baut, verbringt sonst Monate mit Planer, Ausführung und Formatanbindung, bevor die erste eigene Funktion entsteht.

Query-Planner, Vektorisierung und partitionierte Datenquellen

Zum Lieferumfang gehören nach Angabe des README ein vollständiger Abfrageplaner und eine spaltenorientierte Ausführung, die gleichzeitig Streaming, mehrere Threads und Vektorisierung beherrscht. Dazu kommen partitionierte Datenquellen, sodass ein Auftrag auf mehreren Datenbereichen parallel arbeiten kann, statt sie nacheinander zu lesen.

Anpassbar ist die Engine an fast allen Stellen. Genannt werden zusätzliche Datenquellen, weitere Abfragesprachen, eigene Funktionen und benutzerdefinierte Operatoren. Diese Liste ist der eigentliche Kern des Angebots: Ein System, das überall erweiterbar ist, erlaubt es, die Teile zu ersetzen, die für den eigenen Zweck nicht passen, ohne den Rest neu zu schreiben.

Ab Werk mitgeliefert werden SQL- und DataFrame-APIs sowie Unterstützung für CSV, Parquet, JSON und Avro. Für die praktische Arbeit heißt das, dass ein Prototyp ohne eigenen Formatcode entsteht und die Anpassung erst dort beginnt, wo sie gebraucht wird.

nested_expressions, crypto_expressions und parquet_encryption in Cargo.toml

Der Funktionsumfang wird über Cargo-Features gesteuert, die in der eigenen Cargo.toml gesetzt werden. Diese Stelle entscheidet mit darüber, wie groß das Ergebnis wird und was es kann, deshalb lohnt ein genauer Blick auf den Standardsatz.

Voreingestellt sind unter anderem nested_expressions für Funktionen auf verschachtelten Typen wie array_to_string, compression zum Lesen von Dateien, die mit xz2, bzip2, flate2 oder zstd gepackt sind, crypto_expressions für md5 und sha256, datetime_expressions für Funktionen wie to_timestamp, encoding_expressions für encode und decode, parquet für das Parquet-Format und sql für das Parsen und Planen von SQL. Hinzu kommen regex_expressions mit regexp_match, unicode_expressions mit character_length, unparser, um logische Pläne zurück in SQL zu übersetzen, sowie recursive_protection als Schutz gegen Stapelüberlauf über die Crate recursive.

Nicht im Standardsatz, aber zuschaltbar sind avro für das Avro-Format, backtrace für erweiterte Fehlermeldungen, parquet_encryption für die modulare Parquet-Verschlüsselung und serde, um die serde-Fähigkeit von arrow-schema zu aktivieren. Wer verschlüsselte Parquet-Daten lesen muss, kommt an parquet_encryption nicht vorbei.

Python, Java, Comet und Ballista: vier Unterprojekte im Umfeld

Das README grenzt das Crate gegen vier verwandte Vorhaben ab, die sich an Endnutzer statt an Bibliotheksnutzer richten. DataFusion Python bietet eine Python-Schnittstelle für SQL- und DataFrame-Abfragen, DataFusion Java dasselbe für Java. Beide sind der Weg, wenn die eigene Anwendung nicht in Rust geschrieben ist.

Die beiden anderen verfolgen ein anderes Ziel. DataFusion Comet ist ein Beschleuniger für Apache Spark auf DataFusion-Basis, gedacht also für Bestandslandschaften, die Spark behalten wollen. DataFusion Ballista ist eine verteilte Ausführungs-Engine, die DataFusion über einen Cluster von Knoten skaliert.

Für die Auswahl ist diese Abgrenzung hilfreich. Wer eine existierende Spark-Umgebung beschleunigen will, landet bei Comet. Wer über die Grenzen einer Maschine hinaus muss, bei Ballista. Wer eine eigene Engine baut, bleibt beim Crate selbst. Das README verlinkt eine Seite mit Anwendungsfällen, zählt aber selbst keine auf.

Deprecation-Richtlinie, Cargo.lock und Dependabot im CI

Zur Stabilität der Schnittstelle äußert sich das README mit einer Einschränkung, die man kennen sollte. Öffentliche Methoden entwickeln sich im Lauf der Zeit weiter. Das Projekt bemühe sich um eine stabile API, verbessere sie aber eben auch; in der Regel würden Methoden zuerst als veraltet markiert und danach entfernt, nach den auf einer verlinkten Seite festgehaltenen Richtlinien.

Das ist ehrlicher als ein Stabilitätsversprechen, bedeutet für Anwender aber Arbeit: Wer DataFusion als Abhängigkeit trägt, sollte Veraltungshinweise des Compilers nicht übergehen, weil die Methode danach verschwindet.

Zum Umgang mit Abhängigkeiten nennt das Material zwei Handgriffe. Das Projekt legt seine Cargo.lock im Repository ab und folgt damit der Rust-Empfehlung, Lockdateien mitzuführen. Die Continuous Integration arbeitet mit dieser eingecheckten Datei, und Abhängigkeiten werden regelmäßig über Pull-Requests von Dependabot nachgezogen. Für eigene Forks heißt das, dass sich der Abhängigkeitsstand nachvollziehen lässt.

Die Leistungsbehauptung und der Verweis auf benchmark.clickhouse.com

An einer Stelle wird das README sehr viel vager, als der erste Eindruck erwarten lässt. Die Formulierung zur Leistung ist als Verweis ausgeführt und zeigt auf eine fremde Vergleichsseite unter benchmark.clickhouse.com. Eigene Zahlen nennt das Material nicht, weder Durchsatz noch Latenz noch Vergleichswerte.

Diese Zurückhaltung ist im Ergebnis die richtige Entscheidung und trotzdem eine Lücke. Wer DataFusion gegen ein anderes System abwägen will, findet im Repository keine Messung, die auf die eigene Arbeitslast passt. Die Bewertung muss deshalb am eigenen Datenbestand stattfinden, und die Beispiele im Verzeichnis datafusion-examples sind dafür der naheliegende Anfang.

Ähnlich verhält es sich mit der Liste bekannter Anwender. Das README verlinkt sie auf der Projektseite, führt aber keine Namen auf. Eine Aussage über Verbreitung oder Produktionsreife lässt sich daraus nicht ableiten.

Wann DataFusion die falsche Wahl ist und was Ballista anders macht

Der häufigste Fehlgriff dürfte eine falsche Erwartung an den Lieferumfang sein. DataFusion bringt keine fertige Datenbank mit, sondern Bibliotheken und Entwicklerwerkzeuge. Wer einen Server sucht, der nach der Installation Abfragen annimmt, bekommt hier Bausteine und muss Netzschicht, Benutzerverwaltung und Betrieb selbst ergänzen. Das Material nennt ausdrücklich Entwickler als Zielgruppe.

Die nächstliegende Alternative innerhalb des eigenen Umfelds ist Ballista. Der Unterschied ist klar benannt: Ballista skaliert DataFusion über einen Cluster von Knoten, während das Crate selbst auf der Maschine arbeitet, auf der es läuft. Wer die Grenzen eines einzelnen Rechners nicht erreicht, braucht die zusätzlichen Prozesse nicht. Wer sie erreicht, findet im selben Projektverbund den nächsten Schritt.

Daneben bleibt der Verzicht auf eine Abfrage-Engine überhaupt. Liegen die Daten in wenigen Parquet-Dateien und genügt ein fester Auswertungsschritt, ist ein direktes Lesen über die Arrow-Bibliotheken der kürzere Weg. DataFusion rechtfertigt sich erst, wenn Abfragen in wechselnder Form kommen oder wenn das System fremde Abfragen annehmen soll.

Redaktionelles Fazit

DataFusion passt zu Entwicklerteams, die eine eigene Abfrage-Engine, Datenplattform oder Pipeline bauen und dafür einen funktionierenden Unterbau statt eines leeren Blatts suchen, mit SQL, DataFrame-API und Anpassbarkeit an fast jeder Stelle. Es passt nicht für jemanden, der eine fertige Datenbank mit Server, Benutzerverwaltung und Betriebshandbuch sucht, denn das Crate liefert ausdrücklich Bibliotheken und Entwicklerwerkzeuge. Vor dem Einstieg sollte die eigene Abfrage gegen die Beispiele unter datafusion-examples im Repository laufen und die benötigten Formate über die Cargo-Features bewusst ausgewählt werden, weil avro und parquet_encryption nicht im Standardsatz enthalten sind.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository