Skalierung von Python mit Dask

Kapitel 9. Migration bestehender Analytic Engineering

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Viele Nutzerinnen und Nutzer arbeiten bereits mit Analyseprogrammen, die sie auf Dask umstellen möchten. In diesem Kapitel geht es um die Überlegungen, Herausforderungen und Erfahrungen von Nutzern, die den Wechsel vollziehen. Der wichtigste Migrationspfad, der in diesem Kapitel untersucht wird, ist das Verschieben eines bestehenden Big-Data-Engineering-Auftrags von einem anderen verteilten Framework, wie Spark, nach Dask.

Warum Dask?

Hier sind einige Gründe, die dafür sprechen, von einem bestehenden Auftrag, der in Pandas oder verteilten Bibliotheken wie PySpark implementiert ist, zu Dask zu migrieren:

Python und PyData Stack

Viele Datenwissenschaftler/innen und Entwickler/innen bevorzugen einen Python-nativen Stack, bei dem sie nicht zwischen Sprachen oder Stilen wechseln müssen.

Umfangreichere ML-Integrationen mit Dask-APIs

Futures, Delayed und ML-Integrationen erfordern weniger Glue-Code vom Entwickler, und die flexiblere Verwaltung des Task-Graphen in Dask führt zu Leistungssteigerungen.

Feinkörniges Aufgabenmanagement

Der Task-Graph von Dask wird während der Laufzeit in Echtzeit generiert und gepflegt, und die Nutzer können synchron auf das Task-Dictionary zugreifen.

Debugging-Overhead

Einige Entwicklerteams bevorzugen die Debugging-Erfahrung in Python, im Gegensatz zu gemischten ...