Materialização para vistas métricas

A materialização para visualizações métricas acelera consultas ao utilizar vistas materializadas para pré-calcular agregações. Os pipelines do Lakeflow orquestram vistas materializadas definidas pelo utilizador para uma determinada vista de métricas. No momento da execução da consulta, o otimizador de consultas direciona as consultas para a melhor vista materializada, usando correspondência automática de consultas sensível a agregações (reescrita de consultas). Consultas a vista métrica como de costume, sem esforço manual adicional. O Databricks atualiza as materializações para as manter atualizadas. Também escolhe qual materialização consultar para consultas mais rápidas e a menor custo.

Como funciona a materialização

A materialização para vistas métricas envolve duas fases: definir a materialização e executar consultas sobre ela.

Fase de definição

Quando defines uma vista métrica com materialização, especificas os teus campos, medidas e calendário de atualização na vista métrica YAML. Com base nessa definição, o Databricks cria um pipeline gerido do Lakeflow que constrói e mantém as visualizações materializadas.

Isto mantém a definição da métrica separada de como é armazenada:

• A vista de métricas é um objeto do Unity Catalog que define os campos, as medidas e as junções da métrica, juntamente com a configuração de materialização (agendamento e granularidade). É a única fonte de verdade sobre o que a métrica significa.
• A pipeline materializa essa definição em uma ou mais visualizações materializadas, cada uma pré-computada para um nível de granularidade específico. O Databricks escolhe qual deles ler no momento da consulta.

Execução da consulta

Quando executa SELECT ... FROM <metric_view>, o otimizador de consultas utiliza a reescrita de consultas sensível a agregados para otimizar o desempenho:

• Caminho rápido: Lê de vistas materializadas pré-computadas quando existe uma materialização adequada.
• Caminho de recurso: Lê diretamente dos dados de origem quando não existe materialização adequada disponível.

O otimizador de consultas equilibra automaticamente o desempenho e a novidade, escolhendo entre dados materializados e de origem. Recebes resultados de forma transparente, independentemente do caminho que o otimizador utilize. Para mais informações sobre a execução de consultas contra vistas métricas, veja Visualizações métricas de consulta.

Requisitos

Para usar a materialização para vistas métricas:

• O seu espaço de trabalho deve ter computação serverless ativada para executar pipelines Lakeflow.
• Um armazém SQL ou recurso de computação em execução no Databricks Runtime 17.3 ou superior. Vistas métricas sem materialização são suportadas a partir do Databricks Runtime 16.4. Para o tempo mínimo de execução de cada funcionalidade, consulte Disponibilidade de funcionalidades na vista métrica.

Important

Não se pode materializar uma vista métrica quando a vista ou qualquer uma das suas tabelas de origem utiliza segurança ao nível de linha (RLS), máscaras de coluna ou políticas de controlo de acesso baseadas em atributos (ABAC). Como uma materialização é pré-computada uma vez usando a identidade do proprietário, servi-la a outros utilizadores contornaria os controlos de acesso por utilizador que estas funcionalidades aplicam no momento da consulta. Para mais detalhes, veja Modo de reescrita de consultas.

Referência de configuração

Configura a materialização num campo de topo materialization na definição YAML da vista métrica. Este campo define a reescrita da consulta mode (sempre relaxed), uma atualização schedule opcional e uma lista de materialized_views a manter. Cada vista materializada é ou aggregated, que pré-calcula dimensões e medidas específicas, ou unaggregated, que materializa o modelo de dados completo.

Para a especificação completa campo a campo, incluindo campos obrigatórios e opcionais, valores permitidos e as restrições das schedule cláusulas, veja Materialização.

Exemplo de definição

O exemplo seguinte define uma vista métrica com uma materialização não agregada e duas agregadas:

version: 1.1

source: prod.operations.orders_enriched_view

filter: revenue > 0

fields:
  - name: category
    expr: substring(category, 5)

  - name: color
    expr: color

measures:
  - name: total_revenue
    expr: SUM(revenue)

  - name: number_of_suppliers
    expr: COUNT(DISTINCT supplier_id)

materialization:
  schedule: every 6 hours
  mode: relaxed

  materialized_views:
    - name: baseline
      type: unaggregated

    - name: revenue_breakdown
      type: aggregated
      dimensions:
        - category
        - color
      measures:
        - total_revenue
      cluster_by:
        cols:
          - category
          - color
      partition_by:
        - category

    - name: suppliers_by_category
      type: aggregated
      dimensions:
        - category
      measures:
        - number_of_suppliers

Note

O bloco materialization usa a palavra-chave dimensions: para listar os campos a materializar, embora a definição de nível superior use fields:. As duas palavras-chave são equivalentes. Ver Campos.

A materialização revenue_breakdown utiliza cluster_by e partition_by para controlar como os dados materializados são fisicamente organizados, da mesma forma que as cláusulas CLUSTER BY e PARTITION BY numa vista materializada. Para a especificação completa do campo, veja Materialização.

Crie a vista métrica usando SQL

Para criar esta vista de métricas fora do Explorador de Catálogos, envolva o YAML em CREATE OR REPLACE VIEW ... WITH METRICS LANGUAGE YAML AS e coloque a definição entre os delimitadores $$:

CREATE OR REPLACE VIEW catalog.schema.orders_materialized WITH METRICS LANGUAGE YAML AS
$$
  version: 1.1

  source: prod.operations.orders_enriched_view

  filter: revenue > 0

  dimensions:
    - name: category
      expr: substring(category, 5)

    - name: color
      expr: color

  measures:
    - name: total_revenue
      expr: SUM(revenue)

    - name: number_of_suppliers
      expr: COUNT(DISTINCT supplier_id)

  materialization:
    schedule: every 6 hours
    mode: relaxed

    materialized_views:
      - name: baseline
        type: unaggregated

      - name: revenue_breakdown
        type: aggregated
        dimensions:
          - category
          - color
        measures:
          - total_revenue

      - name: suppliers_by_category
        type: aggregated
        dimensions:
          - category
        measures:
          - number_of_suppliers
$$

Modo de reescrita de consultas

No relaxed modo, a reescrita automática da consulta apenas verifica se as visualizações materializadas candidatas têm os campos e medidas necessários para servir a consulta.

As seguintes verificações são ignoradas:

• Atualidade: Não verifica se a materialização está atualizada.
• Definições SQL: Não verifica que as definições como TIMEZONE ou ANSI_MODE correspondam.
• Determinismo: Não verifica que os resultados materializados sejam totalmente determinísticos.

As consultas que correspondem a uma materialização utilizam a atualização mais recente. As consultas que não correspondem voltam à origem e devolvem dados em tempo real. Como resultado, a frescura dos dados pode variar dependendo se uma consulta se qualifica para reescrita. Para verificar a consistência, alinhe o seu calendário de atualização de materialização com o seu pipeline de fonte. Por exemplo, se a sua origem for atualizada diariamente com um pipeline em lote, agende atualizações da materialização para serem executadas depois de esse pipeline estar concluído. Em alternativa, utilize uma materialização não agregada para garantir que todas as consultas são lidas a partir do mesmo instantâneo.

Não se pode criar uma materialização quando a vista métrica ou qualquer uma das suas tabelas de origem utiliza:

• Segurança ao nível de linha (RLS),mascaramento ao nível de coluna (CLM) ou políticas ABAC. Os resultados pré-computados podem contornar os controlos de acesso por utilizador que deveriam ser aplicados no momento da consulta.
• Expressões dependentes do invocador, cujo resultado muda consoante quem executa a consulta (por exemplo, current_user() ou is_member()). Uma materialização é pré-computada uma vez e partilhada, por isso servi-la a um utilizador diferente devolveria resultados incorretos ou inseguros.

O Databricks valida esta restrição quando cria, altera ou atualiza uma materialização. Estas operações falham com a condição METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTED de erro (SQLSTATE 42K0E). Vê METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTED.

Tipos de materializações para vistas métricas

As secções seguintes explicam os tipos de vistas materializadas disponíveis para vistas métricas e fornecem orientações sobre a seleção da configuração adequada para as suas fontes de dados e padrões de consulta.

Tipo agregado

Este tipo pré-calcula agregações para medidas especificadas e combinações de campos para cobertura direcionada.

Use um tipo agregado quando existem combinações específicas de dimensão e medida que são frequentemente consultadas. Com materializações agregadas, aplicam-se tanto a estratégia de correspondência exata como a estratégia de correspondência por agregação, proporcionando o melhor desempenho das consultas para esses padrões.

Para agregações ótimas:

• Inclua as dimensões mais frequentemente usadas nas GROUP BY orações.
• Inclua todas as potenciais colunas de filtro (colunas usadas em WHERE no momento da consulta).
• Materialize no nível mais detalhado que as suas dúvidas precisarem. Por exemplo, uma materialização em (region, sku, event_day) pode servir todas as seguintes funções:
  • GROUP BY region
  • GROUP BY region, event_month
  • GROUP BY sku com WHERE region = 'US'
• Evite dimensões tão granulares que produzam maioritariamente grupos de uma só linha (por exemplo, uma marca temporal em bruto com precisão de milissegundos). Isto não traz qualquer benefício e infla o armazenamento.
• Fique atento a medidas não aditivas. As medidas não aditivas não podem ser reagregadas a partir de resultados parciais (por exemplo, COUNT(DISTINCT), MEDIAN e percentis) e requerem uma correspondência exata com uma materialização.

Uma única agregação só pode suportar consultas que correspondam exatamente às suas dimensões específicas (correspondência exata) ou a um subconjunto das suas dimensões (correspondência por agregação). O Databricks recomenda criar múltiplas materializações agregadas para diferentes formas de consulta.

Tipo não agregado

Este tipo materializa todo o modelo de dados não agregado (os campos source, joins, filter e fields) para uma cobertura mais ampla com menor impacto no desempenho em comparação com o tipo agregado.

Use um tipo não agregado quando algum dos seguintes pontos for verdadeiro:

• A sua visualização de métricas envolve transformações dispendiosas da origem ou junções.
• Os padrões de consulta são imprevisíveis ou variados.
• Todos os utilizadores que consultam a vista métrica devem verificar consistência nos dados.

Com materializações não agregadas, as vistas de origem dispendiosas e as junções são processadas uma única vez aquando da atualização, em vez de o serem em todas as consultas. Quando existem materializações agregadas e não agregadas, o Databricks calcula as materializações agregadas a partir da não agregada. Isto proporciona uma captura consistente e evita o recálculo redundante da origem. Uma correspondência não agregada é sempre elegível independentemente da forma da consulta, sujeita às restrições descritas no modo de reescrita da consulta.

Uma materialização não agregada não ajuda quando a fonte é uma referência direta a uma tabela sem um filtro seletivo. Nesse caso, não tem qualquer vantagem em relação a consultar diretamente a fonte.

Para orientações adicionais sobre como e quando utilizar estes tipos de materialização, consulte Escolher um tipo de materialização para vistas métricas.

Reescrita automática de consultas

Quando consulta uma vista métrica, a reescrita da consulta encaminha automaticamente a sua consulta para a melhor materialização disponível. Utiliza três estratégias de reescrita de consultas: correspondência exata, correspondência de agregação e correspondência não agregada.

A consulta é executada automaticamente na materialização otimizada em vez das tabelas base, usando este algoritmo:

1. Primeiro, o otimizador de consultas tenta uma correspondência exata.
2. Se não houver correspondência exata, o otimizador de consultas tenta uma correspondência por agregação.
3. Se não houver correspondência de rollup e existir uma materialização não agregada, o otimizador de consultas tenta uma correspondência não agregada.
4. Se não houver correspondência não agregada, a consulta é lida diretamente das tabelas de origem.

As secções seguintes explicam como funciona cada estratégia.

Note

As materializações têm de estar completas antes que a reescrita da consulta possa ter efeito.

Correspondência exata

A consulta pergunta exatamente o que foi pré-calculado na materialização. A reescrita da consulta lê o resultado armazenado sem trabalho adicional, permitindo resultados rápidos.

Para se qualificar para a correspondência exata:

• As expressões da GROUP BY consulta devem corresponder exatamente às dimensões de materialização.
• As medidas da consulta devem ser um subconjunto das medidas de materialização.

Por exemplo, uma materialização tem dimensões [region, order_date] e mede [total_revenue, order_count]. Uma consulta que agrupa por region e order_date e pede total_revenue é uma correspondência exata, porque as dimensões são as mesmas e a medida foi pré-calculada.

Combate de rolagem

A consulta pede um resumo a um nível menos detalhado do que o que foi pré-calculado. O otimizador lê o resultado pré-calculado e reagrega-o até ao nível necessário para a consulta.

Para qualificar-se para o rollup match:

• Grão mais grosso: A consulta agrupa por menos dimensões ou por uma granularidade temporal mais ampla do que a materialização.
• Todas as medidas são aditivas: Cada medida que a sua consulta pede deve ser uma que possa ser corretamente recalculada combinando resultados parciais (por exemplo, SUM de SUMs ou MAX de MAXes). MEDIAN Não pode ser enrolada porque depende da distribuição do grupo.
• Quaisquer filtros participantes devem ser expressões determinísticas: Se a sua consulta tiver uma WHERE cláusula, o filtro deve sempre produzir o mesmo resultado para a mesma entrada. Por exemplo, WHERE region = 'US' é determinista, mas expressões como ou rand()uuid() não são.

A correspondência agregada não é válida para medidas não aditivas, porque essas medidas não podem ser corretamente reagregadas a partir de resultados parciais. Ver Medidas aditivas.

Por exemplo, usando a mesma materialização com dimensões [region, order_date] e medidas [total_revenue, order_count], uma consulta que agrupa apenas por region e pede total_revenue é uma correspondência rollup. A consulta precisa de menos dimensões do que as que foram materializadas, por isso o motor agrega os totais diários em totais por região.

Note

A correspondência de rollup não está disponível quando a vista métrica usa uma one_to_many junção. Nesse caso, toda materialização volta apenas à correspondência exata . Para mais detalhes sobre junções de um para muitos, consulte junções de um para muitos.

Medidas aditivas

Uma medida é aditiva se o seu resultado agregado puder ser corretamente recalculado reagregando a partir de materializações agregadas existentes. Este é o requisito fundamental para a correspondência do rollup.

Qualquer agregado que utilize DISTINCT (por exemplo, COUNT(DISTINCT), SUM(DISTINCT)) é não aditivo e não pode ser agregado.

As seguintes funções são aditivas:

• SUM
• COUNT
• MIN
• MAX
• BIT_AND
• BIT_OR
• BIT_XOR
• BOOL_AND
• BOOL_OR

Restrições adicionais aplicam-se às medidas aditivas:

• A definição da medida deve conter exatamente uma função agregada. Uma medida cuja definição combina múltiplos agregados (por exemplo, sum(cost) + min(revenue)) não é elegível para correspondência por rollup.
• Se a definição de medida incluir uma FILTER cláusula, deve ser determinística.
• A medida não pode ser uma medida de janela (por exemplo, uma comparação total móvel de 7 dias ou uma comparação anual definida com um bloco de janela).

A tabela seguinte resume como os padrões de medida comuns correspondem aos tipos:

Padrão de medidas	Tipo de correspondência	Motivo
Agregado aditivo único (SUM, COUNT, MIN, MAX)	Elegível para o pacote cumulativo	Pode ser agregado novamente a partir de resultados parciais
COUNT(DISTINCT) ou outro agregado não aditivo	Apenas correspondência exata	Não pode ser agregado novamente
Múltiplos agregados numa única expressão (SUM(x) + MIN(y))	Apenas correspondência exata	Não é possível isolar agregados individuais para o rollup
Agregado aditivo com determinística FILTER	Elegível para o pacote cumulativo	O filtro é determinístico, o agregado é aditivo
Dimensão da janela	Apenas correspondência exata	A moldura da janela depende do grão exato

Jogo não agregado

A consulta não corresponde a nenhuma agregação pré-computada, mas o trabalho dispendioso de preparação (joins e filtros) já está feito. A reescrita da consulta começa a partir do conjunto de dados preparado da materialização não agregada, em vez de voltar às tabelas de origem.

Se existir uma materialização não agregada, esta estratégia pode ser sempre utilizada como alternativa de recurso antes de ir à origem. Qualquer forma de consulta pode usá-lo, sob reserva das restrições descritas em Modo de reescrita da consulta.

Por exemplo, a sua consulta agrupa por category e pede por unique_customers, mas nenhuma materialização agregada inclui esses campos e medidas. No entanto, existe uma materialização não agregada com o conjunto de dados integrado e filtrado pronto. O otimizador de consultas lê desse conjunto de dados preparado e executa GROUP BY category, COUNT(DISTINCT customer_id) no momento da consulta, em vez de voltar a juntar as tabelas brutas do zero.

Verifique se uma consulta está a usar vistas materializadas

Existem duas formas de verificar se uma consulta está a usar uma visualização materializada:

• Execute EXPLAIN EXTENDED na sua consulta para ver o plano da consulta. Se a materialização foi usada, o nó de folha inclui __materialization_mat_<pipeline ID>___metric_view_mat_ e o nome da materialização do ficheiro YAML.
• Veja o perfil de consultas, como mostrado abaixo.

Ciclo de vida da materialização

Esta secção explica como as materializações são criadas, geridas e atualizadas ao longo do seu ciclo de vida.

Criar e modificar

Quando cria ou modifica uma vista métrica (usando CREATE, ALTER, ou o Explorador de Catálogo), a definição da vista métrica atualiza-se imediatamente. As visualizações materializadas são atualizadas assincronamente em segundo plano através de um pipeline gerido.

Para definir uma nova materialização no editor Catalog Explorer:

1. Clique em Materializações.
2. Clique em Agendar para definir um horário. Pode selecionar um intervalo ou definir a materialização para ser executada a uma hora específica.
3. Selecione um tipo. Apenas uma materialização não agregada é permitida por vista métrica. Para mais informações, veja Tipos de materializações para vistas métricas.
4. Utilize o menu pendente Fields para selecionar os campos a incluir na materialização.
5. Utilize o menu pendente Medidas para selecionar as medidas a incluir.

Quando cria uma vista métrica, o Databricks cria um pipeline Lakeflow e agenda uma atualização inicial imediatamente se forem especificadas vistas materializadas. A visualização métrica mantém-se consultável sem materializações, recorrendo a consultas dos dados de origem.

Quando modifica uma vista métrica, o Databricks não agenda novas atualizações, a menos que esteja a ativar a materialização pela primeira vez. As visualizações materializadas não são usadas para reescrita automática de consultas até que a próxima atualização agendada esteja completa.

Alterar o calendário de materialização não desencadeia uma atualização.

Sem um agendamento, o pipeline executa uma atualização inicial na criação, mas as atualizações subsequentes têm de ser acionadas manualmente ou os dados ficam obsoletos. A Databricks recomenda sempre definir um cronograma para que os dados se mantenham atualizados, a menos que estejas a testar ou a prototipar.

Consulte atualização manual para um controlo mais preciso do comportamento da atualização.

Inspecionar pipeline subjacente

A materialização de visualizações métricas é implementada através de pipelines Lakeflow. Pode aceder ao pipeline de duas formas:

• No Explorador de Catálogo: O separador Descrição geral da vista de métrica inclui uma ligação direta sob o cabeçalho Agendamento de atualização. Para saber como aceder ao Explorador de Catálogos, veja O que é o Explorador de Catálogos?.
• Usando SQL: Execute DESCRIBE EXTENDED. A secção de Informação de Atualização contém o link do pipeline e o estado atual da atualização.

DESCRIBE EXTENDED my_metric_view;

Exemplo de saída:

-- Returns additional metadata such as parent schema, owner, access time etc.
> DESCRIBE EXTENDED my_metric_view;
                      col_name                       data_type    comment
 ------------------------------- ------------------------------ ----------
                           ...                             ...        ...

 # Detailed Table Information
                           ...                             ...

                      Language                            YAML
              Table properties                             ...
 # Refresh Information
         Latest Refresh Status                       Succeeded
                Latest Refresh                     https://...
              Refresh Schedule                   EVERY 6 HOURS

Atualização manual

A partir do link para a página do oleoduto Lakeflow, pode iniciar manualmente uma atualização do oleoduto para atualizar as materializações. Também pode ativar uma atualização manual usando o seguinte comando SQL:

REFRESH MATERIALIZED VIEW <metric-view-name>

Atualização incremental

As visualizações materializadas utilizam atualização incremental sempre que possível e apresentam as mesmas limitações das vistas materializadas padrão relativamente às fontes de dados e à estrutura do plano.

Para detalhes sobre pré-requisitos e restrições, consulte Atualização incremental para visualizações materializadas.

Billing

As vistas materializadas refrescantes acarretam custos de utilização dos oleodutos Lakeflow. Para encontrar o consumo de DBU do pipeline, consulte Qual é o consumo de DBU de um pipeline serverless?.

Restrições conhecidas

As seguintes restrições aplicam-se à materialização para vistas métricas:

• Não se pode materializar uma vista métrica que defina parâmetros.
• Depois de criar uma materialização para uma visualização de métricas, não é possível alterar o proprietário.
• O Databricks não suporta a propriedade de grupos das vistas métricas materializadas.
• Apenas a estratégia de correspondência exata é elegível para visualizações métricas com junções um-para-muitas.
• A materialização schedule não suporta a cláusula TRIGGER ON UPDATE.