Feature Definition Language: Define ML Features as Code

WHY IT EXISTS: In machine learning, the same feature (e.g., user's 7-day purchase count) is needed for both model training on historical data and live predictions on recent data. Without a shared definition, teams build separate, inconsistent data pipelines for each, leading to training-serving skew. A feature definition language provides a single source of truth to solve this.

THE MENTAL MODEL: Think of it as "features-as-code" or a schema definition language (like for a database) but for ML features. You write a declarative file that says, "Here is a feature named avg_transaction_value. It's a float, it's associated with a user_id, and its source data lives in this database table." This definition becomes the canonical blueprint for that feature.

HOW IT WORKS: Using a library like Feast's Python SDK, you write feature definitions that are stored in a central repository, often in Git. A feature store system reads these definitions to orchestrate data movement. For training, it generates point-in-time correct queries against an offline store (like a data warehouse). For serving, it materializes the latest feature values into a low-latency online store (like Redis). The definition file is the contract that connects data sources to the ML application, abstracting away the underlying infrastructure.

WHEN TO USE IT: Use a feature definition language when you need to productionize real-time models and guarantee consistency between the features used for training and serving. It's crucial for MLOps platforms that need to decouple ML model development from data infrastructure, preventing data leakage by enabling point-in-time correct joins.

WHEN NOT TO USE IT: For simple, batch-only ML projects where training-serving skew is not a concern, a full feature definition language and store might be overkill. If your features are static and you don't have a low-latency serving requirement, ad-hoc scripts may be sufficient. It's primarily for operational, real-time systems with structured, timestamped data.

ONE CANONICAL EXAMPLE: Using Feast's Python SDK, a data scientist defines a feature view for user credit scores. The definition specifies the user_id as the entity, points to a Snowflake table as the data source, and declares credit_score as a feature. When feast apply is run, the feature store registers this definition. Later, a training job can ask for historical scores and a real-time API can request the latest score, both using the same feature name.