Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Den här sidan förklarar hur du använder antagningskontroller för att upprätthålla en konsekvent batchstorlek för strömmande frågor.
Antagningskontroller begränsar indatahastigheten för strukturerade strömningsfrågor, vilket kan bidra till att upprätthålla en konsekvent batchstorlek och förhindra att stora batchar orsakar spill och sammanhängande fördröjningar i bearbetningen av mikrobatch.
Azure Databricks har samma alternativ för att styra batchstorlekar för strukturerad direktuppspelning för både Delta Lake och Auto Loader.
Anmärkning
Du kan ändra inställningarna för inträdeskontroll utan att återställa kontrollpunkten för en streamingfråga. Se Återställning efter ändringar i en Structured Streaming-fråga.
Att ändra inställningar för antagningskontroll för att öka eller minska batchstorleken har prestandakonsekvenser. För att optimera arbetsbelastningen kan du behöva justera dina beräkningskonfigurationer.
Varning
Om en mikrobatch planeras när en dataström stoppas träder inga ändringar av antagningskontrollerna i kraft förrän den planerade mikrobatchen har slutförts. När en dataström till exempel stoppas efter en misslyckad transaktion kan du behöva ta bort kontrollpunkten för att tvinga dataströmmen att bearbeta transaktionen igen med de nya antagningskontrollerna. Det här beteendet beror på att Structured Streaming är idempotent och mikrobatcher måste innehålla samma data vid upprepade körningar. Se semantiken för Structured Streaming.
Begränsa indatahastigheten med maxFilesPerTrigger
Inställningen maxFilesPerTrigger (eller cloudFiles.maxFilesPerTrigger för automatisk inläsning) anger en övre gräns för antalet filer som bearbetas i varje mikrobatch. För både Delta Lake och Auto Loader är standardvärdet 1 000. (Observera att det här alternativet också finns i Apache Spark för andra filkällor, där det inte finns något maxvärde som standard.)
Begränsa indatahastigheten med maxBytesPerTrigger
Om du ställer in maxBytesPerTrigger (eller cloudFiles.maxBytesPerTrigger för automatisk inläsning) anges ett "mjukt maxvärde" för mängden data som bearbetas i varje mikrobatch. Det innebär att en batch bearbetar ungefär den här mängden data och kan bearbeta mer än gränsen för att få strömningsfrågan att gå framåt i de fall då den minsta indataenheten är större än den här gränsen. Det finns inget standardvärde för den här inställningen.
Om du till exempel anger en bytesträng, till exempel 10g för att begränsa varje mikrobatch till 10 GB data och du har filer som är 3 GB vardera, bearbetar Azure Databricks 12 GB i en mikrobatch.
Ställa in flera indatafrekvenser tillsammans
Om du använder maxBytesPerTrigger tillsammans med maxFilesPerTriggerfortsätter mikrobatchen att bearbeta data tills den lägre gränsen för antingen maxFilesPerTrigger eller maxBytesPerTriggernås.
Begränsa indatafrekvenser för andra strukturerade direktuppspelningskällor
Strömmande källor, till exempel Apache Kafka, har anpassade indatagränser, till exempel maxOffsetsPerTrigger. Mer information finns i standardanslutningar i Lakeflow Connect.