Attivare i processi quando vengono aggiornate le tabelle di origine

È possibile usare trigger di aggiornamento tabella per attivare un'esecuzione del processo quando vengono aggiornate le tabelle di origine. Usare questa funzionalità per eseguire un processo quando i nuovi dati sono pronti senza la necessità di un cluster in esecuzione continua o di conoscere i processi che aggiornano una tabella.

Funzionamento dei trigger di aggiornamento delle tabelle

Un trigger di aggiornamento tabella controlla la disponibilità di aggiornamenti delle tabelle e, quando viene aggiornata una tabella, viene eseguito il processo. Il trigger può essere eseguito quando una tabella viene aggiornata o quando tutte le tabelle monitorate dal trigger vengono aggiornate. I trigger di aggiornamento delle tabelle non comportano costi aggiuntivi diversi dai costi del provider di servizi cloud associati all'elenco delle tabelle e alla lettura degli aggiornamenti dal percorso di archiviazione.

Un trigger di aggiornamento tabella può essere configurato per monitorare una o più tabelle per le modifiche ai dati, ad esempio aggiornamenti, merge ed eliminazioni. Queste tabelle possono essere tabelle gestite da Unity Catalog Delta e Iceberg, tabelle esterne del catalogo Unity supportate da Delta Lake, viste materializzate, tabelle di streaming e viste del catalogo Unity o viste delle metriche che dipendono dalle tabelle supportate. Quando si selezionano più tabelle, è possibile specificare se un processo viene attivato quando una o tutte le tabelle vengono aggiornate.

È anche possibile configurare i trigger nelle tabelle e nelle viste OpenSharing e nelle tabelle di sistema (Beta). Vedi Aggiungere un trigger a OpenSharing e alle tabelle di sistema.

Aggiungere un trigger di aggiornamento tabella

Per aggiungere un trigger di aggiornamento tabella a un processo esistente:

1. Nella barra di navigazione sinistra dell'area di lavoro, fare clic su i Processi e le pipeline.

2. Nell'elenco dei processi fare clic sul nome del processo a cui si vuole aggiungere un trigger.

3. Nel riquadro destro, in Pianificazioni e trigger, fare clic su Aggiungi trigger.

4. In Tipo di trigger selezionare Aggiornamento tabella.

5. In Tabelle aggiungere le tabelle da monitorare per gli aggiornamenti.

   Se si selezionano più tabelle, configurare un'opzione in Trigger quando specificare se si desidera attivare un'esecuzione di un processo quando vengono aggiornate tutte le tabelle o quando viene aggiornata qualsiasi tabella.

6. (Facoltativo) Configurare le opzioni avanzate facendo clic su Avanzate.

   • Tempo minimo tra i trigger in secondi: tempo minimo di attesa per attivare un'esecuzione dopo il completamento di un'esecuzione precedente. Le tabelle aggiornate durante questo periodo attivano un'esecuzione solo dopo la scadenza del tempo di attesa. Azure Databricks attende questo periodo di tempo prima di attivare un'esecuzione, anche se le tabelle monitorate vengono aggiornate.
   • Attendere dopo l'ultima modifica in secondi: tempo di attesa per attivare un'esecuzione dopo l'aggiornamento di una tabella. Aggiornamenti aggiuntivi della tabella durante questo periodo reimpostano il timer. Questa impostazione può essere usata quando gli aggiornamenti delle tabelle vengono inseriti in batch e l'intero batch deve essere elaborato dopo l'aggiornamento di tutte le tabelle.

   Annotazioni

   Se vengono usate entrambe le opzioni, il trigger attende il tempo minimo tra i trigger e quindi attende il periodo di tempo impostato dopo l'ultima modifica. Ad esempio, se si ha un tempo minimo di 120 secondi e un'attesa dopo le ultime modifiche di 60 secondi, l'esecuzione non viene attivata fino a quando non sono trascorsi almeno 120 secondi, anche se si verifica un aggiornamento della tabella entro i primi 60 secondi. Inoltre, se un aggiornamento arriva a 5 secondi e un altro a 115 secondi, l'attesa dopo l'ultima modifica indica che un'esecuzione non viene attivata fino a dopo 175 secondi.

7. Per convalidare la configurazione, fare clic su Trigger di test.

8. Fare clic su Salva.

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.

Aggiungi un trigger a OpenSharing e alle tabelle di sistema

Oltre alle tabelle locali, è possibile configurare i trigger di aggiornamento delle tabelle per monitorare i dati condivisi con l'area di lavoro tramite OpenSharing e tabelle di sistema. Ad esempio, è possibile attivare un processo ogni volta che i nuovi record di fatturazione vengono inseriti in una tabella di sistema o ogni volta che un provider aggiorna una tabella condivisa.

È possibile attivare gli oggetti condivisi seguenti:

• Tabelle OpenSharing
• Visualizzazioni OpenSharing
• Visualizzazioni delle metriche OpenSharing
• Viste materializzate OpenSharing
• Tabelle di streaming OpenSharing
• Tabelle di sistema

Esaminare le limitazioni del trigger OpenSharing, quindi seguire la procedura descritta in Aggiungere un trigger di aggiornamento tabella e selezionare le tabelle condivise, le viste o le tabelle di sistema da monitorare.

Limitazioni dei trigger OpenSharing

• Questa funzionalità supporta solo Databricks-to-Databricks OpenSharing. La condivisione da Databricks a Open non è supportata.

• Per attivare tabelle e viste condivise, la versione beta deve essere abilitata sia sul lato destinatario che su quello del provider:

  • Trigger di aggiornamento della tabella in OpenSharing (destinatario): funzionalità beta a livello di area di lavoro, abilitata nell'area di lavoro del destinatario in cui viene creato il trigger.
  • Trigger di aggiornamento della tabella in OpenSharing (Provider): beta a livello di account, abilitata nell'account del provider che possiede i dati condivisi.

  Per le tabelle di sistema, è necessaria solo la versione beta del destinatario. Per abilitare, vedere Gestire le anteprime di Azure Databricks.

• L'utente che crea il trigger deve avere il SELECT privilegio per l'oggetto condiviso o la tabella di sistema.

Trigger di aggiornamento tabella con eventi di file

Per ottenere prestazioni e scalabilità ottimali, abilitare gli eventi di file nel percorso esterno in cui vengono archiviate le tabelle. Questo passaggio di configurazione monouso migliora l'efficienza dei trigger di aggiornamento delle tabelle e sblocca altre funzionalità, tra cui trigger di caricamento automatico e arrivo file più efficienti.

Quando gli eventi di file sono abilitati, Databricks tiene automaticamente traccia dei metadati di inserimento usando le notifiche di modifica del provider di servizi cloud, ottenendo aggiornamenti delle tabelle più veloci ed efficienti.

Se le tabelle si trovano nell'archiviazione a livello radice del metastore, convertirle prima in un percorso esterno, quindi abilitare gli eventi di file in tale percorso.

Per domande comuni sugli eventi di file, vedere Domande frequenti sugli eventi di file.

Parametri del processo associati ai trigger di aggiornamento della tabella

Quando si usano trigger di aggiornamento tabella per un processo, sono disponibili tre nuovi riferimenti a valori dinamici da usare come valori di parametro nel processo.

• {{job.trigger.table_update.updated_tables}} - Elenco JSON di tabelle aggiornate dall'ultima esecuzione del processo.
• {{job.trigger.table_update.`<catalog.schema.table>`.commit_timestamp.iso_datetime}} : il timestamp del commit più recente che ha attivato l'esecuzione del job.
• {{job.trigger.table_update.`<catalog.schema.table>`.version}}, la versione di commit più recente che ha attivato l'esecuzione del job.

Per commit_timestamp e versionsono disponibili più versioni del riferimento al valore dinamico. Ogni tabella monitorata ha un <catalog.schema.table> con il nome completo della tabella per la quale si desiderano i dati. Se nel trigger è presente una sola tabella monitorata, viene visualizzato un valore senza .<catalog.schema.table> Ad esempio, è possibile usare {{job.trigger.table_update.commit_timestamp.iso_datetime}}.

Per altre informazioni sui parametri del processo, vedere Parametrizzare i processi.

Ricevere notificazioni di mancati aggiornamenti di trigger delle tabelle

Per ricevere una notifica se un trigger di aggiornamento della tabella non riesce a valutarsi, configurare le notifiche di posta elettronica o di sistema in caso di errore del processo. Vedere Aggiungere notifiche in un processo.

Limitazioni

I trigger di aggiornamento delle tabelle presentano le limitazioni seguenti:

• È possibile selezionare fino a 10 tabelle gestite o Delta per trigger.
• Per le tabelle che si trovano in posizioni senza eventi di file, è possibile configurare un massimo di 1.000 processi con un trigger di aggiornamento tabella.
• È possibile creare un massimo di 1.000 trigger di aggiornamento delle tabelle in oggetti OpenSharing o tabelle di sistema per ogni area di lavoro.

I trigger nelle viste del catalogo Unity presentano le limitazioni aggiuntive seguenti:

• I trigger di aggiornamento delle tabelle supportano solo il monitoraggio delle viste del catalogo Unity o delle visualizzazioni delle metriche che dipendono da tabelle supportate anche dai trigger di aggiornamento delle tabelle. In particolare, le viste seguenti non sono supportate:

  • Viste che usano read_files (possono leggere da una tabella supportata che legge i file, ma non possono usare read_filesdirettamente ).
  • Viste che dipendono da tabelle che non si trovano nel catalogo Unity.
  • Viste che dipendono da tabelle federate.

• La creazione di trigger per le viste contenenti dipendenze non supportate ha ancora esito positivo, ma non viene attivata alcuna esecuzione di processo quando viene aggiornata una dipendenza non supportata.

• I trigger di aggiornamento tabella monitorano le modifiche alle tabelle dipendenti di una vista e considera la vista aggiornata se una delle tabelle dipendenti viene aggiornata. È possibile che un'esecuzione del processo venga attivata per le modifiche ai dati filtrate in base alla definizione della vista.

• Le tabelle di origine per una vista vengono conteggiate in base al limite di 10 tabelle per trigger.

  • Ad esempio, se una vista dipende da 11 tabelle, non è possibile usarla in un trigger di aggiornamento tabella. Analogamente, un trigger con due viste, ognuna delle quali dipende da 6 tabelle, conta come 12 tabelle.

• Esiste un limite separato di 10 visualizzazioni dipendenti per visualizzazione monitorata.

  • Ad esempio, se una vista dipende da altre 11 viste, non è possibile usarla in un trigger di aggiornamento di tabella, anche se ciò non viola la regola delle 10 tabelle per trigger.