Materializzare le visualizzazioni delle funzionalità

Dopo aver creato le definizioni di Visualizzazione funzionalità, archiviate nel catalogo Unity, è possibile produrre dati delle funzionalità dalla tabella di origine usando le definizioni delle funzionalità. Questo processo è detto materializzazione delle funzionalità. Azure Databricks crea e gestisce le pipeline di Lakeflow per popolare le tabelle di Unity Catalog per l'addestramento dei modelli e l'assegnazione di punteggi in batch o il serving online.

Per informazioni sulla gestione delle visualizzazioni delle funzionalità, vedere Gestire le visualizzazioni delle funzionalità.

Per rimuovere i valori materializzati per entità selezionate, vedi Eliminare i valori delle feature per le entità.

Requisiti

• Le funzionalità devono essere create come visualizzazioni delle funzionalità e archiviate nel catalogo unity.
• Per i requisiti di versione, vedere Requisiti.

Supporto alla materializzazione per tipo di caratteristica

Se e dove una caratteristica può essere materializzata dipende dal suo tipo:

• ColumnSelection le caratteristiche possono essere materializzate nei negozi online. Consulta Materializzazione ColumnSelection.
• Le funzionalità batch Last con un RollingWindow possono essere integrate nei negozi online. Vedi Materialize valori più recenti con limiti di freschezza.
• Le funzionalità di RequestSource, FeatureViewSource e CustomUDF non possono essere create. Vedi Funzionalità su richiesta e materializzazione.

Le funzionalità che si materializzano solo nei negozi online sono comunque utilizzabili offline: create_training_set e compute_features calcolano i loro valori puntuali direttamente dalla fonte, quindi non è necessaria alcuna materializzazione offline.

Materializzazione di selezione colonne

ColumnSelection le funzionalità selezionano il valore più recente di una singola colonna per ogni chiave di entità senza aggregazione. Possono essere materializzati solo nei negozi online. Per i casi d'uso offline (inferenza di training e batch), ColumnSelection le funzionalità vengono recuperate direttamente dai dati di origine in fase di query, quindi la materializzazione offline non è necessaria.

Comportamento di materializzazione

• La pipeline scrive la riga più recente per ogni chiave di entità nella tabella online, senza finestra di aggregazione.
• La materializzazione online popola la tabella online con il valore più recente per ogni chiave di entità.

Esempio

from databricks.feature_engineering import FeatureEngineeringClient
from databricks.feature_engineering.entities import (
    DeltaTableSource, Feature, ColumnSelection, TableTrigger, OnlineStoreConfig,
)

fe = FeatureEngineeringClient()

delta_source = DeltaTableSource(
    catalog_name="catalog",
    schema_name="schema",
    table_name="transactions",
)

amount_feature = Feature(
    source=delta_source,
    function=ColumnSelection("amount"),
    entity=["user_id"],
    timeseries_column="transaction_time",
    name="latest_transaction_amount",
)

# Register before materializing
amount_feature = fe.register_feature(
    feature=amount_feature,
    catalog_name="catalog",
    schema_name="schema",
)

mfs = fe.materialize_features(
    features=[amount_feature],
    online_config=OnlineStoreConfig(
        catalog_name="catalog",
        schema_name="feats_online",
        table_name_prefix="txn_",
        online_store_name="lb_usw2"
    ),
    trigger=TableTrigger(),
)

ColumnSelection le funzionalità usano TableTrigger, che esegue la pipeline ogni volta che la tabella Delta di origine riceve un nuovo commit. Non è necessario offline_config perché le funzionalità di ColumnSelection vengono lette direttamente dall'origine per i casi d'uso offline (training e inferenza batch).

Materializza i valori più recenti con limiti di freschezza

Un'aggregazione batch Last con un RollingWindow conferisce a una funzione online un time-to-live (TTL): il suo valore scade dal negozio online quando nessun valore sorgente rientra nella finestra di riferimento. Questo è utile quando l'età di un valore determina se è sicuro da servire. Ad esempio, uno stato del dispositivo dell'ultima ora può essere servito, mentre uno stato più vecchio si risolve in nullo invece di rimanere disponibile indefinitamente.

A RollingWindow definisce una durata esplicita che conferisce alla funzionalità un comportamento di tipo TTL. Ad esempio, se la fonte pubblica i valori quotidianamente e vuoi mantenere solo i valori degli ultimi sette giorni, usa un RollingWindow con una durata di sette giorni. A ogni trigger, la materializzazione sostituisce completamente la tabella online, quindi i valori che escono dalla finestra vengono rimossi in base a una pianificazione prevedibile. Questo produce lo stesso risultato di uno streaming Last con , RollingWindowma costa meno perché non esegue calcolo continuamente.

Questo pattern di pubblicazione è simile a una feature table con un TTL pubblicato in modalità snapshot. Se gestisci un set di feature table e vuoi usarle insieme ad altre Feature View, puoi adattarle al framework di authoring delle Feature Views. Usa un batch Last con un RollingWindow e un TableTrigger.

Questa combinazione prevede una modalità speciale di materializzazione solo online con i seguenti requisiti:

• La sorgente deve essere un DeltaTableSource.
• La funzione aggregazione deve essere Last, e la sua finestra deve essere un RollingWindow.
• La materializzazione deve fornire un OnlineStoreConfig, omettere OfflineStoreConfig e utilizzare TableTrigger.

Nel seguente esempio, latest_device_state_1h è una Funzionalità registrata che soddisfa questi requisiti:

from databricks.feature_engineering import FeatureEngineeringClient
from databricks.feature_engineering.entities import OnlineStoreConfig, TableTrigger

fe = FeatureEngineeringClient()

materialized = fe.materialize_features(
    features=[latest_device_state_1h],
    online_config=OnlineStoreConfig(
        catalog_name="main",
        schema_name="feature_store",
        table_name_prefix="latest_device_state_serving",
        online_store_name="device_state_store",
    ),
    trigger=TableTrigger(),
)

Per l'addestramento offline e il batch scoring, il client di feature engineering calcola direttamente dalla sorgente il valore relativo a uno specifico momento temporale. Non legge una materializzazione offline per questa funzionalità.

Considerazioni

• La scadenza progredisce solo al verificarsi di un trigger. Il valore in linea e la relativa scadenza vengono aggiornati quando il commit di una tabella di origine attiva un aggiornamento della materializzazione. Il solo passare del tempo non fa scattare un refresh. Se il codice sorgente smette di pubblicare, l'ultimo valore materializzato rimane nello store online fino a quando un commit successivo non attiva un refresh.
• Allinea la colonna della serie temporale con l'orario di pubblicazione della fonte. La colonna della serie temporale deve riflettere quando la fonte ha pubblicato i dati. Altrimenti, i valori online e offline divergono, perché il negozio online si unisce al momento di attivazione mentre le letture offline si uniscono all'ora della serie temporale.
• Imposta la durata della finestra a un multiplo della cadenza di pubblicazione. Se la RollingWindow durata non è un multiplo della cadenza di pubblicazione del sorgente, alcuni valori vengono trattati come scaduti durante l'addestramento offline mentre sono ancora visibili online.

Funzionalità su richiesta e materializzazione

RequestSource i valori provengono dal DataFrame di addestramento o dalla richiesta di inferenza, quindi non c'è una tabella sorgente che si materializzi. FeatureViewSource Le caratteristiche si applicano A CustomUDF ai valori delle caratteristiche a monte durante l'addestramento o il servizio. Non memorizzano un risultato precalcolato. La materializzazione non è inoltre supportata per le funzionalità CustomUDF basate su una tabella Delta.

Per un grafo di dipendenza come revenue_sum_7d e cost_sum_7d che alimenta una margin caratteristica:

• Per l'addestramento offline, chiama create_training_set con margin. Risolve le caratteristiche a monte e calcola i valori puntuali nel tempo, utilizzando materializzazioni offline compatibili quando disponibili.
• Per il servizio online, inserisci le funzionalità di fatturato e di costo supportate in un negozio online. L'endpoint li cerca e calcola margin per ogni richiesta.
• Passare solo le funzionalità upstream supportate a materialize_features, non a margin né a qualsiasi funzionalità basata sulle richieste. La materializzazione non materializza ricorsivamente le dipendenze di una caratteristica derivata.

Un grafo che utilizza solo funzionalità supportate da richieste non ha bisogno di un negozio online. Vedi Allenare con funzionalità FeatureViewSource e funzionalità derivate da Serve.

Permissions

La materializzazione richiede privilegi sulla caratteristica e sulle risorse di origine e destinazione. Per descrizioni complete dei privilegi del Catalogo Unity, vedi riferimento ai privilegi del Catalogo Unity.

• La materializzazione di una funzionalità richiede MANAGE. Chiamare materialize_features crea e gestisce le pipeline Lakeflow di supporto e le tabelle del catalogo Unity, quindi è un'operazione di gestione. È necessario disporre di MANAGE per la funzionalità, insieme a READ FEATURE, per leggere la definizione della funzionalità in fase di materializzazione.

• L'eliminazione di una funzione materializzata è riservata al suo creatore. Solo l'utente che ha creato una funzione materializzata può eliminarla con delete_materialized_feature. Questa restrizione è indipendente dai privilegi del Catalogo Unity: MANAGE sulla funzionalità o sul suo schema genitore non permette a un altro utente di eliminarla.

• La lettura dei dati sorgente richiede SELECT. Per una funzionalità che usa una tabella Delta come origine, devi disporre di SELECT nella tabella di origine. Per una funzionalità che usa una sorgente Stream, è necessario disporre di SELECT nella tabella di inserimento di Stream.

  Per altri permessi richiesti dalla configurazione di autenticazione di uno Stream, vedi autenticazione di Kafka.

• Creare tabelle di destinazione richiede CREATE TABLE. Devi avere CREATE TABLE su ogni schema specificato da OfflineStoreConfig o OnlineStoreConfig. Le destinazioni offline e online possono essere in schemi o cataloghi diversi, e la materializzazione richiede privilegi su ciascuna destinazione.

• La pubblicazione in un negozio online richiede CAN USE. Devi disporre di CAN USE sull'istanza o sul progetto Lakebase utilizzati dal negozio online. Per informazioni sui permessi di Lakebase, vedi Concedere permessi ai progetti.

• Elencare le funzionalità materializzate richiede READ FEATURE nella funzionalità padre. Per usare list_materialized_features, devi avere READ FEATURE sulla funzione che è stata materializzata.

• La lettura dei dati materializzati richiede SELECT. Devi avere SELECT su ogni tabella di output offline o online a cui accedi. READ FEATURE la funzione genitore non concede l'accesso a queste tabelle.

Per ciascuna risorsa di Unity Catalog coinvolta nella materializzazione, sono necessari anche USE CATALOG nel catalogo padre e USE SCHEMA nello schema padre. Questo requisito si applica alla caratteristica, a ogni tabella di ingestione sorgente o Stream, e a ogni destinazione configurata. READ FEATURE e MANAGE concessi per uno schema o un catalogo si applicano a tutte le funzionalità correnti e future contenute.

Strutture di dati API

OfflineStoreConfig

Configurazione per l'archivio offline in cui verranno scritte le funzionalità materializzate. Quando materialize_features viene chiamato, il back-end dell'archivio delle funzionalità crea delle tabelle usando questo prefisso. Ogni esecuzione della pipeline materializza i valori delle caratteristiche più recenti nella tabella in base al programma di materializzazione.

OfflineStoreConfig(
    catalog_name: str,        # Catalog name for the offline table where materialized features will be stored
    schema_name: str,         # Schema name for the offline table
    table_name_prefix: str    # Table name prefix for the offline table. The pipeline may create multiple tables with this prefix, each updated at different cadences
)

from databricks.feature_engineering.entities import OfflineStoreConfig

offline_store = OfflineStoreConfig(
    catalog_name="main",
    schema_name="feature_store",
    table_name_prefix="customer_features"
)

OnlineStoreConfig

Configurazione per il negozio online, che conserva le funzionalità usate dal serving del modello. La materializzazione crea tabelle Delta con il catalog.schema.table_name_prefix e trasmette le tabelle all'Online Feature Store con lo stesso nome.

from databricks.feature_engineering.entities import OnlineStoreConfig

online_store = OnlineStoreConfig(
    catalog_name="main",
    schema_name="feature_store",
    table_name_prefix="customer_features_serving",
    online_store_name="customer_features_store"
)

MaterializedFeature

Rappresenta una Feature View materializzata, vale a dire con una rappresentazione precalcolata disponibile in Unity Catalog. Sono disponibili funzionalità materializzate separate per la tabella offline e la tabella online. In genere, gli utenti non creeranno direttamente un'istanza di MaterializedFeature.

Chiamate di funzioni API

materialize_features()

Materializza un elenco di Feature View in una tabella Delta offline oppure in un Feature Store online. Le funzionalità devono essere registrate in Unity Catalog prima di chiamare questa funzione (ad esempio, usando create_feature o register_feature). Le funzionalità costruite localmente che non sono state registrate non funzioneranno.

FeatureEngineeringClient.materialize_features(
    *,                                                                     # Arguments are keyword-only
    features: List[Feature],                                               # List of Feature Views to materialize
    offline_config: Optional[OfflineStoreConfig] = None,                   # Offline store config (aggregation features only)
    online_config: Optional[OnlineStoreConfig] = None,                     # Online store config
    trigger: Union[CronSchedule, TableTrigger, StreamingMode],             # Materialization trigger
    tags: Optional[Dict[str, str]] = None,                                 # Custom tags for cost attribution
    budget_policy_id: Optional[str] = None,                                # Serverless usage policy for cost attribution
) -> List[MaterializedFeature]:

Il metodo restituisce un elenco di funzionalità materializzate, che contengono metadati relativi all'aggiornamento dei valori delle funzionalità e alle tabelle del catalogo Unity in cui vengono materializzate le funzionalità.

Se vengono forniti sia un OnlineStoreConfig sia un OfflineStoreConfig, vengono restituite due caratteristiche materializzate per ogni caratteristica fornita, una per ciascun tipo di negozio.

Il parametro trigger controlla il momento in cui viene eseguita la pipeline di materializzazione.

• CronSchedule: Viene eseguito in base a una pianificazione derivata dalla temporizzazione della funzionalità o a una pianificazione cron di Quartz specificata dal chiamante. Supportato per le funzionalità di aggregazione batch (AggregationFunction da DeltaTableSource).
• TableTrigger: viene eseguito quando la tabella Delta upstream riceve un commit. Supporta le funzionalità ColumnSelection e le funzionalità di aggregazione (AggregationFunction) basate su un DeltaTableSource. Per le funzioni di aggregazione, la pipeline viene limitata in modo da essere eseguita al massimo una volta ogni metà della granularità della funzione (la durata dello scorrimento per una finestra scorrevole, oppure la lunghezza della finestra per una finestra tumbling), con un limite massimo di 1 ora e comunque non più di una volta ogni 5 minuti. Ad esempio, al massimo una volta ogni 30 minuti per una granularità di 1 ora, o al massimo una volta all'ora per una granularità di 2 ore o più. L'intervallo viene calcolato a partire dall'esecuzione precedente, quindi un commit che arriva dopo che è trascorso attiva comunque prontamente un'esecuzione.
• StreamingMode: funziona come pipeline di streaming continua. Obbligatorio per le funzionalità supportate da un oggetto StreamSource.

Non è possibile combinare funzionalità che richiedono tipi di trigger diversi in una singola materialize_features chiamata. In alternativa, eseguire chiamate separate.

Per attribuire il costo di una materializzazione, specifica tags, budget_policy_id oppure entrambi. Azure Databricks li applica al job o alla pipeline che crea, quindi la relativa spesa riporta la tua attribuzione nella tabella di sistema dell'utilizzo fatturabile. Entrambi vengono applicati alla creazione, quindi attribuire una materializzazione esistente in modo diverso significa crearne una nuova. budget_policy_id prende l'ID di una politica di utilizzo serverless. Per crearne uno e ottenere il suo ID, vedi Crea una politica di utilizzo serverless. Per i limiti dei tag, le risorse che ciascun valore raggiunge e come interrogare la spesa attribuita, vedi Feature Store gestione dei costi.

Materializzare l'archivio offline

from databricks.feature_engineering import FeatureEngineeringClient
from databricks.feature_engineering.entities import (
    CronSchedule, OfflineStoreConfig,
)

fe = FeatureEngineeringClient()

materialized = fe.materialize_features(
    features=features,
    offline_config=OfflineStoreConfig(
        catalog_name="main",
        schema_name="feature_store",
        table_name_prefix="customer_features"
    ),
    trigger=CronSchedule(
        quartz_cron_expression="0 0 * * * ?",  # Hourly
        timezone_id="UTC",
    ),
)

Concretizzare nel negozio online

from databricks.feature_engineering import FeatureEngineeringClient
from databricks.feature_engineering.entities import (
    CronSchedule, OfflineStoreConfig, OnlineStoreConfig,
)

fe = FeatureEngineeringClient()

materialized = fe.materialize_features(
    features=features,
    offline_config=OfflineStoreConfig(
        catalog_name="main",
        schema_name="feature_store",
        table_name_prefix="customer_features"
    ),
    online_config=OnlineStoreConfig(
        catalog_name="main",
        schema_name="feature_store",
        table_name_prefix="customer_features_serving",
        online_store_name="customer_features_store"
    ),
    trigger=CronSchedule(
        quartz_cron_expression="0 0 * * * ?",  # Hourly
        timezone_id="UTC",
    ),
)

Materializzare le funzionalità di streaming

Le funzionalità di streaming possono essere materializzate solo nei negozi online; il offline_config parametro non è supportato. La materializzazione offline non è supportata perché le funzionalità di streaming richiedono una pipeline in tempo reale per garantire una freschezza inferiore al secondo. Per il training o la valutazione offline, il client di progettazione delle funzionalità ricompila i valori delle funzionalità in base a ogni punto dati valutato.

Le funzionalità di streaming non possono essere combinate con le funzionalità batch nella stessa materialize_features chiamata.

from databricks.feature_engineering import FeatureEngineeringClient
from databricks.feature_engineering.entities import (
    OnlineStoreConfig, StreamingMode,
)

fe = FeatureEngineeringClient()

materialized = fe.materialize_features(
    features=[streaming_feature],
    online_config=OnlineStoreConfig(
        catalog_name="my_catalog",
        schema_name="my_schema",
        table_name_prefix="streaming_features_serving",
        online_store_name="feature_store_online"
    ),
    trigger=StreamingMode(),
)

list_materialized_features()

Restituisce le materializzazioni di una singola caratteristica, identificata dal nome completo. feature_name è obbligatorio e solo parola chiave. Per esaminare le materializzazioni in molte funzionalità, elencare prima le funzionalità in un catalogo o uno schema, quindi chiamare list_materialized_features su ogni funzionalità restituita.

Per impostazione predefinita, viene restituito un massimo di 100 materializzazioni. È possibile modificare questo limite usando il max_results parametro .

FeatureEngineeringClient.list_materialized_features(
    *,                                      # Arguments are keyword-only
    feature_name: str,                      # Required: full name of the feature whose materializations to list
    max_results: int = 100,                 # Maximum number of materializations to return
) -> List[MaterializedFeature]:

delete_materialized_feature()

Prima di eliminare una funzionalità materializzata, rimuovere o aggiornare i modelli o le specifiche di funzionalità che fanno riferimento alla funzionalità.

Elimina una funzionalità materializzata. La funzionalità da passare dipende dal tipo di funzionalità:

• Funzionalità di aggregazione: passare la funzionalità materializzata offline. Se è presente una funzionalità materializzata online per la stessa funzionalità, entrambe vengono eliminate. Per una funzione batch Last solo online con un RollingWindow, supera la funzione materializzata online.
• ColumnSelection funzionalità: passare la funzionalità materializzata online. ColumnSelection le caratteristiche vengono materializzate solo per il negozio online (vedere materializzazione ColumnSelection), quindi non esiste alcuna corrispondente funzionalità offline.

Nell'ambito della materializzazione, le funzionalità vengono raggruppate in base all'origine dati e alla finestra di aggregazione per garantire l'efficienza. ColumnSelection le funzionalità non hanno finestra di aggregazione, quindi vengono raggruppate solo per origine dati. La pipeline di materializzazione, la tabella offline e la tabella online non vengono eliminate fino a quando non vengono eliminate tutte le funzionalità raggruppate. Quando viene eliminata l'ultima funzionalità materializzata in un gruppo, l'archivio funzionalità pianifica le risorse associate per la pulizia automatica tramite un processo in background. Vedi Pulizia delle risorse in background.

Per pulire le funzionalità materializzate, esaminare la tabella associata a una funzionalità materializzata. Ogni funzionalità della tabella (una per colonna) deve essere eliminata prima di pulire le risorse di tabella Delta e di calcolo.

Usare list_materialized_features() per ottenere l'argomento materialized_feature .

FeatureEngineeringClient.delete_materialized_feature(
    materialized_feature: MaterializedFeature,  # Required: The materialized feature to delete
) -> None

from databricks.feature_engineering import FeatureEngineeringClient

fe = FeatureEngineeringClient()

feature_names = [
    "main.feature_store.amount_sum_sliding_7d_1d",
    "main.feature_store.amount_sum_sliding_30d_1d",
    "main.feature_store.transaction_count_sliding_7d_1d",
    "main.feature_store.latest_transaction_amount",
    "main.feature_store.latest_user_tier",
]

for name in feature_names:
    mfs = fe.list_materialized_features(feature_name=name)   # required, keyword-only
    offline = [mf for mf in mfs if not mf.is_online]
    for mf in (offline or mfs):
        fe.delete_materialized_feature(materialized_feature=mf)
    fe.delete_feature(full_name=name)

Pulizia delle risorse in background

Quando si elimina una funzionalità materializzata, Databricks rimuove immediatamente i metadati della funzionalità. L'infrastruttura associata (tabelle, pipeline e processi) viene pulita in modo asincrono da un processo in background.

Poiché più funzionalità materializzate possono condividere le stesse tabelle e pipeline, queste risorse condivise non vengono rimosse fino a quando non viene eliminata ogni funzionalità materializzata che vi fa riferimento. Quando viene eliminata l'ultima funzionalità materializzata che condivide un set di tabelle, il processo in background elimina automaticamente le risorse seguenti:

• Tabelle Delta offline contenenti i dati delle funzionalità materializzate
• Le tabelle online, se le funzionalità sono state materializzate in un negozio online
• Pipeline di materializzazione
• Processo di orchestrazione

Questo processo in background usa un'entità servizio di sistema gestita da Databricks per eseguire queste azioni di pulizia per conto dell'utente, tra cui l'eliminazione di tabelle, pipeline e processi nell'area di lavoro. Non è necessaria alcuna azione da parte dell'utente. La pulizia è completamente gestita dal feature store.

Visualizzare lo stato di materializzazione

Per visualizzare lo stato di materializzazione delle Feature View nell'interfaccia utente di Databricks ed eseguire il debug degli errori di materializzazione, consulta Esplorare le Feature View in Unity Catalog.

Valida la freschezza end-to-end di RollingWindow

Questa sezione si applica solo alle RollingWindow aggregazioni. Le funzionalità batch non espongono i metadati di freschezza dello streaming descritti qui.

Le funzionalità di streaming RollingWindow materializzate in uno store online Lakebase includono metadati di freschezza per riga. Con CDF, si cattura ogni aggiornamento della tabella online in una tabella di cronologia Delta in Unity Catalog e si misura la freschezza end-to-end senza dover eseguire una pipeline aggiuntiva. La freschezza end-to-end è il ritardo tra il momento in cui si è verificato un evento e quando il suo valore aggregato è diventato disponibile per l’erogazione.

Come le funzionalità di RollingWindow emettono righe

Per una RollingWindow feature, il valore di ciascuna entità riassume gli eventi entro una finestra temporale fissa (ad esempio, il conteggio delle transazioni nell'ultima ora). La finestra scorre continuamente in avanti, quindi una riga viene scritta sullo store online in due situazioni:

• Aggiornamento guidato dai dati (is_timer = false): arriva un nuovo evento che aggiorna l'aggregato. La riga riflette l'evento più recente nella finestra.
• Scadenza finestra (is_timer = true): non arriva un nuovo evento, ma il tempo avanza e gli eventi più vecchi escono dalla finestra o scadono. Poiché quegli eventi non contano più nell'aggregato, il valore cambia (ad esempio, un conteggio diminuisce), quindi la caratteristica emette una riga aggiornata su un timer. La riga riflette il momento in cui l'evento più vecchio è scaduto, cioè la fine della finestra di quell'evento.

In entrambi i casi, event_time è il momento in cui è avvenuto il cambiamento che ha prodotto la riga: l'arrivo di un nuovo evento o la scadenza dell'evento meno recente. Quindi commit_time - event_time indica la freschezza della riga, indipendentemente da come è stata emessa.

Metadati di aggiornamento

Ogni riga online in streaming contiene le seguenti colonne:

Quando il CDF è abilitato, ogni modifica viene aggiunta a una lb_<online_table>_history tabella Delta con colonne di metadati CDF. La _pg_change_type colonna (insert, update_preimage, update_postimage, o delete) identifica ogni tipo di modifica.

Abilita CDF sulla tabella online

1. Lakebase CDF richiede l'identità replica impostata su FULL per ogni tabella sorgente in modo che gli aggiornamenti vengano catturati con immagini complete della riga prima e dopo. Mettilo sulla tabella online:

   ALTER TABLE <schema>.<online_table> REPLICA IDENTITY FULL;
   

2. Avvia Lakebase CDF per lo store online, scegliendo lo schema sorgente e un catalogo e schema di destinazione del Catalogo Unity. Per i dettagli di configurazione, consulta Lakebase Change Data Feed.

CDF crea lb_<online_table>_history nello schema di destinazione.

Per fermare la cattura delle modifiche, vedi Disabilita il CDF di Lakebase. Disabilitare CDF interrompe il feed per tutti gli schema nel progetto. Dopo aver disabilitato il CDF, puoi resettare l'identità replica della tabella online per rimuovere il volume di log extra write-ahead:

ALTER TABLE <schema>.<online_table> REPLICA IDENTITY DEFAULT;

Aggiornamento del compute

La freschezza vale commit_time - event_time sia per le righe basate sui dati che per le righe con scadenza della finestra. Includi is_timer così puoi confrontare i due tipi di emissione e limita la query al periodo che vuoi misurare.

SELECT
  event_time,
  commit_time,
  is_timer,
  (unix_micros(commit_time) - unix_micros(event_time)) / 1000 AS feature_freshness_ms
FROM <dest_catalog>.<dest_schema>.lb_<online_table>_history
WHERE _pg_change_type IN ('insert', 'update_postimage')
  AND commit_time >= (
    SELECT max(commit_time) - INTERVAL 1 DAY
    FROM <dest_catalog>.<dest_schema>.lb_<online_table>_history
  );

feature_freshness_ms è il ritardo, in millisecondi, dal momento dell'evento alla scrittura nello store online. Questa è la freschezza del valore disponibile per l’erogazione.

Interpretare i risultati

• Monitorare sia p50 che p99 di feature_freshness_ms, e confrontare le righe basate sui dati (is_timer = false) con le righe di scadenza della finestra (is_timer = true).
• Aspettati un piccolo picco periodico al limite del batch della modalità real-time (5 minuti per impostazione predefinita), quando la pipeline si ferma brevemente per eseguire checkpoint e commit. Questo è tipicamente trascurabile all'intervallo predefinito.
• Osserva la rara long tail (il massimo, oltre p99). Riflette il recupero della pipeline piuttosto che lo stato stazionario, in particolare dopo un riavvio, come un riavvio di manutenzione, quando la pipeline elabora eventi memorizzati nel buffer. Misura la freschezza dello stato stazionario su una finestra che esclude i riavvii e valuta separatamente i picchi di riavvio.

Limitazioni

Funzionalità di Batch

• Le pipeline di materializzazione in batch vengono eseguite come pipeline serverless di Lakeflow.
• Le funzionalità della finestra rotativa batch non possono essere materializzate, tranne per il caso speciale solo Last online descritto nei valori più recenti limitati dalla freschezza di Materialize. Per l'addestramento offline o l'inferenza batch, le funzionalità delle finestre rolling vengono calcolate dai dati sorgente per ogni ricerca in un momento determinato.
• ColumnSelection le caratteristiche possono essere materializzate solo nei negozi online.
• Le funzionalità di RequestSource, FeatureViewSource e CustomUDF non possono essere create. Vedi Funzionalità su richiesta e materializzazione.
• Le funzionalità materializzate possono essere eliminate solo nell'area di lavoro in cui sono state create.
• Solo l'utente che ha creato una funzionalità materializzata può eliminarla, indipendentemente dai privilegi del Catalogo Unity sulla funzionalità o sul suo schema genitore.
• Per le funzionalità di aggregazione materializzate, la funzionalità materializzata online non può essere eliminata direttamente. Eliminare la funzionalità materializzata offline abbinata e la modifica viene propagata a entrambi.
• Per le funzionalità di aggregazione materializzate create prima del 20 aprile 2026, la pipeline di materializzazione continua a produrre nuovi valori di funzionalità fino a quando non vengono eliminate tutte le funzionalità materializzate nella pipeline, che attiva la pulizia delle risorse. Per creare una pipeline aggiornata che supporta l'eliminazione per funzionalità, eliminare e rimaterializzare la funzionalità.
• Per le funzionalità materializzate ColumnSelection , la pipeline di materializzazione continua a produrre nuovi valori di funzionalità fino a quando non vengono eliminate tutte le funzionalità materializzate nella pipeline, che attiva la pulizia delle risorse.

Funzionalità di streaming

• Le funzionalità di streaming possono essere materializzate solo negli store online. La materializzazione offline non è necessaria perché le funzionalità di streaming in fase di training sono progettate per essere ricalcolate da eventi cronologici per punto dati per fornire un'accuratezza a livello di millisecondo.
• Le funzionalità di streaming non possono essere combinate con le funzionalità batch in una singola materialize_features chiamata.
• compute_features non supporta le funzionalità di streaming.
• L'area di lavoro deve trovarsi in un'area che supporta le istanze di Lakebase.
• I messaggi Kafka possono usare JSON, Avro o Protobuf. Per i requisiti dello schema e le limitazioni del registro dello schema, vedi Registro dello schema.
• Solo RollingWindow e SawtoothWindow sono supportati per le funzionalità di aggregazione dello streaming. TumblingWindow e SlidingWindow devono essere usati con le funzionalità batch. Vedi le finestre temporali per le funzionalità di streaming.
• Solo le funzioni di aggregazione Count, Avg, Sum, FirstDistinct, First, Max, StddevPop, Last, FirstN, Min, LastN e LastDistinct sono supportate per le funzionalità di streaming.
• Le funzionalità di selezione delle colonne dalle origini di streaming non gestiscono i messaggi non ordinati. Viene visualizzato l'evento più recente nel flusso Kafka, anche se il valore della colonna timeseries è precedente a un evento ricevuto in precedenza.
• Le pipeline di streaming vengono riavviate due volte alla settimana. Ogni riavvio può causare ritardi di elaborazione e tempi di avvio fino a 1 minuto. Esclusi i riavvii, la freschezza p99 è di 200 ms.
• Il riempimento delle funzionalità per la materializzazione non è supportato. Quando una funzionalità viene materializzata, viene calcolata da quel punto in avanti. Le aggregazioni appena create nell'archivio dati online non sono accurate finché la relativa finestra temporale non è trascorsa.
• È supportato solo Databricks Online Feature Store .
• Le pipeline di materializzazione in streaming vengono eseguite come pipeline serverless di Lakeflow.