Konfigurace intervalů spuštění strukturovaného streamování

Apache Spark Structured Streaming zpracovává data přírůstkově. Intervaly aktivačních událostí určují, jak často strukturované streamování kontroluje nová data. Intervaly aktivačních událostí můžete nakonfigurovat pro zpracování téměř v reálném čase, pro plánované aktualizace databáze nebo dávkové zpracování všech nových dat za den nebo týden.

Vzhledem k tomu, že Auto Loader používá strukturované streamování k načítání dat, pochopení, jak triggery fungují, nabízí největší flexibilitu pro řízení nákladů při ingestování dat s požadovanou frekvencí.

Důležité

Azure Databricks doporučuje nastavit režim triggeru, který vyrovnává latenci a náklady na váš případ použití. V opačném případě se můžou od poskytovatele cloudu zobrazit neočekávané náklady na úložiště. Podrobnosti najdete v tématu Řízení nákladů na cloudové úložiště .

Přehled režimů spouštění

Následující tabulka shrnuje režimy aktivačních událostí dostupné ve strukturovaném streamování:

Režim triggeru	Příklad syntaxe (Python)	Nejlepší pro
Neurčené (výchozí)	N/A	Streamování pro obecné účely s latencí 3 až 5 sekund Ekvivalent spouštěče processingTime s intervalem 0 ms. Zpracování datových proudů běží nepřetržitě, dokud dorazí nová data.
Doba zpracování	.trigger(processingTime='10 seconds')	Vyrovnávání nákladů a výkonu Snižuje režijní náklady tím, že brání systému v příliš častém kontrolování dat.
Nyní k dispozici	.trigger(availableNow=True)	Plánované přírůstkové dávkové zpracování. Zpracovává tolik dat, kolik je k dispozici v době, kdy se úloha streamování aktivuje.
Režim v reálném čase	.trigger(realTime='5 minutes')	Provozní úlohy s ultra nízkou latencí vyžadující zpracování podsekundy, jako je detekce podvodů nebo přizpůsobení v reálném čase. Veřejná ukázka. 5 minut označuje délku mikrodávkové dávky. Využijte pět minut k minimalizaci režijních nákladů na jednotlivé dávky, jako je kompilace dotazů.
Nepřetržité	.trigger(continuous='1 second')	Není podporováno. Jedná se o experimentální funkci, která je součástí operačního systému Spark. Místo toho použijte režim v reálném čase.

:::Poznámka: Výpočetní prostředky bez serveru

Na serverless výpočtech se podporují jenom Trigger.AvailableNow() a Trigger.Once(). Databricks doporučuje Trigger.AvailableNow().

Pro průběžné streamování na bezserverové výpočetní technice použijte režim spuštěný událostmi vs. průběžný režim pipeline v průběžném režimu.

Viz omezení streamování.

:::

processingTime: Intervaly triggeru založené na čase

Strukturované streamování označuje intervaly aktivačních událostí na základě času jako "mikrodávky s pevným intervalem". Pomocí klíčového processingTime slova zadejte dobu trvání jako řetězec, například .trigger(processingTime='10 seconds').

Konfigurace tohoto intervalu určuje, jak často systém provádí kontroly a zjišťuje, jestli dorazí nová data. Nakonfigurujte dobu zpracování tak, aby vyvažovaly požadavky na latenci a rychlost, kterou data přicházejí do zdroje.

AvailableNow: Přírůstkové dávkové zpracování

Důležité

Ve verzi Databricks Runtime 11.3 LTS a vyšší je Trigger.Once zastaralé. Používá se Trigger.AvailableNow pro všechny úlohy přírůstkového dávkového zpracování.

Možnost spouště AvailableNow zpracovává všechny dostupné záznamy jako přírůstkovou dávku s možností konfigurace její velikosti pomocí možností, jako je maxBytesPerTrigger. Možnosti velikosti se liší podle zdroje dat.

Podporované zdroje dat

Azure Databricks podporuje použití Trigger.AvailableNow pro přírůstkové dávkové zpracování z mnoha zdrojů strukturovaného streamování. Následující tabulka obsahuje minimální podporovanou verzi databricks Runtime požadovanou pro každý zdroj dat:

Zdroj	Minimální verze Databricks Runtime
Zdroje souborů (JSON, Parquet atd.)	9.1 LTS
Delta Lake	10.4 LTS
Automatický nahrávač	10.4 LTS
Apache Kafka	10.4 LTS
Kineze	13.1

realTime: Provozní úlohy s nízkou latencí

Režim strukturovaného streamování v reálném čase dosahuje celkové latence pod 1 sekundou na konci a v běžných případech přibližně 300 ms. Další podrobnosti o tom, jak efektivně nakonfigurovat a používat režim v reálném čase, najdete v tématu Režim v reálném čase ve strukturovaném streamování.

Apache Spark má další interval aktivační události označovaný jako průběžné zpracování. Tento režim byl od Sparku 2.3 klasifikován jako experimentální. Azure Databricks tento režim nepodporuje nebo nedoporučuje. Režim v reálném čase použijte místo toho pro případy použití s nízkou latencí.

Poznámka:

Režim průběžného zpracování na této stránce nesouvisí s průběžným zpracováním v deklarativních kanálech Sparku Lakeflow.

Řízení nákladů na cloudové úložiště

Pokud režim triggeru nenastavíte, nastaví strukturované streamování režim triggeru na processingTime interval a interval 0, na který se kontroluje nová data každých několik milisekund. To může generovat velký objem volání rozhraní API cloudového úložiště za den a vést k neočekávaným poplatkům od poskytovatele cloudu.

Azure Databricks doporučuje nakonfigurovat režim triggeru odpovídající vašim požadavkům na latenci a náklady. Viz processingTime informace o konfiguraci časového intervalu aktivační události.

Změna intervalů aktivačních událostí mezi spuštěními

Můžete změnit interval aktivační události mezi spuštěními při použití stejného kontrolního bodu.

Chování při změně intervalů

Pokud se dotaz strukturovaného streamování zastaví v době, kdy probíhá zpracování mikrodávky, musí se tato mikrodávka dokončit, než se použije nový interval spuštění triggeru. Po změně intervalu triggeru můžete pozorovat, že mikrodávkové zpracování probíhá s dříve zadanou konfigurací. Toto popisuje očekávané chování po přechodu:

• Z časového intervalu do AvailableNow: Mikrodávka může být zpracována jako přírůstková dávka ještě před tím, než jsou zpracovány všechny dostupné záznamy.
• Od AvailableNow do časového intervalu: Zpracování může pokračovat pro všechny záznamy, které byly k dispozici při aktivaci poslední AvailableNow úlohy.

Obnovení po chybách dotazů

Pokud se pokusíte zotavit z selhání dotazu pomocí přírůstkové dávky, změna intervalu triggeru problém nevyřeší. Předchozí neúspěšná dávka musí být dokončena, protože strukturované streamování vyžaduje idempotentní mikro dávky. Podívejte se na sémantiku odolnosti proti chybám pro Apache Spark.

Pokud chcete tuto chybu vyřešit, vertikálně navyšte kapacitu výpočetních prostředků, jako je například zvětšení velikosti pracovních uzlů. Ve výjimečných případech možná budete muset stream restartovat pomocí nového kontrolního bodu.