Het objectmodel van Unity Catalog

Eén model voor elk beheerd asset

Governance mislukt als elk soort asset eigen regels heeft: één rechtensysteem voor tabellen, een ander voor bestanden, nog een ander voor modellen en een spreadsheet voor de rest. Unity Catalog vervangt dat door één objectmodel en één rechtenmodel. Begrijp je het model, dan is elke latere les in deze cursus een variatie erop.

In deze les lopen we langs de objecten, de namespace, het verschil tussen managed en extern en de objecten boven catalogs. Het inschakelen van Unity Catalog op een nieuw account behandelen we niet. Dat is een onderwerp van platforminrichting.

Securable objects

De Databricks-documentatie beschrijft elk beheerd asset als een securable object: een object waarop je rechten kunt geven aan gebruikers, service principals of groepen. Hetzelfde rechtenmodel geldt voor alle objecten.

De meeste objecten waarmee je werkt, staan in een namespace met drie niveaus: catalog.schema.object.

De documentatie noemt ook services (model- en MCP-services) onder de objecten op het derde niveau. Geregistreerde modellen zijn in het rechtensysteem een soort functie, daarom geef je EXECUTE ON FUNCTION om een groep een model te laten gebruiken.

Boven de catalogs, direct onder de metastore, staan objecten die in geen enkele catalog zitten: storage credentials, external locations, connections (voor Lakehouse Federation) en shares. Ze worden over catalogs gedeeld en verdienen dus strengere controle dan een tabel.

Managed en extern

Tabellen en volumes bestaan in twee soorten.

• Managed: Unity Catalog regelt zowel de toegang als de levenscyclus van de bestanden. Verwijder je de tabel, dan gaat de data mee, volgens het bewaargedrag van het platform.
• Extern: Unity Catalog regelt alleen de toegang. De bestanden staan op een locatie die je zelf beheert en bij het verwijderen van de tabel blijven de bestanden staan.

Onze standaard is managed objecten voor alles wat we maken. Gebruik externe objecten als een ander systeem dezelfde bestanden moet lezen of schrijven, of als een contract een opslaglocatie afdwingt. Externe objecten hebben een storage credential en een external location nodig, en beide zijn objecten op metastore-niveau die zorgvuldige rechten vragen.

Eigenaarschap

Elk securable heeft een eigenaar. Eigenaren hebben alle rechten op het object, inclusief het recht om ze te geven. De eigenaar is de krachtigste positie op een object, dus het mag nooit een persoon zijn.

• Maak een groep eigenaar van elke catalog, elk schema, elke tabel en elk volume. Een persoon vertrekt, een groep blijft.
• Gebruik MANAGE spaarzaam. Het recht MANAGE laat een houder rechten beheren, eigenaarschap overdragen, hernoemen en een object verwijderen zonder eigenaar te zijn. Het zit niet in ALL PRIVILEGES.
• Draag bewust over. Eigenaarschap overdragen is één statement, wat het makkelijk maakt en het waard om achter review te zetten:

ALTER TABLE prd_finance.gold.invoices OWNER TO `grp-uc-prd-finance-gold-owner`;

De namespace ontwerpen

Namen dragen betekenis en rechten hechten eraan, dus ontwerp de namespace voor de eerste tabel bestaat. Ons patroon:

• Eén catalog per omgeving en domein, bijvoorbeeld dev_finance, test_finance, acc_finance, prd_finance. Het omgevingsvoorvoegsel voorkomt dat een omgeving aan de data van een andere komt.
• Eén schema per laag of vakgebied, bijvoorbeeld bronze, silver, gold, reference, sandbox.
• Namen in kleine letters met underscores, zonder spaties en zonder datums in namen.
• Eén eigenaarsgroep per catalog en per schema.

Waarom niet één catalog voor alles? Omdat rechten naar beneden overerven. Een recht op een catalog geldt voor elk bestaand en toekomstig schema daarin. Een catalog die domeinen overspant, dwingt je op veel schema's één voor één rechten te geven en één fout stelt meerdere domeinen bloot.

-- Maak de structuur voor één domein en omgeving. Draai via de pipeline, niet met de hand.
CREATE CATALOG IF NOT EXISTS dev_finance;
CREATE SCHEMA  IF NOT EXISTS dev_finance.bronze;
CREATE SCHEMA  IF NOT EXISTS dev_finance.silver;
CREATE SCHEMA  IF NOT EXISTS dev_finance.gold;

Ontdekcommando's die je gebruikt

Je kunt het model met gewone SQL inspecteren:

SHOW CATALOGS;
SHOW SCHEMAS IN dev_finance;
SHOW TABLES  IN dev_finance.gold;
SHOW GRANTS  ON SCHEMA dev_finance.gold;       -- wie kan wat op dit schema
DESCRIBE EXTENDED dev_finance.gold.invoices;   -- eigenaar, type (managed of extern), locatie

SHOW GRANTS is het commando dat je het vaakst draait als iemand zegt: "ik zie de tabel niet". Het antwoord is bijna altijd een ontbrekende USE CATALOG of USE SCHEMA op het pad ernaartoe.

Tags en commentaar

Tabellen, kolommen en andere objecten accepteren commentaar en tags. Gebruik ze vanaf de eerste dag: commentaar dat het doel en de dataeigenaar noemt en tags die de data classificeren, zoals pii of confidential. In les 4 zie je hoe tags beleid voeden. Onze privacy-by-design-regel vraagt om data te classificeren voor we ze laden, en tags zijn waar die classificatie leeft.

Veelgemaakte fouten

• Een persoon als eigenaar. Toegang breekt als hij vertrekt.
• Eén catalog voor alle omgevingen. Een dev-job kan dan naar productiedata schrijven.
• Externe tabellen uit gewoonte. De levenscyclus van de opslag, en het risico, blijven bij jou.
• Geen commentaar en geen tags. De catalogus wordt een lijst namen die niemand kan duiden.
• Rechten op de tabel geven als het schema het juiste niveau is. Les 3 legt het patroon uit.

Samenvatting

Elk beheerd asset is een securable object met een eigenaar en een plek in de namespace catalog.schema.object. Gebruik één catalog per omgeving en domein, één schema per laag, standaard managed objecten en groepen als eigenaar. Objecten op metastore-niveau zoals storage credentials en external locations vragen de strengste rechten.

Volgende les: identiteit, de vraag wie er vraagt.