I normally don’t bother blogging when one of the Power Query monthly updates gets released – the posts on the Power BI blog have all the details and there’s nothing more to add. This month’s update, though, sees Power Query able to use SSAS Multidimensional and Tabular models as a data source (you can read the announcement here and watch the video here) and I thought that since these are my two favourite Microsoft products I should comment.
In no particular order, some observations/thoughts:
- Power Query is generating MDX queries in the background here. And yes, query folding is taking place here so where possible the filtering and sorting is being translated back to MDX so the work is taking place on the server. I’ve had a look at the MDX being generated and while it’s a bit strange in places it’s basically good and should perform well.
- In order to get Power Query to work I had to install the 2012 version of ADOMD, even though I already had the 2014 version installed. Hmmm.
- It also doesn’t display calculated measures that aren’t associated with a measure group, although this is going to be fixed in a later release. In fact I experienced several errors associated with calculated measures when I first installed the new release, but these went away after I cleared the Power Query cache and rebooted.
- This update does not support custom MDX queries, unlike the equivalent SQL Server data source; again this is on the roadmap though. This will be useful for two reasons:
- For complex queries, or queries that have to be written in a certain way to perform well, sometimes you have to have complete control of the query
- It would allow you to run DAX, DMX and SQL queries on SSAS, and also let you query SSAS DMVs. Custom DAX queries can perform a lot better than the equivalent MDX in some cases, and querying DMVs would allow you to build SSAS monitoring dashboards in Excel.
- The Excel Data Model (which lots of people call Power Pivot, but I’m going to stick to my guns on this one because the Excel Data Model is not the same thing as Power Pivot) is not supported as a data source yet either, even though it can be queried in MDX just like SSAS. This would also be useful to have although I can also see it’s harder to implement, given that the Excel Data Model is both a data source and a data destination.
- There are a whole bunch of new (well, not really new because they have been around since the support for SAP Business Objects came out this summer) M functions to generate those MDX queries. They probably deserve their own blog post at some point in the future.
- Apart from the obvious reason that it allows you to combine data from SSAS with other data sources and/or load it into the Excel Data Model, why is it useful to have Power Query to connect to SSAS? What does it give you over and above the existing PivotTable, Excel Cube Function and Query Table connectivity? Why do we even need to extract data from a cube in the first place?
- This may only be a minor reason, but a lot of people still do get caught by the problem of having multiple cubes where they should have one, and need to build reports that incorporate data from multiple cubes. Power Query gives them an easy way of doing this.
- I believe the step-based approach of Power Query makes it much easier for users to build complex queries than other SSAS front-ends, such as PivotTables. Being able to see the effect of filters and other transformations as they are applied, and being able to delete them and rearrange the order that they are applied in, is a huge benefit. Think of Power Query as being a custom MDX query builder where the output is a regular table in Excel rather than a PivotTable.
- This last point leads me on to a topic that I’ve been thinking about a lot recently, and which will be the subject of a whole series of blog posts soon, namely that it is wrong to think of Power Query as simply a self-service ETL tool. It is that, but I also think that has a lot of potential as a self-service reporting tool too. For both relational database and SSAS I think Power Query could be very useful as a means of creating SSRS-like detail-level reporting solutions inside Excel. Problems with the MDX generated by PivotTables mean that queries with large numbers of hierarchies crossjoined together perform badly; the MDX that Power Query generates does not suffer from this problem. Functions can be used to parameterise Power Query queries (in fact earlier this evening I learned something immensely cool about function parameters that I’ll blog about later this week and which will make functions even more useful!) and can therefore be used in almost exactly the same way as datasets in SSRS.
