Verständnis der Spark-Partitionierung

Question

Ich versuche zu verstehen, wie Spark Daten partitioniert. Angenommen, ich habe eine Ausführungs-DAG wie auf dem Bild (orangefarbene Kästchen sind die Stufen). Die beiden Operationen groupBy und join sollen sehr schwer sein, wenn die RDDs nicht partitioniert sind.

Ist es dann ratsam, .partitonBy(new HashPartitioner(properValue)) auf P1, P2, P3 und P4 zu verwenden, um Shuffle zu vermeiden? Was kostet die Partitionierung einer vorhandenen RDD? Wann ist es nicht sinnvoll, eine vorhandene RDD zu partitionieren? Speichert Spark meine Daten nicht automatisch, wenn ich keinen Partitionierer angegeben habe?

Danke

Answer 1

tl; dr Die Antworten auf Ihre Fragen bzw.: Besser zu partitionieren, wenn Sie können; Wahrscheinlich weniger als nicht Partitionierung; Ihr ist auf die eine oder andere Weise partitioniert; Ja.

Dies ist eine ziemlich breite Frage. Es nimmt einen guten Teil unseres Kurses ein! Aber versuchen wir so viel wie möglich über Partitionierung zu sprechen, ohne einen Roman zu schreiben. Wie Sie wissen, besteht der Hauptgrund, ein Tool wie Spark zu verwenden, darin, dass Sie zu viele Daten auf einer Maschine analysieren müssen, ohne dass der Lüfter wie ein Strahltriebwerk klingt. Die Daten werden unter allen Kernen auf allen Maschinen in Ihrem Cluster verteilt, also ja, es gibt eine Standardpartitionierung - entsprechend den Daten. Denken Sie daran, dass die Daten bereits im Ruhezustand verteilt sind (in HDFS, HBase usw.). Daher werden Spark-Partitionen standardmäßig nach der gleichen Strategie verwaltet, um die Daten auf den Rechnern zu behalten, wo sie bereits vorhanden sind - mit der gleichen Anzahl von Partitionen zur Anzahl der Kerne im Cluster. Sie können diese Standardnummer überschreiben, indem Sie spark.default.parallelism konfigurieren, und Sie möchten, dass diese Zahl 2-3 pro Kern pro Computer beträgt.

Normalerweise möchten Sie jedoch Daten, die zusammengehören (z um den Zufall später zu minimieren. Spark bietet auch eine RangePartitioner, oder Sie können Ihre eigenen für Ihre Bedürfnisse ziemlich leicht rollen. Aber Sie haben recht, dass die Kosten für die Umstellung von der Standardpartitionierung auf die benutzerdefinierte Partitionierung hoch sind. es ist fast immer es wert.

Es ist im Allgemeinen ratsam, zu Beginn zu trennen (anstatt das unvermeidliche mit partitionBy zu verzögern) und dann repartition, wenn später benötigt. Später können Sie auch coalesce auswählen, was zu einem Zwischenmischen führt, um die Anzahl der Partitionen zu reduzieren und einige Maschinen und Kerne im Leerlauf zu belassen, da der Gewinn im Netzwerk-IO höher ist als der Verlust der CPU-Leistung.

(Die einzige Situation, die ich mir vorstellen kann, wo Sie nicht am Anfang partitionieren - weil Sie nicht können - ist, wenn Ihre Datenquelle eine komprimierte Datei ist.) Beachten Sie, dass Sie Partitionen während einer Kartenumwandlung mit mapPartitions und beibehalten können.

Schließlich denken Sie daran, dass, wie Sie mit Ihrem Analytics experimentieren, während Sie Ihren Weg bis zu Skala gibt es Diagnosefunktionen können Sie:

• toDebugString die Abstammung von RDD s
• sehen getNumPartitions zu, schockierend, erhalten die Anzahl der Partitionen
• glom deutlich zu sehen, wie Ihre Daten partitioniert werden

Und wenn Sie den schamlosen Stecker begnadigen, sind dies die Arten von Dingen, die wir in Analytics with Apache Spark diskutieren. Wir hoffen, bald eine Online-Version zu haben.

Answer 2

Durch partitionBy Anwendung präventiv beurteilen Sie die Shuffle nicht vermeiden. Du drückst es einfach an einen anderen Ort. Dies kann eine gute Idee sein, wenn partitionierte RDD mehrfach verwendet wird, Sie aber nichts für einen einmaligen Join erhalten.

Speichert Spark meine Daten nicht automatisch, wenn ich keinen Partitionierer angeben?

Es wird partitionieren (auch bekannt als Shuffle) Ihre Daten einen Teil der Join) und anschließenden groupBy (es sei denn, Sie die gleiche Taste halten und Transformation verwenden, die Partitionierung bewahrt).