Executive summary
Quando un'organizzazione impiega modelli predittivi per prendere decisioni operative in tempo reale, la qualità e la tempestività dei dati forniti a questi modelli diventano fattori determinanti per l'affidabilità del sistema complessivo. Questo articolo analizza le infrastrutture specializzate che permettono di calcolare, archiviare e distribuire in modo efficiente i segnali informativi utilizzati dai modelli, garantendo che i dati impiegati durante lo sviluppo corrispondano esattamente a quelli disponibili durante l'uso effettivo. L'analisi mostra che, sebbene queste infrastrutture abbiano ridotto significativamente i tempi di sviluppo e i rischi di incoerenza tra fase sperimentale e fase operativa, restano problemi aperti legati alla gestione dei dati in tempo reale, alla scalabilità dei meccanismi di governo e all'integrazione con le architetture emergenti per i modelli di linguaggio di ultima generazione.
Background
Il passaggio dal prototipo alla produzione rappresenta una delle sfide più critiche nell'ingegneria del machine learning. Sculley et al. [1] hanno identificato nel 2015 come la frazione di codice dedicata al modello stesso costituisca una porzione minima di un sistema di ML in produzione, mentre la gestione dei dati, il monitoraggio e l'infrastruttura di serving rappresentino la maggior parte della complessità operativa. In questo contesto, la gestione delle feature, le variabili di input calcolate a partire da dati grezzi e fornite ai modelli per l'addestramento e l'inferenza, emerge come uno dei colli di bottiglia principali.
Il problema si articola su almeno tre dimensioni. In primo luogo, il feature engineering richiede competenze specifiche di dominio e produce trasformazioni complesse che devono essere mantenute, versionate e condivise tra team. In secondo luogo, esiste una divergenza strutturale tra l'ambiente di addestramento, in cui le feature vengono calcolate su dati storici con vincoli temporali precisi, e l'ambiente di inferenza, in cui le stesse feature devono essere disponibili con latenze dell'ordine dei millisecondi. Questa divergenza, nota come training-serving skew, costituisce una delle cause più frequenti di degrado silenzioso delle prestazioni dei modelli in produzione [2]. In terzo luogo, la proliferazione di modelli all'interno di un'organizzazione genera duplicazione: team diversi ricalcolano le stesse feature con implementazioni leggermente differenti, introducendo inconsistenze difficili da diagnosticare.
La necessità di affrontare sistematicamente queste sfide ha portato, a partire dal 2017, alla nascita dei feature store come componente infrastrutturale dedicata. Le prime implementazioni sono emerse internamente presso organizzazioni con operazioni di ML su larga scala: Uber ha introdotto il feature store come componente centrale di Michelangelo, la propria piattaforma di ML [3], mentre Airbnb ha sviluppato Zipline, un framework dichiarativo per il feature engineering che ha ridotto i tempi di preparazione dei dati da mesi a giorni [4]. In parallelo, Google ha formalizzato il concetto di pipeline di ML end-to-end con TFX (TensorFlow Extended), presentato a KDD 2017, in cui la validazione e la trasformazione delle feature costituiscono fasi esplicite del workflow [5].
Polyzotis et al. [6] hanno inquadrato il problema in termini di gestione del ciclo di vita dei dati, evidenziando come le sfide di validazione, pulizia e monitoraggio dei dati in pipeline di produzione non siano adeguatamente affrontate dalle soluzioni tradizionali di data management. Una survey di Paleyes et al. [2], pubblicata nel 2022, ha confermato che le difficoltà legate alla gestione dei dati e delle feature rimangono tra le barriere più significative al deployment di sistemi di ML, attraverso un'analisi sistematica di casi reali in diversi settori industriali.
Architettura e principi di funzionamento
Un feature store è un sistema di gestione dati specializzato che fornisce un'interfaccia unificata per la definizione, il calcolo, l'archiviazione e il serving delle feature utilizzate da modelli di machine learning. L'architettura di riferimento si articola attorno a una separazione fondamentale tra due modalità di accesso ai dati, ciascuna ottimizzata per un diverso pattern di utilizzo.
Dual-store architecture
Il componente architetturale più caratteristico dei feature store moderni è la dual-store architecture, che separa fisicamente l'archiviazione e il serving dei dati in due sottosistemi complementari [8]. Il diagramma seguente (Figura 1) illustra l'architettura di riferimento e i flussi di dati principali.
Figura 1, Architettura di riferimento di un feature store con dual-store e feature registry.
graph LR
subgraph Sorgenti dati
A[Data warehouse / Data lake]
B[Event stream]
C[Richiesta di inferenza]
end
subgraph Feature Store
D[Feature registry / Metadata]
E[Offline store<br/>columnar]
F[Online store<br/>key-value]
G[Materializzazione<br/>batch / streaming]
end
subgraph Consumatori
H[Training pipeline]
I[Serving endpoint]
end
A -->|batch| G
B -->|streaming| G
G --> E
G --> F
E -->|point-in-time join| H
F -->|lookup bassa latenza| I
C -->|on-demand feature| I
D -.->|definizioni, lineage| E
D -.->|definizioni, lineage| F
L'offline store (o columnar store) è ottimizzato per query analitiche su grandi volumi di dati storici. Il suo scopo primario è la generazione di training dataset con garanzie di correttezza temporale. Le implementazioni si basano tipicamente su data warehouse colonnari (BigQuery, Redshift, Snowflake) o su formati di storage ottimizzati per letture analitiche (Apache Hudi, Delta Lake, Apache Iceberg). L'offline store mantiene la storia completa dei valori delle feature, consentendo la ricostruzione dello stato delle feature a qualsiasi istante passato.
L'online store (o row store) è ottimizzato per letture a bassa latenza di singoli vettori di feature, tipicamente nell'ordine dei millisecondi. Il suo scopo è fornire i valori più recenti delle feature per l'inferenza in tempo reale. Le implementazioni si basano su database in-memory o key-value store ad alte prestazioni: Redis, DynamoDB, Cassandra, oppure soluzioni specializzate come RonDB nel caso di Hopsworks [8]. L'online store mantiene esclusivamente l'ultimo valore di ciascuna feature per ogni chiave primaria, sacrificando la profondità storica in favore della velocità di accesso.
Il processo di materializzazione collega i due store: le feature calcolate o aggiornate vengono scritte nell'offline store per la persistenza storica e contemporaneamente propagate all'online store per il serving in tempo reale. Questo processo può essere orchestrato in batch (con cadenza periodica) o in streaming (con aggiornamento continuo), a seconda dei requisiti di feature freshness dell'applicazione.
Feature registry e metadata
Il feature registry costituisce il catalogo centralizzato che mantiene le definizioni delle feature, i relativi metadati e le dipendenze. Ogni feature è descritta da uno schema che include il nome, il tipo di dato, la sorgente dati, la logica di trasformazione, il proprietario, le policy di accesso e la data di creazione. Il registry abilita la feature discovery, la possibilità per i data scientist di cercare e riutilizzare feature esistenti, e la feature lineage, la tracciabilità delle dipendenze tra dati grezzi, trasformazioni e feature calcolate.
Feast, il feature store open-source più diffuso, implementa il registry come un object store serializzato (su GCS, S3 o file locale) che persiste le definizioni registrate tramite SDK Python [9]. Hopsworks adotta un approccio più strutturato, con un registry integrato nella piattaforma che supporta ricerca full-text, versionamento e governance dei metadati [8]. Tecton, piattaforma enterprise nata dal team che ha sviluppato Michelangelo, implementa il paradigma features-as-code, in cui le definizioni delle feature sono dichiarate in codice Python e gestite con workflow di CI/CD analoghi a quelli del software engineering [10].
Tipologie di feature computation
I feature store distinguono tre modalità di calcolo delle feature, ciascuna con caratteristiche di latenza, complessità e costo differenti.
Le batch feature vengono calcolate periodicamente (tipicamente con cadenza oraria o giornaliera) su grandi volumi di dati storici tramite framework di processing distribuito come Apache Spark. Sono adatte per segnali che cambiano lentamente, ad esempio il numero medio di transazioni mensili di un cliente o il rating medio di un prodotto. Il costo computazionale è ammortizzato su finestre temporali ampie, ma la freshness è intrinsecamente limitata dall'intervallo di schedulazione.
Le streaming feature vengono calcolate in modo continuo su flussi di eventi in tempo reale, tipicamente tramite Apache Flink, Apache Kafka Streams o Spark Structured Streaming. Sono adatte per segnali che richiedono aggiornamento nell'ordine dei secondi o dei minuti, ad esempio il numero di tentativi di login nell'ultima ora o la velocità media di un veicolo negli ultimi cinque minuti. La complessità operativa è significativamente superiore rispetto al batch, poiché richiede la gestione di late-arriving data, deduplicazione e exactly-once processing.
Le on-demand feature (o real-time feature) vengono calcolate al momento della richiesta di inferenza, inline con il flusso di predizione. Sono necessarie quando il valore della feature dipende dal contesto specifico della richiesta, ad esempio la distanza geografica tra un utente e un punto vendita, o il tempo trascorso dall'ultima interazione. Queste feature non possono essere pre-calcolate e materializzate, poiché il loro valore è funzione di parametri noti solo al momento della richiesta. Il vincolo principale è la latenza: l'intero calcolo deve completarsi entro il budget di latenza del serving endpoint, tipicamente inferiore a 100 millisecondi [10].
Point-in-time correctness e consistenza dei dati
La garanzia di point-in-time correctness rappresenta una delle funzionalità più critiche e tecnicamente impegnative di un feature store, nonché una delle ragioni principali che ne motivano l'adozione rispetto a soluzioni di data management generiche.
Il problema del data leakage temporale
Nella costruzione di un training dataset, ogni esempio di addestramento è associato a un timestamp che rappresenta il momento in cui l'evento di interesse è stato osservato. Le feature associate a quell'esempio devono riflettere esclusivamente le informazioni disponibili prima di quel momento. L'inclusione di informazioni successive, fenomeno noto come data leakage temporale, introduce una correlazione spuria tra feature e target che gonfia le metriche di valutazione offline ma degrada le prestazioni in produzione, dove tali informazioni non sono disponibili al momento della predizione.
Si consideri un modello di credit scoring che utilizza come feature il numero di transazioni del cliente nell'ultimo mese. Se il training dataset viene costruito con una join standard tra la tabella dei label e la tabella delle feature, senza vincoli temporali, il modello potrebbe ricevere come input il conteggio delle transazioni calcolato dopo la data di osservazione del default, includendo dunque informazioni causalmente successive all'evento da predire. La conseguenza è un modello che appare eccellente in fase di valutazione offline ma produce predizioni degradate in produzione.
Point-in-time join
Il meccanismo di point-in-time join (o temporal join, o AS OF join) risolve questo problema eseguendo, per ogni esempio di addestramento, una join tra la tabella dei label e la tabella delle feature vincolata dal timestamp. Per un esempio con timestamp $t$, la join restituisce il valore più recente della feature il cui timestamp è $\leq t$ [11]. Formalmente, dato un evento di addestramento $(e_i, t_i)$ con chiave primaria $k_i$, il valore della feature $f$ associato è:
$$f(k_i, t_i) = \arg\max_{t_j \leq t_i} { v_j \mid (k_j, t_j, v_j) \in F \wedge k_j = k_i }$$
dove $F$ è la tabella storica dei valori della feature. Questa operazione, computazionalmente più costosa di una join standard per la necessità di ordinamento temporale e di scansione per-record, è implementata nativamente nei feature store moderni. Databricks, AWS SageMaker e Hopsworks offrono API dedicate che gestiscono automaticamente la semantica temporale [8, 11].
Feature freshness e staleness
La feature freshness, il tempo trascorso tra l'ultimo aggiornamento di una feature e il momento in cui viene servita per l'inferenza, rappresenta un parametro critico che influenza direttamente la qualità delle predizioni. Il problema non è uniforme: alcune feature tollerano aggiornamenti con cadenza giornaliera (ad esempio statistiche aggregate su profili utente), mentre altre richiedono freschezza nell'ordine dei secondi (ad esempio il conteggio di transazioni sospette in una finestra temporale mobile per la rilevazione di frodi).
Tecton ha documentato come un ritardo di una sola ora nel calcolo di feature per un modello di raccomandazione di offerte di lavoro produca un degrado del 3.5% nelle metriche di performance [12]. Questo risultato evidenzia come la staleness delle feature non sia un problema astratto ma abbia un impatto misurabile e significativo sugli outcome di business.
La gestione della freshness richiede un compromesso esplicito tra tre fattori: latenza (quanto velocemente la feature viene aggiornata), costo computazionale (le risorse necessarie per il calcolo e la materializzazione) e complessità operativa (la difficoltà di mantenere pipeline di streaming rispetto a pipeline batch). I feature store moderni consentono di dichiarare freshness SLA per ciascuna feature, lasciando alla piattaforma la scelta del meccanismo di materializzazione più appropriato.
Analisi comparativa delle piattaforme
Il panorama dei feature store si è significativamente diversificato dal 2017 ad oggi. L'analisi che segue esamina le tre piattaforme di riferimento, Feast, Hopsworks e Tecton, evidenziando le scelte architetturali distintive e i rispettivi trade-off.
Feast: modularità e integrazione con infrastrutture esistenti
Feast [9] adotta un approccio unbundled: non impone un'infrastruttura proprietaria ma si integra con i sistemi di storage già presenti nell'organizzazione. L'offline store può essere BigQuery, Redshift, Snowflake, Spark o un file system locale; l'online store può essere Redis, DynamoDB, PostgreSQL o SQLite. Il feature server è implementato come servizio REST basato su FastAPI, espone endpoint per il recupero delle feature e supporta operazioni di push e materializzazione.
Questo approccio presenta vantaggi significativi in termini di flessibilità e costo di adozione: un'organizzazione può iniziare con un'installazione minimale (file locale + SQLite) e scalare progressivamente verso infrastrutture distribuite senza cambiare le definizioni delle feature. Il limite principale risiede nella mancanza di supporto nativo per streaming feature e nella limitata capacità di governance: il registry basato su object store non offre ricerca full-text, versionamento granulare o controlli di accesso sofisticati. Feast è la scelta naturale per team che operano su infrastrutture eterogenee e privilegiano il controllo diretto sullo stack tecnologico.
Hopsworks: piattaforma integrata con prestazioni di riferimento
Hopsworks [8] adotta l'approccio opposto: una piattaforma verticalmente integrata in cui il feature store è un componente nativo dell'ecosistema. L'offline store si basa su Apache Hudi con supporto per data lakehouse esterni (Snowflake, Databricks, BigQuery), mentre l'online store è alimentato da RonDB, un database in-memory sviluppato internamente e derivato da MySQL NDB Cluster, ottimizzato per letture a latenza ultra-bassa.
I risultati di benchmark peer-reviewed, presentati a SIGMOD 2024, documentano prestazioni di primo piano: RonDB raggiunge oltre 250.000 operazioni al secondo con latenza p99 di 7.5 ms, un ordine di grandezza superiore in throughput e inferiore in latenza rispetto a AWS SageMaker Feature Store e GCP Vertex AI Feature Store [8]. La piattaforma supporta nativamente feature group con versionamento, lineage, ricerca full-text sul registry e feature view che implementano point-in-time join con semantica dichiarativa.
Il trade-off è la maggiore dipendenza dalla piattaforma: Hopsworks impone una scelta infrastrutturale più vincolante rispetto a Feast, e il deployment richiede la gestione dell'intero stack Hopsworks (o l'utilizzo del servizio managed). Per organizzazioni con requisiti stringenti di latenza e throughput nell'online serving, e con volumi di feature nell'ordine delle decine di migliaia, Hopsworks rappresenta la soluzione con le migliori prestazioni documentate.
Tecton: enterprise feature platform
Tecton [10] si è posizionata come piattaforma enterprise fully-managed, fondata da membri del team che ha sviluppato Michelangelo in Uber. Il differenziatore principale è il supporto nativo e unificato per i tre tipi di feature computation (batch, streaming e on-demand) all'interno di un unico framework dichiarativo. Le feature view di Tecton definiscono sia la logica di trasformazione sia le policy di materializzazione, e il sistema orchestra automaticamente le pipeline di calcolo appropriate.
Il paradigma features-as-code di Tecton allinea il ciclo di vita delle feature a quello del software: le definizioni vengono versionate in repository Git, validate tramite CI/CD, e promosse attraverso ambienti (sviluppo, staging, produzione) con workflow di approvazione. Questo approccio facilita la collaborazione tra data scientist e ML engineer e riduce il rischio di configurazioni inconsistenti tra ambienti. Tecton è stata utilizzata in produzione da organizzazioni come Atlassian e DoorDash per use case che richiedono feature in tempo reale con latenze inferiori a 100 ms [10].
Un sviluppo significativo è intervenuto nell'agosto 2025, quando Databricks ha acquisito Tecton con l'obiettivo di integrarne la tecnologia di feature serving in tempo reale nella propria piattaforma unificata [7]. L'acquisizione segnala la convergenza tra le piattaforme di data lakehouse e i feature store specializzati, e suggerisce che la gestione delle feature in tempo reale sia destinata a diventare una funzionalità nativa degli ecosistemi di dati, piuttosto che un componente infrastrutturale separato.
Piattaforme cloud-native
Accanto alle piattaforme specializzate, i principali cloud provider hanno integrato funzionalità di feature store nei propri ecosistemi: AWS SageMaker Feature Store, GCP Vertex AI Feature Store e Databricks Feature Store (integrato in Unity Catalog) [11, 13]. Queste soluzioni offrono il vantaggio dell'integrazione nativa con l'ecosistema cloud di riferimento e costi operativi ridotti per organizzazioni già committate su un singolo provider. I benchmark di SIGMOD 2024 [8] hanno tuttavia evidenziato come le prestazioni dell'online store di queste piattaforme siano significativamente inferiori rispetto a soluzioni specializzate, suggerendo che l'integrazione nell'ecosistema cloud avvenga a scapito dell'ottimizzazione per il caso d'uso specifico del feature serving.
Limiti e problemi aperti
Training-serving skew residuo
Nonostante i feature store siano stati progettati esplicitamente per eliminare il training-serving skew, evidenze recenti suggeriscono che il problema non sia completamente risolto. Lo skew può manifestarsi a livelli che il feature store non controlla: differenze nelle versioni delle librerie di preprocessing tra l'ambiente di training e quello di serving, discrepanze nei formati numerici (float32 vs. float64), o comportamenti diversi delle funzioni di aggregazione in presenza di valori nulli. Il feature store garantisce che le stesse definizioni di feature siano utilizzate in entrambi gli ambienti, ma non può garantire che le stesse implementazioni a livello di runtime producano risultati bitwise-identici [1, 2]. Questa distinzione è sottile ma significativa: il feature store risolve lo skew a livello logico ma non necessariamente a livello fisico.
Governance e compliance
La centralizzazione delle feature in un repository condiviso amplifica i requisiti di governance. Feature calcolate a partire da dati personali (PII) devono essere soggette a policy di accesso granulari, audit trail e meccanismi di anonimizzazione o pseudonimizzazione. I feature store attuali offrono livelli di supporto molto eterogenei per queste funzionalità: Hopsworks e Tecton forniscono controlli di accesso role-based e tagging dei metadati, mentre Feast delega interamente la governance all'infrastruttura sottostante [8, 9, 10]. L'integrazione con framework di data governance come Unity Catalog di Databricks [13] rappresenta una direzione promettente ma ancora in fase di consolidamento.
In contesti regolamentati (servizi finanziari, sanità), la capacità di ricostruire esattamente il vettore di feature utilizzato per una specifica predizione, feature reproducibility, è un requisito di compliance, non un'ottimizzazione. Questa capacità richiede il versionamento congiunto delle definizioni delle feature, dei dati grezzi e della logica di trasformazione, un livello di tracciabilità che poche piattaforme supportano in modo completo.
Scalabilità del registry
Man mano che le organizzazioni maturano nelle proprie pratiche di ML, il numero di feature registrate cresce rapidamente: Uber ha documentato decine di migliaia di feature gestite in Michelangelo [3]. A queste scale, la feature discovery diventa un problema di information retrieval: i data scientist devono poter cercare feature rilevanti per semantica, non solo per nome, e valutarne la qualità (completezza, distribuzione, freshness) prima dell'adozione. I feature store attuali offrono funzionalità di ricerca ancora limitate, e l'integrazione di tecniche di ricerca semantica basate su embedding rappresenta un'area di sviluppo attiva.
Integrazione con architetture LLM e RAG
L'emergere dei large language model (LLM) e delle architetture Retrieval-Augmented Generation (RAG) sta ridefinendo i confini funzionali del feature store. In un'architettura RAG, il feature store può fungere da layer di serving per embedding vettoriali precalcolati, combinando la funzionalità tradizionale di feature serving con quella di vector store per la ricerca per similarità [14]. Hopsworks, Feast e Tecton hanno annunciato funzionalità di supporto per embedding vettoriali e ricerca approssimata dei vicini più prossimi (ANN), ma l'integrazione è ancora in fase iniziale.
Il problema concettuale è più profondo: le feature tradizionali per modelli tabulari (valori scalari, aggregazioni, conteggi) hanno semantica e granularità molto diverse dagli embedding vettoriali utilizzati nei sistemi RAG (rappresentazioni dense ad alta dimensionalità di documenti o chunk di testo). La convergenza tra feature store e vector store richiede un ripensamento delle astrazioni di storage, delle API di accesso e dei meccanismi di indicizzazione. Non è chiaro se la soluzione ottimale sia l'estensione dei feature store esistenti o l'emergere di una nuova categoria di infrastruttura dedicata.
Costo e complessità operativa
L'adozione di un feature store introduce complessità operativa non trascurabile: la gestione della materializzazione (scheduling, monitoraggio, recovery da failure), la sincronizzazione tra offline e online store, il monitoraggio della data quality e della feature drift richiedono competenze di platform engineering che non tutte le organizzazioni possiedono. Per team di ML di piccole dimensioni (meno di 5-10 data scientist), il costo di adozione e manutenzione di un feature store dedicato può superare i benefici, specialmente in assenza di requisiti di serving in tempo reale. La regola 4 delle Rules of Machine Learning di Google, "Keep the first model simple and get the infrastructure right" [15], suggerisce che l'investimento in un feature store è giustificato quando la complessità delle feature pipeline e il numero di modelli in produzione raggiungono una soglia critica, non come primo passo.
Implicazioni pratiche
L'adozione di un feature store deve essere guidata da un'analisi dei requisiti specifici dell'organizzazione e del contesto applicativo. È possibile identificare alcuni criteri discriminanti per orientare la decisione.
Il primo criterio è il numero di modelli in produzione e il grado di condivisione delle feature. Se più team o più modelli utilizzano le stesse feature (o feature derivate dagli stessi dati grezzi), il feature store elimina duplicazione e garantisce consistenza. Se l'organizzazione opera con un singolo modello e feature pipeline dedicate, il beneficio marginale è limitato.
Il secondo criterio è il requisito di latenza nel serving. Se l'inferenza avviene in batch (ad esempio scoring notturno), l'online store non è necessario e un data warehouse con point-in-time join può essere sufficiente. Se l'inferenza è in tempo reale con vincoli di latenza stringenti (< 100 ms), l'online store diventa un componente critico e la scelta della piattaforma deve essere guidata dai benchmark di performance.
Il terzo criterio è la maturità dell'organizzazione in termini di data engineering. I feature store non eliminano la necessità di pipeline di dati ben progettate; la spostano a monte, nella definizione delle feature view e nella configurazione della materializzazione. Un'organizzazione con pipeline di dati fragili o non monitorate non risolverà i propri problemi adottando un feature store, li riprodurrà in un contesto più complesso.
Il quarto criterio è l'evoluzione prevedibile verso architetture più complesse. Se la roadmap include l'introduzione di feature in tempo reale, l'adozione di architetture RAG o l'espansione del numero di modelli, l'investimento iniziale in un feature store con capacità di crescita (Hopsworks per prestazioni, Tecton per gestione enterprise, Feast per flessibilità) può evitare costose migrazioni successive.
La scelta tra piattaforme deve inoltre considerare il modello operativo: Feast richiede competenze interne di platform engineering ma offre massima flessibilità; Tecton riduce il carico operativo ma introduce dipendenza da un vendor proprietario; Hopsworks si colloca in posizione intermedia, con un'opzione open-source che richiede gestione infrastrutturale e un servizio managed che la riduce.
Riferimenti
[1] D. Sculley et al., "Hidden Technical Debt in Machine Learning Systems," in Proc. NeurIPS, 2015. https://papers.nips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems
[2] A. Paleyes, R.-G. Urma, N. D. Lawrence, "Challenges in Deploying Machine Learning: A Survey of Case Studies," ACM Computing Surveys, vol. 55, no. 6, 2022. https://dl.acm.org/doi/10.1145/3533378
[3] Uber Engineering, "Meet Michelangelo: Uber's Machine Learning Platform," Uber Engineering Blog, 2017. https://www.uber.com/blog/michelangelo-machine-learning-platform/
[4] Airbnb Engineering, "Zipline: Airbnb's Machine Learning Data Management Platform," Strata Data Conference, 2018. https://conferences.oreilly.com/strata/strata-ny-2018/public/schedule/detail/68114.html
[5] D. Baylor et al., "TFX: A TensorFlow-Based Production-Scale Machine Learning Platform," in Proc. KDD, 2017. https://dl.acm.org/doi/10.1145/3097983.3098021
[6] N. Polyzotis, S. Roy, S. E. Whang, M. Zinkevich, "Data Management Challenges in Production Machine Learning," in Proc. SIGMOD, 2017. https://dl.acm.org/doi/10.1145/3035918.3054782
[7] Databricks Blog, "Tecton is Joining Databricks to Power Real-Time Data for Personalized AI Agents," 2025. https://www.databricks.com/blog/tecton-joining-databricks-power-real-time-data-personalized-ai-agents
[8] J. Dowling, "The Hopsworks Feature Store for Machine Learning," in Proc. SIGMOD (Industrial Track), 2024. https://dl.acm.org/doi/10.1145/3626246.3653389
[9] Feast Project, "Feast: The Open Source Feature Store for Machine Learning," documentazione ufficiale, 2026. https://docs.feast.dev
[10] Tecton, "Tecton Concepts," documentazione ufficiale, 2025. https://docs.tecton.ai/docs/concepts/tecton-concepts
[11] Databricks, "Point-in-Time Feature Joins," documentazione ufficiale, 2026. https://docs.databricks.com/aws/en/machine-learning/feature-store/time-series
[12] Tecton, "Understanding the Feature Freshness Problem in Real-Time ML," Tecton Blog, 2024. https://www.tecton.ai/blog/understanding-the-feature-freshness-problem-in-real-time-ml/
[13] Databricks, "Feature Engineering with Unity Catalog," documentazione ufficiale, 2026. https://docs.databricks.com/aws/en/machine-learning/feature-store/
[14] Hopsworks, "The Definitive Guide to Feature Stores in 2024," 2024. https://www.hopsworks.ai/news/the-definitive-guide-to-feature-stores-in-2024
[15] M. Zinkevich, "Rules of Machine Learning: Best Practices for ML Engineering," Google, 2017. https://developers.google.com/machine-learning/guides/rules-of-ml