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.

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, a learned context layer that draws on Glossary, Domains, and usage signals. Metric views sit inside 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.

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 and the 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 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. The comparison with ontologies, relevant because of Genie Ontology, is in 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 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 holds the approved definition behind a metric and the person who owns it, and 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 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.

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
• Databricks - Metric view YAML syntax reference
• Databricks - Create a metric view
• Databricks - Manage metric views
• Databricks - Materialization for metric views
• Databricks - Use metric views with external BI tools
• Databricks - Agent metadata for metric views
• Databricks - Curate an effective Genie Agent
• Databricks - Row filters and column masks
• Databricks - What's new in Unity Catalog at Data + AI Summit 2026 (June 2026)
• Apache Ossie - Ossie enters the Apache Incubator (July 2026)
• Dawiso Help - Create Databricks connection