Миграция с Tableau на опенсорс-версию DataLens: лёгкий путь с препятствиями

Хабр, привет! Я работаю в департаменте бизнес‑аналитики ППР — компании, которая создаёт экосистему сервисов для автопарка. Зимой 2024 года нам пришлось в короткий срок мигрировать на новый для нас BI‑сервис DataLens: подготовить инфраструктуру, развернуть три новых инструмента и мигрировать 100+ витрин и дашбордов.

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

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

Предыстория и выбор инструмента

Компания ППР в ежедневной работе использовала широко распространённое BI‑решение Tableau в облаке. Пользователи визуализировали и анализировали данные с помощью интерактивных дашбордов и отчетов, была настроена интеграция с различными источниками данных (о которых я расскажу чуть ниже). Этот инструмент помогал «держать руку на пульсе» ключевых показателей бизнеса на предсобранных дашбордах, а также периодически проводить исследовательскую ad‑hoc аналитику.

В декабре 2023 года у компании стали возникать трудности с дальнейшим использованием решения. Политика компании требовала использования on‑premise‑решения, но текущий инструмент этого не позволял. И уже в январе 2024 года мы были в активном поиске альтернатив среди опенсорс‑инструментов.

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

После анализ российского рынка коммерческого BI остались три претендента:

• Yandex DataLens

• Apache Superset (далее SS)

• Metabase

Metabase был исключен из гонки почти сразу из‑за ограниченности инструментария для визуализаций.

В финале остались DataLens и SS — именно эти два инструмента схлестнулись в безжалостной борьбе на двух тестовых стендах ⚔

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

По техническим критериям SS оказался впереди. По UX‑составляющей DataLens оказался более лёгким, интуитивным и приятным в использовании, Superset же показался тяжеловесным, с обилием функционала, которым мы в конечном итоге пользоваться не собирались. Устроив голосование среди аналитиков, мы подтвердили личные впечатления — коллеги оказались на стороне DataLens.

С коллегами из ИБ мы изучили возможность реализации на нашей стороне недостающих компонентов безопасности и поняли, что с технической точки зрения блокеров внедрения DataLens нет (хоть и внедрение будет более трудоёмким, чем SS). Затем спланировали миграцию. Вот что у нас получилось на диаграмме Ганта:

План был следующий: как можно быстрее создать MVP‑окружение, отдать аналитикам миграцию фронт‑части (дашбордов), в параллель с ними приступить к настройке продакшн‑окружения и сетапу репликации из аналитической БД.

У нас было полтора месяца, чтобы развернуть инфраструктуру, засетапить связку с DataLens и мигрировать на неё 100+ дашбордов. Взглянем на детали чуть внимательнее.

Инфраструктура и инженерия данных

Чтобы построить дашборд нужно собрать данные из источников, обработать их в соответствии с определённой бизнес‑логикой и сохранить получившиеся витрины данных в аналитическом хранилище. После этого данные можно визуализировать в BI‑инструменте.

Для реализации сбора, обработки и хранения мы используем СУБД Oracle, в которой консолидируются данные из множества источников как внутри, так и снаружи инфраструктуры ППР.

Поверх аналитической БД мы пользовались облачным Tableau + Bridge до инфраструктуры ППР, который обеспечивал соединение для обмена данными.

Казалось бы, всё просто — меняем один кубик на другой. Но:

1. Если выбирать on‑premise‑версию DataLens, она будет находиться внутри контура ППР — понадобится инфраструктура, серверы, их конфигурирование;

2. У DataLens отсутствует нативный коннектор к Oracle — понадобится промежуточная СУБД, которая будет хранить в себе витрины данных для последующей визуализации BI‑инструментом.

В качестве промежуточной СУБД для конечных витрин был выбран ClickHouse. Эта опенсорс‑колоночная СУБД заточена под обработку агрегирующих аналитических запросов, которые генерирует DataLens. И DataLens дружит с ней «из коробки»!

Данные из аналитического хранилища нужно переместить в ClickHouse. Здесь мы используем механизм ClickHouse external tables, реализующий jdbc подключение ClickHouse → Oracle, dbt для написания SQL‑трансформаций данных и cron для постановки трансформаций на расписание.

На момент публикации статьи все cron-запуски заменены на DAG Airflow

Что в итоге: витрина данных формируется в Oracle, по расписанию копируется в ClickHouse и далее визуализируется в DataLens.

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

На старте мы использовали существующие серверы для экспериментов департамента аналитики: ClickHouse и DataLens расположились на одном сервере, dbt на втором. В дальнейшем мы мигрировали на продакшн‑окружение, каждый инструмент стал жить на своём сервере.

Процесс переноса витрин и дашбордов был реализован так:

• Аналитики выбирают дашборды и витрины под ними, которые нужно перенести в DataLens;

• Аналитики самостоятельно создают копии витрин в песочнице ClickHouse, используя механизм external table для подключения к аналитическому хранилищу в Oracle;

• Аналитики создают визуализацию витрин в DataLens, в то время как команда инженерии ставит на расписание созданные аналитиками витрины, перемещая их в продакшн‑схему из песочницы;

• Как только витрина оказывается в продакшн‑окружении и начинает регулярно обновляться свежими данными, аналитик изменяет схему в датасете под дашбордом на боевую (в DataLens это удобно реализовано на уровне датасета), что обеспечивает бесшовный переход дашборда в продакшн.

Несколько итогов такой миграции с технической точки зрения.

Минусы:

• Усложнение схемы поставки данных до BI‑инструмента, добавилось одно звено копирования данных из аналитического хранилища в ClickHouse;

• Увеличились затраты на собственную инфраструктуру, поддержка работоспособности новых инструментов ложится на команду инженерии данных, в облачном решении было «заплатил и забыл».

Плюсы:

• Уменьшилась задержка при работе с BI‑инструментом — локальная установка всех компонентов ускоряет взаимодействие;

• ClickHouse оптимальным образом обрабатывает агрегирующие SQL‑запросы, связка ClickHouse + DataLens выигрывает у Oracle + Tableau в отклике и в скорости обработки визуализаций — теперь высокие витрины с десятками‑сотнями миллионов записей перестали быть проблемой;

• Наши данные внутри нашей инфраструктуры;

• Используем опенсорс — экономия на лицензии перекрывает затраты на инфраструктуру и поддержку.

ACL и SSO

В момент миграции DataLens ещё не успел обзавестись собственной поддержкой SSO и ACL, поэтому мы реализовали их самостоятельно.

На момент подготовки статьи в DataLens уже была реализована поддержка через Zitadel.

Внутри инфраструктуры ППР мы используем Keycloak — платформу для управления доступом и аутентификацией пользователей. Она предоставляет функции единого входа (SSO), управления пользователями и ролями. Мы подружили DataLens с Keycloak, подняв два дополнительных контейнера — Oauth2 proxy и Nginx. Nginx выступает как обратный прокси, он управляет аутентификацией пользователей на основе учетных записей через Keycloak, используя Oauth2. Аутентификация происходит при помощи существующих учётных записей Active Directory, доступы УЗ к DataLens создаются и управляются через Keycloak.

Доступ пользователей к дашбордам реализован на уровне коллекций. Были реализованы три роли: «аналитик», «пользователь» и «аналитик своей коллекции». «Аналитик» может использовать, редактировать и создавать объекты во всех коллекциях, «пользователь» имеет доступ на просмотр уже существующих дашбордов в коллекциях, к которым согласован и выдан доступ, и не имеет прав на редактирование существующих и создание новых объектов. «Аналитик своей коллекции» может использовать, редактировать и создавать объекты в коллекциях, к которым согласован и выдан доступ.

В целом нам пока хватает существующих возможностей, в планах реализация ролей доступа на уровне воркбуков и дашбордов.

Итог

В короткий срок нам удалось мигрировать на новый BI‑инструмент, не потеряв в качестве визуализаций и информативности дашбордов. Получилось в намеченный срок перенести все запланированные к миграции дашборды в DataLens. Мы гибко подошли к выбору новых инструментов в условиях существующих ограничений. Не все дашборды были перенесены, но миграция позволила критично оценить их бизнес‑ценность. Несмотря на отсутствие некоторых важных для нас вещей (файловые подключения, статистика использования дашбордов, row level security), DataLens оказался качественным надежным инструментом, выполняющим свои бизнес‑функции.

О проекте миграции мы также рассказали в рамках Yandex DataLens Festival 2024 — к фестивалю можно присоединиться в Telegram и посмотреть наше видео о проекте.

Смотреть через Yandex Cloud Video

Визуализации

Для дочитавших до конца бонус — некоторые визуализации, созданные нами в DataLens