Ente gut, alles gut

von Martin Loschwitz

DuckDB kommt als Datenbank für Analyseprozesse daher, läuft im Gegensatz zu anderen OLAP-Datenbanken aber nicht als eigenständiger Prozess. Stattdessen ist sie direkt in die Anwendung integriert. Damit erübrigt sich nicht nur der übliche Aufwand für den Betrieb einer Database, sondern DuckDB kann auch wieselflink direkt auf den Clients arbeiten und so für flottes Rechnen sorgen. Was bei der Datenente unter der Haube steckt und welche Anwendungsfälle davon bestmöglich profitieren, verrät dieser Artikel.

Hören Admins das Wort Datenbank, denken die allermeisten vermutlich zunächst an relationale Systeme und dann in der Mehrzahl der Fälle entweder an MySQL oder an Oracle. Das ist kein Zufall, denn insbesondere MySQL ist weltweit millionenfach im Einsatz und hält von einfachen Websites mit WordPress bis hin zu großen Umgebungen im Enterprise-Umfeld die Welt ein Stück weit am Laufen. Dass die Welt eben nicht nur aus MySQL besteht, zeigen andere Ansätze wie PostgreSQL oder die besonders in jüngster Zeit verstärkt aufkommenden Zeitreihendatenbanken.

Die Krux an praktisch allen klassischen Ansätzen ist, dass sie als eigenständiger Prozess daherkommen, der spezifische Anforderungen an den eigenen Betrieb stellt. Wer schon einmal versucht hat, MySQL hochverfügbar zu betreiben, weiß, was gemeint ist. Und wer schon mal untersuchen durfte, warum die Kommunikation zwischen Datenbank und Client lahmt, weiß ebenfalls ein Liedchen von den Schwierigkeiten zu singen, die mit klassischen RDBMS verbunden sind.

Anwendung integriert Datenbank

Insbesondere in Setups, in denen konkurrierender Zugriff durch eine beliebige Anzahl von Clients nicht nötig ist, sind deshalb schon seit mehr als 20 Jahren Alternativen zu klassischen Datenbanken gefragt. Dabei geht es meist um Anwendungen, die nur intern Informationen in Datenbankform speichern. Die könnten, so der Tenor, die Database ja einfach gleich mit an Bord haben, statt auf einen externen Prozess zuzugreifen.

Der typische Vertreter dieser Gilde ist SQLite, eine integrierte Datenbank mit SQL-Dialekt, die sich als lokale Alternative zu MySQL & Co. geriert. SQLite ist darauf ausgelegt, so viele klassische SQL-Einsatzbereiche wie möglich abzudecken. Spötter behaupten, SQLite könne entsprechend vieles ganz gut, aber nichts wirklich perfekt. In Sachen Analyse der beheimateten Informationen etwa bietet SQLite keinerlei Features, die es möglich machen, etwaige Anfragen schnell abzuwickeln.

Hypothesengestützte Analyse mittels OLAP

Hier kommt die DuckDB [1] ins Spiel: Die ist, ebenso wie SQLite, eine integrierte Datenbank, braucht also keinen eigenen Prozess. Anders als SQLite richtet sich DuckDB aber nicht generisch an jeden Anwendungsfall, der möglicherweise mal eine Database benötigt. Stattdessen geht es hier explizit um OLAP-Anwendungen. OLAP steht dabei für "Online Analytical Processing"; zusammen mit dem Data-Mining gehört es zu den Methoden der analytischen Informationssysteme.

Was in der Theorie verquast klingt, ist in der Praxis relativ leicht erklärt: Klassische DBMS sind schlicht darauf ausgelegt, die zuvor in ihnen abgelegten Daten auf Kommando wieder auszugeben. In OLAP-Anwendungen hingegen hat der Client, der die Abfrage startet, eine Hypothese, und das Ziel der Abfrage dient dazu, diese Hypothese zu stützen oder zu widerlegen.

Dabei nutzen OLAP-Datenbanken unter der Haube diverse Funktionen zum Kombinieren und Gruppieren von Informationen aus diversen Quellen. Anders als bei der bloßen Abfrage etwa aus einer MySQL-Database leistet ein OLAP-System also nicht nur die Verarbeitung der Anfrage selbst, sondern interpretiert die Daten je nach genutzter SQL-Query entsprechend vor. Der Client erhält auf seine Anfrage also die Antwort, die die Datenbank auf Grundlage der in ihr aus verschiedenen Quellen zusammengetragenen Informationen und unter Nutzung der in ihr implementierten Funktionen geben kann.

OLAP-Datenbanken haben ihren Haupteinsatzzweck heute im Dunstkreis der Business Intelligence. Es geht also darum, aus Daten Trends abzulesen und zu Erkenntnissen zu gelangen, die ohne diese DB-Funktionalität nicht verfügbar wären. Genau darin unterscheidet sich DuckDB insofern auch von SQLite.

Im Arbeitsspeicher beheimatet

In den letzten Jahren hat DuckDB eine erstaunliche Entwicklung hingelegt. In den Rankings verschiedener Analysten rangiert die Datenbank mittlerweile gerade bei den OLAP-Vertretern recht weit oben – nicht zuletzt, weil DuckDB mittlerweile als eine Art Author's Darling gilt, wenn es um das Zusammenfügen und Auswerten vieler Informationen aus verschiedenen Quellen geht (Bild 1). Grund genug, sich das Werkzeug genauer anzuschauen, eine Einordnung zu wagen und zu erläutern, wie der Einstieg in DuckDB sinnvoll gelingen kann.

Wie eingangs erwähnt, ist DuckDB kein klassischer Datenbankdienst, sondern wie SQLite unmittelbar in den sie nutzenden Client integriert. Daraus folgt, dass der Administrator sich um irgendwelche Verbindungen oder dienstspezifischen Details keine Gedanken machen muss. Auch das Thema Hochverfügbarkeit spielt keine Rolle, eben weil die Database nicht als Dienst läuft, der eigenständig ausfallen kann. Geht ein Host down, reißt er sowohl DuckDB als auch die Anwendung mit sich, die darauf zugreift.

Ein zentrales Designelement von DuckDB ist die Tatsache, dass der Dienst vorrangig als In-Memory-Datenbank konzipiert ist. Das Gros des Datensatzes liegt während der Nutzung also im Arbeitsspeicher. Der ist bis heute der schnellste verfügbare Speicher in einem durchschnittlichen Computer. Von Haus aus ist DuckDB daher mit jeder Menge Performance ausgestattet, und zwar ohne dass der Entwickler einer Anwendung dafür etwas Besonderes tun müsste. Auch SQLite lässt sich zwar als In-Memory-Database betreiben. Das aber erzwingt, dass der ausführende Programmierer bestimmte Parameter bei seinen Queries nutzt und auf verschiedene Aspekte der Datenkonsistenz achtgibt. DuckDB hingegen läuft bereits in der Standardkonfiguration weitgehend im Speicher.

Dadurch unterscheidet es sich von anderen Datenbanken aus dem analytischen Kontext, die ebenfalls regelmäßig Business Intelligence und ähnliche Aufgaben dienen. Snowflake oder Redshift mögen manchem Administrator ein Begriff sein. Diese sind aber nicht unmittelbar mit ihren Anwendungen integriert, sondern eigene Dienste, die den gesamten Rattenschwanz administrativer Notwendigkeiten hinter sich herziehen. DuckDB hat in den vergangenen Monaten nicht zuletzt deshalb so viel positive PR abbekommen, weil eine OLAP-Datenbank als eingebettete Option am Markt zuvor schlicht nicht vorhanden war. Das Werkzeug füllt also eine Lücke, und in den Augen vieler Beobachter macht es dies sehr effizient.

Mächtiger CLI-Client

Wer sich mit DuckDB befasst, hat mit einiger Wahrscheinlichkeit seinen Interessenschwerpunkt im Umfeld analytischer Datenbanken. Das ist auch besser so, denn andernfalls sieht sich der Nutzer mit einigen Begriffen aus diesem Umfeld konfrontiert, mit denen er zunächst vermutlich wenig anzufangen weiß. Es schadet also nicht, die grundlegenden Begriffe im Kontext von DuckDB zu klären.

So beschreiben die Entwickler als eine der großen Stärken von DuckDB dessen Fähigkeit, Parquet-Dateien dynamisch zu interpretieren und anschließend per SQL-Kommando auslesbar zu machen. Parquet ist dabei kein Markenname. Stattdessen geht es um das gleichnamige Dateiformat Apache Parquet. Das ist, grob formuliert, eine Art CSV auf Steroiden: Es handelt sich um ein freies und offenes Dateiformat, das spaltenorientiert arbeitet, implizit aber Datenkomprimierung und diverse Codierungsschemata unterstützt.

Seinen Ursprung hat Parquet als Austauschformat für Batch- und interaktive Workloads. Es weist gewisse Ähnlichkeiten mit den Dateiformanten auf, die Hadoop nutzt, das ebenfalls zum Apache-Projekt gehört. Parquet-Dateien können beispielsweise Auszüge aus eigenständigen Datenbanken wie Snowflake sein, die an einem anderen Ort ausgewertet werden und als Grundlage für dortige Analysen dienen sollen. DuckDB greift Entwicklern hier vor allem mit einer umfassenden Parsing-Funktion unter die Arme: Wer bisher etwa im Kontext einer Serveranwendung Inhalte aus Parquet-Dateien auslesen wollte, musste sich auf Grundlage bestehender Werkzeuge einen Parser mühsam zusammenbasteln.

Hat die Anwendung eine Anbindung an DuckDB, geht das nun sehr viel leichter: Die Datenbank fungiert auf der Kommandozeile nämlich als Parser für Parquet-Dateien und erlaubt DuckDB-Queries auch über die Inhalte von Parquet-Dateien im Dateisystem. Dazu genügt es, die Datei als Parameter unmittelbar in ein "SELECT"-Statement zu übernehmen wie etwa in "SELECT * FROM 'test.parquet';". Die Ausgabe gleicht dann jener, die der Nutzer auch auf der Kommandozeile erhalten hätte, hätte er die in DuckDB liegenden Daten abgefragt. Schon die Fähigkeit des CLI, beliebige Parquet-Dateien zu parsen und ihre Informationen so leicht zugänglich zu machen, begeistert viele Entwickler.

Ähnliche Funktionen bietet DuckDB aber auch für andere Datenbankinhalte. Die Skriptsprache Python etwa hat in Form von Pandas ein eigenes Framework für die Verwendung von Werkzeugen zur Datenanalyse und -manipulation. Pandas erwartet seine Eingaben im Dataframe-Format, und auch dieses kann DuckDB lesen, um im Anschluss den Zugriff mittels SQL-Syntax zu erlauben. Damit entpuppt die Database sich als echtes Multitalent. Denn anders als Parquet kommt Pandas vorgeblich im wissenschaftlichen Umfeld zum Einsatz und hat mit Business-Analyse nicht viel zu tun. DuckDB passt mithin auch in den akademischen Bereich.

Erste Schritte

Gerade weil die DuckDB keinen eigenen Serverdienst benötigt, ist es denkbar einfach, die Datenbank zu verwenden. Wer etwa auf einem Mac unterwegs ist und dort Homebrew aktiviert hat, führt den Befehl brew install duckdb aus. Danach steht das Kommandozeilenprogramm "duckdb" zur Verfügung und nach dessen Aufruf existiert bereits eine Database. Diese ist zwar noch leer, das lässt sich mit entsprechenden SQL-Kommandos im nächsten Schritt aber leicht ändern. Alternativ ließe sich die neu gestartete Database auch mit einem Schema versorgen, nämlich mittels

So oder so: Wer sich mit SQL etwa von MySQL her etwas auskennt, wird keine größeren Schwierigkeiten haben, sich bezüglich der grundlegenden Funktionen in DuckDB zurechtzufinden. Der Befehl

beispielsweise legt eine Tabelle namens "ducks" an, die zwei Spalten und eine Zeile mit dem Inhalt "3" und "mandarin" hat. Für das Auslesen haben die Entwickler sich im Anschluss sogar eine Abkürzung überlegt: Wo in MySQL SELECT * FROM ducks; nötig wäre, genügt in DuckDB ein simples FROM ducks;.

Wichtig: Wer die Umgebung in diesem Modus nutzt, legt eine Database an, die ausschließlich im Speicher existiert. Das ist gerade in vielen Prozessen aus dem Business-Umfeld durchaus gewollt, etwa dort, wo Inhalte aus mehreren Datenbanken für eine einmalige Analyse zusammengezogen und das Ergebnis hinterher anderweitig verarbeitet wird.

Wer möchte, dass DuckDB die Datenbank speichert, startet diese stattdessen mittels duckdb datenbank.db und findet die Inhalte in "datenbank.db". DuckDB versucht trotzdem, den gesamten Inhalt während der Laufzeit im Speicher vorzuhalten, um schnelle Queries zu ermöglichen.

Wirklich interessant sind aber eher die Analysefähigkeiten von DuckDB, und hierfür steuern die Macher des Projekts einige beeindruckende Beispiele bei. Mittels der Befehle INSTALL httpfs; und LOAD httpfs; laden Sie für das Beispiel zunächst das DuckDB-Modul nach, das Daten aus S3-Buckets auslesen kann. SET s3_region='us-east-1'; definiert danach die AWS-Region, in der DuckDB im Rahmen der nun folgenden Befehle nach Buckets und Dateien sucht. Das Kommando

lädt im nächsten Schritt eine Parquet-Datei mit statischen Daten von Netflix herunter (Bild 2) und legt diese in einer Datenbank namens "netflix" an. Dann lässt sich eine erste Analyse-Query absetzen:

Diese Befehlsfolge fragt ab, welche Sendungen des Anbieters des Typs "Movie" die meisten Tage in den Top 10 der Wiedergabestatistik zu finden waren – freilich innerhalb der Grenzen des zur Verfügung gestellten Datensatzes (Bild 3). Mit einer "COPY ()"-Funktion um das gesamte "SELECT"-Statement herum und einem TO 'output.csv' (HEADER, DELIMITER ','); dahinter ließe sich die gesamte Ausgabe von der Kommandozeile auch in eine CSV-Datei ausgeben. Und freilich ließen sich mit einer leichten Abwandlung der Kommandos auch Tabellen erstellen, die Daten aus mehreren Quellen korrelieren. Analysefunktionen wie "max", die hier exemplarisch zum Einsatz kommt, sind der Hauptgrund für Entwickler, DuckDB genauer unter die Lupe zu nehmen.

Erweiterungen nutzen

Fernab vom ohnehin schon vorhandenen Funktionsumfang ist beeindruckend, dass die DuckDB-Macher ihrem Dienst auch noch eine Schnittstelle für Erweiterungen spendiert haben. SELECT * FROM duckdb_extensions(); zeigt alle verfügbaren Erweiterungen an (Bild 4). Das Nachladen einzelner Erweiterungen passiert dann analog zum obigen Beispiel mit "httpfs". Dieses unterstützt neben HTTP und HTTPS auch native Abfragen aus S3-Bucket, ganz gleich, ob diese im offiziellen S3 vorliegen oder lokal.

Die Anzahl der verfügbaren Erweiterungen versteht zu beeindrucken. Es existiert in Form von "aws" etwa ein Plug-in, das im Hintergrund auf das AWS-SDK zugreift und den größten Teil von dessen Datenbankfunktionen in DuckDB verfügbar macht. "azure" erlaubt es, Blobs aus Azure nativ zu integrieren. Zusätzliche Formate wie Apache Iceberg, ein anderes Format für Analysetabellen, sind ebenfalls mit wenigen Handgriffen aktiviert wie eine Anbindung an MySQL ("mysql_scanner") oder PostgreSQL ("postgres_scanner"), die auf diese Weise ebenfalls Quelle oder Ziel für Analysevorgänge in DuckDB werden können.

Was hier besonders auffällt, ist die erstaunliche Geschwindigkeit, mit der DuckDB insbesondere bei Analysen zur Tat schreitet. Verzögerungen ergeben sich in den allermeisten Fällen daraus, dass DuckDB auf externe Dienste wartet wie etwa Datenquellen. Sobald die Database aber Herrin des Verfahrens ist, scheinen Abläufe wie die Analyse von Informationen in Sekundenbruchteilen erledigt.

Ebenfalls als eine Art Erweiterung von DuckDB dürfen zudem die Integrationen in diverse Skript- und Programmiersprachen gelten, die ebenfalls zur Verfügung stehen. Dass beispielsweise ein "python-duckdb" existiert, wird niemanden wirklich überraschen: Sowohl im Dunstkreis der Business-Analyse als auch im akademischen Umfeld gilt Python schließlich als eine absolute Standardlösung. Ebenso wenig enttäuscht werden etwaige Erwartungen im Hinblick auf ein Go-DuckDB oder eine Integration in R. Darüber hinaus stehen DuckDB-Bindings für C, C++, Java, Node.js, Rust und einige weitere Projekte zur Verfügung. Wer also mit einer der aktuell gängigen Skript- oder Programmiersprachen arbeitet, dem steht mit äußerst hoher Wahrscheinlichkeit auch eine native DuckDB-Integration zur Verfügung.

Zahlreiche Anwendungsfälle

Klar ist bis hierhin so viel: DuckDB ist eine innovative und pfeilschnelle In-Memory-Datenbank, die trotzdem Informationen persistent speichern kann und durch ihre Analysefähigkeiten vor allem im Business-Intelligenz-Umfeld sowie in der analytischen Verarbeitung von Daten für Furore sorgt. Wie aber lässt sich dieser Goldschatz tatsächlich heben und im Kontext einer kommerziellen Anwendung sinnvoll nutzen?

Das Internet hält dazu mehrere Beispiele bereit und zeigt, wie DuckDB sich sinnvoll in Analysewerkzeuge und BI-Frameworks integrieren lässt. Am Anfang steht bei sämtlichen Anwendungsfällen natürlich eine möglichst umfassende Datenquelle für die zu lösende Aufgabe. Gegeben könnte etwa eine Hotelstatistik über alle Übernachtungen in Hotels im Jahre 2023 in Deutschland sein, aufgeteilt in diverse Parameter wie Stadt, Anzahl der übernachtenden Personen, Anzahl der Nächte, Preis pro Nacht, gewählte Hotelkategorie und so weiter. Ferner sei angenommen, dass jene Statistik in Form von Parquet-Dateien vorliegt, auf deren Handhabung sich DuckDB wie beschrieben bestens versteht.

Zerlegen lassen die Daten sich im ersten Schritt dann sinnvoll mittels dbt und DuckDB. dbt ist eine Query-Engine für die Konsolidierung von Datenbankabläufen in SQL-Dialekten, die sich mittels dbt-duckdb nativ an DuckDB ankoppeln lässt. Der Autor einer etwaigen Software schreibt seine Queries und die gewünschten Datentransformationen mithin gar nicht direkt in DuckDB, sondern direkt in dbt-Syntax, und dbt-duckdb kümmert sich im nächsten Schritt darum, dass die Informationen direkt aus DuckDB heraus richtig transformiert in neuen Tabellen landen.

Für die Verarbeitung der Daten lässt sich im nächsten Schritt eine andere Komponente nutzen, nämlich Dagster [3]. Dabei handelt es sich um ein komplettes CI/CD-Framework, das Pipelines im Handling von Datensätzen erstellen kann und mittels eines eigenen Python-Moduls – dagster-duckdb – ebenfalls nativ mit DuckDB verbunden ist. In Dagster lassen sich also die eigentlichen Programme schreiben, die mit den transformierten Informationen aus DuckDB im Anschluss arbeiten, etwa um daraus wie im Beispiel Vorhersagen über das künftige Buchungsverhalten zu treffen.

Mittels Plotly Dash lassen diese Daten sich dann auch noch visualisieren. Denkbar ist natürlich ebenso, die Informationen durch mehrere Prozesse in Dagster zu schicken, sie danach erneut zu transformieren und sie in DuckDB zurückzuschreiben, damit andere Werkzeuge von ihnen profitieren. Gerade weil die Datenbank so vielseitig verwendbar und verbindbar ist, wird aus der eigentlich kleinen In-Memory-Database im Kontext großer Informationsmengen schnell ein Data-Powerhouse.

Dabei fällt zusätzlich auf, dass DuckDB selbst dann nicht zu stottern anfängt, wenn bereits gigabyteweise Daten darin liegen. Problematisch wird es erst, wenn der Maschine, die die Database beheimatet, der Arbeitsspeicher ausgeht. Entsprechend empfiehlt es sich, bei der Dimensionierung von DuckDB-Setups etwa in AWS oder Azure nicht unbedingt die kleinsten zur Verfügung stehenden Instanzen zu nutzen.

Auch in Kubernetes lässt DuckDB sich übrigens hervorragend nutzen, eine native Umsetzung etwa im Tandem mit Apache Airflow steht beispielsweise produktionsreif zur Verfügung. Etwaige Anforderungen an die verfügbare Hardware gelten aber freilich auch hier.

Fazit

DuckDB dürfte vielen IT-Profis, die mit Datenbanken zu tun haben, bis heute kein Begriff sein, was wirklich erstaunlich ist. Denn wer es gewohnt ist, eine MySQL-Query abzusetzen und danach erst einmal eine Tasse Kaffee zu trinken, weil die Database so langsam ist, der wird seine Rituale erheblich ändern müssen: DuckDB ist wieselflink, und wo klassische Standalone-Dienste wie MySQL rödeln, um Daten auch nur ans Tageslicht zu befördern, hat DuckDB in derselben Zeit nicht nur die Informationen geliefert, sondern sie gleich noch nach Vorgabe des jeweiligen Anwendungsentwicklers umfassend ausgewertet.

Obendrein ist DuckDB extrem gut in diverse Frameworks und andere Werkzeuge aus dem BI-Kontext integriert. Wer sich also nicht scheut, die Kontrolle über die eigenen Daten nicht einer klassischen Datenbank wie MySQL anzuvertrauen, sondern seine Anwendungen so umbaut, dass sie mit DuckDB und dessen Art der Datenhaltung gut zurechtkommen, wird mit einem Feuerwerk der Performance belohnt. Jeder, der sich mit der kommerziellen oder wissenschaftlichen Analyse von Informationen befasst, sollte jedenfalls ein Auge auf die Database werfen.

DuckDB als In-App-Datenbank mit OLAP-Fokus

Ente gut, alles gut

Anwendung integriert Datenbank

Anwendung integriert Datenbank

Hypothesengestützte Analyse mittels OLAP

Im Arbeitsspeicher beheimatet

Mächtiger CLI-Client

Erste Schritte

Erweiterungen nutzen

Zahlreiche Anwendungsfälle

Fazit