# O Que É uma Camada Semântica? Definição e Comparação de Suporte em Ferramentas de Analytics > Entenda o que é uma camada semântica, o que ela contém, e como Looker, Power BI, Tableau, dbt, Cube, Snowflake e Databricks dão suporte a ela. Source: https://www.erathos.com/blog/o-que-e-camada-semantica Published: 2026-09-18 Category: Business Intelligence & Analytics ![Definição e ferramentas de BI.](https://cms-media.erathos.com/Definição e ferramentas de BI.png) Uma camada semântica é o lugar onde uma empresa escreve, uma única vez, o que seus números significam. Ela diz como a "receita" é calculada, quais tabelas se juntam a quais, o que "cliente ativo" significa, e quem pode ver o quê. Ferramentas de BI, planilhas e agentes de IA então perguntam à camada semântica por "receita por região" em vez de escrever seu próprio SQL contra as tabelas brutas. Este artigo dá uma definição precisa, mostra o que vai dentro de uma camada semântica, e compara como Looker, Power BI, Tableau, dbt, Cube, Snowflake, Databricks e algumas ferramentas menores dão suporte a isso. Todas as afirmações sobre capacidades vêm da própria documentação de cada fornecedor. ## O que é uma camada semântica? Uma camada semântica é uma camada governada entre o seu data warehouse e as ferramentas que leem dele. Ela guarda definições de métricas, dimensões, caminhos de join, nomes de negócio e regras de acesso, para que ferramentas diferentes recebam a mesma resposta para a mesma pergunta. A Cube descreve isso como [uma camada independente e governada entre suas fontes de dados e as ferramentas que consomem os dados](https://cube.dev/articles/what-is-a-semantic-layer). A AtScale lista [as cinco coisas que ela padroniza](https://www.atscale.com/glossary/semantic-layer/): métricas, dimensões, relacionamentos, terminologia de negócio e regras de acesso. O dbt define isso como [um lugar central para construir e armazenar a lógica de métricas](https://www.getdbt.com/blog/semantic-layer-introduction), para que muitos endpoints possam ler dados consistentes e governados. A ideia é antiga. Em 1991, a Business Objects patenteou um ["sistema de acesso a banco de dados relacional usando objetos semanticamente dinâmicos"](https://motherduck.com/blog/who-needs-a-semantic-layer-anyway/), que se tornou o "Universe". As primeiras camadas semânticas eram [amarradas a um único produto de BI](https://www.atscale.com/glossary/semantic-layer/), como MicroStrategy, Business Objects ou Cognos. Hoje a mesma ideia existe em quatro lugares: dentro da ferramenta de BI, dentro da ferramenta de transformação, dentro do warehouse, ou como um serviço independente que qualquer ferramenta pode consultar. Uma pesquisa da Forrester de 2021 descobriu que [mais de 61% das organizações usam quatro ou mais ferramentas de BI, e 25% usam dez ou mais](https://www.getdbt.com/blog/semantic-layer-introduction)! Com tantas ferramentas, cada uma definindo "receita" à sua própria maneira produz números diferentes em dashboards diferentes. ## O que uma camada semântica contém? Uma camada semântica contém tabelas lógicas, dimensões, fatos, métricas, relacionamentos, sinônimos, descrições e regras de acesso. A especificação de semantic view da Snowflake é a lista pública mais clara dessas partes, então eu uso o vocabulário dela aqui. Parte O que é Exemplo Tabela lógica Uma view nomeada sobre uma tabela física ou consulta SQL orders sobre analytics.marts.fct\_orders Dimensão Uma coluna pela qual você agrupa ou filtra region, order\_date Fato Um número no nível da linha ligado a um evento order\_amount Métrica Uma agregação de fatos, com SUM, AVG, COUNT, etc. revenue = SUM(order\_amount) Relacionamento Como duas tabelas lógicas se juntam orders.customer\_id com customers.customer\_id Sinônimos e descrições Outras palavras que as pessoas usam para a mesma coisa "vendas" e "vendas totais" para receita Modificador de acesso Se um campo é público ou escondido de consultas uma métrica intermediária privada A especificação da Snowflake separa [fatos, que são valores no nível da linha, de métricas, que agregam fatos](https://docs.snowflake.com/en/user-guide/views-semantic/semantic-view-yaml-spec). Uma métrica derivada pode combinar métricas de várias tabelas, por exemplo uma margem de lucro construída a partir de receita total e custo total. Aqui está uma semantic view mínima no formato YAML da Snowflake, seguindo a especificação: `name: sales` `tables:` ` - name: orders` ` base_table:` ` database: analytics` ` schema: marts` ` table: fct_orders` ` primary_key:` ` columns: [order_id]` ` dimensions:` ` - name: region` ` synonyms: ["market", "territory"]` ` expr: region` ` data_type: VARCHAR` ` facts:` ` - name: order_amount` ` expr: amount` ` data_type: NUMBER` ` metrics:` ` - name: revenue` ` description: "Sum of order amounts"` ` synonyms: ["sales", "total sales"]` ` expr: SUM(orders.order_amount)` A mesma especificação também carrega verified queries, que combinam uma pergunta em linguagem natural com o SQL que a responde, e uma configuração de staleness no nível superior. Definir max\_staleness ativa a materialização, e o [valor mínimo permitido é 120 segundos](https://docs.snowflake.com/en/user-guide/views-semantic/semantic-view-yaml-spec). Outras ferramentas usam formatos diferentes para as mesmas partes. O Looker usa LookML. O Power BI usa TMDL, a Tabular Model Definition Language, mais DAX para medidas. O dbt usa MetricFlow YAML. O GoodData usa [MAQL, sua Multi-Dimension Analytical Query Language](https://www.gooddata.com/docs/cloud/create-metrics/concepts/metrics/). O Databricks usa SQL DDL ou uma interface com validação em YAML. As partes são as mesmas; o formato do arquivo muda. ## Uma camada semântica é um data warehouse, um modelo dbt, ou um cubo OLAP? Uma camada semântica é uma camada de significado sobre dados armazenados, então ela é uma coisa diferente do warehouse que armazena os dados, dos modelos dbt que os moldam, e dos cubos OLAP (Online Analytical Processing) que antes os pré-calculavam. Fornecedores modernos entregam todos eles em um único produto, o que confunde as linhas. **Warehouse.** Um banco de dados relacional [armazena e organiza dados em tabelas estruturadas sem focar no significado de negócio](https://learn.microsoft.com/en-us/power-bi/connect-data/semantic-models-third-party). Um modelo semântico adiciona nomes claros, relacionamentos e métricas predefinidas em cima disso. Snowflake e Databricks agora entregam objetos semânticos dentro do warehouse, o que levanta a questão de se o Snowflake é uma camada semântica. A resposta é que o Snowflake é um warehouse que também tem um recurso de camada semântica, chamado semantic views. **Modelos dbt.** Modelos dbt são transformações SQL que produzem tabelas. A dbt Semantic Layer [define métricas em cima de modelos existentes](https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl) e lida com os joins no momento da consulta. Então a camada semântica é uma camada separada que lê seus modelos, mesmo quando os dois estão no mesmo repositório. **Cubos OLAP.** Nos anos 1990, bancos de dados relacionais eram lentos demais para análises complexas. O cubo OLAP [resolveu o problema de performance através de pré-agregação](https://motherduck.com/blog/who-needs-a-semantic-layer-anyway/): o sistema pré-calculava respostas para combinações de dimensões antes que alguém perguntasse. Uma camada semântica, em vez disso, gera SQL no momento da consulta, e usa cache ou materialização como uma otimização em vez de como o design central. ## Onde uma camada semântica se encaixa em uma stack ELT? A camada semântica vem depois da ingestão e da transformação, e antes de BI, planilhas e IA. Em uma stack ELT (Extract, Load, Transform: carregar os dados brutos primeiro, depois transformá-los dentro do warehouse), a ordem é fontes, ingestão, warehouse, transformações, camada semântica, consumidores. Ingestão é o primeiro passo. A Erathos [extrai dados de uma fonte como PostgreSQL ou HubSpot, os deixa em staging em um bucket na nuvem, e os carrega no warehouse com COPY ou o equivalente do destino](https://docs.erathos.com/platform/how-we-move-data), depois apaga os arquivos temporários. Os destinos incluem [BigQuery](https://www.erathos.com/en/connectors/bigquery) e [Databricks](https://www.erathos.com/en/connectors/databricks), ambos com seus próprios recursos de camada semântica mais adiante (o LookML do Looker no BigQuery, as metric views do Unity Catalog no Databricks). As transformações vêm em seguida, geralmente no dbt, e produzem as tabelas limpas que a camada semântica lê. Então a camada semântica define métricas sobre essas tabelas. Depois, ferramentas de BI, Excel, notebooks e agentes de IA consultam a camada semântica. Se você quiser o contexto de ELT primeiro, escrevemos sobre [ETL vs. ELT e as principais diferenças](https://www.erathos.com/en/blog/etl-vs-elt-key-differences). A camada semântica só funciona se as tabelas abaixo dela estiverem completas e atualizadas. Uma métrica como receita fica errada se os pedidos de ontem à noite nunca carregaram. É por isso que a [observabilidade do pipeline](https://www.erathos.com/en/observability) na etapa de ingestão importa para as pessoas que são donas das definições de métricas, mesmo que elas raramente mexam na ingestão. ## Por que ferramentas de IA e text-to-SQL se beneficiam de uma camada semântica? Ferramentas de IA de text-to-SQL se beneficiam de uma camada semântica porque um esquema de banco de dados sozinho não diz como o negócio calcula suas métricas. A Snowflake afirma que [soluções genéricas de IA têm dificuldade com text-to-SQL quando recebem só um esquema, porque esquemas não têm definições de processos de negócio e tratamento de métricas](https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst). A camada semântica fornece exatamente as peças que faltam: fórmulas de métricas, caminhos de join, sinônimos ("vendas" significa receita), descrições e consultas de exemplo verificadas. O Cortex Analyst da Snowflake é uma API REST que [usa semantic views para gerar SQL](https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst). O Databricks permite que [agentes Genie consultem metric views](https://docs.databricks.com/aws/en/uc-semantics/metric-views/) da mesma forma que dashboards e notebooks fazem. A Strategy Mosaic documenta [acesso via MCP](https://www.microstrategy.com/enterprise-analytics) (Model Context Protocol, o padrão que agentes de IA usam para chamar ferramentas) ao lado de suas interfaces SQL, DAX, MDX e REST. Nenhum dos documentos primários que li publica um número de acurácia para text-to-SQL com e sem uma camada semântica, então não estou citando nenhum. O modelo só pode ser tão correto quanto a definição que recebe. Uma camada semântica também é uma coisa diferente de uma "context layer" ou uma "ontologia", termos que aparecem nas mesmas conversas sobre IA. O resumo da MotherDuck sobre essa diferença é útil. ## Quais ferramentas de analytics dão suporte a uma camada semântica? A maioria das plataformas de BI, os principais data warehouses na nuvem, e o dbt dão suporte a uma camada semântica, mas colocam ela em lugares diferentes. A forma útil de organizar é por onde as definições são armazenadas e se outras ferramentas conseguem lê-las. Onde a camada é definida Ferramentas O que isso significa na prática Dentro da ferramenta de BI Looker (LookML), Power BI (semantic models), Tableau Next (Tableau Semantics), Metabase (Metrics), GoodData (métricas MAQL), Superset (camada fina) Definições são escritas na linguagem da ferramenta de BI. Algumas expõem para fora (Looker via JDBC, o padrão Java para conexão com banco de dados; Power BI via XMLA, um protocolo de consulta XML, e REST); outras não (métricas do Metabase só funcionam no seu próprio query builder). Dentro da ferramenta de transformação dbt Semantic Layer (MetricFlow), Lightdash (YAML dentro de um projeto dbt) Definições ficam armazenadas no mesmo repositório Git dos modelos. Consumidores chegam até elas por APIs ou integrações nativas. Dentro do warehouse Snowflake Semantic Views, Databricks Unity Catalog metric views Definições são objetos de esquema, governados por permissões do warehouse. Qualquer cliente SQL consegue consultar. Independente (headless) Cube, AtScale, Strategy Mosaic Um serviço independente com endpoints SQL, REST, GraphQL ou MDX aos quais muitas ferramentas de BI se conectam. Dois detalhes da tabela merecem um olhar mais de perto. O Power BI trata camadas semânticas de terceiros de forma restrita: ele [dá suporte apenas a SAP BW, SAP HANA (como fonte multidimensional) e AtScale](https://learn.microsoft.com/en-us/power-bi/connect-data/semantic-models-third-party) como modelos semânticos externos. Colocar um modelo semântico de terceiros entre o próprio modelo do Power BI e o banco de dados geralmente não tem suporte, porque combinar duas camadas semânticas pode produzir resultados incorretos. O Superset vai pelo caminho contrário. A camada dele é [fina: métricas virtuais são agregações SQL e colunas calculadas virtuais customizam colunas individuais](https://superset.apache.org/user-docs/using-superset/creating-your-first-dashboard/). Com a feature flag experimental SEMANTIC\_LAYERS, o Superset consegue se conectar a camadas externas como dbt Semantic Layer ou Cube como fontes de dados. ## Como Looker, Power BI, Tableau, dbt, Cube, Snowflake e Databricks se comparam? Aqui está a comparação detalhada, construída somente a partir da documentação de cada fornecedor. Onde um documento não cobria uma coluna, a célula diz isso em vez de adivinhar. Ferramenta Nome do recurso Formato de definição Como outras ferramentas o acessam Cache ou materialização Limites documentados Looker Camada de modelagem semântica LookML LookML, com [integração Git](https://docs.cloud.google.com/looker/docs/sql-interface) Open SQL Interface via JDBC; Explores aparecem como tabelas Não coberto na página revisada Open SQL Interface precisa de um [projeto LookML em uma conexão BigQuery](https://docs.cloud.google.com/looker/docs/sql-interface); só SELECT; sem JOIN, window functions ou subqueries Power BI Semantic models TMDL para metadados, DAX para medidas [Endpoint XMLA](https://learn.microsoft.com/en-us/power-bi/connect-data/semantic-models-third-party) para ferramentas de visualização de terceiros; REST para CRUD, consulta e refresh; TOM para .NET Import mode, DirectQuery e Direct Lake (Delta Lake parquet, Iceberg, OneLake) sem refreshes Empilhar semantic models geralmente não tem suporte; só SAP BW, SAP HANA e AtScale como modelos de terceiros Tableau Next Tableau Semantics Semantic models construídos no Semantic Model Builder no Data 360 [Conector Tableau Semantics](https://help.tableau.com/current/tableau-next/en-us/tableau_next_overview.htm) para Tableau Cloud, Server e Desktop Não coberto na página revisada Documentado para Tableau Next e Data 360, não para fontes de dados do Tableau legado dbt Semantic Layer MetricFlow YAML no projeto dbt [JDBC, ADBC, GraphQL, Python SDK](https://docs.getdbt.com/docs/platform-integrations/avail-sl-integrations); integrações nativas para Power BI, Tableau, Google Sheets, Excel, Omni, Hex, Mode, Sigma (preview), entre outras; exportações para qualquer ferramenta de BI [Cache de resultados e cache declarativo](https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl) Precisa de uma conta dbt Starter ou Enterprise Cube Camada semântica Cube Arquivos de data model do Cube [API SQL, API REST (JSON), API GraphQL](https://docs.cube.dev/reference/core-data-apis/queries) Cache em memória mais pré-agregações; consultas com SQL pushdown pulam pré-agregações mas podem usar o cache em memória Limite padrão de 10.000 linhas por consulta, máximo de 50.000 Snowflake Semantic Views Especificação YAML ou SQL DDL (data definition language, os comandos CREATE); objetos em nível de esquema com controle de acesso baseado em papéis, compartilhamento e integração de catálogo do Snowflake Qualquer cliente SQL do Snowflake; [API REST do Cortex Analyst](https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst) para linguagem natural Materialização quando max\_staleness é definido (mínimo de 120 segundos) Nativo do Snowflake; definições não viajam para outro warehouse Databricks Unity Catalog metric views [SQL DDL ou interface do Catalog Explorer com validação em YAML](https://docs.databricks.com/aws/en/uc-semantics/metric-views/) Qualquer conexão SQL usando MEASURE(); wrapper views; modo de compatibilidade com BI; integrações nativas com parceiros Materialização que pré-calcula e atualiza agregações de forma incremental, com reescrita automática de consultas Uma wrapper view tem um [conjunto fixo de dimensões, então cada combinação de dimensões precisa da sua própria view](https://docs.databricks.com/aws/en/uc-semantics/metric-views/bi-tools) Lightdash Camada semântica Lightdash [YAML versionado em um projeto dbt, ou YAML do Lightdash sem dbt](https://docs.lightdash.com/semantic-layer) API e Python SDK Cache de resultados, cache do warehouse, pré-agregados Não coberto na página revisada Metabase Metrics Definidas no query builder, armazenadas em coleções Só o query builder do Metabase [Cache por métrica nos planos Pro e Enterprise](https://www.metabase.com/docs/latest/data-modeling/metrics) Métricas estão amarradas a uma fonte de dados e não podem ser reutilizadas em outra Strategy Mosaic Camada semântica universal Mosaic Models e Mosaic Schema [SQL, DAX, MDX, API REST e MCP](https://www.microstrategy.com/enterprise-analytics) Não coberto na página revisada Página do fornecedor; alegações de performance ali são alegações de casos de clientes O padrão de BI externo do Databricks é o exemplo mais claro de uma camada nativa do warehouse alcançando uma ferramenta externa. Qualquer ferramenta de BI que consiga passar SQL executa isto: `SELECT` ` `Order Month`,` ` MEASURE(`Total Revenue`),` ` MEASURE(`Order Count`)` `FROM main.sales.orders_metric_view` `GROUP BY ALL;` Toda measure precisa passar pela função MEASURE(), e [metric views não têm suporte a SELECT \*](https://docs.databricks.com/aws/en/uc-semantics/metric-views/bi-tools). Para ferramentas que não conseguem passar SQL customizado, o Databricks documenta uma wrapper view que embute as chamadas MEASURE() em uma view padrão, para que a ferramenta de BI a leia como qualquer tabela. Do lado do dbt, aqui está a lista de integrações nativas. ## Quais são os trade-offs e as armadilhas de implementação? Os principais trade-offs são lock-in em um formato de uma ferramenta, limites de como ferramentas externas conseguem consultar a camada, e o custo de manter o cache ou a materialização atualizados. Cada fornecedor documenta sua própria versão desses pontos. **Lock-in de formato.** LookML, TMDL, MetricFlow YAML, YAML da Snowflake e MAQL são todas linguagens diferentes para os mesmos conceitos. Mover um catálogo de métricas de uma para outra é uma reescrita. O Databricks resolve isso parcialmente com o [Genie Code, que importa um arquivo do Tableau ou do Power BI e recria o modelo de dados como uma metric view](https://docs.databricks.com/aws/en/uc-semantics/metric-views/bi-tools). **Limites de consulta de saída.** O Open SQL Interface do Looker é [só SELECT, sem JOIN, window functions ou subqueries](https://docs.cloud.google.com/looker/docs/sql-interface), e precisa de um projeto LookML apoiado em BigQuery. As métricas do Metabase [funcionam só no seu próprio query builder](https://www.metabase.com/docs/latest/data-modeling/metrics). Uma "camada semântica" que só o próprio produto consegue ler é um recurso de métricas, e isso é aceitável enquanto você só tem uma ferramenta de BI. **Duas camadas empilhadas.** A Microsoft diz que [empilhar um modelo semântico de terceiros sob um semantic model do Power BI geralmente não tem suporte](https://learn.microsoft.com/en-us/power-bi/connect-data/semantic-models-third-party) porque a combinação pode dar números errados. Se você adotar dbt ou Cube como a camada central, planeje o Power BI para lê-la através de uma integração nativa ou uma exportação, e mantenha o próprio modelo do Power BI fino. **Atualidade versus velocidade.** As [pré-agregações](https://docs.cube.dev/reference/core-data-apis/queries) da Cube, as materializações da Snowflake, a materialização incremental do Databricks, e o cache declarativo do dbt todos trocam atualidade por velocidade. A Snowflake torna essa troca explícita com um valor max\_staleness em segundos que você precisa escolher. **Limites de linhas.** A Cube [retorna no máximo 10.000 linhas por padrão e 50.000 no máximo](https://docs.cube.dev/reference/core-data-apis/queries). Uma camada semântica serve para respostas agregadas; extrações em massa ainda vão direto contra o warehouse. ## Quando um time deve centralizar uma métrica? Uma métrica pertence à camada semântica quando mais de uma ferramenta ou time a lê, ou quando um valor errado mudaria uma decisão. Um cálculo pontual em um único notebook pode continuar local. Os mecanismos que as ferramentas oferecem dizem como o "centralizado" deveria parecer. A especificação da Snowflake tem [verified queries com uma pergunta, o SQL que a responde, quem verificou e quando](https://docs.snowflake.com/en/user-guide/views-semantic/semantic-view-yaml-spec). A camada do dbt [define uma métrica uma única vez em cima de modelos existentes](https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl), então uma mudança na definição alcança toda integração que a consulta. O Metabase separa [métricas verificadas das não verificadas](https://www.metabase.com/docs/latest/data-modeling/metrics) nos seus planos pagos. Então uma métrica centralizada tem uma descrição, sinônimos que as pessoas usam para ela, um dono, pelo menos uma consulta verificada, e um histórico de mudanças no Git ou na ferramenta. Qualquer coisa a menos disso é um cálculo salvo, e vai desviar com o tempo. ## Resumo - Uma camada semântica guarda métricas, dimensões, relacionamentos, nomes de negócio e regras de acesso entre o warehouse e as ferramentas que o leem. - É uma camada diferente do warehouse, dos modelos dbt e dos cubos OLAP, mesmo quando um fornecedor entrega todos eles juntos. - A camada pode estar dentro da ferramenta de BI, dentro da ferramenta de transformação, dentro do warehouse, ou rodar como um serviço independente. A pergunta chave é se outras ferramentas conseguem consultá-la sem redefinir a métrica. - Ferramentas de IA de text-to-SQL precisam da camada semântica porque um esquema sozinho não carrega definições de métricas. - A métrica só é tão boa quanto as tabelas abaixo dela, então a ingestão precisa chegar completa e no prazo. A Erathos cuida dessa etapa de ingestão: conecte uma fonte, escolha um destino como BigQuery ou Databricks, e os dados chegam no warehouse prontos para o dbt e para a camada semântica em cima. [Experimente a Erathos grátis por 14 dias](https://app.erathos.com/signup).