De lakehouse en de medallion-lagen

Eén platform, drie lagen vertrouwen

De meeste problemen op een dataplatform beginnen met dezelfde vraag die niemand kan beantwoorden: "welke tabel kan ik vertrouwen?" De medallion-architectuur beantwoordt die vraag door elke tabel een laag te geven en elke laag een contract. Het is het patroon achter bijna elke pipeline die we bouwen, dus we beginnen de cursus hier.

In deze les definiëren we de lagen, stellen we regels op voor wat in elke laag hoort en laten we zien hoe de lagen op Unity Catalog-namen worden afgebeeld. De werking van ingestie (les 2) en de syntaxis van pipelines (les 3) behandelen we niet.

De lakehouse in één alinea

Een lakehouse bewaart data in open tabelformaten op cloud-objectopslag en zet daar functies van een datawarehouse bovenop: transacties, schemahandhaving, governance en snelle SQL. Op Databricks zijn tabellen Delta-tabellen en beheert Unity Catalog ze. Je hebt één kopie van de data voor engineering, analyse en AI, in plaats van een lake voor bestanden en een warehouse voor rapporten met een kopieerjob ertussen.

Unity Catalog gebruikt een namespace met drie niveaus: catalog.schema.object. Het objectniveau omvat tabellen, views, volumes, functies en modellen. Tabellen en volumes kunnen beheerd (managed) zijn, waarbij Unity Catalog toegang en de levenscyclus van de opslag regelt, of extern, waarbij het alleen de toegang regelt. Begin voor nieuw werk met managed tabellen, tenzij een bestaand opslagcontract externe tabellen afdwingt.

De medallion-lagen

De Databricks-documentatie beschrijft de medallion-architectuur als ontwerppatroon dat een lakehouse indeelt in drie lagen van oplopende kwaliteit: bronze, silver en gold. Het noemt het patroon een aanbevolen werkwijze en geen vereiste. Wij gebruiken het omdat het verantwoordelijkheden duidelijk maakt.

Drie regels houden de lagen eerlijk.

1. Bronze is een getrouw archief. Kun je silver uit bronze herbouwen, dan is een bug in je opschoonlogica een herstart en geen dataverlies. Daarom houdt bronze velden los: een bron die een kolom toevoegt of een type wijzigt, mag de ingestie niet breken.
2. Silver wordt uit bronze gebouwd, niet uit de bron. De documentatie adviseert waar mogelijk streaming-reads uit bronze en geen directe schrijfacties naar silver vanuit de ingestie. Zo houd je één pad voor lineage en één plek om een fout te herstellen.
3. Gold beantwoordt vragen. Een goldtabel bestaat omdat iemand een zakelijke vraag stelt. Leest niemand hem, verwijder hem dan.

Lagen afbeelden op Unity Catalog

Naamgeving is een ontwerpbeslissing, want rechten hechten aan namen. Onze standaard houdt één catalog per omgeving en domein aan, en één schema per laag:

dev_sales.bronze.orders_raw
dev_sales.silver.orders
dev_sales.gold.orders_daily
prd_sales.bronze.orders_raw
prd_sales.silver.orders
prd_sales.gold.orders_daily

Het omgevingsvoorvoegsel (dev, test, acc, prd) geeft elke omgeving een eigen catalog, zodat een pipeline in dev niet per ongeluk naar productie schrijft. Toegang volgt het schema: een readergroep en een contributorgroep per schema. Analisten krijgen reader op gold. Pipelines draaien als service principal met contributor op de laag die ze schrijven. Niemand krijgt schrijfrechten op bronze behalve de ingestie-identiteit. Het rechtenpatroon werken we uit in de governancecursus.

Een klein voorbeeld

De volgende SQL bouwt de drie lagen uit een ruwe ordertabel. Het gebruikt standaard Databricks SQL op Delta-tabellen. In productie gebruik je de declaratieve pipelines van les 3, maar de laaglogica is identiek.

-- Bronze: bewaar wat binnenkwam, voeg laadmetadata toe. Hier geen bedrijfsregels.
CREATE OR REPLACE TABLE dev_sales.bronze.orders_raw AS
SELECT *, current_timestamp() AS _loaded_at
FROM   dev_sales.landing.orders_export;
 
-- Silver: typen afdwingen, duplicaten verwijderen, onbruikbare rijen weglaten.
CREATE OR REPLACE TABLE dev_sales.silver.orders AS
SELECT DISTINCT
  CAST(order_id AS BIGINT)           AS order_id,
  CAST(customer_id AS BIGINT)        AS customer_id,
  CAST(order_ts AS TIMESTAMP)        AS order_ts,
  CAST(amount AS DECIMAL(12,2))      AS amount
FROM   dev_sales.bronze.orders_raw
WHERE  order_id IS NOT NULL AND amount IS NOT NULL;
 
-- Gold: één tabel voor één zakelijke vraag: omzet per dag.
CREATE OR REPLACE TABLE dev_sales.gold.orders_daily AS
SELECT DATE(order_ts) AS order_date, COUNT(*) AS orders, SUM(amount) AS revenue
FROM   dev_sales.silver.orders
GROUP  BY DATE(order_ts);

Zie wat het voorbeeld laat zien: de silverquery verwijdert onbruikbare rijen. In les 3 zie je hoe je die verwijderingen vastlegt in plaats van ze te verbergen.

Waar teams de fout ingaan

• Bronze overslaan. Direct in silver laden bespaart een tabel en kost je de mogelijkheid om opnieuw af te spelen.
• Bedrijfslogica in bronze. Zodra een regel verandert, ben je het origineel kwijt.
• Gold per dashboard. Vijftig bijna identieke goldtabellen zijn een beheerlast. Modelleer per domein en vraag.
• Geen eigenaren. Elk schema heeft een eigenaarsgroep nodig en elke tabel een gedocumenteerd doel en dataeigenaar.
• Ingestiefrequentie uit gewoonte. De documentatie noemt de afweging: continue ingestie heeft de laagste latency en hoogste kosten, getriggerde ingestie zit ertussen, batch is het goedkoopst en traagst. Vraag de business welke versheid nodig is en kies dan.

Samenvatting

Gebruik bronze voor getrouwheid, silver voor vertrouwen en gold voor antwoorden. Geef lagen de vorm van schema's binnen omgevingsspecifieke catalogs, zodat governance de structuur volgt. Bouw silver alleen uit bronze.

Volgende les: data in bronze krijgen met Auto Loader en Lakeflow Connect.