Köra flera frågor för strukturerad direktuppspelning i samma kluster

Många kunder kör flera frågor om strukturerad direktuppspelning på samma Azure Databricks kluster. Även om det här mönstret stöds rekommenderar Databricks att begränsa antalet frågor per kluster för att undvika skalningsproblem och flaskhalsar i prestanda. Vid serverlös beräkning hanterar Azure Databricks skalning automatiskt, så dessa överväganden hanteras åt dig. Om du använder klassisk beräkning, där du styr drivrutins- och körstorlek, beskriver den här sidan de viktiga flaskhalsar som du bör tänka på och hur du kan åtgärda dem.

När du ska använda flera frågor i samma kluster

Om du kör flera strömningsfrågor i samma kluster minskar infrastrukturkostnaderna, särskilt när du har många små strömmar som inte kräver dedikerad beräkning. Den viktiga kompromissen är delat fel: om klustret misslyckas misslyckas varje ström på det. För verksamhetskritiska pipelines är det gemensamma felläget ofta oacceptabelt.

För arbetsbelastningar som blandar kritiska och icke-kritiska strömmar rekommenderar Databricks följande:

• Tilldela varje ström en prioritet baserat på dess inverkan på verksamheten.
• Placera verksamhetskritiska strömmar på dedikerade kluster, även till högre kostnad.
• Samplacerar strömmar med lägre prioritet för att dela beräkning och minska kostnaderna.

Dimensionering av drivrutin

Drivrutinen är en delad resurs. Flera förfrågningar delar samma CPU, minne, DAG-schemaläggare, uppgiftsschemaläggare och UDF-körning på driversidan (till exempel foreachBatch). När du kör många samtidiga strömmar bör du vara uppmärksam på dessa specifika flaskhalsar utöver standardallokering av CPU och minne:

• Kostnader för automatisk inläsning: Om dina strömmar använder automatisk inläsning ökar filidentifieringen och kataloglistan drivrutinstrycket.
• Resursgränser på OS-nivå (öppna filer): Om du kör en stor mängd filbaserade strömmar (till exempel FileStreamSource eller Automatisk inläsning) samtidigt på en enda drivrutin kan det göra att gränserna för öppna filer på användarnivå överskrids, vilket kan orsaka slumpmässiga strömfel.
• Överbelastning i lyssnarbussen: Ett stort antal samtidiga streamingfrågor kan orsaka överbelastning på den enskilda Spark-sessionens StreamingQueryListener-buss. Alla händelser (inklusive onQueryIdle) skickas till den här enda bussen, och en stor händelsekö kan allvarligt fördröja asynkrona onQueryProgress hanterare och påverka klusterstabiliteten.
• Dyra drivrutinsåtgärder: Undvik att anropa collect() eller andra dyra DataFrame-åtgärder på drivrutinen om det inte är absolut nödvändigt, för att undvika materialisering av stora resultatuppsättningar och orsaka OOM-fel (out-of-memory).

Felsöka drivrutinskonflikter

Om du upplever drivrutinskrascher på grund av OOM eller konkurrensproblem:

1. Övervaka drivrutinsmått i Spark-användargränssnittet. Om du ser hög processor-, minnes- eller diskanvändning justerar du drivrutinsstorleken i inställningarna för klusterberäkning.
2. Om problemet kvarstår kontrollerar du att koden inte kör minnesintensiva åtgärder eller UDF:er på drivrutinen.
3. Om du inte kan skala drivrutinen vertikalt ytterligare rekommenderar Databricks starkt att du delar upp dina jobb i flera kluster för att kringgå dessa flaskhalsar för skalning av delade noder.

Exekverarens storlek

När flera frågekörningar körs i samma kluster delar de på alla uppgiftsplatser på exekverarna. Steg från en fråga kan uppta tillgängliga platser, vilket leder till fördröjningar och svält för andra frågor. Spark använder en 1:1-mappning mellan aktivitetsfack och tillgängliga kärnor. Se till att det finns tillräckligt med kärnor tillgängliga om frågor måste köras samtidigt.

Generellt kan exekverare utföra mer minnesintensiva åtgärder än drivnoden. Justera JVM- och off-heap-minnesallokeringsparametrarna om det behövs för att hantera programbelastningen. Se till att körnoderna har rätt storlek när det gäller PROCESSOR, minne och diskutrymme och skala lodrätt om det behövs. Om vertikal skalning inte är möjlig kan du överväga att lägga till ytterligare arbetsnoder i klustret.

Använd schemaläggarpooler

Du kan konfigurera scheduler-pooler för att tilldela beräkningskapacitet till frågor när du kör flera strömmande frågor från samma källkod.

Som standardläge körs alla frågor som startas i en anteckningsbok i samma rättvisa schemaläggningspool. Apache Spark-jobb som genereras av utlösare från alla strömningsfrågor i en notebook körs en i taget i ordningen "först in, först ut" (FIFO). Detta kan orsaka onödiga fördröjningar i frågorna eftersom de inte effektivt delar klusterresurserna.

Med Scheduler-pooler kan du deklarera vilka strukturerade strömningsfrågor som delar beräkningsresurser.

I följande exempel tilldelas query1 till en dedikerad pool, medan query2 och query3 delar en scheduler-pool.

# Run streaming query1 in scheduler pool1
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool1")
df.writeStream.queryName("query1").toTable("table1")

# Run streaming query2 in scheduler pool2
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool2")
df.writeStream.queryName("query2").toTable("table2")

# Run streaming query3 in scheduler pool2
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool2")
df.writeStream.queryName("query3").toTable("table3")

Mer information om fair scheduler-pooler finns i dokumentationen för Apache Spark Fair Scheduler.

Överväganden för tillståndsbevarande frågor

Tänk på följande för tillståndskänsliga frågor som körs i samma kluster:

• Använd RocksDB som tillståndslagerprovider för att undvika OOM-problem och GC-pauser. RocksDB är standardtillståndslagringsprovidern i Databricks Runtime 17.3 och senare. Se Konfigurera RocksDB tillståndslagring i Azure Databricks.
• Justera shuffle-partitioner för dina programkrav. För tillståndskänsliga steg schemalägger Spark aktiviteter som är proportionella mot antalet shuffle-partitioner.
• Begränsa RocksDB:s minnesanvändning per nod för att undvika OOM-fel från minnesanvändning utanför heapen. Detta hanteras automatiskt i Databricks Runtime 17.3 och senare, men kräver manuell konfiguration i tidigare versioner. Se Cap RocksDB-minnesanvändning.
• Undvik att packa för många partitioner på samma körnod. Underhållsåtgärder i tillståndslagret, inklusive uppladdning av ögonblicksbilder och rensning, utförs per nod. Att tilldela för många partitioner till en exekveringsnod kan leda till att underhållet blir eftersatt och att återställningstiderna blir längre, eftersom det då finns färre fullständiga snapshots tillgängliga.