Materialização para visão de Métis

info

Pré-lançamento público

Esse recurso está em Prévia Pública.

A materialização para views de métricas acelera consultas ao usar visualizações materializadas para pré-computar agregações. Lakeflow Spark Declarative Pipelines coordena visualizações materializadas definidas pelo usuário para uma determinada view de métricas. No momento da consulta, o otimizador de consultas direciona as consultas para a melhor visão materializada usando correspondência de consultas automática com reconhecimento de agregações (reescrita de consultas). Consulta-se a view de métricas como de costume, sem esforço manual adicional. A Databricks atualiza as materializações para mantê-las em dia e escolhe qual materialização consultar para consultas mais rápidas e com menor custo.

Como funciona a materialização

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

Fase de definição

Quando você define uma view de métrica com materialização, você especifica seus campos, medidas e programação de refresh no YAML da view de métrica. A partir dessa definição, a Databricks cria um Pipeline Declarativo gerenciado do Lakeflow Spark que constrói e mantém as views materializadas.

Isso mantém a definição da métrica separada de como ela é armazenada.

• A view de métrica é um objeto do Unity Catalog que define os campos, medidas e joins da métrica, juntamente com a configuração de materialização (programação e granularidade). É a única fonte de verdade para o significado da métrica.
• O pipeline materializa essa definição em uma ou mais visualizações materializadas, cada uma pré-calculada em uma granularidade específica. O Databricks escolhe qual ler no momento da consulta.

Execução de consulta

Quando você executa SELECT ... FROM <metric_view>, o otimizador de consultas usa a reescrita de consultas com reconhecimento de agregação para otimizar o desempenho:

• Caminho rápido : Lê a partir da visão materializada pré-computada quando existe uma materialização adequada.
• Caminho alternativo : Lê diretamente dos dados de origem quando nenhuma materialização adequada está disponível.

O otimizador de consultas equilibra automaticamente o desempenho e a atualização dos dados ao escolher entre dados materializados e de origem. Os resultados são recebidos de forma transparente independentemente do caminho que o otimizador utiliza. Para obter mais informações sobre como executar consultas em views de métricas, consulte Consultar views de métricas.

Requisitos

Para usar a materialização na visualização de métricas:

• Seu workspace deve ter compute serverless habilitada. Isso é necessário para a execução do pipeline declarativo LakeFlow Spark .
• Um SQL warehouse ou recurso compute executando Databricks Runtime 17.3 ou superior.

Referência de configuração

Você configura a materialização em um campo de nível superior materialization na definição YAML da view de métricas. Este campo define a reescrita da consulta mode (sempre relaxed), um refresh opcional schedule e uma lista de materialized_views para manter. Cada view materializada é aggregated (pré-computa dimensões e medidas específicas) ou unaggregated (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 da cláusula schedule, consulte Materialização.

Definição de exemplo

O exemplo a seguir define uma visualização de métrica com uma materialização não agregada e duas agregadas:

YAML

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

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

Modo de reescrita de consultas

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

As seguintes verificações serão ignoradas:

• Atualização : não verifica que a materialização esteja atualizada.
• Configurações de SQL : não verifica se as configurações, como TIMEZONE ou ANSI_MODE, correspondem.
• Determinismo : Não se verifica que os resultados materializados sejam totalmente determinísticos.

Consultas que correspondem a uma materialização usam o último refresh. Consultas que não encontram correspondência recorrem à origem e retornam dados em tempo real. Como resultado, a atualização constante dos dados pode variar dependendo se uma query se qualifica para reescrita. Para verificar a consistência, o agendamento de refresh da materialização deve ser alinhado com o pipeline de origem. Por exemplo, se sua fonte for atualizada diariamente com um pipeline de lotes, programe atualizações de materialização para serem executadas após a conclusão desse pipeline. Alternativamente, utilize uma materialização não agregada para garantir que todas as consultas leiam do mesmo Snapshot.

Não é possível criar uma materialização quando a view de métricas ou qualquer uma de suas tabelas de origem usar:

• Segurança em nível de linha (RLS), mascaramento em nível de coluna (CLM) ou políticas ABAC. Resultados pré-computados podem ignorar controles de acesso por usuário que devem ser impostos no momento da consulta.
• Expressões dependentes do invocador, cujo resultado muda com base em quem executa a consulta (por exemplo, current_user() ou is_member()). Uma materialização é pré-computada uma vez e compartilhada, portanto, entregá-la a um usuário diferente retornaria resultados incorretos ou inseguros.

A Databricks valida essa restrição quando você cria, altera ou refresh uma materialização. Essas operações falham com a condição de erro METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTED (SQLSTATE 42K0E). Consulte METRIC_VIEW_MATERIALIZATION_WITH_INVOKER_DEPENDENT_EXPRESSIONS_NOT_SUPPORTED.

Tipos de materializações para visualizações de métricas

As seções a seguir explicam os tipos de visualizações materializadas disponíveis para views de métricas e fornecem orientação sobre a seleção da configuração apropriada para suas fontes de dados e padrões de consulta.

Tipo agregado

Esse tipo faz pré-compute em agregações para combinações especificadas de medidas e campos para cobertura direcionada.

Utilize um tipo agregado quando houver combinações específicas de dimensão e medida que são consultadas frequentemente. Com materializações agregadas, aplicam-se tanto as estratégias de correspondência exata quanto as de correspondência de rollup, proporcionando o melhor desempenho de consulta para esses padrões.

Para agregações ótimas:

• Inclua as dimensões mais usadas nas cláusulas GROUP BY.

• Inclua quaisquer colunas de filtro em potencial (colunas usadas em WHERE no momento da consulta).

• Materialize no nível de detalhe mais alto que suas consultas exigem. Por exemplo, uma materialização em (region, sku, event_day) pode atender a todos os itens a seguir:

  • GROUP BY region
  • GROUP BY region, event_month
  • GROUP BY sku com WHERE region = 'US'

• Evite dimensões tão granulares que produzam principalmente grupos de linha única (por exemplo, um carimbo de data/hora bruto com precisão de milissegundos). Isso não tem benefício e infla o armazenamento.

• Observe as medidas não aditivas. Medidas não aditivas não podem ser reagregadas a partir de resultados parciais (por exemplo, COUNT(DISTINCT), MEDIAN, e percentis) e exigem uma correspondência exata com uma materialização.

Uma única agregação pode atender somente a consultas que correspondam às suas dimensões específicas (correspondência exata) ou a um subconjunto de suas dimensões (correspondência de agregação). O Databricks recomenda a criação de várias materializações agregadas para diferentes formatos de consulta.

Tipo não agregado

Esse tipo materializa o modelo de dados não agregado completo (os campos source, joins, filter e fields) para maior cobertura com menor ganho de desempenho em comparação com o tipo agregado.

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

• Sua view de métricas envolve transformações de origem ou joins custosos.
• Padrões de query são imprevisíveis ou diversos.
• Todos os usuários que consultam a view de métricas devem ver consistência nos dados.

Com materializações não agregadas, visualizações de origem e junções custosas são computadas uma única vez durante o refresh, em vez de a cada consulta. Quando as materializações agregadas e não agregadas existirem, a Databricks computa as materializações agregadas a partir da não agregada. Isso fornece um snapshot consistente e evita a recomputação redundante da fonte. Uma correspondência não agregada é sempre elegível independentemente do formato da query, sujeita às restrições descritas em Modo de reescrita de query.

Uma materialização não agregada não ajuda quando a origem é uma referência direta de tabela sem um filtro seletivo. Nesse caso, não apresenta nenhum benefício em relação a consultar a origem diretamente.

Para obter orientação adicional sobre como e quando usar esses tipos de materialização, consulte Escolha um tipo de materialização para view de métricas.

Reescrita automática de consultas

Ao consultar uma view de métricas, a reescrita de consulta direciona automaticamente sua consulta para a melhor materialização disponível. Ele usa três estratégias de reescrita de query: correspondência exata, correspondência de rollup e correspondência não agregada.

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

1. Primeiro, o otimizador de query tenta correspondência exata.
2. Se não houver correspondência exata, o otimizador de query tenta uma correspondência de rollup.
3. Se não houver correspondência de rollup e existir uma materialização não agregada, o otimizador de query tentará uma correspondência não agregada.
4. Se não houver correspondência não agregada, a query lê diretamente das tabelas de origem.

As seções a seguir explicam como cada estratégia funciona.

nota

A materialização deve ser concluída antes que a reescrita da consulta entre em vigor.

correspondência exata

A query solicita exatamente o que foi pré-computado na materialização. A reescrita de consulta lê o resultado armazenado sem trabalho adicional, possibilitando resultados rápidos.

Para se qualificar para correspondência exata:

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

Por exemplo, uma materialização tem dimensões [region, order_date] e medidas [total_revenue, order_count]. Uma query 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.

Correspondência de agregação

A query pede um resumo em um nível mais grosseiro do que foi pré-computado. O otimizador lê o resultado pré-computado e o reagrega até o nível necessário para a query.

Para se qualificar para rollup match:

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

A correspondência de rollup não é elegível para medidas não aditivas, porque elas não podem ser corretamente reagregadas a partir de resultados parciais. Consulte Medidas Aditivas.

Por exemplo, ao usar a mesma materialização com dimensões [region, order_date] e medidas [total_revenue, order_count], uma consulta que agrupa somente por region e solicita total_revenue é uma correspondência de rollup. A query precisa de menos dimensões do que foi materializado, portanto o mecanismo agrega os totais diários em totais de nível regional.

Medidas aditivas

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

Qualquer agregação usando DISTINCT (por exemplo, COUNT(DISTINCT), SUM(DISTINCT)) não é aditiva e não pode ser resumida.

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 a medidas aditivas:

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

Partida não agregada

A consulta não corresponde a nenhuma agregação pré-computada, mas o trabalho preparatório caro (junções e filtros) já foi feito. A reescrita da consulta começa a partir do dataset preparado da materialização não agregada, em vez de retornar às tabelas de origem.

Se uma materialização não agregada existir, essa estratégia será sempre elegível como fallback antes de ir para a origem. Qualquer formato de query pode usá-lo, sujeito às restrições descritas em Modo de reescrita de query.

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

Verificar se uma query utiliza visualizações materializadas

Há duas maneiras de verificar se uma consulta está usando uma visualização materializada:

• Executar EXPLAIN EXTENDED na sua query para ver o plano da query. Se a materialização foi atingida, o nó folha inclui __materialization_mat_<pipeline ID>___metric_view_mat_ e o nome da materialização do arquivo YAML.
• Consulte o perfil da consulta, como mostrado abaixo.

Ciclo de vida da materialização

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

Criar e modificar

Ao criar ou modificar uma view de métrica (usando CREATE, ALTER ou o Catalog Explorer), a definição da view de métrica é atualizada imediatamente. Visualizações materializadas são atualizadas assincronamente em segundo plano usando um pipeline gerenciado.

• Ao criar: Se a sua view de métricas incluir materializações, o Databricks cria um pipeline e aciona um refresh inicial imediatamente. Enquanto o refresh estiver em andamento, a view de métricas ainda é consultável; as queries recorrem à origem até que a materialização seja totalmente criada.
• Na modificação: nenhum refresh é acionado, a menos que esteja habilitando materializações pela primeira vez. Materializações existentes não são usadas para reescrita de consulta até que a próxima atualização seja concluída.

Alterar o programador de materialização não aciona uma refresh.

Sem um programar, o pipeline executa um refresh inicial na criação, mas os refreshes subsequentes devem ser acionados manualmente ou os dados ficam obsoletos. A Databricks recomenda sempre definir um agendamento para que os dados permaneçam atualizados, exceto em casos de teste ou prototipagem.

Consulte a refreshmanual para obter um controle mais preciso sobre o comportamento refresh .

Inspecione pipelinesubjacente.

A materialização para views de métricas é implementada usando Pipelines declarativos do Lakeflow Spark. Você pode acessar o pipeline de duas maneiras:

• No Catalog Explorer: A **tab** **Visão geral** para a view de métricas inclui um link direto sob o cabeçalho **Agenda de Refresh**. Para aprender a acessar o Catalog Explorer, consulte O que é o Explorador de Catálogos?.
• Usando SQL : Execute DESCRIBE EXTENDED. A seção **Informações de refresh** contém o link do pipeline e o status de refresh atual.

SQL

DESCRIBE EXTENDED my_metric_view;

Exemplo de saída:

SQL

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

refreshmanual

A partir do link para a página do pipeline declarativo LakeFlow Spark , você pode iniciar manualmente uma atualização pipeline para atualizar as materializações. Você também pode acionar uma refresh manual usando o seguinte comando SQL :

SQL

REFRESH MATERIALIZED VIEW <metric-view-name>

refreshincremental

As views materializadas usam refresh incremental sempre que possível e têm as mesmas limitações que as views materializadas padrão em relação às fontes de dados e à estrutura do plano.

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

Cobrança

Atualizações de visualizações materializadas acarretam encargos de uso do Lakeflow Spark Declarative Pipelines. 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 se aplicam à materialização para a visualização de redes:

• Após a criação de uma materialização para uma view de métricas, não é possível alterar o proprietário.
• Somente a estratégia de correspondência exata é elegível para visualizações de métricas com junções de um para muitos.