Datové modelování v Unity Catalogu

Než sáhnete po jakémkoli nástroji, musíte rozhodnout, jak se data ze zdroje budou vůbec získávat. Tomu se říká extraction type a je to rozhodnutí, které určuje čerstvost dat, spotřebu compute i složitost pipeline. Databricks rozlišuje tři základní vzory — full, inkrementální a streaming — plus specializovaný vzor change data capture (CDC).

Klíčový rozdíl mezi inkrementální extrakcí a CDC: inkrementální extrakce vidí jen „nový stav řádků", zatímco CDC zachovává typ operace — pozná tedy i mazání a změny klíčových sloupců. CDC ale vyžaduje sekvenční informaci (timestamp nebo pořadové číslo), aby šlo správně zpracovat eventy, které dorazí mimo pořadí.

Druhá část návrhu je konfigurace zdroje. U cloud storage (ADLS, S3, GCS) řídíte přístup přes Unity Catalog external locations (viz kapitola 3) a hodně záleží na struktuře složek: Hive-style partitioning (key=value) umožní automatickou extrakci partition hodnot a ploché adresáře s tisíci soubory zpomalují listing. U databází řešíte síť, secrets a dopad extrakce na zdrojový systém; u SaaS API zase rate limity, stránkování a OAuth; u message busů consumer groups a offset management.

Azure Databricks nabízí spektrum ingesčních nástrojů od plně spravovaných po plně vlastní kód. Na jednom konci stojí Lakeflow Connect s hotovými konektory, na druhém Spark Structured Streaming, kde si vše píšete sami. Mezi nimi leží Auto Loader pro soubory v cloud storage, COPY INTO pro SQL dávky a notebooky s JDBC/ODBC. Azure Data Factory hraje roli orchestrátoru a „přistávací dráhy" pro data z Azure ekosystému — ne transformačního enginu.

Lakeflow Connect má tři kategorie managed konektorů (podrobně v sekci 7.1): SaaS konektory (Salesforce, HubSpot, Jira, Workday…), které řeší autentizaci, inkrementální čtení, rate limity i schema evolution a běží na serverless compute; databázové konektory (CDC) (SQL Server, MySQL, PostgreSQL) postavené na čtení transakčního logu, které vyžadují ingestion gateway ve vaší síti a staging volume; a query-based konektory pro databáze bez CDC (Oracle, Teradata a další), které se plánovaně dotazují přes cursor column a gateway nepotřebují. Doplňkem jsou community konektory udržované komunitou. K tomu standard konektory pro cloud storage (interně Auto Loader) a message busy (Kafka, Pub/Sub, Pulsar), typicky používané v rámci Lakeflow Spark Declarative Pipelines. Seznam konektorů roste rychle — aktuální stav ověřte v dokumentaci.

Auto Loader si drží stav zpracovaných souborů v checkpointu a nové soubory objevuje buď directory listingem, nebo přes file notification eventy — zvládá exactly-once zpracování i miliardy souborů a schema inference/evolution. COPY INTO je jeho dávkový sourozenec: idempotentní SQL příkaz, který si zpracované soubory eviduje v transakčním logu Delta tabulky, takže opakované spuštění data neduplikuje.

-- idempotentni davkovy load z landing zony
COPY INTO banka.bronze.transakce
FROM 'abfss://landing@datalake.dfs.core.windows.net/transakce/'
FILEFORMAT = PARQUET
COPY_OPTIONS ('mergeSchema' = 'true');

Nejdřív pojmy: file format (Parquet, CSV, JSON) určuje fyzické uložení dat na disku, table format (Delta Lake, Apache Iceberg) nad ním přidává metadatovou vrstvu — transakce, evidenci souborů a verzí schématu. Delta i Iceberg používají pod kapotou Parquet; liší se právě metadatovou vrstvou.

Parquet ukládá data sloupcově v row groups s min/max statistikami — odtud column pruning (čtou se jen potřebné sloupce) a predicate pushdown (přeskočí se row groups mimo rozsah filtru). Delta Lake k tomu přidává transakční log: ACID transakce, time travel, schema enforcement/evolution a jednotný batch + streaming přístup. V Azure Databricks je Delta výchozím formátem — když formát neuvedete, dostanete Delta tabulku.

Apache Iceberg volte primárně kvůli interoperabilitě: čtou a zapisují ho Snowflake, Trino, Athena, Flink a další. Unity Catalog umí spravovat managed Iceberg tabulky a fungovat jako Iceberg katalog pro externí enginy; cizí Iceberg tabulky (AWS Glue, Snowflake Horizon) lze připojit jako foreign tables. Existuje i UniForm — Delta tabulka, která si vedle sebe generuje Iceberg metadata, takže ji externí Iceberg klienti čtou bez kopírování dat; přesné schopnosti a limity ověřte v dokumentaci. Pozor na jednu asymetrii: liquid clustering a predictive optimization fungují pro Delta i managed Iceberg, ale Change Data Feed je specialita Delta Lake — stojí na jejím transakčním logu.

Partitioning rozděluje tabulku do segmentů podle hodnot sloupce; dotazy filtrované na partition klíč pak čtou jen relevantní část dat (partition pruning). Zní to jako univerzální dobro — ale dokumentace je nečekaně zdrženlivá: „Databricks recommends that you do not partition tables that contain less than a terabyte of data." Pod 1 TB režie správy partition metadat a riziko malých souborů převáží přínosy; nepartitionované Delta tabulky navíc automaticky těží z ingestion time clusteringu.

Pokud partitionujete, dodržujte dvě čísla: tabulka nad 1 TB a každá partition alespoň 1 GB dat. Dobrý partition klíč má nízkou kardinalitu (datum, region, kategorie), odpovídá nejčastějším filtrům dotazů a škáluje s růstem dat. Klíče jako customer_id nebo timestamp na sekundy vyrobí miliony mini-partitions a výkon zabijí.

-- partition podle data odvozeneho z timestampu (generated column)
CREATE TABLE banka.silver.transakce (
    transaction_id STRING,
    customer_id    STRING,
    amount         DECIMAL(12,2),
    transaction_ts TIMESTAMP,
    transaction_date DATE GENERATED ALWAYS AS (CAST(transaction_ts AS DATE))
)
PARTITIONED BY (transaction_date);

Trik s generated column stojí za zapamatování: Delta Lake pak umí odvodit partition filtry i z dotazů filtrujících na původní transaction_ts — analytici nemusí vědět, že tabulka je partitionovaná podle odvozeného data.

Atributy dimenzí (zákazník, produkt, pobočka) se v čase mění a slowly changing dimensions (SCD) definují, co s tím. Když se zákazník přestěhuje ze Seattlu do Portlandu, máte tři možnosti: hodnotu přepsat (a přijít o historii), zachovat starou verzi a založit novou, nebo sledovat jen předchozí hodnotu ve zvláštním sloupci.

V praxi dimenze typy kombinují: datum registrace jako Type 0, e-mail a telefon jako Type 1, přiřazený region jako Type 2. Type 2 si šetřete na atributy, kde historická perspektiva ovlivňuje byznys rozhodnutí — verzovat kvůli změně telefonního čísla je zbytečná režie. Type 3 je nejméně častý; většinu scénářů, které po něm volají, lépe obslouží Type 2.

Implementace v Delta Lake: surrogate key vygeneruje GENERATED ALWAYS AS IDENTITY, platnost verzí drží sloupce valid_from/valid_to a příznak is_current:

CREATE TABLE banka.gold.dim_zakaznik (
    customer_sk   BIGINT GENERATED ALWAYS AS IDENTITY,
    customer_id   STRING NOT NULL,   -- natural / business key
    customer_name STRING,
    city          STRING,
    region        STRING,
    valid_from    TIMESTAMP NOT NULL,
    valid_to      TIMESTAMP NOT NULL,
    is_current    BOOLEAN
)
USING DELTA
TBLPROPERTIES ('delta.enableChangeDataFeed' = 'true');

Samotné zpracování změn je dvoufázové: MERGE nejdřív uzavře aktuální verze změněných záznamů a vloží úplně nové zákazníky, druhý krok pak vloží nové verze pro záznamy, jejichž stará verze byla právě uzavřena. Obě fáze přitom musí pracovat se stejným časovým okamžikem — jinak mezi valid_to staré a valid_from nové verze vznikne mikro-mezera a point-in-time dotaz do ní spadne. Čas si proto uložte do proměnné:

-- jeden casovy okamzik pro obe faze: intervaly pak navazuji bez mezery
DECLARE OR REPLACE VARIABLE zmena_ts TIMESTAMP DEFAULT current_timestamp();

-- krok 1: uzavri stare verze + vloz nove zakazniky
MERGE INTO banka.gold.dim_zakaznik AS t
USING banka.staging.zakaznici AS s
ON t.customer_id = s.customer_id AND t.is_current = true
WHEN MATCHED AND (t.city <> s.city OR t.region <> s.region
                  OR t.customer_name <> s.customer_name)
THEN UPDATE SET t.valid_to = zmena_ts, t.is_current = false
WHEN NOT MATCHED THEN INSERT
    (customer_id, customer_name, city, region, valid_from, valid_to, is_current)
VALUES (s.customer_id, s.customer_name, s.city, s.region,
        zmena_ts, CAST('9999-12-31' AS TIMESTAMP), true);

-- krok 2: vloz nove verze pro prave uzavrene zaznamy
-- EXISTS misto JOIN: jinak by zakaznik s N uzavrenymi verzemi dostal N kopii
INSERT INTO banka.gold.dim_zakaznik
    (customer_id, customer_name, city, region, valid_from, valid_to, is_current)
SELECT s.customer_id, s.customer_name, s.city, s.region,
       zmena_ts, CAST('9999-12-31' AS TIMESTAMP), true
FROM banka.staging.zakaznici s
WHERE EXISTS (SELECT 1 FROM banka.gold.dim_zakaznik h
              WHERE h.customer_id = s.customer_id AND h.valid_to = zmena_ts)
  AND NOT EXISTS (SELECT 1 FROM banka.gold.dim_zakaznik c
                  WHERE c.customer_id = s.customer_id AND c.is_current = true);

Dotaz na stav „k datu" pak filtruje interval platnosti — vrátí přesně jednu verzi na zákazníka:

-- stav dimenze k 15. 6. 2023 (point-in-time)
SELECT customer_id, customer_name, city
FROM banka.gold.dim_zakaznik
WHERE valid_from <= '2023-06-15 12:00:00'
  AND valid_to   >  '2023-06-15 12:00:00';

SCD Type 2 sleduje byznysovou historii pro analytiku. Temporal (history) tabulky řeší něco jiného: technickou historii pro audit, debugging a reprodukovatelnost — „co přesně bylo v tabulce v úterý ve 14:30 a kdo to změnil". V Delta Lake se staví na dvou mechanismech: Change Data Feed (CDF) a time travel.

CDF po zapnutí zaznamenává každou řádkovou změnu s metadaty: _change_type (insert, update_preimage, update_postimage, delete), _commit_version a _commit_timestamp. Ve výchozím stavu je vypnutý a zachytává jen změny provedené po zapnutí — zapněte ho tedy dřív, než do tabulky nalijete produkční data.

-- zapnuti CDF na existujici tabulce
ALTER TABLE banka.silver.transakce
SET TBLPROPERTIES ('delta.enableChangeDataFeed' = 'true');

-- kdo, co a kdy zmenil v lednu (audit dotaz)
SELECT transaction_id, amount, _change_type, _commit_version, _commit_timestamp
FROM table_changes('banka.silver.transakce', '2026-01-01', '2026-01-31')
WHERE _change_type IN ('insert', 'update_postimage')
ORDER BY _commit_timestamp;

Time travel doplňuje CDF o dotazy na celý stav tabulky v minulosti — přes TIMESTAMP AS OF nebo VERSION AS OF; přehled operací dá DESCRIBE HISTORY. Dostupnost historie ale řídí retence: standardně se datové soubory drží 7 dní a log 30 dní. Pro compliance scénáře retenci prodlužte — obě vlastnosti nastavujte společně:

SELECT * FROM banka.silver.transakce TIMESTAMP AS OF '2026-01-15 14:30:00';
SELECT * FROM banka.silver.transakce VERSION AS OF 42;
DESCRIBE HISTORY banka.silver.transakce;

-- prodlouzeni retence pro audit (obe vlastnosti spolecne)
ALTER TABLE banka.silver.transakce SET TBLPROPERTIES (
    'delta.logRetentionDuration' = 'interval 90 days',
    'delta.deletedFileRetentionDuration' = 'interval 90 days');

(spark.readStream
    .option("readChangeFeed", "true")   # delete prijdou jako _change_type = 'delete'
    .table("banka.silver.transakce")
    .writeStream
    .option("checkpointLocation", "/Volumes/banka/audit/checkpoints/transakce_history")
    .trigger(availableNow=True)
    .toTable("banka.audit.transakce_history"))

Granularita („grain") říká, co reprezentuje jeden řádek tabulky. Je to nejtěžší reverzibilní rozhodnutí v modelování: jednou agregovaná data už nikdy nerozagregujete. Pokud minutový agregát říká „průměrná teplota senzoru 75 °C", nikdy z něj nezjistíte, ve které milisekundě přišla špička.

Grain faktové tabulky určuje kombinace dimenzních klíčů: „jeden řádek na produkt, zákazníka, prodejnu a den". Přidáte-li hodinu, počet řádků násobíte. Dokumentace doporučuje grain explicitně deklarovat jako kontrakt („tato tabulka obsahuje jeden řádek na položku objednávky") dřív, než přidáte první sloupec. Volba je pak mezi atomic grain (nejjemnější detail ze zdroje — maximální flexibilita) a aggregate grain (předsumarizovaná data — rychlejší dotazy, omezené otázky). Časté řešení: držet obojí a agregáty udržovat jako materialized views nad atomickými daty.

U dimenzí granularita znamená způsob verzování: jeden řádek na zákazníka (Type 1), na verzi zákazníka (Type 2), nebo na zákazníka a období (periodické snapshoty). Grain dimenze musí sedět ke grainu faktů — transakce odkazující na verzi 5 zákazníka musí tu verzi v dimenzi najít.

Rozhodnutí ovlivňují čtyři síly: byznys otázky (nejdetailnější požadovaná analýza je dolní mez), dotazové vzory (příliš jemná data zdražují běžné agregace), náklady (jemnější grain = více řádků = více storage i compute; agregace senzorických dat na sekundy/minuty umí srazit počty řádků o 99 %) a compliance — finanční instituce často musí držet transakční detail bez ohledu na cenu.

U managed tables spravuje Unity Catalog metadata i datové soubory — data leží v managed storage lokaci schématu, katalogu nebo metastoru. U external tables spravuje Unity Catalog jen metadata; soubory leží v lokaci, kterou určíte klauzulí LOCATION nad registrovanou external location, a za jejich životní cyklus odpovídáte vy.

Kdo čeká, že „managed" znamená jen „Databricks mi vybral cestu", podceňuje, co všechno tím získává. Plná kontrola nad soubory umožňuje Unity Catalogu exkluzivní funkce: predictive optimization (automatická komprese a vacuum), automatic liquid clustering (výběr clustering klíčů podle dotazů), metadata caching a automatický úklid souborů po dropu. Smazaná managed tabulka jde vrátit příkazem UNDROP TABLE — výchozí okno je 7 dní a je konfigurovatelné v rozsahu 7–30 dní. Teprve po uplynutí tohoto okna Databricks datové soubory smaže, typicky do 48 hodin. Přesné hodnoty ověřte v dokumentaci.

External tables mají legitimní use-cases: data musí přežít nezávisle na workspace, čtou/zapisují je nástroje mimo Databricks, migrujete z Hive metastore bez přesunu souborů, nebo potřebujete formáty mimo Delta/Iceberg. Počítejte ale s tím, že přímý přístup do storage obchází přístupová práva i audit Unity Catalogu — pro řízené sdílení je lepší Delta Sharing (viz sekce 5.6). A neregistrujte tutéž external tabulku ve více metastorech; změny se mezi nimi nepropagují.

Všechny tři techniky stojí na stejném základu: data skipping. Delta Lake si pro každý soubor drží statistiky (min/max, počty nulls) a dotaz s filtrem přeskočí soubory, které hledané hodnoty obsahovat nemohou. Skipping ale funguje jen tehdy, když jsou související záznamy fyzicky pohromadě — a přesně to clustering techniky zařizují.

Liquid clustering je doporučený přístup pro nové tabulky (a v Public Preview i pro managed Iceberg tabulky — stav ověřte v dokumentaci). Na rozdíl od partitioningu umí změnit strategii bez přepisu dat: klíče definujete přes CLUSTER BY (až 4 sloupce), fyzickou organizaci provádí inkrementální OPTIMIZE, a když se dotazové vzory změní, prostě klíče přepnete přes ALTER TABLE.

-- faktova tabulka s liquid clusteringem (az 4 klice)
CREATE TABLE banka.gold.fakt_transakce (
    transaction_id STRING,
    customer_sk    BIGINT,
    branch_id      STRING,
    transaction_date DATE,
    amount         DECIMAL(12,2)
)
CLUSTER BY (transaction_date, customer_sk);

OPTIMIZE banka.gold.fakt_transakce;          -- inkrementalni clustering

-- zmena dotazovych vzoru? zadny prepis tabulky:
ALTER TABLE banka.gold.fakt_transakce CLUSTER BY (branch_id, transaction_date);
OPTIMIZE banka.gold.fakt_transakce FULL;     -- preusporadat i stara data

-- nebo vyber klicu nechat na platforme (vyzaduje predictive optimization)
-- CREATE TABLE potrebuje definici sloupcu nebo AS SELECT
CREATE TABLE banka.gold.objednavky (
    order_id     STRING,
    customer_sk  BIGINT,
    order_date   DATE,
    amount       DECIMAL(12,2)
)
CLUSTER BY AUTO;

-- automatiku lze zapnout i na existujici tabulce
ALTER TABLE banka.gold.objednavky CLUSTER BY AUTO;

Z-ORDER je předchůdce liquid clusteringu: OPTIMIZE … ZORDER BY (…) kolokuje související data do stejných souborů, ale aplikuje se jen během OPTIMIZE, změna klíčů znamená plný přepis a nabízí jen transaction-level konkurenci (liquid clustering podporuje row-level). Potkáte ho u zděděných tabulek; migrace je přímočará — ALTER TABLE … CLUSTER BY (…) na nepartitionované tabulce a poté OPTIMIZE … FULL.

V roli data engineera retailové banky navrhnete a postavíte datový model v Unity Catalogu: zákaznickou dimenzi se SCD Type 2 historií, transakční faktovou tabulku s liquid clusteringem, audit trail pro FCA compliance nad Change Data Feed a inspekci i obnovu předchozích verzí tabulek přes Delta time travel.

▶ Otevřít lab na GitHubu (EN) · Learn modul k tématu — s krátkými výukovými videy