Databricks · One-Pager · MLOps

MLOps on Databricks

The end-to-end discipline for training, registering, deploying, and monitoring classic predictive ML models on the Lakehouse — DevOps + DataOps + ModelOps under one Unity Catalog governance plane.

GA Deploy code, not models Verified June 2026 docs

In one line

MLOps on Databricks is the practice of managing the ML lifecycle — data → features → train/track (MLflow) → register (Unity Catalog) → deploy (serving/batch) → monitor — as governed, promotable code across dev, staging, and prod.

Why it matters

It turns one-off notebooks into reproducible, auditable production pipelines. Because models, features, and data all live in Unity Catalog, you get one access-control and lineage model for the whole lifecycle — and you ship by promoting reviewed code through environments rather than copying model files around.

Core concepts

MLflow tracking

Experiments hold runs; each run logs params, metrics, and artifacts. mlflow.autolog() captures them automatically, and log_model() packages the model in MLflow format.

Models in Unity Catalog

Register to the three-level namespace catalog.schema.model; versioned, governed, lineage-tracked. Set registry_uri("databricks-uc") (default in MLflow 3).

Aliases, not stages

A mutable named pointer like @Champion/@Challenger points at a version, decoupling deployment from the inference pipeline. Aliases replace the deprecated stages.

Feature Engineering

Feature tables in UC, joined to labels via FeatureLookup with point-in-time correctness — the same computation at train and serve time kills train/serve skew.

Deploy code, not models

Promote code through dev → staging → prod so prod models are produced by reviewed, tested prod code. MLOps Stacks (Asset Bundles) scaffold the CI/CD.

Serve + monitor

Real-time via Model Serving (serverless, scale-to-zero REST), or batch inference over a Delta table. Lakehouse Monitoring profiles the inference table for drift and quality.

How it works

Click a stage

1 · Features 2 · Train + Track 3 · Register (UC) 4 · Deploy 5 · Monitor

Features — feature tables in Unity Catalog supply training data via point-in-time FeatureLookup joins, so train and serve use identical features.

Minimal example

PySpark · Pythonimport mlflow
from mlflow import MlflowClient

mlflow.set_registry_uri("databricks-uc")   # register to UC, not the workspace registry

with mlflow.start_run():
    mlflow.autolog()                          # auto-log params, metrics, the model
    model = clf.fit(X_train, y_train)
    info = mlflow.sklearn.log_model(
        model, name="model", input_example=X_train[:5],
        registered_model_name="prod.ml_team.churn")   # catalog.schema.model

# point the deploy alias at the new version — pipelines load models:/...@Champion
MlflowClient().set_registered_model_alias("prod.ml_team.churn", "Champion", info.registered_model_version)

Gotchas & limits

UC registration needs a model signature (use input_example) plus CREATE MODEL on the schema and USE SCHEMA/USE CATALOG — the catalog and schema must already exist.
Aliases replace the legacy Staging/Production stages; stages and the workspace Model Registry are deprecated — don't reach for them in new work.
Lakehouse Monitoring computes drift/quality but does not modify the monitored table; model-quality metrics need a ground-truth label column joined back to the inference log.
Model Serving is serverless and scales to zero, so an idle endpoint adds cold-start latency — prefer batch inference for high-volume, latency-tolerant scoring.

Interview soundbites

Say this out loud

"Databricks MLOps says deploy code, not models — you promote reviewed pipeline code through dev/staging/prod, so the prod model is always built by prod code."
"Models live in Unity Catalog as catalog.schema.model with versions and aliases; flipping the @Champion alias is a zero-downtime deploy that the serving/inference pipeline picks up without code changes."
"Feature tables give point-in-time-correct joins so the same feature logic runs at train and serve time — that's how you avoid train/serve skew — and Lakehouse Monitoring watches the inference table for drift afterward."
"Classic ML registers a trained model and serves it; LLMOps (page 22) is the same lifecycle but the unit is a GenAI agent, evaluated with MLflow traces instead of accuracy metrics."

References

Verified against docs.databricks.com · June 2026