Skip to main content

Creating and Consuming Metric Views

Summary

  • Unified metrics: Metric Views solve the problem of the same business metrics calculated five different ways by allowing you to define metrics once and reuse them.
  • Semantic layer: The YAML-based semantic layer sits between raw data and analytics, centralizing metric definitions in a human-readable, version-controlled format.
  • AI-assisted creation: The AI assistant helps create complex calculations, add filters, define dimensions, and generate synonyms and descriptions automatically.

Creating and Consuming Metric Views

Watch: Creating and Consuming Metric Views
In this video, you will learn how Databricks Metric View solves the problem of having the same business metrics calculated in different ways across an organization, which can kill trust in data and slow down decision-making. The solution allows you to define business metrics once and reuse them widely.
🎯 What You'll Learn:
How to create and govern metric views by defining metrics once in a centralized, governed semantic layer
How to use the AI assistant to easily customize a metric view
How to publish the metric view to Unity Catalog, certify it as a governed, trusted definition, and apply fine-grained access control using permissions
How metric views unify metrics across your entire data ecosystem, supporting data in cloud data lakes (Azure Data Lake, AWS S3, Google Cloud Storage) and federated sources like Snowflake
How to consume metric views consistently in SQL queries, dashboards, and Genie, ensuring everyone gets the same trusted, consistent answer
⏱️ CHAPTERS:
📚 Resources:
Databricks Documentation on Metric Views: https://docs.databricks.com/aws/en/metric-views/

Chapters

FAQs

Why is defining metrics consistently important?

When the same metric is calculated five different ways across an organization, it kills trust in data and slows decision-making. Metric Views ensure everyone uses the same verified definition.

What does the YAML definition in a Metric View contain?

The YAML definition includes structured fields, filters (like focusing on direct customers), dimensions (like account ID and sales region), and calculated measures. This becomes the centralized definition.

What is a semantic layer?

A semantic layer is a centralized, governed definition of your organization's metrics that sits between raw data and analytics tools on the Databricks Data and AI platform. It provides a single source of truth for how metrics are calculated, defined through YAML that includes filters, dimensions, and measures. By publishing metrics to Unity Catalog and certifying them as trusted definitions, teams can ensure that everyone across the organization uses consistent calculations, eliminating discrepancies and building trust in data.

How can AI know which definition of a metric to use?

When metrics are published to the Databricks Data and AI platform's semantic layer through Unity Catalog, AI tools like Genie have access to the certified definitions with their descriptions and synonyms. This enables the AI to understand and apply the correct metric definition when answering user questions. The semantic layer's structured format includes alternative names for metrics, making them discoverable through natural language queries without ambiguity about which calculation to apply.

Can business intelligence dashboards and AI agents use the same semantic layer?

Yes, the Databricks Data and AI platform's semantic layer supports consistent metric consumption across SQL queries, dashboards, Genie AI, and alerts. Once a metric view is published to Unity Catalog with fine-grained access controls, any tool that queries the underlying data can reference it. This unified approach ensures that dashboards, AI agents, and business users all operate from the same verified metric definitions with proper governance and lineage tracking.

Full transcript

0:00 <Untitled Chapter 1>

Hi, I'm a senior technical marketing engineer here at Data Bricks. Ever notice how certain metrics get calculated five different ways across your entire organization and no one ever seems to agree which number is correct? That totally kills trust in your data and it slows down decision- making. Metric view solves this by allowing you to define business metrics once and reuse them pretty much anywhere. In this two-part demo, I'll first show you how to create and govern metric views and then I'll walk you through how to consume them in SQL queries, dashboards, and Genie.
Let's get started. Let's start with the accounts data set here in Catalog Explorer. This contains our customer accounts data. Things like sales figures, regional breakdowns, customer status, and life cycle information. It's the kind of data that multiple teams across the organization need to analyze, but often in different ways. From here, I can create a metric view directly from the data set. And you'll notice the platform automatically generates this YAML definition for us.

1:02 Creating a Metric View and Semantic Layer

This is really the foundation of what makes metric views powerful. It's a centralized governed semantic layer that sits between your raw data and your analytics. Instead of everyone writing their own SQL or making their own calculations, we're defining metrics once in a way that's both human readable and version controlled. Now, let me customize this a bit. I'll add a filter here to focus only on direct customers. This way, anyone using this metric view will automatically be working with the right subset of data.

1:33 Customizing with Filters, Dimensions, and Measures (Using AI Assistant)

I also have key dimensions like account ID, sales region, and life cycle stage. For the more complex stuff, I can lean on the AI assistant. Let me ask it to create a ARR value buckets for us. This gives us automatic segmentation without having to manually write case statements. I'll also add some calculated measures here like ARR per commit account. Again, the assistant can help generate these if I describe what I need.
What's great about the assistant is that it tells you what it's going to do and also adds a summary of what it did. Perfect. It looks like the assistant correctly added the ARR per commit account as a measure. I can go ahead and accept that addition and move on to adding a 3mon trailing ARR. Again, the assistant generates a plan and executes it just for me. One more thing I'll do is use the assistant to add synonyms and descriptions.
This makes the metric view more discoverable. So if someone searches for annual revenue, they'll still find our AR metric. What's important here is that this isn't just for data engineers. Business analysts can work in this interface, too, which means the people closest to the business logic can actually help define and refine these metrics. Once we're happy with the definition, I'll save and publish this into Unity catalog.
Now it lives right here in the catalog schema alongside our raw tables and we can certify this metric view so everyone knows this is a governed trusted definition. Let's look at the permissions tab. This is where fine grained access control comes in. We can specify exactly who has select access to query this metric view or manage access to modify it. This ensures that sensitive business metrics are only visible to the right people.

3:27 Permissions, Lineage and Insights

Over in lineage, we can see all the upstream dependencies which raw tables feed into this metric view and any downstream usage like dashboards or notebooks that are consuming it. And if we check insights, we get visibility into who's actually using this metric view most frequently, which dashboards it powers, and where it's being referenced. This makes it easy to understand the impact and adoption of your metrics. One of the strengths of this approach is connectivity.
Metric views aren't limited to just data bricks native tables. We support building metrics on top of data across cloud data links like Azure data lakeink, AWS S3, Google Cloud Storage. And so whether that data lives in managed tables, external tables, or federated sources, it doesn't matter. For example, here's a metric view we've built on a Snowflake federated table. The point is your semantic layer can unify metrics across your entire data ecosystem, not just one platform.

4:14 Connectivity and Cross-Platform Unification

Now, let's move on to how we can consume these metric views in data bricks. You're a business analyst who needs to answer questions about account performance. Your data team just published some new metric views and you want to see how they make your analysis faster and more consistent. First, you can query metric views using the SQL editor. What's nice here is that I'm just writing SQL against the metric view like it's any other table.

4:49 Consuming Metric Views in SQL Queries

But all the filters, calculations, and business logic that the data team defined are already baked in. I don't have to remember to filter for direct customers only or recalculate trailing 3-month ARR myself. It's all consistent and ready to go. Let me run a few real business questions. First, I want to see ARR distribution by sales region and ARR bucket over the past year. There we go. Clean, consistent results. Now let me pull trailing 3-month ARR and compare the number of committed accounts versus total accounts.
Again, the calculations are already handled. I'm not worried about whether I'm using the right formula or the right time window. The metric view ensures I'm getting the same numbers everyone else sees when they ask this question. Now, let me drill into the semantic model itself so you can see what's really powering these queries. Look at these dimensions. They're declared explicitly to support slicing and dicing. Things like account vertical, life cycle, stage, sales region.

6:12 Drilling into the Semantic Model

This isn't just metadata sitting there for documentation. These dimensions are what enable me to analyze the data from multiple angles without writing complex joins or group buys. We also have hierarchies built in for timebased analysis. There's year greater than quarter greater than month greater than date. So I can start at a high level and drill down naturally to daily details when I need to investigate something specific.
And these measures ARR business metrics and accounts they encapsulate all the business logic in a reusable governed form. The formula for trailing 3month ARR lives here in the metric view, not scattered across hundreds of different dashboards and notebooks where everyone might calculate it slightly differently. What's important to understand is that this model is abstracted in the metric view layer. It's not embedded in the raw data sets themselves.
That separation means the data team can evolve the business logic without touching the underlying tables and it ensures governance. We have one source of truth for how we calculate these metrics. Another way we can consume metric views is by setting up alerts. I can set up alerts on these metric views to monitor business critical thresholds. I can create an alert on any SQL query that references our metric view. For example, let me set up an alert for when our open revenue crosses a million dollars.

7:39 Consuming Metric Views with Alerts

I'll author the alert query here in the SQL editor using the measure function to evaluate our revenue measure. Notice I'm explicitly specifying the dimensions I want to monitor. You can't use select star with metric views, which actually helps because it forces you to be clear about exactly what you're tracking. Once this alert is set up, it runs on a schedule and notifies the right people when the threshold is crossed.
So, our revenue team gets proactive alerts based on the same govern metrics everyone else is using. No risk of someone setting up their own alert with a different calculation that gives conflicting signals. Also, metrics can show up as an agnostic semantic layer. Here's where metric views really shine. They're not just for SQL queries and data bricks. They're an agnostic semantic layer that powers analytics across our entire stack.

8:41 Consuming Metric Views with Dashboards

Now, let's look at dashboards. When I create a new dashboard, I can select a metric view directly as my data source. I don't even need to write SQL if I don't want to, just point and click. Or if I want more control, I can reference the metric view in a SQL query right here in the dashboard editor. Either way, I'm working with those govern metrics. And here's a workflow I really like. If I'm exploring a raw data set in a dashboard and I realize this analysis would be useful for others, I can export it to a new metric view right from here.
The governance workflow is built directly into the interface. I don't have to jump to a different tool or file a ticket with the data team. Finally, let's talk about Genie. This is where things get really interesting. I'll create a Genie space using our accounts metric view as the foundation. Watch what happens. Automatically, Genie builds a knowledge store from the metric view. It pulls in all the measures, dimensions, descriptions, and synonyms that were defined when the metric view was created.

9:34 Consuming Metric Views with Genie

This is the foundation of Genie's semantic understanding. It already knows that ARR means annual recurring revenue, that we segment accounts into value buckets, what our life cycle stages mean, and what dimensions are available for slicing the data. But the semantics go beyond just what's in the metric view. Genie can be enhanced with explicit instructions. For example, I can teach it how our sales team talks about committed accounts versus prospect accounts or clarify specific business terminology that's unique to our organization.

10:00 Genie's Semantic Understanding and Continuous Learning

Now, let me ask Genie a question in plain English. Show me ARR by region for committed accounts. Perfect. It understood the business context, knew which metric view to query, applied the right filters, and gave me a clean visualization. Here's where it gets really powerful for ongoing improvement. If I ask a question and Genie's interpretation isn't quite right, I can give feedback with a thumbs up or thumbs down right here in the UI and provide a correction.
That feedback immediately updates the Genie knowledge store. So if I clarify that when I say top accounts I mean the top 10% by ARR not just the highest single account Genie captures that and applies it to future queries not just for me but for anyone else on my team who asks similar questions. This is continuous semantic learning as users across the organization interact with Genie. The system captures how we actually talk about the business, what terms we use, what we expect to see when we ask certain questions.
The model evolves and stays aligned with our business language. And critically, this means Genie isn't just executing SQL queries against column names. It's operating with business aare behavior. And there you have it. No more debates about which calculation is correct. With metric views, you define metrics once and everyone across your organization gets the same trusted answer. Whether they're quering in SQL, building dashboards, or asking Genie any questions.
That's how you build confidence in your data on data bricks.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.