Pular para o conteúdo principal
Última atualização em

Use a visualização materializada no Databricks SQL

Este artigo descreve como criar e refresh uma visualização materializada no Databricks SQL para melhorar o desempenho e reduzir o custo de suas cargas de trabalho de processamento e análise de dados.

O que são visões materializadas?​

No Databricks SQL, as visualizações materializadas são tabelas gerenciais Unity Catalog que armazenam fisicamente os resultados de uma consulta. Diferentemente da visualização padrão, que compute resultados sob demanda, a visualização materializada armazena em cache os resultados e os atualiza conforme as tabelas de origem subjacentes mudam, seja por programa ou automaticamente.

As visualizações materializadas são adequadas para cargas de trabalho de processamento de dados, como processamento de extração, transformação e carregamento (ETL). A visualização materializada fornece uma maneira simples e declarativa de processar dados para compliance, correções, agregações ou captura geral de dados de alterações (CDC) (CDC). A visualização materializada também permite transformações fáceis de usar, limpando, enriquecendo e desnormalizando tabelas base. Ao pré-computar consultas caras ou usadas com frequência, o Materialized visualiza menor latência de consulta e consumo de recursos. Em muitos casos, eles podem compute incrementalmente alterações de tabelas de origem, melhorando ainda mais a eficiência e a experiência do usuário final.

A seguir estão alguns casos de uso comuns para visualização materializada:

  • Manter um painel de BI atualizado com latência mínima de consulta do usuário final.
  • Reduzindo a orquestração ETL complexa com lógica SQL simples.
  • Construindo transformações complexas e em camadas.
  • Quaisquer casos de uso que exijam desempenho consistente com percepções atualizadas.

Ao criar uma view materializada em um warehouse Databricks SQL , um pipelineserverless é criado para processar a criação e a atualização da view materializada. Você pode monitorar o status das operações refresh no Catalog Explorer. Veja os detalhes da visualização com DESCRIBE EXTENDED.

Requisitos​

As visualizações materializadas criadas no Databricks SQL são apoiadas por um pipeline serverless . Seu workspace deve oferecer suporte ao pipeline serverless para usar essa funcionalidade.

Requisitos para criar ou refresh a visualização materializada:​

  • Você deve usar um SQL warehouse pro ou serverless habilitado para Unity Catalog.

  • Para refresh uma view materializada, você deve estar no workspace que a criou.

  • Para refresh incrementalmente uma view materializada de tabelas Delta , as tabelas de origem devem ter o acompanhamento de linhas habilitado.

  • O proprietário (o usuário que cria a view materializada) deve ter as seguintes permissões:

    • SELECT privilégio nas tabelas base referenciadas pela view materializada.
    • USE CATALOG e privilégios USE SCHEMA no catálogo e esquema contendo as tabelas de origem para a view materializada.
    • USE CATALOG e privilégios USE SCHEMA no catálogo de destino e esquema para a view materializada.
    • CREATE TABLE e privilégios CREATE MATERIALIZED VIEW no esquema que contém a view materializada.

  • Para refresh uma view materializada, você deve ter o privilégio REFRESH na view materializada.

Requisitos para consultar a visualização materializada:​

  • Você deve ser o proprietário da view materializada ou ter SELECT na view materializada, junto com USE SCHEMA e USE CATALOG em seus pais.
  • Você deve usar um dos seguintes recursos compute :

    • Armazém SQL

    • Interfaces de pipeline declarativas LakeFlow Spark

    • compute em modo de acesso padrão (anteriormente modo de acesso compartilhado)

    • Modo de acesso dedicado (antigo modo de acesso de usuário único) no Databricks Runtime 15.4 e acima, desde que o workspace esteja habilitado para compute serverless . Veja Controle de acesso refinado em computededicada.

      Se você for o proprietário view materializada, poderá usar um recurso compute no modo de acesso dedicado que esteja executando Databricks Runtime entre 14.3 e acima.

Para saber mais sobre outras restrições ao uso da visualização materializada, consulte Limitações.

Crie uma viewmaterializada​

As operações view materializada Databricks SQL usam um data warehouse Databricks SQL CREATE criar e carregar dados na view materializada. A criação de uma view materializada é uma operação síncrona, o que significa que o comando CREATE MATERIALIZED VIEW bloqueia até que a view materializada seja criada e o carregamento inicial de dados seja concluído. Um pipeline serverless é criado automaticamente para cada view materializada Databricks SQL . Quando a view materializada é atualizada, o pipeline processa a refresh.

Para criar uma view materializada, use a instrução CREATE MATERIALIZED VIEW . Para enviar uma instrução create, use o editor SQL na interface do usuário Databricks , a CLIDatabricks SQL ou a APIDatabricks SQL.

O usuário que cria uma view materializada é o proprietário view materializada.

O exemplo a seguir cria a view materializada mv1 a partir da tabela base base_table1:

SQL
-- This query defines the materialized view:
CREATE OR REPLACE MATERIALIZED VIEW mv1
AS SELECT
  date,
  sum(sales) AS sum_of_sales
FROM
  base_table1
GROUP BY
  date;

Ao criar uma view materializada usando a instrução CREATE OR REPLACE MATERIALIZED VIEW , a refresh e o preenchimento iniciais dos dados começam imediatamente. Isso não consome compute SQL warehouse . Em vez disso, utiliza-se um pipeline serverless para a criação e atualização subsequente.

Os comentários de coluna em uma tabela base são propagados automaticamente para a nova view materializada somente na criação. Para adicionar um programa, restrições de tabela ou outras propriedades, modifique a definição view materializada (a consulta SQL ).

A mesma instrução SQL refresh uma view materializada se for chamada posteriormente ou em um programa. Uma refresh feita dessa maneira atua como qualquer outra refresh. Para obter detalhes, consulte atualizar uma viewmaterializada.

Para saber mais sobre como configurar uma view materializada, consulte Configurar visão materializada no Databricks SQL. Para aprender sobre a sintaxe completa para criar uma view materializada, consulte CREATE MATERIALIZED VIEW. Para saber mais sobre como carregar dados em diferentes formatos e de diferentes locais, consulte Carregar dados em pipeline.

Carregar dados de sistemas externos​

A visualização materializada pode ser criada no uso externo de dados lakehouse Federation para fontes de dados suportadas. Para obter informações sobre como carregar dados de fontes não suportadas pelo Lakehouse Federation, consulte Opções de formato de dados. Para informações gerais sobre como carregar dados, incluindo exemplos, consulte Carregar dados no pipeline.

Ocultar dados confidenciais​

Você pode usar a visualização materializada para ocultar dados confidenciais de usuários que acessam a tabela. Uma maneira de fazer isso é criar a consulta de forma que ela não inclua esses dados em primeiro lugar. Mas você também pode mascarar colunas ou filtrar linhas com base nas permissões do usuário que faz a consulta. Por exemplo, você pode ocultar a coluna tax_id para usuários que não estão no grupo HumanResourcesDept. Para fazer isso, use a sintaxe ROW FILTER e MASK durante a criação da view materializada. Para mais informações, consulte Filtros de linha e máscaras de coluna.

atualizar uma viewmaterializada​

Atualizar uma view materializada atualiza a view para refletir as últimas alterações na tabela base no momento da refresh.

Quando você define uma view materializada, a instrução CREATE OR REPLACE MATERIALIZED VIEW é usada para criar a view e para refresh la para qualquer atualização agendada. Você também pode usar a instrução REFRESH MATERIALIZED VIEW para refresh a view materializada sem precisar fornecer a consulta novamente. Consulte REFRESH (MATERIALIZED VIEW ou STREAMING TABLE) para obter detalhes sobre a sintaxe SQL e os parâmetros deste comando. Para saber mais sobre os tipos de visualização materializada que podem ser atualizadas incrementalmente, consulte refresh incremental para visualização materializada.

Para enviar uma instrução de refresh , use o editor SQL na interface do usuário Databricks , um Notebook anexado a um SQL warehouse, a CLIDatabricks SQL ou a APIDatabricks SQL.

O proprietário e qualquer usuário que tenha recebido o privilégio REFRESH na tabela podem refresh a view materializada.

O exemplo a seguir atualiza a view materializada mv1 :

SQL
REFRESH MATERIALIZED VIEW mv1;

As operações são síncronas por default, o que significa que o comando bloqueia até que as operações refresh sejam concluídas. Para refresh de forma assíncrona, você pode adicionar a palavra-chave ASYNC :

SQL
REFRESH MATERIALIZED VIEW mv1 ASYNC;

Como a visualização materializada Databricks SQL é atualizada?​

A visualização materializada cria e utiliza automaticamente um pipeline serverless para processar operações refresh . A refresh é gerenciada pelo pipeline e monitorada pelo Databricks SQL Warehouse usado para criar a view materializada. A visão materializada pode ser atualizada usando um pipeline que é executado em um programador. A visualização materializada criada Databricks SQL é sempre executada no modo acionado. Consulte Modo de pipeline acionado vs. modo de pipeline contínuo.

As visualizações materializadas são atualizadas usando um dos dois métodos.

  • refreshincremental - O sistema avalia a consulta da view para identificar alterações que ocorreram após a última atualização e mesclar apenas os dados novos ou modificados.
  • refreshcompleta - Se uma refresh incremental não puder ser realizada ou não for economicamente viável, o sistema executa a consulta completa e substitui os dados existentes na view materializada pelos novos resultados.

A estrutura da consulta e o tipo de dados de origem determinam se refresh incremental é suportada. Para suportar refresh incremental, os dados de origem devem ser armazenados em tabelas Delta , com acompanhamento de linhas e feed de dados de alterações ativados. Para verificar se uma consulta é incrementalizável, use a instrução Databricks SQL EXPLAIN CREATE MATERIALIZED VIEW . Após criar uma view materializada, você pode monitorar seu comportamento refresh para verificar se ela é atualizada incrementalmente ou por meio de uma refresh completa.

Por default, Databricks usa um modelo de custo para escolher a opção mais econômica entre atualização completa e refresh incremental. Você pode substituir esse comportamento para preferir a atualização incremental ou completa definindo um REFRESH POLICY em sua definição SQL da view materializada.

Para obter detalhes sobre os tipos de refresh e como otimizar a atualização incremental, consulte refresh incremental para visualização materializada.

Atualização assíncrona​

Por default, as operações refresh são realizadas de forma síncrona. Você também pode configurar operações refresh para ocorrerem de forma assíncrona. Isso pode ser configurado usando o comando refresh com a palavra-chave ASYNC . Consulte REFRESH (MATERIALIZED VIEW ou STREAMING TABLE). O comportamento associado a cada abordagem é o seguinte:

  • Síncrono : uma refresh síncrona impede que outras operações prossigam até que a refresh seja concluída. Se o resultado for necessário para o próximo passo, como ao sequenciar operações refresh em ferramentas de orquestração como LakeFlow Jobs, use uma refresh síncrona. Para orquestrar uma visualização materializada com um Job, use o tipo tarefa SQL . Veja empregosLakeFlow.
  • Assíncrono : Uma refresh assíncrona inicia uma tarefa em segundo plano em compute serverless quando uma refresh view materializada é iniciada, permitindo que o comando retorne antes que o carregamento de dados seja concluído. Esse tipo refresh pode gerar economia de custos porque as operações não necessariamente ocupam capacidade compute no data warehouse onde o comando é iniciado. Se a refresh se tornar um paradoxo e nenhuma outra tarefa estiver em execução, o warehouse poderá ser desligado enquanto a refresh utiliza outros compute disponíveis. Além disso, o recurso de atualização assíncrona permite iniciar várias operações em paralelo.

programar atualização view materializada​

Você pode configurar uma view materializada Databricks SQL para refresh automaticamente com base em um programa definido ou para ser acionada quando os dados upstream forem alterados. A tabela a seguir mostra as diferentes opções para atualização programada.

Método

Descrição

Exemplo de caso de uso

Manual

refresh sob demanda usando uma instrução SQL REFRESH ou através da interface do usuário workspace .

Desenvolvimento, testes, atualizações pontuais.

TRIGGER ON UPDATE

Defina a view materializada para que refresh automaticamente quando os dados upstream forem alterados.

Cargas de trabalho de produção com SLAs de atualização de dados ou períodos refresh imprevisíveis.

SCHEDULE

Defina a view materializada para refresh em intervalos de tempo definidos.

Requisitos refresh previsíveis e baseados no tempo.

Tarefa SQL em um Job

A atualização é orquestrada por meio de tarefasLakeFlow.

Pipeline complexo com dependências entre sistemas.

refreshmanual​

Para refresh manualmente uma view materializada, você pode chamar uma refresh a partir do Databricks SQL ou usar a interface do usuário workspace .

Para refresh um pipeline usando Databricks SQL:

  1. No Ícone do editor de consultas. EditorSQL , execute a seguinte instrução:

    SQL
    REFRESH MATERIALIZED VIEW <mv-name>;

Para obter mais informações, consulte REFRESH (MATERIALIZED VIEW ou STREAMING TABLE).

Acionar na atualização​

A cláusula TRIGGER ON UPDATE atualiza automaticamente uma view materializada quando os dados de origem upstream são alterados. Isso elimina a necessidade de coordenar a programação em todo o pipeline. A view materializada permanece atualizada sem exigir que o usuário saiba quando o Job upstream termina ou mantenha uma lógica de programação complexa.

Essa é a abordagem recomendada para cargas de trabalho de produção, especialmente quando as dependências upstream não executam programas de forma previsível. Uma vez configurada, a view materializada monitora suas tabelas de origem e se atualiza automaticamente quando são detectadas alterações em qualquer uma das fontes upstream.

Limitações

  • Limites de dependência upstream: Uma view materializada pode monitorar no máximo 10 tabelas upstream e 30 visões upstream. Para lidar com mais dependências, divida a lógica em várias visualizações materializadas.
  • Limites do espaço de trabalho: Um máximo de 1.000 visualizações materializadas com TRIGGER ON UPDATE podem existir por workspace. Entre em contato com o suporte Databricks se precisar de mais de 1.000 visualizações materializadas.
  • Intervalo mínimo: O intervalo mínimo de ativação é de 1 minuto.

Os exemplos a seguir mostram como definir um gatilho de atualização ao definir uma view materializada.

Crie uma view materializada com gatilho na atualização.

Para criar uma view materializada que se atualiza automaticamente quando os dados de origem mudam, inclua a cláusula TRIGGER ON UPDATE na instrução CREATE MATERIALIZED VIEW .

O exemplo a seguir cria uma view materializada que agrega pedidos de clientes e é atualizada sempre que as tabelas de origem customers ou orders são atualizadas:

SQL
CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.customer_orders
  TRIGGER ON UPDATE
AS SELECT
    c.customer_id,
    c.name,
    count(o.order_id) AS order_count
FROM catalog.schema.customers c
JOIN catalog.schema.orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.name;

Frequência refresh do acelerador

Se os dados upstream forem atualizados com frequência, use AT MOST EVERY para limitar a frequência de atualização da view e limitar os custos compute . Isso é útil quando as tabelas de origem são atualizadas com frequência, mas os consumidores subsequentes não precisam de dados tempo-real. A palavra-chave INTERVAL é obrigatória antes do valor de tempo.

O exemplo a seguir limita a refresh view materializada a, no máximo, cada 5 minutos, mesmo que os dados de origem sejam alterados com mais frequência:

SQL
CREATE OR REPLACE MATERIALIZED VIEW catalog.schema.customer_orders
  TRIGGER ON UPDATE AT MOST EVERY INTERVAL 5 MINUTES
AS SELECT
    c.customer_id,
    c.name,
    count(o.order_id) AS order_count
FROM catalog.schema.customers c
JOIN catalog.schema.orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.name;

refreshprogramada​

O parâmetro refresh programar pode ser definido diretamente na definição view materializada para refresh a view em intervalos de tempo fixos. Essa abordagem é útil quando a frequência de atualização dos dados é conhecida e se deseja um tempo refresh previsível.

Quando houver uma refresh programada, você ainda poderá executar uma refresh manual a qualquer momento, caso precise de dados atualizados.

Databricks suporta duas sintaxes de programação: SCHEDULE EVERY para intervalos simples e SCHEDULE CRON para programação precisa. 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 a cláusula de programaCREATE MATERIALIZED VIEW.

Quando um programa é criado, um novo trabalho Databricks é configurado automaticamente para processar a atualização.

Para view o programa, faça um dos seguintes:

  • execute a instrução DESCRIBE EXTENDED do editor SQL na interface do usuário Databricks . Veja DESCRIBE TABLE.
  • Use o Catalog Explorer para view a view materializada. O programa está listado na tab Visão geral , em status de atualização . Veja O que é o Catalog Explorer?.

Os exemplos a seguir mostram como criar uma view materializada com um programador:

programar a cada intervalo de tempo

Este exemplo de programa executa uma refresh a cada hora:

SQL
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 de programa refresh a cada 15 minutos, no quarto de hora do fuso horário UTC:

SQL
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;

TarefaSQL em um Job​

A atualização view materializada pode ser orquestrada por meio de Jobs Databricks , criando tarefas SQL que incluam o comando REFRESH MATERIALIZED VIEW . Esta abordagem integra a atualização view materializada na orquestração do fluxo de trabalho existente.

Existem duas maneiras de criar um Job para atualizar a visualização materializada:

  • No Editor SQL : Digite o comando REFRESH MATERIALIZED VIEW e clique no botão do programador para criar um Job diretamente da consulta.
  • Na interface de trabalho Jobs : Crie um novo Job, adicione um tipo de tarefa SQL e anexe uma consulta SQL ou Notebook com o comando REFRESH MATERIALIZED VIEW .

O exemplo a seguir mostra a instrução SQL dentro de uma tarefa SQL que atualiza uma view materializada:

SQL
REFRESH MATERIALIZED VIEW catalog.schema.daily_sales_summary;

Essa abordagem é apropriada quando:

  • Um pipeline complexo com várias etapas possui dependências entre sistemas.
  • É necessária integração com orquestração de Job existente.
  • É necessário um sistema de alertas e monitoramento em nível Job .

A tarefa SQL utiliza tanto o SQL warehouse associado ao trabalho quanto o compute serverless que executa a refresh. Se o uso de programação baseada em definição view materializada atender aos requisitos, a mudança para TRIGGER ON UPDATE ou SCHEDULE pode simplificar o fluxo de trabalho.

Adicionar um programador a uma viewmaterializada existente​

Para definir o programador após a criação, use a instrução ALTER MATERIALIZED VIEW :

SQL
-- Alters the schedule to refresh the materialized view when its upstream data
-- gets updated.
ALTER MATERIALIZED VIEW sales
  ADD TRIGGER ON UPDATE;

Modificar um programador ou gatilho existente​

Se uma view materializada já tiver um programar ou gatilho associado, use ALTER SCHEDULE ou ALTER TRIGGER ON UPDATE para alterar a configuração refresh . Isso se aplica tanto à mudança de um programador para outro, de um gatilho para outro, quanto à troca entre um programador e um gatilho.

O exemplo a seguir altera um programa existente para refresh a cada 4 horas:

SQL
ALTER MATERIALIZED VIEW catalog.schema.my_view
  ALTER SCHEDULE EVERY 4 HOURS;

Solte um programador ou gatilho​

Para remover um programar, use ALTER ... DROP:

SQL
ALTER MATERIALIZED VIEW catalog.schema.my_view
  DROP SCHEDULE;

Parar uma refreshativa​

Para interromper uma refresh ativa na interface Databricks , na página de detalhes do pipeline , clique em Parar para interromper a atualização pipeline . Você também pode interromper a refresh com a CLIDatabricks ou com o comando POST /api/2.0/pipeline/{pipeline_id}/stop. operações na API do pipeline.

Tempo limite para atualização​

A atualização view materializada é executada com um tempo limite que restringe a duração de sua execução. Para visualizações materializadas criadas ou atualizadas a partir de 14 de agosto de 2025, o tempo limite é capturado quando você atualiza executando CREATE OR REFRESH:

  • Se um STATEMENT_TIMEOUT for definido, esse valor será usado. Consulte STATEMENT_TIMEOUT.
  • Caso contrário, será utilizado o tempo limite do SQL warehouse usado para a execução do comando.
  • Se o armazém não tiver um tempo limite configurado, será aplicado um default de 2 dias.

O tempo limite é utilizado na criação inicial, mas também nas atualizações agendadas subsequentes.

Para visualizações materializadas que foram atualizadas pela última vez antes de 14 de agosto de 2025, o tempo limite é definido para 2 dias.

Exemplo: Defina um tempo limite para refreshde uma view materializada. Você pode controlar explicitamente por quanto tempo uma refresh view materializada pode ser executada definindo um tempo limite no nível da instrução ao criar ou atualizar a view:

SQL
SET STATEMENT_TIMEOUT = '6h';

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 ser atualizada a cada 12 horas e, se uma refresh demorar mais de 6 horas, ela expira e aguarda a próxima refresh agendada.

Como as atualizações agendadas lidam com tempos limite​

Os tempos limite são sincronizados apenas quando você executa explicitamente CREATE OR REFRESH.

  • A atualização agendada continua usando o tempo limite capturado durante o último CREATE OR REFRESH.
  • Alterar o tempo limite do repositório de dados por si só não afeta as atualizações agendadas existentes.
importante

Após alterar o tempo limite do armazém, execute CREATE OR REFRESH novamente para aplicar o novo tempo limite à atualização agendada futura.

Excluir permanentemente registros de uma view materializada com vetores de exclusão habilitados​

info

Visualização

O suporte para a instrução REORG com visualização materializada está em Visualização Pública.

nota
  • Usar uma instrução REORG com uma view materializada requer Databricks Runtime 15.4 e acima.
  • Embora você possa usar a instrução REORG com qualquer view materializada, ela só é necessária ao excluir registros de uma view materializada com vetores de exclusão habilitados. O comando não tem efeito quando usado com uma view materializada sem vetores de exclusão habilitados.

Para excluir fisicamente registros do armazenamento subjacente para uma view materializada com vetores de exclusão habilitados, como para compliance GDPR , passos adicionais devem ser tomados para garantir que uma operação vacuum seja executada nos dados da view materializada.

Para excluir registros fisicamente:

  1. executa uma instrução REORG na view materializada, especificando o parâmetro APPLY (PURGE) . Por exemplo REORG TABLE <materialized-view-name> APPLY (PURGE);. Veja REORG TABLE.
  2. Aguarde o período de retenção de dados da view materializada passar. O período default de retenção de dados é de sete dias, mas pode ser configurado com a propriedade da tabela delta.deletedFileRetentionDuration . Consulte Configurar retenção de dados para consultas de viagem do tempo.
  3. REFRESH a view materializada. Veja Atualizar uma viewmaterializada. Dentro de 24 horas das operações REFRESH , a tarefa de manutenção pipeline , incluindo as operações VACUUM necessárias para garantir que os registros sejam excluídos permanentemente, são executadas automaticamente.

Solte uma viewmaterializada​

nota

Para enviar o comando para remover uma view materializada, você deve ser o proprietário dessa view materializada ou ter o privilégio MANAGE na view materializada.

Para descartar uma view materializada, use a instrução DROP VIEW . Para enviar uma instrução DROP , você pode usar o editor SQL na interface do usuário Databricks , a CLIDatabricks SQL ou a APIDatabricks SQL. O exemplo a seguir descarta a view materializada mv1 :

SQL
DROP MATERIALIZED VIEW mv1;

Você também pode usar o Catalog Explorer para soltar uma view materializada.

  1. Clique Ícone de dados. Catálogo na barra lateral.
  2. Na árvore do Catalog Explorer à esquerda, abra o catálogo e selecione o esquema onde sua view materializada está localizada.
  3. Abra o item Tabelas no esquema selecionado e clique na view materializada.
  4. No menu de kebab Ícone do menu de kebab., selecione Excluir .

Entenda os custos de uma viewmaterializada​

Como uma execução view materializada em compute serverless , fora da compute que você configura para um Notebook ou Job, você pode se perguntar como entender os custos associados a ela. O uso view materializada é rastreado pelo consumo DBU . Para saber mais, consulte Qual é o consumo DBU de uma view materializada ou tabela de transmissão?

Habilitando o acompanhamento de linha​

Para dar suporte à atualização incremental de tabelas Delta , o acompanhamento de linhas deve ser habilitado para essas tabelas de origem. Se você recriar uma tabela de origem, deverá reativar o acompanhamento de linhas.

O exemplo a seguir mostra como habilitar o acompanhamento de linhas em uma tabela:

SQL
ALTER TABLE source_table SET TBLPROPERTIES (delta.enableRowTracking = true);

Para obter mais detalhes, consulte Acompanhamento de linhas no Databricks

Limitações​

  • Para requisitos de compute e workspace , consulte Requisitos.
  • Para requisitos refresh incremental, consulte refresh incremental para visualização materializada.
  • A visualização materializada não suporta colunas de identidade ou chaves substitutas.
  • Se uma view materializada usar uma agregação de soma sobre uma coluna NULLe somente valores NULL permanecerem nessa coluna, o valor agregado resultante da visualização materializada será zero em vez de NULL.
  • Não é possível ler um feed de dados de alterações de uma view materializada.
  • Consultas de viagem do tempo não são suportadas na visualização materializada.
  • Os arquivos subjacentes que dão suporte à visualização materializada podem incluir dados de tabelas upstream (incluindo possíveis informações de identificação pessoal) que não aparecem na definição view materializada. Esses dados são adicionados automaticamente ao armazenamento subjacente para dar suporte à atualização incremental da visualização materializada. Como os arquivos subjacentes de uma view materializada podem correr o risco de expor dados de tabelas upstream que não fazem parte do esquema view materializada, Databricks recomenda não compartilhar o armazenamento subjacente com consumidores downstream não confiáveis. Por exemplo, suponha que a definição de uma view materializada inclua uma cláusula COUNT(DISTINCT field_a) . Embora a definição view materializada inclua apenas a cláusula agregada COUNT DISTINCT , os arquivos subjacentes conterão uma lista dos valores reais de field_a.
  • Você pode incorrer em algumas cobranças compute serverless , mesmo ao usar esses recursos em compute dedicada.

Acesse a visualização materializada de clientes externos​

Para acessar a visualização materializada de clientes externos Delta Lake ou Iceberg que não suportam APIs abertas, você pode usar Modede Compatibilidade. Mode de Compatibilidade cria uma versão somente leitura da sua view materializada que pode ser acessada por qualquer cliente Delta Lake ou Iceberg .

Artigos relacionados​