Há muito tempo o Databricks se posiciona como a plataforma completa de inteligência de dados e IA. E realmente é! Com suas capacidades de engenharia de dados, analytics, machine learning e agora GenAI integradas, ela é praticamente um ecossistema all in one, mas havia uma lacuna persistente que nos fazia questionar essa completude: onde estava a camada OLAP nativa? É o que podemos chamar de calcanhar de Aquiles.
Durante anos, essa foi a resposta: “Use Databricks para armazenamento, engenharia de dados e machine learning, mas depois conecte o Power BI ou outra ferramenta de visualização para a camada semântica.”
Funcionava, claro, mas deixava um incômodo constante, principalmente se falarmos de Power BI onde você ficaria limitado a conexões por importação ou DirectQuery. E por que isso não era bom?
E então chegaram as Metric Views. Tema sobre o qual palestrei recentemente no evento Data & AI Saturday - Vitória - 2025, clique aqui e confira como foi.
Metric Views são uma camada semântica nativa do Databricks que permite definir métricas, dimensões e relacionamentos diretamente no lakehouse. Em essência, elas implementam a funcionalidade OLAP que faltava — aquela capacidade de fazer slicing, dicing e agregações multidimensionais sem sair da plataforma.
Antes das Metric Views, a arquitetura típica era:
graph LR
Source1(ERP) -->| Batch | Bronze1(Bronze: ERP) --> Silver(Silver)
Source2(CRM) -->| Batch | Bronze2(Bronze: CRM) --> Silver(Silver)
Source3(IoT) -->| Streaming | Bronze3(Bronze: Teletrias) --> Silver(Silver)
Silver(Silver) -->| Import ou DirectQuery
| PowerBI(Camada Semântica) -->| LiveConnection | Dashboards(Dashboards)
PowerBI(Camada Semântica) -->| LiveConnection | Reports(Reports)
leg1[Fontes de dados] -->| Ingestão
| leg2[Databricks] --> | Transformações
| leg3[Databricks] --> | Conexão
| leg4[Power BI] --> | Conexão
| leg5[Power BI]
Agora, com Metric Views, você tem:
graph LR Source1(ERP) -->| Batch | Bronze1(Bronze: ERP) --> Silver(Silver) Source2(CRM) -->| Batch | Bronze2(Bronze: CRM) --> Silver(Silver) Source3(IoT) -->| Streaming | Bronze3(Bronze: Teletrias) --> Silver(Silver) Silver(Silver) --> PowerBI(Camada Semântica) --> Dashboards(Dashboards) leg1[Fontes de dados] -->| Ingestão | leg2[Databricks] --> | Transformações | leg3[Databricks] --> | Conexão | leg4[Databricks] --> | Conexão | leg5[Databricks]
Tudo integrado. Tudo no mesmo lugar. Tudo vivo.
Deixa eu ser direto: essa é uma das mudanças mais significativas da evolução recente do Databricks. Aqui está o porquê:
Você define uma métrica uma única vez. Todos os dashboards, relatórios e análises usam a mesma definição. Não há mais “qual é o número de receita certo?” porque há apenas uma fonte da verdade.
Com a definição da metric view, podemos estabelecer quais campos podem ser utilizados como dimensão e quais como medidas.
Sua lógica de negócio vive onde seus dados vivem. Não há importação de dados, sincronização externa ou atrasos. A métrica é calculada sob demanda, sempre fresca, sempre consistente.
Você não precisa mais de Power BI ou Tableau como camada obrigatória para BI semântico. Claro, você ainda pode usá-los se desejar — eles se integram perfeitamente — mas agora é uma escolha, não uma necessidade.
Controle de acesso, auditoria, linhagem de dados — tudo acontece em um único lugar. Não há mais descobrir “de onde vieram esses números?” porque a rastreabilidade é automática.
Criar uma Metric View é surpreendentemente direto: feito através de sintaxe SQL como uma view, porém com uma estrutura interna definida em YAML. Veja o exemplo:
%sql
CREATE OR REPLACE VIEW seucatalogo.tpch_orders.mv_orders
WITH METRICS
LANGUAGE YAML
AS $$
version: 1.1
source: samples.tpch.orders
comment: Comprehensive sales metrics with enhanced semantic metadata
dimensions:
- name: order_date
expr: o_orderdate
comment: Date when the order was placed
display_name: Order Date
format:
type: date
date_format: year_month_day
leading_zeros: true
synonyms:
- order time
- date of order
- name: customer_segment
expr: |
CASE
WHEN o_totalprice > 100000 THEN 'Enterprise'
WHEN o_totalprice > 10000 THEN 'Mid-market'
ELSE 'SMB'
END
comment: Customer classification based on order value
display_name: Customer Segment
synonyms:
- segment
- customer tier
measures:
- name: total_revenue
expr: SUM(o_totalprice)
comment: Total revenue from all orders
display_name: Total Revenue
format:
type: currency
currency_code: USD
decimal_places:
type: exact
places: 2
hide_group_separator: false
abbreviation: compact
synonyms:
- revenue
- total sales
- sales amount
- name: order_count
expr: COUNT(1)
comment: Total number of orders
display_name: Order Count
format:
type: number
decimal_places:
type: all
hide_group_separator: true
synonyms:
- count
- number of orders
- name: avg_order_value
expr: SUM(o_totalprice) / COUNT(1)
comment: Average revenue per order
display_name: Average Order Value
format:
type: currency
currency_code: USD
decimal_places:
type: exact
places: 2
synonyms:
- aov
- average revenue
$$No caso acima, a view foi construída sobre a tabela samples.tpch.orders e define, de forma clara e reutilizável, as principais dimensões e medidas para análise de vendas:
Dimensões
Medidas
Mas isso é apenas a superfície. A verdadeira magia vem quando você:
A seguir, vemos a metric view com outras cláusulas, adicionando contextos de junção, filtro e definição de medidas como semi-aditivas (algo bem interessante):
%sql
CREATE OR REPLACE VIEW seucatalogo.tpch_orders.mv_orderslines
WITH METRICS
LANGUAGE YAML
AS $$
version: 1.1
source: samples.tpch.lineitem
joins:
- name: orders
source: samples.tpch.orders
"on": l_orderkey = orders.o_orderkey
joins:
- name: customer
source: samples.tpch.customer
"on": orders.o_custkey = c_custkey
filter: "l_shipdate >= '1995-01-01' AND orders.o_orderstatus IN ('O', 'F')"
comment: "Metric view for analyzing open and fulfilled line items, orders, and customer data since 1995 in TPCH. Joins orders and customer via a snowflake schema."
dimensions:
- name: ship_date
expr: l_shipdate
comment: Date the item was shipped
display_name: Ship Date
format:
type: date
date_format: year_month_day
leading_zeros: false
synonyms:
- shipment date
- date shipped
- name: customer_nation
expr: orders.customer.c_nationkey
comment: Nation key for the customer
display_name: Customer Nation Key
synonyms:
- nation key
- customer nation
measures:
- name: total_quantity
expr: SUM(l_quantity)
comment: Total quantity shipped
display_name: Total Quantity
format:
type: number
decimal_places:
type: exact
places: 2
abbreviation: compact
synonyms:
- quantity sum
- total qty
- name: total_revenue
expr: SUM(l_extendedprice * (1 - l_discount))
comment: Total revenue from shipped items
display_name: Total Revenue
format:
type: currency
currency_code: USD
decimal_places:
type: exact
places: 2
abbreviation: compact
synonyms:
- revenue
- gross revenue
- name: trailing_30d_quantity
expr: MEASURE(total_quantity)
window:
- order: ship_date
semiadditive: last
range: trailing 30 day
comment: Quantity shipped in the trailing 30 days
display_name: Trailing 30 Day Quantity
format:
type: number
decimal_places:
type: exact
places: 2
abbreviation: compact
synonyms:
- 30d quantity
- rolling quantity
$$Isso elimina a necessidade de cada ferramenta de BI (ou desenvolvedor) ter que “adivinhar” como agregar ou relacionar dados. A lógica está centralizada, auditada e versionada.
A Databricks publicou recentemente um ótimo artigo sobre “Databricks Lakehouse Data Modeling: Myths, Truths, and Best Practices” que aborda exatamente isso.
Isso não é só bom para governança — é transformador para o desenvolvimento de dashboards. Os Dashboards do Databricks ganham acesso a:
Agora você pode oferecer aos seus usuários de negócio a mesma experiência “OLAP clássica” (cubes, pivots, drill-through) que tinham em ferramentas caras, mas dentro do Databricks, mais barato e mais flexível.
Este é o momento em que dizemos: você não precisa mais de uma ferramenta BI externa como requisito tecnológico para ter um data lakehouse de qualidade. Você pode, se quiser — Power BI integra-se lindamente — mas agora é opcional, não obrigatório. Isso muda o jogo.
Assistir à evolução do Databricks nestes últimos anos foi fascinante. Passamos de “é ótimo para engenharia, mas você precisa de outra coisa para BI” para “é uma plataforma completa, de verdade.” Metric Views é a prova de que essa evolução é contínua.
A pergunta que nos colocávamos há anos — “E a camada OLAP?” — finalmente tem uma resposta satisfatória. E a resposta está, apropriadamente, dentro da plataforma.
Referências e Aprofundamento: