Pandas skalieren: Ein Vergleich von Dask, Ray, Modin Vaex, und RAPIDS

Ein Vergleich der besten Bibliotheken für skalierbares Data Wrangling

by
DataRevenue

Python und die beliebteste, dazugehörige Data-Wrangling Bibliothek Pandas werden immer populärer. Im Vergleich zu Konkurrenten wie Java ist die Datenexploration und -transformation mit Python und Pandas sehr viel einfacher.

Aber sowohl Python als auch Pandas sind auch für ihre Probleme im Zusammenhang mit Skalierbarkeit und Effizienz bekannt.

Python ist nicht ganz so effizient, da es sich um eine dynamische Programmiersprache handelt. Vor allem hat Python jedoch schon immer größeren Wert auf Simplizität und Lesbarkeit als auf reine Leistung gelegt. Dementsprechend konzentriert sich Pandas darauf, eine einfache, hoch entwickelte API anzubieten, wobei die Leistung weitgehend ignoriert wird. Der Entwickler von Pandas hat sogar selbst "10 Dinge, die ich an Pandas hasse" zusammengefasst:

Zehn Dinge, die Wes McKinney an Pandas hasst.
Leistungsfähigkeit und mangelnde Flexibilität sind die Hauptprobleme, die Pandas' eigener Entwickler an der Bibliothek bemängelt. (Quelle)

Es überrascht also kaum, dass viele Entwickler versuchen, Python und Pandas auf verschiedenen Wegen mehr Leistungsfähigkeit zu verschaffen. Hier eine Auswahl der wichtigsten Projekte:

  • Dask: ein Low-Level Scheduler und High-Level Teilersatz für Pandas, der darauf ausgerichtet ist, Code auf Compute-Clustern auszuführen.
  • Ray: ein Low-Level-Framework um Python-Code über mehrere Prozessoren oder Compute-Cluster zu parallelisieren.
  • Modin: ein Ersatz für Pandas, basierend auf entweder Dask oder Ray.
  • Vaex: ein teilweiser Pandas-Ersatz, der Lazy Evaluation und Memory Mapping verwendet, damit man mit großen Datensätzen auf normalen Rechnern arbeiten kann.
  • RAPIDS: eine Sammlung von Data Science Bibliotheken, die auf GPUs laufen und cuDF enthalten, ein teilweiser Ersatz für Pandas.

Diese Auswahl deckt aber noch lange nicht alles ab. Hier ein Überblick über die Python Data Wrangling-Landschaft:

Eine Übersicht, welche Data Wrangling Bibliotheken in Google Suchen wie oft miteinander verglichen werden
Dask, Modin, Vaex, Ray, und CuDF werden oft als mögliche Alternativen untereinander betrachtet.

Quelle: Erstellt mit diesem Tool

Wenn man also mit vielen Daten arbeitet und schnellere Ergebnisse benötigt, für welche Alternative sollte man sich am besten entscheiden?

Für welches Tool soll ich mich entscheiden?

Die einfache Antwort: Es macht Sinn, sich die Bibliotheken in dieser Reihenfolge anzusehen:

  • Modin, mit Ray als Backend. Hier kann man schon durch Anpassen einer einzigen Zeile erhebliche Fortschritte erzielen (import pandas as pd zu import modin.pandas as pd). Im Gegensatz zu den anderen Tools zielt Modin darauf ab, mit Pandas vollständig kompatibel zu sein.
  • Dask, ein größeres und somit komplizierteres Programm. Dask stellt aber auch den Dask.dataframe zur Verfügung, eine higher-level, Pandas-ähnliche Bibliothek, die beim Umgang mit out-of-core Datensätzen helfen kann.
  • Vaex, ermöglicht mit großen Datenmengen auf normalen Laptops zu arbeiten. Der Pandas-Ersatz von veax deckt nur einen Teil der Pandas-API ab – und ist hauptsächlich auf Daten-Exploration und Visualisierung ausgerichtet.
  • RAPIDS, wenn man Zugriff auf NVIDIA-Grafikkarten hat und diese möglichst effizient nutzen möchte.

Kurzer Vergleich

Jede der Bibliotheken, die wir hier vergleichen, hat unterschiedliche Stärken, Schwächen und Skalierungs-Strategien. Die nächste Tabelle liefert darüber einen groben Überblick. Wie so oft hängen die meisten der folgenden Bewertungen natürlich stark von der jeweiligen Situation ab. 

Eine Tabelle, in der die Bibliotheken bezüglich ihres Entwicklungsstandes, Popularität, Benutzerfreundlichkeit und anderen Kriterien verglichen werden.
Dask und Ray sind weiter entwickelt, aber mit Modin und Vaex fällt der Einstieg leichter. Rapids ist vor allem dann praktisch, wenn man Zugang zu GPUs hat. (Quelle: Autor)

Hierbei handelt es sich um subjektive Bewertungen, die abhängig von den jeweiligen Umständen stark variieren können. Bei der Notengebung haben wir diese Faktoren berücksichtigt:  

  • Entwicklungsstand: Wie lange gibt es die Bibliothek schon, wie aktuelle sind die letzten Commits, und wie viele Commits gibt es schon insgesamt.
  • Beliebtheit: Anzahl an GitHub-Sternen.
  • Leichte Handhabung: Vorwissen, das von Nutzern erwartet wird, vorausgesetzte Hardwareressourcen und wie einfach es ist das Tool zu installieren.
  • Skalierbarkeit: Die ungefähre Begrenzung in der Größe der Datensätze. Abhängig davon ob die Bibliothek hauptsächlich auf RAM oder auf den Festplattenspeicher eines einzelnen Rechners angewiesen ist, oder ob sie auf Clustern von Rechnern skaliert werden kann.
  • Anwendungsbereich: Ob die Bibliotheken darauf ausgelegt sind, Python-Software im Allgemeinen zu beschleunigen ("General"), ob sie sich auf Datascience und Machine Learning konzentrieren ("Data Science") oder ob sie sich darauf beschränken, schlichtweg die Funktion von Pandas' 'DataFrame'-Funktionalität ("DataFrame") zu ersetzen.

CPUs, GPUs, Clusters, or Algorithms?

Wenn der Datensatz zu groß ist, um damit auf einem einzelnen Rechner effizient zu arbeiten, gibt es folgende Möglichkeiten, seine Prozesse zu skalieren:

  • Mehrere Threads oder Prozessoren: Moderne CPUs haben mehrere unabhängige Kerne, von denen jeder Kern mehrere Threads ausführen kann. Der einfachste Ansatzpunkt ist meist, sicherzustellen, dass ein Programm die gesamte potenzielle Rechenleistung nutzt, indem es alle Kerne mit einbezieht.
  • GPU Kerne: Grafikkarten wurden ursprünglich entwickelt, um einfache Operationen auf Millionen von Pixeln effizient und gleichzeitig ausführen zu können. Entwickler erkannten jedoch bald andere Einsatzmöglichkeiten für diese Leistung, und "GP-GPU" (General Processing on a Graphics Processing Unit) ist mittlerweile eine beliebte Methode zur schnelleren Ausführung von Data Wrangling Code, der vor allem von Matrixmanipulationen abhängt.
  • Cluster aufbauen: Sobald man die Grenzen einer einzelnen Maschine erreicht hat, benötigt man einen vernetzten Cluster von Maschinen, die miteinander arbeiten.

Abgesehen vom Einsatz zusätzlicher Hardware-Ressourcen können auch clevere Algorithmen die Effizienz verbessern. Tools wie Vaex verlassen sich stark auf die Lazy Evaluation (Berechnung nur dann durchführen, wenn die Ergebnisse sicher gebraucht werden) und Memory Mapping (Dateien auf Festplatten so behandeln, als ob sie in den RAM geladen wären).

Keine dieser Strategien ist grundsätzlich besser als die anderen, daher sollte man sich immer für diejenige entscheiden, die am besten zum jeweiligen Problem passt.

Parallelberechnungen (unabhängig davon, ob man Threads, CPU-Kerne, GPUs oder Cluster verwendet) bieten viele Vorteile, sind aber auch relativ komplex und erschweren Aufgaben wie das Debugging erheblich.

Moderne Bibliotheken können einen Teil - aber nicht alles - dieser zusätzlichen Komplexität ausgleichen. Unabhängig davon, welche Tools man verwendet, läuft man immer Gefahr dass anstatt eines ordentlichen Ergebnisses (unten links) eher Chaos entsteht (unten rechts).

Hundewelpen in einer ordentlichen Reihe, die Futter aus verschiedenen Schüsseln fressen - und dann entsteht Chaos.
Parallelverarbeitung funktioniert nicht immer so reibungslos, wie man es erwartet. (Quelle)

Dask vs. Ray vs. Modin vs. Vaex vs. RAPIDS

Bei der Auswahl der richtigen Bibliothek für ein bestimmtes Projekt macht es Sinn, all diese Bibliotheken miteinander zu vergleichen, auch wenn sie jeweils unterschiedliche Bereiche abdecken und nicht direkte Alternativen zueinander darstellen.

Bevor wir auf die Einzelheiten eingehen, ein kurzer Hinweis:

  • RAPIDS ist eine Sammlung von Bibliotheken. Für diesen Vergleich betrachten wir nur die cuDF-Komponente, die das RAPIDS-Äquivalent von Pandas darstellt.
  • Dask kann man sich besser als zwei Projekte vorstellen: einen Low-Level Python-Scheduler (in gewisser Weise ähnlich wie Ray) und ein Higher-Level Dataframe-Modul (in vielerlei Hinsicht ähnlich wie Pandas).

Dask vs. Ray

Dask (als ein lower-level Scheduler) und Ray überschneiden sich stark in ihrer Zielsetzung, die parallele Ausführung von Python-Code auf Rechenclustern zu erleichtern. Dask konzentriert sich mehr auf Data Science und stellt higher-level APIs bereit, die wiederum einen teilweisen Ersatz für Pandas, NumPy und Scikit-Learning bieten, zusätzlich zu einem Low-Level Scheduling- und Cluster-Management-Framework.

Die Entwickler von Dask und Ray diskutieren in diesem GitHub Thread die Gemeinsamkeiten und Unterschiede der Bibliotheken und kommen zu dem Schluss, dass eines der Hauptunterscheidungsmerkmale die Scheduling-Strategie ist.

Dask vs. Modin

Dask (der Higher-Level Dataframe) erkennt die Popularität der Pandas-API und übernimmt Teile des Pandas Syntax, zielt aber nicht auf Kompatibilität mit allen Pandas Funktionen ab. Es ist sehr unwahrscheinlich, dass man in kompliziertem Pandas Code einfach DataFrames mit Dask.Dataframe ersetzt kann und alles wie erwartet funktioniert. Im Gegensatz dazu ist dies genau das Ziel von Modin: 100%iger Ersatz und Kompatibilität von Pandas. Modin kann auf Dask laufen, wurde aber ursprünglich für die Verwendung mit Ray gebaut, und diese Integration ist nach wie vor ausgereifter.

Dask vs. Vaex

Dask (Dataframe) ist nicht vollständig kompatibel mit Pandas, aber ziemlich nahe dran. Die vielen Gemeinsamkeiten bringen mit sich, dass Dask einige der Nachteile von Pandas ebenfalls aufweist. Vaex unterscheidet sich stärker von Pandas (wobei auch hier grundsätzliche Abläufe wie das Einlesen von Daten oder Berechnen einfacher Statistiken sehr ähnlich sind) und ist daher auch weniger stark von Pandas abhängig.

Letztendlich konzentriert sich Dask stärker skalierbare Berechnungen auf Rechenclustern, während es Vaex ermöglicht, mit großen Datensätzen auf einem einzigen Rechner zu arbeiten. Vaex bietet außerdem Funktionen zur einfachen Visualisierung und Darstellung großer Datensätze, während sich Dask mehr auf Datenverarbeitung und Data Wrangling konzentriert.

Dask vs. RAPIDS (cuDF)

Dask und RAPIDS funktionieren über eine von RAPIDS bereitgestellte Integration sehr gut zusammen. Wenn man einen Compute-Cluster hat, bietet es sich an, Dask zu verwenden. Mit einer NVIDIA-Grafikkarte sollte man RAPIDS einsetzen. Wenn man einen Compute-Cluster mit NVIDIA-GPUs hat, sollte man beides verwenden.

Ray vs. Modin oder Vaex oder RAPIDS

Es ist nicht besonders sinnvoll, Ray mit Modin, Vaex oder RAPIDS zu vergleichen. Im Gegensatz zu den anderen Bibliotheken bietet Ray keine High-Level-APIs oder ein Pandas-Äquivalent. Stattdessen betreibt Ray Modin und lässt sich ähnlich wie Dask in RAPIDS integrieren.

Modin vs. Vaex

Ähnlich wie beim Vergleich von Dask und Vaex ist es Modins Ziel, einen vollständigen Ersatz für Pandas zu bieten, während Vaex stärker von Pandas abweicht. Modin eignet sich als erste Wahl, um vorhandenen Pandas-Code zu beschleunigen, während Vaex eher für neue Projekte oder spezielle Anwendungsfälle (insbesondere die Visualisierung großer Datensätze auf einem einzigen Rechner) interessant ist.

Modin vs. RAPIDS (cuDF)

Modin skaliert Pandas-Code unter Einsatz vieler CPU-Kerne via Ray oder Dask. RAPIDS skaliert Pandas-Code, indem es ihn auf GPUs ausführt. Wenn GPUs zur Verfügung stehen, sollte man RAPIDS ausprobieren. Der einfachste Erfolg wird aber wahrscheinlich mit Modin kommen, daher sollte man sich erst dann an RAPIDS wenden, wenn man Modin bereits ausprobiert hat.

Vaex vs. RAPIDS (cuDF)

Vaex und RAPIDS sind sich darin ähnlich, dass sie beide Leistungssteigerungen ohne Rechen-Cluster bieten können: Vaex durch bessere Ausnutzung der Festplatten- und Prozessorkerne des Computers und RAPIDS durch Verwendung des Grafikprozessors (sofern dieser verfügbar und kompatibel ist). Das RAPIDS-Projekt als Ganzes zielt darauf ab, sehr viel breiter aufgestellt zu sein als Vaex, sodass man Machine Learning End-to-End durchführen kann, ohne dass die Daten den Grafikprozessor verlassen. Vaex ist eher für die Erstellung von Prototypen und Datenexploration geeignet, da man damit große Datensätze auf normalen Rechnern analysieren kann.

Abschließende Anmerkungen: Voreilige Optimierungen sind häufig ein Problem

Es macht Spaß, neue Tools einzusetzen. Allerdings leiden viele Projekte unter Over-Engineering und voreiliger Optimierung. Wenn man keinerlei Skalierungs- oder Effizienzprobleme hat, ist es nicht verkehrt, lediglich Python und Pandas weiterhin zu verwenden. Pandas ist weit verbreitet, hoch entwickelt und gleichzeitig nicht zu komplex.

Man sollte sich erst dann mit den hier besprochenen Bibliotheken auseinandersetzen, wenn die Grenzen von Python und Pandas erreicht wurden. Andernfalls läuft man Gefahr, zu viel Zeit damit zu verbringen, neue Bibliotheken zu konfigurieren, anstatt mit dem eigentlichen Projekt Fortschritte zu erzielen.

Bei Data Revenue haben wir bereits zahlreiche Projekte mit diesen Bibliotheken umgesetzt und wissen, wann und wie sie am besten eingesetzt werden können. Sollten Sie eine zweite Meinung benötigen, wenden Sie sich an uns. Wir helfen gerne weiter.

Bekomme immer die neusten Artikel

Trag dich mit deiner E-Mail ein, um du bekommst jede Woche unseren neusten Artikel.

Ich danke Ihnen! Ihre Einreichung ist eingegangen!
Oops! Something went wrong while submitting the form.