Trying to understand what is going on under the hood with a Tabular model is possible using the SSAS DISCOVER_OBJECT_MEMORY_USAGE Rowset – but the results aren’t going to win any prizes for accessibility. The mighty Kasper De Jonge had a crack at making it accessible back in 2012 using a PowerPivot model. However it didn’t help me filter down the way I wanted so I decided to up it a notch with a Tabular model on my Tabular model’s memory usage.
A Tabular Model on DISCOVER_OBJECT_MEMORY_USAGE
The main features of the Tabular model are:
- A Measure for Memory usage (kind of important)
- A Hierarchy for exploring the structure of the memory use
- An Attribute for the Model (so you can filter on just the model you want)
- An Attribute for the Model Object (e.g. Hierarchy, Column Storage, Data Sources, etc.)
- An Attribute to identify Server objects (such as Server Assemblies) vs Model objects
Before we get into the gnarly details, here’s a look at what comes out the other side:
What you get is the capacity to browse down the hierarchy and apply a few useful filters:
- Filter to the Model(s) you are interested in
- Filter for the type of Model Object (e.g. Column, Hierarchy) you want to focus on
- Filter for Server / Model level objects (largely useful for just getting rid of server level noise)
Things that work well, and not so well.
Actually, it mostly works pretty well. It cleans up most of the GUIDs that make navigation tricky, categorises objects usefully (for me, anyway) and the logic baked into the view that does most of the work is not too hard to follow.
The biggest problem is that the hierarchy of objects doesn’t always make sense – there seem to be Model level objects at the Server level with no attached model. This is probably more to do with my understanding of how the server handles certain objects.
However, I’m always happy to get some feedback on this and any suggestions – especially on how to categorise things properly – will be greatly appreciated.
How to get this in your environment
The solution comes in a few parts:
- SQL Table to hold the contents of DISCOVER_OBJECT_MEMORY_USAGE
- SSIS Package to extract the results from DISCOVER_OBJECT_MEMORY_USAGE into the table
- SQL View to translate, clean and categorise the output from DISCOVER_OBJECT_MEMORY_USAGE
- A Tabular model to help structure exploring the output
- An Excel spreadsheet to show the results
If you want to get this up and running, the pack here has everything you need. In order to install it do the following:
- Run the SQL script dmv_SSAS_Tabular_DISCOVER_OBJECT_MEMORY_USAGE.sql to create the destination table
- Run the SQL script vw_dmv_SSAS_Tabular_DISCOVER_OBJECT_MEMORY_USAGE.sql to create the translating view
- Run the SSIS package in the the SSAS_DMV project to load the table
- Deploy the SSAS project TabularObjectMemoryUsage to create the tabular model
- Open the spreadsheet ObjectMemoryUsage.xlsx to explore your results
Along the way in steps 1-5 you’ll have to set connections/configurations to ones that work for your environment.
Have fun playing!
The cube on my project has been hitting some apparent concurrency issues, so I’ve been hunting for advice on how to tune the hardware (model tuning has already gone a long way). Unfortunately Microsoft don’t have any reference architectures – and their only other advice was to try and use an appliance in Direct Query mode – which was not practical in our circumstances any way.
As usual, the gents at SQLBI had something useful to say on the subject based on a customer case study, which is detailed in this white paper. While well worth a read, I’ll summarise the key findings:
- Standard Server CPU’s don’t perform well enough, and you will need to look at faster CPU’s with a large cache
- Faster CPU’s are better than more CPU’s in terms of return on investment for perfromance
- Fast RAM is a must
- For NUMA aware servers you need to set the Node Affinity to a single node, preferably using a Hyper-V host for your tabular server
Setting aside the last point, which is a bit deep in server config and requires more explanation, the key thing is to look for fast CPU. They found that Workstation Blades were generally better than Server Blades, and some of the best performance they got was out of one of their Dev’s gaming rigs!
We’ll be trying some of this out and hopefully I can keep you posted with results. I have more stuff on monitoring tabular in the pipeline now I’ve finished my PowerPivot book (to be published soon).
Also, don’t forget my upcoming DW Starter Training on Nov 24/25 in Sydney
The end of the year is closing in fast but there’s still plenty of chances to learn from specialist providers Agile BI, Presciient and of course, me!
Topics cover the full spread of DW, BI and Analytics so there’s something for every role in the data focused organisation.
Build your Data Warehouse in SQL Server & SSIS with the BI Monkey
Nov 24/25 – Are you about to build your Data Warehouse with Microsoft tools and want to do it right first time?
This course is designed to help a novice understand what is involved in building a Data Warehouse both from a technical architecture and project delivery perspective. It also delivers you basic skills in the tools the Microsoft Business Intelligence suite offers you to do that with.
Agile BI workshops
Power BI specialist Agile BI brings your product updates on this key new self service BI technology:
Oct 15 – Power BI workshop – Excel new features for reporting and data analysis – more detail here
Oct 30 – What Every Manager Should Know About Microsoft Cloud, Power BI for Office 365 and SQL Server 2014 – more detail here
Dr Eugene Dubossarsky shares his deep business and technical exercise across a range of advanced and basic analytics. Full details here but the key list is:
Dec 11/12 -Introduction to R and data visualisation
Dec 18/19 – Business analytics and data for beginners
A quick and dirty one – in attempting some clever dynamic security modelling in DAX I was warned about a gotcha in my design – that calculated columns were only evaluated when the model processed, so any approach based on calculated columns was doomed to failure. I didn’t quite believe it so I decided to do a road test in PowerPivot. Using a simple data set of one Dimension and one Fact, like below:
I hooked them up in PowerPivot with a relationship between “Column” on both tables. Then, using the ISFILTERED() function I created a couple of calculations. One, at Row Level, that would return a value of 1 if I filtered on the Attribute column:
Which I then put a SUM on top of. I also added one at measure level, perfoming a similar function:
Then I created a Pivot Table checking the results, and got this:
The takeaway being that filtering on the Attribute was picked up by the table level measure, but the calculated column did not change value.
You can have a check of this yourself in my sample workbook: DAX Calculated Columns Evaluation Order.
What does the documentation say?
Well, nothing terribly clear, but in this page there is this small paragraph:
When a column contains a formula, the value is computed for each row. The results are calculated for the column as soon as you create the formula. Column values are then recalculated as necessary, such as when the underlying data is refreshed.
It doesn’t say exactly when “recalculated as necessary” is necessary, but the implication is that it’s a model level change, rather than the switching of context, or in my case the changing of the user viewing the model.
So in summary, we have to assume that our calculated column values are fixed upon initial calculation, formula changes or data load (or processing in a Tabular model) and there isn’t a way to make the value in a given cell change.
Well, that title makes much more sense in the context of this post in which I mused about the difficulty of developing against tabular models in a multi developer environment, given there is only one .bim file to work against. I even raised a connect to give the SSAS team to have something else to mark as “Won’t Fix” for the next release (cynical, me?).
Now to stretch an analogy if the problem is two drinks and only one mouth, then the solution clearly is cocktails*!
Mix me up a BISM Normaliser, barman!
A chap called Christian Wade has kindly built up a nifty Visual Studio plug in called BISM Normaliser which handily merges two tabular models together giving you an option to handle development in a multi user environment. You put 2 models side by side and get a comparison screen like this:
You can then merge in tables, columns, relationships, measures – all the good stuff. It’s like a diff but considerably more usable than doing a raw XML comparison. This means if you start from the same base model – advisable as tables are grouped by connections so if your connections don’t match you can’t merge – the dev team can work on separate areas and then merge it back together at some point.
It’s not a substitute for a proper multi-author environment, but at least it makes it possible. There are risks of course – it’s a no warranty codeplex plug in – and you won’t get the benefits of TFS managed components (source control, changes, etc) – and the code currently is set to expire in Dec 2014 so if Christian sells the code you’ll need to buy it off someone.
Anyway – there is a partial solution – on our project we’ve given it a first pass and it seems to do what it claims and since we have no alternative it’s going to get used. So, big thanks to Christian!
*Or Jagerbombs, but let’s not go there:
The project I’m currently working on has at it’s heart a whopping great tabular model with dreams of eating more tables and being the biggest, fattest tabular model there ever was. To achieve it’s ambition of eating all this lovely data and becoming so vast it needs an army of chefs … er, developers… to feed it.
Except it has one big problem:
It only has one “mouth” – the .bim file. Only one person at a time can work on it. If you want to do simultaneous development, realistically all you can do is maintain separate versions and merge your changes together either by a diff tool, manually (or potentially via BIML script if that eventuates)
So I’ve raised a connect: Componentise Tabular models to allow for multi user development to request that the .bim file can get broken up into chunks. The text of the connect is below:
At present the Tabular model is a single code object (the .bim) file. This means it is not possible to break up the development of a model across multiple developers – a problem in large projects. It also makes source control less effective as you cannot track which specific objects within the model have been changed.
The model needs to be componentised so that individual elements can be worked on separately and then merged back into a main model, in a manner more similar to OLAP cubes.
Elements that could be broken out are: Perspectives, Connection Managers, Individual tables, Calculated Columns, Measures and relationships
Anyway… if you think this is a problem you’d like to see solved – vote it up!
The MIST developers – Varigence – have been waving their product at me for a wee while now and I’ve finally had a chance to get into the IDE and get a better feel for it.
Before I get too carried away, here’s a quick 101. There’s this thing called BIML – an XML dialect for describing BI Assets (for now, only in the Microsoft world). This opens the door to scripting and therefore simpler dynamic generation of BI objects. BIML can be used by BIDS Helper (a thing you should have if you are an active BI developer) or the more focused BIML IDE MIST.
My feelings so far? I’m a bit “meh”. Now I know there’s a lot more capability to the product which I haven’t got to yet – so this is far from final commentary – but there are a few clear things that I think need to be looked at in the product to give it the sense of really being a development accelerator.
First up, it’s pretty clunky. It suffers heavily from “kitchen sinkism” – i.e. because it can do something, there’s a dialog box / screen / tab for it displayed all at once. Take for example this table development screen:
There’s a lot going on and that’s on a 1920×1080 screen…. some better screen space organisation is needed.
Next up is the fact that the designers don’t add a lot over the basic SSMS capability. The table designer there is effectively the same blank grid that you get in the SSMS table designer, but without even the courtesy of being able to add another row without going back to the ribbon. At this point I’d be more inclined to develop in SSMS and import to MIST.
Then my next concern is over value add / accessibility. For example, when setting up a project there’s some basic stuff that needs to be done – setting up connections, importing from databases – that should just be a wizard when starting up a fresh project. When creating a dimension, a bundle of default attributes should be added (preferably from a checklist or custom template).
So my first impression is that it needs a user experience workover. However this is a far from unique criticism of many developer tools so I won’t go too hard on them. I’ll press on with it and see how the functionality unveils itself.
Thanks to the lovely people over at Syncfusion I’ve been able to share my experiences with HDInsight in a short eBook for the “Succinctly” series which was released this weekend. It is unsurprisingly called “HDInsight Succinctly” and is free to download.
For a quick precis this is the summary description from the website:
Master the higher-level languages and other features necessary to process data with HDInsight. Learn how to set up and manage HDInsight clusters on Azure, how to use Azure Blob Storage to store input and output data, connect with Microsoft BI, and much more. With the guidance of author James Beresford, HDInsight Succinctly will reveal a new avenue of data management.
You can also read my guest blog on Syncfusion’s site entitled “Being on the cutting edge is fun!” where I spend a bit of time extolling the virtues of HDInsight and Microsoft BI and getting all excited about analytics and its place in the future.
The eagle eyed among you may have noticed I’ve added a big countdown banner to the right of the page announcing a course “Build your Data Warehouse in SQL Server & SSIS with the BI Monkey“, running for 2 days from July 28.
The course is aimed at giving an overview of how to build and manage a Data Warehouse using the SQL Server platform as a base. It’s aimed to be a solid mix of Data Warehouse theory and hands on development to get the concepts locked in. For full details see my new “Training” page, but the key outcomes are:
- Learn how to get the Architecture right and keep your solution flexible
- Understand the whole lifecycle of a DW project
- Get hands on with the tools you need to move data
The high level agenda is:
- The Three Main Data Warehouse architectures – Kimball, Inmon & Data Vault
- SSIS Basics – Projects, Control Flows and Data Flows
- Moving Data with SSIS
- ETL Control Frameworks
- Database considerations
- How HDInsight (Hadoop) fits in
- Code Management with Team Foundation Server
- Build Automation
- MDS, DQS and other useful Microsoft Toys
Click the button to register now – look forward to seeing you!
I’m currently doing some Tabular Cube design, and part of the design has to include several “Y/N” flag fields. My inner geek then wondered what, if any, difference the data type made to the compression rates of the cube.
So, to start with I created a SQL Server table with three columns with the three usual types for this type of data
… and then populated it with a mix of Y/N’s for char and 1/0’s for tinyint and bit. I thought about 40 billion rows should do it, as that gave me about half a gig of on disk data.
Next I sucked it into a Tabular model, which gave me the following data types:
- char(1) -> Text
- tinyint -> Whole Number
- bit -> TRUE/FALSE
The results were:
- char(1) = 323,754 bytes
- tinyint = 304,256 bytes
- bit = 303,840 bytes
… and yes, that is bytes. Assuming that the data is stored evenly on disk that means that approx 180 million bytes were compressed to 300 thousand – a compression ratio of 600:1 – yoinks!
Anyway, the first pass of the results seem to show that char is mildly more inefficient that tinyint and bit. However, if you take it a level deeper, and just look at the Memory assigned to the In-Memory Table.Columns element, the most significant source of difference between the memory usage, you see this:
- char(1) = 17,944 bytes
- tinyint = 2,344 bytes
- bit = 2,344 bytes
So it appears that char(1) is much less efficient that tinyint or bit for storage, which end up being the same at this level of detail. For those of you who care deeply, you can view my results spreadsheet.
My conclusion? To be honest the amount of memory used by these columns is going to be pretty trivial unless you have a gigantic dataset, but if you have a flag field on your fact tables, I would choose to use bit in your database and TRUE/FALSE in your tabular model if you can.