Use views materializadas independentes

As visualizações materializadas autônomas pré-computam e armazenam os resultados da query em cache para melhorar o desempenho e reduzir o custo das suas cargas de trabalho de processamento e análise de dados.

Você pode criar e refresh views materializadas autônomas de um warehouse do Databricks SQL ou de um Notebook em execução em compute geral serverless. Para obter detalhes sobre as diferenças entre as duas opções de compute, consulte Requisitos para pipelines autônomos.

Para criar e refresh materialized views autônomas com Python a partir de um notebook, consulte Usar Python com pipelines autônomos.

O que são visualizações materializadas autônomas?

Uma view materializada autônoma é uma tabela gerenciada pelo Unity Catalog que armazena fisicamente os resultados de uma query, definida fora de LakeFlow Pipelines. Ao contrário das views padrão, que compute os resultados sob demanda, as views materializadas armazenam em cache os resultados e os atualizam à medida que as tabelas de origem subjacentes são alteradas, seja em um programar ou automaticamente.

As visualizações materializadas são adequadas para fornecer resultados pré-computados para painéis e relatórios e para transformações que limpam, enriquecem e desnormalizam as tabelas-base. Ao pré-computar queries caras ou usadas com frequência, as visualizações materializadas reduzem a latência da query e o consumo de recursos. Em muitos casos, elas podem fazer compute de forma incremental nas alterações das tabelas de origem, melhorando ainda mais a eficiência e a experiência do usuário final.

Para cargas de trabalho de extração, transformação e carregamento (ETL) em lote que substituem periodicamente uma janela de tempo ou uma partição, como correções, dados que chegam atrasados e exclusões de compliance, use um fluxo REPLACE WHERE. Consulte Quando usar REPLACE WHERE vs. visualizações materializadas.

Os casos de uso comuns para visões materializadas são os seguintes:

• Manter um dashboard de BI atualizado com latência mínima de query do usuário final.
• Criação de transformações complexas e em camadas.
• Qualquer caso de uso que exija desempenho consistente com percepções atualizadas.

Ao criar uma view materializada em um warehouse Databricks SQL, um pipeline Serverless é criado para processar a criação e os refresh da view materializada. Você pode monitorar o status das operações de refresh no Explorador de Catálogos. Consulte view detalhes com DESCRIBE EXTENDED.

Requisitos

Para obter informações sobre opções de compute, permissões e outros requisitos para criar, fazer refresh e consultar views materializadas autônomas, consulte Requisitos para pipelines autônomos.

Para saber mais sobre outras restrições ao usar visões materializadas, consulte Limitações.

Criar uma view materializada

As operações de view materializada independente CREATE usam um Databricks SQL warehouse para 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 independente. Quando a view materializada é refresh, o pipeline processa o refresh.

Para criar uma materialized view, use a instrução view CREATE MATERIALIZED VIEW. Para enviar uma instrução de criação, use o editor SQL na interface do Databricks, a CLI do Databricks SQL ou a API do Databricks SQL.

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

Visualização materializada view

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;

view materializada no Trigger

O exemplo a seguir cria uma view materializada que é refresh automaticamente sempre que os dados de origem upstream são alterados usando TRIGGER ON UPDATE. Use esta abordagem para workloads de produção, especialmente quando as dependências upstream não são execução em programar previsíveis.

SQL

-- Refresh automatically when the source table is updated.
CREATE OR REPLACE MATERIALIZED VIEW mv_trigger
  TRIGGER ON UPDATE
AS SELECT
  date,
  sum(sales) AS sum_of_sales
FROM
  base_table1
GROUP BY
  date;

view materializada agendada

O exemplo a seguir cria uma view materializada para programar refresh CRON diário às 3:30 da manhã UTC. As expressões e os agregados na cláusula SELECT devem usar aliases. As referências de coluna GROUP BY não exigem aliases.

SQL

-- Refresh nightly at 3:30 AM UTC.
-- The cron expression uses six space-separated fields: seconds minutes hours day-of-month month day-of-week
-- Use '?' for either day-of-month or day-of-week to leave it unspecified.
CREATE OR REPLACE MATERIALIZED VIEW daily_revenue_by_region
  SCHEDULE CRON '0 30 3 * * ?' AT TIME ZONE 'UTC'
AS SELECT
  date_trunc('day', order_time) AS sales_date,
  region,
  sum(revenue) AS total_revenue,
  count(*) AS order_count
FROM
  orders
GROUP BY sales_date, region;

Para mais opções de agendamento, incluindo a sintaxe SCHEDULE EVERY e exemplos adicionais de CRON, consulte Programar refresh.

Quando você cria uma view materializada usando a instrução CREATE OR REPLACE MATERIALIZED VIEW, o refresh de dados inicial e a população começam imediatamente. Isso não consome compute de SQL warehouse. Em vez disso, um pipeline Serverless é usado para a criação e refresh subsequentes. Veja Como as views materializadas autônomas são atualizadas?.

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

A mesma declaração SQL refresh uma view materializada se chamada em um momento subsequente ou programar. Um refresh feito desta forma funciona como qualquer outro refresh. Para detalhes, consulte refresh uma materializada view.

Para saber mais sobre a configuração de uma view materializada, consulte Configurar views materializadas autônomas. Para saber mais 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 pipelines.

Carregar dados de sistemas externos

As prévias materializadas podem ser criadas em dados externos usando a Lakehouse Federation para fontes de dados compatíveis. Para obter informações sobre o carregamento de dados de fontes não compatíveis com a Lakehouse Federation, consulte Opções de formato de dados. Para obter informações gerais sobre o carregamento de dados, incluindo exemplos, consulte Carregar dados em pipelines.

Ocultar dados confidenciais

Você pode usar views materializadas para ocultar dados confidenciais de usuários que acessam a tabela. Uma maneira de fazer isso é criar a query de modo 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 está fazendo a query. Por exemplo, você pode ocultar a coluna tax_id para usuários que não estão no grupo HumanResourcesDept. Para fazer isso, use as sintaxes ROW FILTER e MASK durante a criação da view materializada. Para mais informações, consulte Filtros de linha e máscaras de coluna.

refresh de view materializada

O refresh de uma view materializada atualiza a view para refletir as alterações mais recentes na tabela base no momento do refresh.

Quando você define uma view materializada, o comando CREATE OR REPLACE MATERIALIZED VIEW é usado para criar a view e para dar refresh nas atualizações agendadas. Você também pode usar o comando REFRESH MATERIALIZED VIEW para dar refresh na view materializada sem precisar fornecer a query novamente. Consulte REFRESH (MATERIALIZED VIEW ou STREAMING TABLE) para obter detalhes sobre a sintaxe e os parâmetros SQL deste comando. Para saber mais sobre os tipos de views materializadas que podem ser atualizadas incrementalmente, consulte Refresh incremental para views materializadas.

Para enviar uma instrução de refresh, use o editor SQL na interface do Databricks, um Notebook vinculado a um SQL Warehouse, a CLI do Databricks SQL ou a API do Databricks 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 refresh a view materializada mv1:

SQL

REFRESH MATERIALIZED VIEW mv1;

A operação é síncrona por default, o que significa que o comando é bloqueado até que a operação de refresh esteja concluída. Para fazer refresh assincronamente, você pode adicionar a palavra-chave ASYNC:

SQL

REFRESH MATERIALIZED VIEW mv1 ASYNC;

Para saber como programar um refresh, consulte Programar refresh.

Como as visualizações materializadas autônomas são atualizadas?

As visualizações materializadas criam e usam automaticamente pipelines serverless para processar operações de refresh. O refresh é gerenciado pelo pipeline e a atualização é monitorada pelo Databricks SQL warehouse usado para criar a view materializada. As views materializadas podem ser atualizadas usando um pipeline que tem execução em uma programar. As visualizações materializadas autônomas têm execução apenas no modo Trigger. Consulte Modo de pipeline Trigger vs. contínuo.

Os refresh agendados podem ter notificações de atualização, e você pode definir o modo de desempenho para o refresh.

refresh incremental

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

• Refresh incremental - O sistema avalia a query da view para identificar as alterações que ocorreram após a última atualização e faz merge apenas dos dados novos ou modificados.
• refresh completo - Se um refresh incremental não puder ser realizado ou não for econômico, o sistema executa toda a query e substitui os dados existentes na view materializada pelos novos resultados.

A estrutura da query e o tipo de dados de origem determinam se o refresh incremental é suportado. Para suportar o refresh incremental, os dados de origem devem ser armazenados em tabelas Delta com o acompanhamento de linhas ativado. Ativar o feed de dados de alteração é recomendado para melhorar o desempenho do refresh incremental. Para verificar se uma query pode ser incrementada, use a instrução EXPLAIN CREATE MATERIALIZED VIEW do Databricks SQL. Depois de criar uma view materializada, você pode monitorar seu comportamento de refresh para verificar se ela foi atualizada incrementalmente ou por meio de um refresh completo.

Por default, o Databricks usa um modelo de custo para escolher a opção de melhor custo-benefício entre o refresh completo e o incremental refresh. Você pode substituir esse comportamento para preferir refresh incrementais ou completos definindo um REFRESH POLICY na definição SQL da materialized view.

Para obter detalhes sobre tipos de refresh e como otimizar para refreshes incrementais, consulte Refresh incremental para views materializadas.

Refresh assíncrono

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

• Síncrono : um refresh síncrono impede que outras operações continuem até que o refresh seja concluído. Se o resultado for necessário para o o passo, como ao sequenciar operações de refresh em ferramentas de orquestração como o Lakeflow Jobs, use um refresh síncrono. Para orquestrar prévias materializadas com um job, use o tipo de tarefa SQL . Consulte Lakeflow Jobs.
• Assíncrono : Um refresh assíncrono começa um Job em segundo plano no compute Serverless quando o refresh de uma view materializada é iniciado, permitindo que o comando retorne antes que o carregamento de dados seja concluído. Esse tipo de refresh pode economizar custos porque a operação não mantém necessariamente a capacidade de compute no warehouse onde o comando é iniciado. Se o refresh ficar parado e nenhuma outra tarefa estiver em execução, o warehouse poderá ser desligado enquanto o refresh usar outros compute disponíveis. Além disso, os refresh assíncronos suportam a inicialização de várias operações em paralelo.

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

info

Visualização

O suporte para a declaração REORG com views materializadas está em Pré-lançamento público.

nota

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

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

Para excluir fisicamente os registros:

1. execução um comando REORG na view materializada, especificando o parâmetro APPLY (PURGE). Por exemplo REORG TABLE <materialized-view-name> APPLY (PURGE);. Consulte REORG TABLE.
2. Aguarde até que o período de retenção de dados da view materializada passe. O período de retenção de dados default é de sete dias, mas pode ser configurado com a propriedade da tabela delta.deletedFileRetentionDuration. Consulte Configurar a retenção de dados para query de viagem do tempo.
3. REFRESH a view materializada. Consulte refresh uma materializada view. Dentro de 24 horas após a operação REFRESH, as tarefas de manutenção do pipeline, incluindo a operação VACUUM que é necessária para garantir que os registros sejam excluídos permanentemente, são de execução automática.

Remover uma view materializada

nota

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

Para remover uma exibição materializada, use a instrução DROP VIEW. Para enviar uma instrução DROP, você pode usar o editor SQL na interface do usuário do Databricks, a CLI do Databricks SQL ou a API do Databricks SQL. O exemplo a seguir remove a view materializada mv1:

SQL

DROP MATERIALIZED VIEW mv1;

Você também pode usar o Explorador de Catálogos para descartar uma view materializada.

1. Clique em 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 que você selecionou e clique na view materializada.
4. No menu kebab , selecione Excluir .

Entenda os custos de uma view materializada

Ao executar CREATE MATERIALIZED VIEW ou REFRESH MATERIALIZED VIEW, o Databricks cria e executa automaticamente um pipeline serverless para processar a operação. Este pipeline é independente do Databricks SQL warehouse ou recurso de compute do Databricks a partir do qual você enviou o comando. O tamanho do cluster do warehouse não limita o compute ou custo usado pelo refresh.

• O pipeline de refresh está em execução em compute Serverless e é cobrado como DBUs de LakeFlow Pipelines Serverless.
• O pipeline serverless é separado do seu warehouse. O compute do seu warehouse é usado apenas para coordenar a operação, não para realizar o processamento de dados.
• O custo escala com o volume de dados processados, não com o tamanho do seu SQL warehouse.
• Para monitorar os custos de refresh de view materializada, use tabelas do sistema. Consulte Qual é o consumo de DBU de uma view materializada ou tabela de transmissão?.
• Para exibir o pipeline subjacente que gerenciar sua view materializada:
  1. Clique em jobs e pipelines na barra lateral esquerda do seu workspace do Databricks.
  2. Clique em Tipo de pipeline . Em seguida, selecione MV/ST para ver visualizações materializadas autônomas.

nota

Você pode incorrer em cobranças de serverless compute mesmo quando o warehouse de origem usa compute dedicado.

Ativando acompanhamento de linhas

Para dar suporte a refresh incrementais de tabelas Delta, o acompanhamento de linhas deve ser ativado para essas tabelas de origem. Se você recriar uma tabela de origem, deverá reativar o acompanhamento de linhas.

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

SQL

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

Para obter mais detalhes, consulte Acompanhamento de linha no Databricks

Limitações

• Para opções de compute e requisitos de workspace, consulte Requisitos para pipelines autônomos.

• Para requisitos de refresh incremental, consulte Refresh incremental para view materializadas.

• As views materializadas não são compatíveis com colunas de identidade ou chaves substitutas.

• Se uma view materializada usar uma agregação de soma sobre uma coluna NULL-ável e apenas valores NULL permanecerem nessa coluna, o valor agregado resultante das views materializadas será zero em vez de NULL.

• Você não pode ler um feed de dados de alteração de uma view materializada, a menos que habilite o feed de dados de alteração em cada view materializada em que precisar dele. Consulte Ler um feed de dados de alteração de uma view materializada (Beta).

• Consultas de viagem do tempo não são suportadas em visualizações materializadas.

• Os arquivos subjacentes que suportam as views materializadas podem incluir dados de tabelas upstream (incluindo possível informação de identificação pessoal) que não aparecem na definição da view materializada. Esses dados são adicionados automaticamente ao armazenamento subjacente para suportar a atualização incremental de visualizações materializadas. Como os arquivos subjacentes de uma view materializada podem arriscar a exposição de dados de tabelas upstream que não fazem parte do esquema da view materializada, o Databricks recomenda o não compartilhamento do 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 da view materializada inclua apenas a cláusula agregada COUNT DISTINCT, os arquivos subjacentes contêm uma lista dos valores reais de field_a.

• Você pode incorrer em algumas cobranças de computação serverless, mesmo ao usar esses recursos em compute dedicado.

• Se você precisar usar uma conexão AWS PrivateLink com sua materialized view, entre em contato com seu representante Databricks.

Acessar views materializadas de clientes externos

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

Outros recursos

• Configurar views materializadas autônomas
• Monitorar views materializadas autônomas
• Use tabelas de transmissão autônomas