ExamFinch.com My Study

Study guide

1.10 Online vs. Offline Feature Tables

Practice this exam

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

1.10 Online vs. Offline Feature Tables

Key Takeaways Explain This Topic AI

Offline feature tables are Delta tables optimised for high-throughput scans: they hold full history, support time travel, and power training and batch scoring.

Online feature tables are low-latency key-value stores holding only the current value per primary key, and they exist to serve single-row lookups inside a REST request.

An online table is a published copy of an offline table, not an independent source: the offline Delta table remains the system of record and is the only place point-in-time history exists.

Publishing runs in TRIGGERED mode (a one-shot sync per call, matched to a batch refresh schedule) or CONTINUOUS mode (a streaming sync that keeps values seconds-fresh).

Legacy Databricks online tables are deprecated; the current managed path is the Databricks Online Feature Store backed by Lakebase, but the offline-versus-online distinction it implements is unchanged.

Last updated: August 2026

  • 1.10 Online vs. Offline Feature Tables
  • Offline Delta Tables vs. Low-Latency Online Feature Stores

Machine learning architectures separate offline and online storage to meet divergent throughput and latency requirements:

  • Offline feature store Online feature store
  • Engine Delta Lake on cloud object storage Low-latency key-value store
  • Query shape High-throughput scans over full history Sub-10 ms point lookups by primary key
  • Guarantees ACID transactions and Delta time travel Latest feature state per key only
  • Consumers Training runs and batch scoring Real-time model serving over REST
  • The two are joined by an automated publish sync that pushes current values from the

offline Delta table into the online store.

Publishing Features to an Online Store

An offline feature table becomes available for real-time serving only after it is published . On current Databricks, the managed path is a Databricks online store; FeatureEngineeringClient.publish_table takes the online store object plus the

source and destination table names: from databricks.feature_engineering.online_store_spec import DatabricksOnlineStore

  • fe.publish_table(
  • online_store=DatabricksOnlineStore(name="prod_online_store"),
  • source_table_name="prod_catalog.ml_features.customer_demographics",
  • online_table_name="prod_catalog.ml_features.customer_demographics_online",
  • publish_mode="TRIGGERED", # or "CONTINUOUS" for streaming sync
  • )
  • publish_mode="TRIGGERED" runs a one-shot sync each time it is called — the right

choice for features recomputed on a daily or hourly schedule.

publish_mode="CONTINUOUS" keeps a streaming sync running so online values track

the offline Delta table within seconds.

  • Third-party key-value stores (Amazon DynamoDB, Azure Cosmos DB, Azure SQL/MySQL)
  • are reached through the corresponding OnlineStoreSpec subclass rather than a

generic OnlineStoreSpec(store_type=...) constructor. If a question offers OnlineStoreSpec(store_type="CosmosDb") , that is not a real API call.

The Differences That Get Tested

Dimension Offline feature table Online feature table

Storage engine Delta Lake on cloud object storage Low-latency key-value store (Databricks online store, DynamoDB, Cosmos DB, …)

  • Access pattern Scan and join across millions of rows Point lookup by primary key
  • Typical latency Seconds to minutes for a distributed job Single-digit to low double-digit milliseconds per key
  • History retained Full history, with Delta time travel Latest value per key only
  • Point-in-time joins Supported via timeseries_column Not applicable — no history to join against
  • Who reads it Training runs, fe.score_batch , analytics Model Serving endpoints, low-latency applications

Cost profile Cheap per byte, priced like object storage Provisioned throughput and storage, priced per key-value capacity

  • Source of truth Yes No — it is a published projection
  • Why Both Exist
  • A training job reads tens of millions of rows once. Object storage plus a distributed
  • scan is the cheapest possible way to do that, and Delta's history is what makes

point-in-time correctness possible in the first place.

  • A serving endpoint does the opposite: it reads one key, and it must answer inside a
  • user-facing request budget. Opening Parquet footers, pruning files, and launching a
  • Spark job to fetch a single row would blow a 50 ms latency target by orders of

magnitude. A key-value store answers that lookup in milliseconds.

Neither engine is good at the other's job, so Databricks keeps both and synchronises

them.

Freshness and the Sync Contract

The publishing mode determines how stale an online value may be:

  • TRIGGERED — each publish_table call performs one sync. Pair it with the job
  • that recomputes the offline features, so online freshness equals the batch cadence
  • (typically hourly or daily). Cheapest option, and correct for slow-moving features

such as customer tenure or product attributes.

  • CONTINUOUS — a streaming sync runs, keeping the online store within seconds of
  • the offline table. Required for fast-moving features such as a 5-minute transaction

velocity counter.

  • A frequent production bug is a feature whose business meaning demands minute-level
  • freshness being published on a daily trigger: the endpoint returns yesterday's value

with no error at all.

The Decision Rule

Ask what the consumer is:

Training, backfills, batch scoring, analytics → offline only.

  • A synchronous REST endpoint or an application that needs one entity's features in
  • milliseconds → publish the table online , and keep the offline table as the

source of truth.

  • Both → maintain one offline table and publish it; never maintain two independent
  • feature pipelines, because that is precisely the train/serve skew the feature store

exists to eliminate.

  • Where the Online Copy Physically Lives Today
  • The objective is conceptual — describe the differences — but the managed

implementation has been renamed, so it is worth knowing what the current product is.

  • Databricks' original online tables were a workspace-managed key-value copy of a
  • Delta table. Databricks has deprecated them: new online tables can no longer be
  • created, and the documented migration target is the Databricks Online Feature Store ,
  • backed by Lakebase, Databricks' managed Postgres engine, and provisioned as a Lakebase

project. For serving data that is not a feature table, the parallel construct is a Lakebase synced table — a read-only Postgres table kept in sync with a Unity Catalog

table.

  • None of that changes the distinction the exam tests. Offline is Delta on object storage,
  • holds history, and serves scans. Online is a key-value engine, holds current state, and
  • serves point lookups. An answer claiming that an online store keeps history, or that you

should train from it, is wrong regardless of which generation of the product it names.

  • Controlling What Gets Published
  • publish_table does more than copy a whole table, and the extra arguments show up in

scenario questions:

Argument Effect

filter_condition A SQL predicate limiting which rows are published — for example only active customers, instead of ten years of closed accounts

  • features Publishes a subset of feature columns rather than all of them
  • publish_mode TRIGGERED for a one-shot sync, CONTINUOUS for a streaming sync
  • mode merge upserts by primary key into the online table
  • checkpoint_location , trigger Streaming plumbing used when the sync runs continuously
  • Publishing a filtered subset is the standard cost control. Online storage is priced well
  • above object storage, so the online copy should hold only the keys an endpoint can

actually be asked about.

  • Two Failure Modes Worth Recognising
  • A key that was never published. An endpoint asks for customer_id = 'C-90412' , the
  • online table has no such row, and the lookup returns null — it does not fall back to the
  • offline table. If filter_condition excluded that segment, the model silently scores on

missing features. The fix belongs in the publish filter, not the endpoint.

  • A schema change applied offline only. Adding a feature column to the offline Delta
  • table does not retroactively add it online; the table must be republished. A model
  • version trained on the new column fails its lookups until the sync catches up, which is
  • why feature-schema changes and model promotion are sequenced deliberately rather than

shipped together.