Vista do modelo
Esta página descreve como definir os principais componentes de uma view de métricas: origens, campos, medidas, filtros e joins.
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, para que cada usuário em toda a organização relate o mesmo valor para o mesmo KPI, eliminando relatórios inconsistentes e possibilitando uma análise flexível 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. |
|
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. |
|
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
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:
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)
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 colunaexpr: uma expressão SQL que faz referência a dados de origem ou campos previamente definidos na view de métricas
Campos da view de métricas são sempre STRING, mesmo quando a coluna de origem é CHAR ou VARCHAR. O preenchimento de espaço de CHAR(n) aplicado ao limite da tabela é perdido, então as comparações podem ser diferentes da tabela de origem. Por exemplo, um valor 'COLLEGE' de CHAR(10) é armazenado como 'COLLEGE ', então column = 'COLLEGE' retorna true na tabela, mas false no campo da 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. Para referenciar uma medida em uma consulta, use a função MEASURE. As medidas podem fazer referência a colunas base nos dados de origem, a campos definidos anteriormente ou a 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 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 :
# 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
As visualizações de métricas oferecem suporte a junções para enriquecer seus dados de origem com atributos de tabelas relacionadas. Você pode modelar esquemas em estrela (tabela de fatos unida a tabelas de dimensões), esquemas em floco de neve (junções de dimensões em vários níveis) e relacionamentos um-para-muitos (expansão de fatos a partir de uma fonte dimensional). Para obter detalhes sobre tipos de join, cardinalidade, padrões de esquema e restrições, consulte Joins em views de métricas.
O exemplo a seguir une a tabela de fatos orders à tabela de dimensão customer:
version: 1.1
source: samples.tpch.orders
joins:
- name: customer
source: samples.tpch.customer
on: source.o_custkey = customer.c_custkey
fields:
- name: Customer name
expr: customer.c_name
measures:
- name: Total revenue
expr: SUM(o_totalprice)
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
CASEdeclaraçõ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.