In che modo Databricks Feature Store distribuisce le feature con una freschezza inferiore al secondo

I modelli di machine learning sono efficaci solo quanto i segnali che ricevono. Un caso d'uso di rilevamento delle frodi deve decidere in pochi millisecondi dal momento in cui un utente preme "acquista" se autorizzare la transazione. Fare la scelta giusta dipende dal vedere una transazione sospetta avvenuta solo pochi secondi prima. Combinare la media delle transazioni di un utente negli ultimi 30 giorni con l'importo totale delle transazioni degli ultimi 10 minuti evidenzia la potenziale frode. Le aggregazioni a lungo termine definiscono un profilo di base dell'utente per determinare cosa sia normale, mentre i dati più recenti aiutano a far emergere qualsiasi comportamento anomalo proprio mentre si verifica. La personalizzazione affronta la stessa pressione: i segnali più freschi sono quelli che catturano l'intento attuale dell'utente e ne stimolano il coinvolgimento.

Le pipeline Spark sono un modo consolidato per elaborare dati in blocco nel Lakehouse per le feature di base storiche. L'esecuzione di questi job batch a intervalli regolari è ben consolidata, ma introduce un ritardo da minuti a ore. Per i segnali di base sugli utenti, questo ritardo è un prezzo accettabile per un'infrastruttura più semplice. Quando i modelli richiedono segnali freschi, questa infrastruttura non è più sufficiente; scendere a secondi o millisecondi non è possibile nelle attuali piattaforme di feature store. Per offrire il valore delle feature fresche, i data scientist sono costretti a implementare logiche complesse e specifiche per lo streaming per gestire queste aggregazioni e configurare infrastrutture ospitate personalizzate.

Databricks Feature Store ti consente di creare una feature una sola volta e utilizzarla ovunque: la stessa definizione gestisce flussi batch su larga scala offline e pipeline di feature estremamente fresche online. Il framework elimina il carico infrastrutturale, orchestrando Spark Real-Time Mode (RTM) per l'elaborazione continua dei flussi, Lakebase per l'archiviazione online ottimizzata per lo streaming e Model Serving per il recupero su scala. E una volta creata, quella feature viene servita in millisecondi: latenza p99 end-to-end di 200 ms, dall'arrivo di un evento in Kafka alla disponibilità nel feature store online.

Architettura: da Kafka a Feature Store in 200 ms

Diamo un'occhiata dietro le quinte per vedere come Databricks Feature Store prende una definizione di Feature indipendente dall'infrastruttura e crea una pipeline per calcolarla in modo coerente in pochi millisecondi. Il percorso end-to-end per una feature in streaming si presenta così:

1. Gli eventi arrivano su Kafka: dati grezzi come transazioni con carta di credito, impression pubblicitarie o eventi clickstream
2. Una pipeline Spark RTM su Lakeflow Spark Delta Pipelines serverless elabora continuamente gli eventi, calcolando aggregazioni rolling in tempo reale
3. Gli aggregati aggiornati vengono scritti su Lakebase tramite un nuovo sink JDBC di streaming, arrivando nel feature store online
4. Gli endpoint di Model Serving recuperano le feature più recenti da Lakebase al momento dell'inferenza, inserendole automaticamente nel modello

Colleghiamo questo alla nostra feature di frode, ovvero la somma dell'importo delle transazioni di un utente negli ultimi 10 minuti. Ogni evento in entrata porta con sei i dettagli della transazione (importo, posizione, ID utente, informazioni sul commerciante) e viene indirizzato a una pipeline stateful. La pipeline consulta un'istanza locale di RocksDB che contiene il totale parziale delle transazioni dell'utente, con tempi di scadenza che mantengono la finestra temporale agli ultimi 10 minuti. La pipeline legge e incrementa il valore localmente, quindi scrive il valore della feature aggiornato su Lakebase. In questo modo, quando arriva una query al modello per approvare una nuova transazione, nel feature store è disponibile una somma delle transazioni aggiornata con una freschezza inferiore al secondo. Questa feature di somma verrà recuperata insieme al profilo di base storico degli acquisti dell'utente per informare l'approvazione. Una somma ampiamente superiore al profilo di base storico è un forte indicatore per il modello di una potenziale frode.

Ogni componente di questa pipeline è stato ottimizzato in modo che gli eventi in entrata vengano instradati, le aggregazioni vengano calcolate e le feature vengano scritte nello store online il più rapidamente possibile.

Finestra rolling: aggiorna le aggregazioni in millisecondi

Prima di approfondire l'infrastruttura, parliamo delle feature di aggregazione e del passaggio da un paradigma di sincronizzazione batch ad aggiornamenti in tempo reale.

Le feature di aggregazione su una finestra temporale (ad esempio conteggi, somme o medie) sono segnali potenti e flessibili per il ML in tempo reale. Una feature batch a lungo termine definisce un profilo di base storico per l'utente su un periodo di tempo, consentendo al modello di adattarsi e comprendere il comportamento di ciascun utente. Una feature breve e fresca reagisce rapidamente alle situazioni mutevoli per distinguere un nuovo interesse dell'utente o un'attività fraudolenta. Le finestre temporali definiscono un intervallo di tempo (ad es. 10 minuti) e il modo in cui tali intervalli dovrebbero evolversi nel tempo (ad es. sovrapposti o disgiunti).

Databricks Feature Store supporta 3 diverse finestre temporali:

• Le finestre tumbling sono allineate agli intervalli dell'orologio di sistema e iniziano non appena termina l'ultimo intervallo. Una finestra tumbling di 10 minuti potrebbe coprire l'intervallo 12:00–12:10, poi 12:10–12:20. Gli eventi vengono raggruppati in questi intervalli fissi e il valore della feature viene emesso alla fine di un intervallo. Ciò significa che l'aggregato è fresco solo ai limiti dell'intervallo
• Le finestre sliding sono anch'esse allineate agli intervalli dell'orologio di sistema, ma consentono la sovrapposizione degli intervalli. Una finestra sliding di 10 minuti con un intervallo di scorrimento di 5 minuti potrebbe coprire l'intervallo 12:00–12:10, poi 12:05–12:15 e infine 12:10-12:20.
• Le finestre rolling non sono allineate all'orologio di sistema, ma guardano indietro rispetto al timestamp di ciascun evento con una risoluzione al millisecondo. "La somma delle transazioni negli ultimi 10 minuti rispetto all'orologio di sistema corrente" è sempre aggiornata, perché la finestra si sposta con ogni nuovo evento. Questo rende RollingWindow la soluzione ideale per il serving in tempo reale, dove il "presente" è in costante mutamento.

Le finestre tumbling e sliding rimangono utili quando una feature non cambia frequentemente: emettono meno aggiornamenti, sono più economiche da mantenere e si integrano naturalmente in pipeline pianificate più semplici. Le finestre rolling scambiano tale efficienza con la massima freschezza, il che è estremamente prezioso per i segnali in cui ogni nuovo evento dovrebbe influenzare immediatamente il valore servito al modello.

Ecco com'è semplice definire una feature con finestra rolling utilizzando l'API dichiarativa di Feature Store:

Spark Real-Time Mode: il motore per il calcolo delle feature

Passando all'infrastruttura sottostante, la pipeline di streaming è ciò che rende possibili feature fresche ad alto throughput. Questa pipeline porta i dati da Kafka fino al feature store online. La pipeline di streaming è alimentata da Spark Real-Time Mode (RTM), una modalità di esecuzione fondamentalmente nuova per Spark Structured Streaming. RTM rappresenta l'innovazione architetturale chiave che rende possibile una freschezza al millisecondo.

Fasi concorrenti ed elaborazione stateful

Nella modalità microbatch tradizionale (MBM), Spark elabora i dati in streaming in batch discreti. Ciascun batch raccoglie gli eventi in un intervallo configurabile, li elabora in sequenza attraverso ogni fase, esegue il checkpoint e quindi avvia il batch successivo. Ciò crea un limite minimo alla latenza: anche con un tuning aggressivo, le pipeline MBM per le aggregazioni stateful operano in genere nell'ordine di secondi o minuti. RTM, d'altra parte, esegue le fasi in modo concorrente. Gli operatori di aggregazione elaborano tempestivamente le righe non appena sono disponibili, senza attendere che la fase a monte termini l'elaborazione di tutte le righe.

Per le aggregazioni rolling ci sono due fasi importanti. La prima fase è l'elaborazione dei dati, la validazione dello schema, il coalescing dei dati e il type casting. Questa esegue la logica di business che converte gli eventi di azione generici nella forma adatta all'aggregazione delle feature. La seconda fase consiste nell'aggregare i dati per entità per calcolare le aggregazioni della finestra rolling. Ogni riga in entrata aggiorna immediatamente l'aggregato in uno store di stato RocksDB locale ed emette il nuovo valore a valle. Anche la scadenza della finestra avviene riga per riga: quando la durata della finestra scade per un determinato evento, la pipeline rimuove il contributo di quell'evento ed emette l'aggregato corretto su Lakebase. RocksDB viene eseguito localmente su ciascun executor, consentendo dimensioni dello stato che superano la capacità di memoria del cluster.

Gestione dello stato della pipeline in RTM serverless

Il checkpointing è essenziale per la tolleranza ai guasti nello streaming stateful, in quanto consente alla pipeline di riprendersi dal guasto di un singolo worker della pipeline. Ma il checkpointing ha un costo. Nella modalità microbatch, Spark esegue il checkpoint a ogni limite di batch e ogni checkpoint aggiunge latenza alla pipeline poiché interagisce con gli store di oggetti cloud.

RTM adotta un approccio diverso: il costo della pianificazione e del checkpointing viene ammortizzato su intervalli più lunghi. Il costo del checkpointing è distribuito su tutte le righe elaborate in quell'intervallo, anziché bloccare la pipeline a ogni limite di batch. Questo non compromette la tolleranza ai guasti. Le garanzie di elaborazione exactly-once vengono mantenute: in caso di guasto, la pipeline riproduce al massimo 5 minuti di dati dalla sorgente Kafka. Il compromesso è un modesto aumento del volume di riproduzione a fronte di una significativa riduzione della latenza di elaborazione a regime.

Feature Store esegue pipeline RTM serverless su Lakeflow Spark Delta Pipelines (SDP), eliminando completamente la gestione dei cluster e la pianificazione della capacità. Non è necessario configurare macchine, ottimizzare il numero di executor o preoccuparsi della manutenzione dei cluster. Quando gli aggiornamenti dell'infrastruttura richiedono il riavvio di una pipeline, SDP coordina il passaggio di consegne: il nuovo cluster serverless viene configurato ed è completamente pronto prima che quello vecchio si arresti. Questo coordinamento è sincronizzato con gli intervalli di checkpointing di 5 minuti, riducendo al minimo i tempi di inattività ed evitando lacune di rielaborazione. Ciò si traduce in un'interruzione quasi nulla della freschezza delle feature durante le finestre di manutenzione.

Lakebase: ridurre al minimo l'overhead per le scritture in streaming

Databricks Feature Store utilizza Lakebase per memorizzare i valori delle feature online per l'inferenza. L'architettura di Lakebase, che separa computazione e archiviazione, consente la scalabilità automatica per gestire carichi variabili per l'inferenza dei modelli. L'Online Feature Store sfrutta questa capacità per scalare fino a decine di migliaia di letture al secondo con latenze nell'ordine delle decine di millisecondi.

Le scritture in streaming sono particolarmente complesse poiché consistono in un gran numero di piccoli upsert, man mano che i nuovi valori della finestra temporale scorrevole (rolling window) vengono emessi per ogni riga Kafka ricevuta. In Postgres standard, questo pattern può generare un grande volume di write-ahead log perché Postgres utilizza scritture a pagina intera per facilitare il ripristino. Dopo ogni checkpoint, la prima modifica a una pagina scrive l'immagine intera della pagina da 8 KB nel write-ahead-log (WAL), non solo la piccola modifica logica. Per le righe di entità calde (hot) aggiornate di frequente, ciò rende l'amplificazione del WAL il collo di bottiglia per il throughput di scrittura, la replica e l'overhead di ripristino.

Lakebase ora sfrutta la separazione tra computazione e archiviazione distribuita per ridurre al minimo l'amplificazione delle scritture in streaming rispetto a Postgres standard. L'architettura di Lakebase consente a Postgres di scrivere record di modifica piccoli e compatti invece di scrivere ripetutamente snapshot di pagine intere da 8 KB nel WAL. La durabilità è comunque garantita perché questi record compatti vengono confermati da un quorum di nodi safekeeper distribuiti. Gli snapshot di pagine intere sono ancora necessari per il ripristino dopo un numero sufficiente di record di modifica, ma vengono generati successivamente nel livello di archiviazione anziché appesantire il percorso di scrittura. Per Feature Store, il risultato è che RTM può pubblicare continuamente nuovi valori di feature in Lakebase con un'amplificazione del WAL decisamente inferiore e una latenza aggiuntiva minima.

Model Serving: recupero delle feature a bassa latenza su larga scala

L'ultima tappa del percorso consiste nel recuperare le feature fresche da Lakebase e fornirle al modello al momento dell'inferenza. Questo compito è gestito da Databricks Model Serving, un'infrastruttura di serving completamente gestita e ottimizzata per carichi di lavoro a basso livello di latenza e con un elevato numero di QPS.

Model Serving è progettato per soddisfare le esigenze di throughput del ML in tempo reale:

• Architettura completamente scalabile orizzontalmente: il server di inferenza, il livello di autenticazione, il proxy e il limitatore di frequenza (rate limiter) scalano tutti in modo indipendente, supportando oltre 100.000 QPS su endpoint CPU
• Scalabilità elastica rapida: il sistema si adatta ai picchi e ai cali di traffico senza sovradimensionare le risorse (over-provisioning), mantenendo i costi allineati alla domanda effettiva
• Governance e monitoraggio dei modelli: gestisci l'accesso alla rete, i permessi per gli endpoint dei modelli e monitora la qualità utilizzando AI Gateway.

Per Feature Store, l'integrazione è immediata. Quando un modello viene registrato con MLflow, vengono registrate le sue dipendenze dalle feature. Al momento dell'inferenza, Model Serving cerca automaticamente le feature richieste da Lakebase: nessun codice di ricerca personalizzato, nessun collegamento manuale. L'aggregato fresco calcolato da RTM e memorizzato in Lakebase viene recuperato e unito alla richiesta di inferenza in modo trasparente.

Feature Store oltre lo streaming

Le funzionalità in tempo reale ad alte prestazioni sono solo una parte di ciò che un Feature Store può risolvere. Vale la pena considerare brevemente altre due sfide:

Dati di addestramento per le feature in streaming

La generazione dei dati di addestramento può essere complessa per le feature in streaming, poiché le brevi finestre di conservazione (retention) sui flussi richiedono il mantenimento di un archivio offline separato. Databricks Feature Store risolve questo problema memorizzando una copia offline dei dati Kafka inseriti. Per l'addestramento del modello, Feature Store calcola gli stessi valori di feature che calcolerebbero le pipeline in streaming per i valori storici ed esegue join accurati nel tempo (point-in-time). Questa stessa funzionalità viene utilizzata per il backfill delle feature in streaming online per consentire un rapido rilascio in produzione.

Integrazioni

Come mostrato sopra, i Feature Store orchestrano diversi componenti infrastrutturali complessi. Tale frammentazione può rendere difficili la governance, la lineage e il riutilizzo delle feature. Inoltre, rallenta lo sviluppo, poiché gli ingegneri devono coordinare le modifiche tra i vari sistemi.

In Databricks, le feature sono oggetti di prim'ordine in Unity Catalog: individuabili, regolate da controlli di accesso e tracciate con una lineage completa. Le trasformazioni delle feature sono incluse nel pacchetto del modello, MLflow acquisisce quali feature sono state utilizzate e la lineage di distribuzione collega i modelli alle loro dipendenze dalle feature. La piattaforma è una soluzione unica per sviluppare, distribuire e gestire l'intero stack ML.

Il Feature Store di Databricks orchestra componenti fondamentali come Spark RTM, Lakebase e Model Serving, consentendoti di ottenere latenza e scalabilità leader del settore senza dover gestire direttamente l'infrastruttura. Ciascuno di questi sistemi è stato ottimizzato fin nei minimi dettagli per i carichi di lavoro in streaming, per rendere reale una freschezza di 200 ms per le feature di machine learning.

Consulta la documentazione sulle pipeline di streaming per scoprire come definire le feature in streaming. Sperimenta con le feature esistenti per vedere quanto segnale in più potrebbero fornire con una freschezza nell'ordine dei millisecondi.

Se desideri comprendere meglio la tecnologia alla base, consulta il blog di Lakebase sulle scritture più veloci e l'analisi dell'architettura RTM.

Se questo è il genere di problemi su cui desideri lavorare, stiamo assumendo!

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