Acionar tarefa quando tabelas de origem são atualizadas

Você pode usar gatilhos de atualização de tabela para acionar uma execução do seu Job quando as tabelas de origem são atualizadas. Use este recurso para executar um Job quando novos dados estiverem prontos sem a necessidade de um clustercontínuo em execução ou conhecimento dos processos que atualizam uma tabela.

info

Beta

O acionamento de Jobs em tabelas e visualizações do Delta Sharing e em tabelas do sistema está em Beta. Consulte Adicionar um gatilho ao Delta Sharing e tabelas do sistema

Como funcionam os gatilhos de atualização de tabela?

Um gatilho de atualização de tabela verifica se há atualizações de tabela e, quando uma tabela é atualizada, o trabalho é executado. O gatilho pode ser executado quando uma tabela é atualizada ou quando todas as tabelas monitoradas pelo gatilho são atualizadas. Os gatilhos de atualização de tabela não geram custos adicionais além dos custos do provedor cloud associados à listagem de tabelas e à leitura de atualizações do local de armazenamento.

Um gatilho de atualização de tabela pode ser configurado para monitorar uma ou mais tabelas para alterações de dados como atualizações, merges e exclusões. Essas tabelas podem ser tabelas gerenciadas Delta e Iceberg do Unity Catalog, tabelas externas do Unity Catalog apoiadas por Delta Lake, visualizações materializadas, tabelas de transmissão e views ou views de métricas do Unity Catalog que dependem de tabelas compatíveis. Ao selecionar várias tabelas, é possível especificar se um Job é acionado quando qualquer ou todas as tabelas são atualizadas.

Você também pode configurar gatilhos em tabelas e views do Delta Sharing, e em tabelas do sistema (Beta). Consulte Adicionar um gatilho ao Delta Sharing e às tabelas do sistema.

Adicionar um gatilho de atualização de tabela

Para adicionar um gatilho de atualização de tabela a um trabalho existente:

1. Na navegação à esquerda do seu workspace, clique em Trabalhos e pipeline .

2. Na lista de Tarefas, clique no nome da Tarefa à qual você deseja adicionar um gatilho.

3. No painel direito, em Programar & Triggers , clique em Adicionar gatilho .

4. Em Tipo de gatilho, selecione Atualização de tabela .

5. Em Tabelas , adicione as tabelas que você deseja monitorar para atualizações.

   Se você selecionar mais de uma tabela, configure uma opção em Acionar quando para especificar se deseja que uma execução de Job seja acionada quando Todas as tabelas forem atualizadas ou quando Qualquer tabela for atualizada .

6. (Opcional) Configure opções avançadas clicando em Avançado .

   • Tempo mínimo entre triggers em segundos : O tempo mínimo de espera para acionar uma execução após a conclusão de uma execução anterior. Tabelas atualizadas nesse período acionam uma execução somente após o tempo de espera expirar. A Databricks espera esse período de espera antes de acionar uma execução, mesmo que tabelas monitoradas sejam atualizadas.
   • Aguarde após a última alteração em segundos : o tempo de espera para acionar uma execução após uma atualização de tabela. Atualizações adicionais da tabela durante este período Reinicie o cronômetro. Esta configuração pode ser usada quando as atualizações de tabelas ocorrem em lotes, e todos os lotes precisam ser processados depois que todas as tabelas forem atualizadas.

nota

Se ambas as opções forem usadas, então o gatilho aguarda o tempo mínimo entre triggers e, em seguida, aguarda o tempo definido após a última alteração. Por exemplo, se o senhor tiver um tempo mínimo de 120 segundos e uma espera após as últimas alterações de 60 segundos, então ele não iniciará a execução até que pelo menos 120 segundos tenham decorrido, mesmo que uma atualização da tabela ocorra nos primeiros 60 segundos. Além disso, se uma atualização chegar em 5 segundos, e então outra em 115 segundos, então a espera após a última alteração significa que uma execução não será acionada até depois de 175 segundos.

7. Para validar a configuração, clique em Testar gatilho .

8. Clique em Salvar .

nota

Você também pode configurar gatilhos de atualização de tabela na API de trabalhos. Adicione um objeto trigger a uma operação jobs/create, jobs/update ou jobs/reset .

Adicionar um gatilho ao Delta Sharing e às tabelas do sistema

info

Beta

Esta funcionalidade está em Beta.

Além das tabelas locais, você pode configurar triggers de atualização de tabela para monitorar dados compartilhados com seu workspace por meio de Delta Sharing e tabelas do sistema. Por exemplo, é possível acionar um job sempre que novos registros de cobrança chegam em uma tabela do sistema, ou sempre que um provedor atualiza uma tabela compartilhada.

Você pode ativar nos seguintes objetos compartilhados:

• Tabelas do Delta Sharing
• Delta Sharing views
• views de métricas do Delta Sharing
• Visualizações materializadas do Delta Sharing
• Delta Sharing tabelas de transmissão
• System tables

Analise as limitações do trigger do Delta Sharing, em seguida, siga os passos em Adicionar um trigger de atualização de tabela e selecione as tabelas compartilhadas, views ou tabelas do sistema que você deseja monitorar.

Limitações do gatilho do Delta Sharing

• Este recurso suporta somente Databricks-to-Databricks Delta Sharing. Compartilhamento aberto não é compatível.

• Para disparar em tabelas e views compartilhadas, a versão beta deve estar habilitada tanto nos lados do destinatário quanto do provedor:

  • Triggers de Atualização de Tabela no Delta Sharing (Destinatário) : Uma versão beta em nível de workspace, habilitada no workspace do destinatário onde o trigger é criado.
  • Gatilhos de Atualização de Tabela em Delta Sharing (Provedor) : Uma versão beta em nível de account, habilitada na account do provedor que possui os dados compartilhados.

  Para tabelas de sistema, somente a beta do destinatário é necessária. Para habilitar, consulte Gerenciar Databricks previews.

• O usuário que cria o gatilho deve ter o privilégio SELECT no objeto compartilhado ou na tabela do sistema.

A atualização da tabela é acionada por eventos de arquivo

Para melhor desempenho e escalabilidade, habilite eventos de arquivo no local externo onde as tabelas estão armazenadas. Esta configuração única melhora a eficiência dos gatilhos de atualização de tabela e desbloqueia outros recursos, incluindo Auto Loader e gatilhos de chegada de arquivo de melhor desempenho.

Quando eventos de arquivo são habilitados, Databricks rastreia automaticamente metadados de ingestão usando notificações de alteração do provedor cloud , resultando em atualizações de tabela mais rápidas e eficientes.

Se suas tabelas estiverem no armazenamento de nível raiz do metastore, primeiro converta-as para um local externo e, em seguida, habilite eventos de arquivo nesse local.

Para perguntas comuns sobre eventos de arquivo, consulte Perguntas frequentes sobre eventos de arquivo.

ParâmetrosJob associados a gatilhos de atualização de tabela

Quando você usa gatilhos de atualização de tabela para um trabalho, três novas referências de valor dinâmico ficam disponíveis para uso como valores de parâmetro no trabalho.

• {{job.trigger.table_update.updated_tables}} - Uma lista JSON de tabelas atualizadas desde a última execução do Job.
• {{job.trigger.table_update.`<catalog.schema.table>`.commit_timestamp.iso_datetime}} - o carimbo de data/hora commit mais recente que desencadeou a execução do Job.
• {{job.trigger.table_update.`<catalog.schema.table>`.version}} - a versão commit mais recente que acionou a execução do Job.

Para commit_timestamp e version, há várias versões da referência de valor dinâmico. Cada tabela monitorada terá um <catalog.schema.table> com o nome totalmente qualificado da tabela para a qual você deseja dados. Se houver apenas uma tabela sendo monitorada no gatilho, você verá um valor sem o <catalog.schema.table>. Por exemplo, você pode usar {{job.trigger.table_update.commit_timestamp.iso_datetime}}.

Para obter mais informações sobre parâmetros de trabalho, consulte Parametrizar trabalho.

Receber notificações de gatilhos de atualização de tabela com falha

Para ser notificado caso um gatilho de atualização de tabela não seja avaliado, configure notificações de destino email ou sistema em caso de falha de tarefa. Consulte Adicionar notificações em um trabalho.

Limitações

Os gatilhos de atualização de tabelas têm as seguintes limitações:

• Você pode selecionar até 10 tabelas de gerenciamento ou Delta por gatilho.
• Para tabelas localizadas em áreas sem eventos de arquivo, é possível configurar no máximo 1.000 trabalhos com um gatilho de atualização de tabela.
• Um máximo de 1.000 gatilhos de atualização de tabela em objetos do Delta Sharing ou tabelas do sistema podem ser criados por workspace.

Os gatilhos na visualizaçãoUnity Catalog têm as seguintes limitações adicionais:

• Os gatilhos de atualização de tabela suportam apenas o monitoramento da visualização Unity Catalog ou da visualização de métricas que dependem de tabelas que também são suportadas por gatilhos de atualização de tabela. É importante destacar que as seguintes visualizações não são suportadas:

  • visualização que usa em read_files (eles podem ler de uma tabela suportada que lê arquivos, mas não podem usar diretamente read_files).
  • visualizações que dependem de tabelas que não estão no Unity Catalog.
  • visão que depende de tabelas federadas.

• A criação de gatilhos para views que contêm dependências não suportadas ainda é bem-sucedida, mas nenhuma execução de Job é acionada quando uma dependência não suportada é atualizada.

• Os gatilhos de atualização de tabela monitoram as alterações nas tabelas dependentes de uma view e consideram a view atualizada se alguma das tabelas dependentes for atualizada. É possível que a execução de um Job seja acionada para alterações de dados que são filtradas pela definição view .

• As tabelas de origem para uma view são contabilizadas no limite de 10 tabelas por gatilho.

  • Por exemplo, se uma view depende de 11 tabelas, não é possível usá-la em um trigger de atualização de tabela. Da mesma forma, um gatilho com duas views, cada uma das quais depende de 6 tabelas, conta como 12 tabelas.

• Existe um limite separado de 10 visualizações dependentes por view monitorada.

  • Por exemplo, se uma view depender de 11 outras views, não é possível utilizá-la em um trigger de atualização de tabela, mesmo que isso não quebre a regra de 10 tabelas por trigger.