Defina feature views con Feast

In Feast you describe features with code: an Entity, a data source, and a Feature View. Get these three right and the rest follows. 🏗️

An Entity is the thing your features describe, like a driver or a customer. It is the key you will look features up by later.

A data source tells Feast where the raw feature values live, such as a Parquet file or a warehouse table.

A FeatureView groups related features for one entity and links them to a source. It is the heart of a Feast definition.

Inside a Feature View, each Field names a feature and its data type, so Feast knows the schema it will serve.

One Feature View ties the entity, schema, and source into a single object Feast can manage. 🔗

A Feature View's ttl sets how long a value stays valid. Past that window, Feast treats the feature as missing rather than stale.

Every source needs an event timestamp column. It records when each value was true, which makes time-correct lookups possible.

Your definitions live in a feature repo folder with a feature_store.yaml config. Feast scans Python files there to find your objects.

Running feast apply registers your entities and feature views into the registry. Nothing is live until you apply.

The registry is Feast's catalog of every entity and feature view. Teammates query it to discover what features already exist. 📒

Which object does a Feature View group features around?

You defined Feast objects: an Entity, a source, and a Feature View with fields and a ttl, then ran feast apply to register them. Next, you'll serve them online.