A feature is curated data derived from raw data, and a feature store calculates, stores, and serves those values for exploration, training, and production inference.
2
Feature stores address different source characteristics, freshness requirements, time-travel needs, and inconsistencies between offline training and online serving.
3
Tecton focuses on the feature data layer, using declarative Python configuration and automation to backfill, stream, monitor, and serve features in production.
Summary
Kevin Stumpf explains why production ML needs infrastructure for data as well as infrastructure for models. Features are curated values derived from raw data, such as recent order counts or average restaurant preparation times. A feature store must ingest data from warehouses, lakes, streams, and operational databases, then support historical training, recurring training pipelines, and low-latency online prediction. The hard parts include different source capabilities, feature freshness, point-in-time retrieval, and keeping training and serving transformations consistent. Kevin describes how Michelangelo helped Uber standardize the ML workflow, then explains how Tecton concentrates on the feature layer rather than providing an end-to-end modeling platform. Tecton uses versioned Python configuration, integrates with Spark and AWS services, and automates backfills, streaming jobs, storage, serving, and monitoring. It also gives teams visibility into feature usage and processing cost, while monitoring data quality, freshness, and distribution changes.
Features turn raw data into values a model can use
Kevin defines a feature as data for machine learning, usually derived from raw data and curated into high-quality information. A feature can clean raw records, filter outliers, aggregate events, or encode human intuition. His examples include counting how many times a customer ordered a dish in the last 30 days and representing whether the weather is warm or cold. These values help models predict actions such as which restaurant someone may choose or how long an Uber ride may take.
A feature store has to support three different consumers
Feature values must be calculated from raw data and ingested into a store before they can be used. Kevin identifies data scientists exploring historical values, production training pipelines fetching updated values, and production models serving predictions at high scale and low latency. An Uber Eats recommendation or ETA model may have only 10 to 20 milliseconds to fetch its features. The store also needs metadata for discovery, ownership, permissions, trust, and cost.
A feature store becomes useful when teams repeat production problems
A small team working in notebooks with a few features may find a feature store excessive. The signals for adopting one include spending too much time putting models into production, writing pipelines to make feature data available online, and seeing different feature calculations in training and serving. Repeatedly implementing the same feature, combining warehouses with lakes and streams, and sharing features across data scientists are further signs that a central store could help.
Different data sources impose different transformation and freshness limits
Warehouses and data lakes handle large joins and aggregations well, while streams are better for event-level work and bounded temporal aggregations. Operational databases are suited to row-based transformations and smaller aggregations, but may lack older history. Kevin gives a restaurant example where a trailing 30-minute order count should update every minute or five minutes, while a two-week average preparation time can update less often. A feature platform has to manage these different requirements.
Point-in-time correctness prevents training data from lying about the past
Operational ML often needs to reconstruct what the world looked like at a particular time. A training request might ask for 1,000 features for each day across the last 365 days. This time travel is difficult because the system must return historical feature states rather than values that became available later. Kevin also warns that separate offline and online transformations can handle nulls, buckets, or floating-point precision differently. A model can look good in backtesting and fail in production when that happens.
Michelangelo standardized the full path from data to a served model
At Uber, Kevin saw teams build models but struggle with production-grade systems, inconsistent frameworks, and long handoffs between data scientists, software engineers, data engineers, and ML engineers. Michelangelo brought these steps into a centralized platform. It covered raw-data selection, feature engineering, model training, backtesting, evaluation, artifact management, versioning, deployment, serving, and prediction monitoring. Shared features also reduced duplicated work and made existing features easier to find.
Tecton concentrates on the feature layer and connects to modeling tools
Kevin describes Tecton as an enterprise-ready feature store rather than another end-to-end ML platform. Users declare raw sources, feature transformations, entities, ownership, SLAs, and freshness in versioned Python files. A CLI applies the desired state, reports changes, and starts the required pipelines. Tecton can serve interactive historical data, training data, batch predictions, and low-latency online requests, while integrating with tools such as Spark, MLflow, SageMaker, and Seldon.
Tecton automates feature backfills, streaming, and operational checks
When a feature is applied, Tecton determines the required Spark cluster and historical range, runs a backfill, and writes values to offline and online stores. It then starts a streaming job for ongoing freshness. The platform retries failed backfills, checks streaming jobs, watches feature freshness, and alerts when something goes wrong. Kevin also describes monitoring for upstream outages, unexpected feature distributions, and data quality, including an integration with Great Expectations.
Feature stores expose the cost and usage of data pipelines
Reusing an existing feature avoids rebuilding and backfilling its pipeline. A central store can also show the literal compute cost of producing feature values and reveal features that no model consumes. Kevin says costs can be estimated from the data volume, processing frequency, feature-key cardinality, and the frequency of training or online consumption. This gives teams a way to compare feature-processing costs with the models and business use cases that depend on them.
"We are really focused on providing the best in-class feature platform that allows you to curate, manage and serve those feature values."Kevin Stumpf30:26
Who should watch
Your team has models that work in notebooks but takes weeks or months to get them into production.
Different pipelines calculate the same feature differently, or training and serving use inconsistent feature values.
You need to combine batch and streaming data while controlling feature freshness, history, usage, and compute cost.
