How to improve the performance of your Tableau dashboards
March 26, 2014 2 Comments
So you’ve made Tableau part of your corporate BI stack; planned your Tableau architecture; strategized your deployment; and integrated Tableau into your data governance program. Congratulations! You’ve laid a strong foundation for Tableau success in your enterprise. But there’s still this nagging feeling that something is missing…
Oh, right—you still need help building dashboards!
Certainly, preparation and strategy are necessary and critical steps for sustainability and adoption of Tableau in the enterprise, but eventually, you’ll need to start building content to inform, enlighten, and enable smarter decision-making. The last thing you want is to disengage your users because their dashboards are too slow to effectively use. Here’s some tricks of the trade to quickly improve the performance of your dashboards—and the user experience to keep your audience engaged.
Tableau has committed a great deal of resources to making the Tableau Data Extract as light and fast as possible (anywhere from 4x to +10x compression). If you’re using Microsoft Excel as your data source, you should almost always go the route of fully extracting your data and letting Tableau optimize it (not to mention also enabling more calculations that you can run against data).
So when is connecting live going to be a better option for better performance? It’s largely a process of trial and error, but here are some go-to questions to answer before deciding on a live connection vs. a full or partial extract.
- Are you dealing with very large data sets (100M+ rows or 10+ GB)? Live connection may be the best way to address this data.
- Is your source data base an OLAP-specific data base (e.g., Teradata, IBM Netezza, or HP Vertica) or a Big Data source (e.g., Mongo DB, Google Big Query, or Amazon Redshift)? Live connections may best optimize the query capabilities built into the data base.
- Is your data sensitive (only able to be stored in the source system it currently lives in)? Live connections leave your data where it’s stored and only return the results needed for your dashboard.
- Does your SQL Server already have row-level security set up? If so, a live connection can submit user credentials to the data base, only retrieving the users’ rows with no additional configuration on the Tableau side.
If the questions above don’t apply, an extract is going to be your best bet. But again, trial and error will help you find the best solution for your specific situation.
When I start creating Tableau content, I don’t even worry about my data until I see issues with performance. I want as much data as I can get to start with, and then I make decisions as I get closer to the end of my development about how to improve my source data. Consider the following scenario
Here’s an example: A dashboard is being built for a national organization’s western region. That means the underlying data has information for the entire country, when only a subset of records are needed. In this case, “Extract Data Filtering” may be the best way to improve performance; this will filter the results before they’re pulled into Tableau and the resulting data set will only contain the information relevant to the dashboard being built.
Here’s a different example: the data is on an individual transaction level, providing far more detail than will ever be leveraged in the dashboard. In this scenario, build the dashboard first. Then when it’s ready to deploy, hide all the unused fields from the data source, then aggregate data for visible dimensions (both features are available by right-clicking the data source). Now the data will not contain transactional information, only the rows that are necessary to support the dashboard.
This option also works if you have a workbook containing separate high-level and detail-level dashboards. Here, bring the same data in twice as two different data sources. Build the high-level dashboard on one data source, and the detail dashboard on the other data source. Then, when ready to publish, aggregate just like before, and now each dashboard has a data set specifically catered to its needs.
I’m not going to say that you should only use floating instead of tiled worksheets when building your dashboard, but once you get used to the idea that more than just your legends can be floating (as I had to), you won’t want to go back to working with tiles. Not only do you have more flexibility with placement, sizing, and overall look and feel, but your dashboard will likely perform better, too!
Long story short, when you have a dashboard that is all tiled, Tableau has to recalculate the sizing relationship for every worksheet after each and every click. This was a painful realization for me for a dashboard I had built with about 10 worksheets all resizing one another; the processor spent too much time fitting the layout and turned users off from using the dashboard.
Converting that same dashboard to all floating worksheets let me set the exact size of each worksheet and its placement, and ultimately made the worksheet much more usable. Combined with hiding my unused fields and aggregating my data set to the ‘visible’ level, my dashboard went from the scrap heap to deployment.
Incorporating these tips will keep your dashboard performing its best, ultimately leading to beautiful, engaging, easy-to use experiences for your end users..That great user experience will keep people coming back to Tableau, enabling them to quickly glean deep insights without feeling frustrated along the way.
Need help improving your dashboard performance? Drop our Tableau experts a line.