Refresh incremental para views materializadas

Este artigo descreve a semântica e os requisitos para refresh incrementais em views materializadas, e identifica as operações SQL, palavras-chave e cláusulas que suportam o refresh incremental. Inclui uma discussão sobre as diferenças entre atualizações incrementais e completas, além de recomendações para a escolha entre visualizações materializadas e tabelas de streaming.

Para uma visão geral de como os pipelines são atualizados, consulte Como os pipelines são atualizados?.

Ao executar atualizações em views materializadas com pipelines serverless, muitas consultas podem ser atualizadas de forma incremental. Refreshes incrementais economizam custos de compute ao detectar alterações nas fontes de dados usadas para definir a view materializada e ao fazer compute do resultado de forma incremental.

Atualiza execução no compute serverless

Operações de refresh são executadas em pipelines serverless, independentemente de a operação ter sido definida como autônoma ou com LakeFlow Spark Declarative Pipelines.

Para views materializadas autônomas, seu workspace não precisa estar habilitado para Serverless Lakeflow Spark Declarative Pipelines. O refresh usará um pipeline serverless automaticamente.

Para views materializadas definidas usando Lakeflow Spark Declarative Pipelines, é preciso configurar o pipeline para usar serverless. Consulte Configurar um pipeline serverless.

Quais são as semânticas de refresh para views materializadas?

As visualizações materializadas garantem resultados equivalentes às consultas em lote. Por exemplo, considere a seguinte consulta agregada:

SQL

SELECT account_id,
  COUNT(txn_id) txn_count,
  SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id

Ao executar esta consulta usando qualquer produto Databricks, o resultado é calculado usando semântica de lote para agregar todos os registros na fonte transactions_table, o que significa que todos os dados de origem são verificados e agregados em uma única operação.

nota

Alguns produtos Databricks armazenam resultados em cache automaticamente dentro ou entre sessões se as fontes de dados não foram alteradas após a última execução da query. Os comportamentos de cache automático diferem das visualizações materializadas.

O exemplo a seguir converte esta consulta em lote em uma view materializada:

SQL

SQL

CREATE OR REPLACE MATERIALIZED VIEW transaction_summary AS
SELECT account_id,
  COUNT(txn_id) txn_count,
  SUM(txn_amount) account_revenue
FROM transactions_table
GROUP BY account_id

Python

Python

@dp.materialized_view()
def transaction_summary():
  return (spark.read.table("transactions_table")
    .groupBy("account_id")
    .agg(
      count("*").alias("txn_count"),
      sum("txn_amount").alias("account_revenue")
    )
  )

Ao refresh uma view materializada, o resultado compute é idêntico à semântica da consulta de lotes. Esta query é um exemplo de uma view materializada que pode ser incrementalmente refresh, significando que a operação de refresh faz um esforço para processar apenas dados novos ou alterados na origem transactions_table para compute os resultados.

Considerações de fonte de dados para visualizações materializadas

Embora seja possível definir uma view materializada para qualquer fonte de dados, nem todas as fontes de dados são adequadas para views materializadas. Considere as seguintes ressalvas e recomendações:

importante

Visualizações materializadas fazem o possível para incrementalmente refresh os resultados para operações com suporte. Algumas alterações em fontes de dados exigem um refresh completo. É possível definir uma política de refresh que falhe em vez de executar um refresh completo.

Todas as fontes de dados para views materializadas devem ser robustas à semântica de refresh completa, mesmo que a consulta que define a view materializada suporte refresh incremental.

• Para consultas em que um refresh completo seria de custo proibitivo, utilize tabelas de transmissão para garantir o processamento de uma única vez. Exemplos incluem tabelas muito grandes.

• Não se deve definir uma visualização materializada contra uma fonte de dados se os registros devem ser processados apenas uma vez. Em vez disso, use tabelas de transmissão. Exemplos incluem o seguinte:

  • Fontes de dados que não retêm histórico de dados, como o Kafka.
  • Operações de ingestão, como consultas que usam o Auto Loader para ingerir dados do armazenamento de objetos na cloud.
  • Qualquer fonte de dados onde você planeja excluir ou arquivar dados após o processamento, mas precisa reter informações em tabelas downstream. Por exemplo, uma tabela particionada por data em que você planeja excluir registros com mais tempo do que um determinado limite.

• Nem todas as fontes de dados suportam refresh incremental. As seguintes fontes de dados suportam refresh incremental:

  • Tabelas Delta, incluindo tabelas do Unity Catalog gerenciadas e tabelas externas apoiadas pelo Delta Lake.
  • Visualizações materializadas.
  • Tabelas de transmissão, incluindo os alvos de AUTO CDC ... INTO operações.
  • Tabelas Iceberg gerenciadas pelo Unity Catalog (v2 e v3). Iceberg v3 é recomendado para o melhor suporte para refresh incremental. Veja Usar recursos do Apache Iceberg v3. Tabelas Iceberg externas não são suportadas.

• Algumas operações de refresh incremental exigem que o acompanhamento de linhas esteja ativado nas fontes de dados consultadas. O acompanhamento de linhas é um recurso do Delta Lake compatível apenas com tabelas Delta, que incluem views materializadas, tabelas de transmissão e tabelas gerenciadas do Unity Catalog. Consulte acompanhamento de linhas no Databricks.

• Fontes de dados com filtros de linha ou máscaras de coluna definidos não suportam refresh incremental. Consulte filtros de linha e máscaras de coluna

Otimizar visualizações materializadas

Para obter o melhor desempenho, a Databricks recomenda habilitar os seguintes recursos em todas as tabelas de origem de views materializadas:

• Vetores de deleção
• Acompanhamento de linha
• Alterar feed de dados

Você pode definir esses recursos durante a criação, ou posteriormente com a instrução ALTER TABLE (executada no Databricks SQL). Por exemplo:

SQL

ALTER TABLE <table-name> SET TBLPROPERTIES (
  delta.enableDeletionVectors = true,
  delta.enableRowTracking = true,
  delta.enableChangeDataFeed = true);

Refresh types para visualizações materializadas

Quando uma materialized view é atualizada, é possível especificar um refresh ou um refresh completo.

• Um refresh tenta fazer uma atualização incremental, mas recalculará os dados completamente se necessário. O refresh incremental só está disponível quando o compute ao qual está conectado é serverless.
• Um refresh completo sempre recalcula todas as entradas para a visualização materializada e redefine todos os pontos de verificação.

Para determinar qual tipo de refresh uma atualização utilizou, consulte Determine o tipo de refresh de uma atualização.

default refresh

A atualização default para uma visualização materializada em serverless tenta realizar um refresh incremental . Uma atualização incremental processa alterações nos dados subjacentes após a última atualização e, em seguida, anexa esses dados à tabela. Dependendo das tabelas base e das operações incluídas, apenas certos tipos de visualizações materializadas podem ser atualizadas incrementalmente. Se um incremental refresh não for possível ou se o compute conectado for clássico em vez de serverless, um recálculo completo será realizado.

nota

Databricks aplica um refresh completo ou incremental. A decisão baseia-se em qual opção é mais econômica e se uma query oferece suporte a refresh incremental. Para alterar esse comportamento, consulte política de refresh.

O resultado de uma incremental refresh e um recompute completo são os mesmos. Databricks executa uma análise de custo para escolher a opção mais barata entre um refresh incremental e um recompute completo.

Apenas as views materializadas atualizadas usando pipelines serverless podem usar refresh incremental. As visualizações materializadas que não utilizam pipelines serverless são sempre totalmente recalculadas.

Ao criar visualizações materializadas com um SQL Warehouse ou Lakeflow Spark Declarative Pipelines serverless, o Databricks as atualiza incrementalmente se suas consultas forem suportadas. Se uma consulta utiliza expressões não suportadas, o Databricks executa um recálculo completo, o que pode aumentar os custos.

Para determinar qual tipo de refresh uma atualização utilizou, consulte Determine o tipo de refresh de uma atualização.

Refresh completo

O refresh completo sobrescreve os resultados na visualização materializada, limpando a tabela e os pontos de verificação, e reprocessando todos os dados disponíveis na origem.

Para realizar um full refresh em visualizações materializadas definidas usando Databricks SQL, utilize a seguinte sintaxe:

SQL

REFRESH MATERIALIZED VIEW mv_name FULL

Para views materializadas definidas em Lakeflow Spark Declarative Pipelines, é possível optar por executar um refresh completo em datasets selecionados ou em todos os datasets em um pipeline. Consulte a semântica de refresh do pipeline.

importante

Quando uma atualização completa é executada em uma fonte de dados onde os registros foram removidos devido ao limite de retenção de dados ou exclusão manual, os registros removidos não são refletidos nos resultados computados. Pode não ser possível recuperar dados antigos se os dados não estiverem mais disponíveis na origem de dados. Isso também pode alterar o esquema para as colunas que não existem mais nos dados de origem.

Suporte para atualização incremental de visualização materializada

A tabela a seguir lista o suporte para refresh incremental por palavra-chave SQL ou cláusula. Para testar uma consulta específica quanto à incrementalidade, você pode usar EXPLAIN CREATE MATERIALIZED VIEW.

importante

Algumas palavras-chave e cláusulas exigem que o acompanhamento de linha seja ativado nas fontes de dados consultadas. Consulte Acompanhamento de linha no Databricks.

Essas palavras-chave e cláusulas estão marcadas com um asterisco (*) na tabela a seguir.

Palavra-chave ou cláusula SQL	Equivalente ao DataFrame PySpark	Suporte para refresh incremental
SELECT expressões*	df.select() ou df.selectExpr()	Sim, expressões incluindo funções integradas determinísticas e funções definidas pelo usuário (UDFs) imutáveis são suportadas.
GROUP BY	df.groupBy().agg()	Sim
WITH	Encadeamento de variáveis de DataFrame.	Sim, expressões de tabela comuns são suportadas.
WITH RECURSIVE	N/A	Não. Views materializadas que usam CTEs recursivas não são elegíveis para refresh incremental e retornam para uma recomputação completa.
UNION ALL*	df.union ou df.unionAll	Sim
FROM	df = spark.read...	As tabelas base compatíveis incluem tabelas Delta, tabelas Iceberg gerenciadas do Unity Catalog, views materializadas e tabelas de transmissão.
WHERE, HAVING*	df.filter(), df.where(), df.groupBy().filter()	Cláusulas de filtro como WHERE e HAVING têm suporte.
INNER JOIN*	df.join()	Sim
LEFT OUTER JOIN*	df.join(... how="left")	Sim
FULL OUTER JOIN*	df.join(... how="full")	Sim
RIGHT OUTER JOIN*	df.join(... how="right")	Sim
OVER	df.over(window.partitionBy) Funções	Sim. PARTITION_BY colunas devem ser especificadas para incrementalização em funções de janela.
QUALIFY	df.over(w).filter(...)	Sim
EXPECTATIONS	@dp.expect	Sim, views materializadas que incluem expectativas podem ser atualizadas incrementalmente. No entanto, o refresh incremental não é suportado para os seguintes casos: Quando a visualização materializada lê de uma view que contém expectativas. Quando a view materializada tiver uma expectativa de DROP e incluir NOT NULL colunas em seu esquema.
UDFs	UDFs	A Databricks procura detectar quando uma UDF altera seu comportamento e realizar um full refresh. No entanto, UDFs que chamam outras funções ou bibliotecas podem alterar o comportamento de maneiras que o Databricks não reconhece. Quando o comportamento de uma UDF for alterado, é de sua responsabilidade realizar um refresh completo para aplicar a UDF atualizada à view materializada completa.
Funções não determinísticas	Funções não determinísticas	Funções de tempo não determinísticas têm suporte em WHERE cláusulas. Isso inclui funções como current_date(), current_timestamp() e now(). Outras funções não determinísticas não são suportadas.
Fontes não compatíveis	Fontes não compatíveis	Fontes como volumes, locais externos e catálogos externos não são suportadas. Tabelas Iceberg externas não são suportadas. Tabelas Iceberg gerenciadas pelo Unity Catalog são compatíveis.

Determinar o tipo de refresh de uma atualização

Para otimizar o desempenho de refresh de visualizações materializadas, o Databricks usa um modelo de custo para selecionar a técnica usada para o refresh. A tabela a seguir descreve estas técnicas:

Técnica	Atualização incremental?	Descrição
FULL_RECOMPUTE	Não	A visão materializada foi totalmente recalculada.
NO_OP	Não aplicável	A visualização materializada não foi atualizada porque nenhuma alteração na tabela base foi detectada.
Qualquer um de: ROW_BASED PARTITION_OVERWRITE WINDOW_FUNCTION APPEND_ONLY GROUP_AGGREGATE GENERIC_AGGREGATE	Sim	A view materializada foi atualizada incrementalmente usando a técnica especificada.

Consulte também política de refresh.

Para determinar a técnica utilizada, consulte o log de eventos do Lakeflow Spark Declarative Pipelines onde o event_type é planning_information:

SQL

SELECT
  timestamp,
  message
FROM
  event_log(TABLE(<fully-qualified-table-name>))
WHERE
  event_type = 'planning_information'
ORDER BY
  timestamp desc;

Substitua <fully-qualified-table-name> pelo nome totalmente qualificado da view materializada, incluindo o catálogo e o esquema.

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 in :re[LDP] to be executed as ROW_BASED.

Consulte o log de eventos do Pipeline.

Política de refresh

Por default, a Databricks seleciona automaticamente a estratégia de refresh mais econômica (incremental ou completa), com base na estrutura da consulta, no volume de alteração de dados e na modelagem de custos do sistema. Esse comportamento default otimiza o desempenho de refresh sem a necessidade de configuração manual.

Algumas cargas de trabalho, no entanto, requerem um comportamento de refresh mais previsível ou explicitamente controlado. Para dar suporte a esses cenários, você pode especificar um REFRESH POLICY na definição da visualização materializada. Uma política de refresh controla se o Databricks realiza incremental refresh, quando pode recorrer a um full refresh, e se um refresh deve falhar em vez de realizar um recálculo completo.

Usando REFRESH POLICY, você pode configurar o sistema para:

• AUTO (default) - Usar seleção automática com base em custo. O Databricks escolhe a atualização incremental ou completa com base na eficiência e nas funcionalidades de consulta. Recomendado para a maioria dos usuários.
• INCREMENTAL - Prefira refresh incremental. Databricks executa refresh incremental sempre que possível. Recorre a um refresh completo se o plano de consulta não suportar mais o refresh incremental.
• INCREMENTAL STRICT - Exigir estritamente refresh incremental. Incremental refresh é necessária durante a operação normal. Se a incrementalização não for possível, a operação de refresh ou criação falhará.
• FULL - Sempre realize refresh completo. Databricks nunca executa refresh incremental, mesmo quando a consulta é incrementalizável.

SQL

SQL

-- Create a materialized view with an incremental refresh policy
CREATE MATERIALIZED VIEW IF NOT EXISTS my_mv
REFRESH POLICY INCREMENTAL
AS SELECT a, sum(b) FROM my_catalog.example.my_table GROUP BY a;

Python

Python

from pyspark import pipelines as dp

@dp.materialized_view(
  refresh_policy = 'incremental_strict'
)
def my_mv():
  return spark.read("main.default.source_table")

A política ideal de refresh depende das características da carga de trabalho:

• AUTO é apropriado para a maioria das cargas de trabalho. Ele equilibra custo e desempenho e se adapta automaticamente quando o comportamento da consulta muda.
• INCREMENTAL É útil quando o refresh incremental oferece benefícios, mas é aceitável para o Databricks realizar refreshes completos quando a incrementalização se torna temporariamente indisponível (como quando o acompanhamento de linhas em uma tabela de origem é desativado).
• INCREMENTAL STRICT Deve ser usado quando o refresh incremental for necessário para atender a restrições de custo, desempenho ou SLA, e atualizações completas inesperadas são inaceitáveis. Esta política é recomendada quando os usuários preferem que a atualização falhe, permitindo que eles depurem o problema em vez de prosseguir com um refresh completo.
• FULL é adequado quando o refresh incremental oferece pouco benefício, o dataset é pequeno, ou a estrutura da query muda frequentemente de maneiras que impedem a incrementalização.

Para mais detalhes e sintaxe, consulte cláusula REFRESH POLICY (pipelines), ou se o dataset for definido no Databricks SQL, cláusula REFRESH POLICY.