Dela via

Produktionsöverväganden för strukturerad direktuppspelning

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

Databricks rekommenderar att du alltid konfigurerar 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. Detta avser schemaläggningsfunktionen för Azure Databricks Jobs, inte Structured Streaming triggerintervallet.
  • Aktivera inte automatisk skalning för beräkning för strukturerade direktuppspelningsjobb.

Vissa arbetsbelastningar drar nytta av följande:

Azure Databricks har introducerat Lakeflow Spark deklarativa pipeliner för att minska komplexiteten med att hantera produktionsinfrastruktur för arbetsbelastningar inom strukturerad strömning. Databricks rekommenderar att du använder deklarativa Lakeflow Spark-pipelines för nya pipelineprojekt för strukturerad strömmande datahantering. Se Deklarativa pipelines för Lakeflow Spark.

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 Lakeflow Spark Deklarativa pipelines med förbättrad automatisk skalning för strömningsarbetsbelastningar. Se även Optimera klusteranvändningen för Lakeflow Spark deklarativa pipelines med autoskalning.

:::obs Serverlös beräkning

På serverlös beräkning stöds endast Trigger.AvailableNow() och Trigger.Once() . Databricks rekommenderar Trigger.AvailableNow().

För kontinuerlig direktuppspelning vid serverlös beräkning använder du Utlöst kontra kontinuerligt pipelineläge i kontinuerligt läge.

Se Begränsningar för direktuppspelning.

:::

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, kräver 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 erbjuder garantier för minst en gång i stället för exakt en gång. Säkerställ att din bearbetningspipeline är idempotent för dessa åtgärder. Se även Använda foreachBatch för att skriva till godtyckliga datamottagare.

Kommentar

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 prövas ett jobb om 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.

Strategi 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 också tilldela frågor till scheduler-pooler.
Hur hanteras återförsök? Alla uppgifter måste misslyckas innan jobbet omstartar. Uppgiften körs igen om någon sökfrå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ör jobb kontinuerligt.

Den kontinuerliga utlösaren har 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

Databricks rekommenderar att du inte använder streamingQuery.awaitTermination() eller spark.streams.awaitAnyTermination(). Se När du ska använda awaitTermination().

När du ska använda awaitTermination()

streamingQuery.awaitTermination() och spark.streams.awaitAnyTermination() blockerar den aktuella tråden tills en strömmande fråga avslutas. Om du vill använda dessa funktioner beror på din körningsmiljö.

För Databricks-jobb ska du inte använda streamingQuery.awaitTermination() eller spark.streams.awaitAnyTermination(). Dessa funktioner är inte nödvändiga eftersom Jobs service automatiskt förhindrar en körning från att slutföras när en streamingfråga är aktiv. Båda funktionerna blockerar notebook-celler från att slutföras och förhindrar att jobbtjänsten spårar strömningsfrågan, vilket stör kvarvarande mått och jobbmeddelanden.

Använd awaitTermination() i följande fall:

Användningsfall Beteende
Interaktiva anteckningsböcker för generell databehandling awaitTermination() ser till att cellen fortsätter köra, gör att du kan observera frågetillståndet och ser till att problem visas i anteckningsboksresultaten.
Lokala miljöer och utvecklingsmiljöer När du kör ett Spark-program lokalt avslutas processen när huvudtråden är klar. Anropa awaitTermination() för att hålla programmet vid liv tills strömningsfrågan har slutförts eller misslyckats.
Felöverföring till drivrutinen Utan awaitTermination() kan det hända att ett fel i en strömmande frågeprocess i en icke-jobbkontext inte sprids till den anropande tråden. Frågan kan misslyckas tyst, vilket gör fel svårare att identifiera och diagnostisera. Om du anropar awaitTermination() genereras frågefelet på drivrutinen igen.

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

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

Kommentar

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

Mer information om Apache Fair Scheduler-pooler finns i Dokumentation om Apache Fair Scheduler.

  • Last updated on