← Referenční architektury / reference-architecture / diagrams / serverless

Bezserverové ETL pipeliny

Pipeline typu Extract, Transform, Load (ETL) tvoří základ datového inženýrství, protože zajišťují plynulý přenos dat z jejich syrové podoby do strukturovaného a použitelného formátu. Uplatní se zejména tam, kde je potřeba data nejprve shromáždit, očistit a transformovat, než se uloží do cílového úložiště.

Proces začíná extrakcí, při které se data shromažďují z různých zdrojů, jako jsou databáze, soubory nebo datové proudy. Tato surová data bývají často nesourodá a nestrukturovaná, což vyžaduje další krok: transformaci. Během transformace data procházejí řadou operací, které sjednocují formáty, odstraňují nesrovnalosti a doplňují je o další kontext nebo výpočty. Tato fáze je klíčová pro zajištění kvality a konzistence dat i pro jejich soulad s požadavky navazujících aplikací a analytiky.

Nakonec se transformovaná data načtou do cílového úložiště, kterým může být datový sklad, databáze nebo jiné úložné řešení. Fáze načítání spočívá v efektivním přesunu zpracovaných dat do jejich cílového umístění, odkud jsou snadno dostupná a využitelná k různým účelům, například k reportování, analýze nebo jako vstup pro modely strojového učení.

ETL pipeline hrají klíčovou roli v rozhodovacích procesech založených na datech napříč obory a umožňují organizacím těžit z vlastních dat přínosné poznatky a hodnotu. Díky automatizaci a zjednodušení cesty od syrových dat až k využitelným poznatkům pomáhají ETL pipeline firmám činit informovaná rozhodnutí, optimalizovat procesy a získávat konkurenční výhodu v dnešním světě řízeném daty.

Příkladem nasazení ETL procesů v praxi je třeba extrakce prodejních dat z více obchodů, jejich transformace do standardizovaného formátu a následné načtení do centralizovaného datového skladu pro účely analýzy a reportingu. ETL procesy se podobně využívají i v projektech migrace dat, kde je potřeba přesunout starší data do moderních systémů a přitom po celou dobu zachovat jejich integritu a konzistenci.

Cloudflare umožňuje nasazovat zcela bezserverová ETL pipeline, což snižuje složitost, dobu uvedení do provozu i celkové náklady. Následující diagramy ukazují různé způsoby, jak Cloudflare využít při běžném nasazení ETL pipeline.

Tato architektura znázorňuje plně serverless ETL pipeline s API koncovým bodem jako vstupním bodem. Klienti odesílají data ke zpracování pomocí HTTP požadavku. Typickým příkladem jsou data o pohybu uživatelů na webu (click-stream) nebo analytická data.

1. Klientský požadavek: Odeslání POST požadavku s daty ke zpracování. Příkladem mohou být clickstreamová data nebo analytické endpointy.
2. Zpracování vstupu: Zpracování příchozího požadavku pomocí Workers a odesílat zprávy do Queues a přidávat do fronty zpracování.
3. Zpracování dat: Použijte Queues ke spuštění spotřebitel které zpracovávají vstupní data po dávkách, aby se zabránilo přetížení navazujících systémů a zvýšila se efektivita. Consumer provádí veškeré operace čištění, transformace a standardizace dat.
4. Objektové úložiště: Nahrát zpracovaná data do R2 pro trvalé úložiště.
5. Mechanismus Ack/Retry: Signalizace úspěchu nebo chyby pomocí Queues Runtime API ve spotřebiteli pro každý dokument. Queues naplánuje v případě potřeby opakované pokusy.
6. Dotazování na data: Přístup ke zpracovaným datům z externích služeb pro jejich další využití.

Tato architektura znázorňuje plně serverless ETL pipeline s objektovým úložištěm jako vstupním bodem. Typickým příkladem je zpracování protokolů nebo nestrukturovaných dokumentů.

1. Klientský požadavek: Nahrát nezpracovaná data do R2 přes rozhraní kompatibilní s S3 API. Typickým příkladem jsou protokolová a analytická data.
2. Zpracování vstupu: Odesílání zpráv do Queues pomocí Oznámení o událostech R2 při nahrání objektu.
3. Zpracování dat: Použijte Queues ke spuštění spotřebitel které zpracovávají vstupní data po dávkách, aby se zabránilo přetížení navazujících systémů a zvýšila se efektivita. Consumer provádí veškeré operace čištění, transformace a standardizace dat.
4. Objektové úložiště: Nahrát zpracovaná data do R2 pro trvalé úložiště.
5. Mechanismus Ack/Retry: Signalizace úspěchu nebo chyby pomocí Queues Runtime API ve spotřebiteli pro každý dokument. Queues naplánuje v případě potřeby opakované pokusy.
6. Dotazování na data: Přístup ke zpracovaným datům z externích služeb pro jejich další využití.

• Workers: Začínáme
• Queues: Začínáme
• R2: Začínáme