Model Deployment: Batch, Streaming, and Real-Time Serving
Three deployment shapes
Batch: a scheduled job loads data, applies the model with mlflow.pyfunc.spark_udf() (or the feature store's score_batch), and writes predictions to a Delta table. Streaming: the same scoring logic inside foreachBatch or writeStream. Real-time: a Databricks Model Serving endpoint that wraps a registered model version or alias and exposes a REST API with scale-to-zero, CPU or GPU compute, and optional provisioned throughput for latency-sensitive traffic.
Serving essentials
Endpoints are created from Unity Catalog registered models (or the workspace registry in legacy setups) and can serve a specific version or an alias such as champion. Clients POST JSON records to the endpoint URL with a token; the response contains predictions matching the model signature. Endpoints take time to warm up, so a query immediately after creation may fail.
Batch scoring essentials
The model must be logged with a signature before spark_udf can infer the input schema. Load with mlflow.pyfunc.load_model on the driver for pandas or spark_udf for distributed scoring, and give the UDF an explicit return type.
Governance and operations
Keep deployment code in Git-backed Repos or Declarative Automation Bundles, promote by moving the alias, and monitor drift with Lakehouse Monitoring. Permissions on the registered model control who can serve it.
Traps
Confusing an endpoint (real-time) with a job (batch); assuming a version number is required when an alias is preferred; forgetting that serving reads features at request time and needs the transformation in the logged model.
Rule of thumb
Latency tolerance decides the shape: minutes or hours means batch, sub-second means an endpoint.