Schedule icon
Webhook icon
Script icon
OutputValues icon
If icon
SlackIncomingWebhook icon

Feast Feature Store Offline-to-Online Materialization Gate

Automate Feast ML feature store offline-to-online materialization to Redis in Kestra. Audit feature freshness and eliminate training-serving skew.

Categories
AIData

Production machine learning models (such as real-time fraud scoring, recommendation engines, and dynamic pricing models) rely on low-latency online key-value stores (Redis, DynamoDB, PostgreSQL) to serve feature vectors within milliseconds. Meanwhile, training pipelines compute features asynchronously over historical batch data lakes (S3 Parquet, Snowflake, BigQuery).

Without automated orchestration, the online feature store drifts out of synchronization with the offline store, causing catastrophic training-serving skew where production models evaluate decisions on stale or missing feature values.

This blueprint automates incremental feature store materialization using Feast. It synchronizes feature views into online stores, verifies feature freshness against strict SLA thresholds, audits null feature rates, and fires instant Slack alerts if training-serving skew is detected.

How it works

  1. Scheduled & Event-Driven Triggering: Runs on an automated hourly schedule (0 * * * *) or triggers via webhooks (on_pipeline_completion_webhook) when upstream dbt or Spark feature transformation pipelines finish.
  2. Feast Incremental Materialization: An isolated container loads the Feast repository and synchronizes feature views over the configured historical lookback window (materialization_lookback_hours) into the target online store (REDIS, POSTGRESQL, DYNAMODB).
  3. Freshness & Null-Rate Auditing:
    • Staleness Verification: Measures the latest materialized feature timestamp and asserts that feature age does not exceed max_allowable_staleness_minutes.
    • Null Tolerance Gate: Computes missing key ratios across entity sets, ensuring data corruption or upstream join failures do not populate online stores with null vectors.
  4. Compliance Gate & Slack Alerting: An io.kestra.plugin.core.flow.If condition evaluates audit metrics:
    • On Skew Detected: Fires an emergency Slack alert to #mlops-sentinel and flags the pipeline.
    • On Clean Freshness: Emits a green operational status digest and publishes typed output metrics.
  5. Typed Downstream Outputs: Exposes features_materialized, staleness_minutes, and report_uri for downstream model inference canary checks.

What you get

  • Zero Training-Serving Skew: Keeps online Redis/DynamoDB feature stores continuously synchronized with offline batch data.
  • Automated Freshness Defense: Detects stale feature pipelines before outdated values degrade live model inference accuracy.
  • Data Quality Audits: Tracks null-feature ratios to prevent upstream data loss from entering production inference paths.
  • Multi-Store Support: Flexibly materializes to Redis, PostgreSQL, DynamoDB, or SQLite.

Expected outputs

Downstream ML canary jobs or monitoring dashboards can reference the typed metrics produced by output_materialization_metrics:

Output Variable Description Expression Example
total_entities Total number of unique entity keys synchronized {{ outputs.output_materialization_metrics.values.total_entities }}
features_materialized Total count of feature values written to the online store {{ outputs.output_materialization_metrics.values.features_materialized }}
online_store Target online storage engine (REDIS, POSTGRESQL) {{ outputs.output_materialization_metrics.values.online_store }}
staleness_minutes Measured age of the freshest materialized features {{ outputs.output_materialization_metrics.values.staleness_minutes }}
null_rate_pct Average percentage of null or missing feature values {{ outputs.output_materialization_metrics.values.null_rate_pct }}
gate_passed Boolean flag indicating whether freshness and null SLAs were met {{ outputs.output_materialization_metrics.values.gate_passed }}
compliance_verdict Freshness determination (COMPLIANT_FRESH or TRAINING_SERVING_SKEW_DETECTED) {{ outputs.output_materialization_metrics.values.compliance_verdict }}
duration_seconds Total materialization and verification processing time {{ outputs.output_materialization_metrics.values.duration_seconds }}
report_uri Internal Kestra storage URI to materialization_report.json {{ outputs.output_materialization_metrics.values.report_uri }}

Who it's for

  • MLOps & Machine Learning Engineers maintaining production real-time inference pipelines and feature stores.
  • Data Platform Teams establishing reliable feature pipelines between batch data lakes and real-time inference clusters.
  • Data Science Teams requiring guaranteed feature consistency between model training and real-time inference.

Why orchestrate this with Kestra

Running materialization via unmonitored cron jobs leads to silent sync failures, unmanaged Redis connection leaks, and undetected model degradation. Kestra provides:

  • Orchestrated Dependency Chains: Trigger materialization immediately after upstream dbt or Spark feature DAGs complete.
  • Centralized Credential Security: Inject Redis and cloud database credentials securely from Kestra Secrets without plaintext scripts.
  • Comprehensive Observability: Track materialization latency, feature counts, and freshness metrics on unified dashboards.

Prerequisites

  • A Feast feature repository with feature_store.yaml configured.
  • Low-latency online store (Redis, PostgreSQL, or DynamoDB) with write access.
  • An incoming Slack webhook URL for MLOps notifications.

Secrets

Configure the following secrets in your Kestra namespace or instance settings:

Secret Name Description Example
SLACK_WEBHOOK_URL Incoming webhook URL for MLOps alerts https://hooks.slack.com/services/T00/B00/X00
WEBHOOK_KEY Secret authentication key for upstream pipeline webhooks whk_feast_sync_58192
REDIS_HOST (Optional) Hostname for Redis online store redis-cluster.internal
REDIS_PASSWORD (Optional) Password for Redis authentication ••••••••••••

Quick start

  1. Import this blueprint into your Kestra instance under the company.ai namespace.
  2. Add SLACK_WEBHOOK_URL and WEBHOOK_KEY into Settings > Secrets.
  3. Click Execute with default parameters to simulate feature materialization and inspect freshness scorecards.
  4. Connect the webhook to your upstream dbt or Spark feature engineering pipeline.

Common pitfalls & notes

  • Lookback Window Sizing: Keep materialization_lookback_hours aligned with your batch pipeline cadence (e.g. 24h for daily batch jobs, 2h for hourly updates) to avoid redundant computation.
  • Redis Memory Sizing: Monitor Redis cluster memory when materializing hundreds of millions of entity keys; set appropriate TTL policies in Feast feature view definitions.

How to extend

  • Model Canary Evaluation: Chain a downstream task to invoke a canary model endpoint using newly materialized online features to verify latency SLAs.
  • Automated Feature Invalidation: Add an eviction task that purges defunct or deprecated feature views from the online store.
  • Prometheus Metric Export: Push materialization duration and entity counts to Prometheus or Datadog via Kestra HTTP tasks.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.