Overview
A layered architecture, with hard boundaries
The healthy modern data stack has five layers, each with one job:
| Layer | Job | Examples |
|---|---|---|
| Sources | Capture events / records | Postgres, Salesforce, Stripe, Segment |
| Warehouse | Store at scale | Snowflake, BigQuery, Databricks, Redshift |
| Transformation | Raw → staging → marts | dbt, SQLMesh, Dataform |
| Semantic Layer | Metrics, dimensions, joins as code | dbt SL, Cube, LookML, AtScale, Stardog |
| Consumers | Surface answers | Looker, Hex, Streamlit, embedded React, LLM agents, reverse-ETL |
The no-overlap rules
- Marts ≠ semantic models. A dbt mart is a table; a semantic model declares which columns are measures, which are entities, and which dimensions are joinable. The semantic layer reads marts; it does not replace them.
- Semantic layer ≠ dashboard. The dashboard renders answers; the semantic layer produces them. A dashboard that embeds its own SQL is a dashboard bypassing the semantic layer.
- Semantic layer ≠ catalog. A data catalog (DataHub, Atlan, OpenMetadata) describes what exists; the semantic layer says what every term means and computes to. They complement each other.
Most semantic-layer projects fail by collapsing two of these layers. Keep the boundaries crisp.