Pular para o conteúdo principal

Vista do modelo

A visualização de métricas cria uma camada semântica para seus dados, transformando tabelas e visualizações em métricas de negócios padronizadas. Eles definem o que medir, como agregar e como segmentar os dados. A visualização de métricas garante que todos os usuários da organização reportem o mesmo valor para o mesmo indicador-chave de desempenho (KPI), eliminando inconsistências nos relatórios e permitindo análises flexíveis em todas as dimensões.

Para um exemplo completo com junção, dimensões, medidas e metadados do agente, consulte o tutorial: Criar uma view de métricas completa com junção.

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

Dimensões

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

dimensions:
- 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 fonte, as mesmas regras de composição se aplicam para referenciar dimensões e medidas. Veja Composability.

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

dimensions:
- name: Order key
expr: o_orderkey

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

Ao usar uma consulta SQL como fonte com uma cláusula JOIN , defina restrições key primária e estrangeira nas tabelas subjacentes e use a opção RELY para obter o desempenho ideal da consulta. Consulte Declarar relações key primária e key estrangeira e Otimização de consultas usando restrições key primária.

Dimensões

As dimensões são colunas usadas nas cláusulas SELECT, WHERE e GROUP BY no momento da consulta. Cada expressão deve retornar um valor escalar. As dimensões podem fazer referência a colunas dos dados de origem ou a dimensões previamente definidas na view de métricas. Cada dimensão consiste em dois componentes:

  • name: O pseudônimo da coluna
  • exprUma expressão SQL que faz referência aos dados de origem ou às dimensões previamente definidas na viewde métricas.

Medidas

As medidas são expressões que produzem resultados sem um nível de agregação predeterminado. Elas devem ser expressas usando funções agregadas. As medidas podem fazer referência a campos base nos dados de origem, dimensões 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 dimension
- 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 junta a uma ou mais tabelas de dimensão usando um LEFT OUTER JOIN. A visualização de métricas join as tabelas de fatos e dimensões necessárias para a consulta específica, com base nas dimensões e métricas selecionadas.

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 une orders (tabela de fatos) a customer (tabela de dimensões) e expõe os atributos do cliente como dimensões:

YAML
version: 1.1
source: samples.tpch.orders

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

dimensions:
- 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. Exponha dimensões aninhadas adicionando dimensões à sua 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

dimensions:
- 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.
  • Padronizar valores de dimensão : Use transformações (como instruções CASE ) para converter códigos de banco de dados em nomes comerciais claros (por exemplo, converter o status do pedido 'O' para 'Aberto' e 'F' para 'Concluído').
  • 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).
  • Dimensões de tempo separadas : Inclua dimensões de tempo granulares (como "Data do Pedido") e dimensões de tempo truncadas (como "Mês do Pedido" ou "Semana do Pedido") para dar suporte a análises detalhadas e de tendências.

Próximos passos