Cos'è un Feature Store?

Questo blog è stato originariamente pubblicato da Tecton.ai, che è stato acquisito da Databricks nell'agosto 2025. Dall'acquisizione, Databricks Feature Store ha rilasciato API Dichiarative per le Feature, un'astrazione potente per la sperimentazione di feature che automatizza la creazione di pipeline di feature gestite sia per dati batch che in streaming.

Aggiornato: 15 maggio 2025

Informazioni sugli autori:
Mike Del Balso, CEO & Co-Founder di Tecton
Willem Pienaar, Creatore di Feast

I team di dati stanno iniziando a rendersi conto che il machine learning operativo richiede la risoluzione di problemi di dati che vanno ben oltre la creazione di pipeline di dati.

In un post precedente, Why We Need DevOps for ML Data, abbiamo evidenziato alcune delle sfide chiave relative ai dati che i team affrontano quando mettono in produzione sistemi di ML.

• Accesso ai dati grezzi corretti
• Costruzione di feature dai dati grezzi
• Combinazione di feature in dati di training
• Calcolo e serving di feature in produzione
• Monitoraggio delle feature in produzione

I sistemi di dati di produzione, sia per l'analisi su larga scala che per lo streaming in tempo reale, non sono nuovi. Tuttavia, l'apprendimento automatico operativo — intelligenza guidata da ML integrata nelle applicazioni rivolte ai clienti — è una novità per la maggior parte dei team. La sfida di distribuire l'apprendimento automatico in produzione per scopi operativi (ad es. sistemi di raccomandazione, rilevamento frodi, personalizzazione, ecc.) introduce nuovi requisiti per i nostri strumenti di dati.

Sta emergendo un nuovo tipo di infrastruttura dati specifica per ML per renderlo possibile.

Sempre più team di Data Science e Data Engineering si rivolgono ai feature store per gestire i set di dati e le pipeline di dati necessarie per mettere in produzione le loro applicazioni di ML. Questo post descrive i componenti chiave di un feature store moderno e come la somma di queste parti agisce da moltiplicatore di forza per le organizzazioni, riducendo la duplicazione degli sforzi di data engineering, accelerando il ciclo di vita del machine learning e sbloccando un nuovo tipo di collaborazione tra i team di data science.

Breve ripasso: in ML, una feature è un dato utilizzato come segnale di input per un modello predittivo.

Ad esempio, se una società di carte di credito sta cercando di prevedere se una transazione è fraudolenta, una feature utile potrebbe essere se la transazione avviene in un paese straniero, , o come la dimensione di questa transazione si confronta con la transazione tipica del cliente. Quando ci riferiamo a una feature, di solito ci riferiamo al concetto di quel segnale (ad es. “transaction_in_foreign_country”), non a un valore specifico della feature (ad es. non “transaction #1364 was in a foreign country”).

Qual è lo scopo principale di un Feature Store

“L'interfaccia tra modelli e dati”

Abbiamo introdotto per la prima volta i feature store nel nostro post sul blog che descrive la piattaforma Michelangelo di Uber. Da allora, i feature store sono emersi come un componente necessario dello stack di machine learning operativo.

I vantaggi dei feature store includono:

1. Messa in produzione di nuove feature senza un esteso supporto di ingegneria
2. Automazione del calcolo delle feature, dei backfill e del logging
3. Condivisione e riutilizzo delle pipeline di feature tra team
4. Tracciamento delle versioni delle feature, della lineage e dei metadati
5. Ottenimento della coerenza tra dati di training e di serving
6. Monitoraggio dello stato di salute delle pipeline di feature in produzione

I feature store mirano a risolvere l'intero set di problemi di gestione dei dati incontrati durante la creazione e l'operatività di applicazioni di ML operative.

Un feature store è un sistema di dati specifico per ML che:

• Esegue pipeline di dati che trasformano i dati grezzi in valori di feature
• Memorizza e gestisce i dati delle feature stessi, e
• Serve i dati delle feature in modo coerente per scopi di training e inferenza

Per supportare una gestione semplice delle feature, i feature store forniscono astrazioni di dati che rendono facile costruire, distribuire e ragionare sulle pipeline di feature in diversi ambienti. Ad esempio, rendono facile definire una trasformazione di feature una volta, quindi calcolare e servire i suoi valori in modo coerente sia nell'ambiente di sviluppo (per il training con valori storici) sia nell'ambiente di produzione (per l'inferenza con valori di feature aggiornati).

I feature store agiscono come un hub centrale per i dati delle feature e i metadati durante il ciclo di vita di un progetto ML. I dati in un feature store vengono utilizzati per:

• Esplorazione e ingegnerizzazione delle feature
• Iterazione, training e debug del modello
• Scoperta e condivisione delle feature
• Serving in produzione a un modello per l'inferenza
• Monitoraggio dello stato operativo

I feature store portano economie di scala alle organizzazioni ML abilitando la collaborazione. Quando una feature viene registrata in un feature store, diventa disponibile per il riutilizzo immediato da parte di altri modelli nell'organizzazione. Ciò riduce la duplicazione degli sforzi di data engineering e consente ai nuovi progetti ML di avviarsi con una libreria di feature curate e pronte per la produzione.

I feature store efficaci sono progettati per essere sistemi modulari che possono essere adattati all'ambiente in cui vengono distribuiti. Ci sono cinque componenti principali che tipicamente costituiscono un feature store. Nel resto di questo post, esamineremo tali componenti e descriveremo il loro ruolo nell'alimentare le applicazioni ML operative.

Quali sono i componenti di un Feature Store

Ci sono 5 componenti principali di un feature store moderno: Trasformazione, Archiviazione, Serving, Monitoraggio e Registro delle Feature.

Nelle sezioni seguenti forniremo una panoramica dello scopo e delle capacità tipiche di ciascuna di queste sezioni.

Serving dei dati delle feature

I feature store servono dati delle feature ai modelli. Questi modelli richiedono una visione coerente delle feature tra training e serving. Le definizioni delle feature utilizzate per addestrare un modello devono corrispondere esattamente alle feature fornite nel serving online. Quando non corrispondono, viene introdotto uno skew tra training e serving, che può causare problemi catastrofici e difficili da debuggare nelle prestazioni del modello.

I feature store astraggono la logica e l'elaborazione utilizzate per generare una feature, fornendo agli utenti un modo semplice e canonico per accedere a tutte le feature di un'azienda in modo coerente in tutti gli ambienti in cui sono necessarie.

Quando si recuperano dati offline (ad esempio, per l'addestramento), i valori delle feature vengono comunemente acceduti tramite SDK di feature store compatibili con i notebook. Forniscono viste corrette nel tempo dello stato del mondo per ogni esempio utilizzato per addestrare un modello (noto anche come "time-travel").

Per il serving online, un feature store fornisce un singolo vettore di feature alla volta composto dai valori delle feature più recenti. Le risposte vengono servite tramite un'API ad alte prestazioni supportata da un database a bassa latenza.

Archiviazione Dati per Machine Learning

I feature store persistono i dati delle feature per supportare il recupero tramite livelli di feature serving. Solitamente contengono sia un livello di archiviazione online che offline per supportare i requisiti dei diversi sistemi di feature serving.

I livelli di archiviazione offline vengono tipicamente utilizzati per archiviare mesi o anni di dati delle feature per scopi di addestramento. I dati del feature store offline sono spesso archiviati in data warehouse o data lake come S3, BigQuery, Snowflake, Redshift. L'estensione di un data lake o data warehouse esistente per l'archiviazione di feature offline è generalmente preferita per evitare silos di dati.

I livelli di archiviazione online vengono utilizzati per persistere i valori delle feature per ricerche a bassa latenza durante l'inferenza. Solitamente archiviano solo i valori delle feature più recenti per ogni entità, modellando essenzialmente lo stato attuale del mondo. Gli store online sono solitamente eventualmente consistenti e non hanno requisiti di coerenza rigorosi per la maggior parte dei casi d'uso di ML. Sono solitamente implementati con store chiave-valore come DynamoDB, Redis o Cassandra.

I feature store utilizzano un modello dati basato su entità in cui ogni valore di feature è associato a un'entità (ad esempio, un utente) e a un timestamp. Un modello dati basato su entità fornisce una struttura minima per supportare la gestione standardizzata delle feature, si adatta naturalmente ai flussi di lavoro comuni di feature engineering e consente semplici query di recupero in produzione.

Trasformazione Dati nel Machine Learning

Le applicazioni ML operative richiedono l'elaborazione regolare di nuovi dati in valori di feature in modo che i modelli possano fare previsioni utilizzando una visione aggiornata del mondo. I feature store gestiscono e orchestrano le trasformazioni dei dati che producono questi valori, oltre a ingerire valori prodotti da sistemi esterni. Le trasformazioni gestite dai feature store sono configurate da definizioni in un registro di feature comune (descritto di seguito).

I feature store interagiscono comunemente con tre tipi principali di trasformazioni dei dati:

Un vantaggio chiave è rendere facile l'utilizzo di diversi tipi di feature insieme negli stessi modelli.

I modelli necessitano di accesso a valori di feature freschi per l'inferenza. I feature store ottengono questo risultato ricalcolando regolarmente le feature su base continuativa. I job di trasformazione sono orchestrati per garantire che i nuovi dati vengano elaborati e trasformati in nuovi valori di feature freschi. Questi job vengono eseguiti su motori di elaborazione dati (ad esempio, Spark o Pandas) a cui è connesso il feature store.

Lo sviluppo del modello introduce diversi requisiti di trasformazione. Durante l'iterazione su un modello, nuove feature vengono spesso ingegnerizzate per essere utilizzate in set di dati di addestramento che corrispondono a eventi storici (ad esempio, tutti gli acquisti negli ultimi 6 mesi). Per supportare questi casi d'uso, i feature store rendono facile eseguire "job di backfill" che generano e persistono valori storici di una feature per l'addestramento. Alcuni feature store eseguono automaticamente il backfill delle feature appena registrate per intervalli di tempo preconfigurati per i set di dati di addestramento registrati.

Il codice di trasformazione viene riutilizzato tra gli ambienti, prevenendo lo skew tra training e serving e liberando i team dalla necessità di riscrivere il codice da un ambiente all'altro.

Monitoraggio Machine Learning

Quando qualcosa va storto in un sistema ML, di solito è un problema di dati. I feature store sono posizionati in modo univoco per rilevare e far emergere tali problemi. Possono calcolare metriche sulle feature che archiviano e servono, descrivendo correttezza e qualità. I feature store monitorano queste metriche per fornire un segnale sulla salute generale di un'applicazione ML.

I dati delle feature possono essere validati in base a schemi definiti dall'utente o altri criteri strutturali. La qualità dei dati viene monitorata rilevando drift e skew tra training e serving. Ad esempio, i dati delle feature serviti ai modelli vengono confrontati con i dati su cui il modello è stato addestrato per rilevare incongruenze che potrebbero degradare le prestazioni del modello.

Quando si eseguono sistemi di produzione, è anche importante monitorare le metriche operative. I feature store tracciano metriche operative relative alla funzionalità principale, ad esempio, metriche relative all'archiviazione delle feature (disponibilità, capacità, utilizzo, obsolescenza) o al feature serving (throughput, latenza, tassi di errore). Altre metriche descrivono le operazioni di importanti componenti di sistema adiacenti, come metriche operative per motori di elaborazione dati esterni (ad esempio, tasso di successo dei job, throughput, ritardo e tasso di elaborazione).

I feature store rendono queste metriche disponibili all'infrastruttura di monitoraggio esistente. Ciò consente di monitorare e gestire la salute delle applicazioni ML con gli strumenti di osservabilità esistenti nello stack di produzione.

Avendo visibilità su quali feature sono utilizzate da quali modelli, i feature store possono aggregare automaticamente avvisi e metriche di salute in viste pertinenti a utenti, modelli o consumer specifici.

Registro dei modelli di Machine Learning

Una componente critica in tutti i feature store è un registro centralizzato di definizioni e metadati delle feature standardizzate. Il registro funge da unica fonte di verità per le informazioni su una feature in un'organizzazione.

Il registro è un'interfaccia centrale per le interazioni degli utenti con il feature store. I team utilizzano il registro come catalogo comune per esplorare, sviluppare, collaborare e pubblicare nuove definizioni all'interno e tra i team.

Le definizioni nel registro configurano il comportamento del sistema del feature store. I processi automatizzati utilizzano il registro per pianificare e configurare l'ingestione, la trasformazione e l'archiviazione dei dati. Costituisce la base di quali dati vengono archiviati nel feature store e di come sono organizzati. Le API di serving utilizzano il registro per una comprensione coerente di quali valori delle feature dovrebbero essere disponibili, chi dovrebbe poter accedervi e come dovrebbero essere serviti.

Il registro consente di associare metadati importanti alle definizioni delle feature. Ciò fornisce un percorso per il tracciamento della proprietà, delle informazioni specifiche del progetto o del dominio e un modo per integrare facilmente con sistemi adiacenti. Ciò include informazioni su dipendenze e versioni utilizzate per il tracciamento della lineage.

Per facilitare i flussi di lavoro comuni di debug, conformità e audit, il registro funge da record immutabile di ciò che è disponibile analiticamente e di ciò che è effettivamente in esecuzione in produzione.

Finora, abbiamo esaminato le componenti minime fondamentali di un feature store. In pratica, le aziende hanno spesso esigenze come conformità, governance e sicurezza che richiedono funzionalità aggiuntive focalizzate sull'enterprise. Questo sarà l'argomento di un futuro post sul blog.

Iniziare con i Feature Store

Consideriamo i feature store il cuore del flusso di dati nelle moderne applicazioni di ML. Si stanno rapidamente dimostrando infrastrutture critiche per i team di data science che mettono in produzione l'ML. Ci aspettiamo che il numero di organizzazioni che utilizzano i feature store quadruplichi entro il 2028.

Ci sono alcune opzioni per iniziare con i feature store:

• Feast è un'ottima opzione se hai già pipeline di trasformazione per calcolare le tue feature, ma hai bisogno di un ottimo livello di archiviazione e serving per aiutarti a utilizzarle in produzione. Feast è attualmente disponibile solo su GCP, ma stiamo lavorando sodo per rendere Feast disponibile come feature store leggero per tutti gli ambienti. Resta sintonizzato.
• Tecton è una piattaforma di feature come servizio. Una grande differenza tra Feast e Tecton è che Tecton supporta le trasformazioni, quindi le pipeline di feature possono essere gestite end-to-end all'interno di Tecton. Tecton è un'offerta gestita e un'ottima scelta di feature store se hai bisogno di SLA di produzione, hosting, collaborazione avanzata, trasformazioni gestite (batch/streaming/real-time) e/o funzionalità enterprise.

Abbiamo scritto questo post sul blog per fornire una definizione comune dei feature store man mano che emergono come componente primaria dello stack ML operativo. Crediamo che l'industria stia per vedere un'esplosione di attività in questo settore.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale