The short answer: yes. And it’s a metrics layer and a metrics store and it’s headless BI too for what it’s worth.
I’ve been meaning to blog about this question for a long time now, for two reasons:
- Customers migrating to Power BI often ask me if Microsoft also has a product or service that can act as a semantic layer, so I need to explain that Power BI is already a semantic layer.
- I read the deliberations of the cool kids of analytics (Benn Stancil for example, who I enjoy a lot) and get the feeling that Microsoft and Power BI inhabit a separate universe that is invisible to them. This exchange on Twitter is a prime example.
The reason I haven’t blogged about this question yet is that earlier this year Aurimas Račas wrote a truly outstanding blog post on this subject, which I strongly recommend you read:
What more could I say? Well Aurimas’s blog post has the virtue of being impartial and I thought it would be useful adding a few thoughts from the perspective of a Microsoft insider. These opinions are my own, not official Microsoft opinions, but I don’t think any of my colleagues would disagree with them.
So is Power BI a semantic layer?
Back to the main question. Whether or not we do a good job of promoting Power BI as a semantic layer to customers we certainly think of it as one internally; I see it referred to as one internally all the time. Indeed we always thought of Power BI’s ancestors Azure Analysis Services and SQL Server Analysis Services, all through their 20+ year history, as semantic layers too – who remembers the terms BI Semantic Model or UDM?. One of the points Aurimas makes is that this is an awareness problem more than anything else: because Power BI can be used as a self-service BI tool as well as an enterprise BI tool and because more people use it as a self-service tool, the perception of it as such prevents some people from seeing it as an enterprise BI tool. On the Power BI CAT team we certainly work with a lot of large customers that use Power BI as an enterprise BI tool and semantic layer successfully: Walmart’s finance team is a greate example and their recent case study here (this older video is good too) explicitly mentions that they use Power BI as a “semantic model library” on billions of rows of data.
Preference for thin(ness)
Another great point that Aurimas makes is that the current preference in BI tools is for them to be thin layers that “delegate the computational workloads to the (cloud) databases/warehouses where the data is stored”. Back when I first started in BI the debate was between MOLAP and ROLAP and while the pendulum has swung in different directions over the years we’re still arguing over the same points with Import mode versus DirectQuery. My personal opinion is the currently unfashionable one: Import mode and the Vertipaq engine will always outperform an approach that involves generating SQL against an external database, however fast and scalable that database claims to be, for anything more than basic BI requirements (I’m watching Google Malloy with great interest though, along with whatever SQL additions Julian Hyde is working on). The official Microsoft guidance is that Import mode should be your default choice and at present, as this video by Alberto Ferrari shows, the performance differences between Import mode and DirectQuery mode are significant. As the Walmart case study referenced above mentions, you can always mix Import mode and DirectQuery mode in composite models and build aggregations if you’re working with data volumes tha are too large for Import mode alone. We are continuing to invest in improvements to DirectQuery such as Horizontal Fusion and I think that will close the gap between Import and DirectQuery a lot.
DAX or SQL?
In the same way the MOLAP vs ROLAP debate has dragged on for twenty-plus years, people have always argued whether SQL is the right language for expressing BI queries and calculations or if another language – MDX when I started, DAX today – is necessary. To be honest I think if SQL was the right choice the argument would be settled by now and we’d already have a whole ecosystem of BI products allowing you to define complex measures in SQL in a way that developers found easy to understand. Even if you accept that another language is necessary (and the people working on Google Malloy agree on that point) then there’s the question of whether DAX is a good solution to the problem or whether a different approach would be better. DAX is certainly hard to learn but that’s more because of the concepts involved rather than the syntax itself; Marco Russo’s post here is a great explanation of why DAX is simple but not easy. Since the concepts are the issue I strongly suspect that any other language that was as powerful as DAX would be just as difficult to learn. What’s more we’re working on making DAX debugging easier, for example with the EvaluateAndLog function, and making writing calculations easier with the upcoming visual calcs feature, and there are a lot of other similar improvements we could and should implement in the future.
Will these points change anyone’s mind? Probably not, especially since these questions are religious more than anything else: you’re either a Microsoft fan or someone who would never, ever consider using a Microsoft product; you’re either a SQL die-hard or you aren’t. Does this matter? I’ve seen Power BI’s all-conquering usage figures and I’m not sure it does. I love theoretical questions about semantic layers as much as anyone else but what really matters is whether a tool is used and providing value to businesses.