I85PREP
⌘ K
Databricks ML Professional study materials
Databricks ML Professional study resources

Databricks ML Professional: Model Deployment: Batch, Streaming, and Real-Time Serving

Databricks ML Professional · Work through your exam, one topic at a time.

All guide sections

Model Deployment: Batch, Streaming, and Real-Time Serving

The Model Deployment domain tests how you expose a trained model: batch scoring, Structured Streaming, or a real-time Model Serving endpoint. The exam emphasizes the interface between the model artifact and the serving contract, plus safe release patterns. A common scenario gives a business latency requirement and asks which deployment mode and endpoint settings fit.

Real-time endpoints

A Databricks Model Serving endpoint has one or more served entities. Point an entity at a model alias, not a hard-coded version, so promotion does not require an endpoint change. Choose a workload size for CPU/GPU and memory; enable scale-to-zero for intermittent traffic, accepting cold-start latency, or provisioned throughput for steady low latency. Enable inference tables to log payloads. Callers need CAN_QUERY on the endpoint and a token; the request body uses dataframe_records or dataframe_split, and the response follows the model signature.

Batch and streaming

Batch scoring uses mlflow.pyfunc.spark_udf with a model URI such as models:/catalog.schema.model@champion, applied over a Delta table in a job. Streaming uses readStream and foreachBatch, loading the model inside the batch function and writing to a Delta sink with a checkpoint. Batch is right for large offline scoring; streaming for continuous freshness; real-time for per-request latency.

Release patterns

Route optimization splits traffic across served entities, enabling a canary or A/B test (for example, 90% champion, 10% challenger). A shadow deployment sends production traffic to a challenger but returns only the champion response; inference tables capture both for comparison. Rollback means moving the alias back, not redeploying an old endpoint.

Worked example

A fraud team needs sub-second scoring. They create an endpoint with the champion alias, scale-to-zero, and inference tables enabled, then grant CAN_QUERY to the application service principal. After a week, they add a second served entity pointing at challenger and route 95/5. They compare precision at a fixed recall using inference-table joins to confirmed fraud. Reasoning: alias indirection makes promotion safe, the 95/5 split limits customer risk, and inference tables provide the evidence for a full rollout.

Traps that cost marks

  • Hard-coding a model version in the endpoint, then forgetting to update it.
  • Deploying a model without a signature, so payload validation fails.
  • Enabling scale-to-zero for a latency SLO that cold starts violate.
  • Expecting Feature Store lookups at serving time without an online store.
  • Omitting CAN_QUERY for the calling principal.
  • Treating a shadow deployment as if it returned the challenger's response.