Metric Views—What They Are, How They Work, and How to Model Them

Summary

Metric Views are a new Databricks feature that defines measures and models directly in Unity Catalog, making metric definitions available to Notebooks, Databricks SQL, AI/BI Dashboards, and AI/BI Genie from a single governed source of truth.
By placing the semantic layer inside Unity Catalog rather than in a separate BI tool, Metric Views eliminate the language divide between data engineers working in Python and SQL and analysts working in DAX and Power Query.
Metric Views are structured in YAML and work best on a clean Unity Catalog foundation; modeling choices—whether to build small specialized views or broader shared ones—directly affect what Genie returns and how dashboards behave.

Metric Views—What They Are, How They Work, and How to Model Them

Databricks has always had a strong foundation for data engineering, but one thing has been missing: a semantic layer that lives inside the platform. Metric Views finally change that. With Metric Views, measures and models are defined directly in Unity Catalog and reachable from Databricks Notebooks, Databricks SQL editor, AI/BI Dashboards, and AI/BI Genie. Data engineers and analysts are finally working from the same definitions, no more translating DAX back into SQL to understand what a number means. In this video we will walk through what Metric Views are and what the setup looks like in practice. Then we will look at the modeling decisions, whether to build small specialized views or broader shared ones, how those choices affect reuse and consistency, and how they affect what Genie returns and how dashboards behave. New to metric views or already using them, you will leave with a clearer picture of how to approach them.
Talk By: Julia Forde, Databricks SME & Databricks MVP, Knowit ;

Chapters

FAQs

What are Metric Views in Databricks?

Metric Views are a Databricks feature that defines measures and models directly in Unity Catalog, creating a shared semantic layer accessible from Notebooks, the Databricks SQL editor, AI/BI Dashboards, and AI/BI Genie. They use YAML-based definitions and support measures, dimensions, tags, and PII classification through the Databricks UI.

How do Metric Views solve the semantic layer divide between data engineers and analysts?

Traditionally, the semantic layer lived inside BI tools like Power BI, where analysts defined metrics in DAX while data engineers worked in Python, SQL, and Spark—creating silos and communication gaps. Metric Views move metric definitions into Unity Catalog so both roles work from the same definitions, eliminating the need to translate DAX back into SQL to understand what a number means.

Why does placing the semantic layer in Unity Catalog matter for AI?

AI agents and Genie need trusted, consistent metric definitions to answer questions accurately. When metrics are defined in a separate BI tool, AI systems lack access to governed definitions. Metric Views in Unity Catalog make those definitions reachable by Genie and other AI consumers on the Databricks Data and AI platform.

What modeling decisions matter most when designing Metric Views?

The key trade-off is between small specialized views—focused and easy to maintain but requiring more of them—and broader shared views that maximize reuse and consistency but can become harder to manage over time. These choices affect what Genie returns when answering natural language questions and how dashboards behave when querying the same measures.

Full transcript

[00:08] My name is Julia. I'm a data bricks MVP. I work in a consultancy based in Norway and I focus a lot on data warehousing, data engineering. I have a Microsoft background doing SQL servers and databases before I moved over to the
[00:22] data brick stack approximately three and a half years ago. So um all the stuff I'm going to do talk about today are also my own personal
[00:34] opinions. It's nothing that you should uh arrest data bricks on. I'm also sharing my thoughts and uh perspectives on metric views and how they're going to evolve and how I like to work with them
[00:48] myself. So why this session? I feel like the semantic layer is a point of in time where all all data warehouses all data
[01:01] platforms are in a position where we're now changing how we are viewing the semantic layer. We're going from BI being just reports to going over to that BI is also AI and therefore we also have
[01:15] to change how we're working with the semantic layer. So let's take a little recap. Uh the traditional semantic layer is how we're
[01:27] used to defining it in cubes, multi-dimensional models and later tabular models. It has been very much so that the data warehouse or the lakehouse has been divided into its own tool while
[01:42] you're doing your semantic layer and your reporting in a separate BI tool. And this also means that your semantic model where you actually create all your relationships and do all your measures
[01:56] are very much close to all your reports and your dashboards. And this approach has actually made a lot of sense because BI and reporting has been about
[02:08] dashboards until now. But you also have some problems here or challenges because when you're having the semantic layer in its own tools, it also means that your
[02:20] people working on this have are talking different languages. The analysts can for example work in tools like PowerBI and they talk about Power Query, they talk about DAX while you have a data
[02:34] engineer that is mostly interested in Python, SQL, Spark. This creates kind of a divide in how you're working with your data and it's creating a silo between not only the data itself but also the
[02:48] team people that are working on the tech and it lowers the threshold for people to actually ask questions to their colleagues or people on the same team.
[03:03] So the semantic layer has traditionally been built for that reports was the one way to really access our data. That has been the main way we have worked with the semantics and it's also been very
[03:15] much like the analyst builds the models they build the reports and then the business users they just consume your reports. But this is changing. We see now that
[03:27] data is kind of become a very hot topic and everyone wants to do data now because it's easier. We have tools that may enable more and more people to do uh
[03:40] do anything to have to do with data. That also means we have more ways to use our data. we have more use cases and we get as a organization matures you also
[03:52] get more and more complex questions by your users you're the questions are getting more detailed so and then came AI the wave of AI and
[04:04] we've seen it in the keynotes I don't know how many time I've heard the or word agent these days but a couple of hundred at least uh and what happens When you add AI into this mix, when you
[04:18] add AI, you get multiple use cases. You get the chat with your own data. You get AI assistance to enable more and more people to do development. And you also have these agents.
[04:31] And one of the hardest things within data engineering now is that all my business user, all my customers, they want to be able to chat to their own data. Everyone wants to do it because they see it online, they see it in
[04:44] newspapers, it's everywhere. So I that also means I get this question quite a lot. Do we still need dashboards? We can just chat to our own
[04:56] data. You can have Genie, you can have C-Pilot, you can have other tools to chat with your data. And my take on this is you definitely do still need your dashboards, but you do no longer need
[05:09] dashboards to answer every use case and every questions your users have. I would say that dashboards they still make sense. They still make sense for core KPIs that is very very important that
[05:24] your uh organization gets right. total revenue, how many customers you have. These type of questions still needs to be rooted in a way that's easier to find and it also makes sense that people are
[05:36] looking at the same thing. So questions that pop up all of the time should be in a dashboard. It's also good for operational monitoring and basically stuff that uh people use.
[05:49] And then you also have the chatting to your engine tools like Genie is a much better fit for ad hoc and oneoff questions. Up until now when you're talking about
[06:01] BI every question has a tendency to became its own report. that report is usually never accessed again but the report
[06:13] still lives on right and then you end up with having I don't know how many thousand reports you can end up having in uh organization and that is basically because the report wasn't something that
[06:25] you were going to use over and over again. It was more of this one question and it also makes sense for things like you have some users where most of them
[06:37] only need a certain granularity of information and then you have some super users on th those data that needs to dive a bit further. So kind of these deep dive questions make sense with
[06:49] chatting with your own genie. So if you pair a dashboard and then you can for the questions that are very more specific than the others, you could just do chatting with your own data to answer those. I also use it a lot actually for
[07:04] myself as a developer. I use uh chatting with your own agent uh chatting with your own data to actually know how I'm building reports. At some point I'm just guessing I'm just guessing what my users
[07:18] actually want to see in my reports and or a couple of people have told me what they are interested in. So if you give uh genie for example to a group of people and just say this genie isn't
[07:31] totally ready but I need to understand what information you're interested in. Then I can use and analyze those conversations has you my users has to genie and then create a dashboards
[07:43] afterwards to kind of make sure that that is a dashboard people are actually interested in. Yes. And even though many people think AI is magic and it just works, we all in
[07:58] this room know that that is not the case. Uh I think that AI always it just scales whatever you did. If you did something bad, AI will just scale confusion.
[08:13] So if you give it bad data, you will get bad answers. If you have unclear KPIs or a lot of KPIs that are almost similar, you will also get different answers.
[08:25] And AI also tends to be very certain, right? You don't ask your AI and then it says Nia I'm no this answer I can't answer right it will just say this is
[08:37] the answer and then you have to prompt it again a couple of times just like ah are you sure and then maybe it says no I'm not totally sure so what does this actually mean
[08:50] this means that your AI and your agent they also need a semantic layer the same the way our reports and reporting have needed AI
[09:02] there's also the case for your agents or chatting to your own data. So both use cases actually need a semantic layer. So first of all why am I excited about
[09:15] metric views? When they first came out a lot of people were like yeah but I can't do exactly the same thing as PowerBI. I can model more complex stuff in PowerBI. And the truth is, yes, you probably can
[09:28] because this is a much older tool. But that is actually not the reason I'm excited about metrics views. Because what metric views actually does and why it's important is actually where
[09:41] they live. The placement of the metric views is for me the game changer. So let's look at the setup again. We went through this on the uh traditional um semantic layer and you we have talked
[09:56] about that today measures and models they are calculated at the end of your pipeline and they're also not accessible from your platform. The only thing that actually uses your semantic layer and
[10:08] your measures and your models are your reports. What metrics views actually does is that it takes this semantic layer. It takes the information about your data. It takes your KPIs and it puts it in the
[10:21] heart of your data platform. It puts it inside Unity catalog. And that means a couple of things. It means that your model now is reachable from anywhere in
[10:33] your platform, not just the reports. It's also accessible from Genie SQL editor notebooks and I think that it also means that we're kind of one step
[10:45] closer to getting a single source of truth because you can actually reuse your KPIs further back in the stack when my analyst now have a problem with a measure. I no longer have to take a DAX
[10:57] and translate it into SQL and then kind of run that query all the way in the back. I can query my measures from within my platform directly. It also has
[11:09] they're also based on SQL which means that these two people can now start talking more the same language. SQL is the most intuitive of the languages to learn.
[11:22] That's proven by a lot of stuff. It's a bit more logical than DAX. Um so it can be a good way to kind of also unify the roles in your team. So how do the metric views actually look
[11:36] in practice? Uh the metric views they are defined in SQL and YAML and a lot of people when I say YAML they're like ah no but the YAML itself is actually quite
[11:50] intuitive to understand because the YAML just gives you the structure of how and in what order you're writing your SQL. So you have this structure where you define your sources. Then you have
[12:02] dimensions. Think of them as columns to a table. You have joins and then you have measures that are actually calculation that end up in one specific number.
[12:15] I also think that something data bricks generally is doing these days when they're uh developing tools if that's uh late flow designer or
[12:27] spark clarity pipelines or metric views or dashboards is that they have this birectional way of thinking. they have still the way you have the option to do the code and
[12:40] then they're all now trying more and more to put a nice UI on top of it. So you can actually create your uh metric views both from a low code option inside the tool but you can also write your
[12:53] JAML from scratch. So it's pretty much up to you if you want to write all the code or if you want to use uh the low code interface. We're going to take a quick look at that uh on the next slides.
[13:05] But as any model, it relies on big good metadata. And if you have done all your stuff in Unity catalog good and correctly, your metric views will be a lot better. And what is nice is that
[13:19] because it's in the platform, usually your metadata in the platform in Unity catalog are better than if you have to do it again in a separate tool. So it kind of uses whatever is of
[13:31] information inside there to create a good model and it's also integrated into my favorite datab bricks tool the unity catalog. It means that you have a similar experience. You have the lineage
[13:45] column level lineage across all different workloads. You can steer your access and get overview of who has access the exactly the same way you're doing on the rest of the platform.
[13:58] So let's take a look for those who haven't seen how it actually looks. So basically your metric views are stored together with your tables. I would usually if you have multiple metric
[14:11] views, you should create your own schema to do your metric views, but you can see it by the icon that it's a metric view. And here you kind of get the overview of how your metric metric view looks. And it looks quite similar to your other
[14:24] datab bricks tables. So you have the different uh measures, you can do comments, you can do tags, you can do PII information, you can also get the overview of all the different columns
[14:36] that are part of the metric view along also with the tags. You get the details which basically gives you the whole definition of your model in code and you see this uh you see the JAMO structure
[14:49] we were talking about the joints and dimensions and measures and the measures themselves are in SQL and the joints as well.
[15:05] And then you can go ahead and edit your metric views from the Unity catalog. And then as you see you can switch between two experiences. You can write the JAML code or you can go into the low code user interface where you get a more low
[15:18] code drag and drop where they also do a bit more AI stuff to suggest how you can create your measures and what your definition of your measure should be. Um and then you can also get the lineage.
[15:31] So, and this is also in preview, so I would expect that to kind of become a bit more uh sexy when time passes. But at least they've started with um the
[15:43] first iteration of it. So, and now how to model the metric views. In my opinion, the metric views
[15:55] actually has elements of both the multi-dimensional cubes and the tabular models we have been using for the last years. Some people when I say this is a bit surprised when I'm mentioning cubes
[16:07] and multi-dimensional models. So let's see if I can at least give my two cents on it. So the core information about the multi-dimensional cube, it is centered
[16:20] around measures. It's not centered around the tables. That means every measures that can be analyzed by the same dimensions will be together in one cube. That means
[16:33] it's actually a cartisian product of every combination of measures and dimensions. This means that every combination has to make sense. It has to give an answer that means something for the business.
[16:47] Um this was actually super super fast when it was first a thing because the analytical databases were so slow. So by doing these smaller met uh cubes h and
[17:01] pre-calculate them you got really really fast response times but the dimensional cube had some issues. So one of them was that they were quite complex. You can
[17:13] imagine if every combination of everything always have to make sense then as the cube grows it's very very hard to add one more thing and that also made it that they were also written in
[17:25] MDX which was a language a lot of people had really trouble working with so you kind of ended up having like if you we think data engineers are bottlenecks today they were like even worse when we
[17:37] had the multi-dimensional cube so it was really hard to kind of work with and that they made them both expensive and it also was a lot of duplication of
[17:51] dimensions because you had to have the same dimension in so many different tubes and back then duplicating data wasn't as cheap as it is today. So it was kind of a genuine cost to doing it.
[18:06] And then we went over to doing tabular models. That's the one that most people have uh experience with. And the idea about the table model is that you drag relationships between the tables so that
[18:19] not every combination of measure and dimension has to make sense anymore. How it's filtered is based on the relationships and the context and the filters. uh the uh measures they were
[18:32] calculated at query times and you could this actually means that you could have many many tables in one model. So you had a lot less duplication of data in
[18:45] this way of doing it. Another thing about it was that it was a much more flexible than the multi-dimensional cube and analytics kind of moved closer to the users because it was more intuitive
[18:57] to understand. Um, so people kind of understood it a bit more and it was less of a black box for people using it because they could actually see the relationships. But there are also some uh challenges
[19:10] with this one is that they don't have to be big. But if you go to any company, you see a tendency that the model grows quite quickly and you end up with a lot
[19:23] of big a lot of big big uh models. And in addition to that in for example a lot of BI tools you can have only have one model as the source
[19:35] of your uh reports. So that's also a reason why they had to be big because they had to span the entire report. So
[19:47] so in my opinion this actually means that first of all metric views they are a semantic layer. You're defining relationships. you're calculating measures and also we have to remember I said that
[20:02] one of the bad things about multi-dimensional cubes was the docuation of data right that's not as big an issue today because the storage now is decoupled from the compute which
[20:14] makes it not that expensive to actually um uh to actually have duplication of some dimensions that not is not that that also the metric views are more
[20:27] modular. You can combine multiple metric views and use them as the source for the same report or the same genie space for example. So you no longer have to do the tabler version where you actually create
[20:40] one bedroom metric views to serve entire report or serve a entire genie space. Uh so we're kind of going a bit back in my view. My favorite way of working with the metric views is again going up a
[20:54] little bit back to centering it around measures that make sense together. And you don't have to put things that don't belong together together just to be able to create one report.
[21:13] So my experience and and recommendation is I prefer to start with multiple specialized metric views. I will always start with having small special metric views and then I I'm careful about letting them grow. I would
[21:27] rather have a modular approach when building reports and dashboards because it means that I have more clear semantic intent. I know that this metric views is supposed to answer these questions. Uh
[21:41] it's also faster to validate and work with. So we can work with multiple metric views for different use cases and different business problems. It's also easier to iterate and change them
[21:53] because they're not um they're not they don't have that many dependencies around. uh and it also means that you get less duplication in total because you can now
[22:05] reuse your metric views across the state. But my key takeaway is I'm not going to stop here today and say that metric views you can do all the stuff that you
[22:19] can currently do with other DI tools. But I am here to say that I do think we need to rethink how we're doing the semantic layer. And the main reason why we have to do that because the semantic
[22:31] layer is no longer a place where you just do your reports. It also has to enable you to use the same model across workloads AI and BI.
[22:43] Um I also so I just want to say thank you so much for coming to my session. I'm going to be over hanging out here for like 40
[22:55] minutes. So if anyone wants to take a chat or also if you want to discuss it, this is something I discuss a lot with customers and different organization these days. Uh just add me on LinkedIn.
[23:07] I also post a bunch of content on my honest opinions about AIBI and yeah thank you for coming.

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.