If you have ever asked "why does Marketing report different revenue numbers than Finance?" — you have experienced the problem that semantic layers solve.
A semantic layer is an abstraction that sits between your raw data and your business users. It translates complex database tables and joins into business concepts that everyone understands: revenue, customers, orders, churn rate.
The Problem: Inconsistent Metrics
In a typical organization, data lives in a warehouse like Snowflake or BigQuery. When someone wants to answer a business question, they write SQL — or ask an analyst to write SQL for them.
The problem? Everyone writes slightly different SQL:
- Marketing calculates revenue including refunds
- Finance excludes refunds and discounts
- Sales includes pending orders
- The CEO gets three different numbers in three different dashboards
This is not a people problem. It is a systems problem. Without a single source of truth for metric definitions, inconsistency is inevitable.
The Solution: A Semantic Layer
A semantic layer solves this by defining metrics once, in a central place, with clear business logic. Instead of writing SQL directly, users query the semantic layer, which translates their request into the correct SQL.
Think of it as a translation layer:
- User asks: "What was revenue last month?"
- Semantic layer knows: Revenue = SUM(order_total) WHERE status = 'completed' AND refunded = false
- Database receives: The correct SQL query, every time
Key Components of a Semantic Layer
1. Metrics
Metrics are the quantitative measures your business tracks: revenue, orders, customers, conversion rate. A semantic layer defines exactly how each metric is calculated.
2. Dimensions
Dimensions are the attributes you use to slice and filter metrics: date, region, product category, customer segment. The semantic layer defines which dimensions can be used with which metrics.
3. Entities
Entities are the business objects in your data: customers, orders, products, employees. The semantic layer understands how these entities relate to each other.
4. Time Grains
Most metrics need to be analyzed over time. A semantic layer defines valid time grains (daily, weekly, monthly) and handles date logic correctly.
Popular Semantic Layer Tools
dbt Semantic Layer (MetricFlow)
MetricFlow is dbt's open-source semantic layer engine. You define metrics in YAML files alongside your dbt models, and MetricFlow generates optimized SQL for any query.
The advantage of MetricFlow is that your metrics live in the same repository as your data transformations. Everything is version-controlled, tested, and documented together.
Looker (LookML)
Looker pioneered the semantic layer concept with LookML, a proprietary modeling language. While powerful, LookML requires significant investment to learn and locks you into the Looker ecosystem.
Cube
Cube is an open-source semantic layer that works with any BI tool. It uses a JavaScript-based schema and offers pre-aggregations for performance.
Why dbt Teams Choose MetricFlow
If you already use dbt for data transformation, MetricFlow is the natural choice:
- Same repository: Metrics live alongside your dbt models
- Same workflow: Define, test, and deploy metrics with your existing CI/CD
- Open standard: No vendor lock-in, portable metric definitions
- Growing ecosystem: BI tools are adding MetricFlow support
How Metricly Uses the Semantic Layer
Metricly is built on MetricFlow, giving you the best of both worlds: the governance of a semantic layer with the accessibility of natural language queries.
With Metricly, you can:
- Connect your existing dbt project — no migration needed
- Ask questions in plain English: "What was revenue by region last quarter?"
- Build dashboards that always show consistent, governed metrics
- Share insights with stakeholders who never need to write SQL
Getting Started
Ready to implement a semantic layer? Here is how to start:
- Audit your current metrics: Document how different teams calculate key metrics today
- Identify discrepancies: Find where definitions differ and decide on the source of truth
- Define metrics in dbt: Use MetricFlow to codify your metric definitions
- Connect a BI layer: Use Metricly or another MetricFlow-compatible tool
- Deprecate direct SQL: Gradually move teams to querying via the semantic layer
Conclusion
A semantic layer is not just a nice-to-have — it is becoming essential for data teams that want to scale. By defining metrics once and making them accessible everywhere, you eliminate inconsistency, reduce time-to-insight, and empower everyone in your organization to make data-driven decisions.
If you are using dbt, MetricFlow makes it easy to add a semantic layer to your existing stack. And with tools like Metricly, you can make that semantic layer accessible to everyone — no SQL required.
Want to see how Metricly works with your dbt semantic layer? Start your free trial or book a demo with our team.