In almost every data platform engagement, the hardest problem is not the pipelines or the lakehouse. It’s consistency.
Ask Finance and Sales to report last quarter’s revenue, using the same source data, and platform, and you often get two different numbers. It is not because anyone made a mistake, but because each team quietly encoded their own version of business logic into their dashboards, SQL scripts, or BI models. Revenue means one thing in Finance and something slightly different in Operations.
So how do we fix this gap? The traditional answer was: “Define it in your BI tool.”
Power BI has DAX models. Looker has LookML. Tableau has calculated fields. But those definitions stay inside the tool. They don’t travel to notebooks, SQL editors, APIs, or AI assistants. And multiple BI tools mean multiple places where someone is, or isn’t, maintaining the same metric.
Databricks Unity Catalog Metric Views + Genie change that.
Bringing Semantics Into the Platform
Databricks Metric Views move business metric definitions out of BI tools and into the data platform itself, governed by Unity Catalog which is accessible to every tool that connects to Databricks.
A Metric View is a YAML-defined object sitting on top of your curated data. It separates dimensions (Region, Product, Channel, Date) from measures (Total Revenue, Churn Rate, Margin %), each defined once with exact formulas and business rules. Every supported tool querying that Metric View gets the same number, calculated the same way, every time.
Unlike a standard SQL view, a Metric View defines logic once while the query engine handles computation at runtime against whatever dimensions the user requests. One total_revenue definition correctly handles slicing by Region, Product, Segment, or any combination, without pre-building every permutation.
Metric Views support:
- Composable metrics
- Filtered measures
- Window measures (Experimental)
- Multi-level joins
- Materialization for pre-computed aggregations (Experimental)
They also carry agent metadata, synonyms, display names, format specs, business descriptions, that Genie uses to resolve natural-language questions accurately.
Databricks is open-sourcing the core Metric View implementation in Apache Spark and has joined the Open Semantic Interchange (OSI) initiative, ensuring metric definitions stay portable across platforms. This allows your metric definitions to stay portable, without any vendor lock-in.
Because Metric Views live in Unity Catalog, the platform’s full governance model applies permissions, lineage and audit trails, enforced consistently across SQL editors, dashboards and conversational AI.
What Changes When Genie Runs on a Semantic Layer
Databricks Genie lets business users ask plain English questions and get answers instantly. No ticket to the data team or waiting for a new dashboard.
Without a semantic layer, Genie reasons against raw table structures, guessing column meanings, metric calculations and valid joins. Sometimes right, sometimes technically valid but often times “business meaningless.”
With Metric Views underneath, Genie resolves questions against governed, pre‑defined business metrics. A user asking about “revenue” hits the exact total_revenue measure definition, the same one Finance uses, the same one feeding the board pack. Genie works with a governed context rather than inferring intent from raw schemas. This improves accuracy significantly.
Result: Conversational analytics you can actually trust.
The Architecture in Practice
So, what does this look like when you put Metric Views into a real lakehouse? The key is that you don’t need to redesign your pipeline layers.
- Data engineering pipelines continue as normal: Bronze (ingestion) → Silver (cleansing) → Gold (curation).
- Metric Views sit on top of Gold, translating curated data into governed business metrics.
- Everything above, dashboards, SQL editors, Genie spaces, APIs, ideally consumes from Metric Views, not directly from Gold tables. (Today, Databricks AI/BI dashboards and Tableau can consume Metric Views natively. Power BI does not currently support direct Metric View queries. In the interim, Power BI can still query the Gold-layer tables that underpin Metric Views, so governed data remains accessible even without the semantic abstraction.)
This allows a seamless transition for multiple teams and processes. Engineers work with tables. Business users and AI tools work with metrics. Changes to business logic flow through one governed layer, instead of being scattered across dozens of downstream assets.

Our Accelerator: iAURA Semantic Data Modeler
The most common question we often get is: “How long does it take to build the semantic layer?”
The answer is simple: without acceleration, it will take longer than it should.
Mapping existing business logic into governed Metric View definitions is painstaking, especially when that logic is buried across Power BI models, Tableau workbooks and years of handwritten SQL queries.
iAURA Semantic Data Modeler solves this. It scans existing BI reports to extract measure definitions, dimension structures and business rules, then converts them into governed semantic definitions (for example, Databricks Metric Views) complete with agent metadata optimized for Genie accuracy.
But it doesn’t stop at “replicating what’s already in the dashboards”. It also analyzes the Gold-layer data model to automatically identify the domains, metrics, granularities and filters that are truly supported by the underlying curated data.
iAURA first builds a logical semantic view (a business-friendly model of entities, relationships, measures and dimensions). That logical layer can then be exported to multiple target platforms, including Databricks, so teams can standardize semantics once and operationalize them wherever analytics and AI are consumed.
iAURA is Persistent’s AI‑first platform for enterprise data operations, spanning Data Insights, Observability, Migrate, DataOps and Platforms, running in production at Fortune 500 enterprises managing petabytes of data.
What Customers Actually Gain
- One version of truth: Every tool and user draw from the same governed metric definition. The “why don’t our numbers match?” conversation stops altogether.
- Real self-service: Business users ask Genie, get the answer, ask a follow‑up, get answers to that too. Self‑service works when a semantic layer makes data trustworthy.
- AI readiness: Metric Views make business context explicit, governed and machine‑readable. That’s the foundation for trustworthy AI capabilities.
- Lower engineering overhead: One governed layer replaces parallel summary tables and BI‑tool‑specific metric definitions. This creates fewer objects, less logic replication and less variations.
What to Know Before You Start
Metric Views are powerful, but a few design constraints are worth understanding upfront:
- Mixing Metric Views and raw tables in the same Genie space can lead Genie to attempt joins that aren’t supported. For reliable results, structure Genie spaces around Metric Views (semantic domains) or alternatively, a tightly scoped set of base tables, but not both.
- Measures must be wrapped in the MEASURE() function when queried. Standard SELECT * does not apply. This is intentional as it forces explicit metric invocation rather than ambiguous column references.
These are not limitations in the traditional sense. They are design choices that enforce the governed consumption pattern. But teams coming from a “query anything” culture should plan for the shift.
Closing Thought
The semantic layer is not a new idea. What is new: it finally has a natural home, inside the lakehouse, governed by Unity Catalog, accessible to every tool and AI capability on the platform, which will soon be portable through open‑source Apache Spark.
For organizations serious about self‑service analytics, AI‑powered BI and a genuine single source of truth, this is the architecture worth investing in.
And for those who want to get there without a lengthy build cycle, iAURA Semantic Data Modeler is where the conversation starts.
For more details about iAURA 2.0, please visit here
Author’s Profile
Mandar Baxi
Associate Vice President , Technology
Chandraprakash Jain
Vice President, Technology






