Optimera Apache Spark-program i HDInsight

Den här artikeln innehåller en översikt över strategier för att optimera Apache Spark-program i Azure HDInsight.

Översikt

Du kan stöta på följande vanliga scenarier

Samma Spark-jobb är långsammare än tidigare i samma HDInsight-kluster
Spark-jobbet är långsammare i HDInsight-klustret än en lokal eller annan tredjepartstjänstleverantör
Spark-jobbet är långsammare i ett HDI-kluster än ett annat HDI-kluster

Prestandan för dina Apache Spark-jobb beror på flera faktorer. Dessa prestandafaktorer är:

Hur dina data lagras
Så här konfigureras klustret
De åtgärder som används vid bearbetning av data.
Tjänst för ej felfria garn
Minnesbegränsningar på grund av felaktigt storleksanpassade exekutorer och OutOfMemoryError
För många uppgifter eller för få uppgifter
Datasnedvridning orsakade några tunga uppgifter eller långsamma uppgifter
Uppgifter långsammare i felaktiga noder

Kontrollera om ResourceManager- eller NodeManager-aviseringar
Kontrollera ResourceManager- och NodeManager-status i YARN > SAMMANFATTNING: Alla NodeManager ska vara i Startad och endast Active ResourceManager ska vara i Startad

Kontrollera om Yarn-användargränssnittet är tillgängligt via https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster
Kontrollera om det finns några undantag eller fel i ResourceManager-inloggningen /var/log/hadoop-yarn/yarn/hadoop-yarn-resourcemanager-*.log

Mer information finns i Vanliga problem med Yarn

Gå till Ambari UI YARN SUMMARY (Ambari UI > YARN > SUMMARY) och kontrollera KLUSTERMINNE i ServiceMetrics
Kontrollera yarnkömått i information:

Gå till Yarn-användargränssnittet, kontrollera Yarn Scheduler-mått via https://YOURCLUSTERNAME.azurehdinsight.net/yarnui/hn/cluster/scheduler
Du kan också kontrollera yarn scheduler-mått via Yarn Rest API. Exempel: curl -u "xxxx" -sS -G "https://YOURCLUSTERNAME.azurehdinsight.net/ws/v1/cluster/scheduler" För ESP bör du använda domänadministratörsanvändare.

Alla körresurser: spark.executor.instances * (spark.executor.memory + spark.yarn.executor.memoryOverhead) and spark.executor.instances * spark.executor.cores. Se mer information i spark-körkonfiguration
ApplicationMaster
- I klusterläge använder spark.driver.memory du och spark.driver.cores
- I klientläge använder spark.yarn.am.memory+spark.yarn.am.memoryOverhead du och spark.yarn.am.cores

Kommentar

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

Jämför dina nya resurser för programsumma med tillgängliga yarnresurser i den angivna kön

Vi måste identifiera symptomen nedan via Spark-användargränssnittet eller Spark-historikgränssnittet:

Vilken fas är långsam
Används den totala körprocessorn v-kärnor fullt ut på fliken Händelsetidslinje på fliken Fas
Om du använder Spark SQL, vad är det fysiska planet på SQL-fliken
Är DAG för långt i ett steg
Observera aktivitetsmått (indatastorlek, shuffle-skrivstorlek, GC-tid) på fliken Steg

Det finns många optimeringar som kan hjälpa dig att lösa dessa utmaningar, till exempel cachelagring och tillåta datasnedvridning.

I var och en av följande artiklar hittar du information om olika aspekter av Spark-optimering.

spark.sql.shuffle.partitions är 200 som standard. Vi kan justera baserat på affärsbehoven när du blandar data för kopplingar eller aggregeringar.
spark.sql.files.maxPartitionBytes är 1G som standard i HDI. Det maximala antalet byte som ska packas i en enda partition vid läsning av filer. Den här konfigurationen är endast effektiv när du använder filbaserade källor som Parquet, JSON och ORC.
AQE i Spark 3.0. Se Körning av anpassningsbara frågor