The Gap Between Analytics and ML
Your data warehouse powers dashboards, reports, and analytics perfectly. But when your team wants to ship an ML model to production, they hit a wall.
The problem is not the data itself. The problem is that data warehouses are optimized for human consumption through SQL and BI tools, not for machine learning pipelines that need consistent, versioned, time-aware feature sets.
This article covers the engineering work required to bridge that gap: transforming a traditional data warehouse into an ML-ready platform that supports the entire model lifecycle from training to production serving.
Why Your Data Warehouse Is Not ML-Ready
1. Point-in-Time Correctness
Data warehouses typically store the current state. For ML training, you need historical point-in-time snapshots.
The problem: When training a model to predict churn, you need to know what features looked like at the time of prediction, not what they look like today.
Example: A customer churned 6 months ago. Your training data needs their account age, purchase count, and support tickets as they were 6 months ago, not their current values.
Most warehouses overwrite historical data or only keep snapshots at daily granularity, which creates data leakage in your training set.
2. Feature Computation Logic Lives in Notebooks
Data scientists compute features in Python notebooks during exploration. When the model goes to production, those same features must be recomputed in production infrastructure.
The problem: Training-serving skew. The feature engineering code that ran in pandas during training does not match the SQL or streaming code running in production.
This causes silent model degradation where predictions are wrong because features are computed differently.
3. No Feature Versioning or Lineage
When you change how a feature is computed, you cannot recreate the exact training dataset used for a model deployed 3 months ago.
The problem: You cannot debug production issues, retrain with new data, or roll back bad deployments because feature definitions drift over time.
4. Batch-Only Pipelines
Data warehouses run on batch schedules (daily, hourly). Real-time ML applications need features computed on streaming data.
The problem: Fraud detection, dynamic pricing, and recommendation systems cannot wait hours for feature updates.
5. Training and Serving Datastores Are Separate
Training pulls from the warehouse. Serving pulls from an application database or cache. These systems are managed separately with no consistency guarantees.
The problem: Features available at training time might not exist at serving time, or their schema might have changed.
The ML-Ready Architecture
An ML-ready data platform has five key components:
1. Feature Store
What it is: A centralized repository for feature definitions, historical values, and online serving.
What it solves:
- Training-serving skew (same code path)
- Feature reuse across teams
- Point-in-time correctness
- Feature versioning and lineage
Tools: Feast, Tecton, AWS SageMaker Feature Store, Databricks Feature Store
2. Feature Engineering Pipelines
What it is: Declarative transformations that run in both batch (training) and streaming (serving) modes.
What it solves:
- Consistent feature computation across environments
- Automatic backfilling of historical features
- Incremental updates for efficiency
Tools: dbt for batch, Apache Flink or Spark Structured Streaming for real-time
3. Offline Store (Training)
What it is: Columnar storage optimized for large historical feature retrievals.
Requirements:
- Time-travel queries (point-in-time joins)
- Fast bulk reads
- Support for large datasets (billions of rows)
Tools: Snowflake, BigQuery, Delta Lake, Iceberg
4. Online Store (Serving)
What it is: Low-latency key-value store for feature retrieval at prediction time.
Requirements:
- Sub-10ms latency for single-entity lookups
- High throughput (thousands of QPS)
- Sync from offline store automatically
Tools: Redis, DynamoDB, Cassandra, Bigtable
5. Feature Registry
What it is: Catalog of all features with schema, lineage, ownership, and version history.
What it enables:
- Feature discovery and reuse
- Impact analysis (which models use this feature?)
- Access control and data governance
Tools: DataHub, Amundsen, built into feature store platforms
The Engineering Work: Step by Step
Phase 1: Audit Current Data
Goal: Understand what features exist.
Tasks:
- List all tables and columns
- Inventory feature engineering code in notebooks
- Map features to business entities
- Identify temporal dependencies
Phase 2: Implement Point-in-Time Correctness
Goal: Ensure training data reflects what was knowable at prediction time.
Implementation:
- Add event timestamp to all fact tables
- Build slowly changing dimension tables
- Implement time-travel queries
Phase 3: Build Feature Engineering Pipelines
Goal: Centralize feature logic.
Batch pipeline (dbt):
Define features as SQL transformations
Run daily to backfill historical features
Materialize results into offline store
Phase 4: Deploy Feature Store
Goal: Single interface for retrieving features.
Setup:
- Offline store: Snowflake or BigQuery
- Online store: Redis or DynamoDB
- Registry: Configure feature definitions
- Sync: Schedule offline to online jobs
Phase 5: Version Features
Goal: Enable reproducible training.
Implementation:
- Tag each feature with a version
- Store definitions in Git
- Log feature versions per training run
- Track data lineage
Phase 6: Monitor Data Quality
Goal: Detect pipeline failures early.
What to monitor:
- Null rates
- Distribution shifts
- Freshness
- Schema changes
Common Pitfalls
1. Building Before You Have Models
Solution: Start with one model. Build infrastructure to support it. Generalize later.
2. Over-Engineering Online Store
Solution: Start offline-only. Add online serving when you have real-time use cases.
3. Not Testing Feature Logic
Solution: Unit test transformations. Integration test pipelines. Compare batch and streaming outputs.
4. Ignoring Data Drift
Solution: Monitor feature distributions. Alert on statistical drift.
5. No Access Controls
Solution: Implement role-based access control. Tag sensitive features.
Key Takeaways
Transforming a data warehouse into an ML-ready platform requires:
Point-in-time correctness to avoid data leakage
Centralized feature engineering to eliminate training-serving skew
Feature stores to manage definitions and serving
Data quality monitoring to catch failures
Both offline and online datastores
This work is foundational. Models trained on bad features fail silently in production.
Start small: pick one model, build infrastructure to support it end-to-end, then generalize.
