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-varningar
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 och kontrollera CLUSTER MEMORY i ServiceMetrics.
Kontrollera Yarn kö-mätvärden i detalj:

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-exekveringskonfiguration
ApplicationMaster
- I klusterläge använder du spark.driver.memory och spark.driver.cores
- I klientläge, använd spark.yarn.am.memory+spark.yarn.am.memoryOverhead och spark.yarn.am.cores

Anteckning

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

Jämför applikationens totala resurser med tillgängliga YARN-resurser 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 de totala CPU v-kärnorna för exekveraren fullt ut i Händelsetidslinje-fliken på fliken Fas
Använder du Spark SQL, vad är det fysiska utförandet i 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 vi omordnar 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

Var den här sidan till hjälp?