Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
I den här artikeln beskrivs hur du optimerar konfigurationen av ditt Apache Spark-kluster för bästa prestanda i Azure HDInsight.
Översikt
Om du har långsamma jobb på en koppling eller shuffle är orsaken förmodligen dataskevhet. Dataförskjutning är asymmetri i dina jobbdata. Ett kartjobb kan till exempel ta 20 sekunder. Men det tar timmar att köra ett jobb där data kopplas till eller blandas. Om du vill åtgärda datasnedvridning bör du salta hela nyckeln eller använda ett isolerat salt för endast en delmängd nycklar. Om du använder ett isolerat salt bör du filtrera ytterligare för att isolera din delmängd av saltade nycklar i kartkopplingar. Ett annat alternativ är att introducera en bucketkolumn och föraggregera i bucketar först.
En annan faktor som orsakar långsamma kopplingar kan vara kopplingstypen. Som standard använder Spark kopplingstypen SortMerge . Den här typen av koppling passar bäst för stora datamängder. Men är annars beräkningsmässigt dyrt eftersom det först måste sortera vänster och höger sida av data innan de slås samman.
En Broadcast koppling passar bäst för mindre datamängder, eller där den ena sidan av kopplingen är mycket mindre än den andra sidan. Den här typen av koppling sänder en sida till alla utförare och kräver därför mer minne för sändningar i allmänhet.
Du kan ändra kopplingstypen i konfigurationen genom att ange spark.sql.autoBroadcastJoinThreshold, eller så kan du ange ett kopplingstips med hjälp av DataFrame-API:erna (dataframe.join(broadcast(df2))).
// Option 1
spark.conf.set("spark.sql.autoBroadcastJoinThreshold", 1*1024*1024*1024)
// Option 2
val df1 = spark.table("FactTableA")
val df2 = spark.table("dimMP")
df1.join(broadcast(df2), Seq("PK")).
createOrReplaceTempView("V_JOIN")
sql("SELECT col1, col2 FROM V_JOIN")
Om du använder bucketade tabeller har du en tredje kopplingstyp, Merge kopplingen. En korrekt förpartitionerad och försorterad datauppsättning hoppar över den dyra sorteringsfasen från en SortMerge koppling.
Ordningen på kopplingar är viktig, särskilt i mer komplexa frågor. Börja med de mest selektiva kopplingarna. Flytta kopplingar som ökar antalet rader efter aggregeringar när det är möjligt.
Om du vill hantera parallellitet för kartesiska kopplingar kan du lägga till kapslade strukturer, fönster och kanske hoppa över ett eller flera steg i ditt Spark-jobb.
Optimera jobbhantering
- Cachea vid behov, till exempel om du använder data två gånger, cachea dem.
- Sända variabler till alla utförare. Variablerna serialiseras bara en gång, vilket resulterar i snabbare sökningar.
- Använd trådpoolen på drivrutinsnivå, vilket resulterar i snabbare operationer för många uppgifter.
Övervaka dina pågående jobb regelbundet för att upptäcka prestandaproblem. Om du behöver mer insikt i vissa problem bör du överväga något av följande verktyg för prestandaprofilering:
- Intel PAL-verktyget övervakar processor-, lagrings- och nätverksbandbreddsanvändning.
- Oracle Java 8 Mission Control profilerar Spark och executor.
Nyckeln till Spark 2.x-frågeprestanda är Tungsten-motorn, som är beroende av helstegs-kodgenerering. I vissa fall kan kodgenereringen i hela fasen inaktiveras. Om du till exempel använder en icke-föränderlig typ (string) i aggregeringsuttrycket SortAggregate visas i stället för HashAggregate. Om du till exempel vill ha bättre prestanda kan du prova följande och sedan återaktivera kodgenereringen:
MAX(AMOUNT) -> MAX(cast(AMOUNT as DOUBLE))