Delen via

Productieoverwegingen voor gestructureerd streamen

  • Artikel

Dit artikel bevat aanbevelingen voor het plannen van structured streaming-workloads met behulp van taken in Azure Databricks.

Databricks raadt altijd het volgende aan:

  • Verwijder overbodige code uit notebooks die resultaten opleveren, zoals display en count.
  • Voer geen Structured Streaming-workloads uit met behulp van berekeningen voor alle doeleinden. Plan altijd streams als taken met behulp van taken berekenen.
  • Taken plannen met behulp van Continuous de modus.
  • Schakel automatisch schalen niet in voor berekeningen voor structured streaming-taken.

Sommige workloads profiteren van het volgende:

Azure Databricks heeft Delta Live Tables geïntroduceerd om de complexiteit van het beheren van productie-infrastructuur voor structured streaming-workloads te verminderen. Databricks raadt het gebruik van Delta Live Tables aan voor nieuwe structured streaming-pijplijnen. Zie Wat is Delta Live Tables?

Notitie

Automatisch schalen van berekeningen heeft beperkingen bij het omlaag schalen van clustergrootte voor structured streaming-workloads. Databricks raadt het gebruik van Delta Live Tables aan met verbeterde automatische schaalaanpassing voor streamingworkloads. Zie Het clustergebruik van Delta Live Tables-pijplijnen optimaliseren met verbeterde automatische schaalaanpassing.

Streamingworkloads ontwerpen om fouten te verwachten

Databricks raadt aan altijd streamingtaken te configureren om automatisch opnieuw op te starten bij fouten. Bij sommige functies, waaronder de ontwikkeling van schema's, wordt ervan uitgegaan dat Structured Streaming-workloads zijn geconfigureerd om het automatisch opnieuw te proberen. Zie Structured Streaming-taken configureren om streamingquery's opnieuw op te starten bij fouten.

Sommige bewerkingen bieden foreachBatch ten minste één keer in plaats van exactly-oncegaranties. Voor deze bewerkingen moet u ervoor zorgen dat uw verwerkingspijplijn idempotent is. Zie foreachBatch gebruiken om naar willekeurige gegevens-sinks te schrijven.

Notitie

Wanneer een query opnieuw wordt opgestart, wordt de microbatch gepland tijdens de vorige uitvoeringsprocessen. Als uw taak is mislukt vanwege een fout met onvoldoende geheugen of als u een taak handmatig hebt geannuleerd vanwege een oversized microbatch, moet u de rekenkracht mogelijk omhoog schalen om de microbatch te verwerken.

Als u configuraties tussen uitvoeringen wijzigt, zijn deze configuraties van toepassing op de eerste nieuwe batch die is gepland. Zie Herstellen na wijzigingen in een Structured Streaming-query.

Wanneer wordt een taak opnieuw geprobeerd?

U kunt meerdere taken plannen als onderdeel van een Azure Databricks-taak. Wanneer u een taak configureert met behulp van de continue trigger, kunt u geen afhankelijkheden tussen taken instellen.

U kunt ervoor kiezen om meerdere streams in één taak te plannen met behulp van een van de volgende methoden:

  • Meerdere taken: Definieer een taak met meerdere taken die streamingworkloads uitvoeren met behulp van de continue trigger.
  • Meerdere query's: Definieer meerdere streamingquery's in de broncode voor één taak.

U kunt deze strategieën ook combineren. In de volgende tabel worden deze benaderingen vergeleken.

Meerdere taken Meerdere query's
Hoe wordt compute gedeeld? Databricks raadt aan taken te implementeren die de juiste grootte hebben voor elke streamingtaak. U kunt eventueel berekeningen delen tussen taken. Alle query's delen dezelfde rekenkracht. U kunt optioneel query's toewijzen aan scheduler-pools.
Hoe worden nieuwe pogingen verwerkt? Alle taken moeten mislukken voordat de taak opnieuw wordt geprobeerd. De taak wordt opnieuw geprobeerd als een query mislukt.

Gestructureerde streamingtaken configureren om streamingquery's opnieuw te starten bij een fout

Databricks raadt aan om alle streamingworkloads te configureren met behulp van de continue trigger. Zie Taken uitvoeren continu.

De continue trigger biedt standaard het volgende gedrag:

  • Hiermee voorkomt u dat meer dan één gelijktijdige uitvoering van de taak wordt uitgevoerd.
  • Start een nieuwe uitvoering wanneer een vorige uitvoering mislukt.
  • Gebruikt exponentieel uitstel voor nieuwe pogingen.

Databricks raadt aan om altijd taken te gebruiken in plaats van rekenkracht voor alle doeleinden bij het plannen van werkstromen. Bij taakfouten en nieuwe pogingen worden nieuwe rekenresources geïmplementeerd.

Notitie

U hoeft deze niet te gebruiken streamingQuery.awaitTermination() of spark.streams.awaitAnyTermination(). Taken verhinderen automatisch dat een uitvoering wordt voltooid wanneer een streamingquery actief is.

Scheduler-pools gebruiken voor meerdere streamingquery's

U kunt planningsgroepen configureren om rekencapaciteit toe te wijzen aan query's bij het uitvoeren van meerdere streamingquery's vanuit dezelfde broncode.

Standaard worden alle query's gestart in een notebook die in dezelfde eerlijke planningsgroep worden uitgevoerd. Apache Spark-taken die worden gegenereerd door triggers van alle streamingquery's in een notebook, worden na elkaar uitgevoerd in fifo-volgorde (first in, first out). Dit kan onnodige vertragingen in de query's veroorzaken, omdat ze de clusterbronnen niet efficiënt delen.

Met Scheduler-pools kunt u declareren welke Structured Streaming-query's rekenresources delen.

In het volgende voorbeeld wordt query1 een toegewezen pool toegewezen, terwijl query2 een query3 scheduler-pool wordt gedeeld.

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

Notitie

De configuratie van de lokale eigenschap moet zich in dezelfde notebookcel bevinden waar u de streamingquery start.

Zie de documentatie van Apache Fair Scheduler voor meer informatie.