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. |
|
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. |
|
Filtros | Condições aplicadas aos dados de origem para definir o escopo. |
|
join | Relacionamentos entre tabelas, visualização e visualização de métricas para enriquecer dados. | junte a tabela |
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:
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:
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)
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 colunaexprUma 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 medidaexprUma 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):
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 :
# 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).
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:
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:
joins:
- name: customer
source: samples.tpch.customer
using:
- customer_key
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:
- Criar uma viewde tempo
- Adicionar junção de primeiro nível (esquema em estrela)
- unir com outras tabelas de dimensões
- 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 .
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.