Советы по улучшению перфоманса дашбордов в Tableau

Anastasiya Kuznetsova
6 min readFeb 23, 2022

--

Есть такой материал у Tableau “Designing Efficient Production Dashboards” от Ben Bausili и Mat Hughes про лучшие практики для создания эффективных дэшбордов. Интересно посмотреть все, но я повытаскивала около список того, на что обращать внимание, чтобы все нормально работало.

Это не заменяет performance recording, но мне всегда хотелось это как-то для себя структурировать (что делать и что не делать). Чтобы посмотреть, как Tableau вообще работает, супер советую видео Ромы БунинаПод капотом Tableau”.

А чтобы замерить перфоманс вашей книжки есть отличный тул от Виталия Ковалёва, который максимально близко покажет, сколько грузится ваша книга у людей.

https://tableau-speedtest.site/

Данные

  • Скорость дашборда зависит в том числе от скорости базы данных. Здесь нужно обращаться к инженерам баз данных и просить их проводить подробный анализ производительности и повышать ее (например, засчет индексов).
  • Если подключаетесь к базе данных, пользуйтесь специальными драйверами для нее. Драйверы типа ODBC, JDBC могут замедлять работу.
  • Экстракты часто работают лучше, чем живое (live) подключение. Лайв будет сильно зависеть опять же от базы. Плюс экстракты можно предагрегировать
  • При экстракте убирайте те данные, которыми вы не пользуетесь (фильтры прямо на экстракт и кнопочка Hide All Unused Fields). Вторую лучше нажимать только после создания всех визов.
  • Initial SQL быстрее, чем Custom SQL, особенно на лайве (но его сложнее поддерживать и обновляться он будет только при новой пользовательской сессии).
  • RLS (row level security) при неправильном оформлении тоже может замедлять книгу. Про Best Practices есть тут.
  • Встроенные в книгу экстракты быстрее, чем опубликованный источники с экстрактом.
  • Сложные калькуляции делайте на уровне базы данных и по возможности материализуйте их прямо в источник. В Tableau можно навертеть очень много калькуляшек, но и на скорость это тоже повлияет (в особенности калькуляции типа LOD)
  • Блендинг замедляет книгу, тк запрашивает данные из обоих источников данных на уровне связывающих полей перед объединением результатов в Tableau. Чем больше уникальных значений, тем дольше. блендинг лучше делать только по крупным полям (например, по категориями, а не по айди), а лучше вообще не делать.

Калькуляции

  • Материализуйте вычисления, сделанные в Tableau, записав их прямо в экстракт. Там есть кнопочка Extract > Compute Calculations Now. Тогда они впишутся сразу в файл экстракта, а не будут пересчитываться каждый раз при обращении к дашборду. Калькуляции, использующие параметры, не материализуются.
  • На лайве большую часть калькуляций тоже лучше вносить в источник, в том числе потому что не все функции Tableau будут работать.
  • Часто LOD медленнее Table Calculations, но вторые хорошо работают только на нормально сконструированных визуализациях. Лучше не использовать то или другое без необходимости (если можно решить задачу обычной калькуляцией) и по возможности реально лучше материализовать.
  • Уменьшайте гранулярность вычислений. Чем больше вы агрегируете за раз, тем лучше, но если у вас LOD с кучей категорий, то будет не быстро.
  • MIN и MAX быстрее, чем ATTR и AVG. Если вам нужно отобразить столбец, содержащий повторяющиеся значения и результат для всех 4х функций одинаковый, то возьмите MIN или MAX.
  • Создавайте группы с операторами CASE. Внутренний инструмент создания групп медленнее (для меня это вообще шоком было). Для создания групп лучше всего работают (в порядке от самых лучших к худшим)
    1. CASE
    2. Tableau Sets
    3. Встроенная функция группировки (правой кнопкой на пилюлю, Create > Group)
    4. Операторы IF / ELSEIF
  • Пользуйтесь IN вместо OR. С версий Tableau 2020.3 появился оператор IN, он работает быстрее, чем OR.
  • Встроенный функционал Alias быстрее, чем создание названий через калькуляции.
  • Уменьшайте количество вложенных калькуляций (когда одна калькуляция обращается к другой). Каждое такое вложение усложняет работу Tableau, особенно, когда много IF. Решение — снова материализация.
  • COUNTD работает медленно (так как нужен описк уникальных значений). Если можете, используйте COUNT.
  • Калькуляции с текстовыми типами данных и датами тоже медленные и их лучше материализовывать. С текстовыми переписывание калькуляций с функцией CONTAINS() будет работать быстрее, чем FIND() и если выделение категорий не нужно, нет смысла вписывать это все в IF, лучше оставить логическое поле. С датами лучше пользоваться DATEPARSE and MAKEDATE. Используйте TODAY() вместо NOW(), если нужна только дата без времени.
  • Текстовые значения (string), которые вы отдаете в результаты вычисления и параметров ничем не хуже числовых (integer) или логических (boolean). Делать специально параметр с integer, если вам удобнее string смысла нет (производительность одинаковая, иногда даже текстовые чуть быстрее).
from Designing Efficient Production Dashboards

Фильтры

  • Уменьшайте количество фильтров с типом Show only relevant values.
  • Добавляйте кнопку Apply (быстрее фильтровать не будет, но пользователю будет проще).
  • Избегайте фильтров со многими вариантами включения или исключения. Берите измерение более высокого уровня, например, страну вместо города.
  • Избегайте фильтрации по результатам агрегации.
  • Фильтры с датами лучше делать по непрерывной дате (зеленые пилюли, relative или range of dates). Range быстрее.
  • Range фильтры лучше, чем детализированные. Выбор диапазона значений (например, продажи больше 500 или цена от 10 до 20 долларов) — гораздо более простой запрос, чем список значений.
  • Через параметры тоже можно фильтровать, особенно между источниками и иногда это быстрее.
  • Фильтры, сделанные через LOD лучше поменять на Sets.
  • Контекстные фильтры не ускоряют работу книг (так было в старых версиях, но больше нет). Короче, добавление в контекст, увы, не ускорит книгу.
  • Зум не фильтрует, например, на карту иногда полезнее добавить фильтр по региону, вместо того, чтобы пользователь призумивал ее.
  • Самые быстрые типы фильтров:
    1. Custom Value List
    2. Wildcard Match
    3. Relative Date Filters
    4. Browse Period Date Filters
  • Самые долгие типы фильтров:
    1. Multiple Value List
    2. Single Value List
    3. Compact List
    4. Slider
  • При создании filter action не передавайте все поля, а выбирайте конкретные, которые передавать межу листами для фильтрации.
  • На filter action вариант “Exclude all values” тоже может помочь, если виз до экшна вам действительно не нужен. Плюс это понятная для пользователей история с детализацией и “проваливанием” на уровень глубже.

Листы

  • Визуализации лучше, чем текстовые таблицы. Tableau все же для датавиза и огромные текстовые таблицы могут замедлять работу.
  • Уменьшайте количество использованных marks (чем больше разных данных и категорий внутри, тем сложнее виз и дольше он будет рендериться). Например, в табличке каждая ячейка — mark. Количество использованных marks можно посмотреть снизу. Из прикольного — Density marks работают быстрее, чем обычные.
  • Пользуйтесь форматированием вместо создания дополнительных калькуляций. Например, для стрелочек KPI.
  • Уменьшайте размер изображений (для кастомных шейпов и изображений). Лучше держать их до 50kb и 32x32 пикселя.
  • Используйте PNG, а не JPG. Они занимают меньше места.
  • Полигоны медленны в отрисовке и если можно не делать, не делайте.
  • Pages не работают как фильтры и их так лучше и не использовать. Они не фильтруют данных, поэтому и работают сильно медленнее.
  • Если добавляете виз в тултип, этот виз должен быстро грузиться иначе смысла в нем нет. И как и с фильтрами, передавайте не все поля для фильтрации, а только нужные.

Дашборды

  • Используйте фиксированный разер дашбордов. Tableau так легче закэшировать результат.
  • Чем меньше визов на дашборде, тем он быстрее. Советуют не больше 5. Сложные можно разбивать на несколько дашбордов.
  • Уменьшайте количество фильтров, с которыми может взаимодействовать пользователь. Лучше 3–5.
  • Не добавляйте на дэш, то чем не будут пользоваться. Тут надо подробнее с пользователями говорить, конечно.
  • Скрывайте визы, если ими не пользуются постоянно. Сейчас у всех контейнеров появилась кнопка скрытия.
  • Удаляйте ненужные device layouts. Например, мобильная версия дашборда создается автоматичеки. Если она вам не нужна — убирайте.
  • При создании дэша могут появиться лишние контейнеры, их тоже лучше удалить. Про контейнерную верстку можно посмотреть это видео.
  • Уже на сервер публикуйте не все листы, а только дашборды (скрывайте их при использовании). Лишнее лучше не заливать.
from Designing Efficient Production Dashboards

Я честно хотела короткий чек-лист, но коротко не получилось…

--

--

Anastasiya Kuznetsova

Write about Data Visualization, BI and Tableau. Love sociology, space and urban analytics.