Sie können einen Supercomputer verwenden, um eine E-Mail zu senden, aber sollten Sie das?

Spark feiert in diesem Jahr seinen zehnten Geburtstag, was ein guter Moment ist, um über seine Relevanz als Datenverarbeitungs-Engine nachzudenken. Selbst nach einem Jahrzehnt bleibt Spark der De-facto-Standard in der verteilten Verarbeitung - eine bemerkenswerte Leistung, wenn man den Anstieg der Konkurrenten im Laufe der Jahre bedenkt.

Für mich gibt es zwei entscheidende Fortschritte, die den Wettbewerb befeuerten:

• Die verfügbaren Ressourcen für eine Cloud-Instanz haben erheblich zugenommen. Zum Beispiel hat sich die Speicherkapazität von 64 GB auf 4 TB bei AWS entwickelt.

• Viele Unternehmen sind pragmatischer geworden beim Entwerfen ihrer Datenpipelines und erkennen, dass nicht jede Pipeline eine verteilte Engine erfordert.

Infolgedessen hat sich das Pendel zurück zu Einzelknoten-Verarbeitungstools bewegt, wie DuckDB und Polars, anstatt sich nur auf verteilte Verarbeitung Engines zu konzentrieren. In diesem Beitrag werde ich beide Engines näher beleuchten und erklären, wie sie Spark ergänzen können.

Dieser Blogbeitrag ist das Ergebnis eines kürzlichen Vortrags, den ich zusammen mit

Jan Vanbuel

gehalten habe. Wenn Sie die Aufzeichnung ansehen möchten, können Sie siehierfinden.

Sehen Sie sich die Wiederholung auf YouTube >>

Datenverarbeitungslandschaft

Bei der Untersuchung von Datenverarbeitungs-Engines finde ich es nützlich, sie nach drei wichtigen Merkmalen zu kategorisieren: Skalierbarkeit, Einfachheit und Kosten-effizienz. Jede Datenverarbeitungs-Engine positioniert sich an der Kante des Dreiecks, da sie sich in erster Linie auf zwei Merkmale konzentriert.

Die verschiedenen Kanten können wie folgt beschrieben werden:

• Mapreduce und Spark auf k8s befinden sich an der Kante, die Kosten-Effizienz und Skalierbarkeit kombiniert. Diese Technologien ermöglichen es Unternehmen, mit Standardhardware zu skalieren, die in der Regel viel günstiger ist als vertikale Skalierung.

• Produkte wie Snowflake und Databricks konzentrieren sich darauf, es so einfach wie möglich zu machen, Ihre Workloads zu skalieren. Sie machen die verteilte Verarbeitung für Unternehmen viel zugänglicher, da sie das Cluster-Management für Sie übernehmen.

• An der Grenze zwischen Kosten-Effizienz und Einfachheit stand Pandas lange allein, mit begrenzter Entwicklung von 2010 bis 2022.

DuckDB und Polars füllen eine Lücke, die von Pandas 1.0 hinterlassen wurde, da es nicht viele Dateningenieure und Analysten gewinnen konnte. Dies lag hauptsächlich an Problemen wie ineffizientem Speichermanagement, einer verwirrenden API und langsamer Leistung bei der Zeichenfolgenverarbeitung. Im Gegensatz zur Datenwissenschaft arbeiten Datenpipelines hauptsächlich mit Zeichenfolgen, weshalb dies ein viel größeres Problem darstellt.

DuckDB 101

Für mich ist die beste Beschreibung von DuckDB die folgende:

Wir sind das SQLite für die Online-Analytikverarbeitung

DuckDB ist eine In-Prozess-Datenbank, was bedeutet, dass Ihre Datenbank im selben Prozess wie Ihr Code läuft. Dies macht es extrem einfach, damit zu beginnen, da Sie nur ein einzelnes Binary installieren müssen. DuckDB ist vor allem eine Datenbank, daher hat es alle Funktionen, die Sie von einer Datenbank erwarten: transaktionale Garantien, einen reichen SQL-Dialekt und Unterstützung für verschiedene Dateiformate,…

Ich mag DuckDB sehr für die folgenden Szenarien:

• Da Sie keine Datenbank konfigurieren müssen, bevor Sie SQL-Abfragen ausführen, ist DuckDB mein bevorzugtes Tool für SQL-Tutorials und Schulungen. Wenn Sie mir nicht glauben, beachten Sie, dass sogar dbt DuckDB in ihrem Erste Schritte-Projekt verwendet.

• Die Kombination von dbt mit DuckDB ist eine gute Alternative zu Spark-Datenpipelines, was ich bereits in einem früheren Blogbeitrag besprochen habe.

DuckDB verwendet eine vektorisierte Abfrage-Engine, die es ermöglicht, Transformationen auf einem Vektor von Eingabewerten anstelle von einem Wert gleichzeitig durchzuführen. Darüber hinaus unterstützt DuckDB die Verarbeitung außerhalb des Speichers, was es ihm ermöglicht, Datensätze, die größer sind als der verfügbare Speicher, zu verarbeiten, indem es Zwischenresultate auf der Festplatte speichert. Diese Funktionen machen DuckDB zu einer ausgezeichneten Wahl für die Einzelknotenverarbeitung und bieten sowohl Geschwindigkeit als auch die Fähigkeit, eine Vielzahl von Datensätzen zu verarbeiten.

Ein letzter Aspekt von DuckDB ist die Erweiterbarkeit durch die Verwendung von Plugins. Dank dieser Funktion kann die Community dazu beitragen, DuckDB zugänglicher zu machen. Die wichtigsten Plugins sind die Integrationen mit verschiedenen Cloud-Anbietern, um Daten aus Blob-Speichern zu lesen. Wenn Sie versuchen möchten, Ihr eigenes Plugin zu schreiben, können Sie dies in C++ oder Rust tun.

Polars 102

Der Slogan von Polars lautet:

Ein DataFrame-Frontend für eine Analytik-Engine

Polars hat einen anderen Ansatz als DuckDB gewählt, indem es zunächst eine funktionale DataFrame-API ähnlich der von Apache Spark anbietet. Der Einstieg in Polars ist ebenso einfach wie pip install polars auszuführen.

Polars verwendet ebenfalls eine vektorisierte Engine und unterstützt auch Streaming, um größere als speicherintensive Workloads zu unterstützen. Die Unterstützung für die Verarbeitung außerhalb des Speichers von Polars ist jedoch derzeit weniger ausgereift als in DuckDB.

Sie können die Polars API erweitern, indem Sie Ihr eigenes Plugin in Python oder Rust schreiben. Damit können Sie die Lesbarkeit oder Leistung bestimmter Operationen verbessern.

Ein Team von Data Minded hat viel Erfahrung im Migrieren von Spark-Datenpipelines, die eine begrenzte Datenmenge verarbeiten, zu Polars. Der Übergang hat die Leistung dieser Pipelines verbessert und der Migrationsprozess verlief reibungslos aufgrund der Ähnlichkeit zwischen beiden APIs.

Neben der Bereitstellung einer DataFrame-API beginnt Polars auch, SQL zu unterstützen. Im Moment ist die SQL-API noch ein Work in Progress, aber es ist interessant zu sehen, wie sie Funktionen hinzufügen, um mit DuckDB zu konkurrieren.

Der Fluchtweg Apache Arrow

Eine Ökosystem rund um eine neue Verarbeitungs-Engine aufzubauen, braucht Zeit, da es viele Systeme gibt, die mit Cloud-Anbietern, Datenbanken und Datenformaten integriert werden müssen,…

Ein Grund, warum diese Werkzeuge so schnell angenommen wurden, ist Apache Arrow. Arrow ist eine Spezifikation, die ein in-memory Datenformat definiert. Mit einer Engine, die diese Spezifikation implementiert, kann der Wechsel von einer Engine zu einer anderen, die Arrow unterstützt, nahtlos erfolgen, ohne dass eine Datenkopie erforderlich ist.

Ein Beispiel:

Jan Vanbuel

hat ein Problem mit der Polars Unterstützung für Excel-Dateien auf Azure Blob-Speicher festgestellt. Als Workaround lud er die Daten mit Pandas und konvertierte sie dann in ein Polars DataFrame für nachfolgende Operationen.

Die richtige Engine auswählen

Mit der Einführung von 2 neuen Verarbeitungs-Engines fragen Sie sich vielleicht, wann Sie sie verwenden sollten. Ich habe einen Flussdiagramm erstellt, um Ihnen bei der Entscheidungsfindung zu helfen, basierend auf drei Schlüsselfragen.

Wie viel Daten verarbeiten Sie?

Das Volumen der zu verarbeitenden Daten ist ein wichtiger Faktor bei der Auswahl der geeigneten Verarbeitungs-Engine. Als allgemeine Richtlinie betrachte ich typischerweise 100 GB als Schwelle. Über 100 GB bietet ein Cluster von Maschinen normalerweise eine bessere Leistung, während unterhalb dieser Schwelle eine Einzelknoten-Verarbeitung die schnelleren Ergebnisse produziert. Der Engpass bei der Verarbeitung großer Datenmengen ist häufig I/O und nicht die Verarbeitung, weshalb die Parallelisierung über ein Cluster von Maschinen häufig effizienter ist.

Möchten Sie einen Cluster selbst verwalten?

Wenn Sie ein Cluster von Maschinen verwenden, ist die nächste Frage, ob Sie die Fähigkeiten haben und Zeit investieren möchten, um Ihr Cluster zu verwalten und zu warten. Wenn die Antwort negativ ist, sollten Sie in Erwägung ziehen, Anbieter zu erkunden, die verwaltete Lösungen anbieten, wie Databricks oder Snowflake. Andernfalls, wenn Sie einen Do-it-yourself-Ansatz bevorzugen, ist Spark auf Kubernetes eine gute Option, ebenso wie AWS EMR.

Wer verarbeitet die Daten?

Um zu entscheiden, welche Einzelknoten-Verarbeitungs-Engine gut zu Ihrem Anwendungsfall passt, können Sie sich ansehen, welche Profile für die Datenverarbeitung verantwortlich sind. Jedes Ingenieurprofil bevorzugt ein bestimmtes Tool, da es mit ihrer Arbeitsweise übereinstimmt. Eine häufig beobachtete Kategorisierung ist wie folgt:

• Dateningenieure bevorzugen Polars

• Datenwissenschaftler bevorzugen Pandas

• Datenanalysten bevorzugen SQL, daher ist DuckDB eine großartige Wahl

Fazit

In diesem Blogbeitrag habe ich zwei aufkommende Tools zur Datenverarbeitung besprochen: DuckDB und Polars. Ich habe ihre gemeinsamen Merkmale hervorgehoben, aber auch ihre unterschiedlichen Ansätze zur Einzelknotenverarbeitung. DuckDB konzentriert sich hauptsächlich auf SQL und Polars auf die DataFrame-Abstraktion.

Ich schloss mit Hinweisen zur Auswahl der entsprechenden Datenverarbeitungs-Engine für einen bestimmten Anwendungsfall. Um Ihnen bei dieser Entscheidung zu helfen, verwendete ich drei Fragen:

• Wie viel Daten verarbeiten Sie?

• Möchten Sie Ihr Cluster selbst verwalten?

• Wer verarbeitet die Daten?

Ich ermutige Sie, beide Verarbeitungs-Engines auszuprobieren, um ein tieferes Verständnis ihrer Fähigkeiten zu gewinnen. Wenn Sie sie für unterschiedliche Anwendungsfälle verwenden oder Erkenntnisse zu teilen haben, lassen Sie es mich gerne im Kommentarbereich wissen.