Konfigurace Auto Loaderu pro produkční úlohy

Článek
03/06/2025

Databricks doporučuje dodržovat osvědčené postupy streamování pro spouštění Auto Loader v produkčním prostředí.

Databricks doporučuje používat Auto Loader v DLT ke zvýšení přírůstkového příjmu dat. DLT rozšiřuje funkce strukturovaného streamování Apache Sparku a umožňuje napsat jen několik řádků deklarativního Pythonu nebo SQL pro nasazení datového kanálu v produkční kvalitě pomocí:

Automatické škálování výpočetní infrastruktury pro úsporu nákladů
Kontroly kvality dat s očekáváním
Automatické zpracování vývoje schématu
Monitorování prostřednictvím metrik v protokolu událostí

Monitorování automatického zavaděče

Dotazování na soubory objevené automatickým načítačem

Poznámka:

Funkce cloud_files_state je dostupná v Databricks Runtime 11.3 LTS a vyšší.

Auto Loader poskytuje rozhraní SQL API pro kontrolu stavu datového proudu. Pomocí funkce cloud_files_state můžete najít metadata o souborech zjištěných datovým proudem Auto Loader. Stačí provést dotaz z cloud_files_state a poskytnout umístění kontrolního bodu spojeného se streamem automatického zavaděče.

SELECT * FROM cloud_files_state('path/to/checkpoint');

Poslech aktualizací streamu

K dalšímu monitorování datových proudů automatického zavaděče doporučuje Databricks používat rozhraní naslouchacího procesu dotazů streamování Apache Sparku.

Automatický nakladač hlásí metriky posluchači dotazů v reálném čase při každé dávce. Na kartě numFilesOutstanding a numBytesOutstanding metrik pod záložkou Nezpracovaná data na řídicím panelu průběhu streamovacího dotazu můžete zobrazit, kolik souborů je v backlogu a jak velký backlog je:

{
  "sources": [
    {
      "description": "CloudFilesSource[/path/to/source]",
      "metrics": {
        "numFilesOutstanding": "238",
        "numBytesOutstanding": "163939124006"
      }
    }
  ]
}

V Databricks Runtime 10.4 LTS a vyšších verzích budou při použití režimu oznámení souborů metriky zahrnovat i přibližný počet událostí souborů ve frontě cloudu jako approximateQueueSize pro AWS a Azure.

Důležité informace o nákladech

Při spuštění Auto Loaderu by hlavním zdrojem nákladů byly výpočetní prostředky a zjišťování souborů.

Pro snížení nákladů na výpočetní prostředky doporučuje Databricks použít Databricks Jobs k naplánování Auto Loader jako dávkových úloh místo toho, abyste jej spouštěli průběžně, pokud nemáte požadavky na nízkou latenci. Viz Konfigurace intervalů triggeru strukturovaného streamování.

Náklady spojené se zjišťováním souborů se mohou objevit v podobě operací LIST na účtech úložiště v režimu výpisu adresáře a také jako požadavky rozhraní API na službu předplatného a službu fronty v režimu oznámení souborů. Databricks doporučuje snížit náklady na zjišťování souborů:

Poskytnutí triggeru při průběžném spouštění automatického ProcessingTime zavaděče v režimu výpisu adresáře
Navrhování souborů nahraných do účtu úložiště v lexikálním pořadí, aby bylo možné využívat přírůstkové výpisy (zastaralé), pokud je to možné
Využívání oznámení o souborech v případech, kdy přírůstkové výpisy nejsou možné
Použití značek prostředků k tagování prostředků vytvořených nástrojem Auto Loader za účelem sledování nákladů

Použití Trigger.AvailableNow a omezování rychlosti

Poznámka:

K dispozici ve službě Databricks Runtime 10.4 LTS nebo vyšší.

Automatický zavaděč lze naplánovat ke spuštění v úlohách Databricks jako dávková úloha pomocí Trigger.AvailableNow. Trigger AvailableNow dá automatickému zavaděči pokyn, aby zpracoval všechny soubory, které přišly před počátečním časem dotazu. Nové soubory, které se nahrají po spuštění streamu, se ignorují až do dalšího triggeru.

V případě Trigger.AvailableNow, zjišťování souborů probíhá asynchronně se zpracováním dat a data lze zpracovávat v několika mikrodávkách s omezováním rychlosti. Auto Loader ve výchozím nastavení zpracovává maximálně 1 000 souborů v každé mikrodávce. Můžete nakonfigurovat cloudFiles.maxFilesPerTrigger a cloudFiles.maxBytesPerTrigger tak, aby bylo určeno, kolik souborů nebo kolik bajtů má být zpracováno v mikrodávce. Limit souboru je pevný limit, ale limit bajtů je měkký limit, což znamená, že více bajtů lze zpracovat, než je zadané maxBytesPerTrigger. Když jsou obě možnosti k dispozici společně, auto loader zpracuje tolik souborů, které jsou potřeba k dosažení jednoho z limitů.

Umístění kontrolního bodu

Databricks doporučuje nastavit místo kontrolního bodu na umístění, které nepodléhá zásadám životního cyklu cloudových objektů. Pokud se soubory v umístění kontrolního bodu vyčistí podle zásad, stav datového proudu je poškozený. Pokud k tomu dojde, musíte stream restartovat úplně od začátku.

Uchovávání událostí

Auto Loader sleduje zjištěné soubory v umístění kontrolního bodu pomocí RocksDB, aby zajistil záruky přesně jednoho příjmu dat. Databricks důrazně doporučuje použít cloudFiles.maxFileAge možnost pro všechny datové proudy s velkým objemem nebo dlouhodobým příjmem dat. Tato možnost odstraňuje události z umístění kontrolního bodu, což zrychluje spuštění Auto Loaderu. Doba spuštění může narůstat a trvat několik minut při každém spuštění Auto Loaderu, což přidává zbytečné náklady v situacích, kdy máte stanovenou maximální přípustnou dobu stáří souborů, jež budou uloženy ve zdrojovém adresáři. Minimální hodnota, pro cloudFiles.maxFileAge kterou můžete nastavit, je "14 days". Odstranění v RocksDB se zobrazují jako položky náhrobků, proto byste měli očekávat, že se využití úložiště dočasně zvýší, když se události postupně vyprchají, než se úroveň začne stabilizovat.

Varování

cloudFiles.maxFileAge je k dispozici jako mechanismus řízení nákladů pro datové sady s velkým objemem. Příliš agresivní ladění cloudFiles.maxFileAge může způsobit problémy s kvalitou dat, jako je duplicitní příjem dat nebo chybějící soubory. Proto Databricks doporučuje konzervativní nastavení pro cloudFiles.maxFileAge, například 90 dní, což je podobné tomu, jaké srovnatelné řešení pro příjem dat doporučují.

Pokus o ladění této možnosti může vést k tomu, že Automatický nakladač ignoruje nezpracované soubory nebo že platnost již zpracovaných souborů vyprší a poté jsou zpracovány znovu, což způsobuje duplicitní data. Tady je několik věcí, které je potřeba vzít v úvahu při výběru cloudFiles.maxFileAge:

Pokud se stream po delší době restartuje, jsou události oznámení souboru, načtené z fronty a starší než cloudFiles.maxFileAge, ignorovány. Podobně pokud používáte výpis adresáře, soubory, které se mohly objevit v době výpadku, které jsou starší, než cloudFiles.maxFileAge jsou ignorovány.
Pokud používáte režim výpisu adresáře a použijete cloudFiles.maxFileAge, například nastavíte "1 month", když zastavíte a restartujete stream s nastavením cloudFiles.maxFileAge na "2 months", soubory, které jsou starší než 1 měsíc, ale ne starší než 2 měsíce, se znovu zpracují.

Pokud tuto možnost nastavíte při prvním spuštění streamu, nebudete ingestovat data starší než cloudFiles.maxFileAge, takže pokud chcete ingestovat stará data, neměli byste tuto možnost nastavit při prvním spuštění streamu. Tuto možnost byste ale měli nastavit při dalších spuštěních.

Spouštění pravidelných backfillů pomocí cloudFiles.backfillInterval

Automatický načítač může v daném intervalu spustit asynchronní doplnění dat, například jednou za den pro doplnění jednou denně, nebo jednou za týden pro doplnění jednou týdně. Systémy notifikací událostí souborů nezaručují 100% doručení všech nahraných souborů a neposkytují přísné SLA ohledně latence těchto událostí. Databricks doporučuje spouštět pravidelné doplňování pomocí možnosti cloudFiles.backfillInterval v Auto Loader, aby bylo zaručeno, že všechny soubory budou v rámci daného SLA nalezeny, pokud je vyžadováno úplné zpracování dat. Aktivace pravidelných backfillů nezpůsobí duplicity.

Sdílet prostřednictvím