Objekty v Unity Catalogu

Vše, co v Unity Catalogu vytvoříte, žije v třívrstvém namespace: catalog.schema.object. Nad těmito třemi vrstvami stojí metastore — jeden na region, sdílený všemi workspaces v daném regionu. Metastore sami nevytváříte pro každý projekt; je to střecha, pod kterou stavíte katalogy.

Než začnete cokoliv vytvářet, dohodněte si naming conventions. Unity Catalog má několik tvrdých pravidel, která vám rozhodování zjednoduší:

Doporučený vzor je lowercase s podtržítky (customer_data, sales_summary) — camelCase se stejně převede na lowercase a vznikne jen zmatek. Views prefixujte vw_, dočasné staging tabulky tmp_. Názvy schémat zarovnejte s vrstvami medallion architektury: bronze, silver, gold — pak z sales_data.gold.monthly_revenue každý na první pohled pozná, co drží v ruce.

U katalogů se rozhodujete mezi dvěma strategiemi: podle domény (sales_data, finance_data) nebo podle prostředí (dev, test, prod). Kombinace {domena}_{prostredi} — tedy sales_dev, sales_prod — škáluje nejlépe, ale roste vám počet katalogů, takže potřebujete disciplínu ve správě.

Catalog je nejvyšší kontejner a primární jednotka izolace dat: každý katalog může mít vlastní storage location, bezpečnostní hranice i přístupové politiky. K vytvoření potřebujete být metastore admin, nebo mít privilegium CREATE CATALOG. Každý nový katalog automaticky dostane dvě schémata: default a information_schema.

-- katalog s dedikovanym managed storage
CREATE CATALOG IF NOT EXISTS prod_catalog
MANAGED LOCATION 'abfss://prod-data@mystorageaccount.dfs.core.windows.net/catalog-root'
COMMENT 'Production catalog with dedicated ADLS Gen2 storage';

Managed storage location určuje, kam Unity Catalog fyzicky ukládá soubory managed tabulek a volumes v katalogu. Bez ní padají managed objekty do defaultního úložiště metastore — a pokud metastore default nemá, je MANAGED LOCATION při vytvoření katalogu povinná. K jejímu nastavení potřebujete existující external location a privilegium CREATE MANAGED STORAGE.

Schema je druhá vrstva namespace a organizuje data uvnitř katalogu do logických celků — typicky jeden use case, projekt nebo tým. V Databricks narazíte i na termín „database": CREATE DATABASE je alias pro CREATE SCHEMA, jde o totéž. K vytvoření potřebujete USE CATALOG a CREATE SCHEMA na nadřazeném katalogu.

CREATE SCHEMA IF NOT EXISTS prod_catalog.customer_analytics
COMMENT 'Customer behavior and segmentation analysis';

-- schema s vlastnim ulozistem (napr. finance kvuli compliance)
CREATE SCHEMA IF NOT EXISTS prod_catalog.financial_data
MANAGED LOCATION 'abfss://finance@mystorageaccount.dfs.core.windows.net/schema-data';

Tři osvědčené vzory organizace schémat:

Managed storage na úrovni schématu je volitelná — pokud ji nezadáte, managed tabulky používají úložiště katalogu (případně metastore). Hierarchie fallbacku je tedy: schema → catalog → metastore.

Managed vs. external tabulky

Managed table je default: Databricks spravuje metadata i datové soubory, formát je Delta Lake (ACID transakce, time travel, schema enforcement) a při DROP TABLE se smažou metadata i data. External table jen registruje metadata nad daty v externím úložišti — DROP odstraní pouze registraci v katalogu, soubory zůstanou.

-- managed tabulka (default, format Delta Lake)
CREATE TABLE production.sales.sales_transactions (
  transaction_id BIGINT,
  customer_id INT,
  amount DECIMAL(10,2),
  transaction_date DATE
);

-- external tabulka nad existujicimi CSV soubory
CREATE EXTERNAL TABLE production.sales.archived_sales
USING CSV
LOCATION 'abfss://container@storage.dfs.core.windows.net/sales/archive'
OPTIONS (header 'true', inferSchema 'true');

Primary a foreign keys

Unity Catalog umí definovat PRIMARY KEY a FOREIGN KEY constraints — ale pozor na očekávání z klasických databází:

CREATE TABLE customers (
  customer_id BIGINT NOT NULL,
  customer_name STRING,
  CONSTRAINT customers_pk PRIMARY KEY (customer_id)
);

CREATE TABLE orders (
  order_id BIGINT NOT NULL PRIMARY KEY,
  customer_id BIGINT,
  total_amount DECIMAL(10,2),
  CONSTRAINT orders_customers_fk FOREIGN KEY (customer_id)
    REFERENCES customers(customer_id)
);

Views: standardní, dynamické, materializované

-- dynamic view: maskovani sloupce podle skupiny
CREATE VIEW sales_redacted AS
SELECT user_id,
  CASE WHEN is_account_group_member('auditors') THEN email
       ELSE 'REDACTED' END AS email,
  product, total
FROM sales_raw;

-- materialized view s planovanym refreshem
CREATE MATERIALIZED VIEW daily_sales_summary
SCHEDULE EVERY 1 DAY
AS SELECT transaction_date,
  COUNT(*) AS transaction_count,
  SUM(amount) AS total_sales
FROM sales_transactions
GROUP BY transaction_date;

Materialized views podporují inkrementální refresh — zpracují jen změněná data. Podmínkou je, aby zdrojové Delta tabulky měly zapnutý row tracking (delta.enableRowTracking = true). Zapnutí na velké existující tabulce chvíli trvá, povyšuje protokol tabulky a je nevratné.

Volume je objekt Unity Catalogu pro netabulková data — CSV k ingestion, obrázky, audio, ML modely. Sedí na třetí úrovni namespace (catalog.schema.volume) a přenáší stejný governance model, jaký znáte z tabulek, na soubory.

Stejně jako u tabulek volíte managed (úložiště i lifecycle řeší Unity Catalog; po dropu jsou soubory označeny ke smazání po retenční lhůtě) nebo external (soubory leží na vámi zadané cestě a drop odstraní jen registraci). External volume použijte, když k souborům přistupují i systémy mimo Databricks nebo když governance přidáváte nad existující úložiště.

-- managed volume
CREATE VOLUME IF NOT EXISTS dev_catalog.bronze_schema.landing_files
COMMENT 'Landing area for CSV files from external systems';

-- external volume nad existujicim ulozistem
CREATE EXTERNAL VOLUME prod_catalog.silver_schema.ml_models
LOCATION 'abfss://models@mystorageaccount.dfs.core.windows.net/production/';

-- prava: cteni a zapis pro skupinu
GRANT READ VOLUME, WRITE VOLUME ON VOLUME dev_catalog.bronze_schema.landing_files
TO `data-engineers`;

K souborům přistupujete jednotnou POSIX-style cestou /Volumes/<catalog>/<schema>/<volume>/<cesta> — funguje ve Sparku, pandas, SQL i dbutils.fs, bez credentials a connection stringů:

# stejna cesta pro Spark i pandas
df = spark.read.format("csv").load("/Volumes/dev_catalog/bronze_schema/landing_files/data.csv")

import pandas as pd
pdf = pd.read_csv("/Volumes/dev_catalog/bronze_schema/landing_files/data.csv")

# sprava souboru
dbutils.fs.ls("/Volumes/dev_catalog/bronze_schema/landing_files")

Funkce jako governed objekty

Funkce v Unity Catalogu nejsou jen syntaktický cukr — jsou to governed objekty s vlastníkem, privilegii a sledováním použití. Definujete je jednou a voláte odkudkoliv, takže výpočet slevy nebo klasifikace známky je v celé organizaci konzistentní. Podporovány jsou scalar i table-valued funkce v SQL nebo Pythonu:

-- SQL scalar funkce
CREATE FUNCTION dev_catalog.finance_schema.calculate_discount(price DOUBLE, discount_rate DOUBLE)
RETURNS DOUBLE
RETURN price * (1 - discount_rate);

-- Python funkce (bezi na serverless / pro SQL warehouse)
CREATE FUNCTION dev_catalog.analytics_schema.normalize_text(input_text STRING)
RETURNS STRING
LANGUAGE PYTHON
AS $$
  return input_text.lower().strip() if input_text else None
$$;

-- table-valued funkce
CREATE FUNCTION dev_catalog.utils_schema.split_to_rows(input_array ARRAY<STRING>)
RETURNS TABLE(value STRING)
RETURN SELECT explode(input_array) AS value;

Pro vícekrokové workflow (validace → transformace → load) existují SQL stored procedures — CREATE PROCEDURE s IN/OUT/INOUT parametry, proměnnými a řízením toku, volané přes CALL. Vyžadují Databricks Runtime 17.0+; přesný stav podpory ověřte v dokumentaci.

ALTER: vlastnictví, tagy, struktura

-- prevod vlastnictvi katalogu na skupinu
ALTER CATALOG dev_catalog SET OWNER TO `data_engineering_team`;

-- governance tagy pro klasifikaci a dohledatelnost
-- nazev tagu i hodnota musi byt retezcove literaly
ALTER CATALOG dev_catalog SET TAGS (
  'environment' = 'development',
  'cost_center' = 'engineering',
  'data_classification' = 'internal'
);

-- upravy struktury tabulky bez rebuildu
ALTER TABLE dev_catalog.sales_schema.orders
ADD COLUMN shipping_carrier STRING COMMENT 'Name of the shipping carrier';

ALTER TABLE dev_catalog.sales_schema.orders
ALTER COLUMN quantity TYPE BIGINT;

ALTER TABLE zvládne přidání, přejmenování i odstranění sloupců a rozšíření typů (INT → BIGINT) při zachování dat — vyžaduje privilegium MODIFY. Rozšiřování typů (type widening) funguje na Delta tabulkách od Databricks Runtime 15.2 a výš; má-li se typ rozšířit automaticky už při ingesci, zapněte na tabulce delta.enableTypeWidening. Podporované dvojice typů a přesný stav funkce ověřte v dokumentaci. Přejmenování sloupce potřebuje zapnutý Delta column mapping. Tagy jsou prohledávatelná metadata: základ pro klasifikaci dat, cost management i pozdější automatizovanou governance.

Ne všechna data máte v lakehousu — a ne všechna tam potřebujete stěhovat. Lakehouse Federation umožňuje dotazovat externí databáze (PostgreSQL, MySQL, Azure SQL, Snowflake, BigQuery…) přímo z Databricks, přičemž přístup řídí, audituje a lineage sleduje Unity Catalog. Ideální pro ad-hoc analýzy nad živými provozními daty, proof-of-concept bez ETL a postupnou migraci.

Architektura stojí na dvou objektech: connection uchovává technické detaily připojení (JDBC host, port, credentials — ideálně přes Databricks secrets) a foreign catalog zrcadlí konkrétní externí databázi do namespace Unity Catalogu. Jedna connection může obsloužit více foreign catalogů (více databází na stejném serveru).

-- 1) connection: credentials pres Databricks secrets, ne v plaintextu
CREATE CONNECTION postgresql_prod TYPE postgresql
OPTIONS (
  host 'prod-db.example.com',
  port '5432',
  user secret ('prod-secrets','postgres-user'),
  password secret ('prod-secrets','postgres-password')
);

-- 2) foreign catalog zrcadlici databazi customers
CREATE FOREIGN CATALOG IF NOT EXISTS prod_customer_data
USING CONNECTION postgresql_prod
OPTIONS (database 'customers');

-- 3) dotaz jako na beznou tabulku Unity Catalogu
SELECT customer_id, SUM(transaction_amount) AS total_spent
FROM prod_customer_data.public.transactions
GROUP BY customer_id;

Metadata se synchronizují automaticky při každém dotazu. U vysokofrekvenčních dotazů to může být pomalé — pak metadata občerstvujte plánovaně přes REFRESH FOREIGN CATALOG / SCHEMA / TABLE (např. z Lakeflow Jobs) a dotazy poběží nad cache.

AI/BI Genie umožňuje business uživatelům ptát se na data přirozeným jazykem — Genie z otázky vygeneruje SQL nad tabulkami Unity Catalogu. Aby generovalo správné SQL, potřebuje kontext: k tomu slouží knowledge store objektu Genie Agent (dříve Genie space), kde metadata upravujete na jeho úrovni, aniž byste měnili podkladové objekty v katalogu.

Genie Agent stavíte nad výběrem tabulek (max. 25, doporučeno začít s pěti a méně). Pak vrstvíte kontext:

Tady se vyplácí poctivá práce z předchozích sekcí: PK/FK constraints ze sekce 3.4, popisné komentáře a konzistentní jména Genie automaticky vytěží při zakládání Genie Agenta (knowledge mining) a uloží jako join relationships. Dobře anotovaný katalog znamená méně ruční konfigurace.

Konfigurace Genie je iterativní proces: otestujte Genie Agenta vlastními otázkami, přes Show generated code zkontrolujte vygenerované SQL, chybné odpovědi opravte a uložte jako novou instrukci (Add as instruction). Průběžně sledujte zpětnou vazbu uživatelů v tabu Monitoring a měřte přesnost benchmark otázkami.

Lakeside University buduje datovou platformu pro studijní agendu: v labu vytvoříte katalog edu_dev s medallion schématy (bronze/silver/gold), managed tabulky studentů, kurzů a zápisů s PK/FK constraints, view a materialized view pro analytické dotazy, managed volume pro CSV soubory, SQL funkci pro klasifikaci známek a přes ALTER aplikujete governance tagy. Volitelně nad datasetem postavíte Genie Agenta.

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