Dela via

Produktionsöverväganden för strukturerad direktuppspelning

  • Artikel

Den här artikeln innehåller rekommendationer för schemaläggning av strukturerade strömningsarbetsbelastningar med hjälp av jobb i Azure Databricks.

Databricks rekommenderar att du alltid gör följande:

  • Ta bort onödig kod från notebook-filer som returnerar resultat, till exempel display och count.
  • Kör inte strukturerade strömningsarbetsbelastningar med generella beräkningsresurser. Schemalägg alltid strömmar som jobb med jobbberäkning.
  • Schemalägg jobb med hjälp av Continuous läge.
  • Aktivera inte automatisk skalning för beräkning för strukturerade direktuppspelningsjobb.

Vissa arbetsbelastningar drar nytta av följande:

Azure Databricks har introducerat DLT för att minska komplexiteten i hanteringen av produktionsinfrastrukturen för strukturerade strömningsarbetsbelastningar. Databricks rekommenderar att du använder DLT för nya pipelines för strukturerad direktuppspelning. Se Vad är DLT?.

Kommentar

Automatisk skalning av beräkningskraft har begränsningar för att skala ned klusterstorleken för strukturerad strömmande arbetsbelastning. Databricks rekommenderar att du använder DLT med förbättrad automatisk skalning för strömningsarbetsbelastningar. Se Optimera klusteranvändningen av DLT-pipelines med förbättrad automatisk skalning.

Utforma strömmande arbetsflöden med beredskap för fel

Databricks rekommenderar att du alltid konfigurerar direktuppspelningsjobb för att automatiskt starta om vid fel. Vissa funktioner, inklusive schemautveckling, förutsätter att strukturerade strömningsarbetsbelastningar konfigureras för att försöka igen automatiskt. Se Konfigurera strukturerade strömmande jobb för att starta om strömmande frågor vid fel.

Vissa åtgärder som foreachBatch ger minst en gång i stället för exakt en gång garantier. För dessa operationer bör du se till att din bearbetningspipeline är idempotent. Se även Använda foreachBatch för att skriva till godtyckliga datamottagare.

Anteckning

När en fråga startas om, bearbetas mikrobatchen som planerades under föregående körning. Om jobbet misslyckades på grund av ett minnesfel eller om du avbröt ett jobb manuellt på grund av en överdimensionerad mikrobatch kan du behöva skala upp beräkningen för att kunna bearbeta mikrobatchen.

Om du ändrar konfigurationer mellan körningar gäller dessa konfigurationer för den första nya batchen som planeras. Se Återställning efter ändringar i en Structured Streaming-fråga.

När försöker ett jobb igen?

Du kan schemalägga flera aktiviteter som en del av ett Azure Databricks-jobb. När du konfigurerar ett jobb med den kontinuerliga utlösaren kan du inte ange beroenden mellan aktiviteter.

Du kan välja att schemalägga flera strömmar i ett enda jobb med någon av följande metoder:

  • Flera uppgifter: Definiera ett jobb med flera aktiviteter som kör strömmande arbetsbelastningar med hjälp av den kontinuerliga utlösaren.
  • Flera frågor: Definiera flera strömmande frågor i källkoden för en enda uppgift.

Du kan också kombinera dessa strategier. I följande tabell jämförs dessa metoder.

Flera uppgifter Flera frågor
Hur delas datorkapacitet? Databricks rekommenderar att du distribuerar jobb med lämplig storlek för varje direktuppspelningsaktivitet. Du kan också dela beräkning mellan aktiviteter. Alla frågor delar samma beräkning. Du kan välja att tilldela frågor till scheduler-pooler.
Hur hanteras återförsök? Alla uppgifter måste misslyckas innan jobbet omstartar. Uppgiften försöker igen om någon fråga misslyckas.

Konfigurera strukturerade strömningsjobb för att återstarta strömmande frågor vid fel

Databricks rekommenderar att du ställer in alla strömningsarbetsbelastningar med hjälp av den kontinuerliga utlösaren. Se Köra jobb kontinuerligt.

Den kontinuerliga utlösaren tillhandahåller följande beteende som standard:

  • Förhindrar mer än en samtidig körning av jobbet.
  • Startar en ny körning när en tidigare körning misslyckas.
  • Använder den exponentiella "backoff"-metoden för återförsök.

Databricks rekommenderar att du alltid använder jobbberäkning i stället för all-purpose compute när du schemalägger arbetsflöden. Vid jobbfel och återförsök distribueras nya beräkningsresurser.

Kommentar

Du behöver inte använda streamingQuery.awaitTermination() eller spark.streams.awaitAnyTermination(). Jobb förhindrar automatiskt att en körning slutförs när en strömmande fråga är aktiv.

Använd schemaläggningspooler för flera strömmande förfrågningar

Du kan konfigurera schemapooler 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 triggers från alla strömmande frågor i en anteckningsbok körs en efter en i FIFO-ordning (först in, först ut). 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 schemaläggarpool.

# 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")

Anmärkning

Den lokala egenskapskonfigurationen måste finnas i samma notebook-cell där du startar din streamingfråga.

Mer information finns i dokumentationen för Apache Fair Scheduler.