---
title: "What Is the Databricks Semantic Layer? Metric Views | Dawiso"
description: "Two dashboards, two revenue numbers? The Databricks semantic layer fixes it with Unity Catalog metric views that Genie, SQL, and BI tools all reuse."
url: "https://www.dawiso.com/glossary/databricks-semantic-layer"
language: "en"
---

November 4, 2026

databricks semantic layermetric viewsUnity Catalog metric viewsDatabricks Unity CatalogDatabricks Genierow filters and column maskssemantic layerApache Ossie

# What Is the Databricks Semantic Layer? Metric Views

The **Databricks semantic layer** is the set of Unity Catalog features that let teams define business metrics once and reuse them across Databricks, and its core is **Unity Catalog metric views**. A metric view is a governed Unity Catalog object, defined in YAML, that separates measures such as revenue or order count from the dimensions they are grouped and filtered by, so dashboards, Genie, SQL queries, and external BI tools all compute the same number.

Before metric views, a Databricks metric usually lived wherever it was first written: in a dashboard dataset, a notebook, a Power BI model, or a SQL view with the aggregation baked in. A plain view fixes the grouping, so "revenue by region" and "revenue by month" become two objects. A metric view keeps the measure separate from the grouping and lets the query engine generate the right calculation for whatever dimensions a user picks.

TL;DR

Databricks calls its semantic layer **Unity Catalog semantics**, announced at Data + AI Summit 2026 as **Unity Catalog Metrics**. Its building block is the **metric view**: a YAML definition with a source, joins, dimensions (now called fields), and measures, queried with the `MEASURE()` function. Metric views feed AI/BI dashboards, [Genie](https://www.dawiso.com/glossary/databricks-ai-bi-genie), SQL, notebooks, alerts, and tools such as Power BI, Tableau, and Sigma. Access follows Unity Catalog permissions; row filters, column masks, and ABAC policies on source tables are enforced at query time, which is why a metric view over such tables cannot be materialized. The semantic layer covers data in Databricks; business definitions and lineage across other platforms come from a [context layer](https://www.dawiso.com/glossary/context-layer-for-databricks).

## What Is the Databricks Semantic Layer?

Databricks documents metric views as the core implementation of Unity Catalog semantics, and in its June 2026 Data + AI Summit announcements it grouped them, with related features, under the name Unity Catalog Metrics. As of November 2026 the semantic layer is made of these parts:

- **Metric views**, the centralized definitions of measures and the fields they can be analyzed by.
- **Agent metadata** on metric views: display names, formats, and up to 10 synonyms per field or measure, which help AI tools such as Genie find the right measure when a user phrases a question differently.
- **Materialization** (public preview), which pre-computes and incrementally refreshes aggregations and rewrites queries to use them.
- **Multi-fact relationships** (public preview in dashboards) and relationships between metric views (beta), for models that combine several fact tables.

Around it, Databricks announced **Domains** (public preview), a **Glossary** (preview "coming soon" at the time of the announcement), and [Genie Ontology](https://www.dawiso.com/glossary/databricks-genie-ontology), a learned context layer that draws on Glossary, Domains, and usage signals. Metric views sit inside [Databricks Unity Catalog](https://www.dawiso.com/glossary/databricks-unity-catalog) like tables and views, so they appear in Catalog Explorer, have owners, and show up in lineage.

## How Metric Views Work

A metric view definition names a **source** (a table, view, or SQL query), optional **joins** in a star or snowflake shape, the **fields** users can group and filter by, the **measures**, and an optional **filter**. The key `fields` is the preferred name in the current YAML specification; `dimensions` is still accepted for backward compatibility. A shortened example from Databricks' documentation:

```
version: 1.1
source: samples.tpch.orders
joins:
  - name: customer
    source: samples.tpch.customer
    on: source.o_custkey = customer.c_custkey
fields:
  - name: Customer name
    expr: customer.c_name
measures:
  - name: Total revenue
    expr: SUM(o_totalprice)
filter: o_orderdate > '2024-01-01'
```

To use a measure in SQL, you reference it with the `MEASURE()` function and group by any field the metric view defines. The query engine generates the correct aggregation at runtime, which matters for measures such as ratios or distinct counts that cannot simply be summed across groups. Advanced measures cover composable metrics and window measures for trailing averages, period-over-period changes, and running totals. Metric views can be created with SQL DDL or in Catalog Explorer, which validates the YAML, and creating one requires Databricks Runtime 16.4 or later, with some features needing 17.3 or later.

## How Genie Uses Metric Views

Genie, the natural-language interface of Databricks AI/BI, is the main reason metric views have become an AI topic. In the current documentation Genie spaces are called **Genie Agents**, and each one can use up to 50 tables, views, or metric views as data sources. Databricks recommends metric views for Genie because they pre-define the metrics, dimensions, and aggregations, so Genie does not have to infer a calculation from raw columns.

Two details make the combination work in practice:

- **Synonyms** on fields and measures help Genie map a user's words to the right definition ("order time" to `order_date`, "turnover" to a revenue measure), and they are imported into Genie automatically.
- **The path works in both directions.** A team that first tuned a Genie Agent with instructions and example queries can create a metric view from the semantic context configured in that agent, which turns ad hoc knowledge into a governed object.

Metric views make Genie's answers consistent with dashboards and SQL, because all of them read the same measure. They do not make the underlying definition correct: if "active customer" means something different to sales and finance, the metric view encodes whichever version its author chose. For the wider picture, see [Databricks AI/BI Genie](https://www.dawiso.com/glossary/databricks-ai-bi-genie).

## Row-Level Security and Masking With Metric Views

Metric views use the same hierarchical permissions model as other Unity Catalog securables. Any user with at least `SELECT` on a metric view can query it, privileges granted on a catalog or schema cascade to the metric views inside it, and only the owner can edit the definition. Creating a metric view requires `SELECT` on its source plus `CREATE TABLE` and `USE SCHEMA` on the target schema.

Fine-grained security is handled in Unity Catalog, not in the metric view itself. **Row filters** and **column masks** restrict which rows and values a user can see, and **ABAC policies** (now generally available) apply filtering and masking consistently across many tables based on governed tags. These controls are evaluated at query time for the person running the query. That has one important consequence for the semantic layer:

- **A metric view cannot be materialized** if the view or any of its source tables uses row filters, column masks, or ABAC policies. Databricks explains that serving a pre-computed result to other users would bypass the per-user controls these features enforce.
- **Invoker-dependent expressions** such as `current_user()` or `is_member()` are not allowed in the filter, fields, or measures of a materialized metric view, for the same reason.
- **Collaborative editing** needs care: a group that edits a metric view needs `SELECT` on every table the view depends on, and the view can only reach data that group is allowed to select.

In practice teams choose per metric view: keep sensitive sources protected with row filters and masks and query them live, or materialize views over data that every reader may see. Testing a metric view with a restricted account before publishing it to Genie or a dashboard is worth the few minutes.

## Using Metric Views Outside Databricks

Databricks documents how to query metric views from external BI tools, in each case through SQL that calls `MEASURE()`:

- **Power BI:** the Databricks connector's Native query option in DirectQuery mode, or a wrapper view.
- **Tableau:** a Custom SQL connection, or BI compatibility mode enabled from the Initial SQL field.
- **Sigma:** a dataset backed by custom SQL.
- **Other JDBC and ODBC tools:** the tool's pass-through SQL option.

Databricks also announced an **import from Power BI and Tableau** (beta), which turns existing BI semantic models into metric views, and said that Metrics is open source in Apache Spark and Unity Catalog OSS and aligned with the Open Semantic Interchange, now **Apache Ossie**. That standard, which [Snowflake semantic views](https://www.dawiso.com/glossary/snowflake-semantic-views) and the [dbt Semantic Layer](https://www.dawiso.com/glossary/dbt-semantic-layer) also align with, is meant to let metric definitions move between platforms instead of being rebuilt in each one.

## Where the Databricks Semantic Layer Stops

Metric views solve consistency inside Databricks. Three questions sit outside their scope:

- **Data outside Databricks.** Metrics that depend on Snowflake, Microsoft Fabric, or operational systems need a definition that does not live in one platform's catalog.
- **Business ownership.** A metric view has a technical owner who can edit the YAML. Whether finance agrees with the formula is a governance question, answered in a [business glossary](https://www.dawiso.com/glossary/what-is-a-business-glossary) with named owners.
- **End-to-end lineage.** Unity Catalog lineage covers Databricks workloads. Tracing a number from a source system through pipelines and Databricks to a Power BI visual needs lineage that crosses platforms.

This is the difference between a semantic layer and a context layer, explained in [context layer vs semantic layer](https://www.dawiso.com/glossary/context-layer-vs-semantic-layer). The comparison with ontologies, relevant because of Genie Ontology, is in [ontology vs semantic layer](https://www.dawiso.com/glossary/ontology-vs-semantic-layer).

## How Dawiso Works With Databricks

Dawiso reads metadata from more than 30 sources, including Databricks, Snowflake, SAP HANA, Microsoft Fabric, and Power BI, and scanning is read-only and copies no rows. The [Databricks connector](https://www.dawiso.com/connectors/databricks) runs its metadata statements on a SQL warehouse and authenticates with an OAuth service principal, a personal access token, or an Azure managed identity.

On top of that metadata, the [business glossary](https://www.dawiso.com/product/business-glossary) holds the approved definition behind a metric and the person who owns it, and [lineage](https://www.dawiso.com/product/interactive-data-lineage) follows a value across platforms to the report that shows it. AI tools that support MCP, such as Claude and Cursor, query Dawiso through the [Dawiso MCP Server](https://www.dawiso.com/product/mcp) and get the definition, owner, and lineage along with the number. Metric views keep calculating the metric inside Databricks; Dawiso gives people and agents the business context around it. For how Databricks metric views compare with other options, see the [best semantic layer tools](https://www.dawiso.com/blog-post/best-semantic-layer-tools-2026).

## Conclusion

The Databricks semantic layer turns metrics into governed Unity Catalog objects that dashboards, Genie, SQL, and external BI tools share. Metric views remove the "two dashboards, two numbers" problem inside Databricks, respect Unity Catalog permissions and fine-grained controls, and, through Apache Ossie, are moving toward portability. What they leave to the rest of the stack is agreement on what a metric means across the business and visibility across every platform the data passes through.

## Sources

- Databricks - [Unity Catalog metric views](https://docs.databricks.com/aws/en/uc-semantics/metric-views/)
- Databricks - [Metric view YAML syntax reference](https://docs.databricks.com/aws/en/uc-semantics/metric-views/yaml-reference)
- Databricks - [Create a metric view](https://docs.databricks.com/aws/en/uc-semantics/metric-views/create)
- Databricks - [Manage metric views](https://docs.databricks.com/aws/en/uc-semantics/metric-views/manage)
- Databricks - [Materialization for metric views](https://docs.databricks.com/aws/en/uc-semantics/metric-views/materialization)
- Databricks - [Use metric views with external BI tools](https://docs.databricks.com/aws/en/uc-semantics/metric-views/bi-tools)
- Databricks - [Agent metadata for metric views](https://docs.databricks.com/aws/en/uc-semantics/agent-metadata)
- Databricks - [Curate an effective Genie Agent](https://docs.databricks.com/aws/en/genie-agents/best-practices)
- Databricks - [Row filters and column masks](https://docs.databricks.com/aws/en/data-governance/unity-catalog/filters-and-masks/)
- Databricks - [What's new in Unity Catalog at Data + AI Summit 2026](https://www.databricks.com/blog/whats-new-unity-catalog-data-ai-summit-2026) (June 2026)
- Apache Ossie - [Ossie enters the Apache Incubator](https://ossie.apache.org/updates/ossie-enters-apache-incubator/) (July 2026)
- Dawiso Help - [Create Databricks connection](https://help.dawiso.com/actual/create-databricks-connection/)

[See it in action](https://www.dawiso.com/product/business-glossary)

Business Glossary

Clear context is essential to ensure everyone interprets terms consistently and accurately.

### Table of contents

What Is the Databricks Semantic Layer?How Metric Views WorkHow Genie Uses Metric ViewsRow-Level Security and MaskingUsing Metric Views Outside DatabricksWhere the Databricks Semantic Layer StopsHow Dawiso Works With DatabricksSources

## Related Terms

### [What Is the dbt Semantic Layer? MetricFlow Explained](https://www.dawiso.com/glossary/dbt-semantic-layer)

The dbt Semantic Layer defines metrics once in YAML next to your dbt models, and MetricFlow turns them into SQL for BI tools, spreadsheets, and AI agents.

Read more →

### [What Is Databricks Genie Ontology?](https://www.dawiso.com/glossary/databricks-genie-ontology)

Databricks Genie Ontology is a context layer that grounds Genie in business meaning. Learn how Unity Catalog feeds it and where a cross-platform layer reaches.

Read more →

### [Context Layer for Databricks](https://www.dawiso.com/glossary/context-layer-for-databricks)

A context layer gives Databricks data the governed business meaning AI needs. Learn how it works with Unity Catalog and what a cross-platform context layer adds for AI.

Read more →

### [What Is the Tableau Semantic Layer? Tableau Semantics](https://www.dawiso.com/glossary/tableau-semantic-layer)

See where the Tableau semantic layer lives today: published data sources, Pulse metric definitions, and Tableau Semantics in Tableau Next on Data 360.

Read more →

### [What Is the Looker Semantic Layer? LookML Explained](https://www.dawiso.com/glossary/looker-semantic-layer)

LookML was built for Looker dashboards. Now the Looker semantic layer also feeds Gemini, AI agents through MCP, and BI tools such as Tableau and Power BI.

Read more →

### [Semantic Layer vs Traditional Data Marts](https://www.dawiso.com/glossary/semantic-layer-vs-data-marts)

Semantic layer vs data marts - how a central semantic layer defines each metric once for every connected tool, versus per-team marts that define their own.

Read more →