Dela via

Vägledning för prestandajustering för Spark i HDInsight och Azure Data Lake Storage Gen1

  • Artikel

När du justerar prestanda på Spark måste du överväga antalet appar som ska köras i klustret. Som standard kan du köra fyra appar samtidigt i HDI-klustret (Obs! standardinställningen kan komma att ändras). Du kan välja att använda färre appar så att du kan åsidosätta standardinställningarna och använda mer av klustret för dessa appar.

Förutsättningar

Parametrar

När du kör Spark-jobb, här är de viktigaste inställningarna som kan justeras för att öka prestanda på Data Lake Storage Gen1:

  • Num-executors – antalet samtidiga uppgifter som kan köras.

  • Executor-memory – mängden minne som allokeras till varje utförare.

  • Executor-cores – antalet kärnor som allokerats till varje utförare.

Num-executors Num-executors anger det maximala antalet aktiviteter som kan köras parallellt. Det faktiska antalet aktiviteter som kan köras parallellt begränsas av det minne och de CPU-resurser som är tillgängliga i klustret.

Körminne Det här är mängden minne som allokeras till varje utförare. Det minne som behövs för varje utförare är beroende av jobbet. För komplexa åtgärder måste minnet vara högre. För enkla åtgärder som läsning och skrivning blir minneskraven lägre. Mängden minne för varje utförare kan visas i Ambari. I Ambari navigerar du till Spark och visar fliken Konfigurationer .

Executor-cores Detta anger mängden kärnor som används per köre, vilket avgör antalet parallella trådar som kan köras per köre. Om till exempel executor-cores = 2 kan varje utförare köra två parallella uppgifter i kören. De körkärnor som behövs är beroende av jobbet. I/O-tunga jobb kräver inte mycket minne per uppgift, så varje utförare kan hantera mer parallella uppgifter.

Som standard definieras två virtuella YARN-kärnor för varje fysisk kärna när du kör Spark på HDInsight. Det här talet ger en bra balans mellan samtidighet och mängden kontextväxling från flera trådar.

Vägledning

När du kör Spark-analysarbetsbelastningar för att arbeta med data i Data Lake Storage Gen1 rekommenderar vi att du använder den senaste HDInsight-versionen för att få bästa möjliga prestanda med Data Lake Storage Gen1. När jobbet är mer I/O-intensivt kan vissa parametrar konfigureras för att förbättra prestanda. Data Lake Storage Gen1 är en mycket skalbar lagringsplattform som kan hantera högt dataflöde. Om jobbet huvudsakligen består av läsning eller skrivningar kan ökad samtidighet för I/O till och från Data Lake Storage Gen1 öka prestandan.

Det finns några allmänna sätt att öka samtidigheten för I/O-intensiva jobb.

Steg 1: Avgör hur många appar som körs i klustret – Du bör veta hur många appar som körs i klustret, inklusive det aktuella. Standardvärdena för varje Spark-inställning förutsätter att det finns 4 appar som körs samtidigt. Därför har du bara 25 % av klustret tillgängligt för varje app. För att få bättre prestanda kan du åsidosätta standardinställningarna genom att ändra antalet utförare.

Steg 2: Ange executor-memory – det första du ska ange är executor-memory. Minnet kommer att vara beroende av det jobb som du ska köra. Du kan öka samtidigheten genom att allokera mindre minne per köre. Om du får slut på minnesfel när du kör jobbet bör du öka värdet för den här parametern. Ett alternativ är att få mer minne genom att använda ett kluster som har högre mängder minne eller öka storleken på klustret. Mer minne gör att fler utförare kan användas, vilket innebär mer samtidighet.

Steg 3: Ange körkärnor – För I/O-intensiva arbetsbelastningar som inte har komplexa åtgärder är det bra att börja med ett stort antal executor-kärnor för att öka antalet parallella uppgifter per utförare. Det är en bra början att ställa in executor-cores på 4.

executor-cores = 4

Om du ökar antalet executor-cores får du mer parallellitet så att du kan experimentera med olika executor-cores. För jobb som har mer komplexa åtgärder bör du minska antalet kärnor per utförare. Om executor-cores har angetts som högre än 4 kan skräpinsamling bli ineffektiv och försämra prestanda.

Steg 4: Fastställa mängden YARN-minne i klustret – Den här informationen är tillgänglig i Ambari. Gå till YARN och visa fliken Contigs. YARN-minnet visas i det här fönstret. Observera när du är i fönstret, du kan också se standardstorleken för YARN-containern. YARN-containerns storlek är samma som minne per körparameter.

Totalt YARN-minne = noder * YARN-minne per nod

Steg 5: Beräkna num-executors

Beräkna minnesbegränsning – parametern num-executors begränsas antingen av minne eller cpu. Minnesbegränsningen bestäms av mängden tillgängligt YARN-minne för ditt program. Ta det totala YARN-minnet och dividera det med executor-memory. Begränsningen måste avskalas för antalet appar, så vi delar upp med antalet appar.

Minnesbegränsning = (totalt YARN-minne/körminne)/antal appar

Beräkna CPU-begränsning – CPU-begränsningen beräknas som det totala antalet virtuella kärnor dividerat med antalet kärnor per utförare. Det finns två virtuella kärnor för varje fysisk kärna. Precis som minnesbegränsningen har vi dividerat med antalet appar.

virtual cores = (noder i klustret * antal fysiska kärnor i noden * 2) CPU-begränsning = (totalt antal virtuella kärnor/antal kärnor per utförare) / antal appar

Ange num-executors – parametern num-executors bestäms genom att ta det minsta av minnesbegränsningen och CPU-begränsningen.

num-executors = Min (totalt antal virtuella kärnor/antal kärnor per executor, tillgängligt YARN-minne/executor-memory) Om du anger ett högre antal num-executors ökar inte nödvändigtvis prestandan. Du bör överväga att lägga till fler utförare ger extra omkostnader för varje ytterligare utförare, vilket potentiellt kan försämra prestanda. Num-executors begränsas av klusterresurserna.

Exempelberäkning

Anta att du för närvarande har ett kluster som består av 8 D4v2-noder som kör två appar, inklusive den som du ska köra.

Steg 1: Avgör hur många appar som körs i klustret – du vet att du har två appar i klustret, inklusive de som du ska köra.

Steg 2: Ange executor-memory – i det här exemplet fastställer vi att 6 GB körminne räcker för I/O-intensivt jobb.

executor-memory = 6GB

Steg 3: Ange executor-cores – Eftersom det här är ett I/O-intensivt jobb kan vi ange antalet kärnor för varje utförare till fyra. Om kärnor per köre anges till större än fyra kan det orsaka problem med skräpinsamlingen.

executor-cores = 4

Steg 4: Fastställa mängden YARN-minne i klustret – Vi går till Ambari för att ta reda på att varje D4v2 har 25 GB YARN-minne. Eftersom det finns 8 noder multipliceras det tillgängliga YARN-minnet med 8.

Totalt YARN-minne = noder * YARN-minne* per nod Totalt YARN-minne = 8 noder * 25 GB = 200 GB

Steg 5: Beräkna num-executors – parametern num-executors bestäms genom att ta det minsta antalet minnesbegränsningar och CPU-begränsningen dividerat med antalet appar som körs på Spark.

Beräkna minnesbegränsning – Minnesbegränsningen beräknas som det totala YARN-minnet dividerat med minnet per köre.

Minnesbegränsning = (totalt YARN-minne/körminne) /# för appar Minnesbegränsning = (200 GB/6 GB) / 2 Minnesbegränsning = 16 (avrundat) Beräkna CPU-villkor – CPU-begränsningen beräknas som det totala antalet garnkärnor dividerat med antalet kärnor per utförare.

YARN-kärnor = noder i kluster * antal kärnor per nod * 2 YARN-kärnor = 8 noder * 8 kärnor per D14 * 2 = 128 CPU-begränsning = (totalt YARN-kärnor/ antal kärnor per utförare) / antal appar CPU-begränsning = (128 / 4) / 2 CPU-begränsning = 16

Ange num-executors

num-executors = Min (minnesbegränsning, CPU-begränsning) num-executors = Min (16, 16) num-executors = 16