Business Semantics
You'll stop arguing about whose revenue number is right by defining KPIs once as Unity Catalog metric views, usable from SQL, dashboards, and Genie. Budget about 1 hour: 20 min reading, 30 to 45 min hands-on.
Prereqs: Unity Catalog foundations, Data governance strategy, Databricks AI/BI
UC Metric Views reference
Read this deck first. It walks the whole metric views surface: why they exist, how they're put together, and how dimensions, measures, and queries fit.
Benefits of Metric Views
| Benefit | What you get |
|---|---|
| One definition, no drift | AI/BI Dashboards, Genie, and SQL all read the same object, so the KPI can't come back different per tool. |
| Governed in the catalog | Access, lineage, discovery, and certification travel with the metric because it's a first-class Unity Catalog object. |
| One view replaces many | A single metric view answers many questions. You stop writing a near-duplicate view for every slice and filter. |
| Simpler queries | MEASURE() hides the joins and aggregations; the engine generates the SQL for you. |
| Query the metric, not the tables | You don't need to know the underlying schema layout to get the number. |
| Performance when it helps | The engine can materialize behind the scenes for speed when applicable. |
Who feels it most:
| Role | What gets easier |
|---|---|
| Data engineers | Stop maintaining a view per slice. Define the metric once and every downstream tool reads the same object, so fewer "why does the dashboard disagree with the notebook" tickets land on you. |
| Analysts | Query MEASURE(...) without reverse-engineering the tables or guessing join keys. The number is already certified, so you spend time analyzing, not defending. |
| Business users | Ask Genie or open a dashboard and trust the number. No more picking which team's revenue to believe this week. |
When a KPI looks wrong
Before metric views, a wrong number meant hunting across dashboards, SQL files, notebooks, and AI prompts to find whose definition drifted. With the metric defined once, the debug path is short.
- Someone reports the number looks off. Don't chase the consumer tool first. The dashboard and Genie read the same object, so they're not the source of the disagreement.
- Open the metric view in Unity Catalog. Lineage shows the source tables it reads. One object, one place to look.
- Check the measure and filter. Is the formula what you expect? Is the filter scoping the right rows? Most "wrong number" bugs live here.
- Check the source tables. If the formula is right, the data upstream is the suspect. Lineage points you at the table; check freshness and row counts.
- Fix the metric view definition. One change, one object. Every consumer (dashboards, Genie, SQL, AI apps) picks up the fix on the next query. No redeploying dashboards, no rewriting prompts, no chasing downstream copies.
The DevOps win is the blast radius: a fix touches one object and propagates to every consumer automatically. That's the difference between "define metrics once" as a slogan and as an operational property.
Where it sits
-
Unity Catalog:
- A metric view is a first-class Unity Catalog object. You discover it, permission it, and audit it the same way you would a table. The body is YAML wrapped in a
CREATE VIEW … WITH METRICS LANGUAGE YAMLstatement. - It lives inside a schema, at the same level as tables, views, functions, and models: UC three-level namespace.
- A metric view is a first-class Unity Catalog object. You discover it, permission it, and audit it the same way you would a table. The body is YAML wrapped in a
-
BI analytics and reports: the source of truth for first-party AI/BI or third-party apps.
- Dashboard, Genie space, or third-party app reads the metric view, which reads the UC tables.
Watch first
Metric View main parts
| Part | What it does | Example |
|---|---|---|
| Source | The Unity Catalog table or SQL query the metric reads from | samples.tpch.orders |
| Measures | Aggregate expressions, the numbers themselves | SUM(o_totalprice) |
| Dimensions | Columns you slice and group by | DATE_TRUNC('MONTH', o_orderdate) |
| Filter | Optional row scoping applied before aggregation | o_orderdate > '1990-01-01' |
So is a metric view just an OLAP cube?
No, though the family resemblance is real. Both think in measures, dimensions, and filters. The difference is where the work happens.
- OLAP cubes pre-aggregate and materialize data into a multidimensional structure. You pay storage and build time upfront, and you get fast slice-and-dice at query time.
- Metric views are a semantic layer, not a physical structure. They hold the metric logic (aggregations, dimensions, time grains) as SQL definitions in Unity Catalog. At query time the engine generates SQL and runs it against the underlying tables. There's no pre-aggregation and nothing materialized unless you configure it.
Go deeper
Next
- Do next: Hands-on lab, then 13. Data Access Control (in progress)
- Learn why: Unity Catalog foundations
- Reference: Business semantics in Unity Catalog