Programar refresh
Você pode refresh manualmente uma view materializada autônoma ou tabela de transmissão quando souber que as tabelas de origem foram atualizadas. No entanto, você também pode programar refresh, por tempo, quando as tabelas de origem são atualizadas ou por meio de orquestração.
Você também pode criar notificações e definir o modo de desempenho para suas refresh agendadas.
Programar
Você pode configurar um pipeline autônomo para refresh automaticamente com base em um programar definido ou para Trigger quando os dados de origem upstream forem alterados. A tabela a seguir mostra as diferentes opções para programar refresh.
Método | Descrição | Exemplo de caso de uso |
|---|---|---|
Refresh sob demanda usando um comando SQL | Desenvolvimento, testes, atualizações ad hoc. | |
Programar o pipeline para fazer o refresh automaticamente quando os dados upstream forem alterados. | Cargas de trabalho de produção com SLAs de refresh de dados ou períodos de refresh imprevisíveis. | |
Programe o pipeline para refresh em intervalos de tempo definidos. | Requisitos de refresh previsíveis e baseados em tempo. | |
O refresh é orquestrado pelo Lakeflow Jobs. | Pipelines complexos com dependências entre sistemas. |
Mesmo ao programar refreshes, você pode execução um refresh manual a qualquer momento se precisar de dados atualizados.
Refresh manual
Para fazer refresh manualmente um pipeline, você pode chamar um refresh do Databricks SQL ou usar a interface do usuário do Workspace.
- REFRESH statement
- Workspace UI
Para refresh um pipeline usando o Databricks SQL:
-
No
SQL Editor, execute a seguinte instrução:SQLREFRESH MATERIALIZED VIEW <table-name>;Para tabelas de transmissão, use
REFRESH STREAMING TABLE.
Para obter mais informações, consulte REFRESH (MATERIALIZED VIEW or STREAMING TABLE).
Para fazer refresh de um pipeline na UI do workspace:
- No workspace do Databricks, clique em
Jobs e pipelines . - Selecione o pipeline que você deseja refresh na lista.
- Clique no botão Começar .
À medida que o pipeline é refresh, você vê as atualizações na IU.
Trigger na atualização
A cláusula TRIGGER ON UPDATE refresh automaticamente um pipeline quando os dados de origem upstream são alterados. Isso elimina a necessidade de coordenar programar entre pipelines. O dataset permanece fresco sem exigir que o usuário saiba quando os jobs upstream terminam ou mantenha uma lógica de programar complexa.
Esta é a abordagem recomendada para workloads de produção, especialmente quando as dependências upstream não são execução em agendas previsíveis. Após configurar o trigger na atualização, o pipeline monitora suas tabelas de origem e refresh automaticamente quando as alterações em qualquer uma das fontes upstream são detectadas.
Limitações
- Limites de dependência upstream: Um pipeline pode monitorar um máximo de 10 tabelas upstream e 30 view upstream. Para mais dependências, divida a lógica em vários pipelines.
- Limites do Workspace: um máximo de 1.000 pipelines com
TRIGGER ON UPDATEpodem existir por workspace. Entre em contato com o suporte da Databricks se precisar de mais de 1.000. - Intervalo mínimo: o intervalo mínimo do trigger é de 1 minuto.
Os exemplos a seguir mostram como definir um trigger na atualização ao definir um pipeline.
Criar um pipeline com trigger na atualização
Para criar um pipeline que refresh automaticamente quando os dados de origem são alterados, inclua a cláusula TRIGGER ON UPDATE na instrução CREATE.
O exemplo a seguir cria uma tabela de transmissão que lê os pedidos dos clientes e os refresh sempre que a tabela de origem orders é atualizada:
CREATE OR REFRESH STREAMING TABLE catalog.schema.customer_orders
TRIGGER ON UPDATE
AS SELECT
o.customer_id,
o.name,
o.order_id
FROM catalog.schema.orders o;
Limitar a frequência de refresh
Se os dados upstream forem refresh com frequência, use AT MOST EVERY para limitar a frequência com que a view é refresh e limitar os custos de compute. Isso é útil quando as tabelas de origem são atualizadas com frequência, mas os consumidores downstream não precisam de dados tempo-real. A palavra-chave INTERVAL é necessária antes do valor de tempo.
O exemplo a seguir limita a tabela de transmissão a refresh no máximo a cada 5 minutos, mesmo se os dados de origem forem alterados com mais frequência:
CREATE OR REFRESH STREAMING TABLE catalog.schema.customer_orders
TRIGGER ON UPDATE AT MOST EVERY INTERVAL 5 MINUTES
AS SELECT
o.customer_id,
o.name,
o.order_id
FROM catalog.schema.orders o;
refresh agendada
Os programar de refresh podem ser definidos diretamente na definição do pipeline para fazer o refresh da view em intervalos de tempo fixos. Essa abordagem é útil quando a cadência de atualização de dados é conhecida e deseja-se um tempo de refresh previsível.
Quando há um programar de refresh, você ainda pode fazer uma execução de refresh manual a qualquer momento se desejar dados atualizados.
A Databricks suporta duas sintaxes de agendamento: SCHEDULE EVERY para intervalos simples e SCHEDULE CRON para agendamento preciso. As palavras-chave SCHEDULE e SCHEDULE REFRESH são semanticamente equivalentes.
Para obter detalhes sobre a sintaxe e o uso da cláusula SCHEDULE, consulte Cláusula CREATE STREAMING TABLE programar ou Cláusula CREATE MATERIALIZED VIEW programar.
Quando um programar é criado, um novo job da Databricks é configurado automaticamente para processar a atualização.
Para ver a programar, siga um destes procedimentos:
- Execute a execução do comando
DESCRIBE EXTENDEDno editor SQL da IU do Databricks. Consulte DESCRIBE TABLE. - Use o Explorador de Catálogos para view o dataset. A programar está listada na tab Visão geral , em Status da refresh . Consulte O que é o Explorador de Catálogos?.
Os exemplos a seguir mostram como criar uma view materializada com programar:
Programar cada intervalo de tempo
Este exemplo agenda um refresh a cada hora. A cláusula EVERY suporta intervalos de hora, dia e semana. Para intervalos menores que uma hora, use SCHEDULE CRON .
CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.hourly_metrics
SCHEDULE EVERY 1 HOUR
AS SELECT
date_trunc('hour', event_time) AS hour,
count(*) AS events
FROM catalog.schema.raw_events
GROUP BY 1;
Programar usando cron
Este exemplo agenda um refresh a cada 15 minutos, no quarto de hora do fuso horário UTC:
CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.regular_metrics
SCHEDULE CRON '0 */15 * * * ?' AT TIME ZONE 'UTC'
AS SELECT
date_trunc('minute', event_time) AS minute,
count(*) AS events
FROM catalog.schema.raw_events
WHERE event_time > current_timestamp() - INTERVAL 1 HOUR
GROUP BY 1;
Tarefa SQL em um job
Os refresh de pipeline podem ser orquestrados por meio do Lakeflow Jobs criando tarefas SQL que incluem comandos REFRESH. Essa abordagem integra os refreshes de pipeline à orquestração existente usando jobs.
Existem duas maneiras de criar um job para fazer refresh de tabelas de transmissão:
- No Editor SQL : escreva o comando
REFRESHe clique no botão Programar para criar um Job diretamente da query. - Na UI de Job : crie um novo Job, adicione um tipo de tarefa SQL e anexe uma query SQL ou Notebook com o comando
REFRESH.
O seguinte exemplo mostra a instrução SQL dentro de uma tarefa SQL que refresh uma tabela de transmissão:
REFRESH STREAMING TABLE catalog.schema.sales;
Para views materializadas e tabelas de transmissão autônomas, orquestrar um refresh por meio de um Job não as mantém em execução contínua. Cada execução de job realiza um único refresh acionado. A execução contínua por meio de um Job se aplica apenas aos LakeFlow Pipelines. Consulte Faça uma execução de um pipeline contínuo com um Job contínuo.
Esta abordagem é apropriada quando:
- Pipelines complexos de várias etapas têm dependências entre sistemas.
- É necessária integração com a orquestração de jobs existente.
- É necessário alerta e monitoramento em nível de job.
As tarefas SQL usam tanto o SQL Warehouse vinculado ao job quanto o compute serverless que executa o refresh. Se o uso do programar baseado na definição da tabela de transmissão atender aos requisitos, mudar para TRIGGER ON UPDATE ou SCHEDULE pode simplificar o fluxo de trabalho.
Programar um agendamento a um pipeline existente
Para definir o programar após a criação, use a instrução ALTER STREAMING TABLE ou ALTER MATERIALIZED VIEW. Por exemplo:
-- Alters the schedule to refresh the streaming table when its upstream
-- data gets updated.
ALTER STREAMING TABLE sales
ADD TRIGGER ON UPDATE;
Modificar uma programar ou um trigger existente
Se um pipeline já tiver um programar ou um trigger associado, use ALTER SCHEDULE ou ALTER TRIGGER ON UPDATE para alterar a configuração de refresh. Isso se aplica ao mudar de um programar para outro, de um trigger para outro ou ao alternar entre um programar e um trigger.
O exemplo a seguir altera programar existente para refresh a cada 5 minutos. Como a cláusula EVERY não oferece suporte a intervalos de um minuto, use uma expressão CRON para programar inferiores a uma hora:
ALTER STREAMING TABLE catalog.schema.my_table
ALTER SCHEDULE CRON '0 */5 * * * ?';
Descartar um programar ou trigger
Para remover um programar, use ALTER ... DROP:
ALTER STREAMING TABLE catalog.schema.my_table
DROP SCHEDULE;
Acompanhe o status de um refresh
Você pode consultar o status de um refresh visualizando o pipeline na interface do usuário de Pipelines ou consultando a Informação de Refresh retornada pelo comando DESCRIBE EXTENDED para o dataset.
DESCRIBE TABLE EXTENDED <table-name>;
Alternativamente, você pode view o dataset no Explorador de Catálogos e ver o status do refresh lá:
- Clique em
Catálogo na barra lateral. - Na árvore do Catalog Explorer à esquerda, abra o catálogo e selecione o esquema onde seu dataset está localizado.
- Abra o item Tabelas no esquema que você selecionou e clique na tabela de transmissão ou na view materializada.
A partir daqui, você pode usar as tab sob o nome do dataset para view e editar informações sobre o dataset, incluindo:
- Status e história de refresh
- O esquema da tabela
- Dados de exemplo (exige um compute ativo)
- Permissões
- Linhagem, incluindo tabelas e outros pipelines dos quais este dataset depende
- Percepções sobre o uso
- Monitores que você criou para este dataset
Parar um refresh ativo
Para parar um refresh ativo na interface do usuário do Databricks, na página Detalhes do pipeline , clique em Parar para parar a atualização do pipeline. Você também pode parar o refresh com o Databricks CLI ou a operação POST /api/2.0/pipelines/{pipeline_id}/stop operação na API REST do Pipelines.
Veja a história de execuções de um refresh agendado
Se você abrir seu dataset no Catalog Explorer, o painel de detalhes no lado direito do Workspace mostrará a programar de refresh . Clicar no Link da programar (por exemplo, Cada 1 hora ) leva você à página do Job para o Job (gerenciado pelo sistema) que execução a programar. Você pode ver a história de execuções, incluindo um gráfico das últimas 48 horas de execuções, incluindo sucesso ou falha e o tempo gasto. Você pode clicar em uma execução específica para obter mais detalhes.
Você não pode editar este job gerenciado pelo sistema. Para fazer alterações no programar, edite a definição do pipeline com CREATE OR REFRESH ou com ALTER. Consulte Modificar um programar ou Trigger existente.
Timeouts para refresh
Os refreshes de pipeline são uma execução com um tempo limite que limita o tempo que podem ser executados. Para pipelines independentes criados ou atualizados em ou após 14 de agosto de 2025, o tempo limite é capturado quando você atualiza executando CREATE OR REFRESH:
- Se um
STATEMENT_TIMEOUTestiver definido, esse valor será usado. Veja STATEMENT_TIMEOUT. - Caso contrário, o timeout do SQL warehouse usado para executar o comando é usado. Consulte Timeout da instrução.
- Se o warehouse não tiver um limite de tempo configurado, um default de 2 dias será aplicado.
O tempo limite é usado na criação inicial, mas também nos refresh agendados que se seguem.
Para tabelas de transmissão que foram atualizadas pela última vez antes de 14 de agosto de 2025, o tempo limite é de 2 dias.
Exemplo: definir um tempo limite para um refresh Você pode controlar explicitamente por quanto tempo um refresh pode estar em execução definindo um tempo limite no nível da instrução ao criar ou atualizar o dataset:
SET STATEMENT_TIMEOUT = 21600;
CREATE OR REFRESH MATERIALIZED VIEW my_catalog.my_schema.my_mv
SCHEDULE EVERY 12 HOURS
AS SELECT * FROM large_source_table;
Isso configura a view materializada para receber refresh a cada 12 horas e, se um refresh levar mais de 6 horas, ele atingirá o tempo limite e aguardará o próximo refresh programado.
Como os refresh agendados lidam com timeouts
Os tempos limites são sincronizados apenas quando você execução explicitamente CREATE OR REFRESH.
- Os refreshes agendados continuam usando o timeout capturado durante o
CREATE OR REFRESHmais recente. - Alterar apenas o timeout do warehouse não afeta os refreshes agendados existentes.
Depois de alterar o tempo limite do warehouse, execução CREATE OR REFRESH novamente para aplicar o novo tempo limite aos futuros refreshes agendados.
Obter notificações de refreshes agendados
Beta
Os recursos de notificações para refresh agendados de DDL estão em Beta. Os administradores do Workspace podem controlar o acesso a esse recurso na página Pré-visualizações optando pela pré-visualização Job gerenciado pelo sistema para views materializadas e tabelas de transmissão . Consulte Gerenciar prévias do Databricks.
Ao criar um programar para o pipeline, você pode editá-la para receber notificações. Há várias maneiras de programar pipelines e o recebimento de notificações depende de qual desses métodos você escolhe:
-
Agendado com um job : Para receber notificações de uma tarefa SQL no Lakeflow Jobs, edite a tarefa e adicione notificações. Veja Tarefa SQL para Job.
Você tem uma ampla gama de opções para as notificações a serem recebidas e como recebê-las. Veja Adicionar notificações em um job
-
Agendado com uma cláusula
SCHEDULE: para receber notificações de um pipeline que é agendado por uma cláusulaSCHEDULEna definição SQL, edite-o no Explorador de Catálogo:-
Abra o dataset no Catalog Explorer.
-
Na tab Visão geral , em programar de refresh, clique em
para editar a programar para a qual você deseja receber notificações. -
Em Mais opções , adicione ou modifique notificações.
Você tem a opção de ser notificado por email no começar, sucesso ou falha do refresh agendado. Por default, o proprietário é notificado apenas em caso de falha.
O email inclui um Link que leva à história de execução do Job gerenciado pelo sistema que orquestra seu programar. Consulte view a história de execuções para um refresh agendado.
-
Selecione um modo de desempenho para atualizações agendadas
O compute Serverless usado pelo pipeline é executado no modo otimizado para desempenho quando executado por meio da IU.
Para pipelines agendados na definição SQL, você pode selecionar o modo de desempenho de compute serverless usando a configuração Desempenho otimizado no Catalog Explorer. Quando essa configuração está desativada (o default), o pipeline usa o modo de desempenho default. O modo de desempenho padrão foi projetado para reduzir os custos de cargas de trabalho em que uma latência de inicialização ligeiramente maior é aceitável. Cargas de trabalho Serverless usando o modo de desempenho padrão geralmente começam dentro de quatro a seis minutos após serem Trigger, dependendo da disponibilidade de compute e de programar de forma otimizada.
Quando o desempenho otimizado está ativado, o seu pipeline é otimizado para obter desempenho, resultando em um startup e execução mais rápidos para cargas de trabalho sensíveis ao tempo.
Ambos os modos usam a mesma SKU, mas o modo de desempenho padrão consome menos DBUs, refletindo menor uso de compute.
Beta
A modificação do modo de desempenho para refresh programados está em Beta. Os administradores do Workspace podem controlar o acesso a esse recurso na página Pré-visualizações optando pela prévia do Job Gerenciado pelo Sistema para views Materializadas & Tabelas de transmissão . Consulte Gerenciar prévias do Databricks.
Por default, os pipelines usam o modo otimizado para desempenho quando em execução interativa na IU, a configuração Desempenho otimizado do Job quando programados com uma tarefa SQL e o modo padrão quando programados. Para definir o modo de compute para pipelines agendados por uma cláusula SCHEDULE na definição, edite o programar no Explorador de catálogos:
- Abra o dataset no Catalog Explorer.
- Na tab Visão geral , em programar de refresh , clique em para editar o programar que você deseja modificar.
- Marque Desempenho otimizado para usar o modo de desempenho otimizado em futuras refresh.