Databricks ha annunciato la Public Preview di Feature Views, un framework per creare pipeline di feature managed direttamente nella piattaforma. L’idea di fondo risponde a un problema concreto del real-time ML: una feature che funziona in un notebook, quando va in produzione, si trasforma spesso in logica duplicata, pipeline fragili, backfill una tantum, plumbing per l’online store e overhead di governance. Per casi d’uso come fraud detection, personalizzazione e recommendation, dove i modelli dipendono da segnali freschi, questa complessità pesa ancora di più.
Con Feature Views si definisce la feature una volta (sorgente, entity, colonna time-series e computazione) e la piattaforma gestisce tutto, dall’esperimento al serving in tempo reale. Dalla stessa definizione, il Feature Store genera dati storici point-in-time accurati per sperimentazione e training; quando si è pronti, si materializza la Feature View e Databricks esegue le pipeline che calcolano i dati per l’inference. La stessa definizione supporta sorgenti batch e streaming: passare dall’una all’altra è questione di poche righe di codice.
Perché conta per chi lavora con data stack e ML
Il punto più rilevante è l’eliminazione del training/serving skew: con un’unica definizione, i valori di training e quelli di inference online sono calcolati sulla stessa base e quindi coincidono per costruzione, con meno codice da mantenere. In produzione, registrando la feature in Unity Catalog e chiamando materialize_features, Databricks crea e gestisce le pipeline scrivendo sugli store online e offline; casi limite come il backfill di finestre lunghe o l’espirazione delle righe stale funzionano out of the box.
Sul fronte freshness, le streaming feature possono essere alimentate da Kafka con una latenza end-to-end p99 di 200ms dall’evento alla disponibilità online. Una RollingWindow guarda indietro dal timestamp di ogni evento con risoluzione al millisecondo, così un aggregato come “somma delle transazioni negli ultimi 10 minuti” è sempre aggiornato. Sotto il cofano Databricks orchestra Spark Realtime Mode (aggregati aggiornati per evento invece che per microbatch), Lakebase come online store ottimizzato per lo streaming e Model Serving per il recupero delle feature a inference time.
Le Materialized Features sono trattate come dati: oggetti Unity Catalog di prima classe, discoverable, con access control e lineage completo. Quando si logga un modello con MLflow ne vengono registrate le dipendenze di feature, e a inference time Model Serving le recupera in automatico, senza codice di lookup custom.
In sintesi
- Una sola definizione di feature copre esperimenti, batch e real-time serving, senza gestire l’infrastruttura sottostante.
- Il training/serving skew viene chiuso per costruzione, riducendo il codice da mantenere e la strada verso la produzione.
- La materializzazione streaming richiede un workspace Enterprise-tier in una region che supporta Lakebase.
Fonte: Introducing Feature Views — https://www.databricks.com/blog/introducing-feature-views
Hai qualcosa da aggiungere? Unisciti alla discussione.