Power BI at Enterprise Scale

Last night I was scheduled to present this topic at the Power BI User Group in Portland except the meeting was cancelled because of a snowstorm; except the snowstorm didn’t happen… not even a little. In fact, the roads were so clear and traffic was so light (because everyone stayed home from work to avoid the alleged storm) that I nearly got a speeding ticket on the freeway during what would have normally been rush hour traffic. I made the the 60 mile round trip from my house to the venue and back in under an hour.

Since I had prepped up my presentation, I decided to record and post it here on my blog. Please like it on YouTube but post your questions here so other community members can see them. I’ll add the transcription below.

This presentation demonstrates how to implement Incremental data refresh and discuss a recent reference project that required versioning & managing high-volume data. We discuss: Composite data models, dual-mode tables, partitions & parameters in Power Query.

We’re going to talk about new features in Power BI specifically designed for managing large-scale, serious IT-driven and managed solutions. This presentation was actually prepared for a live session at our local Power BI user group meeting which was cancelled due to a snowstorm that didn’t occur. The pop-music references were there to incent participation and there were prizes for correctly guessing the artists of the songs that I referenced – just for fun.

What’s this all about?
We’re going to talk about BI models… the way that we did serious data modeling in the past, today and where that’s going in the future. We’ll talk about some new, evolving emerging, and some existing Power BI Enterprise features which includes different modeling choices, how the design tool features are merging and where that’s heading over time. We’ll talk about working with data in high volume and massive scale; and then I will show you a reference project which is a real project that I worked on recently. I’m actually using screenshots of that project simply because there was a lot of sensitive data. A live demo of a sample project will follow.

We’ll talk about composite models and then I’ll demonstrate using parameterised queries – which you can use even if you’re just in a regular shared capacity tenant without premium features. And then incremental refresh policies, which are a premium feature, to take that to the next level.

The Way We Were
So let’s think about the song title first and we’re going to talk about the way that serious BI solutions used to be and then we’ll talk about where that’s going in the wake of Power BI. So, The Way We Were of course… that’s a reference to a song sung by Barbra Streisand for a movie that she co-starred in with Robert Redford of the same title.

Serious BI solutions have in the past used SQL Server Analysis Services for data modeling and storing that data, and of course we’re talking about analytical datasets that are used for analytical trend reporting the kinds of things that we typically use tools like Power BI for. In the past, Analysis Services is installed with SQL Server onto an on-premises server. You pay for that server; you not only have to buy the hardware and manage, optimize and tune but there are also licensing costs associated with SQL Server outside of Power BI. Typically, the person who’s going to design those data models and manage those data models is a person like this. They’re a very technical person. It’s a fairly complicated thing. It’s time-consuming and these people generally work for an IT organization. That’s the traditional approach.

Times, They Are A Chang’in
What’s the song reference? …of course that was a song performed by Bob Dylan in the 60s.
Visual Studio has long been the design tool of choice for serious semantic data model design and up to as recent as a year ago, that was my recommendation. If you’ve got serious data large volume data you need to protect that data, it needs to be a govern dataset that is being managed seriously within the organization… That’s typically going to be owned by IT; and they’re going to design it deploy it, manage it and then users can connect to it – or IT will build reports that users can use. That’s the way that things have been and but things are changing.

Come Together
Tool sets are coming together and of course “Come Together” as a reference to a song by the Fab Four, the Beatles.
What’s coming together? …the features of Visual Studio SQL Server Data Tools (SSDT) for Analysis Services tabular and Power BI Desktop are coming together. Now it’s a bit of an evolution. We’re seeing features added to each of the tools but they’re definitely converging and so we would typically use Visual Studio the SQL Server Data Tools add-in for Visual Studio to create tabular data models like this but now we have these same capabilities – and even more capabilities – in Power BI Desktop. Power BI Desktop is really kind of becoming the preferred tool.

That Was Then But This Is Now
You’d have to have grown-up in the early 80s to get this song title. This was a song, and the name of an album, from a pop/dance group in the 80s called “ABC”. They did some great songs like Poison Arrow and When Smokey Sings, but things are changing and we’re now at a place where Power BI is moving at a very rapid pace. The development of that product is very quick and the product team will focus on adding features to the product that they own and they manage; and that is Power BI Desktop. In order for this to be a cohesive development experience and for Power BI Desktop to be a tool that is aligned with the Power BI service, Power BI Desktop is really becoming the recommended enterprise BI development tool. Now, that’s not to say that there aren’t features and capabilities of SSDT in Visual Studio that may be preferable in some cases but today Power BI Desktop is the tool that I typically go to first before falling back on Visual Studio so you think about that experience we author in Desktop. We manage all of our development in Desktop; our queries, data sources, security, the data model calculations and the report visuals. All of that is done in Desktop. We deploy those assets up to the cloud, into workspaces in our Power BI tenant.

Peeking behind that cloud out there… that’s not the Sun that you see; that’s actually the Analysis Services tabular engine. That’s right: Power BI in the service, up in Azure actually has an instance of Analysis Services tabular that manages our data models. This is the same analytic database engine that’s available when you install Analysis Services on your own server with the the SQL Server install bits. The enterprise features of SSAS just have to be lit up through the Power BI tools that we’re using

What enterprise features are we talking about well we’re talking about DirectQuery which is a capability that allows you to not import data into your data model but stored metadata about tables so that when users interact with reports queries are generated in the native query language of the data source; whether that’s SQL Server, Teradata, Oracle or whatever – and those queries are actually processed by that data platform and results are sent back to your Power BI reports. There are trade-offs but it is still viable with some important features.

Composite data models give us the ability to use the capabilities of DirectQuery with the capabilities of imported/cached tables as well. Because there are performance trade-offs with DirectQuery and when we’re just generally working with data at scale, very large volumes of data, that’s going to impact performance. This impacts performance drastically with DirectQuery but it can also impact performance with imported/cached tables as well.

Aggregations give us a mechanism for speeding up those queries in our reports by actually storing aggregate values at different levels of grain. I’ll show you what that looks like and then incremental data refresh policies allow us to automatically generate partitions over our tables for a couple of reasons: First) so we don’t have to run huge queries to reload high volumes of data, and Secondly) so that we can break-down the the data stored for those tables so that we don’t have to reload unchanged historical datasets. We can only refresh new data and perhaps more recent data for our large tables.

The XMLA endpoint… as of this recording, this is still a forthcoming feature. We know that the product team are actively working on the XMLA endpoint for Power BI which will give us the same capabilities we have for Analysis Services today, so that third parties can develop tools, we can write PowerShell scripts, we can do automation, and we can generate scripts. We can do all of those things that we do have access to with Analysis Services – against Power BI that we haven’t had access to in the past. This capability will really open up the gate for for serious automation, for DevOps, build management, version control. Those things are going to become much easier when we have this programmatic and metadata layer access to data models.

If you’ve attended a Microsoft event or a conference where the Microsoft product team folks have presented about Power BI recently, you’ve probably seen this demonstration.
How is this possible that in a Power BI report we can surface six trillion rows of data?

Most of us don’t work with datasets this large but this is an excellent example of how these new features can enable such capabilities and we’re going to talk about how that works. Before we talk about enterprise scale, let’s talk about the limitations of different levels of Power BI and Analysis Services.

First of all. it’s important to understand that when working with Power BI data models and Analysis Services tabular data models (which technically are the same thing), that data is always compressed. The compression ratio (the degree to which the size of your data model will be reduced) depends greatly on characteristics of your data. Correctly modeled data will allow you to achieve compression ratios of typically up to about 20x. We generally we expect to see 5x, 10x and 20x compression but I’ve seen tables that compress much smaller: up to let’s say 50x or even 100x but that’s not very usual. This depends on characteristics like the the sparsity of the data, duplicate column values, the data types and granularity of key values. The more sparse the data, the more duplication or empty values there are in column values, and the less granular specific values are; the more that data is going to compress.
Model Size Limitations

Thinking about compressed data sizes, a standard shared capacity Power BI tenant will allow you to upload up to a one gigabyte PBIX file (that’s again, compressed data). We want to reduce the size of these files as much as possible and especially reduce the size of the file that you actually upload. If we can perform a data refresh that will then expand the size of the data, making all necessary data available after it has been refreshed, that’s better than having to refresh your Desktop file before you upload it.

What about if we are dealing with more data than one gigabyte?
In Power BI Premium dedicated capacity, a premium tenant will allow you to upload and store datasets of three to twelve gigabytes. This depends on the level of the premium capacity subscription that you pay for each month. The largest capacity will allow you to upload a file that is up to ten gigabytes in size, then when you refresh that it can expand to up to twelve gigabytes. so that’s that’s actually a lot of data for most solutions if you need to exceed that though, you can use Azure Analysis Services in the cloud (so no hardware to buy and nothing on prem.) It is in Azure which means that Azure Analysis Services is a neighbor to Power BI – possibly in the same data center – so connections between that data are very fast. Depending on the service level, you can store up to 400 gigabytes of compressed data in Azure Analysis Services.

On premises, if you have Analysis Services installed on your own server: if you use SQL Server standard licensing, you are limited to 16 gigabytes per database.

If you use enterprise licensing, there is no stated limit. The product itself can deal with any size dataset but you’re limited just by your hardware. Think about modern server hardware where you know we can have very large shared storage. Of course, memory is a limitation for the tabular engine but modern, well-equipped servers can have 1 to 4 terabytes (or more) of RAM. That’s a lot of memory that can manage a lot of data …so really, virtually there there is no limit to the size of the dataset that you can manage in SQL Server Analysis Services with enterprise licensing.
Let’s talk about how to optimize that experience. Another song reference…

Blurred Lines
Of course, that refers to the the dance song from Robin Thicke and Pharell Williams who were famously sued by the Marvin Gaye family due to copyright infringement.
what do I mean by “blurred lines”? Well, the distinction between Analysis Services and Power BI are becoming blurred because Power BI uses the Analysis Services tabular modeling engine. In the past, we’ve had a subset of those features and now we have a superset of those features but Analysis Services also has features that Power BI doesn’t have. This means the two really are converging, feature-by-feature, as they’re being added to each of those services and tools. There is definitely a shift to the Power BI toolset and the Power BI service from Analysis Services in terms of the preferred tool to use for developing solutions.

I want to cite a reference solution that I recently finished up for a client. I’m not going to show any sensitive data here but I did want to show the row counts of various tables. These table sizes have actually increased since I captured this screen but you can see that we have some relatively large tables here… just shy of five million appointments; just over six million charge capture records (which is an extension of patient encounters), about 20 million test results. The largest table in this model today has about 30 million records. The “person-measures” table in the bottom row had 16 million at the time that I captured this but that’s up to about 30 million now.
In this reference solution, how did I design for scale? There were several high-volume tables that I filtered using parameters. That was to reduce the working dataset size and to reduce the size of the PBIX file. This was, 1) to speed up development and, 2) so that it didn’t take forever every time I deployed a new version of that dataset file.

I’ll point out that in new Power BI projects I separate the dataset and report files. I create two different PBIX files. There are some minor challenges in doing that so actually I start with one PBIX where we manage the queries, the data model, measures (calculations) and the reports. But then when we get ready to transition to a true version management & ALM model, I create a separate copy of the PBIX file where the reports are connected to a separate, published dataset. That copy of the PBIX file only has the reports in it. You can actually copy and paste visuals from one Desktop file to another now. In the end we only have the queries and data modeling calculations in one file, and the reports in another file. That makes it a whole lot easier for users to do their own reporting as well. The dataset PBIX file can be large and I use parameters to reduce the size of that file. Then we can fill it up with data when we do a full data refresh, once it’s been deployed to the service.

How are parameters used to manage the dataset size? Well, we define two parameters. If you look at the documentation for the new incremental data refresh policy feature, you define two parameters called RangeStart and RangeEnd. They have to have these case-sensitive names and they have to be date/time datatypes. Even if you’re working with date-only data, they must be date/time types in order for this feature to work correctly. You then give them default values. Here, I used a range of one-year: January 1 2018 through December 31 2018. Then, I imported the tables from views.

This is key: database professionals tend to try to solve problems in SQL, which is fine because that’s an effective tool for joining tables together, creating aliases, doing groupings and aggregations. You know, all of those things can be done in SQL. However, for this and many other features to work correctly, Power BI prefers – and in some cases only works with – single database objects that it perceives to be tables. That that could be a table, or it could be a view, or it could be a table-valued, user-defined function. As you can see here, once I’ve connected to the data source, I have this list of views (I actually wrote a view for every single table that I wanted to import) and then I just select those views rather than using inline SQL. You need to select database objects from the source and don’t write any inline SQL queries. Again, I created views to consolidate database queries on the server and we actually created a separate database just to contain the views. This was so we didn’t have to to put those views into a vendor database. Next, we create a row filter step. That’s very simply: you go to the column that is a date/time datatype (this is our partition key that we want to filter on to create partitions) and just create a date filter on that column.
The row filter must use this logic on the column: is after or equal to RangeStart, and is before RangeEnd. Again, the column has to be date/time just as the parameters are date/time – even if you’re just dealing with dates, it has to be date/time. You want to perform that filter as early in the query as possible (by “query”, I’m referring to the Power Query query in Power BI Desktop) and the reason that we do that is that we want the filter to get folded into a native query. This only works with data sources that support query folding. There are many data connectors that support query folding. Query folding means that the “M” language query in Power Query gets translated into the native query language of the data source. In this case (since we’re using SQL Server), the native query language is T-SQL. If it were Oracle, it would be PL/SQL and if it were Teradata, it would use the Teradata SQL dialect, etc. Here, you can see the predicates down at the bottom of this native query that I’m viewing. It says WHERE encounter timestamp is greater than or equal to…and less than…the parameter values. Power Query generates the folded native query with this filter, and if you have steps later in your query that break query folding with some complex transformations, things still work as they should. It’s OK because the queries already been folded at this stage of the query and the results are cached in memory for later steps to be applied. Power Query works against that cached result set as a result of this folded filter parameterised query.
Within the data model, we define an incremental refresh policy. That’s done within the data model designer and not in Power Query. That feature will only light-up and enable you to perform the incremental refresh policy feature when you have this filter in place referencing this pair of parameters. You define the period number and period type. In this case, I’m saying five years. If I were to say sixty months, it would generate sixty partitions instead of five partitions. I actually had a table in this project where the SQL Server query plan was was so poor (because so many tables were being joined together and there were some indexing issues in in SQL Server). Those queries were very slow and the one-year partitions actually would timeout. By using months instead of years to partition, the Power BI service generated a series of smaller queries that didn’t timeout and it solved that data refresh problem. You can optionally detect changes using the check box you see down at the bottom of this dialog. If you select that option, it prompts you to select a column in the table with the last update date. This would typical be a timestamp type column that a database designer would use for ETL maintenance. This will detect changes and automatically refresh those changes.

To Cache Or Not To Cache
Even though the spelling is different, this is a reference to the late great Johnny Cash, just for fun.
Imported, in-memory data tables provide high performance. Okay, so this this is an important learning about using the Vertipaq Analysis Services engine: In its most native mode, where you import data into the model that is held in memory, you can expect high performance but the trade-off is that you have to have a place in memory to put all of that data. DirectQuery tables, by contrast, offer scalability so if you have you know massively large data at the data source; it may not be feasible to import all of that data. There’s a lot of goodness that you get if it is possible to import all the data into an in-memory data model. It makes things simple, development is faster, performance is going to be good and your projects are uncomplicated. All good news, but in cases where there is a bonafide reason to use DirectQuery to deal with data at scale, perhaps using unique data sources that deal efficiently with large volume data. There’s a lot of goodness in this option as well but there’s such a trade-off between those two different options.
Now, we have composite data models. These are the best of both worlds with what we call “dual mode” tables and optionally predefined aggregations.
So, what does that look like? In the past, the only option was to use one or the other – either DirectQuery or import. You could not combine tables in both modes into a single data model. Today we have the ability to create composite models where tables can either be DirectQuery or imported. It’s important to note that you can’t take an import table and convert it to a DirectQuery table but you can take a DirectQuery table and convert it to import table. Composite models provide performance for cached in memory tables but also provides some flexibility supporting high volume and near real-time access from data sources. DirectQuery has some performance trade-offs and some calculation restrictions; there are certain DAX functions that will either not be supported and not work at all or will just perform very poorly because of the way that they have to handle a lot of data at aggregate. There are reasons that DirectQuery has been kind of a difficult pill to swallow in the past. Aggregations allow us to mitigate some of these performance concerns. The idea behind aggregations is that we define a virtual table in the data model that is the aggregate of values grouped by a group of keys. As you can see, sitting between the date and geography tables we have this aggregate table that we’re calling Aales Aggs, and if the grain of the Date table is one row per day, and the grain of the Geography table is City, then we’re going to have one row in the Sales Aggregate table per each combination of Date and City with grouped and pre-aggregated values. When a user navigates to a visual or uses a report that is grouped on Date and City, they’re going to get that pre aggregated value rather than having to go back to a fact table and perform the aggregation on-the-fly. If that fact table were DirectQuery, then it’s not going to have to go out and run a group by SQL query against the data source. So, this resolves performance issues by storing the cached aggregate results and the aggregate tables are already rolled up at a certain level of grain. You can have multiple aggregate tables. This all requires some planning and advanced design skills. Typically, you’re going to use aggregations to solve performance problems. Perhaps, with more experience, after we have years of experience with this feature, we’ll be able to look at a model design and say “OK, yeah we ought to put an aggregate table there” but today, we see that there’s a performance issue and say “let’s add some aggregations to to take care of that performance problem.” It’s a brand brand new feature and it does work well. We just don’t have much experience with this yet.
As you can see in this image, we specify the columns for a table that we want to group on. This is much like a lot of user experience interfaces that we already have in Power Query and in query building tools. We just say “I want to group by the Order Date, the Customer and the Product Subcategory and then I want to aggregate the Sales Amount and the Unit Price using sums.”
You can create multiple aggregate tables to support different levels of detail or grain. Since the aggregate values are stored in the model, it does increase the model size but if designed well, the storage costshouldn’t be significant. The purpose is to improve performance and mitigate the performance handicap of DirectQuery tables. You’re not limited just to DirectQuery but that’s a use case that that’s very common.
Something to keep in mind is that these aggregates are stored in the model and of course DirectQuery results are not stored in the model, therefore there is opportunity for the DirectQuery tables and the aggregate tables to to become out of sync so refresh often and just manage expectations around that. Just know that this is a trade-off of using aggregations with DirectQuery.

Show Me The Way
What’s the song reference? I’m gonna show you a picture of the group but I’m not going to tell you who they are yet. what are we talking about? Well, these are our demos so I’m going to demonstrate a couple of things. I’m going to show you query parameterization, which is not limited to premium capacity tenants. Then, I’m going to show you incremental refresh policies which are kind of an extension of query parameterization. Incremental refresh policies are a premium feature.
Show Me The Way was a great song in the 80s from the group Styx. Peter Frampton also had a hit with a song by the same name in the mid 70s. Alright, let’s take a look at our demos. This is a Power BI project that I’ve created with data from a an on-premises SQL Server database… the Contoso DW database, with retail sales information here in Power Query…
(demos)
Thanks for watching. Contact information is on the last slide.