1.6 Feature Tables in Unity Catalog vs. the Workspace Feature Store

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.6 Feature Tables in Unity Catalog vs. the Workspace Feature Store

Key Takeaways Explain This Topic AI

Feature Engineering in Unity Catalog registers feature tables at the account level under catalog.schema.table , so any authorised workspace on the metastore can read them.

The legacy Workspace Feature Store was scoped to a single workspace's Hive metastore, which forced duplicate feature pipelines and cross-workspace sync scripts.

Unity Catalog feature tables inherit standard SQL privileges ( GRANT SELECT , GRANT MODIFY ), audit logging, and automatic end-to-end lineage from source Delta tables through training runs to serving endpoints.

The client changed with the namespace: databricks.feature_engineering.FeatureEngineeringClient replaces databricks.feature_store.FeatureStoreClient .

Any Delta table in Unity Catalog with a NOT NULL primary key constraint is usable as a feature table — Feature Engineering in Unity Catalog requires Databricks Runtime 13.2 or above and Privilege Model Version 1.0.

Last updated: August 2026

1.6 Feature Tables in Unity Catalog vs. the Workspace Feature Store

In enterprise machine learning, feature reusability, consistency, and governance are paramount. Without a centralized feature platform, disparate data science teams frequently rewrite identical feature transformations (e.g., calculating 30-day average transaction volumes), leading to code duplication, computational waste, and severe train/serve skew .

Feature Engineering in Unity Catalog represents the evolution of the Databricks Feature Store. It replaces legacy, workspace-confined feature stores with an account-level architecture governed under Unity Catalog's standard 3-level namespace ( catalog.schema.table ).

• Namespace level Example What it controls
• Catalog (account level) prod_catalog Environment isolation and the coarsest unit teams grant across
• Schema ml_features Grouping of related feature domains

Table customer_360_features A Delta feature table keyed on customer_id , holding avg_monthly_spend , tenure_months , total_returns

Table transaction_temporal_features A time-series feature table keyed on account_id with a TIMESERIES column transaction_timestamp , holding rolling_7d_spend and declined_txn_count

• Both tables belong to the metastore rather than to a workspace, which is the entire
• point: prod_catalog.ml_features.customer_360_features resolves to the same physical

data from every workspace attached to that metastore.

Workspace Feature Store vs. Feature Engineering in Unity Catalog

Understanding the architectural advantages of Unity Catalog feature tables over legacy workspace feature stores is a primary focus of the Databricks ML certification.

Capability / Property Legacy Workspace Feature Store Feature Engineering in Unity Catalog

Client Package databricks.feature_store.FeatureStoreClient databricks.feature_engineering.FeatureEngineeringClient

Namespace Structure 2-level namespace: database.table (or hive_metastore.database.table ) 3-level namespace: catalog.schema.table

Cross-Workspace Access Complex; required workspace-to-workspace API tokens and custom syncing. Native; feature tables in a catalog are instantly accessible across all authorized workspaces.

Governance & Security Table ACLs isolated to individual workspace metastores. Centralized Unity Catalog RBAC ( GRANT SELECT / MODIFY ON TABLE ) with audit logging.

Lineage Tracking Local to workspace; partial visibility into upstream data sources. End-to-end automated lineage from raw Delta tables -> feature tables -> MLflow models -> endpoints.

Discoverability Limited to users with access to the specific local workspace. Account-wide searchable UI catalog with column-level descriptions, tags, and owner metadata.

• Why Account-Level Registration Changes the Economics
• The comparison table above lists the mechanical differences. The exam cares about the

consequences, which are worth stating explicitly.

• One definition, many consumers
• A workspace-scoped feature table is invisible outside its workspace. In a typical

enterprise with separate workspaces for marketing, risk, and operations, the same customer_30d_spend feature gets rebuilt three times, with three slightly different

• window definitions. When those teams later compare model results, the discrepancy is
• untraceable. An account-level table has exactly one definition, and every team reads

the same computed values.

• Governance uses the tools the platform already has
• Because a Unity Catalog feature table is a Delta table with feature metadata, access

is granted with ordinary SQL: GRANT SELECT ON TABLE prod_catalog.ml_features.customer_spending TO `data-scientists`;

• GRANT MODIFY ON TABLE prod_catalog.ml_features.customer_spending TO `sp-feature-pipeline`;
• Column masks, row filters, tags, and audit logs apply the same way they do to any
• other governed table. The workspace feature store required a parallel permission model

that no data governance team could reconcile with the rest of the estate.

• Lineage becomes end-to-end and automatic
• Unity Catalog records, without instrumentation, that a bronze table fed a feature
• computation job, that the job wrote a feature table, that a training run consumed
• particular feature columns, that the run produced a registered model version, and that

the version backs a serving endpoint. Two questions become answerable in seconds:

If this upstream table is wrong, which production models are affected?

Which features does this production model actually depend on?

• Discoverability prevents duplicated work
• Account-level tables are searchable in Catalog Explorer with descriptions, tags, and

owners. Feature reuse is only possible when engineers can find what already exists.

What changes in your code

• Concern Workspace Feature Store Feature Engineering in Unity Catalog
• Package databricks-feature-store databricks-feature-engineering
• Client FeatureStoreClient() FeatureEngineeringClient()
• Table name database.table catalog.schema.table
• Time-series parameter timestamp_keys=[...] timeseries_column="..."
• Exam tip : any option that describes copying feature tables between workspaces,
• or maintaining per-workspace ACL scripts, is describing the legacy architecture and

is the wrong answer when Unity Catalog is available.

• What Actually Makes a Table a Feature Table
• The most commonly missed fact in this objective is that Unity Catalog has no separate
• feature-table storage type . Any Delta table in Unity Catalog that carries a primary
• key constraint can be used as a feature table. There is no registration call, no
• proprietary format, and nothing preventing an analyst from querying it with ordinary

SQL.

• That single design decision produces most of the benefits listed above. A feature table
• is a governed Delta table, so every capability the platform already has — grants, tags,
• comments, lineage, Delta history, OPTIMIZE — applies to it with no parallel

implementation.

Requirements to satisfy

• Requirement Value
• Databricks Runtime 13.2 or above for Feature Engineering in Unity Catalog
• Metastore Unity Catalog enabled, Privilege Model Version 1.0
• Primary key Required; every primary key column must be NOT NULL
• Time-series tables One column marked TIMESERIES (Databricks Runtime 13.3 LTS or above)
• Ownership Only the table owner may declare the primary key constraint
• Promoting an existing Delta table
• Because the requirement is only a constraint, an existing Delta table becomes a feature

table with two DDL statements — no data movement and no rewrite: ALTER TABLE prod_catalog.ml_features.customer_spending

ALTER COLUMN customer_id SET NOT NULL;

• ALTER TABLE prod_catalog.ml_features.customer_spending
• ADD CONSTRAINT customer_spending_pk PRIMARY KEY (customer_id);
• The order matters: the NOT NULL designation must be in place on every column named in
• the key before the primary key constraint is added. The legacy workspace feature store
• offered no equivalent path — a table had to be created through the feature store client
• and registered in a workspace-local registry, so adopting an existing curated table

meant copying it.

• Privileges involved
• Setting up the namespace uses ordinary Unity Catalog privileges rather than a

feature-store-specific permission model:

CREATE CATALOG on the metastore to create a new catalog, or USE CATALOG on an

existing one.

CREATE SCHEMA on the catalog to create the schema that will hold feature tables.

SELECT on the table for anyone who trains against it, and MODIFY for the pipeline

identity that writes to it.

• A scenario describing a data scientist who can see a feature table in Catalog Explorer
• but cannot build a training set from it is almost always missing SELECT — not some

feature-store-specific grant.