Freigeben über

Optimieren von Apache Spark-Anwendungen in HDInsigh

  • Artikel

Dieser Artikel bietet eine Übersicht über die Strategien zur Optimierung der Apache Spark-Arbeitsplätze für Azure HDInsight.

Übersicht

Die folgenden häufigen Szenarien können auftreten

  • Der gleiche Spark-Auftrag ist langsamer als zuvor im gleichen HDInsight-Cluster
  • Der Spark-Auftrag ist im HDInsight-Cluster langsamer als lokal oder bei anderen Drittanbietern
  • Der Spark-Auftrag ist in einem HDI-Cluster langsamer als ein anderer HDI-Cluster

Die Leistung Ihrer Apache Spark-Aufträge hängt von mehreren Faktoren ab. Diese Leistungsfaktoren umfassen:

  • Wie Ihre Daten gespeichert sind
  • Wie der Cluster konfiguriert ist
  • Die Vorgänge, die beim Verarbeiten der Daten verwendet werden.
  • Fehlerhafter Yarndienst
  • Speichereinschränkungen aufgrund von nicht korrekt dimensionierten Executors und OutOfMemoryError
  • Zu viele Aufgaben oder zu wenige Aufgaben
  • Datenschiefe verursachte einige schwere Aufgaben oder langsame Aufgaben
  • Aufgaben langsamer in schlechten Knoten

Schritt 1: Überprüfen, ob Ihr Yarn-Dienst fehlerfrei ist

  1. Wechseln Sie zur Ambari-Benutzeroberfläche:
  • Überprüfen, ob ResourceManager oder NodeManager Warnungen ausgibt
  • Überprüfen des Status "ResourceManager" und "NodeManager" in YARN > SUMMARY: Alle NodeManager sollten den Status "Gestartet" haben und nur der aktive ResourceManager sollte den Status "Gestartet" haben

  1. Überprüfen, ob die Yarn-Benutzeroberfläche über https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster zugänglich ist

  2. Überprüfen, ob Ausnahmen oder Fehler im ResourceManager-Protokoll in /var/log/hadoop-yarn/yarn/hadoop-yarn-resourcemanager-*.log vorliegen

Weitere Informationen finden Sie unter Häufig auftretenden Problemen in Yarn

Schritt 2: Vergleichen Ihrer neuen Anwendungsressourcen mit verfügbaren Yarn-Ressourcen

  1. Wechseln Sie zu Ambari Benutzeroberfläche > YARN > SUMMARY, überprüfen Sie CLUSTERSPEICHER in ServiceMetrics

  2. Überprüfen Sie Yarn-Warteschlangenmetriken in Details:

  • Wechseln Sie zur Yarn-Benutzeroberfläche, überprüfen Sie Yarn-Zeitplanmetriken über https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster/scheduler
  • Alternativ können Sie Yarn-Zeitplanmetriken über yarn Rest-API überprüfen. Beispiel: curl -u "xxxx" -sS -G "https://YOURCLUSTERNAME.azurehdinsight.net/ws/v1/cluster/scheduler". Für ESP sollten Sie den Domänenadministratorbenutzer verwenden.
  1. Berechnen der Gesamtressourcen für Ihre neue Anwendung
  • Alle Executorressourcen: spark.executor.instances * (spark.executor.memory + spark.yarn.executor.memoryOverhead) and spark.executor.instances * spark.executor.cores. Weitere Informationen finden Sie in Spark-Executorkonfiguration
  • ApplicationMaster
    • Im Clustermodus verwenden Sie spark.driver.memory und spark.driver.cores
    • Im Clientmodus verwenden Sie spark.yarn.am.memory+spark.yarn.am.memoryOverhead und spark.yarn.am.cores

Hinweis

yarn.scheduler.minimum-allocation-mb <= spark.executor.memory+spark.yarn.executor.memoryOverhead <= yarn.scheduler.maximum-allocation-mb

  1. Vergleichen Sie Ihre neuen gesamten Anwendungsressourcen mit den verfügbaren yarn-Ressourcen in Ihrer angegebenen Warteschlange

Schritt 3: Nachverfolgen Ihrer Spark-Anwendung

  1. Überwachen Ihrer ausgeführten Spark-Anwendung über die Spark Benutzeroberfläche

  2. Überwachen Ihrer vollständigen oder unvollständigen Spark-Anwendung über Spark History Server-Benutzeroberfläche

Wir müssen die folgenden Symptome über Spark-Benutzeroberfläche oder Spark History-Benutzeroberfläche identifizieren:

  • Welche Phase ist langsam
  • Sind die gesamten CPU-V-Cores des Executors in der Ereigniszeitachse auf der Registerkarte Stage vollständig ausgelastet
  • Wenn Sie Spark Sql verwenden, wie lautet der physische Plan auf der Registerkarte "SQL"
  • Ist der gerichtete azyklische Graph zu lang in einer Phase
  • Beobachten von Aufgabenmetriken (Eingabegröße, Schreibgröße, GC-Zeit) auf der Registerkarte Stage

Weitere Informationen finden Sie unter Monitoring der Spark-Anwendungen

Schritt 4: Optimieren Ihrer Spark-Anwendung

Es gibt zahlreiche Strategien, die Ihnen dabei helfen können, diese Herausforderungen zu meistern. Hierzu zählen beispielsweise das Zwischenspeichern und das Zulassen von Datenschiefe.

Die folgenden Artikel enthalten jeweils Informationen zu verschiedenen Aspekten der Spark-Optimierung:

Optimieren von Spark SQL-Partitionen

  • spark.sql.shuffle.paritions ist standardmäßig 200. Die Daten können je nach den Geschäftsanforderungen angepasst werden, wenn sie für Verknüpfungen oder Aggregationen umgeschichtet werden.
  • spark.sql.files.maxPartitionBytes ist standardmäßig 1G in HDI. Die maximale Anzahl von Bytes, die beim Lesen von Dateien in eine einzelne Partition gepackt werden. Diese Konfiguration ist nur wirksam, wenn dateibasierte Quellen wie Parquet, JSON und ORC verwendet werden.
  • AQE in Spark 3.0. Siehe Ausführung von adaptiven Abfragen

Nächste Schritte