How can I eliminate duplicate metric logic across multiple BI tools?

Summary

• Duplicate metric logic disappears when you define each KPI once in a governed semantic layer and have every tool read that one definition, instead of re-implementing the same calculation in each BI tool.
• Unity Catalog metric views are a headless semantic layer: define measures, dimensions, and joins once as a governed catalog object, and AI/BI Dashboards, AI/BI Genie, SQL, and external BI tools all resolve the same logic.
• Metric views are defined declaratively and compiled to SQL at query time, so every consumer, human or AI, returns the same value for the same metric.
• Semantic metadata such as display names, comments, and synonyms travels with the metric, giving AI/BI Genie the context to map plain-language questions to the correct measure and dimensions.
• Dashboard-level joins, filters, and calculated fields can be promoted to a new metric view in one action, so logic built in a report becomes reusable across Genie, SQL, notebooks, and external BI tools.

How can I eliminate duplicate metric logic across multiple BI tools?

Define every metric once, in a governed semantic layer, and point each tool at that single definition rather than rebuilding the calculation inside each BI tool. On Databricks that layer is Unity Catalog metric views: you declare your measures, dimensions, and joins once as a governed catalog object, and AI/BI Dashboards, AI/BI Genie, SQL, and external BI tools all resolve the same logic. The duplication problem goes away because there is exactly one place the metric is defined, and one result any consumer can get.
The stakes are real. When the same KPI is re-implemented in several tools, each copy drifts on its own, and two dashboards end up showing different values for "revenue" or "active customers." A shared definition removes that drift at the source instead of reconciling it after the fact.

What is a metric view?

A metric view is a governed object in Unity Catalog that captures a business metric's full definition: its measures, the dimensions you can slice by, and the joins that assemble the underlying tables. It is a headless semantic layer, meaning it lives outside any single BI tool and carries no visualization of its own. You define it declaratively in YAML, authored with SQL or a point-and-click UI in Catalog Explorer, and the engine compiles and runs the underlying SQL at query time. Because it lives in Unity Catalog, it inherits access controls, lineage, and certification like any other governed asset.

What to look for in a semantic layer

If your goal is one metric definition across every tool, evaluate a semantic layer on these criteria:

Capability	Why it matters
Headless, tool-independent	The definition lives outside any one BI tool, so every tool reads the same logic instead of its own copy.
Governed and permissioned	Access controls, lineage, and certification apply to the metric itself, not just the raw tables.
Query-time resolution	Metrics compile to SQL deterministically at run time, so results are identical no matter who or what asks.
Semantic metadata for AI	Display names, comments, and synonyms let AI assistants map plain-language questions to the right measure.
External BI connectivity	Existing BI tools consume the same governed metrics through SQL, so you consolidate rather than re-key logic.
Promotion path	Logic built ad hoc in a dashboard can be lifted into the shared layer instead of staying trapped in one report.

How Databricks approaches it

Metric views are generally available and sit at the center of AI/BI. AI/BI Dashboards build directly on them, so every visual, filter, and comparison uses the same certified measures and dimensions. AI/BI Genie resolves natural-language questions from those same governed definitions rather than inferring logic on its own, which keeps conversational answers aligned with your dashboards. Semantic metadata such as synonyms is what lets Genie map a question like "revenue last week" to the correct measure and time dimension.
For the BI tools you already run, metric views are reachable through SQL: query a metric view with the MEASURE() function, expose it through a wrapper view, or use the built-in BI compatibility so an external tool reads the governed metric instead of its own re-implementation. See using metric views with BI tools.
The migration path is gradual. When you build a dashboard on tables that lack a metric view, the joins, filters, and calculated fields you create can be promoted to a new Unity Catalog metric view in one action, immediately making that logic available to Genie, SQL, notebooks, and external BI tools. Over time, the definitions that used to live in each tool converge into one governed layer. For the full approach, read Redefining the semantic layer for the future of BI and AI and Metric views: define your metrics once.

FAQs

Why do two BI tools show different values for the same metric?

Usually because the metric is defined separately in each tool, and the definitions have drifted. Centralizing the logic in one metric view that both tools resolve removes the source of the discrepancy.

Do my existing BI tools have to be replaced?

No. External BI tools can consume metric views through SQL, the MEASURE() function, or BI compatibility, so they read the same governed definition while your teams keep the tools they already use.

How does defining metrics once help AI answers?

AI/BI Genie resolves questions from the governed metric view rather than guessing the calculation, and semantic metadata such as synonyms maps business language to the right measure. Answers then match what your dashboards show.

Are metric views generally available?

Yes. Unity Catalog metric views and their integration with AI/BI Dashboards and Genie are generally available. Some authoring conveniences, such as UI-based creation, continue to roll out.