Versions Compared

Old Version 15

changes.mady.by.user Steve Martin

Saved on

compared with

New Version 16

changes.mady.by.user Steve Martin

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...


Table of Contents
minLevel4
stylesquare

  1. Try to keep your visuals as simple as possible
  2. Dashboards work best when there is less ink on the page
  3. Keep your dashboards to the point: avoid huge numbers of charts and a large scrollable page
  4. keep calculation names short and descriptive, replacing spaces for underscores
  5. Keep your work-space tidy by using folders wherever possible

(1.) Only use calculations when you need them:

...

(4.) Use Tableau built-in functions (aliases, groups, sets, bins etc) wherever possible instead of calculations or make the changes in CustomSQL

But calculations are easier and aliases / groups / bins etc may be single-use
Expand
titleI can't argue with either of those points however...

... consider this calculation to alter the alias of Tenure Type : (running over a 30M row optimised set:

CalcTableau InterpretedResults in this plan


Code Block
Case [Tenure Type]
    When 'F' Then 'Freehold'
    When 'L' Then 'Leasehold'
    Else 'Unknown'
End



Code Block
SELECT (CASE [vw_Property_Sales].[Tenure_Type] WHEN 'F' THEN 'Freehold' WHEN 'L' THEN 'Leasehold' ELSE 'Unknown' END) AS [Calculation_1483936116037431300]
FROM [dbo].[vw_Property_Sales] [vw_Property_Sales]
WHERE ([vw_Property_Sales].[Tenure_Type] = 'F')
GROUP BY (CASE [vw_Property_Sales].[Tenure_Type] WHEN 'F' THEN 'Freehold' WHEN 'L' THEN 'Leasehold' ELSE 'Unknown' END)


Where aliases, being a Tableau object result in no execution time in order to generate the outputs, result is, far faster performance and zero impact to the underlying source.

This object:

is the generally the cause of over 9 in 10 bottle-necks, slowdowns and server impacts yet is also one of the most easiest you can control.

...

Expand
titleTableau is a presentation layer, a very powerful presentation layer, but still...

.. 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 A Tableau Overview for the Excel User

(9.) Limit your use of filters

...

Expand
titleAh, the humble quickfilter:

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:

Code Block
Select
Field_1 As Quickfilter_1
From YourTable

Group By Field_1

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: 

  • type-in allowing users to type their filter:
    • Although you must be very careful with this as this results in a full-text search to filter the records which can be very slow - imagine string matching a partial index to 10 million records.
  • The trusty parameter:
    • A static list that the developer must maintain, having this as a multi-select is just about the only thing that would truly make this but alas, being only single-select is a major turn-off for most users and for good reason too.

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.

Expand
titleHow this worked was...

.. Tableau will not attempt to render any item including quickfilters without data, trouble is, an empty parameter meant that no data was being served which means, the report had a chance to open and render (as nothing but headers/footers titles and parameters would still be drawn), and then, once the user enters their ticket id which filters the data from the outset down from 2 billion rows to 3 million rows, the quickfilters are then built using the same Select distinct only against a considerably smaller set.

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.

(10.) Keep your visuals clean and your dashboards focused

Expand
titleSounds simple doesn't it:

Unfortunately, development requests from another user can often cause this very important point to fall by the wayside.

Dashboards need to be as clean as possible - the maxim Less is More is absolutely necessary here.

Tools such as Excel and to a lessor degree, Powerpoint have enabled users to attempt to cram as much information as possible into the tiniest of spaces. Users have been brought-up on a diet of "All on one page". This is terrible, for a number of reasons:

  • First of all, this is far too much information for users to consume and keep track of
  • Dashboards quickly lose focus so end-up a mess of disorganised charts that hide or worse, lose them message
  • Imagine you have an odd data point that needs investigation, trying to trace this through multiple charts can often lead to losing the point or, by the time the user reaches chart 9, they are more likely to have forgotten the reason for the investigation
  • Finally and most importantly, much charts on a screen quickly leads to performance degradation:
    • At best, a chart may be made of two components: a dimension and a measure. These need to be executed as a query, and plotted taking at least 5 operations:
      • Tableau generates the initial query and send to the data-server
      • The data engine executes the query
      • Data is returned back to Tableau
      • Tableau reads the data and identifies which objects are to be plotted where
      • Tableau plots the data
    • Tableau must follow the above steps regardless as to the number of marks to plot and furthermore, need to do this for every chart so if you have 15 charts on a page, then this needs to happen 15 times, which is a huge amount of work
    • Worse (what could be worse than this?), as you build interactivity into your dashboard such as filters, parameters and action filters, each of these items generate a new query each time a change needs to be computed

Visuals (charts and tables) also need to be as clean as possible. The less ink on the page, the easier a chart is to read:

  • Use the most simplest design to get the message across: there's no denying a beautifully crafted info-chart can look like a work of art in its own right, however, such charts are designed to beautify data with a single message in mind such that they often lose out to more simplistic bars and line charts
  • Colour can allow you to add another dimension to your data
  • But keep your design clean and simple; the more data you cram onto your chart, the easier your audience will lose track of the message
  • Most importantly, the more data that has been crammed onto a chart, the more processing that needs to be done in order to build the chart, so only include that which is necessary for you to present the message.

(11.) Keep your work-space tidy

Expand
titleFour really easy points to help you keep your work-space tidy, which improves your development experience:
  1. Keep calculation and parameter names short, descriptive and where necessary, replace spaces with underscores:
    1. Default database behaviour is to surround all field names in square brackets, just in case there's a space in there. Sure, this isn't a problem, but when none of your fields contain spaces, you can do away withe the brackets in calculations, which improves readability (and helps with documentation too).

  2. Remember to add comments in your calculations: Single-line comments follow two forward-strokes eg:

    Code Block
    // This is a comment and will not be evaluated by Tableau
(Sum(Sales) - Sum(Profit)) // * Sum(Profit) - Everything after the double forward-stroke is still a comment so shall not be evaluated


  3. Annotations (object comments) are really useful in understanding the purpose of a calculation or object (like a field, dimension or parameter etc) without needing to open it. Annotations use rich-text so you are free to format as you want. To add an annotation simply:
    Image Added
    1. Add your comments and press OK to save them

  4. Folders. Folders allow you to organise your work-space, however, you will need to alter the view model in order to access them which in so doing, will remove data-model groupings, so fields that are grouped by table from a joined data-model, will now lose their groupings to be listed alphabetically. No matter, if you want to add this arrangement back, simply create folders to represent the tables instead.
    To switch to folders:
    1. Select the menu option and alter to Group by Folder
      Image Added
    2. You will now be able to:
      1. Create new folders
      2. Delete existing folders
      3. Select a group of dimensions (or measures or parameters etc) and choose either to create a new folder (and insert into the folder) or to add to an existing folder