title: Data Quality Monitoring in Feast 0.64

description: Feast 0.64 adds native data quality monitoring with baseline metrics, batch and serving-log analysis, REST APIs, CLI workflows, and a built-in monitoring UI.

date: 2026-06-26

authors: ["Jitendra Yejare", "Nikhil Kathole", "Francisco Javier Arceo"]

<div class="hero-image">

<img src="/images/blog/feast-dqm-monitoring-hero.png" alt="Feast Data Quality Monitoring" loading="lazy">

</div>

Serving ML models in production is extremely hard.

The reason is simple: production models depend on data from many different places. Every source system has some probability of operational error: a delayed pipeline, a schema change, a column that starts producing nulls, a categorical value that changes meaning, a late partition, a silent backfill, or a service that behaves differently under production traffic.

The more data sources a model depends on, the more chances there are for one of those systems to drift, fail, or change underneath you. That creates a basic tension in ML systems. Models are data hungry and often benefit from orthogonal features from many upstream systems, but every additional upstream dependency increases operational risk. What ML wants for predictive power can conflict with what engineering wants for reliability.

The only way to manage that tension is to monitor what is actually happening in production. Feature quality problems rarely arrive as neat exceptions. A model may keep serving predictions while one upstream table starts producing nulls, a batch pipeline shifts a numeric distribution, or production requests drift away from the training baseline. By the time these issues show up in model metrics, the debugging path usually crosses feature definitions, data sources, materialization jobs, and serving logs.

Feast 0.64 adds a native data quality monitoring system that brings those signals directly into the feature store. Instead of relying on a separate validation framework, Feast can now compute, store, serve, and visualize feature-level statistics across batch data and logged serving data.

The biggest change is that monitoring is now a first-class Feast workflow:

- `feast apply` can compute baseline metrics for registered feature views

- `feast monitor run` can compute scheduled daily, weekly, biweekly, monthly, and quarterly metrics

- REST endpoints expose monitoring jobs, per-feature metrics, aggregate feature-view and feature-service metrics, baselines, and time series

- the Feast UI includes a Monitoring page with filters, summary tabs, feature drilldowns, histograms, and time-series charts

- compute is pushed into supported offline stores where possible, with a Python fallback for other backends

Feast previously supported a Great Expectations-based DQM path for validating historical retrievals. That integration was useful, but it lived outside the normal feature store workflow: users had to install the `feast[ge]` extra, write profiler code, and run validation against saved datasets.

That original integration proved the need for data quality inside Feast. It helped answer an important question: after generating a training dataset, does this dataset satisfy the expectations we care about?

But production feature quality problems usually happen after the training dataset is generated. A pipeline may keep running while an upstream producer changes a column, shifts a distribution, starts sending nulls, or changes the meaning of a categorical value. In those cases, the feature code may be perfectly correct while the data feeding it has changed.

Feast needed monitoring that was closer to the system that actually computes and serves features. By coupling DQM to Feast's compute engines and offline stores, Feast can compute quality metrics where the data already lives, reuse feature metadata, compare batch and serving-log distributions, and expose the results through the same CLI, REST API, and UI used to operate the feature store.

This also helps when teams maintain multiple feature execution paths. For example, a feature may be generated one way for training and another way for low-latency serving or streaming. DQM is not a formal proof that two implementations are equivalent, but distribution metrics, baselines, and serving-log comparisons provide an early warning when those paths start producing meaningfully different values.

The new system is broader and more operational. It automatically computes statistical profiles for registered features, stores them in monitoring tables, and makes them available to the CLI, REST API, and UI. This gives teams the kind of feature health view they need after features are already in production, not only during one historical retrieval.

For each feature, Feast can track:

| Metric family | Examples |

|---|---|

| completeness | row count, null count, null rate |

| numeric profile | mean, standard deviation, min, max |

| percentiles | p50, p75, p90, p95, p99 |

| distributions | numeric histograms or categorical top values |

| aggregate health | feature-view and feature-service summaries |

The simplest way to turn on monitoring is to enable DQM in `feature_store.yaml`:

data_quality_monitoring:

auto_baseline: true

For Feast Operator deployments, the same setting is available on the `FeatureStore` custom resource:

For ongoing monitoring, schedule:

In auto mode, Feast detects the latest event timestamp in the source data and computes metrics across the supported granularities: daily, weekly, biweekly, monthly, and quarterly.

You can also scope monitoring to a specific feature view:

Or compute a specific window and mark it as a baseline:

If a `FeatureService` has logging configured, Feast can compute monitoring metrics from the logged online features:

You can also run batch and log monitoring together:

The page includes three main tabs:

<img src="/images/blog/feast-dqm-ui-all-features.png" alt="Feast DQM Monitoring dashboard showing feature metrics, filters, histograms, and health status" loading="lazy">

Clicking a feature opens a detail page with:

- a distribution chart for numeric histograms or categorical values

- a statistics panel with null rate, mean, standard deviation, min, max, and percentiles

- a granularity selector that can switch between computed windows and baseline

- time-series charts for metric drift, including aggregate statistics and null-rate trends

<img src="/images/blog/feast-dqm-ui-numeric-feature.png" alt="Feast DQM numeric feature detail page with distribution chart, statistics, and time-series analysis" loading="lazy">

<img src="/images/blog/feast-dqm-ui-categorical-feature.png" alt="Feast DQM categorical feature detail page with category distribution and statistics" loading="lazy">

This is the workflow we wanted: feature owners can start from a table of health signals, filter down to the part of the feature store they care about, and then drill into the exact feature whose distribution changed.

Supported backends push computation into the underlying system:

Feast 0.64 also adds the Apache Flink compute engine, continuing the broader move toward a unified compute-engine model. DQM follows the same direction: feature quality checks should be part of the feature platform's execution model, not a sidecar that every team wires up differently.

The UI and CLI are built on top of monitoring APIs that can also be used by external systems:

A typical production setup now looks like this:

1. Add `data_quality_monitoring.auto_baseline: true` to `feature_store.yaml`

The next step for users is simple: enable baselines, run monitoring jobs on the same cadence as your data pipelines, and use the UI to make feature quality visible to the teams that own production models.