Definire feature view con Feast

In Feast descrivete le feature con il codice: un'Entity, una fonte di dati e una Feature View. Se impostate correttamente questi tre elementi, il resto viene di conseguenza. 🏗️

Un'Entity è l'elemento descritto dalle vostre feature, come un conducente o un cliente. È la chiave che userete in seguito per cercare le feature.

Una data source indica a Feast dove risiedono i valori grezzi delle feature, ad esempio in un file Parquet o in una tabella di data warehouse.

Una FeatureView raggruppa le feature correlate di un'entità e le collega a una fonte. È il cuore di una definizione Feast.

All'interno di una Feature View, ogni Field assegna un nome a una feature e ne indica il tipo di dati, così Feast conosce lo schema che dovrà servire.

Una Feature View riunisce entità, schema e fonte in un unico oggetto che Feast può gestire. 🔗

Il ttl di una Feature View stabilisce per quanto tempo un valore rimane valido. Superata questa finestra, Feast considera la feature mancante anziché obsoleta.

Ogni fonte ha bisogno di una colonna event timestamp. Registra il momento in cui ogni valore era valido, rendendo possibili ricerche temporalmente corrette.

Le vostre definizioni risiedono in una cartella di feature repo contenente una configurazione feature_store.yaml. Feast analizza i file Python presenti per trovare i vostri oggetti.

L'esecuzione di feast apply registra le entità e le feature view nel registry. Nulla è attivo finché non eseguite apply.

Il registry è il catalogo di Feast che contiene ogni entità e feature view. I membri del team lo interrogano per scoprire quali feature esistono già. 📒

Avete definito gli oggetti Feast: un'Entity, una fonte e una Feature View con campi e un ttl, quindi avete eseguito feast apply per registrarli. Ora li servirete online.