Databricks Declarative Pipelines: Úvod do deklarativních pipeline

Katerina Protivenskyi

26. srpna 2026

„Můžete mít k dispozici tu nejlepší AI na světě, ale pokud stojí na nekvalitních datech, nepřinese vám žádnou skutečnou hodnotu.“
Carol Clements, Chief Digital and Technology Officer, JetBlue

V současnosti se téměř každá diskuse točí kolem AI. Dříve nebo později se ale vždy dostaneme ke stejnému tématu – ke kvalitě dat, na kterých AI stojí. Výstupy AI totiž nikdy nebudou lepší než data, ze kterých vycházejí. Platí zde známé pravidlo: garbage in, garbage out.

Právě proto dnes většina datových týmů zodpovídá za přípravu dat tak, aby byla připravená pro využití AI. Přesto se ve většině případů stále spoléhají na tradiční, imperativní přístup ke zpracování dat.

V imperativní pipeline vývojář přesně určuje jednotlivé kroky zpracování dat. Definuje celý průběh procesu – načtení zdrojových dat, spuštění transformací, zápis do cílových tabulek, pořadí jednotlivých operací, práci s inkrementálními daty, opakování neúspěšných úloh i závislosti mezi jednotlivými kroky. Jinými slovy, vývojář řídí celý proces a nese odpovědnost za jeho správné pořadí, konzistenci, obnovu po chybách i celkovou spolehlivost.

Existuje však i jiný přístup – declarative pipelines v Databricks.

V deklarativní pipeline už neurčujeme, jak má zpracování proběhnout. Popisujeme pouze jaký má být výsledný stav. Neřešíme pořadí spuštění, práci s novými soubory ani závislosti mezi jednotlivými kroky. Jednoduše definujeme například, že „tato tabulka má obsahovat výsledek tohoto SQL dotazu“.

O vše ostatní se postará samotný Databricks. Automaticky analyzuje definice tabulek, sestaví graf závislostí, určí pořadí zpracování, řídí inkrementální načítání dat, zajišťuje opakování neúspěšných úloh i obnovu po chybách a zároveň vynucuje definovaná pravidla kvality dat.

V tomto článku si ukážeme, co deklarativní pipeline jsou, jak je krok za krokem vytvořit a jaké místo mají v moderní datové architektuře.

Co jsou Declarative Pipelines?

Deklarativní přístup znamená, že definujeme pouze obsah výsledných tabulek. Nepíšeme plánovač úloh, logiku závislostí, správu opakování ani checkpointů. Popíšeme pouze požadovaný výsledek a Databricks sám rozhodne, jak a kdy jej vytvoří.

V praxi vytvoříme SQL nebo Python definici typu:

„Tabulka B obsahuje transformaci tabulky A.“

To je vše.

Databricks z této definice automaticky rozpozná závislost na tabulce A, rozhodne o správném pořadí spuštění, postará se o opakování při chybách i o sledování inkrementálního zpracování.

Při spuštění pipeline Databricks analyzuje všechny definice tabulek, vyhodnotí jejich vzájemné odkazy a vytvoří DAG (Directed Acyclic Graph).

Tabulky bez závislostí se spustí jako první. Tabulky navazující na jiné čekají, dokud jejich zdroje úspěšně nedokončí zpracování.

Pokud během běhu některá tabulka selže, Databricks označí jako neúspěšnou pouze tuto tabulku a všechny navazující části pipeline. Výsledky tabulek, které již byly úspěšně zpracovány, zůstávají zachovány. Kvůli chybě v jedné části pipeline tedy není nutné znovu zpracovávat všechna data.

Poznámka k názvosloví

Tento produkt během několika let několikrát změnil název.

V roce 2022 jej Databricks uvedl jako Delta Live Tables (DLT) a pod tímto názvem jej komunita používala několik let.

V letech 2024–2025 Databricks sjednotil své nástroje pro data engineering pod platformu Lakeflow, která zahrnuje:

Lakeflow Connect – spravované konektory,
Lakeflow Declarative Pipelines – přejmenované Delta Live Tables,
Lakeflow Jobs – orchestraci datových workflow.

V roce 2025 Databricks zároveň otevřel samotný engine komunitě Apache Spark pod názvem Spark Declarative Pipelines. Současný produkt Databricks se proto označuje jako Lakeflow Spark Declarative Pipelines (SDP).

Ve starších článcích se tak můžete setkat s označením DLT, v novějších pak s názvy Lakeflow nebo SDP. Ve všech případech jde o stejnou technologii.

Medallion architektura

Než začneme pipeline vytvářet, je dobré si připomenout jeden základní koncept, který se objevuje téměř ve všech moderních datových platformách – Medallion architekturu.

Ta rozděluje zpracování dat do tří vrstev:

Bronze obsahuje surová data přesně v podobě, v jaké přicházejí ze zdrojových systémů. Slouží jako vstupní vrstva a auditní stopa.
Silver obsahuje vyčištěná, validovaná a deduplikovaná data se správnými datovými typy a jednotným formátem.
Gold představuje data připravená pro business využití, typicky ve formě hvězdicového schématu určeného pro BI nástroje nebo analytiku.

Tok dat probíhá vždy jedním směrem:

Bronze → Silver → Gold

V imperativním přístupu bychom museli jednotlivé vrstvy propojit a naplánovat jejich spuštění ve správném pořadí.

V deklarativní pipeline pouze definujeme tabulky v jednotlivých vrstvách a Databricks se o správné pořadí jejich zpracování postará automaticky.

Právě díky tomu posouvají Declarative Pipelines koncept Medallion architektury na vyšší úroveň. A přesně takovou pipeline si nyní společně vytvoříme.

Vytvoření pipeline

Bronze: Načtení surových dat

Začneme načtením surových zákaznických a prodejních dat do Bronze vrstvy.

V tomto případě použijeme streaming table, tedy tabulku určenou pro data, která přicházejí průběžně. Každý záznam zpracuje právě jednou, pamatuje si již načtená data a při dalším spuštění zpracuje pouze nově příchozí soubory.

Poznámka: Katalog i schéma je potřeba vytvořit předem.

Zdroj kódu: https://www.youtube.com/watch?v=8v150KsR5ak

Klíčovou funkcí je cloud_files(…), která využívá technologii Auto Loader. Ta průběžně sleduje zvolený adresář, automaticky načítá nově příchozí soubory a zároveň si pamatuje, které soubory již byly zpracovány.

V imperativní pipeline bychom tuto logiku museli implementovat sami – sledovat zpracované soubory, řešit jejich stav a zajistit, aby nedocházelo k opakovanému načítání. S Auto Loaderem pouze určíme zdrojovou složku a deklarujeme cílovou tabulku. O zbytek se postará Databricks.

Silver: Čištění dat a zajištění jejich kvality

Data v Bronze vrstvě jsou převzata přímo ze zdrojových systémů, a proto obvykle obsahují chybějící hodnoty, nekonzistentní zápis, duplicity nebo nesprávně naformátovaná data.

Úkolem Silver vrstvy je tato data vyčistit a sjednotit.

Pro tento krok využíváme materialized view – tabulku definovanou pomocí dotazu nad existujícími daty, která průběžně odráží aktuální výsledek tohoto dotazu. Pokud je to možné, Databricks ji udržuje inkrementálně.

Materialized views jsou proto ideální pro transformační operace, jako jsou:

čištění dat,
spojování tabulek (join),
agregace,
odstraňování duplicit,
standardizace datových typů a formátů.

Ke každé definici tabulky zároveň připojujeme pravidla kvality dat (data quality constraints) přímo v její definici.

Zdroj kódu: https://www.youtube.com/watch?v=8v150KsR5ak

Ke každé tabulce můžeme také připojit pravidlo kvality dat (constraint). To připojuje pravidlo kvality dat k tabulce a vyhodnocuje se pro každý řádek při zápisu.

Místo psaní kódu, který prochází jednotlivé řádky a zaznamenává problémy, definujete pravidlo pouze jednou: „e-mail by měl vypadat jako e-mail“ nebo „množství by mělo být kladné“, přímo vedle definice tabulky, kde jej uvidí každý, kdo čte kód.

Pro porušení pravidla existují přesně dva režimy, které se nastavují pomocí klauzule ON VIOLATION:

To je užitečné při vývoji, kdy chcete nejprve zjistit, jak moc jsou data znečištěná, než se rozhodnete, zda neplatné záznamy zahodíte, nebo kvůli nim necháte pipeline selhat.

Gold: Hvězdicové schéma pro analytiku

Nakonec čistá data přetvoříme do podoby, kterou využívají business uživatelé a BI nástroje: do sady dimenzních tabulek („kdo, co, kdy“) a faktové tabulky (měřitelné události). To představuje Gold vrstvu.

Zdroj kódu: https://www.youtube.com/watch?v=8v150KsR5ak

Jak to funguje dohromady: Automaticky vytvořený DAG

A právě tady se projeví hlavní výhoda. Všimněte si, že jsme nikde neřekli, že dim_customers závisí na customers_cleaned nebo že customers_cleaned závisí na customers_raw. Pouze jsme napsali dotazy, které odkazují na jiné tabulky podle jejich názvu.

Databricks vytvoří DAG pro spuštění celé pipeline výhradně na základě těchto odkazů. Když fact_sales vybírá data z sales_cleaned, Databricks automaticky ví, že sales_cleaned musí být nejprve dokončena. Nikde v kódu neexistuje žádná explicitní deklarace závislostí – samotný odkaz je deklarací.

Žádná konfigurace plánovače. Žádná logika pro opakování běhu. Databricks spustí nejprve Bronze, poté Silver, následně Gold a zároveň za vás vytvoří graf datové lineage.

Auto-Built Dag: https://www.youtube.com/watch?v=8v150KsR5ak

Další možnosti

Výše uvedená pipeline pokrývá běžné scénáře. Jakmile si osvojíte základy, stojí za to se seznámit ještě s jednou funkcí.

AUTO CDC

AUTO CDC zjednodušuje sledování vložených, aktualizovaných a smazaných záznamů ve zdrojové databázi a jejich promítání do navazujících tabulek, aniž by bylo nutné psát složitou logiku pomocí příkazu MERGE.

KEYS určují jednoznačný identifikátor řádku, SEQUENCE BY říká Databricks, podle čeho má příchozí změny seřadit, aby vždy zvítězila ta nejnovější, a STORED AS SCD TYPE 1 přepíše existující záznam nejnovějšími hodnotami. Pokud naopak potřebujete zachovat historické verze jednotlivých řádků, použijte SCD TYPE 2.

Závěr

Pomocí tří jednoduchých vrstev – načtení surových dat, jejich vyčištění pomocí pravidel kvality dat a vytvoření hvězdicového schématu pro analytiku – jsme vytvořili kompletní pipeline, aniž bychom napsali jediný řádek orchestrace.

Právě v tom spočívá hlavní přínos Declarative Pipelines a důvod, proč Databricks postavil celou produktovou řadu na tomto principu. Popíšete pouze tabulky, které chcete vytvořit, a platforma se postará o jejich správné vytvoření, ve správném pořadí a při každém spuštění.

Pokud jsou kvalitní data základem úspěšného využití AI, pak právě takový datový základ stojí za to vybudovat správně.

Zdroje

Kateřina Protivenskyi

Kateřina je Senior Data Engineer ve společnosti Revolt BI se silným zaměřením na moderní datové platformy a datovou architekturu.

Má zkušenosti s návrhem a implementací škálovatelných datových modelů, budováním ELT pipeline v dbt a orchestrací workflow v nástrojích jako Apache Airflow. Specializuje se na transformaci a integraci dat, zajištění jejich kvality a konzistence a na automatizaci datových procesů. Kateřina pomáhá firmám efektivně pracovat s daty, nastavovat robustní datovou infrastrukturu a připravovat jejich data na pokročilou analytiku a AI.