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

Vista do modelo

Views de métricas criam uma camada semântica para seus dados, transformando tabelas e views em métricas de negócios padronizadas. Eles definem o que medir, como agregá-lo e como segmentá-lo. As views de métricas garantem que cada usuário em toda a organização relate o mesmo valor para o mesmo Indicador Chave de Desempenho (KPI), eliminando relatórios inconsistentes e possibilitando análises flexíveis em todos os campos.

Para um exemplo completo com joins, campos, medidas e metadados de agente, consulte Tutorial: criar uma view de métricas completa com joins.

Componentes principais​

Uma view métricas consiste nos seguintes elementos:

Componente

Descrição

Exemplo

Origem

A tabela base, view ou a consulta SQL que contém os dados.

samples.tpch.orders

Campos

Atributos de coluna usados para segmentar ou agrupar métricas.

Categoria do produto, Mês do pedido, Região do cliente

Medidas

Agregações de colunas que produzem métricas.

COUNT(o_order_id) como Contagem de Pedidos, SUM(o_total_price) como Receita Total

Filtros

Condições aplicadas aos dados de origem para definir o escopo.

  • status = 'completed'
  • order_date > '2024-01-01'

join

Relacionamentos entre tabelas, visualização e visualização de métricas para enriquecer dados.

junte a tabela orders com a tabela customers em customer_key

Defina uma fonte​

Você pode usar uma tabela semelhante a um ativo ou uma consulta SQL como fonte para sua view de métricas. Você deve ter pelo menos SELECT privilégios em qualquer ativo referenciado.

Um ativo do tipo tabela é qualquer objeto Unity Catalog que expõe um esquema tabular e suporta consultas SELECT , incluindo tabelas, visualizações, visualizações materializadas, tabelas de transmissão, tabelas estrangeiras, tabelas de sistema e visualizações de métricas.

Utilize uma tabela ativa como fonte.​

Para usar uma tabela ativa como fonte, especifique o nome totalmente qualificado. Por exemplo: samples.tpch.orders.

Utilize uma view métrica como fonte.​

Você pode usar uma view de métricas existente como fonte para uma nova view de métricas:

YAML
version: 1.1

source: views.examples.source_metric_view

fields:
  - name: Order month
    expr: '`Order Month`'

measures:
  - name: Latest order month
    expr: MAX(`Order month`)
  - name: Latest order year
    expr: "DATE_TRUNC('year', MEASURE(`Latest order month`))"

Ao usar uma view de métricas como origem, as mesmas regras de composição se aplicam para referenciar campos e medidas. Consulte Componibilidade.

Utilize uma consulta SQL como fonte.​

Para usar uma consulta SQL, escreva o texto da consulta diretamente no YAML:

YAML
version: 1.1

source: SELECT * FROM samples.tpch.orders o LEFT JOIN samples.tpch.customer c ON o.o_custkey
  = c.c_custkey

fields:
  - name: Order key
    expr: o_orderkey

measures:
  - name: Order Count
    expr: COUNT(o_orderkey)
nota

Ao utilizar uma consulta SQL como origem com uma cláusula JOIN, defina restrições de chave primária e estrangeira em tabelas subjacentes e utilize a opção RELY para um desempenho de consulta ideal. Consulte Declarar chave primária, chave estrangeira e restrições exclusivas e Otimização de consulta usando chave primária e restrições exclusivas.

Campos​

Campos são colunas usadas em SELECT, WHERE e GROUP BY cláusulas no momento da consulta. Cada expressão deve retornar um valor escalar. Campos podem referenciar colunas dos dados de origem ou campos definidos anteriormente na view de métricas. Cada campo consiste em dois componentes:

  • name: O pseudônimo da coluna
  • expr: uma expressão SQL que faz referência a dados de origem ou campos previamente definidos na view de métricas

Medidas​

Medidas são expressões que produzem resultados sem um nível de agregação pré-determinado. Elas devem ser expressas usando funções de agregação. Medidas podem referenciar colunas base nos dados de origem, campos definidos anteriormente ou medidas definidas anteriormente. Cada medida consiste nos seguintes componentes:

  • name: O pseudônimo da medida
  • exprUma expressão SQL agregada que pode incluir funções de agregação SQL.

O exemplo a seguir demonstra padrões de medidas comuns para analisar dados de pedidos e receitas. Estes exemplos utilizam a tabela de pedidos TPC-H, que contém dados de transações de vendas, incluindo preços de pedidos (o_totalprice), identificadores de clientes (o_custkey), chave de pedido (o_orderkey), datas de pedidos (o_orderdate) e níveis de prioridade (o_orderpriority):

YAML
measures:
  # Simple count measure
  - name: Order Count
    expr: COUNT(1)

  # Sum aggregation measure
  - name: Total Revenue
    expr: SUM(o_totalprice)

  # Distinct count measure
  - name: Unique Customers
    expr: COUNT(DISTINCT o_custkey)

  # Calculated measure combining multiple aggregations
  - name: Average Order Value
    expr: SUM(o_totalprice) / COUNT(DISTINCT o_orderkey)

  # Filtered measure with WHERE condition
  - name: High Priority Order Revenue
    expr: SUM(o_totalprice) FILTER (WHERE o_orderpriority = '1-URGENT')

  # Measure using a field
  - name: Average Revenue per Month
    expr: SUM(o_totalprice) / COUNT(DISTINCT DATE_TRUNC('MONTH', o_orderdate))

Consulte Funções de agregação para obter uma lista de funções de agregação.

Aplicar filtros​

Um filtro na definição YAML se aplica a todas as consultas que fazem referência à view métricas. O exemplo a seguir mostra como escrever filtros como expressões Boolean :

YAML
# Single condition
filter: o_orderdate > '2024-01-01'

# Multiple conditions
filter: o_orderdate > '2024-01-01' AND o_orderstatus = 'F'

# IN clause
filter: o_orderstatus IN ('F', 'P') AND o_orderdate >= '2024-01-01'

Trabalhe com a equipe​

A funcionalidade de junção na visualização de métricas suporta tanto a junção direta de uma tabela de fatos para tabelas de dimensões (esquema em estrela) quanto a junção de múltiplos saltos entre tabelas de dimensões normalizadas (esquemas em floco de neve).

nota

Tabelas unidas não podem incluir colunas do tipo MAP . Para desempacotar valores de colunas do tipo MAP , consulte Explodir elementos aninhados de um mapa ou matriz.

Esquemas de modelo em estrela​

Em um esquema em estrela, o source é a tabela de fatos e se une a uma ou mais tabelas de dimensão usando um LEFT OUTER JOIN join. As views de métricas join as tabelas de fatos e dimensões necessárias para a consulta específica, com base nos campos e medidas selecionados.

Especifique as colunas join usando uma cláusula on (expressão booleana) ou uma cláusula using (nomes de colunas compartilhadas). A join deve seguir uma relação de muitos para um. Em casos de relacionamento muitos-para-muitos, a primeira linha correspondente da tabela de dimensão unida é selecionada.

O exemplo a seguir join orders (tabela de fatos) a customer (tabela de dimensões) e expõe atributos do cliente como campos. A configuração rely.at_most_one_match: true declara que a join é muitos-para-um (cada pedido tem exatamente um cliente), o que permite ao mecanismo otimizar queries que filtram em campos da tabela combinada.

atenção

Defina at_most_one_match: true somente quando o relacionamento for de muitos para um. Esta propriedade não é validada em runtime. Se o join produzir um fan-out, as medidas retornarão resultados incorretos.

Veja Otimizar joins com rely.

YAML
version: 1.1
source: samples.tpch.orders

joins:
  - name: customer
    source: samples.tpch.customer
    on: source.o_custkey = customer.c_custkey
    rely:
      at_most_one_match: true

fields:
  - name: Customer name
    expr: customer.c_name
  - name: Customer market segment
    expr: customer.c_mktsegment

measures:
  - name: Total revenue
    expr: SUM(o_totalprice)
  - name: Order count
    expr: COUNT(1)

Use a cláusula using em vez de on quando ambas as tabelas compartilharem o mesmo nome de coluna:

YAML
joins:
  - name: customer
    source: samples.tpch.customer
    using:
      - customer_key
nota

Em uma cláusula on , source se refere à tabela de origem da view métricas e a join name se refere às colunas da tabela unida. Por exemplo, source.o_custkey = customer.c_custkey une a coluna o_custkey da tabela de origem à coluna c_custkey da tabela customer . Caso nenhum prefixo seja fornecido, a referência padrão será a tabela resultante da junção.

Modelo de esquemas de floco de neve​

Um esquema em floco de neve estende um esquema em estrela normalizando tabelas de dimensão e conectando-as a subdimensões. Isso cria uma estrutura join multinível.

Para definir um esquema de floco de neve:

  1. Criar uma viewde tempo
  2. Adicionar junção de primeiro nível (esquema em estrela)
  3. unir com outras tabelas de dimensões
  4. Para expor atributos aninhados, adicione campos na view.

O exemplo a seguir utiliza o dataset TPC-H para ilustrar um esquema em forma de floco de neve, mostrando a hierarquia geográfica dos pedidos. O exemplo une a tabela de pedidos aos clientes, depois às suas nações (países) e, finalmente, às suas regiões (continentes). Essa estrutura join multinível permite análises como "mostrar a receita por região" ou "comparar a distribuição de clientes entre países". O dataset TPC-H está disponível no catálogo samples em seu workspace Databricks .

YAML
source: samples.tpch.orders

joins:
  - name: customer
    source: samples.tpch.customer
    on: source.o_custkey = customer.c_custkey
    joins:
      - name: nation
        source: samples.tpch.nation
        on: customer.c_nationkey = nation.n_nationkey
        joins:
          - name: region
            source: samples.tpch.region
            on: nation.n_regionkey = region.r_regionkey

fields:
  - name: clerk
    expr: o_clerk
  - name: customer
    expr: customer
    comment: returns the full customer row as a struct
  - name: customer_name
    expr: customer.c_name
  - name: nation
    expr: customer.nation
  - name: nation_name
    expr: customer.nation.n_name

Sintaxe e formatação YAML​

As definições view métricas seguem a sintaxe padrão da notação YAML. Consulte a referência de sintaxe YAML para view sobre a sintaxe e a formatação necessárias.

Melhores práticas​

Utilize as seguintes diretrizes ao modelar a visualização de métricas:

  • Modele medidas atômicas : comece definindo primeiro as medidas mais simples (por exemplo, SUM(revenue), COUNT(DISTINCT customer_id)). Crie medidas complexas usando a capacidade de composição.
  • Padronize os valores dos campos: use transformações (como CASE declarações) para converter códigos de banco de dados em nomes comerciais claros (por exemplo, converta o status do pedido 'O' para 'Aberto' e 'F' para 'Atendido').
  • Defina o escopo com filtros : Se uma view de métricas deve incluir apenas pedidos concluídos, defina esse filtro na view de métricas para que os usuários não incluam dados incompletos acidentalmente.
  • Use nomenclatura clara : os nomes das análises devem ser reconhecíveis para os usuários empresariais (por exemplo, "Cliente o valor da duração da vida" em vez de cltv_agg_measure).
  • Campos de tempo separados : Incluir campos de tempo granulares (como "Data do Pedido") e campos de tempo truncados (como "Mês do Pedido" ou "Semana do Pedido") para oferecer suporte à análise de detalhes e de tendências.

Próximos passos​

Nesta página