Как мы переезжали из Tableau в Superset и почему из 130 дашбордов оставили только 36

Зачем переезжать вообще?

C 2022 года многие компании из РФ столкнулись с рисками и санкциями, из-за которых нужно было искать обходные локальные решения.

Такое случилось и у нас в Т. Cчастливые специалисты, работающие с Tableau встали перед выбором нового сурового биай инструмента. После исследований разных вариантов остановились на Superset.

Поэтому сегодня расскажу как мы переосмыслили 130 отчётов в Tableau (Табло) и перевезли только 36 из них в Superset (Суперсет).

Здесь будет не про технические детали и администрацию самого Суперсета.
Это взгляд со стороны аналитики:

1. Как мы за месяц продвинулись с нуля до экспертов в Суперсете.
2. Как решали, что перевозить, а что нет.
3. Как обучали всему продуктовых аналитиков.

Я понял, каким принципам следовать при переезде, чтобы было быстро, эффективно и полезно. Поэтому теперь делюсь этим с вами.

Переезд как переосмысление

У всего на свете есть разная сложность и глубина. У переездов и миграций тоже:

1. Lift & Shift — срочно скопировали всё что есть без изменений.
2. Рефакторинг — оптимизировали внутренние процессы, для пользователя всё как было.
3. Редизайн — оптимизировали внутри + снаружи, не изменяя суть (набор метрик, срезов).
4. Переосмысление — изменили метрики, подходы, технологии.

Роль BI до нашего прихода работала по-другому — это была аутсорс команда, которой можно заказать отчёт, а она его сделает. Причём делали фундаментально, поэтому долго.

Из-за этого большинство отчётов делали продуктовые аналитики на скорую руку, потому что времени всегда мало. Всё это привело к тому, что развитие отчётности было не системным, перекошенным и с пробелами.

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

Переезд для нас выглядел как:

1. Разберитесь в инструменте, с которым раньше не работали.
2. Погрузитесь в 4 разные бизнес-линии, которые включают в себя 14 разных сервисов, осознайте все процессы и поймите, что нужно отслеживать, а что нет.
3. Разработайте систему шаблонов и решений, которые дальше все будут переиспользовать.
4. Поддерживайте и разберитесь в старых решениях, чтобы не поломались процессы, пока всё переделываете.

Этап 1. Как разобраться в новом BI инструменте

На первый взгляд может показаться, что Superset и Tableau — две разные вселенные, причём первая гораздо менее функциональная и простая, чем вторая.

Если воспринимать их через внешнее, то да, так и получается. Но это дело очень неблагодарное, нужно за внешним видеть суть. Поэтому при знакомстве с любой системой надо подумать:

Какие задачи мне нужно решить?

Ответом на этот вопрос будет ряд задач или других вопросов. Штука на самом деле коварная. Не любой ответ приведёт вас в правильном направлении, так как можно не выйти на нужный уровень абстракции.

Поэтому написал ниже небольшую шпаргалку из трёх принципов. Она поможет сформулировать правильные вопросы и задачи:

Получается, что для полного погружения в любой BI инструмент достаточно знать ответ на следующие вопросы:

1. Как загрузить данные?
2. Как нарисовать график?
3. Как задать стиль графику?
4. Как расположить график на дашборд?
5. Как задать стиль дашборду?
6. Как настроить взаимодействие пользователя с дашбордом?

Для Superset ответ на эти вопросы оказался таким:

Получается, что в Суперсет можно сделать всё то же самое, что и в Табло.

Отличаются пути решения, и в случае Суперсета они могут быть чуть длиннее или менее дружелюбны. Но всему можно научиться, вопрос привычки. Мы научились всему этому примерно за месяц.

Этап 2. Как разобраться в новом бизнесе

Для того, чтобы понять, какие отчёты нужны бизнесу, а какие нет, нужно разобраться в бизнесе и его процессах. Недостаточно просто спросить у ключевых людей: а за чем вы смотрите.

Без понимания процессов и контекста вы становитесь просто руками, которые реализуют хотелки заказчиков. Это скучно и больно, потому что в этом не будет системы. Плюс влечёт к бесполезным задачам, результат которых никто не испольует. Поэтому погружаемся.

Несмотря на то, что у каждого бизнеса очень много своих особенностей, фундаментально они одинаковы и состоят из следующих функций:

1. Создание ценности. Всё, что касается продуктов/услуг для закрытия потребностей рынка (пользователей).
2. Маркетинг. Привлечение пользователей в созданный продукт
3. Продажи. Конвертация пользователей в клиентов
4. Доставка ценности. Предоставление обещанного, контроль того, что всё прошло хорошо.
5. Финансы. Как устроены денежные потоки, из чего состоят расходы и доходы бизнеса.

Поэтому при знакомстве с продуктом и общении с заказчиками мы погружаемся в каждый из этих этапов.

Как он работает? Почему так? Какие критерии успеха? Что на входе процесса, что на выходе?

Это позволяет превратить аналитика из роли исполнителя-рук в роль головы-партнёра, который может свою экспертность в аналитике связать с реальными процессами, и сделать это лучше заказчика.

В этом и карьерный рост, и качественные решения и пока что так мало кто делает. Поэтому пробуйте и удивитесь результатам.

Этап 3. Разработка шаблонных решений в Superset

Шаблоны нужны. Даже в ручном режиме (а я вот тут сделал, скопируй), это очень полезно.

Без единых стандартов весь визуал будет разъезжаться, а каждый придумывать что-то своё, в итоге увеличивая скорость разработки и когнитивную нагрузку
на пользователей.

Шаблоны мы используем на следующих этапах:

1. Настройка параметров на графиках и дашбордах.
2. Выбор визуализаций под типы задач.
3. Кастомизация визуализаций.
4. Сетка графиков на дашборде.

Приоткрою завесу тайны и покажу примеры шаблонов на каждом из этапов, чтобы вы могли забрать это себе.

Первое. Шаблоны параметров Jinja

Это 3 кита, на которых держатся все наши дашборды. Мы у себя используем ClickHouse для визуализации, поэтому синтаксис может быть специфичен для CH.

Плюс мы используем кастомные временные срезы (создавая виртуальный датасет со значениями), потому что так исторически сложилось и нам удобнее.

Изменение форматирования оси Х в зависимости от временного среза

• По неделям даты в формате: 2025 W12
• По дням даты в стандартном виде: 2025-06-18
• По кварталам: 2025 Q1
• По годам: 2025
• По месяцам: 2025.05

Стандартное форматирование мне кажется не самым удобным, поэтому такой костыль позволяет не выводить лишнюю пустую информацию на оси.

toString(
{% if filter_values('dimension')|first == 'Неделя' %}
formatDateTime(toMonday(period_end_dt), '%Y W%V')

{% elif filter_values('dimension')|first == 'День' %} 
toDate(period_end_dt)

{% elif filter_values('dimension')|first == 'Квартал' %} 
formatDateTime(toStartOfQuarter(period_end_dt), '%Y Q%Q')

{% elif filter_values('dimension')|first == 'Год' %} 
formatDateTime(toStartOfYear(period_end_dt), '%Y')

{% else %}
formatDateTime(toStartOfMonth(period_end_dt), '%Y.%c')
{% endif %})

Фильтрация дат по умолчанию

Я считаю, что нужно придерживаться следующей концепции в фильтрах и параметрах:

• фильтр — выбор пользователя, может не принимать значения, по умолчанию должен быть пустым
• параметр — способ конфигурации данных, не может быть пустым, по умолчанию должен быть выбран

Потому что это интуитивно понятнее.

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

{% if filter_values('business_dt')|first == 'No filter' or filter_values('period_end_dt')|first  == 'No filter' %}
  {% if filter_values('dimension')|first == 'День' %}
    business_dt >= yesterday() - interval 14 day 
    and business_dt <= yesterday()
  {% elif filter_values('dimension')|first == 'Неделя' %}
    toMonday(business_dt) >= toMonday(yesterday()) - interval 12 week
    and toMonday(business_dt) <= toMonday(yesterday())
  {% elif filter_values('dimension')|first == 'Квартал' %}
    toStartOfQuarter(business_dt) >= toStartOfQuarter(yesterday()) - interval 12 quarter
    and toStartOfQuarter(business_dt) <= toStartOfQuarter(yesterday())
  {% elif filter_values('dimension')|first == 'Год' %}
    toStartOfYear(business_dt) >= toStartOfYear(yesterday()) - interval 5 year
    and toStartOfYear(business_dt) <= toStartOfQuarter(yesterday())
  {% else %}
    toStartOfMonth(business_dt) >= toStartOfMonth(yesterday()) - interval 12 month
    and toStartOfMonth(business_dt) <= toStartOfMonth(yesterday())
  {% endif  %}
{% else %}
  1 
{% endif %}

Изменение группировки данных

Эта концепция используется для овервью отчётов и позволяет поддерживать высокую гибкость, при этом редко внося изменения в сам визуал дашборда, меняя только данные.

{% if filter_values('groupby')|first == 'Бизнес-линия' %} 
business_line_nm
{% elif filter_values('groupby')|first == 'Вертикаль' %} 
vertical_nm
{% else %}
'Общее'
{% endif %}

Второе. Выбор визуализаций

Подробно сейчас не будем это разбирать, потому что тема напрямую касается принципов разработки дата-продуктов и раскрою её в одной из следующих статей.

Если коротко, то наши любимые визуализации, это:

• Линейный график
• Таблица
• KPI
• Барчарт (для вспомогательных графиков)

Этого набора достаточно для 99% всех дашбордов.

Третье. Кастомизация визуализаций

Здесь мы стараемся следовать заветам Эдварда Тафти и минимизировать визуальный шум.

Графики динамики выглядят обычно так:

• Убрана ось Y и отступы

• Добавили подписи данным и маркеры к точкам

• Оставили на оси Х опору в виде линии, повернули значения на 90°

Четвёртое. Сетка графиков на дашборде

В одинаковых типах отчёта мы используем одинаковую сетку, чтобы это воспринималось как единый продукт и людям, работающим кросс-командно, было проще переключаться между дашбордами.

Строится она по одному из принципов макро-визуала, который я распишу в одной из следующих статей — от общего к частному.

Например, все Главные отчёты выглядят так:

Для сравнения, раньше два Главных отчёта выглядели так:

Этап 4. Переезд из Tableau в Superset

На самом деле, даже несмотря на всё вышеописанное, перелопатить 130 отчётов только руками трёх-четырёх биайщиков за 3-6 месяцев при таком подходе сложно.

Учитывая, что остаются на поддержке текущие процессы, параллельно разрабатываются новые инструменты и проводится общественная работа в виде кросс-ревью.

Поэтому единственный рабочий вариант в таком случае:

1. Выявить ключевую отчётность и процессы. Перенести это самим. Это сделали на этапе 2.
2. Помочь продуктовым аналитикам решить, что перевозить.
3. Научить аналитиков работать с новым инструментом, чтобы повысить скорость переноса.
4. Держать на контроле переезд.

Шаг 2. Помочь аналитику в выборе

В нашем случае это было довольно легко, так как были готовы инструменты, которые показывали статистику использования отчётов, а некоторые даже считали рейтинг важности отчёта в зависимости от рабочей иерархии заходящего. Условно, топ-менеджер, заходящий раз в месяц мог добавить больше важности, чем 3 линейных сотрудника, заходящие раз в неделю.

Если у вас есть возможность посмотреть посещаемость ваших отчётов, то следующие критерии хорошо покажут необходимость вашего дашборда:

1. Больше N просмотров за последние 2 месяца. Где N — около 10% аудитории биай инструмента.
2. Просмотры у дашборда есть в каждом месяце за последний год
3. Отчёт смотрят регулярно (каждый день \ неделю \ месяц \ квартал)
4. Отчёт смотрят люди, принимающие решения
5. Информация в дашборде уникальна, нет аналогов

Номер пункта — вес по важности. Если набралось больше 10 баллов, отчёт точно нужен и его перевозим.

Шаг 3. Помочь с освоением нового инструмента

Нашей задачей было провести аналитиков через принципы, которые мы разобрали на этапе 1.

Для этого мы регулярно выступали на демо, презентуя созданные отчёты, писали в аналитические каналы с новостями о том, что что-то появилось или обновилось. Это первый слой погружения — показываем на примерах, что происходит, чтобы было, что копировать.

Второй уровень погружения — через воркшопы показать принципы того, как устроен инструмент, чтобы можно было систематизировать практику.

На мой взгляд принципы, которые я там описал, до сих пор актуальны и на них можно опираться, чтобы понять, что и как связано и работает в Суперсете.

Шаг 4. Держать на контроле переезд

Каждую неделю мы публиковали статистику по перевезённым отчётам
на руководителей аналитики и аналитиков, чтобы те держали руку на пульсе и били в колокол, если что-то идёт не по плану.

Таким способом нам получилось добиться того, что команда аналитиков нефинансовых сервисов одна из первых в банке мигрировала из Табло в Суперсет.

Выводы

• Переезд — это не просто про "перелить" отчёты, а шанс пересобрать систему и сделать её лучше
• Не надо тащить всё подряд. Легаси всегда будет возникать, и лучше его оставлять с почестями
• В Superset тоже можно делать красиво и функционально, а главное полезно для бизнеса
• BI — это не про графики, а про партнёрство с бизнесом и помощь в осознавании процессов
• Готовьтесь, обучайте, документируйте

—————————————
Что думаете про переезд? Не перегрузил? Подписаны ли на Telegram?
https://t.me/think_visualize