Databricks

Introductie

Modern Data Platform Architecture vergeleek Databricks al met Snowflake en Fabric op workload-niveau: sterk voor ML/Python en complexe Spark-transformaties. Delta Lake, de tabellaag die ACID-garanties aan het lakehouse toevoegt, krijgt een eigen volledige behandeling in Delta Lake; PySpark zelf in PySpark. Dit hoofdstuk vult het gat ertussen in: de platformmechanica van Databricks zelf — hoe clusters werken, hoe Unity Catalog governance regelt, hoe Delta Live Tables declaratieve pipelines mogelijk maakt, en wat Photon en MLflow toevoegen.

Drie Soorten Compute: Clusters en SQL Warehouses

Een veelvoorkomende bron van verwarring bij nieuwkomers: Databricks kent niet één, maar drie verschillende compute-vormen, elk voor een ander doel.

All-purpose clusters zijn bedoeld voor interactief, exploratief werk — een engineer die in een notebook stap voor stap data verkent, met de mogelijkheid om cellen los uit te voeren en tussentijds resultaten te bekijken. Ze blijven draaien totdat je ze expliciet stopt of een inactiviteitstimeout verstrijkt, en zijn relatief duur om continu te laten draaien.

Job clusters worden automatisch aangemaakt bij het starten van een geplande job, en automatisch weer afgebroken zodra de job klaar is — geen doorlopende kosten voor idle-tijd, in tegenstelling tot all-purpose clusters. Voor elke productiepipeline die op een schema draait (via Databricks Workflows) is dit de juiste keuze; het is functioneel vergelijkbaar met Snowflake's auto-suspend, maar dan als het standaardgedrag in plaats van een instelling die je expliciet aanzet.

SQL warehouses zijn een aparte compute-laag, specifiek geoptimaliseerd voor SQL-workloads vanuit BI-tools (Power BI, Tableau) of Databricks SQL zelf — met eigen auto-scaling en auto-stop, losstaand van de Spark-clusters die notebooks en jobs gebruiken. Ze bieden een warehouse-achtige ervaring (vergelijkbaar met een Snowflake virtual warehouse) bovenop dezelfde onderliggende lakehouse-data.

// job_cluster_config.json — ephemeral cluster, alleen actief tijdens de job
{
  "new_cluster": {
    "spark_version": "15.4.x-scala2.12",
    "node_type_id": "Standard_DS3_v2",
    "autoscale": { "min_workers": 2, "max_workers": 8 },
    "autotermination_minutes": 20
  }
}

De vuistregel: all-purpose voor ontwikkelen, job clusters voor productie, SQL warehouses voor BI — het door elkaar gebruiken (bijvoorbeeld een productiepipeline op een permanent draaiend all-purpose cluster) is de meest voorkomende, makkelijk te vermijden kostenfout op dit platform.

Notebooks en Workflows: de Ontwikkelervaring

Databricks' ontwikkelervaring is bewust notebook-gedreven, wat een aantal concrete gewoontes met zich meebrengt die op andere platformen minder centraal staan. Een notebook combineert code-cellen (Python, SQL, Scala of R, zelfs gemengd binnen één notebook via %sql/%python-magic-commands) met markdown-cellen voor documentatie, en wordt cel voor cel interactief uitgevoerd — ideaal voor exploratie, maar met een addertje: de volgorde waarin cellen zijn uitgevoerd kan afwijken van de volgorde waarin ze in het notebook staan, wat reproduceerbaarheidsproblemen geeft als je niet consequent van boven naar beneden werkt.

%run laat een notebook een ander notebook aanroepen, functioneel vergelijkbaar met een Python import, en wordt vaak gebruikt om gedeelde hulpfuncties (connectielogica, herbruikbare transformaties) in een apart notebook te isoleren. Widgets (dbutils.widgets) maken een notebook parametriseerbaar — een datumparameter, een omgevingsnaam — zodat hetzelfde notebook zowel interactief als via een geplande job met andere inputs kan draaien, zonder de code zelf aan te passen.

Databricks Workflows orkestreert vervolgens meerdere notebooks of scripts als taken (tasks) in een DAG, met afhankelijkheden, retries en alerting — Databricks' eigen antwoord op orchestratie, functioneel overlappend met Airflow uit Introduction to Data Engineering maar dan native in het platform, zonder aparte infrastructuur:

// workflow_definition.json (vereenvoudigd)
{
  "name": "daily_orders_pipeline",
  "tasks": [
    { "task_key": "bronze_ingest", "notebook_task": { "notebook_path": "/pipelines/bronze_orders" } },
    { "task_key": "silver_transform", "depends_on": [{ "task_key": "bronze_ingest" }],
      "notebook_task": { "notebook_path": "/pipelines/silver_orders" } }
  ],
  "schedule": { "quartz_cron_expression": "0 0 3 * * ?", "timezone_id": "Europe/Amsterdam" }
}

Databricks Repos: Git-integratie voor Notebooks

Notebooks zijn van nature lastig te versiebeheren — een los .ipynb-bestand met celuitvoer erin geeft rommelige, moeilijk leesbare Git-diffs. Databricks Repos koppelt een workspace-map direct aan een Git-repository, zodat notebooks als broncode (niet als uitvoerbundel) worden opgeslagen, met normale branches, commits en pull requests — de brug die notebook-gedreven ontwikkeling verenigbaar maakt met de CI/CD-principes uit CI/CD for Data Engineering, inclusief het draaien van Workflows tegen een specifieke branch voor pull-request-validatie vóórdat er naar main wordt gemerged.

Instance Pools: Clusterstart Versnellen

Een operationeel detail dat de moeite waard is te kennen: het opstarten van een nieuw cluster (het aanvragen en provisionen van virtuele machines bij de onderliggende cloudprovider) kan enkele minuten duren — vervelend voor job clusters die je juist kort en efficiënt wilt laten draaien. Instance pools houden een voorraad al-opgestarte, maar ongebruikte virtuele machines paraat, zodat een nieuw cluster daaruit kan putten in seconden in plaats van minuten. Dit kost een beetje continue infrastructuur (de pool zelf), in ruil voor aanzienlijk snellere opstarttijden bij frequent draaiende job clusters — een afweging die vooral de moeite waard is bij pipelines die vaak, kort en op strikte tijdschema's draaien.

Unity Catalog: het Drieledige Namespace

Unity Catalog is Databricks' governance-laag, en de kern ervan is een namespace-structuur met drie niveaus in plaats van de gebruikelijke twee: catalog.schema.table in plaats van alleen schema.table. Dit extra niveau bestaat specifiek om de medallion-scheiding uit Medallion Architecture fysiek af te dwingen op organisatieniveau, over meerdere workspaces heen:

-- Drie catalogi, elk met eigen toegangsrechten -- niet drie schema's binnen één catalogus
CREATE CATALOG bronze_catalog;
CREATE CATALOG silver_catalog;
CREATE CATALOG gold_catalog;

-- Rechten per laag, exact zoals de governance-principes uit Modern Data Platform Architecture
GRANT USAGE, SELECT ON CATALOG bronze_catalog TO `data-engineering-team`;
GRANT USAGE, SELECT ON CATALOG gold_catalog TO `analytics-team`;

Unity Catalog is ook waar Databricks automatische lineage aanbiedt — niet afgeleid uit projectconfiguratie zoals dbt's ref()-gebaseerde graph, maar uit daadwerkelijk uitgevoerde queries. Elke keer dat een query data uit tabel A leest en naar tabel B schrijft, registreert Unity Catalog die relatie automatisch, zichtbaar als graph in de UI — bruikbaar naast, niet in plaats van, de dbt-lineage uit Medallion Architecture wanneer dbt tegen Databricks draait.

Delta Live Tables: Declaratieve Pipelines met Expectations

Waar Snowflake's Dynamic Tables (zie Snowflake) een TARGET_LAG declareren, declareert Delta Live Tables (DLT) een pipeline van afhankelijke tabellen mét ingebouwde datakwaliteitsregels, expectations genoemd — een direct antwoord op de teststrategie-per-laag uit Medallion Architecture, maar dan uitgevoerd tijdens het laden zelf in plaats van als losse test-stap achteraf:

import dlt
from pyspark.sql.functions import col

@dlt.table(comment="Ruwe orders, ongewijzigd geland")
def bronze_orders():
    return spark.readStream.format("cloudFiles").option("cloudFiles.format", "json").load("/raw/orders")

@dlt.table(comment="Schone, gededuplice­erde orders")
@dlt.expect_or_drop("valid_order_id", "order_id IS NOT NULL")
@dlt.expect("positive_amount", "amount > 0")   # loggen, niet blokkeren
def silver_orders():
    return (
        dlt.read_stream("bronze_orders")
        .dropDuplicates(["order_id"])
        .withColumn("amount", col("amount").cast("decimal(10,2)"))
    )

expect_or_drop verwijdert rijen die niet aan de voorwaarde voldoen stilzwijgend uit de output (met telling in de UI); expect logt overtredingen zonder de rij te verwijderen; een derde variant, expect_or_fail, laat de hele pipeline-run falen bij een overtreding — drie niveaus van streng, gekozen per regel naargelang hoe kritiek die specifieke garantie is. Dit is precies de bronze/silver-teststrategie uit Medallion Architecture, maar dan native in het laadmechanisme verweven in plaats van als aparte schema.yml-tests erna.

Photon: de Vectorized Query-engine

Photon is Databricks' native, in C++ herschreven query-executie-engine, een drop-in-vervanging voor de standaard JVM-gebaseerde Spark-engine voor SQL- en DataFrame-operaties. Het voordeel zit in vectorized processing: in plaats van rij voor rij te verwerken, verwerkt Photon batches van rijen tegelijk met CPU-instructies die daarvoor zijn geoptimaliseerd (SIMD), wat vooral bij aggregatie- en join-zware SQL-workloads een aanzienlijk snelheidsvoordeel oplevert ten opzichte van standaard Spark — vaak zonder dat je zelf iets aan je query hoeft te veranderen, simpelweg door Photon in te schakelen op het cluster. Het is geen vervanging voor goed queryontwerp (dezelfde principes uit SQL for Data Engineers blijven gelden), maar een engine-niveau versnelling die bovenop die principes komt.

MLflow: Experimenttracking als Eerste-klas Burger

Waar Snowflake ML-workloads via Snowpark toegankelijk maakt zonder ze centraal te positioneren, is MLflow — oorspronkelijk door Databricks ontwikkeld, inmiddels open-source — diep geïntegreerd in het platform en direct relevant voor het grensvlak tussen data engineering en data science dat in AI for Data Engineers verder wordt uitgewerkt. MLflow legt automatisch experimenten vast: welke parameters, welke dataset-versie (vaak gekoppeld aan een specifieke Delta Lake-versie via Time Travel-achtige functionaliteit), welke metrics, en welk uiteindelijk model-artefact bij elke trainingsrun hoorden — waardoor "welk model draait er precies in productie, en met welke data is het getraind" een reproduceerbare vraag wordt in plaats van tribale kennis.

import mlflow

with mlflow.start_run():
    mlflow.log_param("max_depth", 5)
    model = train_model(training_df, max_depth=5)
    mlflow.log_metric("accuracy", evaluate(model, test_df))
    mlflow.sklearn.log_model(model, "churn_model")

Voor een data engineer die primair aan pipelines werkt, is het relevant om te weten dát dit bestaat en hoe het aansluit op Delta Lake-versies — de diepgaande ML-workflow zelf valt buiten de scope van dit handbook.

Best Practices

• Gebruik job clusters voor elke productiepipeline, nooit een permanent draaiend all-purpose cluster — de kostenbesparing is direct en aanzienlijk.
• Structureer Unity Catalog-catalogi rond medallion-lagen (of een vergelijkbare governance-indeling), niet rond individuele teams, zodat toegangscontrole de datastroom volgt in plaats van de organisatiestructuur.
• Kies het expectation-niveau per regel bewust (expect, expect_or_drop, expect_or_fail) — niet alles verdient dezelfde striktheid.
• Schakel Photon standaard in op clusters die primair SQL/DataFrame-workloads draaien, tenzij een specifieke, zelden voorkomende operatie niet door Photon wordt ondersteund.
• Gebruik MLflow vanaf de eerste trainingsrun, niet pas zodra een model naar productie gaat — retroactief reproduceerbaarheid toevoegen aan oude experimenten is vaak niet meer mogelijk.
• Koppel elke productienotebook aan Databricks Repos, zodat wijzigingen via pull requests lopen in plaats van rechtstreeks in de workspace-UI bewerkt te worden.
• Gebruik instance pools voor frequent draaiende job clusters met strikte tijdvensters, waar de paar minuten clusterstarttijd anders een merkbaar deel van het beschikbare tijdvenster opsoupeert.

Veelgemaakte Fouten

• All-purpose clusters gebruiken voor geplande productiejobs — een van de meest voorkomende en makkelijkst te verhelpen kostenlekken op dit platform.
• Eén platte Unity Catalog-catalogus voor alles, zonder onderscheid tussen bronze/silver/gold of tussen teams, waardoor toegangscontrole net zo grof wordt als geen governance.
• Alle expectations op expect_or_fail zetten uit voorzichtigheid, waardoor elke kleine datakwaliteitsafwijking de hele pipeline blokkeert in plaats van gericht te reageren naar ernst.
• Photon uitschakelen "voor de zekerheid" zonder te meten of het daadwerkelijk een compatibiliteitsprobleem veroorzaakt — in de meeste gevallen is het een zuivere performancewinst zonder nadeel.
• MLflow overslaan tot het "nodig" lijkt, waarna niemand meer kan reconstrueren met welke data en parameters een model in productie is getraind.
• Notebooks rechtstreeks in de productieworkspace bewerken zonder Repos/Git-koppeling, waardoor wijzigingen niet reviewbaar zijn en een fout direct productie raakt zonder pull-request-stap ertussen.
• Widgets vergeten bij het herbruikbaar maken van een notebook, waardoor omgevingsspecifieke waarden (datums, schema-namen) hardcoded in de cellen blijven staan in plaats van als parameter te worden meegegeven.

Performance Tips

• Zet autotermination_minutes laag op all-purpose clusters die voor ontwikkelwerk worden gebruikt — vergeten clusters die dagenlang idle doordraaien zijn een stille kostenpost.
• Gebruik autoscaling (min_workers/max_workers) in plaats van een vaste clustergrootte voor jobs met wisselende datavolumes, zodat je niet permanent voor piekcapaciteit betaalt.
• Monitor DLT-expectationstatistieken actief — een geleidelijk oplopend percentage gedropte rijen is vaak een vroeg signaal van een verslechterende databron, lang voordat het een zichtbaar rapportageprobleem wordt.
• Vergelijk clusterprestaties met en zonder Photon op je zwaarste periodieke jobs — de winst is workload-afhankelijk, en meten is betrouwbaarder dan aannemen.
• Zet instance pools in voor pipelines met een strak tijdvenster, waar clusterstarttijd een merkbaar deel van de beschikbare verwerkingstijd anders zou opeisen.
• Houd %run-ketens ondiep. Een notebook dat via %run tien andere notebooks aanroept die op hun beurt weer andere aanroepen, wordt net zo moeilijk te doorgronden als een diep geneste macro-structuur in dbt.

Interviewvragen

"Wat is het verschil tussen een job cluster, een all-purpose cluster en een SQL warehouse?" Let op: job clusters zijn ephemeral en gekoppeld aan een specifieke geplande run, all-purpose clusters blijven draaien voor interactief werk, SQL warehouses zijn een aparte, BI-geoptimaliseerde compute-laag — en het besef dat het door elkaar gebruiken ervan de meest voorkomende kostenfout is.

"Waarom heeft Unity Catalog drie namespace-niveaus (catalog.schema.table) in plaats van twee?" Let op: het extra catalogus-niveau maakt het mogelijk om medallion-lagen (of teams) fysiek te scheiden met eigen toegangsrechten, over meerdere workspaces heen.

"Wat zijn expectations in Delta Live Tables, en welke drie niveaus van striktheid bestaan er?" Let op: expect (loggen), expect_or_drop (rij verwijderen), expect_or_fail (hele pipeline laten falen) — met het besef dat de keuze per regel afhangt van hoe kritiek die specifieke garantie is.

"Wat doet Photon, en wanneer levert het het meeste voordeel op?" Let op: vectorized, CPU-geoptimaliseerde query-executie die vooral bij aggregatie- en join-zware SQL/DataFrame-workloads een merkbaar verschil maakt, zonder dat de query zelf hoeft te veranderen.

"Waarom zou een data engineer iets van MLflow moeten weten, ook als hij zelf geen modellen bouwt?" Let op: het besef dat MLflow experimenten koppelt aan specifieke datasetversies (vaak via Delta Lake), wat reproduceerbaarheid van modellen mogelijk maakt — relevant voor iedereen die de data levert waarop modellen trainen.

"Wat is het reproduceerbaarheidsprobleem met notebooks, en hoe voorkom je het?" Let op: cellen kunnen out-of-order worden uitgevoerd tijdens interactief werk, waardoor de zichtbare volgorde niet de daadwerkelijke uitvoeringsvolgorde hoeft te zijn — consequent van boven naar beneden werken (of "Run All" gebruiken vóór oplevering) voorkomt dit.

"Wat is het voordeel van Databricks Repos ten opzichte van los notebookbeheer?" Let op: notebooks worden als broncode (niet als uitvoerbundel met celresultaten) opgeslagen in Git, met normale branches en pull requests — noodzakelijk om notebook-ontwikkeling te combineren met CI/CD.

"Wat lossen instance pools op, en wanneer zijn ze de moeite waard?" Let op: ze houden vooraf opgestarte virtuele machines paraat om clusterstarttijd te verkorten van minuten naar seconden — vooral waardevol bij job clusters die frequent en kort draaien op een strak schema.

Relevante Documentatie

• Databricks: Compute (Clusters) — het volledige onderscheid tussen cluster-types.
• Databricks: Unity Catalog — namespace-structuur, lineage en governance.
• Databricks: Delta Live Tables — expectations en pipeline-declaratie in detail.
• Databricks: Photon — ondersteunde workloads en activering.
• MLflow Documentation — experimenttracking, model registry en deployment.

Samenvatting

Databricks' platformmechanica draait om drie herkenbare, elk-hun-eigen-doel compute-vormen (job clusters, all-purpose clusters, SQL warehouses), een drieledig Unity Catalog-namespace dat governance direct aan de medallion-indeling koppelt, en Delta Live Tables die datakwaliteitsregels — expectations — rechtstreeks in het laadproces verweven in plaats van als losse teststap. Photon versnelt SQL/DataFrame-workloads op engine-niveau zonder queryherschrijving, en MLflow maakt de brug naar machine learning reproduceerbaar door experimenten aan specifieke dataversies te koppelen. Notebooks als broncode via Databricks Repos en versnelde clusterstart via instance pools maken de operationele kant van het platform compleet. Met Snowflake en Databricks nu beide behandeld, richt het volgende hoofdstuk zich op het derde grote platform in dit handbook: Microsoft Fabric, met zijn eigen unified-platformbenadering.