New Feature Semantic Bridge – Ep. 476

Semantic layers aren’t just a Power BI thing anymore. In this episode, Mike and Tommy explore the growing landscape of semantic modeling across platforms—Databricks metric views, Snowflake Cortex Analyst, dbt semantic models—and what a “semantic bridge” between these worlds could look like.

News & Announcements

• Decoupling Default Semantic Models in Microsoft Fabric — Microsoft is decoupling default semantic models from other Fabric items, giving teams more control over when and how semantic models are created and managed.

Main Discussion: The Semantic Bridge

Semantic Layers Everywhere

Mike and Tommy survey the semantic layer landscape:

• Power BI / Analysis Services — The original tabular and multidimensional models, now powering 35M+ monthly active users
• Databricks Metric Views — Databricks’ approach to defining reusable metrics on top of lakehouses
• Snowflake Cortex Analyst — Snowflake’s semantic model specification for AI-powered analytics
• dbt Semantic Models — dbt’s MetricFlow layer for defining metrics in code

Each platform is building its own semantic layer because they’ve all reached the same conclusion: raw data isn’t enough. AI and analytics need shared definitions.

What Is a Semantic Bridge?

The concept: a connector or translation layer that lets semantic definitions flow between platforms. If your organization uses Power BI for reporting but Databricks for data science, a semantic bridge would ensure both platforms share the same business definitions rather than maintaining parallel versions.

The Industry Challenge

Today, each platform’s semantic layer is a walled garden:

• Power BI measures don’t translate to Databricks metric views
• dbt metrics don’t automatically sync with Snowflake Cortex
• Organizations running multi-platform environments maintain duplicate definitions

Microsoft’s Position

With Analysis Services heritage (tabular + multidimensional), Power BI semantic models, and now Fabric IQ ontology, Microsoft has arguably the deepest semantic layer investment. The question is whether they’ll open it up for cross-platform interop or keep it as a competitive moat.

Practical Implications

For teams today:

• Pick a primary semantic layer and treat it as the source of truth
• Document definitions independent of any tool (so they can be translated)
• Watch the standards space — semantic layer interop is an emerging area
• Don’t duplicate definitions across platforms without a sync strategy

Looking Forward

The semantic bridge concept is early but inevitable. As organizations adopt multi-platform data stacks, maintaining consistent business definitions across tools becomes critical. Mike and Tommy expect this to be a major theme in 2026 as AI agents need reliable semantic context regardless of which platform they’re querying.

Episode Transcript

Full verbatim transcript — click any timestamp to jump to that moment:

0:00 Good morning everyone and welcome back to the Explicit Measures podcast with

0:32 Tommy and Mike. Good morning, everybody. Good morning, Mike. How you doing? I’m doing well. Just kicking in here, getting going today. Got my coffee, which is always needed today. So, been a long week. It feels like feels like a lot of things are happening. I’m this is my last This is our our last main podcast here for a little bit. We’re We got a couple recordings coming. So, just FYI, there’s some recordings coming up. if you want to watch the episodes as soon as we record them, we would recommend you come be a member of our YouTube channel. So go check out YouTube. You can become a member and you get the videos as soon as we record any

1:05 Video or any future videos. You can hear the content as soon as it comes out. A little perk for our members. also just really quick here, I’ll be in Budapest here soon. And I’ll be teaching an entire day on DANB Vega Vega light going through a whole series of educational content around using other visuals not the standard PowerBI visuals which I think is a good thing. There’s going to need to pushing things pushing the boundaries of what you can build in desktop. So how long is that training? Is it just a single day or how long are you going

1:37 To be teaching people on DAB? It’s a precon so it’ll be a full day of teaching. So the we’ll be teaching on Monday. So with the session it’s data Prague no sorry data data Budapest I’m can’t remember the name of the conference off top of my head I just know I’m going there so I’ll get the name here later on but we’ll be doing a full day I think it’s like a seven-h hour thing with like an hour launch in the middle there but we do like in the morning full day on learning how to build DAB understanding Vega Vegaite specs we have a whole bunch of

2:10 Workshop pieces you’re going to be building visuals creating stuff and then on the afternoon we’ll be more of the same advanced features, more things you can do inside the Neb. it’s such a versatile program. I really like the the visual that it that it is. I I wish it was easier to get more data into it. I wish there was a better way of like collecting galleries and items of things, but stay tuned. You never know what will come into the marketplace. Dude, that’s that’s awesome. And not that I’m surprised there’s still how unpopular DAB is, but quick question with the DAB. Are are you finding in

2:44 Your reports what percentage of your reports have visuals? Probably a lower amount. They’re more of like a stylized thing for now. , depends on who you work with. It does take a little bit more to set them up. They’re not quite as straightforward as click a button, get a visual, and start dragging and dropping fields over. You have to do a little bit more work to get it to run correctly. But I think u the the intent here is this gives you full capability to stylize and do whatever you want. and you get spacing between the bars, you can round the edges. There’s there’s no there’s really

3:17 No limitations on what it can do. It’s really I’ve seen some very elaborate and amazingly complex things. There’s this one person who’s got a Gant chart that’s incredible that is really highly interactive and all built inside inside of the NB visual. So, more the idea is here, you can build these really complex, very beautiful visuals with the Neb. it gives you an experience there as well. So, one thing I’ll just point out here too, Tommy, , data bricks has also jumped into this Vega and Vega. So, so DAB is the the visual that lives inside PowerBI. The spec that runs or

3:50 The the code that runs basically DANB is Vega and Vegaite. Data Bricks has just made a blog post announcement on I think it was like the ETH talking about how they are going to incorporate a private preview around using Vega and Vega light directly inside their AIBI dashboards. And I fired off a couple notes here across Twitter and and the the social media platforms. I said I think Microsoft’s going to get a really solid competitor here with data bricks absolving or using DAB or not DAB

4:25 Basically Vega Vega light a specbas based visualization program to build visuals this opens up a big world for them and I think this actually unblocks data bricks a lot if they do this well this could be a substantial competitor to to Microsoft because of how quickly and how more how more complex you can make visuals. You can start off with a simple design, but you can continue to stylize and customize it to a high degree. I I think this is going to be a really interesting move here. So, I think there’s a a wind here in the

4:58 Marketplace that is going to really change how visuals are going to be built here and Microsoft better keep up. Interesting. All right. I’m I’m excited to see that. But Mike, what are we talking about today? I am excited for today’s topic. Well, we got a our main topic today will be a new feature announcement from tabular editor. So, we have potentially a guest come on today that we’re going to unpack that with. so, that’ll be our new main topic for today. We’ll talking more about the semantic bridge. That’ll be our topic for today. Tommy, let’s go into some news items here. You

5:31 Got a news article that you found. Let’s expand that. Yeah. So, this is a followup to Microsoft Fabric’s blog about the deprecation of the default semantic model created when you create a lakehouse that we all wondering why that was a feature in the first place. But if you missed the announcement, Microsoft announced maybe last month that they were no longer creating exist default semantic models. When you create a lakehouse, you’d always have

6:02 That default semantic model. Then you’d have to create a new one, but you always have the default one. So now they actually have using the fabric AP API to identify and delete decoupled semantic models. , and it just simply runs the script retrieves anything that’s decoupled. So meaning it’s no longer in a sense that default. , sees if that model’s empty and then deletes that model, , and skips those objects. So, it’s a script, but it’s just again just one of the things Microsoft’s trying to push to get everyone on board with. No

6:34 More default semantic models. Yeah. , I think this is something that was I I didn’t really want to use the default semantic model. This is so limited in what you could do with it. Oh, yeah. I think Microsoft was just spinning these suckers up all over the place. And now when you create lakeouses, you don’t get that default semantic model anymore. You just build your own semantic model directly from the lakehouse. So, I think this is a great move. I don’t think I was using it. it it wasn’t something I was recommending to clients and customers. So, I really think this is the the right move to to get away from those default semantic models. What I will say though is the ones that you

7:06 Have that are already out there, they’re still going to work. I believe I just don’t think they’re making any new ones moving forward. And I would also argue if you’re spending time building on top of the default semantic models, it’s probably time for you to migrate away from them and build just standard semantic model in the service and migrate your measures or code over to that that proper semantic model and not the default one. Yeah. Just just from a safety standpoint, you don’t want to have something stuck in that lakehouse that or that semantic model that just doesn’t exist. One of the tricks here, Tommy,

7:39 Did you ever use deployment pipelines with lakehouses? Did I ever use No, I did not. So the reason I’m asking this question or pointing this out here is one of the things I felt that was interesting was when you create a lakehouse in dev and you use a deployment pipeline to move it from dev to test the lakehouse would move but neither the semantic model or the the SQL analytics endpoint like if you had definitions in there those didn’t migrate it was just create the lake house and you would get a brand new

8:10 Created default semantic model which defeated the purpose of whole the whole deployment pipeline in my mind, right? So again, the story here was build a lakehouse, get a def default semantic model by default. Great. You have all these things. Okay, let’s add a couple measures. You add some measures to the default semantic model and then when you deploy it to the next environment, it all disappears and you can’t deploy the things you just built, which is like I don’t know why we would want to do this. So I think this makes a lot more sense now to not have that default semantic model going between environments. you can now just have a

8:43 Lakehouse and a separate semantic model that when you migrate to the next environment or use the deployment pipelines, you’re actually going to be able to deploy the semantic model with all of its measures and things inside it. So there was to me there was a little bit of friction there as well that I didn’t really like and was very hesitant to use the default stuff. Yeah, it always seemed to have bugs when I would go to PowerBI desktop to try to edit a lot of those like trying to reload if you’re creating a measure. We’ve come a long way since the initial build a lakehouse and build a semantic

9:15 Model off of it. So thank goodness the features are available in external tools. They’re available in PowerBI desktop to create an a semantic model which is one of my favorite features by the way to create a semantic model off of direct link in desktop which is cool because it doesn’t even create a file on your computer. It just saves it immediately right back. So we’ve come a long way. just also note here at the bottom of the article. I think this is always important to call out there’s a list of known limitations. So in lie of what’s changing right I want to make sure that

9:50 Users go to this article. It’s in the chat window as well. Make sure you go through the known limitations. There may be something that you’re doing that you may want to check those limitations cuz there are some things here about like import mode. there’s something about default semantic models and reports with deployment pipelines. If you rebuild the semantic model, the the re the auto rebinding between the report and the semantic model gets broken. So there’s a lot of things that cause issue here that you’ll need to be mindful of and in working with these again as you move away from the default

10:21 Semantic models moving forward. Anyways, just check those things out as well. those are items you want to just pay attention to. All right, but that being said, Tommy, let’s you ready to get into our main topic today? Do let’s bring it on. All right, main topic for today will be talking about All right, I just lost my notes. We’re going to talk about the new semantic bridge feature here. And let’s bring in our There’s our call. Oh, caller. Let’s Hello, caller. Let’s bring our caller in today. Greg, good morning. welcome back to the podcast again. We

10:55 Appreciate you being here. Welcome back to the show. Thank you. Yeah, longtime listener, fourth time caller. I’m really excited to be here with you guys. Fourth Fourth times the charm. We’re finally figuring this out slightly. A little bit maybe . , all right. We’ll we’ll kick it out here. Greg said he had a couple questions for us to kick off the conversation today. So, I’m going to punt the conversation directly over to Greg. Up to you. , ask away. Yeah. So, thanks very much. , Mike, Tommy, you’ve both done some consulting on data in your days. You’ve worked with small companies, large companies.

11:29 How many times I want to ask you, have you met a company that has actually truly one data platform, a single data warehouse, a single reporting tool, one one platform that’s used across the organization with nothing else? Can I follow this up with another question? Yeah. Does does Excel count as a reporting tool? Absolutely. Okay. [Laughter] So, yeah. very leading question here, Greg. I have never experienced any organization that doesn’t have at least one reporting tool. Usually two or three

12:02 That are out there. You’re using some backend system that’s in some other SAP dropping things down to another data warehousing system something different and then you’re then flipping it over to okay here let you export and now you’re onto your third system Excel or other things that are being built on in the business side as well. So I’ve never had a single solution around these things. We hear a lot of like useful things and now now the challenge becomes I think Greg even further when we look at like the big three I’m going to call them fabric data bricks no there’s three large

12:37 Data warehousing solution systems there’s other there’s others out there Oracle or SAP has other things going on as well so I don’t want to discredit them either but the ones that I’m like focus my attention on are those systems and when we look at those there’s companies that have a mix of all three of those or two of or like blending different things together. So, , every one of these guys are trying to say, well, we want to have this unified semantics layer and we want to have these unified cataloges of things like there’s there’s constantly this need to like let diversity happen but also have some consolidation down to

13:09 Like where do I discover things? So, it’s this it’s a double-edged sword, I guess. Tommy deal to answer your question. , if they only had one reporting solution, usually they don’t need a consultant and true. so and but the other part too is dude it’s it’s fabric in itself too could be almost considered and there’s an argument that in fabric it’s multiple data platforms in fabric because it could be streamlined with a pi with a warehouse or a lakehouse you’re just doing normal. So

13:41 Even if you’re just using fabric, there’s a lot of different methodologies and where the data is coming from. But yeah, it’s both the problem on the intake of all the different sources and then the outtake. How does each department organization again actually manage and look at their data? I feel like I I have an observation again Greg also you do you do consulting as well. a lot about companies here as well. When I look at companies, it feels like right now, at least in the last year or two, there’s been this abundance of building like the platform,

14:15 Right? There’s like this, , we used to have like a lot of different tools. I feel like there was a lot of like, well, we can use data bricks and we can use dbt, we can use these other different tools that combine things. We have talent, we had all these different programs that were doing very specific things. It feels like recently the emphasis from the market has been look we don’t want to buy seven different tools to do what we got to do. We’re really looking to buy a singular tool or start consolidating and there may be multiple tools right there’s going to be some decisions being made like we’re going to be a data bricks and

14:46 We’re going to be a fabric shop. That’s what we’re going to be and here’s the team that’s going to use this tool and it’s easy to draw security boundaries because this team has access and this these other members do not. So sometimes tools decide on security boundaries to some degree. but what I’m finding it feels like is we’re trying to figure out how to negotiate less tools than more. We’re starting to see a consolidation of effort here and the tools that exist are getting more monolithic. They’re adding more things to them to to continue to keep you in that wheelhouse longer.

15:19 Doesn’t mean you’ll stay there forever. Again, a lot of patterns I really really enjoy is do the data engineering with data bricks and then flip over to to fabric and use fabric lakeouses, shortcuts, semantic models and reporting for the security layer and the distribution layer. So, it really depends on what your company is doing. But I feel like there’s a consolidating effort happening to some degree moving offrem. We’re trying to get to the cloud. Let’s, , we’re we’re going to be an Azure shop. We’re going to be an AWS shop. we’re going to move many of our main data systems into something that’s a bit more portable

15:52 And cloud-centric. Would you agree, Greg? Do you see similar trend right now? Yeah, I think there’s always a drive toward consolidation whether that’s whole platform migrations just trying to get off of one thing so we have fewer total but also even when you’ve got a fairly tightly organized set of data platforms or data tools there’s also the interoperability between them and I think that’s and I’d love to hear from you guys but I think that’s one of the the core challenge areas is even if you say like we’re going to use a combination of snowflake and fabric or we’re going to use a combination of data

16:25 Bricks in fabric or we’re going to, , if we’ve got these multiple tools, the right tool for the job, there’s still the the level of integration and an effort to integrate between these things. Even though you might have chosen to adopt a couple of tools as your standards, data bricks and fabric are not one platform. They are multiple or snowflake and fabric, , whatever combination. Yes. And so there’s often even with an organization that has decided to consolidate, there’s still an ongoing integration process. How do we make sure it’s easy to use work from one of these layers in another layer? And

16:58 I’d love to hear your guys’ thoughts on that as well. There’s still friction and even at the fabric conference Vienna conference, there was a lot of announcements around like, hey, look, we’re going to have native Snowflake integration. We’re going to have iceberg integration. We’re going to have Delta more more easily using Delta. I feel like there there’s a lot of olive branches being brought from Snowflake over to fabric to try and get those two systems to work really well together. I’m observing a lot of it’s getting easier with data bricks but data bricks is very forward thinking and

17:30 How they like to build stuff. There’s a lot of advanced delta tables. They have this deletion partition pruning thing that they’re doing right now. They’re they’re able to handle lots of small records quickly but then consolidate on a schedule. their data bricks is doing some really interesting things and being able to maintain like the lakehouse and parquet delta file standards they’re the ones who created it to their credit right that’s that’s their their thing but they also are closed garden they don’t actually release the features that they’re building for a series of time like they

18:03 Keep those internal to themselves and they don’t open them up and open source those until like 6 months a year later in in the time frame letting other companies adopt those standards so Microsoft has adopted the delta standard and now is able to read and use iceberg which makes it easier to play with these two different tools. But I see a lot of fighting between data bricks messaging and fabric messaging more so on the data bricks side than the fabric side. It feels like data bricks playing a little bit dirty. they’re like oh you never want to connect your your data to a semantic model in data bricks it’s going

18:35 To be so slow it’s always going to fall over and go back to direct query and like it’s super slow. Like I hear a lot of language from the data bricks side trying to accuse a lot of things. I’m like, well, , you have some valid points, but you’re also overexaggerating some of the the points you’re talking about if you don’t design your system well. So, , when I think about the platforms, it’s it’s probably a little bit easier to integrate or going to be easier to integrate with Snowflake than it will be data bricks. , I really like the Unity catalog data bricks object in the workspace. Still needs a little bit more love. I still

19:07 Can’t use streaming tables or materialized views. It’d be nice to have a couple extra features that we could use inside fabric, but with minimal effort, I can design around that. And , I can do bronze, silver, and data bricks, and I can land gold in a lakehouse in fabric. , it’s like none the wiser. Data bricks can write to both locations. That’s what we’re finding is a bit more efficient for us is to take that last mile and just move it to fabric and let fabric own the rest of it. So, that’s that’s my experience with the different platforms and how they’re working together. Tommy, what do you feel

19:39 Now? Honestly, I I’m actually wondering why you’re asking this, , Greg, because I’m going to agree with most everything Mike said. The implementation side of things is hard when you have different people also from the skill point of view where a lot of people’s background is in one of the platforms and then it’s like, okay, well, we’re going to try to integrate everything else like does that mean we have to move everything over? which tool or which platform are we going to spend most of our time? Because it’s more than just what is best for the

20:11 Organization is you got to work look at the people and where they’re comfortable and what their background is too. But I’m intrigued. Why do you ask? Well, because it’s a leading question, Tommy, that’s why I asked. so, one of the things that we’ve talked about a little bit in these last couple of episodes is the semantic model. And that the semantic model is really the the place where meaning is made. It’s where you define business metrics of interest. It’s what most reporting is based off of, or at least in the ideal, it’s what most reporting is based off of, especially in the PowerBI world.

20:44 And , Mike, you talked a lot about some of the interoperability points. , Microsoft uses the delta table format in Maverick. And so these are these are the same format. You can take a delta table and you can feasibly use it in different places. again depending on the the recency of the features in data bricks perhaps but if it’s just a bog standard delta table that can go in either place but another area that a lot of these vendors are are working on and some of the ones that you mentioned Mike data bricks snowflake and we know Microsoft

21:16 All have semantic layers so data bricks has something they’ve launched fairly recently they’re calling it metric views and their spec for that has gone through at least a couple of revisions publicly snowflake has their own semantic layer. Microsoft themselves, they have two full semantic layers. They have multi-dimensional, the original analysis services, and they have tabular, which is used throughout the fabric and PowerBI stacks. And these are areas that there is no intercompatibility. they’re different formats. They have they represent

21:49 Different things, but they are all fulfilling the same basic idea of we want to have this place where we define reusable business metrics. something that we can use across different reports where we can have those metrics defined once. And so this is what we’ve been working on. That is the semantic bridge. That’s the the goal behind it is to be able to take these things that have different formats and be able to bridge the gap between them. And so the feature that I’ve been working on is in MVP right now. We’ve actually been

22:21 Partnering with Advancing Analytics where we’ve got both an evil mastermind and a helpful partner in Simon and at Advancing Analytics and they’ve been helping us. Yeah. they’re really good guys. but they’ve been helping us as we’ve been building this MVP and testing it and working on some features. And what we can do right now is just a small piece of what we want to be able to do in the future. but we’ve built the infrastructure to go from a data bricks metric view which is a semantic model that’s defined with a YAML specification and we can translate those directly into

22:55 A tabular model in PowerBI or in analysis services using tabular editor. So I’ve done a little one let me call out advanced analytics amazing team also been really loving Simon right his does all the YouTube videos love the things that he learns through he does he does really good like it’s like a little bit like freehand it’s like let me show you I’ve got a demo that I have worked out and then I’m just going to walk you through like the data bricks side of things what they’re building what features being

23:26 Released so I just recently watched this video on metrics view and then I did a little homework on myself around metrics views as well. I like the idea that data bicks is using is trying to make this a bit more human readable to some degree. But one of the things I really like about the definition of metric views at data bicks side is they’re defining the the metrics inside YAML. So YAML is yet another markup language but it’s actually fairly human readable and it translates you can translate YAML directly into JSON which is very

23:59 Computable computer readable and useful but there’s a lot of extra syntax and and language there that’s not helpful for building things. So I really liked the experience of going to data bricks and seeing YAML showing up defining what a measure is naming the measure putting its details inside there. So that makes a lot of sense to me of what what they’re trying to accomplish. So that part I like. I haven’t really seen that much on the Snowflake side as to what they’re doing on their semantic layers. Again, we we have some interaction with Snowflake, but more more of what we do is we try

24:32 And we’re actually working with customers right now to migrate them off of Snowflake into fabric. because Snowflake is a bit more of a pricier option at this point. So I don’t think they’re the cost leaders at this point. they’re a bit more expensive. So we’re doing migrations off of Snowflake and re-envisioning that data platform inside Fabric at this point. Tommy, what’s your experience with any of these semantic layers? Have you touched anyone on Snowflake or data bricks yet? Yeah, so we did a migration with Snowflake and it it was a pain because it also was the more of the organizational thing on people’s skill sets. Again, I’m I’m

25:07 Going to go back to that, but the the snowflake one is you’re dealing with more heavy data engineers and then trying to get them into fabric is we’ll just say just a little frustrating, but honestly, no, I I would say that it’s always a headache. Yeah. And so we are that’s that headache is really what we’re trying to address. , like I said, we’re an MVP now, but what we can do is we can translate one of these existing semantic models. Again, right now we

25:39 Target data bricks to tabular, but we’ve built the infrastructure to be able to target any arbitrary semantic layer. And what we do is we map the concepts that are similar across all different semantic models. You always have a fact which is going to contain things that you aggregate. Those things that you aggregate are measures regardless of what the the semantic layer names them. like you could have a semantic model that calls them metrics instead of measures. the specific name isn’t important. The idea that it is a reusable piece of business logic that is encapsulated with a name, that’s the

26:11 Important thing. And we call those measures. and so we can take measures, we can take facts, we can take dimensions. And again, whether or not something is strictly in a star schema or not, there are still dimensions. There are attributes that are descriptive that you want to group or filter by. And we can take those things. And so we’re able to take these concepts of a dimensional model and then map between different concrete implementations. So the the metric view in data bricks is one concrete implementation of a semantic model. The semantic model in PowerBI which is the

26:44 Tabular engine is another concrete implementation of a semantic model. But if you’ve got facts and dimensions in one, you’re going to have facts and dimensions in the other. And the question is how do we take the syntax the concrete representation which again in data bricks that’s YAML u in different platforms it can have a different serialization format or a different structure but taking those ideas and mapping them through to a different concrete format is what we’re what we’ve been building. So, Greg, again, I’m going to unpack a little bit. I said there’s like two

27:15 Ideas I’m like mulling over in my head here as you describe this, right? Yeah. And again, this is my observation of looking at the ecosystem, the this the scope of what’s out there right now. , when we look at like data bricks, we have this concept like the Unity catalog, right? So, everything you build, all the tables, all the , schemas that you’re producing gets attached to a Unity catalog by default. It just is there. So this this concept of the uni catalog provides like the governance control that you want across all your data. And what data bricks I feel like is doing is they’re coming at this from

27:47 The angle of hey you’re going to do notebooks you’re going to transform data. This unity catalog is this monolithic massive system where everything goes. It doesn’t matter what you build. It’s got to land somewhere in uni. You could choose not to use uni catalog but most everyone’s they’ve made it easy enough that why not, right? Just choose it. Right? So that’s a little bit of a different mindset than what Microsoft has come up with, which is Microsoft could have monolithic semantic models, but because PowerBI basically caches or brings into

28:20 Memory the columner store to make the reporting hyper fast, Microsoft has decided like we’re not going to give you like the monolithic everything semantic model, right? We’re not going to give you all tables that have ever been created inside your organization. All measures that have been created. They’re they’re basically localizing down to I would call them maybe like a data mart, right? There’s these data marts that exist that are a localized semantic model. It could serve a lot of people. I’m not not discrediting that. But Microsoft is not does not have this holistic view. And so

28:54 We throw things like one lake catalog. We have things like purview that is trying to give the organizational view of all the data that’s happening across your estate. So I feel like the story here is slightly when I look at the two stories that we’re comparing here. It feels like data bricks has a more complete all-encompassing semantic story because it could span everything in the data estate across the entire organization. PowerBI to me feels like a little bit more dissected. there’s more

29:28 Nuance to those things and I would also argue too I I like that to some degree because it gives me semantic models per business unit or I could I could have them open up to all organizations semantic models but where I struggle I feel like and the point I I’m thinking here is my my two points are data bricks has taken a different approach and Microsoft has been leading the semantic layer the this whole concept of there’s not really a centralized place to get everything. I feel like I’m in the

29:59 PowerBI realm and fabric realm. We get close. I have glimmers of hope around like one lake catalog of like seeing all the things, but as me as an admin, there’s just some missing stuff and and the things that I’m missing are where’s that consolidated view of all my information? How similar are two tables that are being either imported or direct across all these different semantic models? Do we have repeating business logic in measures and semantic layers? we don’t really get a really it we can do it but it’s going to take a

30:32 Lot of effort from admins or central BI teams to really aggregate this information to start having conversations around this one. Mhm. So let me just pause there. I said a lot of things around like the maybe the two different lines of thought between what data bricks and fabric are doing here. What do you think Greg? Is that your observation too? Did I miss something here? I think it’s partially messaging. because if you think about it, a fabric tenant is a catalog of everything that is in the tenant. And there are APIs to get

31:08 Definitions. So there’s no good UI that gives you a centralized view. But you can scrape very easily using things like the scanner API for PowerBI or just enumerating workspaces and getting the definitions of everything in there. The the information is centralized. There’s one set of endpoints that you would hit to get that list of everything that exists in the tenant. And the the concept of everything that exists in the tenant is a catalog. Data bricks has named it. They’ve given a name to this concept. They call it the Unity catalog. Yes. and they’ve given

31:41 Better interfaces into it from an ad from an administrator’s perspective, but it’s the the information is there. , maybe that’s what I’m pointing at. Yeah, maybe I’m pointing at like the difference between like the different levels of friction I receive from both tools, right? To me, there’s a bit less friction right now in the way that data bricks is doing it. There’s a bit more friction in PowerBI. And I have visions of grandeur around like man if I could just only get all this stuff together and like once I have call it the the one late catalog of all the

32:16 Things like okay great now how do I get like statistics on how much it’s being used where’s my where’s my events coming from the the scanner API so I can see all the events coming back from who’s opening and viewing and seeing stuff so I have this vision of grandeur around taking like both the the assets side with a better graph of like here’s all the things that relate together and then conversely flipping that over and saying okay now that we have that let’s look at the analytics and usage and then tie those two together because a lot of conversation Tommy and I beat up on the

32:48 Podcast is we know there’s too much for a central BI team to manage everything we have to pick and choose there’s going to be so much content created we call this like our pyramid of content right there’s there’s personal reporting at the very bottom of it there’s just so much content being created and then you go up the pyramid becomes more enterprisegrade and you have less content looked at by more people and that’s where I want to focus my effort. I want to focus my time and effort on the most impactful valuable models, designs, reports with the widest audience that decision-m I want

33:23 To focus on those things first and then we can come address more of the ad hoc stuff that’s that’s at the bottom of the pyramid. Yeah. Well, but I think you’re you’re touching on something from a a slightly different angle, but the idea that we’ve got again every organization has multiple data repositories, multiple places where data is living. And so the question you’re coming at it is ad admin, , how do I know what’s there? How do I put governance on top of it? But there’s also a very I’ I’d argue it’s your strength, but the this is this is not a stereotypical

33:57 Interview. So we don’t need to do my weakness as my strength and my strength is my weakness. But I’d say if we look at it from a more concrete usage perspective, , that’s where really where we’re coming from with the semantic bridge. It’s it’s not so much the question of how do we govern and put it and have this one view. That’s a very important question. And I don’t mean to sweep it under the rug, but the other side is knowing that we have these things. How do we get artifacts in the into the hands of end users so they can use them? Because right now, if I have a semantic model in

34:30 PowerBI, I can’t consume that in data bricks in any meaningful way. And similarly, if I have a metric view semantic model in data bricks, I can’t meaningfully consume that in PowerBI or in fabric in any meaningful way. and so the question is not just how do we know everything that exists and govern it well, but then how do we make sure that we get these tools into the hands of the users in a way that they can take advantage of them. And so that’s really the angle we’re we’re coming from with the semantic bridge is not just discoverability but usability. If you’ve got a if you’ve got

35:03 A report designer and they know how to build PowerBI reports and that’s what your end users want to see, but you’ve got a data layer in data bricks and semantic models have been defined as metric views in data bricks. How do you get those business definitions? How do you get that dimensional model structure into a place where PowerBI reports can be built on top of it? And that’s that’s what we’re trying to answer. And the way that we do it is we give you a way to seamlessly and automatically import the entire structure of that metric view into a new semantic model. So the governance question remains very

35:36 Important because now we’ve got two artifacts that are logically linked but there’s no physical link like linking between the two. Yeah, you could update the metrics view but that doesn’t necessarily immediately reflect in the semantic model. Like you could change the for the measure something. So what is what does a synchronization look like to that? And how do you do that without it being a manual effort every time? Because maybe your data engineers are doing their, , you’re doing your data engineering in data bricks and then your data engineers are saying here’s some semantic models, here’s some metric views that surface up these things in reusable ways and they’ll keep those

36:09 Metric views up to date, but then you’ve got someone who wants to consume it in PowerBI. It sure would be nice to have a tool to be able to make that happen automatically rather than a user having to go and read new definitions or do a diff of some YAML and try to understand what they need to update on the other side. And so that’s that’s really what we’re tackling is the ability to automatically take a definition from one side and convert it into a definition on the other side. We’ve had a client in asking this exact question. We’ve been exploring a similar thing as well for this exact reason because again the data

36:40 Engineering team is data bricks. We’re serving reports to customers and business teams with PowerBI. And so we we need this like easy interoperability between the two formats or going from one format to another one. Tommy, so you’re gonna Sorry, Tommy, you’re gonna say something. No, I was going to say I think one of the biggest issues with all the different platforms is let’s say even with the import right is what happens when if I’m importing and just aligning with change management that’s such an important part for me and I know for everyone else but I think that’s something that is not always considered

37:12 Is okay yeah we have this existing data set we’re going to get that into fabric well if they’re make usually it’s like well we’re making changes in one platform so and it’s no longer in sense link linked over to what’s happening in whether Snowflake or data bricks all of a sudden over time they’re going to have different definitions and that’s always always the culprit of a lot of organizations woes and frustrations. So that’s such a huge part to ask some question. Do you mind do you mind if I dig in on some of the technical details

37:44 Here? Great because I know we talked a little bit high level. Mike, me. Okay. I Well, I know you’re you’re Mr. technical but I want to ask some like I’m trying to in my mind I’m trying to bridge the gap between what I know in semantic models in PowerBI and what I understand around again my understanding of data bricks metrics views are very new they’re still I think they’re still are they still in preview or do they just get released out of preview I don’t g yet I haven’t checked in the last couple of days though okay so we’re on the hot so where where we are is on bleeding edge of things

38:16 We’re bleeding edge like stuff is getting released we’re in private public preview. Okay. of that like okay so when I think about data bricks right data bricks is generating tables it’s loading things in it’s pulling those tables into a final view when we talk the jump to semantic model semantic model has this concept on tables where you import direct query and now we can do interesting things where the data can stay in data bricks but I can make a data bricks item inside fabric that’s like a shortcut to it and then I can reference it and then re you

38:49 Know go back to the table and get the but then pull it forward. So where where does like in in this thinking of a tool that does this where does the information live to say I’m going to take this table and import it direct query it using a a data bricks SQL endpoint versus a a direct link or a shortcut to the tables. So does that is that something that’s part of the tool because it feels like that when I look at the data brick catalog maybe you can add annotations or things there that would give some hints to your tool to

39:23 Tell PowerBI or that the translator say hey look this table is an import table I want to import this one hey this is a table that I’m going to do directly to using this SQL endpoint or whatever so how do you handle that part what does that look like to you yeah so right now in the MVP we just make everything into an import partition in the tabular model. that is a decision we made for the MVP that we’ll just take this simple path and we point those partitions directly at the data bricks source. So you provide the metric view definition that’s a YAML file. You provide the data bricks host name and

39:57 The the path to the database in data bricks because those are not defined within the metric view yaml. in the future though we’ll connect directly to data bricks and you’d be able to select a metric view and we’d be able to have that data bricks host information automatically through the UI but right now you provide those things the the host name and the path you provide the YAML file itself which is the structure of the metric view of this dimensional model on the data brick side and then what we do is we’ve built the infrastructure to migrate that structure and build tabular object model objects on that. So

40:33 A metric view has a single fact table by design and it can have then many dimension tables. They’re called joins in the metric view and it can have many dimension fields. Those dimension fields can live in any of the join tables or they can live directly in the fact table. And then you have a bunch of measures. those measures are little snippets of SQL that are evaluated based on the joins and the fact table in the metric view. So we’ve got some highle concepts. We’ve got a fact table. We’ve got some dimension tables. We’ve got a bunch of dimension attributes, fields that live in dimensions and we’ve got some measures. So these are all things we can represent in the semantic model

41:07 In the tabular object model on the PowerBI side. And so what we do is we create a table. Right now we name it fact for you. but in the future this thing will be a little bit more customizable. but we name it fact. We add fields for all of the measures for all of the for anything that a measure is aggregating. We add those fields to the fact table. So if you’re say do doing a distinct count of a key in the fact table well that field for PowerBI that needs to exist in the fact table. So we add the correct fields then we add the measures on top.

41:39 We add a table for all of the dimensions that were defined as joins in the metric view side. We add a relationship from the fact table to that join. We add all the appropriate fields to those dimensions and we add partitions to each of these tables that point back to the datab bricks to the data bricks host and we set those as import partitions. And so then you’re in tabular editor and you’re looking at this semantic model that has a fact table, dimensions, measures, and fields all populated. At that point, you can do anything you want. You can change those partitions from import to direct query. If that you’ve got this shortcut set up in

42:13 Fabric so that the data bricks tables are visible in fabric directly, you could very easily rewrite those partitions instead of pointing at datab bricks to point at fabric. that would be something that you would do either manually in tabular editor or via C# script in tabular editor or you could ask an LLM to help you at that point. You could use semantic link labs if you’ve deployed this thing to fabric. you could use that to programmatically change it because what you end up with is a whole semantic model in tabular and so that

42:46 Can be deployed anywhere you can deploy a tabular model fabric analysis services and so on. you can use it in PowerBI desktop because it is a tabular model and that’s what PowerBI desktop makes. so then you could load it into PowerBI desktop and you could use it there and you could use PowerBI desktop to edit this thing. so right now that’s the translation you end up with a you’re holding a tabular model and then you can do anything you want with it and that’s going to be in our January release. Like I said this is an MVP. We’ve built a lot we’ve built with a lot of forward-looking extensibility in

43:19 Mind. So the goal would be that you can provide in instructions probably snippets of C# but maybe we’ll put even more structure on top of it so we could give you a UI to map things in certain ways. So for example, we can’t translate every instance of SQL into DAX. That’s a hard problem. But we can translate basic SQL. So we can do basic aggregations, no problem. And those happen right now in the the MVP. any basic aggregation will flow through and get a DAX expression written for you. But one thing we’ve talked about I don’t know if we’ll implement this or

43:52 Where we’ll put it on the road map, but the idea of having the automatic translation take the structure and then where we’ve got snippets of SQL, we could have an LLM just go after those snippets of SQL and say, “Hey, figure out the right DAX to write for this.” What’s the Dax to write for this one? Because cuz that was one of my questions I had here on my list here was like when you’re writing the the measures, measures could be simple, right? Sum of this column, right? That’s very straightforward. We can even like it’s like 100% transferable. You could just you could just write that and it just works. you would need to add not just the column name but you need to like

44:24 Table column name would be the only translation we would need to go from that step. But there’s other statements and other examples they were giving here which was like hey there’s going to be like a case statement a which is basically the similar to a switch. So there’s all these patterns that would need to be translated between the two and you you could write just straight SQL however you would normally write it. And Mhm. as you’re describing this, Greg, I’m opening my mind here a little bit to like the pattern I’m seeing here. As you describe this, it feels like we’re building programmable SQL to some degree, right? Cuz in my in my mind,

44:59 I’ve I’ve gone to a notebook. I said, “Okay, I’m going to create I’m going to go figure out this information. I know I’m going to count this column. I’m going to aggregate or sum this thing here.” And so I have to okay, I’m going to intentionally think about this is the column I’m aggregating by. total dollars, total units, whatever. And then I have to write the SQL to make it happen, right? So, okay, do this, write the sum, okay, name the column as something else. So, it’s the statement of sum column as piece of information, which is the measure, right? So, that’s and that’s the thing I would like to

45:31 Reuse over and over again. And it’s, , the semantics layer is now saying, okay, when I just say total units, it now knows the exact same calculation to run that that measure over and over again. And in the data bricks world, this is just like now SQL, right? This is not just SQL consuming that. , as a quick side note, data bricks, again, this is I don’t know this one. You have to correct me if I’m wrong. In data bricks, you can use the metrics view in a notebook and you can call out the measures in SQL statements and it will

46:04 Know how to interpret those measures correctly back in the SQL statements in the notebook. Is that correct? I cannot confirm that on the data brick side. I I just don’t know. Johnny’s on the call right here as well. There’s a couple Jake is also on the call in the chat window as well. Johnny or Jake, if you’ve used these metric views, I’m going to call you out directly. chat, you’re gonna come to my rescue here hopefully. If you have used metric fuse and you’re using metric fuse in notebooks, fill in my details here and I’ll I’ll come back to your comments. So, first one first one to chat to give me the right answer or even the wrong answer. I’ll talk about it

46:36 Anyway. So, I don’t even know if it’s right or wrong. I’m going to rely on chat here, but I’m going to Okay, so Johnny is saying yes, you can use the metrics view, but you have to wrap it in a function. Okay, I’ll have to go dig into that a little bit more later. And it’s a static item. Okay, interesting. Good. I’m just going to call that out there to chat to to give me any other details around using metrics views from data bricks in the notebooks. But going back to our point, Greg, there is some parts of this where this falls apart because we’re not writing like you you’re not assuming we’re going to write DAX inside the metrics view. You’re

47:10 Going to write SQL there. And so there is a translation to like what does that SQL statement mean? How would we get an equivalent DAX statement for the same measure? column seems pretty straightforward like name of column format type like I’m not seeing anything in columns that are like scary to me columns can also be arbitrary SQL in a metric view oh dog gone it so okay so then then yeah so this offers a couple of opportunities we can either generate M code

47:41 To columns on top and then those would be in the partition definition or we could use M to only import the columns that are physically available in those data bricks tables, not SQL ask and we could define a DAX calculated column to represent that. No, don’t do that, Greg. Delete that one. That’s a bad feature. put put that in put that in danger risk mode. Don’t don’t generate me calculated columns. Please don’t do that. So, but see, we’re doing some product design right now, but we we’ve got we’ve got options.

48:13 Feature downvoted feature downvoted. But I I wanted to call out something that you said, Mike, because I think it’s really important and it is really one of the core justifications for why we have a semantic layer. And you were talking about the idea of SQL to represent a measure. And if you’re writing a whole SQL query yourself, you would write the expression, so the sum of a column, and then you would write as to alias that thing with a name. And so that’s two pieces of information in a SQL query. The first is the expression

48:45 The logic to define this aggregation we care about and then also the naming is directly in line in a single SQL query and there’s no structure to that other than the structure of the SQL query. So this may be a lot a really big SQL query. It may do a lot of joins it could have some really complex filtering logic subts in inner join table weird stuff. Yes, things happen. And the structure of that is one big chunk of text that is SQL source code that runs somewhere in response to a user action. And that might be the

49:18 Definition that is the backing for a report, something like a pageentated report, SSRS, these more traditional reporting tools where you just define a SQL query and then you throw that onto the page and render it somehow. And so the idea of a semantic model in general, not the PowerBI semantic model, not tabular, not a metric view, just in general, a generic semantic model, you take this definition and instead of having it in this giant query, you have a structure where you say that we have many things that are measures. Each of these things that is a measure has a

49:52 Name. And each of these things that is a measure that is named has a definition. And we can pick which of these measure definitions we want. When you were doing this in SQL queries, you just had to grab one SQL query, read it, understand it. The semantic model is now in your brain. And if you want to write another query, you have to know which parts that you extract and copy paste over. And there was no structured way to do that. You would just open up a text editor that hopefully had some syntax highlighting and autocompletion for you. But you would open up the text editor and write a new query that reuses the idea of the measure. But the only way to

50:26 Reuse it is to copy and paste it and put it into place in a query. The idea of a semantic layer is by giving structure to this, by giving a name to each measure, by giving a name to each dimension and a name to the fact, then you can pick and choose these things atomically. And that’s what a tool like a PowerBI visual does. You’ve got this menu of options like a a restaurant menu, not like a program menu. You’ve got this menu of options that you can select from. And you say, “Ah, today I’d like the fish. I’d like the fact table and I’d like this measure. I’d like my fish prepared in this way. I’d like this measure from

50:58 The fact table. And you pull that into your reporting canvas. And because each of these things is a separate named object, it’s not something embedded in a query somewhere, but it is its own entity. This measure is then something that you can reuse and tools can automatically generate queries that include that measure. And so I don’t know if that’s the point you were trying to make, but it is the one that you did make is the idea of a measure as an object on its own. Exactly. That was it. You nailed it. The the idea of this object on its own instead of something just embedded in a giant piece of source

51:31 Correct of source code. that makes sense though. again I think about like the the cop so in a much better way of describing this the that’s what I was thinking right and to be jokes aside here a little bit like this makes sense because if I’m going to make the definition of some measure odds are I’m going to use it once or twice Tommy will need to go into the same experience write the same measure again and again again this is the whole reason why I really liked DAX and the semantic model in PowerBI is because I was looking at SQL servers and writing SQL and saying Okay, well, I’m

52:04 Just trying to investigate the data. And what I found was much faster was let’s just load the table into PowerBI and I can just drag and drop columns and behind the scenes it knows, hey, this is a implicit measure on a column as a number. If I’m just doing data discovery, it was so much faster than writing SQL. Okay, how many here’s a dimension. How many counts of records do I have of that? Okay, boom. Trick click and drag. Boom, boom, boom. a guy was able to write and I had an epiphany when I was in a different consulting firm that was like, “Oh my gosh, all I’m doing is writing really fast SQL

52:39 Statements that are built on top of DAX that I can then define common calculations and instead of having to write select these columns and do the order by and all the grouping things, all that stuff is handled. and the the extra syntax that SQL is powerful. And I’ll I’ll also argue I think SQL runs the world. I think the the most elaborate data systems you’re going to find in the world no matter what there’s some form of SQL ripping across them. There’s there’s now I think I think a shift in a little bit here where more

53:13 Modern systems are using like slightly different languages like Scola or or things that are being interpreted down to a different layer. But at the end of the day, mo I think almost all companies have SQL stuff laying around. It runs the world. It’s not going away. It’s SQL and Excel, baby, all the way down. Yeah. Yes. Agree. Whether you want it or not. Yes. Totally agree. Okay. This is really interesting. , wow. There’s a lot to unpack here. Okay. So, last maybe question I have here around unpacking this idea a little bit. One of the

53:44 Things that I really like about semantic models is the ability for us to add annotations to something. So if I’m building something custom, if I’m building like, , special things, I know that SQLBI does this a lot. SQLBI does a ton of adding annotations to, , hey, this is my date table. This was made by SQLBI’s Bravo tool. Inside there, it adds an annotation to that table or objects in the table say, hey, this is my date column that I’m going to be using. And they and what SQLBI does is they reference these common tables with a very common name.

54:18 And that way when they’re building measures or having automation of measures, they can say, “Oh, I’m just going to go look for annotations that have the things that I need and then go use those pieces of data from the model.” Does the YAML spec that data bricks provides, does it allow us to have the ability to have like custom YAML in there? For example, a measure might need to have an annotation on top of it. A , whatever we would want to add or is or do or are you aware again also asking chat here as well is the YAML definition extremely rigid when you’re working with data

54:53 Bricks and you can’t add additional properties that it just holds on to for the sake of holding on to them. It has a I don’t remember the name of the of the property. It’s either comment or annotation I think. but there is a property in the 1.1 version of the metric view specification that allows you to include this additional information. There are also confusingly comments that you can inline in YAML. It’s that’s also what I saw. Yes. and those are because they are YAML. They are comments in the YAML

55:26 Syntax. Yes. They’re not comments on the metric view objects. Yes. Those confusing you would Yes. So you could include that but they would mean nothing because any YAML deserializer which is what you do first you deserialize it so that you have an object model yes you won’t have those comments anymore because they are YAML comments they are comments in the syntax of YAML and so you would need a a deserializer that is aware of those things and captures them and feeds them through as some additional property. So you can put them in there and they will certainly be

55:58 Helpful for the maintainers of a metric view who are writing literal YAML but they aren’t useful really to anyone trying to consume a metric view because they are opaque in any object model of a metric view because they are not properties they are comments so I don’t I don’t remember if the the formal is called comment. Yeah. So that so I’m looking at this one. So you can do comments in the YAML to like save what you’re doing in the YAML and then there’s comments in the metric that you would then save back to the

56:31 Metrics that gives you a comment about what it is. And I don’t see in my opinion when I look at semantic models there’s there’s a really rich layer of metadata that goes behind the scenes that tools automation tools can use. And that’s and that’s to me where I see annotations coming from. An annotation is a key value pair annotation value answer, right? value or key and then the response to that, right? That makes a lot of sense because now I can then at mass add a lot of extra automation data to these metric things as well. So

57:04 There’s I do like the fact that they have synonyms that seems to be very corresponding to what we have inside PowerBI semantic models. do like this comment feature, but it doesn’t really fit or scratch the need that I feel like I have, which is I need metrics views in data bricks to contain the ability for me to add an annotation, which is just a series of key value pairs that I can then pick up later on and like use more programmatically. It feels it feels a bit clunky right now that it’s not going to be formulated as smoothly as I would like. So, I’m going

57:37 To have to go build a an array inside a comment that will have my key value pairs attached to them. , and have it all and and have it hopefully having the YAML parse correctly on on things. So, to me, that’s one area where I’d like to see data bricks improve that a bit more is like the this ability of like it doesn’t have to be called an annotation, but I I’m going to need the ability to add custom pairing of data elements on top of these measures so I know a little bit more how to handle them, especially like from the there’s a usability side of this that’s like the

58:09 User side, but then there’s like the automation side and that’s and that’s what I’m looking for. I need a little more support on the automation side for the data bricks metrics views. Yeah. And we will for several of the things that we’ve talked about that we’d like to implement for the semantic bridge, we will probably be taking a lot of advantage of annotations in the tabular object model to be able to capture things like what was the specific metric view object this came from and what was the original SQL definition of this thing. That would be very useful information to

58:41 Have in such a a translation pipeline. And we will have this we didn’t really talk about implementation but the the way we we go about this is we’ve actually defined an abstract dimensional model that is an intermediate representation which is the target for all translation through the semantic bridge. and that will also be very rich with annotations and being able to flow this information through. some of this is currently implemented but not used so barely implemented. Some of it is still in to-dos and backlog items, but we would

59:14 Like to be able to support very rich translation flow translation flows between more than just metric views and and tabular models. And so we’ve talked a lot about data bricks and tabular because well that’s what we’ve implemented in the MVP, but it is just an MVP. we expect to have a lot richer functionality going forward and that’s largely going to be driven by needs of our end users and of our customers. but there’s there’s there’s a lot of there is a lot of information about the information. There’s a lot of metadata about the

59:46 Structure of a semantic model and about about how it’s being used about where it’s coming from. And we want to be able to preserve as much of that as possible to aid in automated processing of these things as we’re translating them and building pipelines like this. So if I had to just quickly call out again, we’ve been talking a lot about data bricks because that’s what we know. Again, most of my customers are on data bricks and the ones that I have that are on Snowflake are debating whether or not we’re going to stay with them or not. , what is just as a quick question, what is the equivalent metrics view thing for Snowflake? What do they call theirs? Is

60:20 It just called semantic? I’m looking here. I’m trying to Google them real quick here. They just call I dropped a I dropped a link in our show notes and I have actually forgotten what the snowflake name is. , dbt also has a semantic layer. model spec cortex analysis semantic model specifications. Okay, so these these exist it seems like a lot of platforms are realizing what Microsoft knew back in the late 90s and early 2000s that semantic layers are valuable and it’s it’s about more than just writing a giant SQL query that

60:52 Does the right things and quickly. Yes. so and I want to double down on that point exactly because I like the fact that Microsoft made this decision a long time ago. the semantic layer was what they started with and so we’re now seeing other tools in the last year starting to come out with the semantic modeling data bricks PowerBI has been doing this since I’ve been around in it since 10 years now and even before that there were some of this back in power query and excel beyond that so you could probably already go back to like earlier than 2015 of when this stuff was existing analysis services is a lot of

61:24 This information as well so love the conversation super exciting Greg thank you for announcing this first here on the podcast. We really appreciate your announcement around this semantic bridge. I’m excited to see where this this project goes. One more feather in the cap of tabular editor again changing the market, leading the way and be very innovative on like stuff we didn’t even know we needed to have. And all of a sudden, boom, we now we now know we need this new semantic bridge between different data systems and making things

61:56 Easier for us to create artifacts that are PowerBI semantic models, which is exciting. Awesome. Very exciting there as well. Tommy, any final thoughts? Honestly, I love all the updates. Tableau editor is when I did restart my PC over the weekend because issue the first install. the one it’s one of the first installs and yeah me and my macros go a long way baby so but no I love seeing this and looking forward too with tablet editor also to the AI features that are coming out I’ve heard

62:28 About that as well so there’s a link so yeah that’s that one’s not mine to talk about as much but that’s also going to be in our January release so it won’t quite be a Christmas present but some things to look forward to in the new year awesome very exciting it’s hard it’s hard things out at the end of the year because everyone takes a little bit more time off around the holidays and things. So, it’s difficult to release Christmas presents for things. Microsoft themselves, PowerBI team is going to take a very big break. We don’t get any features in January. So, having some excitement in January from tab editor will be very encouraging. So,

63:00 Looking forward to that as well. All right. for those of you who want to play around with metric views, look at the the notes on this video itself and on the description. All the links that Greg provided. There’s some things about DBT semantic modeling. There’s some things around Snowflake and data modeling. There’s three links around metric views and data bricks, multi-dimensional modeling for Microsoft analysis services, dimensional modeling and and other articles as well. Check out the video description of this video. You’ll be able to see all the details and additional learning materials as well. Greg, thank you very much for your time on talking about developer

63:33 Experience tools. I think I’ve learned a lot. Again, , as always, whenever we bring on people that are way smarter than I am on the show, I continually am flabbergasted at how little I actually know, , and need to do more. I feel like I feel there’s not enough time in my day to continue pushing all these new cool experiences and ideas. It’s a lot of I I honestly think we’re in a very exciting time right now between AI, agentic things, pooling, big data systems. there there’s a lot of really interesting developments happening that I think we can stay busy

64:04 With for many many more years. That being said, thank you thank you all for joining and and participating with the podcast. we’re going to just wrap it here. If you want to become a member, check out our vid our membership down below. any recorded videos that are coming up here over the holiday break here and traveling that Tommy and I are doing, you’ll be able to catch those as soon as they come out. So we’d love it if you become a member. That being said, Tommy, where else can you find the podcast? You can find us on Apple, Spotify, or wherever you get your podcast. Make sure to subscribe and leave a rating. It helps out a ton. Do you have a question,

64:36 Idea, or topic that you want us to talk about a future episode? Head over to PowerBI tipsodcast. Leave your name and a great question. And finally, join us live every Tuesday and Thursday, 7:30 a.m. Central on all PowerBI tips social media channels. Thank you all so much, and we’ll see you next time. you. Let’s go down.

Thank You

Want to catch us live? Join every Tuesday and Thursday at 7:30 AM Central on YouTube and LinkedIn.

Got a question? Head to powerbi.tips/empodcast and submit your topic ideas.

Listen on Spotify, Apple Podcasts, or wherever you get your podcasts.