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 all användningsberäkning. 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 Delta Live Tables för att minska komplexiteten i hanteringen av produktionsinfrastrukturen för strukturerade strömningsarbetsbelastningar. Databricks rekommenderar att du använder Delta Live Tables för nya pipelines för strukturerad direktuppspelning. Se Vad är Delta Live Tables?.

Kommentar

Automatisk skalning av beräkning har begränsningar för att skala ned klusterstorleken för arbetsbelastningar med strukturerad direktuppspelning. Databricks rekommenderar att du använder Delta Live Tables med förbättrad automatisk skalning för strömningsarbetsbelastningar. Se Optimera klusteranvändningen för Delta Live Tables-pipelines med förbättrad autoskalning.

Utforma strömmande arbetsbelastningar för att förvänta sig 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 direktuppspelningsjobb 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 åtgärder bör du göra så att din bearbetningspipeline är idempotent. Se Använda foreachBatch för att skriva till godtyckliga datamottagare.

Kommentar

När en fråga startas om planeras mikrobatchen under föregående körningsprocesser. 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älla efter ändringar i en fråga för strukturerad direktuppspelning.

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 beräkning? 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 aktiviteter måste misslyckas innan jobbet försöker igen. Uppgiften försöker igen om någon fråga misslyckas.

Konfigurera strukturerade direktuppspelningsjobb för att starta om strömmande frågor vid fel

Databricks rekommenderar att du konfigurerar alla strömmande arbetsbelastningar 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 exponentiell backoff 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ända scheduler-pooler för flera strömmande frågor

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 standard startades alla frågor i en notebook-fil som körs i samma rättvis schemaläggningspool. Apache Spark-jobb som genereras av utlösare från alla strömmande frågor i en notebook-fil 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")

Kommentar

Den lokala egenskapskonfigurationen måste finnas i samma notebook-cell där du startar strömningsfrågan.

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