Konfigurace automatického zavaděče pro produkční úlohy

Článek
11/08/2024

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

Databricks doporučuje používat automatický zavaděč v rozdílových živých tabulkách pro přírůstkové příjem dat. Delta Live Tables 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 pro produkční kvalitu 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í souborů zjištěných automatickým zavaděč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. cloud_files_state Pomocí funkce můžete najít metadata o souborech zjištěných datovým proudem automatického zavaděče. Stačí zadat dotaz na cloud_files_stateumístění kontrolního bodu přidruženého k datovému proudu 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.

Automaticky zavaděč hlásí metriky do naslouchacího procesu dotazů streamování v každé dávce. V backlogu můžete zobrazit, kolik souborů existuje a jak velký je backlog na numFilesOutstanding numBytesOutstanding kartě Nezpracovaná data na řídicím panelu průběhu dotazu streamování:

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

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

Důležité informace o nákladech

Při spouštění automatického zavaděče by hlavním zdrojem nákladů byly náklady na výpočetní prostředky a zjišťování souborů.

Aby se snížily náklady na výpočetní prostředky, doporučuje Databricks použít úlohy Databricks k naplánování automatického zavaděče jako dávkových úloh, které místo Trigger.AvailableNow průběžného spouštění používají, pokud nemáte požadavky na nízkou latenci. Viz Konfigurace intervalů triggeru strukturovaného streamování.

Náklady na zjišťování souborů můžou být ve formě operací LIST u účtů úložiště v režimu výpisu adresáře a požadavků rozhraní API ve službě předplatného a ve službě 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žití oznámení o souborech v případech, kdy přírůstkové výpisy nejsou možné
Použití značek prostředků k označení prostředků vytvořených automatickým zavaděčem ke sledování nákladů

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

Poznámka:

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

Automatické zavaděč lze naplánovat tak, aby běžel v úlohách Databricks jako dávková úloha pomocí Trigger.AvailableNow. Trigger AvailableNow dá automatickému zavaděče 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 a cloudFiles.maxBytesPerTrigger nakonfigurovatcloudFiles.maxFilesPerTrigger, 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 umístění kontrolního bodu na umístění bez zásad životního cyklu cloudového objektu. 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 poskytoval přesně jednou záruky 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 vyprší události z umístění kontrolního bodu, což zrychluje dobu spuštění automatického zavaděče. Doba spuštění může narůstat do minut za spuštění automatického zavaděče, což přidává zbytečné náklady, pokud máte horní mez maximálního stáří souborů, které budou uloženy ve zdrojovém adresáři. Minimální hodnota, pro cloudFiles.maxFileAge kterou můžete nastavit, je "14 days". Odstranění ve službě 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ýší, jakmile vyprší platnost událostí, než začne vyrovnávat úroveň.

Upozorňující

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 cloudFiles.maxFileAge ladění této možnosti může vést k tomu, že automatické zavaděč ignoruje nezpracované soubory nebo už zpracované soubory, jejichž platnost vypršela, a následné zpracování 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, události oznámení souboru, které se načítají z fronty, které jsou starší, než cloudFiles.maxFileAge jsou 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.maxFileAgeho například tak, že "1 month"stream zastavíte a restartujete stream s nastaveným cloudFiles.maxFileAge "2 months"nastavením , soubory, které jsou starší než 1 měsíc, ale novější 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.

Aktivace běžných backfillů pomocí cloudFiles.backfillInterval

Automatický zavaděč může v daném intervalu aktivovat asynchronní obnovení, například jeden den pro obnovení jednou za den nebo jeden týden pro obnovení jednou za týden. Systémy oznámení událostí souborů nezaručují 100% doručení všech nahraných souborů a neposkytují přísné smlouvy SLA o latenci událostí souboru. Databricks doporučuje aktivovat pravidelné zavaděče automatického zavaděče pomocí cloudFiles.backfillInterval možnosti zaručit, že se všechny soubory v rámci dané smlouvy SLA zjistí, pokud je požadavek na dokončení dat. Aktivace pravidelných backfillů nezpůsobí duplicity.

Sdílet prostřednictvím