Langsame Spark-Phase mit wenig E/A

Wenn Sie eine langsame Phase mit wenig E/A haben, kann das die folgenden Ursachen haben:

• Lesen vieler kleiner Dateien
• Schreiben in viele kleine Dateien
• Langsame UDF(s)
• Kartesische Verknüpfung
• Explodierende Verknüpfung

Fast alle diese Probleme können mit dem SQL-DAG identifiziert werden.

Öffnen des SQL-DAG

Um den SQL-DAG zu öffnen, scrollen Sie auf der Auftragsseite ganz nach oben, und klicken Sie auf Zugeordnete SQL-Abfrage:

Nun sollte der DAG angezeigt werden. Wenn nicht, scrollen Sie ein bisschen herum, bis Sie ihn sehen:

Bevor Sie fortfahren, sollten Sie sich mit dem DAG vertraut machen und wissen, wofür die Zeit verwendet wird. Einige Knoten im DAG bieten hilfreiche Zeitinformationen und andere nicht. Dieser Block dauerte beispielsweise 2,1 Minuten und liefert sogar die Phasen-ID:

Diesen Knoten müssen Sie öffnen, um zu sehen, dass er 1,4 Minuten gedauert hat:

Diese Zeiten sind kumulativ, es handelt sich also um die Gesamtzeit, die für alle Aufgaben aufgewendet wurde, nicht um die Uhrzeit. Das ist aber dennoch sehr nützlich, weil sie mit der Uhrzeit und den Kosten korrelieren.

Es ist nützlich, sich damit vertraut zu machen, wofür die Zeit im DAG verwendet wird.

Lesen vieler kleiner Dateien

Wenn einer Ihrer Scan-Operatoren viel Zeit in Anspruch nimmt, öffnen Sie ihn, und überprüfen Sie die Anzahl der gelesenen Dateien:

Wenn Zehntausende von Dateien oder mehr gelesen werden, liegt möglicherweise ein Problem mit kleinen Dateien vor. Ihre Dateien sollten nicht kleiner als 8 MB sein. Das Problem mit kleinen Dateien wird meist durch die Partitionierung auf zu viele Spalten oder eine Spalte mit hoher Kardinalität verursacht.

Wenn Sie Glück haben, müssen Sie vielleicht nur OPTIMIZE ausführen. Unabhängig davon müssen Sie ihr Dateilayout überdenken.

Schreiben in viele kleine Dateien

Wenn der Schreibvorgang lange dauert, öffnen Sie ihn und überprüfen Sie die Anzahl der Dateien und die Menge der geschriebenen Daten:

Wenn in Zehntausende von Dateien oder mehr geschrieben wird, liegt möglicherweise ein Problem mit kleinen Dateien vor. Ihre Dateien sollten nicht kleiner als 8 MB sein. Das Problem mit kleinen Dateien wird meist durch die Partitionierung auf zu viele Spalten oder eine Spalte mit hoher Kardinalität verursacht. Sie müssen ihr Dateilayout überdenken oder optimierte Schreibvorgänge aktivieren.

Langsame UDFs

Wenn Sie wissen, dass Sie UDFs haben, oder etwas Ähnliches im DAG sehen, könnten langsame UDFs ein Problem darstellen:

Wenn Sie glauben, dass dieses Problem bei Ihnen vorliegt, kommentieren Sie Ihre UDF aus, und beobachten Sie die Auswirkungen auf die Geschwindigkeit Ihrer Pipeline. Wenn die UDF tatsächlich die Ursache für den Zeitaufwand ist, ist es am besten, die UDF mit nativen Funktionen neu zu schreiben. Wenn das nicht möglich ist, überprüfen Sie die Anzahl der Aufgaben in der Phase, in der Ihre UDF ausgeführt wird. Wenn sie kleiner als die Anzahl der Kerne in Ihrem Cluster ist, verwenden Sie repartition() für Ihren Datenrahmen, bevor Sie die UDF verwenden:

  (df
    .repartition(num_cores)
    .withColumn('new_col', udf(...))
  )

UDFs können auch von Arbeitsspeicherproblemen betroffen sein. Bedenken Sie, dass jede Aufgabe möglicherweise alle Daten ihrer Partition in den Arbeitsspeicher laden muss. Wenn diese Daten zu groß sind, kann ein sehr langsames oder instabiles Verhalten auftreten. „Repartition“ kann auch dieses Problem lösen, indem jede Aufgabe verkleinert wird.

Kartesische Verknüpfung

Wenn Sie eine kartesische Verknüpfung oder verschachtelte Schleifenverknüpfung in Ihrem DAG sehen, sollten Sie wissen, dass diese Verknüpfungen sehr teuer sind. Vergewissern Sie sich, dass das so beabsichtigt ist, und überlegen Sie, ob es eine andere Möglichkeit gibt.

Explodierende Verknüpfung oder „explode“

Wenn einige Zeilen in einen Knoten hineingehen und wesentlich mehr herauskommen, kann eine explodierende Verknüpfung oder explode() vorliegen:

Weitere Informationen über explodierende Verknüpfungen finden Sie im Leitfaden zur Databricks-Optimierung.