Governance objektů Unity Catalogu

Governance nezačíná u oprávnění, ale u metadat. Dobře popsané tabulky a sloupce jsou to, co odděluje důvěryhodný data estate od skládky parquet souborů — a s nástupem AI-driven discovery nástrojů (např. AI/BI Genie) platí přímá úměra: kvalita komentářů a tagů určuje kvalitu odpovědí, které nad vašimi daty AI vygeneruje.

Komentáře jsou volný popisný text — lze je přidat na katalog, schema, tabulku, view i jednotlivé sloupce, a to už při vytvoření tabulky nebo dodatečně. Podporují i markdown:

-- komentare primo v definici tabulky
CREATE TABLE sales.customers.profiles (
    customer_id  BIGINT COMMENT 'Unique identifier for each customer',
    email        STRING COMMENT 'Customer primary email address',
    created_date DATE   COMMENT 'Date when customer account was created'
);

-- dodatecne pridani / uprava komentare
COMMENT ON TABLE sales.customers.profiles
IS 'Contains customer profile information including contact details';

ALTER TABLE sales.customers.profiles
ALTER COLUMN email COMMENT 'Primary email address used for notifications';

Tagy jsou key-value páry pro strukturovanou klasifikaci — na rozdíl od komentářů se podle nich dá vyhledávat a stavět na nich politiky:

-- tagy na tabulce a na sloupci
ALTER TABLE sales.customers.profiles
SET TAGS ('domain' = 'sales', 'data_classification' = 'internal');

ALTER TABLE sales.customers.profiles
ALTER COLUMN email
SET TAGS ('pii' = 'email', 'sensitivity' = 'high');

-- odebrani tagu
ALTER TABLE sales.customers.profiles UNSET TAGS ('domain');

Limity: max. 50 tagů na objekt, 1 000 column tagů na tabulku, klíč i hodnota max. 256 znaků; klíče jsou case-sensitive. A protože se tagy ukládají jako plain text, nikdy do nich nedávejte citlivé hodnoty.

K průzkumu slouží Catalog Explorer (záložky Columns, Sample Data, Details, History, Insights) nebo SQL:

SHOW CATALOGS;
SHOW SCHEMAS IN sales;
SHOW TABLES IN sales.customers LIKE 'profiles_*';
DESCRIBE TABLE EXTENDED sales.customers.profiles;
SHOW TBLPROPERTIES sales.customers.profiles;

Row filtry a masky z kapitoly 4 (sekce 4.4) mají jednu slabinu: konfigurují se tabulku po tabulce. Attribute-based access control (ABAC) tento problém obrací — místo oprávnění pro každou kombinaci tabulka × uživatel definujete policy navázanou na tag. Otagujete-li novou tabulku, politika se na ni aplikuje automaticky, bez další konfigurace.

Základem jsou governed tagy — na rozdíl od standardních tagů mají centrálně definované klíče a povolené hodnoty a přiřazovat je smí jen uživatelé s oprávněním ASSIGN:

Governed tag vytvoříte v UI: Catalog → Governance → Governed Tags — např. klíč pii s povolenými hodnotami ssn, email, address. Tagy na katalogu a schématu se dědí na všechny objekty uvnitř; tagy na sloupcích se nedědí.

Policy pak spojuje UDF funkci, cílovou skupinu a podmínku na tag:

-- maskovaci funkce (deterministicka, bez externich volani)
CREATE OR REPLACE FUNCTION mask_ssn(ssn STRING)
RETURNS STRING
DETERMINISTIC
RETURN '***-**-****';

-- centralni policy: maskuj kazdy sloupec s tagem pii=ssn v celem schematu
CREATE POLICY mask_sensitive_ssn
ON SCHEMA sales.customers
COLUMN MASK mask_ssn
TO `all_users`
EXCEPT `compliance_team`
FOR TABLES
MATCH COLUMNS
    has_tag_value('pii', 'ssn') AS ssn_col
ON COLUMN ssn_col;

Analogicky funguje ROW FILTER policy na úrovni katalogu či schématu — jeden příkaz pokryje všechny tabulky, které mají sloupec s daným tagem. Policies se dědí: politika na katalogu platí pro všechna schémata a tabulky uvnitř. Na jednu tabulku se smí uplatnit jen jeden row filter a na sloupec jedna maska — kolize policies vede k zablokování přístupu s chybou.

Delta Lake si uchovává historii — transakční log a staré verze datových souborů. To umožňuje time travel, ale také to znamená, že smazaná data fyzicky nezmizí, dokud je neodstraní VACUUM. Retenci řídí dvě vlastnosti tabulky:

Obě vlastnosti pracují společně — chcete-li 30 dní historie i u tabulek s častým VACUUM, nastavte obě:

ALTER TABLE sales.customers.transactions
SET TBLPROPERTIES (
    'delta.logRetentionDuration' = 'interval 30 days',
    'delta.deletedFileRetentionDuration' = 'interval 30 days'
);

-- VACUUM: default prah 7 dni, nebo explicitne
VACUUM sales.customers.transactions;
VACUUM sales.customers.transactions RETAIN 168 HOURS;

Retence úzce souvisí s GDPR „právem být zapomenut": DELETE záznam pouze označí v nové verzi tabulky, fyzické odstranění zajistí až VACUUM. Mazání navíc musíte propagovat vrstvami medallionu — materialized views se srovnají při refreshi, ale streaming tables očekávají append-only zdroj a upstream delete je rozbije; řešením je skipChangeCommits:

# stream ignoruje upstream delety a updaty
spark.readStream.option('skipChangeCommits', 'true').table("bronze.users")

Ruční plánování VACUUM/OPTIMIZE přes stovky tabulek je přesně ta práce, kterou nechcete dělat. Predictive optimization ji pro managed tabulky automatizuje — spouští VACUUM, OPTIMIZE i ANALYZE podle skutečného využití tabulek:

ALTER SCHEMA sales.customers ENABLE PREDICTIVE OPTIMIZATION;

-- monitoring probehle udrzby vcetne nakladu
SELECT * FROM system.storage.predictive_optimization_operations_history;

Unity Catalog zachytává runtime data lineage automaticky — pro všechny jazyky, až na úroveň sloupců, včetně vazeb na notebooky, joby a dashboardy. Nemusíte nic instrumentovat: stačí, aby dotazy běžely na Unity Catalog-enabled compute a tabulky se referencovaly třívrstvým jménem catalog.schema.table (přístup přes přímou cestu k souborům lineage negeneruje).

V Catalog Exploreru otevřete u tabulky záložku Lineage a tlačítkem See Lineage Graph interaktivní vizualizaci: uzly jsou tabulky, šipky směr toku, ikonou + rozbalujete další úrovně upstream/downstream. Kliknutím na hranu zobrazíte, který notebook či job vazbu vytvořil; záložky Jobs a Dashboards ukážou konzumenty tabulky — ideální pro impact analysis před změnou schématu.

Pro reporting slouží dvě system tables:

-- nejcasteji dotazovane tabulky za posledni tyden
SELECT
  source_table_full_name,
  COUNT(DISTINCT event_id) AS query_count
FROM system.access.table_lineage
WHERE event_date > CURRENT_DATE() - INTERVAL 7 DAYS
  AND source_table_full_name IS NOT NULL
GROUP BY source_table_full_name
ORDER BY query_count DESC
LIMIT 10;

Kdo, kdy a k čemu přistoupil — na to odpovídá audit log system table system.access.audit. Konfiguruje se na úrovni accountu, pokrývá všechny workspaces připojené k metastoru a z compliance šetření dělá obyčejný SQL dotaz místo prohledávání log souborů.

Klíčové sloupce: event_time, user_identity, workspace_id (0 = account-level událost), service_name (např. unityCatalog, notebook, clusters), action_name (např. getTable, updatePermissions), request_params, response a source_ip_address.

-- kdo pristoupil ke konkretni tabulce za poslednich 7 dni
SELECT
  user_identity.email AS user_email,
  action_name AS access_type,
  event_time
FROM system.access.audit
WHERE request_params.full_name_arg = 'catalog.schema.table_name'
  AND action_name IN ('getTable', 'createTable', 'deleteTable')
  AND event_date > CURRENT_DATE() - INTERVAL 7 DAYS
ORDER BY event_time DESC;

-- audit zmen opravneni v metastoru
SELECT event_time, user_identity.email, request_params.securable_full_name, request_params.changes
FROM system.access.audit
WHERE service_name = 'unityCatalog' AND action_name = 'updatePermissions'
ORDER BY event_time DESC;

Výchozí logování nezachytává plný text spouštěných příkazů. Pro detailní forenzní stopu zapněte verbose audit logs (Admin Settings → Advanced) — přibudou události runCommand (notebooky, joby) a commandSubmit (Databricks SQL). Samotné zapnutí/vypnutí verbose logování je auditovaná událost.

Pro centrální monitoring lze logy přes Azure diagnostic settings doručovat do Log Analytics (KQL dotazy, dashboardy, typická latence ~15 minut), Storage accountu (levná dlouhodobá archivace) nebo Event Hubs (real-time streaming do SIEM). Kombinace „system table pro ad-hoc šetření + SIEM pro kontinuální monitoring" pokryje obě potřeby.

Delta Sharing umožňuje sdílet živá data s partnery a jinými organizacemi bez kopírování — příjemce čte přímo z vašich dat, vy si držíte plnou kontrolu nad tím, kdo vidí co. Strategické rozhodnutí číslo jedna je volba protokolu:

Share je securable objekt — kolekce sdílených assetů. Recipient reprezentuje příjemce. Celý životní cyklus zvládnete v SQL:

CREATE SHARE IF NOT EXISTS partner_analytics
COMMENT 'Sales analytics data for partner integration';

ALTER SHARE partner_analytics ADD TABLE catalog.schema.sales_summary;
ALTER SHARE partner_analytics ADD TABLE catalog.schema.transactions WITH HISTORY;

-- D2D recipient pres sharing identifier (prijemce jej zjisti: SELECT CURRENT_METASTORE())
CREATE RECIPIENT IF NOT EXISTS contoso_analytics
USING ID 'azure:westeurope:a1b2c3d4-e5f6-7890-abcd-ef1234567890';

GRANT SELECT ON SHARE partner_analytics TO RECIPIENT contoso_analytics;

-- prehled a odebirani
SHOW SHARES;
SHOW ALL IN SHARE partner_analytics;
REVOKE SELECT ON SHARE partner_analytics FROM RECIPIENT contoso_analytics;

Když různí příjemci mají vidět různé výseky dat, nesdílejte celou tabulku — použijte dynamic view s funkcí CURRENT_RECIPIENT() nad custom properties příjemce:

ALTER RECIPIENT regional_partner SET PROPERTIES ('country_region' = 'US');

CREATE VIEW catalog.schema.regional_sales AS
SELECT * FROM catalog.schema.all_sales
WHERE region = CURRENT_RECIPIENT('country_region');

Aktivitu sledujte v auditu: událost deltaSharingQueriedTable (open sharing) a generateTemporaryTableCredential (D2D). Zavedete-li měsíční revizi aktivních recipientů, kontrolu obsahu shares a sledování neúspěšných přístupů, máte governance smyčku uzavřenou. Delegujte správu přes specifická privilegia (CREATE SHARE, CREATE RECIPIENT, SET SHARE PERMISSION) skupinám data stewardů — ne plošným metastore adminům.

Automobilka AutoSphere AG buduje platformu pro connected vehicles: ingestuje telemetrii z milionů vozů a spravuje servisní záznamy. V labu vytvoříte tabulky vehicle_telemetry a service_records, opatříte je komentáři a PII tagy, nastavíte Delta retenci a spustíte VACUUM, prozkoumáte lineage graf v Catalog Exploreru a nakonec budete lineage i audit události dotazovat programově přes system tables.

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