Batch versus streamování zpracování dat v Azure Databricks

Dávkové a streamované jsou dvě sémantika zpracování dat používaná pro úlohy přípravy dat, včetně příjmu dat, transformace a zpracování v reálném čase.

Streamování je běžně spojeno s nízkou latencí a průběžným zpracováním z sběrnic zpráv, jako je Apache Kafka.

V Azure Databricks má ale rozsáhlejší definici. Základní modul deklarativních kanálů Sparku Lakeflow (Apache Spark a strukturované streamování) má jednotnou architekturu pro dávkové zpracování a zpracování streamování:

• Modul může zacházet se zdroji, jako je cloudové úložiště objektů a Delta Lake , jako zdroje streamování pro efektivní přírůstkové zpracování.
• Streamové zpracování lze spouštět jak aktivovaným, tak nepřetržitým způsobem, což vám dává flexibilitu při řízení nákladů a vyvážení výkonu pro streamovací úlohy.

Níže jsou základní sémantické rozdíly, které rozlišují dávkové zpracování a streamování, včetně jejich výhod, nevýhod a úvah pro jejich výběr pro vaše úlohy.

Sémantika služby Batch

Při dávkovém zpracování modul nesleduje, jaká data se už zpracovávají ve zdroji. Všechna data aktuálně dostupná ve zdroji se zpracovávají v době zpracování. V praxi je dávkové zdroje dat obvykle dělené logicky, například podle dne nebo oblasti, aby se omezilo opětovné zpracování dat.

Například výpočet průměrné prodejní ceny položky agregované v hodinové členitosti může být pro prodejní událost spuštěnou společností elektronického obchodování naplánován jako dávkové zpracování, aby se vypočítala průměrná prodejní cena každou hodinu. Při dávkovém zpracování se data z předchozích hodin každou hodinu znovu zpracovávají a dříve vypočítané výsledky se přepíšou tak, aby odrážely nejnovější výsledky.

Sémantika streamování

Při zpracování streamování modul sleduje, jaká data se zpracovávají, a zpracovává pouze nová data v následných spuštěních. V předchozím příkladu můžete naplánovat zpracování streamování místo dávkového zpracování, abyste vypočítali průměrnou prodejní cenu každou hodinu. Při streamování se od posledního spuštění zpracovávají pouze nová data přidaná do zdroje. Nově vypočítané výsledky musí být připojeny k dříve vypočítaným výsledkům, aby bylo možné zkontrolovat úplné výsledky.

Batch versus streamování

V předchozím příkladu je streamování lepší než dávkové zpracování, protože nezpracovává stejná data zpracovávaná v předchozích spuštěních. Zpracování datových proudů se ale stává složitějším v situacích, jako jsou data doručená mimo pořadí nebo pozdě.

Příkladem opožděně doručených dat je situace, kdy některá prodejní data z první hodiny dorazí do zdroje až ve druhé hodině.

• Při dávkovém zpracování se data o pozdním příjezdu z první hodiny zpracovávají s daty z druhé hodiny a existujícími daty z první hodiny. Předchozí výsledky z první hodiny jsou přepsány a opraveny na základě pozdě dorazivších dat.
• Při streamovém zpracování jsou opožděně doručená data z první hodiny zpracována bez ostatních dat z první hodiny, která již byla zpracována. Logika zpracování musí ukládat informace o součtu a počtu z průměrných výpočtů první hodiny, aby se správně aktualizovaly předchozí výsledky.

Tyto složitosti streamování se obvykle zavádějí, když je zpracování stavové, jako jsou spojení, agregace a odstranění duplicitních dat.

Pro bezstavové zpracování streamování, jako je připojování nových dat ze zdroje, je zpracování nesprávně seřazených a pozdě příchozích dat méně složité, protože pozdě příchozí data lze připojit k předchozím výsledkům při jejich příchodu ze zdroje.

Následující tabulka popisuje výhody a nevýhody dávkového zpracování a zpracování streamování a různé funkce produktu, které podporují tyto dvě sémantiky zpracování v Databricks Lakeflow.

Zpracování sémantické	Výhody	Nevýhody	Produkty přípravy dat
Batch	Logika zpracování je jednoduchá. Výsledky jsou vždy přesné a odrážejí všechna dostupná data ve zdroji.	Není tak efektivní; data se znovu zpracovává v určitém dávkovém oddílu. Pomalejší může zpracovávat požadavky na latenci od hodin po minuty, ale ne sekundy nebo milisekundy.	Deklarativní kanály Lakeflow Sparku materializované zobrazení toku a materializované zobrazení. Databricks Runtime – Apache Spark (spark.read.load() a spark.write.save()).
Streamování	Efektivní, zpracovávají se pouze nová data. Rychlejší zpracování požadavků na latenci od hodin po minuty, sekundy a milisekundy.	Logika zpracování může být složitá, zejména pro stavové zpracování, jako jsou spojení, agregace, odstranění duplicitních dat atd. Výsledky nemusejí být vždy přesné s ohledem na data přicházející mimo pořadí a opožděně doručená data.	Lakeflow Connect. Deklarativní kanály Sparku Lakeflow tok připojení, aplikace toku změn, streamovací tabulka a výstup. Databricks Runtime – strukturované streamování Sparku (spark.readStream.load() a spark.writeStream.start()).

Doporučení

Následující tabulka popisuje doporučenou sémantiku zpracování na základě charakteristik úloh zpracování dat v každé vrstvě architektury medallionu.

Vrstva medailiónu	Charakteristiky úloh	Doporučení
Bronz	Úlohy pro zpracování příjmu dat Obvykle zahrnuje žádné nebo bezstavové zpracování pro postupné připojování ze zdrojů dat. Velikost dat je obvykle větší.	Streamové zpracování je obecně lepší volbou, protože uživatelé mohou těžit z výhod streamování, ale nejsou vystaveni složitostem stavového streamového zpracování.
Stříbro	Úlohy transformace Obvykle zahrnuje bezstavové zpracování, jako je filtrování a stavové zpracování, jako jsou spojení, agregace a odstranění duplicitních dat.	Použijte dávkové zpracování (s přírůstkovou aktualizací v materializovaných zobrazeních). Použijte streamovací zpracování jako možnost pro případy, kdy je efektivita a latence mnohem důležitější než přesnost výsledků. Mějte na paměti složitosti zavedené stavovým zpracováním streamování.
Zlato	Agregační úlohy na posledních mílích Obvykle zahrnuje stavové zpracování, jako jsou spojení a agregace. Velikost dat je obecně menší.	Použijte dávkové zpracování (s přírůstkovou aktualizací v materializovaných zobrazeních).