What is a Feature? Feature Engineering Explained for Data Engineers

Two teams ask how many orders customer 5 placed in 30 days. One gets 13, the other gets 15, and both are right. That number is a feature, and this is who owns it. This is feature engineering explained from the pipeline side, not the notebook side. I cover what a feature actually is (a value about one entity at one moment), the four families features fall into, and training-serving skew: the silent failure where one definition exists twice and 706 of 1,000 customers get two different values. Then where a feature should live (notebook, dbt model in the warehouse, or a feature store like Feast), when to buy external signals instead of building them, and point-in-time correctness: how a leaked join made a feature look over four times as predictive as it is, and how a DuckDB ASOF join fixes it. Finally, the four lines every feature needs written above it so it survives the next person who touches it. ⏱️ Chapters 0:00 - Two teams, one feature, two answers 0:30 - What this video covers 1:23 - What a feature actually is 2:23 - The four families of features 3:45 - Training-serving skew: the silent failure 5:08 - Where features live: notebook, warehouse, store 6:19 - Buying features: external signals 7:27 - Point-in-time correctness 8:48 - What the leak does to your numbers 10:22 - How to document a feature so it survives 11:28 - Recap 12:02 - When you don't need a feature store 🔗 Links Feast: https://feast.dev PredictHQ: https://www.predicthq.com DuckDB ASOF join: https://duckdb.org/docs/guides/sql_features/asof_join dbt: https://www.getdbt.com #featureengineering #featurestore #dataengineering #featureengineering #featurestore #Feast #trainingservingskew #pointintimecorrectness #dataleakage #dataengineering #machinelearning #MLOps #DuckDB #dbt #asofjoin #PredictHQ #mlfeatures