...
Using Tableau is no different: In order to ensure we as developers are getting the best from Tableau, we really need to be asking "is this method the best way to achieve this" or "is Tableau the best tool for the job" or "do we actually need this" and finally "I'm sure we can demonstrate this more simply than that"
Top items to consider for best practice for all of your analyses and dashboards:
Table of Contents | ||||
---|---|---|---|---|
|
...
Data drives everything.
Including your reports, but data is not always optimised for the job in-hand, and is often unable to be, so really you should see data and data performance as the main drivers behind your reports, don't try and over-wrangle Tableau.
So this where the following guide steps in, and a little more information can be found on the following pages:
Child pages (Children Display) | ||||
---|---|---|---|---|
|
Finally, this is my list of items to consider for best practice for all of your analyses and dashboards:
Table of Contents | ||||
---|---|---|---|---|
|
- Try to keep your visuals as simple as possible
- Dashboards work best when there is less ink on the page
- Keep your dashboards to the point: avoid huge numbers of charts and a large scrollable page
- keep calculation names short and descriptive, replacing spaces for underscores
- Keep your work-space tidy by using folders wherever possible
...
Expand | ||
---|---|---|
| ||
... should exist in the source. |
Data drives everything.
Including your reports, but data is not always optimised for the job in-hand, and is often unable to be, so really you should see data and data performance as the main drivers behind your reports, don't try and over-wrangle Tableau.
So this where the following guide steps in, and a little more information can be found on the following pages:
...
Remembering the maxim: Less is More And expanding on point 1 above: Regardless as to the source, be it Excel or a flat-file, or a database table, calculations that operate on a row-by-row basis and these even include numerators and denominators of ratio calculations, can and therefore should be materialised in the source. If you are unable to modify the source table, this is the perfect time to use CustomSQL. By pre-materialising your base numbers at the source level, you are significantly increasing performance on the presentation layer (Tableau). Examples of such calculations include:
|
(8.) Understand Tableau's role
Expand | ||
---|---|---|
| ||
.. a presentation layer. All too often, Tableau is given Excel-centric nicknames "Excel on steroids" or "a more powerful Excel tool", and many of Tableau's user-base began there analytical lives with Excel or a similar spreadsheet tool, as such, most people therefore try to gain the same results from Tableau that they see with Excel, which often leads to terrible results further down the line. Tableau is NOT Excel and it does not behave like Excel either. The problem comes from the ease of use that Tableau provides, and users failing to understand the architecture of both tools. Only when explained that Tableau is nothing more than a presentation-layer with the bulk of the heavy-lifting taking place outside of Tableau, compared to Excel which does process every action, do users begin to see the bigger picture. This is discussed in greater detail in Tableau - is Not Excel: A High-Level Guide for the Excel User |
(9.) Limit your use of filters
Are you kidding? If I don't have filters, my charts and dashboards will become unusable! It was only a matter of time before these ended-up on your list - killjoy!
Expand | |||||||
---|---|---|---|---|---|---|---|
| |||||||
The ideal tool to slice and dice your data. They can be formed from dimensions, measures and calculations. They can use top n, bottom n, wildcard matching, type in and multi-select. Far more powerful (at least from a basic sense), than parameters, these filters really bring your visualisations to life. It's true, but these are amongst the biggest culprits for terrible data performance. Yet another one that fails to convey the impact to performance, you see, in order to build a quickfilter, Tableau needs to run a Select Distinct on the entirety of the column, it matters not whether the table contains a thousand rows, or one-hundred trillion, it still needs to perform this. Net result, as many users routinely plug Tableau into tens and one-hundreds of millions of rows of data, do you have any idea how much processing just one quickfilter takes to build. And then, the source-engine must start again for the next quickfilter. So if your table contains 10M rows and you have just five quickfilters, the data engine must run this query once for each filter, touching every record in the set:
So essentially, the data engine will have touched 50 million records from a 10 million record set. Now do you understand? There are however, two type of filter that don't touch any records:
I can offer two further solutions that will enable yo to go crazy with your filters: (1.) Either use a parameter to filter your initial set or (2.) Have your filters on just a single page (1.) The quote I put at the top of this page regarding needing to re-build the r&d report, well, part of the problem was that this was plugged into a 2 billion row set with around 8 quickfilters that needed to be generated causing huge slow-downs on what was already a 650ms network lag. However, the r&d entries were all Jira tickets, and frustratingly, users were only interested in a single ticket id each time they were using the report, with the average data size per ticket being around 3 million rows. Ok, so part of the back-end rebuild I mentioned was to partition the data by ticket id which hugely improved performance but, from the front-end, simply converting the connection to CustomSQL with a type-in parameter for the where-clause (this was eventually populated over a url-call) resolved the problem.
Therefore, by using CustomSQL and a parameter to reduce your set to that which is of interest from the outset, your quickfilters can be built against a much smaller set. (2.) The second alternative I can offer cam about from a pure accident: A second major drawback of the quickfilter is that if the same filter is placed on more than one dashboard or chart page but, enough time passes between initially building the filters on page/dashboard 1, where other actions have taken place enough to clear the cache for the filters, when moving to the alternate pages, the quickfilters must be re-generated with the same Select distinct query. I provided some consultancy to a company who just because they had 20 filters which took-up huge amounts of screen-space so, to save on space, we created a page of filters; it was awkward for the end-user to have to go back to the filters page when they wanted to adjust something, and I had to create an indicator to sit on every page to flag when and which filters were applied, but, the users were happy with it. Moreover, by moving the quickfilters to the one page, this meant that despite their number, they would only have to query the data just once per session, which allowed for an improved experience. |