Warum Dask, wenn ich fragen darf?

Von Zeit zu Zeit tauchen neue Daten-Tools auf (z.B. Rapids und Databricks Delta). Die Akzeptanz solcher Tools braucht jedoch Zeit. Sowohl für das Framework, um stabil zu werden, als auch für potenzielle Benutzer, um es in ihrem Software-Stack zu positionieren. Die Frage ist: Welche Tools werden sich durchsetzen?

Wir werden versuchen, Ihnen bei der Beantwortung dieser Frage für ein Tool namens Dask zu helfen. Das Projekt wurde erstmals im Jahr 2014 veröffentlicht und erreichte im Oktober 2018 den Status 1.0. Inzwischen sollte das Projekt einigermaßen stabil sein; ein guter Zeitpunkt, um zu untersuchen, was dieses Tool für unsere Kunden tun kann.

Was ist Dask

Lassen Sie uns zunächst hören, was die Autoren zu sagen haben:

Dask ist eine flexible Bibliothek für parallele Berechnungen in Python. Dask besteht aus zwei Teilen:

• Dynamische Aufgabenplanung, optimiert für Berechnungen. Dies ist vergleichbar mit Airflow, Luigi, Celery oder Make, aber optimiert für interaktive Berechnungsaufgaben.
• "Big Data"-Sammlungen wie parallele Arrays, Dataframes und Listen, die gängige Schnittstellen wie NumPy, Pandas oder Python-Iteratoren auf Umgebungen mit mehr als einem Speicherplatz oder verteilten Umgebungen erweitern. Diese parallelen Sammlungen laufen auf dynamischen Aufgabenplanern.

Mit anderen Worten: Dask ist ein allgemeines Framework zur Parallelisierung der Datenmanipulation sowohl von unstrukturierten (Python-Datenstrukturen) als auch von strukturierten (tabellarischen) Daten. Letzteres steht im Vordergrund, da Dask eindeutig von etablierteren Projekten wie Pandas inspiriert wurde. Es ist gar nicht so abwegig, sich Dask so vorzustellen, dass es die gleichen Dinge wie Pandas tut, nur eben parallel.

Um dies zu erreichen, müssen Sie die sequentiellen Algorithmen überdenken. Nehmen wir als einfaches Beispiel die Berechnung des Durchschnittswerts einer Reihe von Zahlen. Es muss festgelegt werden, was parallel geschieht ("map") und wie die Ergebnisse kombiniert werden sollen ("reduce"). Jeder Worker sollte zwei Zwischenergebnisse berechnen, eine "Summe" und eine "Anzahl", und diese an den Hauptknoten weitergeben, der das Endergebnis erzeugt. Beachten Sie, dass eine einfache Aufteilung der Arbeit und die Anwendung des sequentiellen Algorithmus auf jeden Worker nicht zum Ziel führt. Der Hauptwert eines Frameworks wie Dask für die strukturierte Datenmanipulation besteht darin, uns den Aufwand zu ersparen, diese parallelen Algorithmen selbst zu entwickeln und zu programmieren.

Um die Lernkurve seines Frameworks so sanft wie möglich zu halten, versucht Dask, für die meisten Datenexperten so nah wie möglich an ihrem Zuhause zu bleiben. Dies geschieht durch die Nutzung vorhandener Pakete wie Pandas und NumPy aus dem PyData-Ökosystem. Es baut auf diesen Paketen auf und ähnelt deren APIs.

Eine Anmerkung zur "Skalierung" bzw. Parallelisierung

Beachten Sie, dass Skalierung nicht unbedingt die Verteilung auf einen Cluster von Computern bedeuten muss. Manchmal möchten Sie analytische Arbeitslasten (durch Parallelisierung) auf einem einzelnen Computer mit mehreren CPUs oder Kernen beschleunigen. Zum Beispiel bei der Durchführung von Datenanalysen mit benutzerdefinierten Python-Operationen in einer Notebook-Umgebung. In solchen Fällen bietet Dask eine willkommene Abstraktion für viele gängige Datenrahmenmanipulationen.

Alternativen, die Ihr Interesse wecken könnten

In Anbetracht des Umfangs des Dask-Projekts liegt es nahe, es mit Apache Spark zu vergleichen, einer weit verbreiteten Technologie, die sich in den letzten Jahren bewährt hat.

Der Gedanke, dass diese Projekte recht ähnlich sind, wird von den Dask-Entwicklern aufgegriffen: Sie haben genau diesem Thema eine Hilfe- und Referenzseite gewidmet.

Dask vs. Spark

Es ist nur Python

Während Spark in Scala (mit Python-Unterstützung) erstellt wurde, ist Dask in Python programmiert. Es bleibt näher am PyData-Ökosystem, indem es auf Bibliotheken wie NumPy, Pandas und Scikit-Learn aufbaut. Dies erleichtert die Fehlersuche, da es möglich wird, den Stacktrace bis in die Interna des Dask-Frameworks zu verfolgen. Dasselbe ist in PySpark nicht wirklich möglich, da die meisten API-Aufrufe mehr oder weniger sofort an Scala weitergereicht werden. So bleiben sie außerhalb des Blickfelds der IDE/des Python-Debuggers. Neben der Erleichterung der Introspektion ist natives Python einfacher zu erweitern und an Ihre spezifischen Bedürfnisse anzupassen.

Reifegrad

Dask ist ein jüngeres Projekt und daher weniger bekannt und in aktuelle Software-Stacks eingebettet. Die meisten neuen Technologien durchlaufen eine Phase der Sprödigkeit / Wachstumsschmerzen, die mit einigen Macken oder "Gettos" einhergehen. Zugegeben, während unserer kurzen Evaluierung von Dask mussten wir bei einigen Gelegenheiten die Stacktraces von unbenannten Ausnahmen in einer unbekannten Codebasis entschlüsseln. Fairerweise muss man sagen, dass dies bis zu einem gewissen Grad zu erwarten ist und nicht unbedingt ein Grund zum Aufgeben ist. Außerdem ist der Weg des durchschnittlichen Datenwissenschaftlers zur Beherrschung von Spark auch kein Spaziergang im Park. Nichtsdestotrotz gibt es Spark schon länger und die meisten Probleme wurden von der Community (z.B. auf Stackoverflow) entweder durch Updates oder Workarounds behoben.

DAG-Optimierung

Sowohl Spark als auch Dask erstellen einen Ausführungsplan, bevor sie etwas berechnen. APIs für Berechnungen mit strukturierten Daten sind in hohem Maße deklarativ: Sie geben an, wie das Ergebnis aussehen soll, und nicht, wie es berechnet werden soll. Den idealen Weg für eine verteilte Berechnung zu finden, kann sehr schwierig sein und hängt von vielen Faktoren im Zusammenhang mit der Datenverteilung und den verfügbaren Rechenressourcen ab. Der Vorteil von deklarativen APIs ist, dass sie einen Großteil dieses Rätsels (potenziell) an den Computer auslagern können. Dadurch kann sich der Benutzer mit Problemen auf höherer Ebene befassen, und wenn es gut gemacht ist, führt dies auch zu besseren Lösungen. Die meisten seit langem bestehenden Implementierungen relationaler Datenbanken sind sehr effizient, weil sie viele Iterationen der Optimierung und Verbesserung durchlaufen haben.

Während Spark den Plan durch mehrere Optimierungsebenen (logisch und physisch) verbessert, scheint Dask in begrenzterer Weise zu optimieren. Wenn ein Abfrageplan beispielsweise eine Reduzierung von Zeilen oder Spalten enthält, plant Spark diese Reduzierung so früh wie möglich ein ("Prädikat-Pushdown"). Das ist effizient, denn es vermeidet die Verarbeitung von Daten, die für das Ergebnis nicht erforderlich sind. Dasselbe ist in Dask möglich, geschieht aber nur, wenn der Benutzer dies explizit angibt.

Asynchrone API

Dask bietet seinen Benutzern eine asynchrone API ("futures API"), die mit asyncio integriert ist, einem Projekt, das Green Threading ermöglicht und Teil der Python-Standardbibliothek ist. Dask läuft in einem vom initiierenden Python-Prozess getrennten Prozess. Wenn Sie einen Auftrag an den Dask-Cluster übermitteln, ist der Hauptprozess an die E/A gebunden, so dass es möglich ist, gleichzeitig etwas anderes zu tun. Mit anderen Worten: Es ist möglich, Dask eine lange laufende Berechnung durchführen zu lassen, ohne den Hauptprozess zu blockieren, während Sie auf das Ergebnis warten. Es ist zwar möglich, einen nicht blockierenden Auftrag über die PySpark CLI zu übermitteln, aber das Gleiche kann nicht über einen Python-Interpreter gemacht werden.

Die Dask-Tutorials enthalten eine tolle Demonstration des Vorteils von asynchronen Aufrufen: gestapelte, iterative Berechnungen. Die Berechnungen werden in jedem Stapel parallel durchgeführt, aber die einzelnen Ergebnisse werden so früh wie möglich gesammelt. In der Zwischenzeit wird ein Graph ständig aktualisiert, was bedeutet, dass sich die Figur während der Berechnung entwickelt. Eine praktischere Anwendung ist ein Webservice, der Dask für die Bearbeitung einiger seiner eingehenden Anfragen benötigt. Aufträge könnten an den Cluster weitergeleitet werden, während der Dienst für neue, gleichzeitige Verbindungen offen bleibt. Auf diese Weise ließe sich Dask gut mit einem asynchronen Webserver wie Sanic integrieren, PySpark hingegen nicht.

Urteil

Nach unserer Erfahrung ist Spark immer noch stabiler und ausgereifter und bleibt daher unser Tool der Wahl. Aber wie gesagt, es dauert seine Zeit, sich ein neues Tool anzueignen und mit der Zeit könnte sich unsere Meinung ändern.

Wenn Sie Dask ausprobieren möchten, sollten Sie Folgendes beachten:

• Bleiben Sie nach Möglichkeit bei Pandas oder scikit-learn und wechseln Sie nur dann zu Dask, wenn es nötig ist, denn Sie wollen keine zusätzliche Komplexität/keinen zusätzlichen Aufwand, wenn es nicht notwendig ist.
• Wenn Sie mit halb- oder unstrukturierten Daten beginnen, sollten Sie so schnell wie möglich von der Low-Level Dask Bag-API auf die High-Level Dask Dataframe-API umsteigen. Aufgrund der einfacheren API werden Sie weniger Fehler machen und dennoch eine vergleichbare Leistung erzielen.
• Folgen Sie der unten aufgeführten Anleitung, in der die oben genannten Punkte näher erläutert werden.

Erfahrung sammeln

Interessiert? Wir können Ihnen eine sehr ausführliche Anleitung empfehlen. Sie können sogar Binder (kostenlos) verwenden, um mit nur einem Klick eine komplett eingerichtete Umgebung inklusive Compute zu starten.

Das Tutorial behandelt die verschiedenen Benutzerschnittstellen, die Dask dem Benutzer zur Verfügung stellt, z.B. Dask bag, Dask array und Dask dataframe. Außerdem werden die Benutzerschnittstellen Delayed und Futures erklärt, die verwendet werden, wenn Ihr Problem nicht in eine der oben beschriebenen Datenerfassungen passt. Das Tutorial endet mit einem Notizbuch über maschinelles Lernen mit Dask, in dem z.B. erklärt wird, wie Dask eine Grid-Suche in Scikit-learn parallelisieren kann.

Was meinen Sie dazu?

Wir sind auch an Ihren Erfahrungen interessiert. Haben Sie Dask verwendet? Welche Erfahrungen haben Sie gemacht? Sprechen Sie uns an und wir hoffen, dass wir Sie in der Community wiedersehen!