Modelar visualizações de métricas
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. Dessa forma, cada usuário em toda a organização relata o mesmo valor para o mesmo KPI, o que elimina relatórios inconsistentes e permite análise flexível em todos os campos.
Os componentes principais que você define são origens, joins, filtros, campos e medidas.
Para ver um exemplo completo com joins, campos, medidas e metadados do agente, consulte Tutorial: criar uma view de métricas com joins e modelagem de dados.
Componentes principais
Uma view de métricas consiste nos seguintes elementos:
Componente | Descrição | Exemplo |
|---|---|---|
Origem | A tabela base, view ou query SQL que contém os dados. |
|
join | Relações entre tabelas, views e views de métricas para enriquecer dados. | Faça join da tabela |
Filtros | Condições aplicadas aos dados de origem para definir o escopo. |
|
Campos | Colunas usadas para agrupar, filtrar e agregar métricas. Inclui colunas categóricas e colunas numéricas não agregadas. Também chamadas de dimensões. | Categoria de produto, Mês do pedido, Preço unitário |
Medidas | Agregações de coluna que produzem métricas. |
|
Definir uma origem
Você pode usar um ativo tipo tabela ou uma query SQL como fonte para sua view de métricas. Você deve ter no mínimo SELECT privilégios em qualquer ativo referenciado.
Um ativo tipo tabela é qualquer objeto do Unity Catalog que expõe um esquema tabular e oferece suporte a SELECT queries, incluindo tabelas, views, visualizações materializadas, tabelas de transmissão, tabelas externas, tabelas de sistema e views de métricas.
Use um ativo semelhante a uma tabela como origem
Para usar um ativo semelhante a uma tabela como origem, especifique o nome totalmente qualificado. Por exemplo: samples.tpch.orders.
Usar uma view de métricas como fonte
Você pode usar uma view de métricas existente como origem 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 composibilidade se aplicam para referenciar campos e medidas. Consulte Composibilidade.
Usar uma query SQL como origem
Para usar uma query SQL, escreva o texto da query 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 usar uma query SQL como fonte com uma cláusula JOIN, defina restrições de key primária e key estrangeira nas tabelas subjacentes e use a opção RELY para obter o desempenho ideal da query. Consulte Declarar chave primária, chave estrangeira e restrições exclusivas e Otimização de query usando chave primária e restrições exclusivas.
Campos
Campos, também chamados de dimensões, são colunas da view de métricas que pode usar nas cláusulas SELECT, WHERE e GROUP BY no momento da query. Um campo pode ser uma coluna categórica, como região ou status, ou uma coluna numérica não agregada, como preço ou quantidade, que pode ser agregada no momento da query. Cada expressão de campo deve retornar um valor escalar. Pode referenciar colunas dos dados de origem ou campos definidos anteriormente na view de métricas. Cada campo consiste em dois componentes:
name: O alias da colunaexpr: Uma expressão SQL que referencia os dados de origem ou campos definidos anteriormente na view de métricas
Os campos da view de métricas semelhantes a strings são sempre STRING, mesmo quando a coluna de origem é CHAR ou VARCHAR. Como o preenchimento de espaço CHAR(n) é perdido, as comparações podem retornar resultados diferentes. Por exemplo, column = 'COLLEGE' corresponde a um valor CHAR(10) na tabela de origem (que é preenchida com espaços), mas não no campo da view de métricas.
Medidas
Medidas são expressões que produzem resultados sem um nível predeterminado de agregação. Elas devem ser expressas usando funções de agregação. Para referenciar uma medida em uma query, use a função MEASURE. As medidas podem referenciar colunas base nos dados de origem, campos definidos anteriormente ou medidas definidas anteriormente. Cada medida consiste nos seguintes componentes:
name: O alias da medidaexpr: Uma expressão SQL agregada que pode incluir funções de agregação SQL.
O exemplo a seguir demonstra padrões comuns de medida para analisar dados de pedido e receita. Estes exemplos usam a tabela de pedidos TPC-H, que contém dados de transação de vendas, incluindo preços de pedido (o_totalprice), identificadores de cliente (o_custkey), chaves de pedido (o_orderkey), datas de pedido (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 uma lista de funções de agregação.
Aplicar filtros
Um filtro é aplicado a todas as queries que fazem referência à view de métricas. Para definir um filtro na UI, consulte O passo 3: Definir um filtro.
Para definir um filtro na definição YAML, escreva uma expressão Boolean. O exemplo a seguir mostra padrões comuns de filtro:
# 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'
Trabalhar com joins
As views de métricas oferecem suporte a joins para enriquecer seus dados de origem com atributos de tabelas relacionadas. É possível modelar esquemas estrela (tabela de fatos unida a tabelas de dimensão), esquemas floco de neve (joins de dimensão de 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.
Para definir joins na UI, consulte O passo 2: Adicionar um join. Para definir joins na definição YAML, use os padrões nas seções a seguir.
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 array.
Modelar esquemas em estrela
Em um esquema em estrela, o(a) source é a tabela de fatos e une-se a uma ou mais tabelas de dimensões usando um(a) LEFT OUTER JOIN. As views de métricas join as tabelas de fatos e de dimensões necessárias para a query específica, com base nos campos e medidas selecionados.
Especifique as colunas de join usando uma cláusula on (expressão Boolean) ou uma cláusula using (nomes de coluna compartilhados). O join deve seguir um relacionamento de muitos para um. Em casos de muitos para muitos, o mecanismo seleciona a primeira linha correspondente da tabela de dimensões associada.
O próximo exemplo join orders (tabela de fatos) a customer (tabela de dimensões) e expõe os atributos do cliente como campos. Definir rely.at_most_one_match: true declara que a join é de muitos para um (cada pedido tem exatamente um cliente), o que permite ao mecanismo otimizar as queries que filtram em campos da tabela unida.
Defina at_most_one_match: true apenas 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.
Consulte Otimizar joins com rely.
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 de view de métricas seguem a sintaxe de notação YAML padrão. Consulte Referência de sintaxe YAML da view de métricas para a sintaxe e formatação necessárias.
Práticas recomendadas
Use as diretrizes a seguir ao modelar visualizações de métricas:
- Medidas atômicas do modelo : comece definindo as medidas mais simples primeiro (por exemplo,
SUM(revenue),COUNT(DISTINCT customer_id)). Crie medidas complexas usando a componibilidade. - Padronizar valores de campo : utilize transformações (como instruções
CASE) para converter códigos de banco de dados em nomes de negócios claros (por exemplo, converter 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 possam incluir dados incompletos acidentalmente.
- Use nomes claros : Os nomes das métricas devem ser reconhecíveis para usuários de negócios (por exemplo, "Value da duração da vida do cliente" em vez de
cltv_agg_measure). - Separar campos de tempo : Inclua campos de tempo granulares (como "Data do Pedido") e campos de tempo truncados (como "Mês do Pedido" ou "Semana do Pedido") para permitir análise detalhada e de tendências.