# Feature engineering and feature stores A pack of 8 sessions from the MLOps Community YouTube channel, in the order to watch them. 5h 44m of video. Page: https://mlopstalks.com/packs/feature-engineering-and-feature-stores Two models use a feature with the same name, but different calculations. A training join quietly uses today's values for last year's examples. A fast prediction endpoint serves yesterday's view of a customer. These failures need different fixes, and buying a feature store does not settle which one you have. Start with Malt's shared historical tables, then ask when overlapping feature work deserves a shared system. Compare storage with feature computation before following one definition through training and serving. Shopify and Skyscanner add reuse and versioning; LinkedIn and Lyft show when fresher features justify streaming and how to check that they match offline results. Finish with the responsibility that survives every architecture: knowing who consumes a feature, who maintains it, and when it can be retired. ## This pack is for you if - Two teams say they use the same feature, but their calculations disagree. - Your training examples use historical records, but you cannot reconstruct the features available on each date. - You are considering a feature store because serving inputs are stale or differ from training inputs. ## The talks, in order ### 1. BigQuery Feature Store Nicolas Mauti, Malt | 50:39 | MLOps Podcast Video: https://www.youtube.com/watch?v=NtDKbGyRHXQ Summary: https://mlopstalks.com/talks/bigquery-feature-store.md Why first: Copied feature code at Malt produced different calculations under the same name. Mauti shows how daily historical tables solved that problem without a separate feature-store product. This modest design gives you a starting point for deciding how much shared infrastructure your features actually need. ### 2. Mid-Scale Production Feature Engineering Dr. Venkata Pingali, Scribble Data | 1:01:35 | MLOps Meetup Video: https://www.youtube.com/watch?v=1CcYuVVwOGg Summary: https://mlopstalks.com/talks/mid-scale-production-feature-engineering.md Why second: Shared computation becomes more useful when several models need overlapping datasets. Pingali's 2020 discussion connects that need to data shape and reusable intermediate results. It extends Malt's example into criteria you can bring to a comparison of feature-store architectures. ### 3. How Feature Stores Work Simba Khadder, Featureform | 30:33 | DE4AI 2024 Video: https://www.youtube.com/watch?v=DQWjPEXdzJM Summary: https://mlopstalks.com/talks/how-feature-stores-work.md Why here: A feature store can include very different amounts of work. Khadder separates storing computed values from defining and running their transformations, including historical backfills and ongoing updates. That distinction helps you ask what a proposed system includes before following the storage path in Wang's demo. ### 4. Feast Feature Store Deep Dive Felix Wang, Tecton | 28:36 | MLOps Meetup Video: https://www.youtube.com/watch?v=hNnp3o3LmG0 Summary: https://mlopstalks.com/talks/feast-feature-store-deep-dive.md Why here: Wang makes the offline-to-online path concrete, following feature views from historical retrieval into online materialization and prediction. His 2021 Feast workshop illustrates the sequence rather than providing a current installation guide. The next account adds the complications that appear when several teams share and change those definitions. ### 5. Feature Stores at Shopify and Skyscanner Matt Delacour, Shopify & Mike Moran, Skyscanner | 49:36 | MLOps Reading Group Video: https://www.youtube.com/watch?v=v42YVgPGKro Summary: https://mlopstalks.com/talks/feature-stores-at-shopify-and-skyscanner.md Why here: Sharing a feature creates a versioning problem as well as a storage problem. Delacour shows why Shopify kept its existing storage and made reuse visible in a shared repository; Moran explains how Skyscanner lets old and new attribute versions coexist. Their unresolved freshness requirements lead into the decision about whether to add streaming. ### 6. "Real-Time" ML: Features and Inference Sasha Ovsankin & Rupesh Gupta, LinkedIn | 51:55 | MLOps Podcast Video: https://www.youtube.com/watch?v=cZpGgobIFxU Summary: https://mlopstalks.com/talks/real-time-ml-features-and-inference.md Why here: Fresh features and fast inference are different requirements. Gupta and Ovsankin recommend starting with real-time versions of batch features that already matter, combining recent and historical signals. This supplies a test for when the extra work is justified; Kumar's Lyft account then exposes its implementation cost. ### 7. Real-time Feature Generation at Lyft Rakesh Kumar, Lyft | 58:05 | MLOps Podcast Video: https://www.youtube.com/watch?v=saAezbQqarc Summary: https://mlopstalks.com/talks/real-time-feature-generation-at-lyft.md Why here: Kumar describes Lyft comparing online features against offline results and declining real-time requests that batch data can satisfy. Those checks put the preceding freshness trade-offs into practice. They also leave a longer-term question: how to keep shared computation useful after the features have shipped. ### 8. The Evolution of Lyft's Feature Store Devon Mittow, Lyft | 13:13 | DE4AI 2024 Video: https://www.youtube.com/watch?v=tI974V6yMsQ Summary: https://mlopstalks.com/talks/the-evolution-of-lyfts-feature-store.md Why last: A feature service can accumulate values that nobody will maintain. Mittow follows Lyft's serving work into that maintenance problem: usage logs help find consumers and remove unused features, while sampled reads expose dependencies that manual records miss. Reuse only stays useful if someone can still explain and change the feature you chose to share.