ETL vs ELT: Jaký je rozdíl a co je lepší v roce 2026?

Co je ETL (Extract, Transform, Load)

ETL je klasický přístup k integraci dat, který vznikl v 90. letech v éře on-premise datových skladů. Data se nejprve extrahují ze zdrojových systémů (ERP, CRM, soubory), pak transformují v samostatném výpočetním prostředí (ETL serveru) a teprve čistá a strukturovaná se nahrají do cílového datového skladu.

Klíčová charakteristika: transformace probíhá *před* uložením do skladu. Sklad obsahuje pouze prověřená, agregovaná a modelovaná data. To zjednodušuje reporting, ale znamená, že pokud potřebujete jiný pohled na data, musíte upravit pipeline a obvykle i přepočítat historii.

Tento přístup dává smysl v prostředí, kde je výpočetní výkon skladu drahý nebo omezený (Oracle, Teradata, MS SQL on-premise), kde požadavky na auditovatelnost vyžadují, aby do skladu vstupovala jen schválená data, nebo kde už máte vybudovanou ETL infrastrukturu (Informatica, IBM DataStage, SSIS) a tým, který ji ovládá.

Co je ELT (Extract, Load, Transform)

ELT je moderní varianta, kterou umožnily cloudové datové sklady jako Snowflake, BigQuery, Redshift a Databricks. Data se opět extrahují ze zdrojů, ale rovnou se nahrají ve své surové podobě do skladu a transformace probíhají až tam, pomocí SQL nebo Sparku přímo nad uloženými daty.

Rozdíl není jen v pořadí písmen — je to fundamentální posun v architektuře. Cloudové sklady mají prakticky neomezený výpočetní výkon a oddělené storage od compute, takže transformace, která by v on-premise světě zabila produkční databázi, v Snowflake/BigQuery proběhne na separátním warehouse, který si platíte jen po dobu běhu.

Velkou výhodou ELT je flexibilita: protože ve skladu máte i surová data, můžete kdykoli postavit novou transformaci, novou dimenzi nebo experimentovat s daty, aniž byste museli předělávat pipeline. Standardem se stalo nasazení dbt (data build tool), který transformační logiku verzuje v Gitu a generuje optimalizovaný SQL.

ETL vs ELT — srovnávací tabulka

Pro rychlou orientaci jsme srovnali oba přístupy podle nejdůležitějších kritérií, na která se nás zákazníci ptají před rozhodnutím:

Kdy zvolit ETL

ETL je správná volba v několika konkrétních scénářích, které se v praxi pořád potkávají:

• Legacy on-premise sklady — pokud máte Oracle/Teradata/MS SQL a nechystáte migraci do cloudu, ETL je přirozená cesta. Výpočetní zdroje skladu jsou drahé a ETL server je odlehčí.
• Striktně regulované prostředí — bankovnictví, zdravotnictví, státní správa. Když do skladu mohou vstoupit jen data po validaci, GDPR maskování a auditu, ETL toto vynucuje na úrovni architektury.
• Existující ETL tým a nástroje — pokud máte certifikované specialisty na Informaticu nebo IBM DataStage, výměna za ELT a dbt znamená přeškolení i přepsání desítek pipeline. Často není ekonomické.
• Velmi citlivá data, která nesmí do cílového skladu v surové podobě — typicky PII, finanční detaily, zdravotní záznamy.

Kdy zvolit ELT

ELT je dnes výchozí volbou pro většinu nových datových platforem. Doporučujeme ho v těchto případech:

• Cloudový datový sklad — Snowflake, BigQuery, Redshift, Databricks. Tyto platformy jsou navržené pro ELT a v ELT režimu vás vyjdou levněji než v ETL.
• Rychle se měnící business požadavky — když potřebujete každý měsíc dodávat nové reporty, dashboardy nebo metriky, ELT s dbt vám umožní iterovat během dní místo měsíců.
• Data science a ML — pokud chcete data science týmu poskytnout surová data k experimentování, ELT je jediná smysluplná cesta. V ETL světě by museli čekat na novou pipeline.
• Velké objemy semi-strukturovaných dat (JSON, logy, eventy) — moderní sklady umí dotazovat JSON nativně, takže nemá smysl je předem ploškovat.

Pokud teprve začínáte stavět platformu a vybíráte technologii, podívejte se na náš průvodce data warehouse vs data lake, který vám pomůže s volbou cílové architektury.

Nástroje pro ETL a ELT

Moderní data stack se obvykle skládá ze tří vrstev: ingestion (E/L), transformation (T) a orchestration. Zde jsou nástroje, které v daata.cz nasazujeme nejčastěji:

Ingestion (Extract & Load)

• Fivetran / Airbyte — managed konektory k stovkám SaaS aplikací (Salesforce, HubSpot, Stripe, GA4). Nastavení v řádu hodin, ale platíte za objem dat.
• Stitch / Meltano — open-source / freemium alternativy k Fivetranu, vhodné pro menší objemy.
• Custom Python/Spark loadery — když potřebujete netriviální logiku, retry policy, anebo zdroj, který komerční nástroje neumí.

Transformation

• dbt (data build tool) — de-facto standard pro ELT transformace v SQL. Modely verzované v Gitu, testy, lineage zdarma. Pokud děláme ELT, používáme dbt.
• Apache Spark / Databricks — pro velké objemy a komplexní transformace, kde čisté SQL nestačí.

Orchestration

• Apache Airflow — průmyslový standard. Definujete DAGy v Pythonu, máte UI s historií běhů, alerting a SLA tracking. Více v naší službě data orchestration.
• Dagster / Prefect — modernější alternativy s lepším developer experience a integrovaným asset modelem.

Pokud řešíte konkrétní výběr stacku, naše služba data engineering zahrnuje audit současného stavu a doporučení nástrojů na míru vaší situaci.

Reverse ETL, CDC a streaming

Moderní datové týmy málokdy končí u „nahrajte sklad a postavte dashboard". Dva vzory rozšiřují klasickou ETL/ELT pipeline. Reverse ETL posílá namodelovaná data ze skladu zpět do operativních nástrojů — health score zákazníka ze Snowflake do HubSpotu nebo segment churn rizika do Braze. Nástroje jako Hightouch a Census umožňují vnímat sklad jako jediný zdroj pravdy a synchronizovat kurátorované tabulky do desítek SaaS cílů.

Change Data Capture (CDC) a streaming doplňují batch ELT pro low-latency použití. Debezium čte transakční logy Postgresu, MySQL nebo SQL Serveru a streamuje row-level změny do Kafky nebo přímo do skladu. V kombinaci s orchestraci dat tak dokážete dodávat near real-time analytiku — sub-minutová latence nad objednávkami, skladem nebo fraud událostmi — bez ztráty jednoduchosti SQL transformací níže po proudu.

Typická architektura roku 2026 míchá všechny tři vrstvy: noční Fivetran load pro SaaS zdroje, CDC streamy pro transakční databáze, dbt pro transformace ve skladu a reverse ETL pro aktivaci. Hranice mezi „ETL" a „ELT" se rozmazává — důležitější je, která vrstva vlastní kterou transformaci a jak spolehlivě běží.

Náklady a realistický timeline implementace

Rozpočet ETL nebo ELT projektu závisí na počtu zdrojových systémů, objemu dat a cílové latenci. Pro střední firmu napojující 5–10 SaaS zdrojů do Snowflake nebo BigQuery počítejte se 400 000–900 000 Kč na úvodní build (nastavení ingestion, 20–40 dbt modelů, základní testy a orchestrace) a s 40 000–130 000 Kč měsíčně za nástroje (Fivetran/Airbyte, compute skladu, monitoring).

Legacy on-premise ETL projekty (Informatica, SSIS, DataStage) typicky stojí 3–5× více kvůli licencím, infrastruktuře a delším vývojovým cyklům. Výměnou je předvídatelný náklad — žádné překvapivé účty za sklad — a těsnější kontrola pro regulované obory.

Realistický timeline: první produkční pipeline naběhne za 4–6 týdnů u ELT a 8–12 týdnů u tradičního ETL. Plná migrace enterprise datové platformy obvykle trvá 6–12 měsíců, přičemž v prvním čtvrtletí dodáváme quick wins, aby stakeholdeři viděli postup. Začínáme vždy 30minutovým auditem, ve kterém s vámi prioritizujeme rozsah, než se zavážeme k dodávkovému plánu.

Časté otázky