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.
Resolver matrizes e mapas na fonte
Campos, medidas e joins operam em colunas planas e escalares. Se seus dados de origem tiverem colunas do tipo ARRAY ou MAP, resolva-as para colunas planas na query source antes de referenciá-las em outro lugar na view de métricas. Existem duas estratégias de transformação, dependendo se você deseja uma linha por elemento de matriz ou um único valor por linha de origem. Ambos se aplicam independentemente de a matriz estar na origem de nível superior ou em uma tabela à qual você faz um join. Consulte Transformar tipos de dados complexos para o conjunto completo de funções de transformação.
Nenhum dataset no catálogo samples possui uma coluna de matriz, portanto, os exemplos nesta seção usam uma view orders que possui uma matriz line_items de estruturas. Use o exemplo a seguir para criar uma view com um campo que seja uma matriz. Substitua catalog.schema pelo catálogo e esquema nos quais deseja gravar. Você deve ter permissões para criar objetos nesse esquema.
CREATE OR REPLACE VIEW catalog.schema.orders AS
SELECT
o.o_orderkey,
o.o_custkey,
o.o_orderdate,
o.o_orderstatus,
collect_list(named_struct(
'product_id', l.l_partkey,
'quantity', cast(l.l_quantity as int)
)) AS line_items
FROM samples.tpch.orders o
JOIN samples.tpch.lineitem l ON o.o_orderkey = l.l_orderkey
GROUP BY o.o_orderkey, o.o_custkey, o.o_orderdate, o.o_orderstatus;
Transformar um array em linhas
Para analisar cada elemento de array como sua própria linha, use explode() na query source para descompactar o array. Cada elemento se torna uma linha separada, e as outras colunas da linha de origem se repetem para cada elemento. Consulte Explodir elementos aninhados de um mapa ou array.
O exemplo a seguir descompacta a matriz line_items para que cada item se torne uma linha:
version: 1.1
source: |
SELECT o_orderkey, o_custkey, item.product_id, item.quantity
FROM catalog.schema.orders
LATERAL VIEW explode(line_items) AS item
fields:
- name: Product
expr: product_id
measures:
- name: Total quantity
expr: SUM(quantity)
- name: Line item count
expr: COUNT(1)
A expansão (exploding) do array em source multiplica as linhas de origem, portanto, uma agregação como COUNT(1) conta os elementos do array, não as linhas originais. Para medir também as linhas originais sem fan-out, modele a tabela expandida como um join one_to_many em vez disso. Consulte join um-para-muitos.
Agregar uma matriz em um único valor
Para reduzir um array a um valor por linha de origem sem alterar a contagem de linhas, aplique uma função de array escalar na query source, como aggregate(), array_size() ou reduce(). Cada linha de origem mantém sua granularidade, e a coluna de compute está disponível para campos e medidas.
O exemplo a seguir computa a contagem de itens e a quantidade total do array line_items por pedido:
version: 1.1
source: |
SELECT o_orderkey, o_custkey,
array_size(line_items) AS item_count,
aggregate(line_items, 0, (acc, x) -> acc + x.quantity) AS total_quantity
FROM catalog.schema.orders
measures:
- name: Total quantity
expr: SUM(total_quantity)
- name: Average items per order
expr: AVG(item_count)
Como a query de origem reduz a matriz antes que a view de métrica a processe, a origem mantém uma linha por pedido e mede o agregado entre os pedidos como de costume.
Resolver uma matriz em uma tabela unida
A mesma regra se aplica quando a matriz reside em uma tabela que você deseja join, não na origem de nível superior. Um join opera em colunas planas, portanto, resolva a matriz na própria subconsulta source da tabela unida antes do join. Escreva o join source como uma query SQL que achata ou agrega a matriz e, em seguida, faça o join nas colunas resultantes. Consulte Joins em views de métricas.
O exemplo a seguir usa customer como fonte e faz o join da view orders com cardinality: one_to_many. O join source agrega o array line_items de cada pedido em um total_quantity escalar antes do join, para que a view de métricas possa somá-lo por cliente sem duplicar as linhas de clientes:
version: 1.1
source: samples.tpch.customer
joins:
- name: orders
source: |
SELECT o_orderkey, o_custkey,
aggregate(line_items, 0, (acc, x) -> acc + x.quantity) AS total_quantity
FROM catalog.schema.orders
on: orders.o_custkey = source.c_custkey
cardinality: one_to_many
fields:
- name: Customer name
expr: c_name
measures:
- name: Total quantity
expr: SUM(orders.total_quantity)
- name: Order count
expr: COUNT(orders.o_orderkey)
Para, em vez disso, tratar cada elemento da matriz como sua própria linha na tabela unida, achate a matriz com explode() no join source da mesma maneira. Consulte Achatar uma matriz em linhas.
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 ARRAY ou MAP. Para resolver arrays ou mapas em colunas simples antes da junção, consulte Resolver arrays e mapas na origem.
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.