Вопрос, чем заменить Power BI, стал актуален для многих пользователей одной из самых популярных BI-платформ. С точки зрения синтаксиса DAX и удобства работы с моделью данных наиболее очевидной альтернативой является Visiology. Но у этой платформы до недавнего времени не было своего ETL-инструментария. Недавно вендор представил свой Self-Service ETL, и у меня возник логичный профессиональный интерес к его тестированию. В этой статье я делюсь своими исследованиями возможностей SS ETL от Visiology по сравнению с Power Query.
Меня зовут Антон Соломонов, и я работаю в сфере BI около 10 лет. Я – сертифицированный специалист по Power BI, и в прошлом мне приходилось реализовывать сложные проекты в сфере BI, опираясь на технологии MS Azure. В том числе речь шла про BigData-проекты, которые мы с различными командами делали в Mars, Ингосстрах и других организациях. Так что опыта работы с Power BI у меня более чем достаточно. Другими словами, я знаю как обо всех плюсах, так и о недостатках решений Microsoft в сфере BI.
Рассматривая новый ETL-редактор Visiology, я хотел в первую очередь оценить, насколько он удобен в работе по сравнению с Power BI. В этой статье я делюсь выводами из этого опыта, включая оценку удобства интерфейса и скорости работы в сопоставлению с Power Query.
Тест №1. Загрузка и формирование звезды
Начнем с простого задания: загрузим данные из файлов и построим модель данных типа Звезда.
Первые шаги: добавление источников данных
В ETL-редакторе Visiology доступно два способа добавления таблиц в модель данных:
Через "Данные -> Подключения" — в этом случае источник данных можно переиспользовать в других запросах. Фактически создаётся инструкция для подключения к источнику, но самих данных в модели ещё нет. Чтобы работать с ними, нужно создать запрос на основании этого источника.
Через "Преобразование данных -> Данные -> Новый источник данных" — в этом случае создаётся запрос сразу на основании выбранного источника данных, но его нельзя переиспользовать в других запросах (разве что создать заново).
На мой взгляд, недостатком второго подхода является визуальное сходство запроса и источника данных в модели. Они выглядят одинаково, и сразу понять разницу между ними непросто. В Power BI Service это реализовано более наглядно.
Вот пример того как выглядит отношение Источник_Данных->Датасет в power bi. Здесь наглядно видно, что является источником, а что датасетом
Вот как это выглядит в visiology. Внешне это абсолютно одинаковые таблицы. Понять сразу, что одно из них – это источник данные, а другое – это уже датасет созданные на основании этого источника нельзя.
Конечно, можно не создавать flow -диаграмму аналогично power bi – достаточно промаркировать источник и датасет различными цветами. Это уже сильно облегчит работу. Надеюсь, разработчики сделают это.
Тест №2. Работа с CSV файлами
Так как в моём тесте использовались CSV-файлы, которые я не планировал переиспользовать, я выбрал вариант создания таблиц через "Новый источник данных".
Что касается их загрузки, здесь никаких неожиданностей нет. Существует возможность указать в качестве разделителя различные знаки, в том числе пользовательские символы. Единственный недостаток – нельзя указать кодировку загружаемых данных.
Тест №3. Работа с Excel
Здесь обнаружилось одно из первых отличий от Power Query: Visiology не распознаёт структуру Excel-файлов. Нет выделенных таблиц, диапазонов — данные загружаются просто как лист. Вручную нужно указывать, в какой строке находятся заголовки и где начинаются данные. Это не критично, но Power Query делает этот процесс более удобным и гибким.
После загрузки в таблице Shipments у меня появился значок предупреждения. При наведении на него нет никаких объяснений - непонятно, о чём предупреждение. При открытии запроса в режиме редактирования тоже неясна причина предупреждения. Будем ждать исправления этой недоработки от разработчиков — ведь любому пользователю необходимо, чтобы было видно пояснение значка предупреждения.
Тест №4. Преобразование данных
Давайте посмотрим, как работают джоины. Попробуем обогатить таблицу Trucks данными из таблицы Truck_Category. При попытке создать объединение таблиц необходимо, чтобы все объединяемые таблицы были загружены в один запрос. Если таблица загружена в модель данных, сослаться на неё или использовать в джоине нельзя. Это непривычно.
Добавим таблицу Truck_Category в запрос Trucks и удалим её из модели данных, так как там она нам уже не нужна. Вот теперь объединение таблиц возможно.
Аналогичным образом поступим с таблицами Drivers и Driver_ratings.
В тестовой таблице фактов были дубликаты, и я решил удалить их по столбцу ID. Здесь выявился ещё один нюанс: удалить дубли можно только по одному столбцу, если же необходимо учитывать несколько колонок — придётся писать SQL-запрос.
Кроме того, нельзя переименовывать шаги преобразования в запросе, что усложняет навигацию, особенно в сложных сценариях.
Что же, когда все эти этапы были пройдены, в итоге у меня получилась модель данных, построенная по схеме "звезда".
Тест №5. Особенности использования SQL
Visiology использует SQL-диалект PostgreSQL. В моём тесте нужно было рассчитать срок доставки в днях, для чего я добавил новый столбец через SQL-запрос. Однако новые столбцы создаются в текстовом формате, и тип данных приходится менять вручную. Было бы удобнее, если бы система либо автоматически определяла тип, либо предлагала выбрать его при создании столбца.
Давайте выполним еще одно задание, которое продемострирует возможность использования PostgreSQL при обработке данных. Для этого создадим ещё одну модель данных, где преобразования будем делать с помощью кода PostgreSQL.
Задача: загрузить справочник, содержащий подразделения компании, и преобразовать его в иерархическую структуру.
Исходная таблица содержит поля:
ИД_Подразделение
Подразделение_Наименование
Подразделение_Родитель
Нужно выполнить иерархическое преобразование и создать таблицу со следующей структурой:
ИД_Подразделение
Канал продаж
Дивизион
Подразделение
Загружаем данные (в моём случае это CSV-файл) и в качестве преобразования выбираем "SQL_преобразование". Далее вводим SQL-запрос в диалекте PostgreSQL, который строит иерархию подразделений:
WITH RECURSIVE hierarchy AS (
SELECT
"ИД_Подразделение",
"Подразделение_Наименование",
"Подразделение_Родитель",
"Подразделение_Наименование" AS уровень_1,
NULL::VARCHAR AS уровень_2,
NULL::VARCHAR AS уровень_3
FROM
{Подразделения}
WHERE
"Подразделение_Родитель" IS NULL
UNION ALL
SELECT
child."ИД_Подразделение",
child."Подразделение_Наименование",
child."Подразделение_Родитель",
parent.уровень_1,
CASE
WHEN parent.уровень_2 IS NULL THEN child."Подразделение_Наименование"
ELSE parent.уровень_2
END AS уровень_2,
CASE
WHEN parent.уровень_2 IS NOT NULL THEN child."Подразделение_Наименование"
END AS уровень_3
FROM
{Подразделения} AS child
JOIN
hierarchy AS parent ON child."Подразделение_Родитель" = parent."ИД_Подразделение"
)
SELECT
«ИД_Подразделение»,
уровень_1 AS «Канал продаж»,
уровень_2 AS «Дивизион»,
уровень_3 AS «Подразделение»
FROM
hierarchy;
Как видим, данные успешно преобразовались в нужный формат. Загружаем запрос и смотрим результат в режиме "Просмотр данных" — всё отлично.
Выводы
Скорость загрузки данных в обоих Заданиях оказалась аналогичной Power BI, но нужно учесть, что тест проводился на небольших файлах. Было бы интересно проверить производительность на больших объёмах данных. Возможно, у меня получится сделать это немного позднее.
Если говорить про удобство работы, в целом интерфейс Self-Service ETL от Visiology оставил положительное впечатление: базовые преобразования доступны и логично организованы. Про моменты, которые хотелось бы улучшить, я уже сказал выше.
Положительное:
Интуитивно понятный интерфейс. За время тестирования я только раз обратился к документации, когда мне нужно было понять, как правильно записать формулу при создании нового столбца.
Если вы до этого работали с Power BI, то перейти на Visiology для вас не составит труда. Это действительно так.
Если разработчики Visiology продолжат активно развивать этот продукт, то он вполне может стать заменой для Power BI при определённой настойчивости.
Пожелания по развитию
Хотелось бы получить отображение кода каждого шага преобразования в строке формул, как в Power Query. Поскольку я чаще работаю с кодом на языке M, а визуальный интерфейс использую в качестве вспомогательного инструмента, отсутствие кода для меня непривычно.
Нужна возможность переключаться в расширенный редактор с полным кодом запроса. Поскольку Visiology использует PostgreSQL, можно, например, представить каждый шаг Запроса в виде Common Table Expression, вместо создания отдельного языка запросов (вроде M в Power BI). Это удобно, так как разработчику не нужно изучать новый язык — он может сразу работать с SQL, используя знакомый синтаксис. Тут у Visiology есть хороший потенциал для создания даже более удобного решения — нужно только приложить усилия в правильном направлении.
Полезно было бы добавить средства аналитики, показывающие план запросов и скорость их выполнения.
Очевидно, что инструменту нужно больше коннекторов. Но учитывая, что Self‑Service ETL появился относительно недавно, будем надеяться, что разработчики добавят их в ближайших релизах.
Ждем различные цвета для источников данных и созданных на их основе запросов. Это очень просто изменить, а без «раскраски» элементы выглядят одинаково, что затрудняет навигацию.
Подводя итог, я скажу, что новый ETL-редактор Visiology пока уступает Power BI в наполнении интерфейса, но уже выглядит перспективно. Если разработчики учтут пожелания, новый инструмент действительно может стать достойной альтернативой Power Query.
