Study guide
4.1 Differences and Advantages of Batch, Streaming, and Real-Time Serving
Databricks Certified Machine Learning Associate Study Guide Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Databricks Machine Learning (38% of the Exam)
1.1 MLOps Best Practices on Databricks 1.2 Advantages of Databricks ML Runtimes and Compute Selection 1.3 Promoting Code vs. Promoting Models 1.4 How AutoML Facilitates Model and Feature Selection 1.5 AutoML Advantages in the Model Development Process 1.6 Feature Tables in Unity Catalog vs. the Workspace Feature Store 1.7 Creating a Feature Table and Writing Data to It 1.8 Training a Model with Features from a Feature Table 1.9 Scoring a Model with Features from a Feature Table 1.10 Online vs. Offline Feature Tables 1.11 Manually Logging Metrics, Artifacts, and Models in an MLflow Run 1.12 Identifying the Best Run with the MLflow Client API 1.13 Information Available in the MLflow UI 1.14 Registering a Model in the Unity Catalog Registry 1.15 Model Tags, Aliases, and Champion/Challenger Promotion
2 Chapter 2: Data Processing and ML Workflows (19% of the Exam)
2.1 Computing Summary Statistics on a Spark DataFrame 2.2 Creating Visualizations for Categorical and Continuous Features 2.3 Comparing Two Categorical or Two Continuous Features 2.4 Removing Outliers with Standard Deviation and IQR 2.5 When Log-Scale Transformation Is Appropriate 2.6 Comparing and Applying Mean, Median, and Mode Imputation 2.7 One-Hot Encoding and When It Is or Is Not Appropriate
3 Chapter 3: Model Development (31% of the Exam)
3.1 Selecting the Appropriate Algorithm for a Scenario 3.2 Methods to Mitigate Data Imbalance in Training Data 3.3 Comparing Estimators and Transformers 3.4 Developing a Training Pipeline 3.5 Tuning Hyperparameters with Hyperopt's fmin 3.6 Grid, Random, and Bayesian Search Strategies 3.7 Parallelizing Single-Node Models for Hyperparameter Tuning 3.8 Cross-Validation vs. a Train-Validation Split 3.9 Counting the Models Trained by Grid Search and Cross-Validation 3.10 Using Common Classification Metrics 3.11 Using Common Regression Metrics 3.12 Choosing the Most Appropriate Metric for the Objective 3.13 Exponentiating Log-Transformed Predictions Before Evaluation 3.14 Model Complexity and the Bias-Variance Tradeoff
4 Chapter 4: Model Deployment (12% of the Exam)
4.1 Differences and Advantages of Batch, Streaming, and Real-Time Serving 4.2 Performing Batch Inference with pandas and Spark UDFs 4.3 Streaming Inference with Delta Live Tables 4.4 Deploying a Custom Model to a Model Endpoint 4.5 Deploying, Querying, and Splitting Traffic Across Real-Time Endpoints
4.1 Differences and Advantages of Batch, Streaming, and Real-Time Serving
Key Takeaways Explain This Topic AI
Batch inference is scheduled and asynchronous, delivers the lowest cost per prediction, and writes results to Delta Lake for later consumption.
Streaming inference applies a model to a continuous Structured Streaming DataFrame, producing second-to-minute latency with checkpointed exactly-once recovery.
Real-time serving answers synchronous HTTPS requests in tens of milliseconds from serverless endpoints that scale to zero when idle.
The decisive question is whether a human or live service is blocked waiting for the prediction; if not, batch or streaming is almost always cheaper.
Hybrid designs precompute predictions in batch and push them to a low-latency store, which works only when the entity universe is bounded and known in advance.
Last updated: August 2026
4.1 Differences and Advantages of Batch, Streaming, and Real-Time Serving
Deploying a trained machine learning model into production requires selecting an inference architecture that aligns with business latency constraints, throughput requirements, compute budgets, and operational complexity. On the Databricks Lakehouse Platform, practitioners deploy models across three primary serving paradigms: Batch Inference (Offline Scoring) , Streaming Inference (Near-Real-Time / Event-Driven) , and Real-Time Model Serving (Synchronous REST API) .
Choosing the incorrect inference pattern introduces severe production failure modes, such as excessive cloud infrastructure costs from over-provisioning real-time endpoints for non-interactive workloads, or unacceptable user-facing latency when batch pipelines are misapplied to interactive applications.
The Machine Learning Serving Spectrum
Inference paradigms exist along a continuum defined by latency requirements, data arrival characteristics, and invocation triggers: +---------------------------------------------------------------------------------------------------+
- | DATABRICKS ML INFERENCE PARADIGM SPECTRUM |
- | |
- | BATCH INFERENCE STREAMING INFERENCE REAL-TIME SERVING |
- | (Offline / Scheduled) (Near-Real-Time / Micro-batch) (Interactive / Synchronous) |
- | +-----------------------+ +-------------------------+ +-------------------------+ |
- | | - Trigger: Schedule | | - Trigger: Event Stream | | - Trigger: HTTP Request | |
- | | - Latency: Hours/Mins | ----> | - Latency: Secs/Mins | ----> | - Latency: 10 - 50 ms | |
- | | - Throughput: TBs/PBs | | - Throughput: Millions | | - Throughput: 1-10k RPS | |
- | | - Target: Delta Lake | | - Target: Delta / Bus | | - Target: App Client | |
- | | - Engine: Spark Job | | - Engine: Structured St.| | - Engine: Serverless EP | |
- | +-----------------------+ +-------------------------+ +-------------------------+ |
- | LOWEST COST PER ROW LOWEST REQUEST LATENCY|
- +---------------------------------------------------------------------------------------------------+
- In-Depth Analysis of Inference Paradigms
- Batch Inference (Offline Scoring)
Batch inference operates on static, accumulated datasets at scheduled intervals (hourly, daily, weekly). It is the most common and cost-effective serving pattern in enterprise machine learning.
Execution Mechanics: A Databricks Workflow executes a scheduled Python or SQL job. The job reads a Delta Lake table, broadcasts or distributes the registered MLflow model across Spark worker nodes, evaluates predictions in parallel using mlflow.pyfunc.spark_udf or vectorized Pandas UDFs, and writes output predictions into a target Delta Lake gold table.
Latency SLA: Asynchronous; minutes to hours. Predictions are generated long before downstream consumers access them.
Throughput Capacity: Massive. Scales horizontally across hundreds of Spark executor cores to process billions of records or petabytes of data.
Cost Efficiency: Lowest cost per prediction. Workloads utilize ephemeral automated job clusters that spin up on demand, execute vectorized SIMD/Arrow operations, and terminate immediately upon completion. Spot/preemptible instances can be leveraged safely because Delta ACID transactions ensure complete, recoverable writes.
Failure Recovery: Idempotent job retries. If a node fails, Spark recomputes failed partition tasks; if the job fails, the target Delta table remains unaffected until the atomic transaction commits.
Canonical Use Cases:
Nightly customer churn risk scoring for CRM marketing campaigns.
Weekly customer lifetime value (LTV) recalculations.
Daily retail demand forecasting across store-SKU hierarchies.
Monthly credit limit adjustment calculations for banking portfolios.
Streaming Inference (Near-Real-Time / Micro-Batch)
Streaming inference operates on continuous, unbounded data streams. It bridges the gap between batch efficiency and real-time responsiveness.
Execution Mechanics: Spark Structured Streaming continuously ingests streaming events from message brokers (Apache Kafka, AWS Kinesis, Azure Event Hubs) or Delta Lake Change Data Feed (CDF). The stream applies an MLflow scoring UDF on micro-batches (e.g., every 5 to 30 seconds) or continuous event streams, writing scored results to downstream Delta sinks, message queues, or operational databases.
Latency SLA: Sub-second to several minutes depending on trigger configuration ( Trigger.ProcessingTime("5 seconds") or Trigger.AvailableNow() ).
Throughput Capacity: High and elastic. Automatically adapts to variable streaming ingestion volume.
Cost Efficiency: Moderate. Requires continuously running cluster resources unless scheduled incrementally with Trigger.AvailableNow() .
Failure Recovery: Checkpoint-driven state recovery. The stream persists processed offsets and metadata to cloud object storage via checkpointLocation , guaranteeing exactly-once fault tolerance upon restarts.
Canonical Use Cases:
Real-time financial transaction fraud detection on continuous card swipe streams.
IoT industrial sensor anomaly detection and alert triggering.
Real-time clickstream intent classification for dynamic web personalization.
Live delivery driver and customer order matching feeds.
Real-Time Model Serving (Synchronous REST API)
Real-time model serving exposes models as low-latency, highly available HTTPS endpoints. Predictions are generated synchronously on-demand in response to individual client requests.
Execution Mechanics: Databricks Model Serving hosts models on managed Serverless compute. Client applications (mobile apps, web servers, backend microservices) issue HTTPS POST requests containing JSON feature payloads. The serving gateway routes requests to containerized model replicas, which compute predictions and return synchronous JSON responses.
Latency SLA: Sub-second (typically 10 ms to 50 ms).
Throughput Capacity: Requests are processed individually or in small micro-payloads (1 to 100 records). Throughput scales horizontally by adding container instances based on incoming Requests Per Second (RPS) and concurrent connections.
Cost Efficiency: Highest cost per individual prediction. Serverless architecture optimizes costs through automatic scale-to-zero , shutting down compute instances when no traffic is detected.
Failure Recovery: Client-side retries, exponential backoff, circuit breakers, multi-region failover, and static fallback heuristic responses.
Canonical Use Cases:
Point-of-sale instant credit underwriting and loan decisioning.
Interactive e-commerce search query re-ranking and real-time recommendations.
Live chatbot conversational intent parsing and sentiment extraction.
Real-time medical triage diagnostic screening.
Comprehensive Architectural Comparison Matrix
The following matrix summarizes the technical, operational, and financial dimensions across the three paradigms:
Evaluation Dimension Batch Inference Streaming Inference Real-Time Model Serving
Invocation Paradigm Scheduled / Asynchronous pull Continuous / Event-driven stream Interactive / Synchronous request-response
- Serving Latency Minutes to Hours 500 ms to Minutes 10 ms to 50 ms (<100 ms SLA)
- Throughput Volume Billions of rows / Petabytes Millions of events / hour 100 to 10,000+ Requests/sec
Compute Architecture Ephemeral multi-node Spark cluster Continuous or triggered Spark stream Serverless containerized micro-replicas
Cost per Prediction Lowest (vectorized bulk processing) Low to Moderate Highest (dedicated standby concurrency)
Data Freshness T+Schedule (e.g., T+24h) Near-instantaneous (T+Seconds) Instantaneous (incorporates request-time data)
Input Data Source Delta Lake tables, Parquet files Kafka, Kinesis, Event Hubs, Delta CDF JSON REST payload, Online Feature Store
Output Destination Delta Lake tables, Data Warehouses Delta tables, Message queues, NoSQL Synchronous HTTP JSON response
Fault Tolerance Spark task retry & Delta ACID commit Structured Streaming checkpoints Gateway routing, client retries, fallback
Operational Overhead Low (handled by Workflow orchestrator) Moderate (stream monitoring & lag) High (endpoint uptime, latency SLOs, alerting)
Hybrid Architectures: Precomputation vs. Dynamic On-Demand Scoring
In complex enterprise systems, machine learning engineers frequently combine paradigms to optimize latency and compute expenditure. +---------------------------------------------------------------------------------------------------+
- | HYBRID SERVING ARCHITECTURES |
- | |
- | PATTERN A: BATCH PRECOMPUTATION + ONLINE CACHE LOOKUP |
- | +------------+ Spark Batch +------------+ Sync Push +------------+ Sub-5ms GET |
- | | Delta Lake | -----------------> | ML Scoring | --------------> | Key-Value | <------------ |
- | | Gold Table | (Nightly Run) | Predictions| | Redis/KV | Web Client |
- | +------------+ +------------+ +------------+ |
- | |
- | PATTERN B: REAL-TIME SERVING + ONLINE FEATURE STORE ENRICHMENT |
- | +---------------------------------------+ |
- | | Databricks Serverless Model Endpoint | |
- | +------------+ | 1. Receive {user_id, cart_items} | +--------------------------+ |
- | | Web Client | -> | 2. Fetch user historical features | <-> | Unity Catalog Feature | |
- | | (HTTP POST)| | 3. Compute dynamic score | | Store (Online Store) | |
- | +------------+ | 4. Return JSON {risk_score: 0.82} | +--------------------------+ |
- | +---------------------------------------+ |
- +---------------------------------------------------------------------------------------------------+
- Pattern A: Batch Precomputation with Low-Latency Cache Store
Mechanism: Compute predictions for all possible entities (e.g., every active customer ID) during an offline batch job. Push the {entity_id: prediction_value} pairs into a high-throughput, low-latency NoSQL database or cache (e.g., Redis, DynamoDB, Cosmos DB, or Unity Catalog Online Table).
Advantages: Delivers sub-5ms lookup latency at request time without incurring the compute latency and cost of executing model forward passes during live user interactions.
Limitations: Only viable when the entity universe is bounded and known in advance (e.g., existing registered users). Cannot incorporate real-time session context, dynamic user queries, or unseen feature values.
Pattern B: Real-Time Dynamic Scoring with Feature Store Joins
Mechanism: The client sends an HTTP request containing lightweight transient keys (e.g., user_id , current_session_click ). The serving endpoint automatically enriches the payload by fetching precomputed historical features (e.g., 90-day purchase frequency) from the Unity Catalog Online Feature Store, combines them with live request-time features, and executes model inference dynamically.
Advantages: Supports dynamic inputs, unseen entity combinations, and real-time contextual signals while retaining access to complex historical features.
Architectural Decision Framework
When designing an inference pipeline on Databricks, evaluate these four foundational questions:
Is the prediction required synchronously to unblock a human user or live service?
Yes: Real-Time Model Serving (Serverless Endpoint).
No: Proceed to Question 2.
Does the input feature set originate from a continuous streaming message broker with a sub-minute latency requirement?
Yes: Streaming Inference (Spark Structured Streaming).
No: Proceed to Question 3.
Is the entity space small and predictable enough to precompute all combinations in advance?
Yes: Batch Precomputation + Online Key-Value Store.
No: Batch Inference directly to Delta Lake.