Monitorar visualizações materializadas autônomas

Monitore e faça query dos dados de refresh sobre uma view materializada independente usando o Catalog Explorer, DESCRIBE EXTENDED ou o log de eventos do pipeline.

Ver os detalhes de uma única view materializada

Você pode ver os detalhes de uma única view materializada usando o Explorador de Catálogos ou programaticamente, com a operação DESCRIBE EXTENDED. Você também pode query o log de eventos para obter detalhes da história de refresh de uma view materializada.

view detalhes no Explorador de Catálogos

Você pode acessar informações sobre sua view materializada visualizando-a no Explorador de Catálogos. No Explorador de Catálogos, você pode ver o último status de refresh e quaisquer programar de refresh criadas no SQL. Para obter detalhes sobre programar criadas no SQL, consulte CREATE MATERIALIZED VIEW.

O Explorador de Catálogos mostra detalhes de cada view materializada em um painel do lado direito, incluindo:

Status de refresh atual e hora da última execução. Para ver mais detalhes sobre a atualização, incluindo a duração da execução, erros detalhados e o tipo de refresh (incluindo se a view materializada foi atualizada total ou incrementalmente e por que), clique em Ver detalhes do refresh .
refresh programar . Se a view materializada tiver um programar definido via SQL, o programar será mostrado. Para atualizar o programar, use ALTER MATERIALIZED VIEW.
Tags . Para adicionar tags personalizadas, clique em Adicionar tags . As tags não são usadas automaticamente para atribuir custos, mas você pode criar manualmente uma query para conectar tags personalizadas aos seus custos. Para obter detalhes, consulte Atribuir custos ao SQL warehouse com tags personalizadas.

Existem propriedades da view materializada que não estão disponíveis no Explorador de Catálogos. Para essas propriedades, ou para obter as informações programaticamente, você pode usar o comando DESCRIBE EXTENDED.

view detalhes com `DESCRIBE EXTENDED`

nota

O DESCRIBE EXTENDED comando não é suportado no compute dedicado. Você deve usar compute padrão para execução DESCRIBE EXTENDED em uma view materializada.

Você pode ver detalhes sobre uma view materializada de forma programática usando o comando DESCRIBE EXTENDED. Isso inclui detalhes além do que você obtém do Catalog Explorer. Eles incluem:

O status do último refresh concluído.
A programar de refresh.
As colunas da view materializada.
O tipo de refresh da view materializada (não disponível no Explorador de Catálogos).
O tamanho dos dados da view materializada, em bytes totais (não disponível no Explorador de Catálogos).
O local de armazenamento da view materializada (não disponível no Explorador de Catálogos).
Algumas informações são incluídas apenas no resultado quando habilitadas:
- Colunas de clustering, se habilitadas.
- Se os vetores de exclusão estão ativados (somente mostrado quando true).
- Se o acompanhamento de linhas está habilitado (somente mostrado quando true).

SQL
-- As table:
DESCRIBE TABLE EXTENDED sales;

-- As a single JSON object:
DESCRIBE TABLE EXTENDED sales AS JSON;

query o log de eventos programaticamente

Para obter detalhes sobre a história de refresh de uma view materializada, ou os detalhes à medida que um refresh acontece, você pode fazer query do log de eventos programaticamente.

Como proprietário do pipeline, você pode criar uma view para permitir que outras pessoas query o log de eventos do seu pipeline. A seguinte query cria uma view que outras pessoas podem usar para consultar o log de eventos. Essa query usa a função de valor TABLE para query a tabela de log de eventos correta.

SQL
CREATE VIEW my_event_log_view AS
  SELECT *
  FROM event_log(TABLE(<catalog_name>.<schema_name>.<mv_name>));

Para fazer a query da view do log de eventos, use uma query como a seguinte.

SQL
SELECT *
  FROM my_event_log_view
  WHERE event_type = "update_progress"
  ORDER BY timestamp desc;

Para fazer a query do log de eventos diretamente como o proprietário do pipeline, você não precisa criar uma view. Você pode usar a função de valor TABLE e consultar os dados diretamente, como na seguinte query de exemplo.

SQL
SELECT *
  FROM event_log(TABLE(<catalog_name>.<schema_name>.<mv_name>))
  WHERE event_type = "update_progress"
  ORDER BY timestamp desc;

Para uma lista completa de exemplos de query usando o log de eventos, consulte Exemplos básicos de query.

Monitorar execuções de view materializada

Você pode monitorar execuções de pipeline em seu workspace usando a página Jobs & Pipelines , a página Query History ou programaticamente consultando o log de eventos. Você também pode configurar notificações para pipelines agendados.

Ver todas as execuções de view materializada na interface do usuário

Se você usar a página Jobs & Pipelines para monitorar o status de diferentes Jobs de orquestração em seu Workspace, você também poderá rastrear todas as views materializadas e tabelas de transmissão criadas lá. Cada view materializada autônoma tem um pipeline que a suporta. Para ver todas as views materializadas e tabelas de transmissão às quais você tem acesso:

Clique no botão Jobs e pipelines no lado esquerdo do seu workspace.
Clique no botão de alternância Pipelines para filtrar sua view apenas para pipelines.
Clique no botão Tipo de pipeline e selecione MV/ST para filtrar apenas para pipelines autônomos.
Clique no filtro Acessível por mim para mostrar todos os pipelines aos quais você tem acesso.

Você pode ver todas as views materializadas e tabelas de transmissão criadas em sua organização, incluindo uma view de resumo dos status de execuções recentes. Clicar no nome de um pipeline abre a página de detalhes do monitoramento do pipeline para obter mais informações. Para saber mais sobre a página de detalhes do monitoramento de pipeline, consulte Solucionar problemas de um refresh com falha.

view execuções usando a história de queries

Se você estiver mais familiarizado com a Query History tab, também poderá usá-la para view todas as execuções anteriores de todas as queries onde você tem pelo menos CAN VIEW acesso ao SQL Warehouse em execução. Você pode usar a página de história de query para acessar detalhes da query e perfis de query que podem ajudá-lo a identificar queries de baixo desempenho e gargalos no pipeline usado para a execução das atualizações da tabela de transmissão. Para obter uma visão geral do tipo de informação disponível para históricos de query e perfis de query, consulte Histórico de query e Perfil de query.

info

Visualização

Esse recurso está em Prévia Pública. Os administradores do Workspace podem controlar o acesso a esse recurso na página Pré-visualizações . Consulte Gerenciar prévias do Databricks.

Todos os comandos relacionados a materialized views aparecem no história de query. Você pode usar o filtro suspenso Comando para selecionar qualquer comando e inspecionar as queries relacionadas. Todos os comandos CREATE são seguidos por um comando REFRESH que é executado de forma assíncrona em um pipeline. Os comandos REFRESH geralmente incluem planos de query detalhados que fornecem percepções sobre a otimização do desempenho.

Para acessar comandos REFRESH na interface do usuário de história de query, siga os passos abaixo:

Clique em Query History na barra lateral esquerda.
Selecione a caixa de seleção REFRESH no filtro de dropdown Instrução .
Clique no nome da instrução da query para view detalhes de resumo, como a duração da query e as métricas agregadas.
Clique em Ver perfil da query para abrir o perfil da query. Para obter detalhes sobre como navegar no perfil da query, consulte Perfil da query.
Opcionalmente, use os links na seção Origem da query para abrir a query ou o pipeline relacionado.

Consulte CREATE MATERIALIZED VIEW.

Receba notificações de refresh agendados

info

Beta

O recurso de notificações para refreshes agendados de DDL está em Beta. Os administradores do Workspace podem controlar o acesso a esse recurso na página Pré-visualizações optando pela visualização Job gerenciado pelo sistema para views materializadas e tabelas de transmissão . Consulte Gerenciar prévias do Databricks.

Ao programar uma view materializada, você pode editá-la para receber notificações. Há várias maneiras de programar views materializadas, e o recebimento de notificações depende do método escolhido:

Agendado com um job : para receber notificações de uma tarefa SQL no Lakeflow Jobs, edite a tarefa e adicione notificações. Consulte Tarefa SQL para Job.

Você tem uma ampla gama de opções para as notificações a serem recebidas e como recebê-las. Consulte Adicionar notificações em um job
Programado com uma cláusula SCHEDULE : para receber notificações de uma view materializada que é programada por uma cláusula SCHEDULE na definição SQL, edite-a no Explorador de Catálogos:
1. Abra a view materializada no Explorador de Catálogos.
2. Na tab Visão geral , em refresh programar , clique em para editar a programar para a qual deseja receber notificações.
3. Em Mais opções , adicione ou modifique notificações.
  
  Você tem a opção de receber notificações por email no início, sucesso ou falha do refresh agendado. Por default, o proprietário é notificado apenas em caso de falha.

Solucionar problemas de um refresh com falha

Você pode localizar as atualizações com falha de views materializadas (ou tabelas de transmissão) consultando a lista de Jobs e pipeline . Para solucionar uma atualização com falha, use a página de detalhes do monitoramento de pipeline ou o log de eventos.

Para solucionar problemas de um refresh completo quando você acredita que ele deveria ser incremental, primeiro verifique se você ativou o acompanhamento de linhas para quaisquer tabelas Delta de origem. Para outros detalhes sobre refresh incremental, consulte Suporte para refresh incremental de view materializada.

Você pode obter detalhes adicionais na página de monitoramento de pipeline ou consultando o log de eventos programaticamente.

Como usar a página de monitoramento de pipeline

Para obter mais detalhes sobre uma view materializada (ou tabela de transmissão) que falhou, você pode usar a página de monitoramento de pipeline para depurar problemas. Cada view materializada tem um pipeline que lhe dá suporte. A página de monitoramento de pipeline inclui informações como:

O status da última execução e a história de execuções.
A duração da última execução.
Se a view materializada foi atualizada total ou incrementalmente. Para obter mais detalhes sobre como fazer com que sua view materializada faça um refresh incremental, consulte Suporte para refresh incremental de view materializada.
O log de eventos para uma depuração mais detalhada. No caso de sua view materializada não ter sido atualizada ou ter outros problemas, clique no painel de problemas para ver os logs com mais detalhes.

Para solucionar problemas em sua view materializada:

No seu workspace, clique no botão Jobs e pipelines na barra de navegação esquerda.
Clique no nome do seu pipeline na lista.
Se a atualização não for execução, a interface do usuário mostrará um erro (ou uma lista de erros) no painel inferior.
Clique no botão para view Logs ou clique no painel de problemas para view os erros com mais detalhes.
Isso abre a interface do usuário do registro de eventos. Cada erro tem uma mensagem e um resumo de alto nível e uma tab JSON com mais detalhes. Para corrigir um problema com o Genie Code, clique em Diagnosticar Erro .

Para obter mais detalhes sobre a página de monitoramento de pipeline, consulte aqui.

Query a história de refresh para uma view materializada

O log de eventos pode ser útil para configurar dashboards para monitorar o status ou a duração das atualizações em todo o workspace, ou se você preferir monitoramento programático em vez de usar a interface do usuário. Views materializadas autônomas não suportam salvar o log de eventos em um metastore, portanto, apenas o proprietário da view materializada pode fazer query no log de eventos diretamente.

Para ver o status das operações de REFRESH em uma view materializada, incluindo refresh atuais e passados, faça uma query no log de eventos do pipeline:

SQL
SELECT *
FROM event_log(TABLE(<fully-qualified-table-name>))
WHERE event_type = "update_progress"
ORDER BY timestamp desc;

Substitua <fully-qualified-table-name> pelo nome totalmente qualificado da view materializada, incluindo o catálogo e o esquema. Se você não for o proprietário do pipeline, talvez seja necessário primeiro criar uma view para query o log de eventos. Consulte query o log de eventos programaticamente.

Consultar o tipo de refresh que ocorreu para uma view materializada

Algumas queries podem ser atualizadas incrementalmente. Se um refresh incremental não puder ser realizado, um refresh completo será realizado.

Para ver o tipo de refresh de uma view materializada, query o log de eventos:

SQL
SELECT timestamp, message
FROM event_log(TABLE(my_catalog.my_schema.sales))
WHERE event_type = 'planning_information'
ORDER BY timestamp desc;

Exemplo de saída para este comando:

- carimbo de data/hora
- Mensagem
- 2025-03-21T22:23:16.497+00:00
- Flow 'sales' has been planned to be executed as ROW_BASED.

Atribuir custos ao SQL warehouse com tags personalizadas

Há duas formas pelas quais as tags se relacionam aos registros de cobrança para uma view materializada ou tabela de transmissão, e elas servem a propósitos diferentes:

As tags de Warehouse são herdadas automaticamente do SQL Warehouse e propagadas para a coluna custom_tags de system.billing.usage. Use-as para atribuir o custo de refresh de view materializada/tabela de transmissão ao SQL Warehouse de origem. Isso não requer joins manuais.
Tags de nível de objeto adicionadas a uma view materializada ou tabela de transmissão no Explorador de Catálogos atribuem o custo à tabela individual, para que você possa agrupar os gastos por uma dimensão que você define no próprio objeto, como equipe, projeto ou centro de custo. Essas tags não são anexadas automaticamente aos registros de cobrança. Para usá-las para atribuição de custos, join-as manualmente da tabela de sistema table_tags, conforme descrito em Join tags de nível de objeto manualmente.

Propagação automática de tags de warehouse

Uma view materializada ou tabela de transmissão no Databricks SQL entra em execução em um pipeline Serverless nos bastidores. Esse pipeline captura automaticamente as tags personalizadas do warehouse delimitador que executa a instrução, de modo que os refreshes sejam atribuídos da mesma forma que qualquer outra instrução SQL, sem necessidade de joins extras para rastrear custos de volta a um warehouse. Essas tags aparecem diretamente na coluna custom_tags de system.billing.usage.

nota

A propagação de tag de warehouse se aplica apenas a views materializadas e tabelas de transmissão cujas instruções têm execução a partir de um SQL Warehouse. Views materializadas e tabelas de streaming autônomas criadas e atualizadas com Python têm execução em compute geral serverless em vez de um SQL warehouse, portanto, não há um warehouse delimitador do qual herdar tags. Consulte Usar Python com pipelines autônomos.

O warehouse cujas tags se aplicam depende de como o refresh é acionado:

DDL refreshes herdam as tags do warehouse que executou a instrução DDL (o CREATE ou CREATE OR REPLACE que define a view materializada/tabela de transmissão).
refresh ad hoc e refresh Trigger por uma tarefa SQL do Lakeflow Jobs herdam as tags do warehouse que faz a execução dessa refresh.

Se uma política de uso Serverless e as tags do warehouse definirem a mesma key de tag, a tag da política de uso vencerá. Isso corresponde ao comportamento de resolução de conflitos de jobs serverless.

Para aplicar tag novamente a uma view materializada ou tabela de transmissão existente, faça a execução de CREATE OR REPLACE (ou CREATE OR REFRESH) a partir do warehouse cujas tags você deseja usar. Os refresh agendados selecionam essas tags.

Views materializadas e Tabelas de transmissão criadas no Databricks SQL aparecem na fatura com billing_origin_product definido como SQL e usage_metadata.dlt_pipeline_id preenchido. A query a seguir extrai tags de warehouse herdadas e uso de DBU para esses registros nos últimos 30 dias:

SQL
SELECT
  usage_metadata.dlt_pipeline_id,
  custom_tags,
  SUM(usage_quantity) AS dbus
FROM system.billing.usage
WHERE billing_origin_product = 'SQL'
  AND usage_metadata.dlt_pipeline_id IS NOT NULL
  AND usage_date >= DATEADD(day, -30, current_date)
GROUP BY ALL
ORDER BY dbus DESC;

Join tags de nível de objeto manualmente

As tags adicionadas a uma view materializada (ou tabela de transmissão) no Explorador de Catálogos não são anexadas automaticamente aos registros de faturamento, mas você pode fazer join manualmente entre elas e suas informações de faturamento em uma query.

Depois de adicionar tags a cada view materializada (ou tabela de transmissão) com o Explorador de Catálogos, você pode monitorar os custos das views materializadas juntando as tabelas do sistema table_tags e billing. Este é um exemplo de query para recuperar registros de faturamento de todas as views materializadas e tabelas de transmissão criadas com o Databricks SQL e anexar tags de nível de tabela:

SQL
SELECT
  u.*,
  tag_info.tags
FROM
  system.billing.usage u
LEFT JOIN (
  SELECT
    t.catalog_name,
    t.schema_name,
    t.table_name,
    collect_list(named_struct('tag_name', t.tag_name, 'tag_value', t.tag_value)) AS tags
  FROM
    main.information_schema.table_tags t
  GROUP BY
    t.catalog_name,
    t.schema_name,
    t.table_name
) tag_info
  ON tag_info.catalog_name = u.usage_metadata.uc_table_catalog
  AND tag_info.schema_name = u.usage_metadata.uc_table_schema
  AND tag_info.table_name = u.usage_metadata.uc_table_name
  WHERE usage_metadata.uc_table_name is not null;

Você pode usar essa mesma ideia para join tags de coluna da tabela column_tags também.

Ver os detalhes de uma única view materializada​

view detalhes no Explorador de Catálogos​

view detalhes com DESCRIBE EXTENDED​

query o log de eventos programaticamente​

Monitorar execuções de view materializada​

Ver todas as execuções de view materializada na interface do usuário​

view execuções usando a história de queries​

Receba notificações de refresh agendados​

Solucionar problemas de um refresh com falha​

Como usar a página de monitoramento de pipeline​

Query a história de refresh para uma view materializada​

Consultar o tipo de refresh que ocorreu para uma view materializada​

Atribuir custos ao SQL warehouse com tags personalizadas​

Propagação automática de tags de warehouse​

Join tags de nível de objeto manualmente​