Skip to main content

11. 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

Journey checklist​

  • Get started.
  • Before you start.
  • Infra setup.
  • Cost monitoring.
  • Data governance strategy.
  • Access your data.
  • Build the first pipeline.
  • Automation and orchestration.
  • Query and explore.
  • Databricks AI/BI.
  • Business Semantics
    • Understand the metric drift problem
    • Read and write a metric view in YAML
    • Hands-on lab: the same KPI returns the same number in SQL, AI/BI, and Genie
  • 12. Data Access Control (in progress)
  • 13. CI/CD and DevOps (in progress)
  • 14. MLOps (in progress)

UC Metric Views reference​

tip

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.

Deck - Metric Views

The problem: same KPI, different numbers​

Three teams report Q1 revenue. You get three numbers.

  • Sales: SUM(amount) WHERE status = 'closed' returns $4.2M
  • Finance: SUM(amount) WHERE invoice_date >= '2026-01-01' returns $4.0M
  • BI dashboard: SUM(net_amount) joined to a refunds table returns $3.8M

None of them is wrong. Each definition lives in a separate SQL file or BI tool, and nobody owns the canonical one. So leadership goes with whichever number they trust most that week.

The fix: define metrics once, in the catalog​

A metric view is a Unity Catalog object that holds the formula, the grain, and the filters for a KPI. SQL editors, notebooks, AI/BI dashboards, and Genie all call the same object, so they can't drift apart.

SELECT `Order Month`, MEASURE(`Total Revenue`)
FROM main.sales.orders_metrics
WHERE `Order Month` >= '2026-01-01';

Run that query in any tool. You get the same number every time.

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 YAML statement.
    • It lives inside a schema, at the same level as tables, views, functions, and models: UC three-level namespace.

  • 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​

PartWhat it doesExample
SourceThe Unity Catalog table or SQL query the metric reads fromsamples.tpch.orders
MeasuresAggregate expressions, the numbers themselvesSUM(o_totalprice)
DimensionsColumns you slice and group byDATE_TRUNC('MONTH', o_orderdate)
FilterOptional row scoping applied before aggregationo_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​