650 GB Daten (Delta Lake auf S3): Polars vs. DuckDB vs. Daft vs. Spark

 (dataengineeringcentral.substack.com)
8 Punkte von GN⁺ 2025-11-16 | 1 Kommentare | Auf WhatsApp teilen
  • Delta-Lake-Daten im Umfang von 650 GB auf S3 gespeichert und ein Performance-Vergleich durchgeführt, wie diese in einer Single-Node-Umgebung mit Polars, DuckDB, Daft und Spark verarbeitet werden
  • Auf einer EC2-Instanz mit 32 GB Speicher wurde geprüft, ob die einzelnen Engines große Datenmengen verarbeiten können, und im Vergleich zu clusterbasiertem Spark das Potenzial eines Single Nodes untersucht
  • DuckDB benötigte 16 Minuten, Polars 12 Minuten, Daft 50 Minuten und PySpark mehr als eine Stunde, was zeigt, dass praktische Verarbeitung auch auf einem Single Node möglich ist
  • Polars unterstützt keine Deletion Vectors, nur DuckDB unterstützt diese Funktion, wodurch es Unterschiede bei der Lake-House-Kompatibilität gibt
  • Insgesamt zeigt das Ergebnis, dass Single-Node-Frameworks auch auf kostengünstiger Hardware große Datenmengen verarbeiten können, und regt dazu an, die Abhängigkeit von Distributed Computing neu zu bewerten

Cluster-Müdigkeit und die Single-Node-Alternative

  • Mit den steigenden Kosten und der Komplexität des Betriebs von SaaS-basierten Lake-House-Clustern wird das Phänomen der „Cluster-Müdigkeit“ (cluster fatigue) erwähnt
  • Früher wurde Spark genutzt, weil es außer Pandas kaum Alternativen gab; mit dem Aufkommen von DuckDB, Polars und Daft (D.P.D.) haben sich die Möglichkeiten für Single-Node-Verarbeitung erweitert
  • D.P.D. kann größer-als-Arbeitsspeicher-(LTM)-Datensätze verarbeiten und ermöglicht schnelle Berechnungen
  • Der Artikel stellt verteilte und nicht verteilte Ansätze als zwei Optionen gegenüber und betont das Konzept der „Single Node Rebellion“

Aufbau der Testumgebung

  • Eine Delta-Lake-Tabelle auf S3 erstellt und rund 650 GB Daten gespeichert (Ziel waren 1 TB, wurde aber abgebrochen)
  • Auf einer EC2-Instanz (32 GB RAM, 16 CPU) wurden DuckDB, Polars und Daft ausgeführt und anschließend mit Spark verglichen
  • Die Daten bestanden aus simulierten Social-Media-Posts; Python-dicts wurden erzeugt, in einen Daft DataFrame umgewandelt und als Parquet-Dateien gespeichert
  • Anschließend wurden die Parquet-Dateien in Databricks in eine Delta-Lake-Tabelle umgewandelt und nach Jahr und Monat partitioniert
  • Ohne das Delta-Log wurden etwa 650 GB Daten bestätigt

Speichergrenzen und die Notwendigkeit von Streaming

  • Da auf einem Single Node mit 32 GB Speicher 650 GB Daten verarbeitet werden mussten, wurde die Notwendigkeit einer Streaming-basierten Ausführung von Abfragen hervorgehoben
  • Unter Verweis auf ein Polars-GitHub-Issue wird ein Beispiel erwähnt, in dem Streaming-Schreibfunktionen für Iceberg gefordert werden
  • Es wird betont, dass neue Frameworks wie Polars und DuckDB grundlegende Unterstützung dafür brauchen, Lake-House-Formate per Streaming zu lesen und zu schreiben

Testergebnisse nach Engine

  • DuckDB
    • Einzige Engine mit Unterstützung für Deletion Vectors
    • Verarbeitete 650 GB Daten auf einer Linux-Maschine mit 32 GB in nur 16 Minuten erfolgreich
    • Der Code war einfach und die Ergebnisdatei wurde korrekt erzeugt
  • Polars
    • Wegen fehlender Unterstützung für Deletion Vectors in Lake-House-Umgebungen eingeschränkt
    • Die Lazy API (Scan/Sink) muss verwendet werden
    • Verarbeitung in nur 12 Minuten, also schneller als DuckDB
  • Daft
    • Rust-basiert, gute Nutzungserfahrung, aber mit 50 Minuten Verarbeitungszeit am langsamsten
    • Bei Iceberg-bezogenen Arbeiten wurde ein stabiler Betrieb bestätigt
  • PySpark (Databricks Single Node)
    • Mehr als eine Stunde Laufzeit, ohne Tuning ausgeführt
    • Im Vergleich zu Single-Node-Engines weniger effizient
    • Ziel des Experiments war weniger Geschwindigkeit als vielmehr die Überprüfung der Realisierbarkeit eines Single Nodes

Fazit und Implikationen

  • Das Experiment zeigt, dass Single-Node-Frameworks große Lake-House-Datenmengen verarbeiten können
  • Selbst auf kostengünstiger Hardware sind vernünftige Laufzeiten und eine einfache Code-Struktur möglich
  • DuckDB, Polars und Daft liefern alle praktikable Leistung auch ohne verteilten Cluster
  • Es zeigt, dass Distributed Computing nicht die einzige Lösung ist, und legt eine Neubewertung moderner Lake-House-Architekturen nahe
  • Das Konzept der „Single Node Rebellion“ hebt das Potenzial eines kosteneffizienten Data-Engineering-Ansatzes hervor

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-11-16
Hacker-News-Kommentar
  • Ich bin Softwareingenieur bei Eventual und wollte mich dafür bedanken, dass ihr Benchmarks für Daft geteilt habt, das von unserem Team entwickelt wird
    Daft ist eine leistungsstarke Datenverarbeitungs-Engine für AI-Workloads und läuft sowohl auf einem einzelnen Knoten als auch in verteilten Umgebungen
    Durch diesen Benchmark haben wir viele Möglichkeiten entdeckt, Parallelität und Pipelining zu verbessern. Besonders beim deltalake-Reader und beim groupby-Operator gibt es noch viel zu optimieren
    Wir planen, diese Verbesserungen in künftige Releases einfließen zu lassen; mehr dazu findet ihr auf GitHub, Twitter und LinkedIn
    Wenn euch Daft interessiert, könnt ihr es mit pip install daft selbst ausprobieren
    • Mich würde interessieren, ob ihr plant, Daft als Backend für ibis bereitzustellen. Das wäre praktisch, um sanft von anderen Engines zu wechseln und Tests durchzuführen
    • Das sieht wie ein Account aus, der für Firmenwerbung erstellt wurde
  • Awk? Dazu gibt es einen interessanten Artikel — Command-line tools can be 235x faster than your Hadoop cluster
  • 650 GB, das sind so wenig Daten, dass sie sogar auf mein Handy passen würden
    Statt übertriebenem Tooling sollte man einfach GNU-Tools verwenden
    Zur Referenz, ein älterer, aber immer noch interessanter Beitrag — command-line tools can be 235x faster than your Hadoop cluster
    • Inzwischen ist es allerdings nicht mehr die Hadoop-Ära von 2014, um die es in dem Artikel ging
      Wenn man 650 GB JSON-Daten mit CLI-Tools aggregiert, wird es schwer, an die Parallelisierungsleistung von DuckDB oder ClickHouse heranzukommen. Ich habe es auch mit GNU Parallel versucht, aber das hatte Grenzen
    • Bei 650 TB wäre die Situation natürlich völlig anders. Der Artikel ist letztlich nur ein Mikrobenchmark
      In der Praxis braucht man dann einen Datenkatalog und clusterbasierte Verarbeitung
    • Zusammen mit dem Witz „Ich habe vergessen, wie man so kleine Zahlen zählt“ wurde dieses Video geteilt
  • Ich verarbeite auf einem einzelnen Knoten oft „biggish data“ mit DuckDB
    Statt Delta oder Iceberg durchlaufe ich Parquet-Dateien direkt und frage sie ab
    Ich lade Abfrageergebnisse aus BigQuery als lokale Parquet-Dateien herunter (jeweils etwa 1 GB) und analysiere sie mit DuckDB. Die Daten sind deutlich größer als der RAM, aber es funktioniert gut
    Ich vergleiche auch die Aggregationsleistung von BigQuery und DuckDB und teile Jobs manchmal zwischen beiden Engines auf. Genau solche Kombinationen machen Data Engineering interessant
    • Bei etwa 650 GB lässt sich das auch auf einem lokalen Dateisystem problemlos verarbeiten. Dafür braucht man keine komplexen Tools
  • Dieser Benchmark wirkt wie ein Experiment, das vollständig von der NIC-Bandbreite dominiert wurde
    Mit den maximal 10 Gbps einer c5.4xlarge-Instanz dauert es mindestens 9 Minuten, 650 GB aus S3 zu lesen
    Schon kleine Unterschiede im I/O-Scheduling dürften das Ergebnis stark beeinflusst haben
    Vielleicht ist es sogar wirtschaftlicher, größere Instanzen zu verwenden und schneller fertig zu sein
    • Es wäre auch interessant, das auf einem normalen Desktop oder einem guten Laptop zu testen
      NVMe-Storage ist viel schneller als S3, und eine lokale CPU mit 8 bis 16 Kernen könnte besser sein als die Cloud
      S3 ist ein großartiges Produkt, kommt aber an die Leistung lokaler Speicher nicht heran
    • Wahrscheinlich hat die reale Abfrage nicht alle Dateien vollständig gescannt, sondern S3-Byte-Range-Reads genutzt und nur einige Spalten verarbeitet
      Die Verteilung der Dateigrößen oder eine Schieflage bei API-Aufrufen waren vermutlich die größeren Variablen
      Der Aussage „Eine größere Instanz könnte am Ende billiger sein“ stimme ich vollkommen zu
    • Der Wert des Experiments ist unklar
      Spark eignet sich für große mehrstufige Datensätze, und wenn S3 als Backend verwendet wird, zeigt sich der Netzwerkengpass unmittelbar in den Kosten
      Die Single-Node-Performance von DuckDB und Polars ist beeindruckend, aber das ist so, als würde man ein Flugzeug auf der Startbahn gegen ein Motorrad antreten lassen
    • 10 Gbps ist viel zu wenig. Bei Google wurden 400-Gbps-NICs und eine verbesserte TCP-Staukontrolle verwendet
      Solche Unterschiede sind auch ein Grund, warum viele von verteiltem Computing genervt sind
    • Ich kann diesen Einwand gut nachvollziehen. Vor 30 Jahren an der Wall Street habe ich eine Lektion gelernt — Bevor man die Systemleistung testet, sollte man zuerst das theoretische Maximum verstehen
      Wenn man die Ressourcenlimits kennt und die reale Leistung als Verhältnis zu diesen Grenzen ausdrückt, wird alles viel klarer
  • Dieser Beitrag ist in zweierlei Hinsicht irreführend dargestellt
    1. Wahrscheinlich wurde tatsächlich Column Pruning angewendet und nur auf 2 Spalten plus Metadaten zugegriffen
    2. Die meiste Zeit dürfte auf S3-I/O entfallen sein, wobei Limits bei gleichzeitigen Verbindungen vermutlich den größeren Einfluss hatten
      Es ist gut, dass verschiedene Systeme ausprobiert wurden, aber ich hätte mir gewünscht, dass Abfragen größer als der Arbeitsspeicher ernsthaft behandelt werden
    • Wichtig ist, dass die Abfrage eine Projektion ist, die nur einen Teil der gesamten 650 GB zurückliefert
      DuckDB ist stark beim Streaming über die Speicherkapazität hinaus, während Polars hier noch unreif ist
      Die Standardeinstellungen von S3 verhindern paralleles Lesen nicht, daher ist am Ende vermutlich die Netzwerkbandbreite der VM der Engpass
  • Ich musste vor Kurzem einige TB an JSON-Daten verarbeiten, und das eigentliche Problem waren die vielen kleinen Dateien von 10 bis 20 MB
    ClickHouse war am schnellsten, DuckDB war in Sachen Einfachheit und Stabilität am besten
    Flink und PySpark waren 3- bis 5-mal langsamer, und auch Dask und Ray waren zu langsam
    Ich würde inzwischen empfehlen, bei den meisten Workloads mit DuckDB oder ClickHouse zu starten. Wenn Pandas zu langsam ist, ersetze ich es standardmäßig durch DuckDB
    • Mich würde interessieren, ob die JSON-Daten zuerst in ein anderes Format umgewandelt wurden oder ob direkt auf JSON gearbeitet wurde
  • Polars ist für die Unterstützung von Delta Lake auf delta-rs angewiesen, und diese Implementierung unterstützt Deletion vectors nicht
    Selbst mit einer Single-Node-Bibliothek kann man etwa 1 TB gut verarbeiten; erst ab mehr als 10 TB sollte man zu Spark wechseln
    Zugehöriges Issue
    • Viele Leute wechseln viel zu schnell zu Spark, nur weil „Spark leicht zu parallelisieren ist“
      Dabei lässt sich vieles mit besseren Tools lösen
      Früher brauchte ein Junior Engineer 18 Stunden, um mehrere hundert 5-GB-JSON-Dateien per Python-Stringverkettung zu verarbeiten,
      nach dem Umstieg auf einfache Konsolen-Tools und multiprocessing waren es nur noch 35 Minuten
      Die Wahl des richtigen Werkzeugs ist entscheidend
  • Presto (AWS Athena) könnte eine schnellere und bessere Alternative sein. Ich würde die 650 GB Daten auch gern lokal testen
    • Presto heißt inzwischen Trino
      Betrieb und Ausführung sind sehr günstig, und es ist ein Tool mit starkem Preis-Leistungs-Verhältnis
  • Auch das neue DuckLake-Katalogformat von DuckDB wäre ein guter Testkandidat — ducklake.select
    • Die Data-Inlining-Flush-Funktion von DuckLake ist noch im Alpha-Stadium
      Um das Problem zu lösen, dass bei kleinen Batch-Schreibvorgängen zu viele Parquet-Dateien entstehen, speichert DuckLake diese inline in einem DBMS (z. B. Postgres)
      Erst vor Kurzem kam die Funktion hinzu, sie wieder in Parquet zurückzuschreiben, aber das muss noch stabilisiert werden
      Zugehörige Dokumentation
    • Beim DuckLake-Format gibt es ein Henne-Ei-Problem durch die SQL-Abhängigkeit
      Der Katalog muss als SQL-Datenbank ausgedrückt werden, während der Vorteil von Parquet gerade darin besteht, diese Komplexität zu vermeiden
      Würde man auch den Katalog auf Parquet aufbauen, könnte daraus vielleicht ein selbstbootstrapendes Format werden