Attivare i processi quando i modelli vengono aggiornati

Usare i trigger di aggiornamento del modello per eseguire automaticamente un processo quando si verifica una modifica del modello nel catalogo unity. Questa funzionalità sostituisce la necessità di pianificazioni cron o cluster persistenti per tenere traccia degli aggiornamenti del modello.

I trigger di aggiornamento del modello sono progettati per due utenti principali:

• I data scientist possono attivare processi quando una nuova versione del modello è pronta o quando viene impostato un alias, su un singolo modello o su più modelli alla volta. Ad esempio, è possibile eseguire automaticamente processi di convalida, test o promozione ogni volta che cambia un modello di cui sono proprietari. Vedere Esempio: Convalidare i modelli in nuove versioni o alias.
• Gli amministratori possono monitorare tutti i modelli in un intero metastore (o uno schema). Ad esempio, gli amministratori possono controllare automaticamente ogni nuovo modello durante la creazione. Vedere Esempio: Controllare i modelli in uno schema o in un metastore.

Funzionamento dei trigger di aggiornamento del modello

Un trigger di aggiornamento del modello monitora un ambito in Unity Catalog per un evento del modello e attiva un'esecuzione di un processo quando si verifica un evento corrispondente. Quando si configura un trigger di aggiornamento del modello, si sceglie un ambito e una condizione.

Gli ambiti disponibili includono:

• Modello: modello registrato singolo.
• Schema: tutti i modelli in uno schema.
• Metastore: tutti i modelli nel metastore. Solo un amministratore del metastore può configurare un trigger a livello di metastore.

La condizione determina quando attivare un'esecuzione:

• Viene creato un modello: viene creato un nuovo modello registrato nell'ambito.
• La versione del modello è disponibile: una nuova versione del modello diventa disponibile nell'ambito specificato.
• L'alias del modello è impostato: un alias specificato viene applicato a una versione del modello. È possibile specificare fino a 10 alias per trigger e il trigger risponde quando uno di essi viene applicato.

I trigger di aggiornamento del modello non comportano costi aggiuntivi diversi dai costi del provider di servizi cloud.

Aggiornamenti in batch

L'aggiornamento del modello attiva il polling di nuovi eventi circa una volta al minuto. Le modifiche rilevate a ogni intervallo di polling vengono raggruppate e passate all'esecuzione successiva del processo come parametri del processo. Vedi Parametri del job associati ai trigger di aggiornamento del modello.

Un batch non contiene un numero fisso di aggiornamenti. Ogni run include tutti gli aggiornamenti che rientrano nel limite di 10.000 caratteri per il valore di un parametro del processo. Il trigger aggiunge aggiornamenti al batch uno alla volta e si ferma prima dell'aggiornamento che supererebbe il limite, quindi il conteggio dipende dalla durata di ogni aggiornamento serializzato.

Il valore del parametro è compact JSON: un elenco tra parentesi di oggetti separati da virgole, dove ogni oggetto elenca il nome completo del modello, più una versione per la versione Model è pronta, e sia una versione che un nome alias per l'alias Model sono impostati. Questi nomi consumano il limite, quindi nomi di modelli e alias più brevi lasciano spazio a ulteriori aggiornamenti in ogni esecuzione.

Ad esempio, un aggiornamento alias del modello viene impostato per un modello denominato main.ml_models.fraud_detection alla versione 123 con l'alias champion viene serializzato in 84 caratteri:

{"full_name":"main.ml_models.fraud_detection","version":123,"alias_name":"champion"}

Ogni aggiornamento dopo il primo costa anche un carattere per la virgola che lo separa dall'aggiornamento precedente, e i bracket che lo circondano ne costano due. Il numero di aggiornamenti che rientrano è quindi il numero massimo n per il quale 2 + 84n + (n - 1) resta entro 10.000, ossia 117 aggiornamenti per un totale di 9.946 caratteri.

Ripetendo quel calcolo per ogni condizione, usando lo stesso nome del modello e, dove la condizione li include, una versione a tre cifre e l'alias champion:

I nomi più lunghi abbassano questi numeri. Con un nome del modello di 200 caratteri, un'esecuzione comporta 46 aggiornamenti per Il modello viene creato, 43 per La versione del modello è pronta e 39 per L'alias del modello è impostato. Sostituire l'alias breve con uno di 50 caratteri riduce L'alias del modello è impostato da 117 aggiornamenti a 78.

Quando sono in attesa più aggiornamenti di quanti possano essere elaborati in una singola esecuzione, il trigger rimanda quelli rimanenti alle esecuzioni successive, un batch a ogni intervallo di polling. Sono previste raffiche brevi che si esauriranno nel corso dei minuti successivi. Se un ambito produce aggiornamenti più rapidamente di quanto il trigger possa elaborarli per un periodo di tempo prolungato, il trigger viene eseguito a ogni intervallo senza riuscire a recuperare e alla fine ha esito negativo e si arresta. Vedi volume di eventi elevato e costante.

Volume di eventi elevato sostenuto

Un trigger di aggiornamento del modello funziona al meglio negli ambiti in cui gli aggiornamenti arrivano, in media, a una frequenza non superiore a quella che una singola esecuzione può gestire. Vedere Aggiornamenti in batch.

Per evitare un backlog sempre più ampio, un trigger che viene eseguito a ogni intervallo di polling per circa un'ora consecutiva va in errore e si arresta. L'errore viene segnalato sul trigger. Il trigger non viene ripristinato automaticamente e non vengono avviate altre esecuzioni fino a quando non viene ripristinato manualmente.

Per ripristinare l'attivazione:

1. Riduci la frequenza degli aggiornamenti in modo che una singola esecuzione riesca a stare al passo. Ad esempio, limitare l'ambito del trigger o suddividere il monitoraggio tra più trigger, come descritto nelle raccomandazioni seguenti. Se si salta questo passaggio, il trigger fallisce di nuovo dopo il ripristino.
2. Reimposta il trigger sospendendolo e riattivandolo. La messa in pausa azzera lo stato accumulato del trigger, così che riprenda dal punto corrente. Usare la sezione Pianificazioni e trigger del riquadro Dettagli del processo, oppure impostare pause_status su PAUSED e quindi su UNPAUSED con l'API Jobs. Vedi Gestire un trigger esistente.

Le opzioni avanzate (Tempo minimo tra i trigger e Attendi dopo l'ultima modifica) controllano con quale frequenza vengono create le esecuzioni, ma non cambiano quanti aggiornamenti viene eseguito. Non impediscono questo errore quando gli aggiornamenti arrivano costantemente più rapidamente di quanto un'esecuzione possa gestirli.

Per monitorare in modo affidabile un ambito con volumi elevati:

• Limita l'ambito di ciascun trigger. Usare trigger con ambito schema o modello anziché un singolo trigger con ambito metastore, in modo che un burst in un'area non arresti il monitoraggio per l'intero metastore.
• Suddividere il monitoraggio tra più trigger e processi in modo che ogni trigger osservi un ambito di volume inferiore.
• Mantenere leggero il processo attivato e usare un oggetto For each task per elaborare ogni aggiornamento. Vedere Elaborare gli aggiornamenti del modello con un oggetto For each task( Per ogni attività).
• Per volumi elevati e costanti su larga scala, contattare il team dell'account di Azure Databricks per valutare le opzioni disponibili.

Prima di iniziare

Per usare i trigger di aggiornamento del modello, è necessario quanto segue:

• L'area di lavoro deve avere Unity Catalog abilitato.
• È necessario disporre del privilegio EXECUTE sul modello o schema di destinazione che si desidera che il trigger monitori. Senza EXECUTE, le operazioni di lettura e scrittura su tali modelli potrebbero non andare a buon fine.
• Per configurare un trigger con ambito del metastore, è necessario essere un amministratore del metastore. È inoltre necessario concedersi l'EXECUTE autorizzazione per ogni catalogo corrente e futuro nel metastore, in modo che il job possa accedere a qualsiasi modello in Unity Catalog.

Aggiungere un trigger di aggiornamento del modello

Per aggiungere un trigger di aggiornamento del modello a un processo esistente:

1. Nella barra laterale dell'area di lavoro Azure Databricks fare clic su Jobs & Pipeline.
2. Nell'elenco dei processi fare clic sul nome del processo a cui si vuole aggiungere un trigger.
3. Nel riquadro Dettagli del processo a destra, fare clic su Aggiungi trigger.
4. In Tipo di trigger selezionare Aggiornamento modello.
5. In Ambito selezionare Modello, Schema o Metastore e quindi specificare il modello o lo schema da monitorare.
6. In Condizione selezionare l'evento da attivare:
   • Viene creato il modello
   • La versione del modello è pronta
   • L'alias del modello è impostato. Specificare fino a 10 alias da monitorare. Il trigger risponde quando viene impostato uno degli alias specificati.
7. (Facoltativo) Configurare le opzioni avanzate:
   • Tempo minimo tra i trigger in secondi: tempo minimo di attesa per attivare un'esecuzione dopo un'esecuzione precedente. I modelli aggiornati durante questo periodo attivano un'esecuzione solo dopo la scadenza del tempo di attesa. Utilizzare questa impostazione per controllare la frequenza di creazione delle esecuzioni.
   • Attendere dopo l'ultima modifica in secondi: tempo di attesa per attivare un'esecuzione dopo un aggiornamento del modello. Un altro aggiornamento del modello durante questo periodo reimposta il timer. Questa impostazione può essere usata quando arrivano gli aggiornamenti del modello in batch e l'intero batch deve essere elaborato dopo l'arrivo di tutti gli aggiornamenti.
8. Per convalidare la configurazione, fare clic su Trigger di test. Se non sono presenti errori, il pulsante mostra Operazione completata.
9. Fai clic su Salva.

Dopo aver salvato il trigger, attendere circa un minuto per l'inizializzazione del trigger. Il messaggio Il trigger verrà valutato a breve indica che l'inizializzazione è in corso. Dopo l'inizializzazione, qualsiasi evento del modello corrispondente nell'ambito attiva un'esecuzione del processo.

Per modificare, sospendere o rimuovere questo trigger in un secondo momento, usare la sezione Pianificazioni e trigger del riquadro Dettagli processo . Vedi Gestire un trigger esistente.

Esempio: Convalidare i modelli in nuove versioni o alias

Per eseguire un processo di convalida, test o promozione quando un modello cambia, configura un trigger con ambito Modello e una delle condizioni La versione del modello è pronta o L'alias del modello è impostato. Per le modifiche dell'alias, specificare gli alias da monitorare, ad esempio prod e staging. Per monitorare più modelli contemporaneamente, usare invece l'ambito dello schema . Una volta inizializzato il trigger, una modifica corrispondente apportata a un modello monitorato avvia l'esecuzione di un job.

Esempio: Controllare i modelli in uno schema o in un metastore

Per verificare ogni modello creato in uno schema o in un metastore, configurare un trigger con l'ambito Schema o Metastore e la condizione Il modello viene creato. Dopo l'inizializzazione del trigger, qualsiasi modello creato nell'ambito attiva un'esecuzione del processo in grado di registrare o convalidare la modifica.

Parametri del job associati ai trigger per l'aggiornamento del modello

Quando si attiva un trigger di aggiornamento del modello, le informazioni sulle modifiche che hanno attivato l'esecuzione sono disponibili per l'esecuzione del processo tramite il riferimento al valore dinamico {{job.trigger.model.updates}}. Il valore è un elenco JSON degli aggiornamenti del modello nel batch:

[
  {
    "full_name": "model.full.name1",
    "version": 123,
    "alias_name": "prod"
  }
]

I campi vengono popolati come segue:

• full_name: popolato sempre con il nome del modello creato o aggiornato.
• version: popolato per gli eventi La versione del modello è pronta con la versione che è diventata pronta e per gli eventi L'alias del modello è impostato con la versione a cui è stato impostato l'alias.
• alias_name: Viene popolato solo per gli eventi in cui è impostato l'alias del modello, con il nome dell'alias che è stato impostato.

Ad esempio, il valore del parametro per ogni condizione è il seguente:

• Viene creato il modello:

  [{ "full_name": "model.number.one" }, { "full_name": "model.number.two" }]
  

• La versione del modello è pronta:

  [
    { "full_name": "model.number.one", "version": 7 },
    { "full_name": "model.number.two", "version": 3 }
  ]
  

• L'alias del modello è impostato:

  [
    { "full_name": "model.number.one", "version": 7, "alias_name": "prod" },
    { "full_name": "model.number.two", "version": 3, "alias_name": "staging" }
  ]
  

Per rendere disponibili gli aggiornamenti a un'attività, aggiungere un parametro di processo il cui valore è {{job.trigger.model.updates}}. Per aggiungere un parametro, fare clic su Modifica parametri nel pannello laterale del processo, quindi impostare il valore del parametro su {{job.trigger.model.updates}}. Per altre informazioni sui parametri del processo, vedere Parametrizzare i processi.

Il notebook seguente legge un parametro denominato events ed elabora gli aggiornamenti del modello passati all'esecuzione:

import json

json_list = dbutils.widgets.get("events")
data = json.loads(json_list)

for item in data:
    print(f"Full Name: {item['full_name']}, Version: {item.get('version')}, Alias Name: {item.get('alias_name')}")

Elaborare gli aggiornamenti del modello con un oggetto For each task

Per ogni attività viene eseguita un'attività nidificata una volta per ogni elemento in un elenco. Per i trigger di aggiornamento del modello, è possibile eseguire un'iterazione per elemento in {{job.trigger.model.updates}}:

1. Configura l'attività For each in modo che accetti {{job.trigger.model.updates}} come input.
2. Configura l'attività annidata per leggere i valori di ciascun input fornito dall'iterazione.
3. I valori di ogni aggiornamento sono disponibili come parametri del widget per l'attività annidata.

Il notebook seguente legge i valori per iterazione in un'attività annidata:

full_name = dbutils.widgets.get("full_name")
version = dbutils.widgets.get("version")
alias_name = dbutils.widgets.get("alias_name")

print(f"Full Name: {full_name}, Version: {version}, Alias Name: {alias_name}")

Configurare un trigger di aggiornamento del modello con la Jobs API

È possibile configurare un trigger di aggiornamento del modello aggiungendo un trigger oggetto a un'operazione jobs/create, jobs/updateo jobs/reset . Nell'esempio seguente viene usato jobs/update:

{
  "job_id": 574587036927544,
  "new_settings": {
    "trigger": {
      "pause_status": "UNPAUSED",
      "model": {
        "securable_name": "main.default",
        "condition": "MODEL_ALIAS_SET",
        "aliases": ["alias1", "alias2"],
        "min_time_between_triggers_seconds": 3600,
        "wait_after_last_change_seconds": 120
      }
    },
    "parameters": [
      {
        "default": "{{job.trigger.model.updates}}",
        "name": "events"
      }
    ]
  }
}

Per l'oggetto di attivazione model:

• securable_name: schema o modello da monitorare. Lascialo vuoto oppure omettilo per monitorare l'intero metastore.
• condition: uno di MODEL_CREATED, MODEL_VERSION_READYo MODEL_ALIAS_SET.
• aliases: Gli alias da monitorare. Si applica solo alla MODEL_ALIAS_SET condizione.

Ricevere notifiche sui trigger di aggiornamento del modello non riusciti

Per ricevere una notifica se un trigger di aggiornamento del modello non viene valutato correttamente, configurare le notifiche tramite e-mail o tramite destinazione di sistema in caso di errore dell’attività. Vedere Aggiungere notifiche in un processo.

Limitations

I trigger di aggiornamento del modello presentano le limitazioni seguenti:

• È possibile configurare un massimo di 100 trigger di aggiornamento del modello per ogni area di lavoro. Questo limite può essere elevato caso per caso.
• Una singola esecuzione di lavoro trasporta tanti aggiornamenti di modello quanti rientrano nel limite di 10.000 caratteri per un valore di parametro di lavoro, che di solito è superiore a 100. Gli ulteriori aggiornamenti in sospeso vengono elaborati nelle esecuzioni successive, un lotto al minuto. Vedere Aggiornamenti in batch.
• Ogni trigger di aggiornamento del modello può monitorare fino a 10 alias.
• Se un trigger si attiva continuamente a ogni intervallo di polling per circa un'ora, non riesce con un errore e smette di attivare esecuzioni. Non si ripristina automaticamente: è necessario ridurre la frequenza di aggiornamento e quindi reimpostare il trigger mettendolo in pausa e poi riattivandolo. Ciò si verifica quando un ambito produce aggiornamenti più velocemente di quanto il trigger possa elaborarli per un periodo prolungato. Vedi volume di eventi elevato e costante.
• Per configurare un trigger con ambito del metastore, è necessario essere un amministratore del metastore e concedersi il privilegio EXECUTE per ogni catalogo corrente e futuro in Unity Catalog, affinché il job possa accedere a qualsiasi modello.

FAQ

Quando dovrei usare i processi di distribuzione rispetto ai trigger di aggiornamento del modello?

Usare i trigger di aggiornamento del modello quando è necessario:

• Monitorare gli eventi di creazione del modello o le modifiche degli alias.
• Monitorare gli eventi in un ambito più ampio di un singolo modello, ad esempio uno schema o un metastore.
• Monitorare molti modelli con un singolo trigger, invece di configurare un processo separato per ogni modello.

Usare i processi di distribuzione quando è necessario un accoppiamento stretto dell'interfaccia utente e i log attività relativi alla relazione tra la creazione della versione del modello e le esecuzioni dei processi.