Semantic layers are finally getting opinionated enough to be useful
Summary
Semantic layers are finally getting opinionated enough to be useful
The semantic layer has been around for years. It's the business translation sitting between raw data and the decisions people actually make. What's changed is that AI now makes it necessary.
Look at the state of things. 40% of Databricks users still don't use dbt. Every BI tool in the org carries its own definition of "revenue." You end up with dozens of dashboards and none of them agree.
AtScale, Stardog, Databricks Unity Catalog Metrics, and the rest fix this by letting you define a metric once and then use it everywhere: SQL, DAX, MDX, Python, even AI agents. The point was never no-code BI. It's no-drift semantics, where a metric means the same thing to analysts, ML engineers, and LLMs. Your dashboards and your model training data should both pull from the same "revenue."
The AtScale plus Databricks "Semantic Lakehouse" model gets this right. No moving data around, automatic aggregates, one set of metric definitions, and direct integration with Unity Catalog and Spark. That gives AI a stable source of business truth to stand on.
My new TIL post, "Semantic Layer Solutions in Modern Data Architecture" covers vendors (AtScale, Stardog, Timbr), integrations (Unity Catalog Metrics, Power BI), and the Databricks + AtScale partnership that makes "semantic lakehouse" more than a buzzword. It explains what a semantic layer is, why 40% of Databricks users still don't use dbt, and how tools like AtScale and Databricks Unity Catalog Metrics are working to solve the "truth problem" in analytics.
The semantic layer question reaches well past BI. Once "revenue" means the same thing in SQL that it does in DAX, and your Python code agrees, and even the MDX crowd gets the same number, you've built a base for both human and machine reasoning. That consistency carries over to dashboards etc.
"AtScale's main selling point is that it stops data from moving..." It queries data in place within Databricks, creates and manages aggregates independently, accelerates performance through intelligent caching, and maintains a single source of truth without duplication. (AtScale x Databricks blog)
You create drift the moment you pull data into a BI cube. AtScale's Databricks integration closes that loop by bringing together technical lineage (through Unity Catalog) and business-facing semantics. It's foundation work, the kind AI architectures get built on.
The next step is to use the same layer to train and test the AI model. The same "revenue" metric that powers dashboards should also feed model features and evaluation metrics. That's how you stop AI from learning about the business from one definition while executives use another.
Pushback
- "Single source of truth" is just a saying unless you hard-gate BI against the layer. You'll end up with "two truths and a hope" if teams can still point tools directly at warehouse tables.
- MDX-to-DAX-to-LookML equivalence sounds clean in theory. Edge-case functions and time-intelligence logic do not map one-to-one. Set aside time for testing.
- Vendor lock-in is real. If your BI surface is small, Unity Catalog Metrics and dbt/MetricFlow-style semantics might be "good enough." When you're "multi-surface and politically decentralized," AtScale is worth it.
See the full TIL for vendor details, query protocols, and implementation patterns.