Metric Views no Unity Catalog: defina o KPI uma vez, use em todo lugar

Em quase duas décadas de engenharia de dados, aprendi a reconhecer um sintoma que aparece em quase toda empresa que cresce: a mesma métrica calculada de vários jeitos diferentes. "Receita" no dashboard executivo não bate com "receita" no relatório de finanças, que por sua vez não bate com a "receita" que o time de ciência de dados usou para treinar o modelo de churn. Ninguém errou de propósito — cada pessoa reimplementou a mesma lógica em um SQL ligeiramente diferente, e as pequenas divergências (um filtro a mais aqui, um DISTINCT a menos ali) se acumularam.

As Metric Views do Unity Catalog, destacadas pela Databricks no Data + AI Summit 2026 como parte da nova camada semântica, atacam exatamente esse problema. A proposta é simples e poderosa: você define a métrica uma única vez, de forma governada, e todo consumidor — SQL, BI, API ou agente de IA — lê a mesma definição.

O problema com a view tradicional

Uma view SQL comum resolve reutilização de consulta, mas não de métrica. Quando você escreve:

CREATE VIEW receita_por_pais AS
SELECT pais, SUM(total) AS receita
FROM vendas
GROUP BY pais;

você travou a granularidade na criação. Essa view só serve para receita por país. Se amanhã alguém precisar de receita por mês, ou por produto, ou por país e mês, terá que escrever outra view — e é aí que as definições começam a divergir. A agregação (SUM(total)) e a dimensão (pais) ficam grudadas no mesmo objeto.

A Metric View separa essas duas coisas. Você define a medida (o cálculo) independentemente das dimensões (por onde se agrupa), e decide a granularidade só na hora da consulta.

Passo 1 — Definir a métrica em YAML

Uma Metric View é declarada em YAML e registrada no Unity Catalog como se fosse uma view. Em SQL, você embrulha o YAML em um CREATE VIEW ... WITH METRICS, com a definição entre delimitadores $$:

CREATE VIEW vendas.receita_mv
WITH METRICS
LANGUAGE YAML
AS $$
version: 1.1
source: vendas.pedidos
dimensions:
  - name: pais
    expr: pais
  - name: mes
    expr: date_trunc('MONTH', data_pedido)
measures:
  - name: receita
    expr: SUM(total)
  - name: clientes
    expr: COUNT(DISTINCT cliente_id)
$$;

Repare na estrutura: source é a tabela (ou uma query) de origem; dimensions são os eixos por onde você vai fatiar; measures são os cálculos agregados. A definição de receita como SUM(total) agora existe em um lugar só — o Unity Catalog.

Passo 2 — Consultar com MEASURE() e agrupar por qualquer dimensão

Aqui está a diferença prática em relação à view tradicional. Você consulta a Metric View com a função MEASURE() e agrupa por qualquer dimensão disponível — o motor gera a agregação correta a cada consulta:

-- receita por país
SELECT pais, MEASURE(receita) AS receita
FROM vendas.receita_mv
GROUP BY pais;

-- a MESMA métrica, agora por país e mês
SELECT pais, mes, MEASURE(receita) AS receita
FROM vendas.receita_mv
GROUP BY pais, mes;

Não há uma segunda definição de receita. A regra de cálculo é a mesma; muda apenas o GROUP BY. Esse é o coração da camada semântica: a métrica é imutável, a granularidade é livre.

E porque a Metric View vive no Unity Catalog, você também pode consultá-la programaticamente com spark.sql() (em notebooks no DBR 17.2+ ou via SQL warehouse) — sempre passando pela MEASURE(). O mesmo número, agora disponível para pipelines em PySpark:

df = spark.sql("""
    SELECT pais, MEASURE(receita) AS receita
    FROM vendas.receita_mv
    GROUP BY pais
""")
df.show()

Um detalhe que pega muita gente: a Metric View só responde através da MEASURE(). Um SELECT * — ou um spark.read.table(...).show() puro — não é suportado, justamente porque a medida não tem granularidade pré-definida até você dizer por onde agrupar.

Passo 3 — Um número só, consumido em todo lugar

O ganho estratégico aparece quando você olha quem consome a definição. Como ela vive no catálogo, o mesmo KPI é lido de forma idêntica por:

• SQL e Warehouses — analistas escrevem queries sem reinventar o cálculo.
• Power BI e ferramentas de BI — o dashboard herda a definição oficial, não uma cópia.
• APIs — aplicações consomem a métrica governada por trás de um endpoint.
• Agentes de IA — e este é o ponto mais atual de 2026: quando um LLM precisa responder "qual foi a receita do trimestre?", ele consulta a definição oficial em vez de improvisar um SQL. A camada semântica vira o grounding que impede o agente de inventar o cálculo.

Governança: a métrica herda o Unity Catalog

Um detalhe que engenheiros de dados valorizam: por ser um objeto do Unity Catalog, a Metric View herda todo o modelo de governança — permissões por grupo, mascaramento de colunas, linhagem (lineage) e auditoria. Você controla quem pode consultar a métrica com as mesmas ferramentas que já usa para tabelas, e consegue rastrear a origem de cada número até a tabela de base. A consistência deixa de depender de disciplina humana e passa a ser garantida pela plataforma.

Quando usar — e quando não

As Metric Views brilham quando o objetivo é padronizar os KPIs centrais do negócio — receita, margem, churn, usuários ativos — e garantir que todos os consumidores vejam o mesmo número. São a resposta certa para a pergunta clássica "por que esses dois relatórios discordam?".

Mas é importante ser honesto sobre os limites:

• Metric Views não substituem a modelagem dimensional. Elas ficam por cima das tabelas já limpas e tratadas. Você ainda precisa do seu ETL, das suas dimensões conformadas e das suas tabelas fato. A Metric View padroniza o cálculo final, não a preparação do dado.
• Não são um atalho para pular a engenharia. Se a tabela de origem está suja ou mal modelada, a métrica só vai propagar o problema de forma mais consistente.
• A especificação ainda evolui. A sintaxe YAML (campos como source, fields — o antigo dimensions —, measures, filter, joins, window measures) está amadurecendo rápido — vale conferir a referência oficial antes de desenhar algo complexo, pois novos recursos continuam sendo adicionados.

Conclusão

Depois de anos vendo times debaterem qual dashboard tem o número "certo", é difícil não enxergar as Metric Views como uma correção de rota necessária. O problema nunca foi falta de SQL — era excesso dele, com a mesma métrica reimplementada dezenas de vezes. Transformar o KPI em um objeto governado, definido uma vez e consumido por SQL, BI, API e agentes de IA, é o tipo de simplificação que devolve confiança ao dado.

Se na sua empresa a palavra "receita" significa coisas ligeiramente diferentes dependendo de quem pergunta, vale um experimento com Metric Views. A chance de você acabar apagando definições duplicadas — em vez de criar mais uma — é real.