Wie kann sichergestellt werden, dass das Laden von Spark DataFrame von Parquet verteilt und parallelisiert wird?

Question

Wenn Spark Quelldaten aus einer Datei in einen DataFrame lädt, hängt es von den Faktoren ab, ob die Daten vollständig in den Speicher eines einzelnen Knotens (höchstwahrscheinlich der Treiber/Master-Knoten) oder in die für die Berechnung erforderlichen minimalen, parallelen Teilmengen geladen werden auf den Arbeiter/Executor-Knoten)? Wenn Sie Parquet als Eingabeformat und das Laden über die Spark DataFrame-API verwenden, sind Überlegungen erforderlich, um sicherzustellen, dass das Laden aus der Parquet-Datei parallelisiert und an die Executoren übertragen wird Spalten benötigt für die Berechnung auf dem betreffenden Executor-Knoten?

(Such den Mechanismus Funken verwendet planen Laden von Quelldaten in dem verteilten Ausführungsplan, um zu vermeiden, anstrengende Speicher auf einem Knoten durch das Laden des vollständigen Datensatz. Verstehen)

Answer 1

Solange Wenn Sie Spark-Operationen verwenden, werden alle Datentransformationen und Aggregationen nur für Executoren ausgeführt. Daher ist es nicht notwendig, dass ein Treiber die Daten lädt, sein Job besteht darin, den Verarbeitungsfluss zu verwalten. Der Treiber ruft die Daten nur dann ab, wenn Sie einige Terminaloperationen wie collect(), first(), show(), toPandas(), toLocalIterator() und ähnliche verwenden. Außerdem lädt der Executor nicht den gesamten Dateiinhalt in den Speicher, sondern erhält die kleinsten möglichen Chunks (die Partitionen genannt werden).

Wenn Sie das Spaltenspeicherformat wie Parkett verwenden, werden nur Spalten geladen, die für den Ausführungsplan erforderlich sind. Dies ist das Standardverhalten in Spark.

Edit: Ich habe gerade gesehen, dass es ein Fehler in dem Funken sein, und wenn Sie verschachtelte Spalten in Ihrem Schema verwenden dann unnötige Spalten geladen werden können, finden Sie unter: Why does Apache Spark read unnecessary Parquet columns within nested structures?