Biblioteca de conceptos
The Semantic Layer
A governed contract between physical data and consuming tools — defining metrics, dimensions, and access in one place so that every consumer (BI, ML, agents) reads the same business truth.
What it is
The semantic layer is the place where business logic — what revenue means, what churn means, what active customer means — is defined once and consumed by every downstream tool. It sits between the physical warehouse or lakehouse and the things that read from it: BI dashboards, ML feature stores, embedded analytics, and increasingly AI agents.
Done well, the semantic layer turns the warehouse into an API for the business. Done poorly — or skipped entirely — it leaves every consuming tool to redefine the metrics in its own language, with predictable consequences.
Why it matters
Three things break when there is no semantic layer:
- Metric drift. The same KPI gets defined three different ways in three different tools. Reconciliation becomes a quarterly fire drill.
- Governance gaps. Row-level security, column masking, and access policies have to be re-implemented in every consumer.
- AI hallucination at the metric level. When LLMs and agents query the warehouse directly, they invent metric definitions that sound plausible but do not match the business.
The third problem is the one that has changed the urgency. In a BI-only world, you could survive metric drift by editing the definitions in one extra tool. In an agentic world, the semantic layer becomes the contract that prevents agents from confidently giving wrong numbers to executives.
How it works
A semantic layer expresses three things in code:
- Entities and dimensions — the customer, the order, the contract; their attributes and how they relate.
- Metrics — measurements defined as expressions over entities; with explicit aggregation, time grain, and filters.
- Permissions — who can see what at the row, column, and metric level.
These are typically expressed in a YAML or DSL artifact, version-controlled, peer-reviewed, and CI-tested. The semantic layer compiles these definitions into queries on demand — so the consuming tool asks for monthly_recurring_revenue and the layer returns a SQL query that respects the canonical definition and the permissions of the requesting user.
For AI consumption, the semantic layer also exposes a metadata layer — natural-language descriptions, synonyms, and known query patterns — that lets LLMs reason about which metric to use without inventing one.
Three deployment patterns
| Pattern | Where the layer lives | Pros | Cons |
|---|---|---|---|
| BI-native | Inside the BI tool (LookML, Power BI semantic model) | Easy adoption | Locked to the tool, hard for non-BI consumers |
| Headless | Standalone service (Cube, dbt Semantic Layer, AtScale) | Tool-agnostic, AI-friendly | More infrastructure to run |
| Warehouse-native | Inside the warehouse (Snowflake Semantic Views, Databricks Unity Catalog metrics) | Single platform | Less mature, vendor-locked |
The headless pattern is winning in 2026 because of agentic consumption — but the warehouse-native pattern is closing fast.
Vendor comparison
| Aspect | LookML (Looker) | dbt Semantic Layer | Cube | AtScale | Snowflake Semantic Views |
|---|---|---|---|---|---|
| Architecture | BI-native | Headless on top of dbt | Headless | Headless | Warehouse-native |
| Definition language | LookML (proprietary YAML-ish) | YAML on dbt models | YAML / JS schemas | XMLA-compatible | SQL + metadata |
| AI/agent friendly | Limited via API | Yes — Metric API + GraphQL | Strong — REST + GraphQL + MCP | Strong — XMLA, REST | Improving |
| Governance | RLS in Looker | Inherits dbt + warehouse | RLS configurable | Mature enterprise | Native to Snowflake |
| Best for | Looker-centric organizations | dbt-centric organizations | Agentic + multi-consumer | Enterprise BI cubes (TM1 replacement) | Snowflake-only, simple |
LookML. The original modern semantic layer. Excellent inside Looker; less excellent outside it. The API exists but is not a first-class agentic surface. If you have already standardized on Looker, the practical move is to keep LookML as the source of truth and integrate other consumers through the API. Replacing it has rarely paid off in my engagements.
dbt Semantic Layer. The natural choice for organizations already running dbt — which is most of them. Definitions sit next to the models that produce the data, version control is automatic, and the Metric Flow language has become quite expressive. Performance and cost optimization on the query side are still maturing.
Cube. The cleanest headless implementation for agentic consumption. The API surface includes REST, GraphQL, SQL, and MCP — meaning agents can query the layer with the same precision a BI tool would. My current default for greenfield AI-aware semantic layers.
AtScale. Enterprise-grade, XMLA-compatible — the right answer when the organization needs to retire SSAS or TM1 cubes without retraining the analyst population. Heavyweight but mature.
Snowflake Semantic Views. New as of 2024-2025 and improving fast. The right answer for Snowflake-native shops that want a simple, governed metric layer without running another service. Watch the maturity curve.
Yoann’s take
I treat the semantic layer as the most important piece of architecture in any modern data platform — more important than which warehouse, more important than which BI tool. It is the contract that decides whether your KPIs survive contact with AI consumers. My current default for new builds is Cube when the organization is multi-consumer and AI-forward; dbt Semantic Layer when dbt is already the center of gravity; Snowflake Semantic Views when the platform is Snowflake-only and the team is small.
— Yoann
Related reading
External references
- Building a Headless BI Layer — Maxime Beauchemin
- The dbt Semantic Layer documentation — getdbt.com
- Cube documentation — cube.dev/docs