Contents
In brief
A semantic layer sits between physical data storage and consumers—BI tools, spreadsheets, AI agents. It is not a catalog or glossary but an executable contract for metrics, dimensions, and access rules. To scale AI analytics without “different answers to the same question,” this layer is becoming essential infrastructure—even though the product market is still maturing.
What happened
Axenix on Habr explains why “semantic layer” is back in every data-platform conversation. The idea is not new—data marts, presentation layers, metric spaces in BI—but AI agents and fragmented analytics stacks force a rethink.
The semantic layer (also Metrics Layer or Headless BI) defines business terms, metrics, dimensions, entity relationships, filters, and aggregations. When BI or an agent asks for “revenue by region this quarter,” the layer builds SQL from an approved model—the same way for every channel.
The key difference from data governance: glossaries and catalogs describe what a metric means and where it lives; the semantic layer executes the calculation via its own query-generation engine.
The article outlines four architectural patterns:
- BI-Native — semantics inside Power BI, Looker, SAP BO;
- DWH-Native — semantic views in Snowflake, Databricks;
- Metric Store — a dedicated metrics layer (e.g. dbt Semantic Layer) that pushes SQL to the database;
- Semantic Platform — caching, pre-aggregates, and routing (AtScale, Cube Cloud).
For AI analytics, Axenix recommends: the LLM interprets intent, the semantic layer executes logic. RAG supplies reference context but does not guarantee deterministic calculation—agents can still “invent” joins or formulas.
Why it matters
Without centralized metrics, every tool calculates differently: dashboards, Excel, and chatbots with raw SQL diverge on the same question. Scaling AI agents multiplies the problem—LLMs can generate SQL but should not be the source of business logic.
A semantic layer provides:
- One result across all consumption channels;
- Determinism instead of “every prompt, a new metric interpretation”;
- A bridge from natural language to physical tables without giving agents unchecked DWH access.
The market is still forming: few mature universal platforms exist; many teams already use embedded BI/DWH approaches without naming them. Open Semantic Interchange (OSI) standardizes model description, not a single implementation architecture.
In practice
If you are building AI analytics or connecting agents to corporate data:
- Do not confuse a data catalog with a semantic layer—documentation ≠ executable logic.
- Centralize metrics before wiring LLMs: formulas, grain, filters, and access in one place.
- Limit the LLM to intent recognition and mapping to model objects, not arbitrary SQL generation.
- Pick an approach for your stack: one BI tool may suffice with BI-Native; many consumers plus AI may need Metric Store or Semantic Platform.
- Plan for evolution: teams that define a semantic contract today can scale agents tomorrow without rebuilding analytics from scratch.
For BI without built-in semantics (e.g. Superset), an external layer effectively becomes the analytics backend—the tool sees a “table,” while a full model runs underneath.
Takeaway
The semantic layer is not slide-deck jargon but infrastructure for trustworthy AI analytics: shared metrics, reproducible calculations, controlled access. The market is young, but defining a metric contract now beats retrofitting after dozens of agents interpret the same tables differently.