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 lokalt eller någon 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.
- Yarn-tjänsten med feltillstånd
- Minnesbegränsningar på grund av felaktigt storleksanpassade utförare och OutOfMemoryError
- För många uppgifter eller för få aktiviteter
- Dataskevhet orsakade några tunga uppgifter eller långsamma uppgifter
- Aktiviteter långsammare i felaktiga noder
Steg 1: Kontrollera om yarn-tjänsten är felfri
- Gå till Ambari-användargränssnittet:
- 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
Steg 2: Jämför dina nya programresurser med yarn-tillgängliga resurser
Gå till Ambari UI YARN SUMMARY (Ambari UI > YARN-sammanfattning>) och kontrollera KLUSTERMINNE i ServiceMetrics
Kontrollera Yarn-kömåtten 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. Till 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.
- Beräkna totalt antal resurser för det nya programmet
- Alla utförarresurser:
spark.executor.instances * (spark.executor.memory + spark.yarn.executor.memoryOverhead) and spark.executor.instances * spark.executor.cores
. Se mer information i konfigurationen av Spark-utförare - ApplicationMaster
- I klusterläge använder
spark.driver.memory
du ochspark.driver.cores
- I klientläge använder
spark.yarn.am.memory+spark.yarn.am.memoryOverhead
du ochspark.yarn.am.cores
- I klusterläge använder
Anteckning
yarn.scheduler.minimum-allocation-mb <= spark.executor.memory+spark.yarn.executor.memoryOverhead <= yarn.scheduler.maximum-allocation-mb
- Jämför det totala antalet resurser för ditt nya program med yarn-tillgängliga resurser i den angivna kön
Steg 3: Spåra ditt Spark-program
Övervaka spark-programmet som körs via Spark-användargränssnittet
Övervaka ditt fullständiga eller ofullständiga Spark-program via Spark-historikservergränssnittet
Vi måste identifiera nedanstående symptom via Spark-användargränssnittet eller användargränssnittet för Spark-historik:
- Vilken fas som är långsam
- Används processor v-kärnorna för den totala körningen fullt ut i Event-Timeline på fliken Fas
- Om du använder Spark SQL, vad är den fysiska planen på sql-fliken
- Är DAG för lång i ett steg
- Observera aktivitetsmått (indatastorlek, blandningsskrivningsstorlek, GC-tid) på fliken Fas
Mer information finns i Övervaka dina Spark-program
Steg 4: Optimera spark-programmet
Det finns många optimeringar som kan hjälpa dig att lösa dessa utmaningar, till exempel cachelagring och tillåta snedställning av data.
I var och en av följande artiklar hittar du information om olika aspekter av Spark-optimering.
- Optimera datalagring för Apache Spark
- Optimera databearbetning för Apache Spark
- Optimera minnesanvändningen för Apache Spark
- Optimera HDInsight-klusterkonfigurationen för Apache Spark
Optimera Spark SQL-partitioner
-
spark.sql.shuffle.paritions
är 200 som standard. Vi kan justera baserat på affärsbehoven när vi 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 Anpassningsbar frågekörning