Share via


Concetti relativi alla materializzazione dei set di funzionalità

La materializzazione calcola i valori delle funzionalità dai dati di origine. I valori ora di inizio e ora di fine definiscono una finestra delle funzionalità. Un processo di materializzazione calcola le funzionalità in questa finestra. I valori delle funzionalità materializzati vengono quindi archiviati in un archivio di materializzazione online o offline. Dopo la materializzazione dei dati, tutte le query sulle funzionalità possono quindi attingere a tali valori dall'archivio di materializzazione.

Senza materializzazione, una query offline del set di funzionalità applica le trasformazioni all'origine in tempo reale, per calcolare le funzionalità prima che la query restituisca i valori. Questo processo offre buoni risultati nella fase di prototipazione. Tuttavia, per le operazioni di training e inferenza, in un ambiente di produzione, le funzionalità devono essere materializzate prima del training o dell'inferenza. La materializzazione in questa fase garantisce maggiore affidabilità e disponibilità.

Esplorazione della materializzazione delle funzionalità

L'interfaccia utente dei processi di materializzazione mostra lo stato di materializzazione dei dati negli archivi di materializzazione offline e online e un elenco di processi di materializzazione.

Screenshot showing the feature set materialization jobs user interface.

In una finestra delle funzionalità:

  • Il grafico serie temporale nella parte superiore mostra gli intervalli di dati che rientrano nella finestra delle funzionalità, con lo stato di materializzazione, sia per gli archivi offline che per quelli online.
  • L'elenco di processi nella parte inferiore mostra tutti i processi di materializzazione con finestre di elaborazione che si sovrappongono alla finestra delle funzionalità selezionata.

Stato della materializzazione dei dati e intervallo di dati

Un intervallo di dati è una finestra temporale in cui il set di funzionalità materializza i relativi valori di funzionalità a uno di questi stati:

  • Completo (verde) - Materializzazione corretta dei dati
  • Incompleto (rosso): uno o più processi di materializzazione sono stati annullati o hanno dato esito negativo per questo intervallo di dati
  • In sospeso (blu): uno o più processi di materializzazione per questo intervallo di dati sono in corso
  • Nessuno (grigio): nessun processo di materializzazione è stato inviato per questo intervallo di dati

Man mano che i processi di materializzazione vengono eseguiti per il set di funzionalità, creano o uniscono intervalli di dati:

  • Quando due intervalli di dati sono continui nella sequenza temporale e hanno lo stesso stato di materializzazione dei dati, diventano un intervallo di dati
  • In un intervallo di dati, quando una parte dei dati di funzionalità viene materializzata di nuovo e tale parte ottiene un diverso stato di materializzazione dei dati, tale intervallo di dati viene suddiviso in diversi intervalli

Quando gli utenti selezionano una finestra delle funzionalità, potrebbero visualizzare diversi intervalli di dati all'interno della stessa, con diversi stati di materializzazione dei dati. Nella sequenza temporale potrebbero essere visualizzati diversi intervalli di dati non contigui. Ad esempio, lo snapshot precedente ha 16 intervalli di dati per la finestra di funzionalità definita nell'archivio di materializzazione offline.

In qualsiasi momento, un set di funzionalità può avere al massimo 2.000 intervalli di dati. Quando un set di funzionalità raggiunge tale limite, non è possibile eseguire altri processi di materializzazione. Gli utenti devono quindi creare una nuova versione del set di funzionalità con la materializzazione abilitata. Per la nuova versione del set di funzionalità, eseguire la materializzazione delle funzionalità nei negozi offline e online da zero.

Per evitare il limite, gli utenti devono eseguire i processi di back-fill in anticipo per colmare le lacune negli intervalli di dati. Tale operazione unisce gli intervalli di dati e riduce il conteggio totale.

Processi di materializzazione dei dati

Prima di eseguire un processo di materializzazione dei dati, abilitare le materializzazioni dei dati offline e/o online a livello di set di funzionalità.

from azure.ai.ml.entities import (
    MaterializationSettings,
    MaterializationComputeResource,
)

# Turn on both offline and online materialization on the "accounts" featureset.

accounts_fset_config = fs_client._featuresets.get(name="accounts", version="1")

accounts_fset_config.materialization_settings = MaterializationSettings(
    offline_enabled=True,
    online_enabled=True,
    resource=MaterializationComputeResource(instance_type="standard_e8s_v3"),
    spark_configuration={
        "spark.driver.cores": 4,
        "spark.driver.memory": "36g",
        "spark.executor.cores": 4,
        "spark.executor.memory": "36g",
        "spark.executor.instances": 2,
    },
    schedule=None,
)

fs_poller = fs_client.feature_sets.begin_create_or_update(accounts_fset_config)
print(fs_poller.result())

È possibile inviare i processi di materializzazione dei dati come:

Avviso

I dati già materializzati nella materializzazione offline e/o online non saranno più utilizzabili se la materializzazione dei dati offline e/o online è disabilitata a livello di set di funzionalità. Lo stato di materializzazione dei dati nell'archivio di materializzazione offline e/o online verrà reimpostato su None.

È possibile inviare processi di back-fill tramite:

  • Stato di materializzazione dei dati
  • ID di un processo di materializzazione annullato o che ha dato esito negativo

Back-fill dei dati per stato di materializzazione dei dati

L'utente può inviare una richiesta di back-fill con:

  • Un elenco di valori di stato di materializzazione dei dati - Incompleto, Completo o Nessuno
  • Una finestra delle funzionalità (facoltativa)
from datetime import datetime
from azure.ai.ml.entities import DataAvailabilityStatus

st = datetime(2022, 1, 1, 0, 0, 0, 0)
et = datetime(2023, 6, 30, 0, 0, 0, 0)

poller = fs_client.feature_sets.begin_backfill(
    name="transactions",
    version="1",
    feature_window_start_time=st,
    feature_window_end_time=et,
    data_status=[DataAvailabilityStatus.NONE],
)
print(poller.result().job_ids)

Dopo l'invio della richiesta di back-fill, viene creato un nuovo processo di materializzazione per ogni intervallo di dati con stato di materializzazione dei dati corrispondente (Incompleto, Completo o Nessuno). Inoltre, gli intervalli di dati pertinenti devono rientrare nella finestra di funzionalità definita. Se lo stato di materializzazione dei dati è Pending per un intervallo di dati, non viene inviato alcun processo di materializzazione per tale intervallo.

Sia l'ora di inizio che quella di fine della finestra delle funzionalità sono facoltative nella richiesta di back-fill:

  • Se l'ora di inizio della finestra di funzionalità non viene specificata, l'ora di inizio viene definita come ora di inizio del primo intervallo di dati che non ha uno stato di materializzazione dei dati di None.
  • Se l'ora di fine della finestra di funzionalità non viene specificata, l'ora di fine viene definita come ora di fine dell'ultimo intervallo di dati che non ha uno stato di materializzazione dei dati di None.

Nota

Se non sono stati inviati processi ricorrenti o di back-fill per un set di funzionalità, il primo processo di back-fill deve essere inviato con un'ora di inizio e un'ora di fine della finestra di funzionalità.

Questo esempio include questi valori di stato di materializzazione e intervallo di dati correnti:

Ora di inizio Ora di fine Stato di materializzazione dei dati
2023-04-01T04:00:00.000 2023-04-02T04:00:00.000 None
2023-04-02T04:00:00.000 2023-04-03T04:00:00.000 Incomplete
2023-04-03T04:00:00.000 2023-04-04T04:00:00.000 None
2023-04-04T04:00:00.000 2023-04-05T04:00:00.000 Complete
2023-04-05T04:00:00.000 2023-04-06T04:00:00.000 None

Questa richiesta di back-fill ha questi valori:

  • Materializzazione dei dati data_status=[DataAvailabilityStatus.Complete, DataAvailabilityStatus.Incomplete]
  • Avvio della finestra delle funzionalità = 2023-04-02T12:00:00.000
  • Fine della finestra delle funzionalità = 2023-04-04T12:00:00.000

Crea questi processi di materializzazione:

  • Processo 1: finestra delle funzionalità di processo [2023-04-02T12:00:00.000, 2023-04-03T04:00:00.000)
  • Processo 2: finestra delle funzionalità di processo [2023-04-04T04:00:00.000, 2023-04-04T12:00:00.000)

Se entrambi i processi vengono completati correttamente, i nuovi valori di intervallo di dati e stato di materializzazione diventano:

Ora di inizio Ora di fine Stato di materializzazione dei dati
2023-04-01T04:00:00.000 2023-04-02T04:00:00.000 None
2023-04-02T04:00:00.000 2023-04-02T12:00:00.000 Incomplete
2023-04-02T12:00:00.000 2023-04-03T04:00:00.000 Complete
2023-04-03T04:00:00.000 2023-04-04T04:00:00.000 None
2023-04-04T04:00:00.000 2023-04-05T04:00:00.000 Complete
2023-04-05T04:00:00.000 2023-04-06T04:00:00.000 None

Un nuovo intervallo di dati viene creato il giorno 02-04-2023, perché la metà di quel giorno ha ora uno stato di materializzazione differente: Complete. Anche se un nuovo processo di materializzazione è stato eseguito per metà del giorno 04-04-2023, l'intervallo di dati non viene modificato (diviso) perché lo stato di materializzazione non è cambiato.

Se l'utente effettua una richiesta di back-fill solo con materializzazione dei dati data_status=[DataAvailabilityStatus.Complete, DataAvailabilityStatus.Incomplete], senza impostare l'ora di inizio e di fine della finestra delle funzionalità, la richiesta usa il valore predefinito di tali parametri menzionati in precedenza in questa sezione e crea i seguenti processi:

  • Processo 1: finestra delle funzionalità di processo [2023-04-02T04:00:00.000, 2023-04-03T04:00:00.000)
  • Processo 2: finestra delle funzionalità di processo [2023-04-04T04:00:00.000, 2023-04-05T04:00:00.000)

Confrontare la finestra delle funzionalità per questi processi di richiesta più recenti e i processi di richiesta mostrati nell'esempio precedente.

Back-fill dei dati in base a ID processo

È anche possibile creare una richiesta di back-fill con un ID processo. Si tratta di un modo pratico per ritentare un processo di materializzazione annullato o che ha dato esito negativo. Innanzitutto, trovare l'ID del processo da riprovare:

  • Andare all'interfaccia utente dei processi di materializzazione del set di funzionalità
  • Selezionare il nome visualizzato di un processo specifico che ha un valore di statoNon riuscito
  • Nella pagina Panoramica del processo individuare il valore dell'ID del processo pertinente nella proprietà Nome Inizia con Featurestore-Materialization-.

poller = fs_client.feature_sets.begin_backfill(
    name="transactions",
    version=version,
    job_id="<JOB_ID_OF_FAILED_MATERIALIZATION_JOB>",
)
print(poller.result().job_ids)

È possibile inviare un processo di bak-fill con l'ID processo di un processo di materializzazione annullato o che ha dato esito negativo. In questo caso, lo stato dei dati della finestra delle funzionalità per il processo di materializzazione originale annullato o che ha dato esito negativo deve essere Incomplete. Se questa condizione non viene soddisfatta, il processo di back-fill in base all'ID genera un errore utente. Ad esempio, un processo di materializzazione che ha dato esito negativo potrebbe avere un valore 2023-04-01T04:00:00.000 di ora di inizio e uno 2023-04-09T04:00:00.000 di ora di fine nella finestra delle funzionalità. Un processo di back-fill inviato usando l'ID di questo processo non riuscito ha esito positivo solo se lo stato dei dati ovunque, nell'intervallo di tempo da 2023-04-01T04:00:00.000 a 2023-04-09T04:00:00.000 è Incomplete.

Materiale sussidiario e procedure consigliate

Impostare una pianificazione source_delay adeguata e ricorrente

La proprietà source_delay per i dati di origine indica il ritardo tra il tempo di acquisizione dei dati pronti per l'utilizzo, rispetto all'ora dell'evento di generazione dei dati. Un evento che si è verificato in corrispondenza di t finisce nella tabella dei dati di origine in corrispondenza di t + x, a causa della latenza nella pipeline di dati upstream. Il valore x è il ritardo di origine.

Illustration that shows the source_delay concept.

Per una corretta configurazione, la pianificazione dei processi di materializzazione ricorrente determina la latenza. Il processo ricorrente produce caratteristiche per la finestra temporale[schedule_trigger_time - source_delay - schedule_interval, schedule_trigger_time - source_delay).

materialization_settings:
  schedule:
    type: recurrence
    interval: 1
    frequency: Day
    start_time: "2023-04-15T04:00:00.000"

Questo esempio definisce un processo giornaliero che viene attivato alle 4:00, a partire dal 15/4/2023. A seconda dell'impostazione di source_delay, l'esecuzione del processo dell'1/5/2023 produce funzionalità in finestre temporali differenti:

  • source_delay=0 produce valori di funzionalità nella finestra [2023-04-30T04:00:00.000, 2023-05-01T04:00:00.000)
  • source_delay=2hours produce valori di funzionalità nella finestra [2023-04-30T02:00:00.000, 2023-05-01T02:00:00.000)
  • source_delay=4hours produce valori di funzionalità nella finestra [2023-04-30T00:00:00.000, 2023-05-01T00:00:00.000)

Aggiornare l'archivio di materializzazione

Prima di aggiornare un archivio di materializzazione online o offline, di un archivio di funzionalità, tutti i set di funzionalità nell'archivio di funzionalità devono avere la materializzazione offline e/o online corrispondente disabilitata. Se alcuni set di funzionalità hanno la materializzazione abilitata, l'operazione di aggiornamento non riesce come UserError.

Se la materializzazione offline e/o online è disabilitata in un set di funzionalità, lo stato di materializzazione dei dati nell'archivio di materializzazione offline e/o online viene reimpostato. La reimpostazione esegue il rendering dei dati materializzati non utilizzabili. Se la materializzazione offline e/o online nel set di funzionalità viene abilitata in un secondo momento, gli utenti devono inviare nuovamente i processi di materializzazione.

Bootstrap dei dati online

Il bootstrap dei dati online è applicabile solo se i processi di materializzazione offline inviati sono stati completati correttamente. Se solo la materializzazione offline è stata inizialmente abilitata per un set di funzionalità e la materializzazione online viene abilitata in un secondo momento:

  • Lo stato di materializzazione predefinito dei dati presenti nell'archivio online è None

  • Quando viene inviato un processo di materializzazione online, i dati con lo stato di materializzazione Complete nell'archivio offline vengono usati per calcolare le funzionalità online. Questa operazione è denominata bootstrap dei dati online. Il bootstrap dei dati online consente di risparmiare sui costi di calcolo perché riutilizza le funzionalità già elaborate salvate nell'archivio di materializzazione offline. Questa tabella riepiloga i valori di stato dei dati offline e online in intervalli di dati che comporterebbero il bootstrap dei dati online:

    Ora di inizio Ora di fine Stato dei dati offline Stato dei dati online Bootstrap dei dati online
    2023-04-01T04:00:00.000 2023-04-02T04:00:00.000 None None No
    2023-04-02T04:00:00.000 2023-04-03T04:00:00.000 Incomplete None No
    2023-04-03T04:00:00.000 2023-04-04T04:00:00.000 Pending None Nessun processo di materializzazione inviato
    2023-04-04T04:00:00.000 2023-04-05T04:00:00.000 Complete None

Risolvere gli errori e le modifiche dei dati di origine

Alcuni scenari modificano i dati di origine a causa di un errore o altri motivi dopo la materializzazione dei dati. In questi casi, un aggiornamento dei dati delle funzionalità, per una finestra di funzionalità specifica in più intervalli di dati, può risolvere dati di funzionalità errati o non aggiornati. Inviare la richiesta di materializzazione per la risoluzione di dati di funzionalità errati o obsoleti presenti nella finestra delle funzionalità, per gli stati dei dati None, Complete e Incomplete.

È consigliabile inviare una richiesta di materializzazione per un aggiornamento dei dati delle funzionalità solo quando la finestra delle funzionalità non contiene alcun intervallo di dati con uno stato dei dati Pending.

Colmare le lacune

Nell'archivio di materializzazione i dati materializzati potrebbero avere lacune in quanto:

  • un processo di materializzazione non è mai stato inviato per la finestra delle funzionalità
  • i processi di materializzazione inviati per la finestra delle funzionalità hanno dato esito negativo o sono stati annullati

In questo caso, inviare una richiesta di materializzazione nella finestra delle funzionalità per data_status=[DataAvailabilityStatus.NONE,DataAvailabilityStatus.Incomplete] per riempire le lacune. Una singola richiesta di materializzazione colma tutte le lacune nella finestra delle funzionalità.

Passaggi successivi