FineBI 6.0: Укрощение строптивого

Всем привет! Меня зовут Илья Лавриков, являюсь старшим аналитиком в «Альфа-Лизинге» и по совместительству активно участвую в жизни сообщества #FineBI компании GlowByte. Занимаюсь разработкой и поддержкой BI-отчетов по различным потребностям бизнеса. К лету 2022 года я создал более 30 отчетов «Альфа-Лизинга» в MS Power BI. Тем же летом в компании было принято решение провести миграцию отчетов и уйти с Power BI. Но куда? Я провел исследование рынка BI-систем, и после взвешивания всех за и против наш выбор пал на китайского «дракона» FineBI. В конце января 2023 года я стартовал миграцию отчетов.

Старт миграции пришелся на FineBI версии 5.1, но уже тогда я знал о скором выходе версии 6.0 и с нетерпением ждал ее. В «пятерке» возникли определенные сложности: новая система, другие подходы к консолидации данных для отчетов и верстке самих дашбордов. Нужно было уходить от привычных моделей, учиться создавать дашборды в условиях, когда 1 визуализация = 1 датасет. К тому же все вычисления ранее проводились с помощью мощного DAX. Для меня, как аналитика, работавшего в экосистеме MS и не знающего Tableau, было непривычно. Несмотря на сложности, я относительно быстро освоился в 5.1.

Прогресс нашей миграции был осуществлен приблизительно на 25%, когда вышел релиз FineBI 6.0. И тогда я принял решение проводить обновление среды разработки до «шестерки» по следующим причинам:

• Проводить миграцию отчетов сразу в 6.0 практичнее, чем в 5.1: таким образом исключается адаптация бОльшей части всех дашбордов от версии к версии.
• В «шестерке» вендор реализовал много необходимых фишек (DEF-функции, расширенный ETL, возможность строить визуализации по связанным друг с другом таблицам и многое другое). Особенно важно последнее нововведение, т. к. это упрощает подготовку данных и мы избегаем излишней денормализации датасетов.
• Возможность протестировать новую версию, т. к. пользователей обновление никак не затронет, ведь миграция отчетов находится на начальном этапе.

Итак, с коллегами из ИТ мы поставили новую версию. Привыкнув к интерфейсу, логике создания Self-service Dataset (SSDS) и дашбордов в 5.1, сперва было непонятно: что, куда, зачем и почему вообще так сделали. Что это за фрукт, ваш 6.0, и с чем его едят? Потребовалось время на изучение документации, «тыканье» в кнопки и осознание того, что как раньше не будет, нужно изучать FineBI не с нуля, но по новой. Это вроде тот же продукт, только улучшенный, но в то же время совсем другой инструмент. Но вместо того чтобы полноценно изучать новые возможности «Файна», я начал видеть баги новой версии. И далее я расскажу о них подробнее.

Первое, с чем я столкнулся в версии 6.0.5, это проблемы с интерфейсом. Решил я собирать все баги и отправлять их вендору. Тут большое спасибо GlowByte за посредничество, т. к. на тот момент у меня не было каналов связи с вендором.

На скриншоте показан фильтр-компонент с выбором интервала, но какой — вопрос, т. к. значения не видны из-за наименования полей. Раньше вместо «Year» и «Month» были «Y» и «M». В 6.0.7 этот баг поправили.

А здесь отрывок из настройки Tab component (такой инструмент для создания вкладок в дашборде). Выбрать шрифт вместо Arial еще можно, а вот изменить его размер — увы. В 6.0.7 этот баг поправили.

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

Следующей проблемой, с которой я столкнулся, стала неработающая вкладка плагин-маркета. Шла бесконечная загрузка, в коде браузера указывалась ошибка 404. В этой ситуации вендор пришел на помощь, указав что именно нужно изменить в настройках на сервере: просто активировать в plugin.xml.

Дальше мои руки добрались до обещанных улучшений в ETL-инструменте. И каково было мое удивление не увидеть части функций, которые демонстрировались на Fine Day коллегами из GlowByte. Дело в том, что если вы с нуля устанавливаете FineBI, то у вас будет последняя версия, а если проводите обновление с 5.1 до 6.0, то ставится 6.0.5, и далее нужно накатывать еще обновления. Для того чтобы убрать вышеперечисленные недочеты и получить те самые недостающие фичи, нужно обновиться до 6.0.7. Получив JAR-файлы, мы легко провели обновление, и действительно, все неточности с отображением интерфейса в английской версии ушли. После этого я смог полноценно оценить ETL-инструмент, опробовать построение связей между датасетами и на их основе приступить к созданию визуализаций. Но появилась другая серьезная проблема…

В FineBI есть классная возможность передавать значение из фильтра (будь он создан на основе полей из SSDS или с кастомными значениями) в расчеты. В шестой версии эта возможность стала параметром. Представьте кейс: вы открываете дашборд по продажам и визуализации показывают вам количество проданного товара по категориям. И есть два виджета: в одном вы можете снять выбор с «Количество» и указать «Прибыль», а в другом — снять с «Категории» и указать «Менеджер». Тогда визы перестроятся и будут показывать прибыль по менеджерам. Динамично? Красиво? Удобно? А вот в 6.0.7 это перестает быть таким элегантным решением. После выбора того или иного параметра он не применяется автоматически в расчетных полях ни в одном созданном мною дашборде. Иногда компоненты ломаются, и пропадает отображение всех данных. Для меня это катастрофа, ведь больше половины созданных дашбордов используют параметры.

Что делать? Откатываться назад? До 6.0.5, где работают параметры, но проблемы с интерфейсом? Или до 5.1, где возможностей в разы меньше? Принял решение идти до конца: составлять подробный кейс и просить коллег из GlowByte обратить внимание вендора на эту проблему. Так я и поступил: наделал много скриншотов с описанием шагов по созданию параметров и того, как они НЕ влияют на компоненты автоматически, а только после ручного обновления дашборда. Затем оформил и отправил. Спустя несколько дней мы получили в какой-то мере радостные вести. Вендор признал это багом и пообещал исправление в следующей версии.

Прошла неделя, и вендор присылает нам JAR-файлы новой версии 6.0.9. Мы пробуем обновиться и получаем недоступный сервер…

Конечно, мы думаем, что свежеупакованная версия — с проблемами, ведь мы смогли ранее до 6.0.7 обновиться. Сообщаем об этом вендору. Пока ждем ответ, пробуем поставить версию 6.0.8, зная об успешных обновлениях до этой версии от коллег из сообщества в Telegram. Получаем аналогичную ошибку: сервер недоступен. Совместно с техническими специалистами GlowByte, обратившись к вендору, мы нашли корень проблемы. Причиной оказалось отсутствие установленного пакета fontconfig. Почему он отсутствовал — вопрос, который останется без ответа. К сожалению, и сам вендор не предупреждал в инструкциях по обновлению о необходимости наличия данного пакета. Ставим пакет — успех! Ставим 6.0.8 — успех! Ставим 6.0.9 — УСПЕХ! Все как по маслу, и, ради чего это все затевалось, параметры работают автоматически!

По ходу пьесы я еще опробовал плагины форматов дат и чисел, которые вендор выпустил изначально под версию 5.1. Суть плагина заключается в том, что можно изменить в визуализациях формат даты (с ГГГГ-ММ-ДД на ДД.ММ.ГГГГ) и разделитель разрядов в числе (с 100,000.00 на 100 000,00). Сперва было утверждение, что плагины заработают и в шестой версии, однако числа не везде отображались как надо: в таблицах все было в привычном нам формате, а вот в визуализациях нет.

Тут так же спасибо GlowByte: увидев мое недоумение в чатике сообщества, они передали это вендору, и через какое-то время мы получили новую версию плагина для формата чисел, где все отображается корректно. Кроме одного случая: когда число выглядит как ноль целых со знаками после запятой (0,***). В таких ситуациях 0 не отображается. Проблема решается «отжатием» галочки разделителя разрядов в настройках формата. Но это влияет на все значения в индикаторе, и когда наравне с такими числами в одном поле присутствуют сотни тысяч, миллионы и т. д., то пропадает и полезное свойство этого плагина. На сегодня этот момент все еще требует доработки со стороны вендора.

Хочу отметить еще один момент в шестой версии. Он не относится к багам, но мне категорически не нравится. В 6.0 нам представлена концепция, когда компонент существует независимо от дашборда, и это несет в себе определенные неудобства. На этапе настройки компонента мы не видим, как на него влияют внешние фильтры, параметры и дизайн самого дашборда. Он живет своей жизнью, но когда мы его размещаем на дашборде, то он подстраивается под окружающую среду. Давайте я покажу на примерах.

На скриншоте выше мы видим график в редакторе компонентов. Он отображает данные по всему датасету: за все года по всем категориям. Несмотря на то, что на дашборде, где используется этот компонент, применены различные фильтры. С этим еще можно жить, терпимо, но дальше становится «веселее».

Нет взаимосвязи цветовой палитры в настройках Color со стилем дашборда, и вот тут начинаются сложности. Когда в компании принят единый корпоративный стиль, то и дашборды должны соответствовать брендбуку. И если мы можем настроить стиль дашборда с необходимыми нам цветами, то цвета в самом компоненте свои, зафиксированные, никак не синхронизированные со стилем дашборда. Даже если нет единого корпоративного стиля, но есть цвета, которые вы считаете наиболее удачными и чаще их используете, — держите их html-коды под рукой. На мой взгляд, нужно добавить возможность настройки стиля в самом компоненте, тогда и цвета будут доступны, и не придется все время их вбивать вручную.

Двигаемся дальше, видите чарт?

И я не вижу, а он есть! На скриншоте компонент, в индикаторе которого применяется параметр. А его значения выбираются где? Правильно, на самом дашборде. В таком случае настройка компонента производится вслепую, и нужно переключаться на даш, смотреть, как выглядит компонент, и возвращаться обратно в редактор. А теперь объедините предыдущий пример с этим. Когда в измерении участвует параметр (пользователь выбирает срез: категория марки автомобиля или тип кузова), то нет возможности назначить те цвета, которые нужны. Есть обходное решение, костыльное, но оно есть: поочередно указывать в вычисляемом поле измерения, которые будут использоваться (сначала категорию марки, затем тип кузова), накидывать на значения цвета и после, сложив пальцы крестиком, прописывать полную меру и надеяться, что ничего не собьется. Через мои руки прошло несколько таких дашбордов. Реализация кропотливая и никак не тянет на self-service.

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

По многочисленным просьбам клиентов вендор реализовал возможность использования одного и того же рассчитанного индикатора в разных компонентах. Напомню, что в FineBI 5.1 при создании компонента мы каждый раз проходили рутинное создание одних и тех же мер (если не копировать сам компонент). Считаете вы сумму продаж в карточке KPI, затем добавляете график, а созданного ранее индикатора нет. Ctrl+C и Ctrl+V всей написанной функции, а если она короткая (простая сумма по полю), то быстренько набрать руками. В FineBI 6.0 представлена некая модель отчета, и при создании вычислительных мер они будут доступны в новых компонентах. Конечно, это невероятно удобно. Отсюда следует, что наименования у индикаторов должны быть уникальными. И тут вылезает новый казус, который ждет, притаившись, когда же вы обновитесь и получите в модели «Сумма продаж», «Сумма Продаж», «Сумма продаж — 1», «Сумма продаж — 2» и т. д. А все вот почему. Посмотрите на два индикатора и найдите отличия:

Наименования у индикаторов разные. «Файн» на данный момент чувствителен к регистру. Поэтому если вы не хотите получить две разные меры в отчете, затем проводить замену одной на другую в компонентах и других мерах, где они участвуют, то сделайте одинаковые наименования во всех компонентах дашборда. Сами индикаторы должны быть одинаковыми полностью, с точностью до пробелов. На примерах выше можно увидеть, что если False, то в одном случае стоит null, а в другом 0. Получается, что функции разные, хоть и покажут в большинстве случаев одно и то же.

Ну хорошо, тут понятно, они отличаются. А что насчет пробелов и пустых строк? Если две меры отличаются хоть на ОДИН пробел и только — это две разные меры. И если они будут носить одинаковые наименования, то после обновления на шестую версию мы получим «Сумма продаж» и «Сумма продаж — 1». Работать все будет, не переживайте. Ну, в 99% случаев будет. Огромных мучений будет стоить привести все в порядок, чтобы вести поддержку созданных отчетов. Не повторяйте ошибок первопроходцев, посмотрите на скриншоты ниже…

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

В своих разработках способ подключения Direct я не использовал и описанный ниже кейс услышал от коллег по цеху. В шестую версию нам добавляют LOD-функции для вычислений в режиме импорта (ура!). Это функции DEF (), DEF_ADD (), DEF_SUB (). Они же работают и в Direct. Только вопрос: а что со старыми FIXED (), INCLUDE (), EXCLUDE ()? Они превращаются в тыкву. FineBI 6.0 не знает, что это такое, и воспринимает как текст. Да еще и синтаксис у них отличается, изменен порядок аргументов. Так что, если у вас дашборды в 5.1 используют индикаторы с этими функциями, готовьтесь кропотливо все менять… На момент написания этой статьи автоматической замены не создано. Советую этот момент уточнять у вендора, чтобы иметь актуальное представление.

Подводя итоги, не могу не упомянуть, что мысли об откате на пятую версию были. И много раз. Но, кроме этого, была еще и уверенность в том, что такие серьезные ошибки вендор не оставит без внимания. С какими-то особенностями научился справляться. Сразу начал использовать новые возможности 6.0. И они крутые! FineBI уверенно двигается к тому, чтобы называться полноценным продуктом BI-аналитики. Обратная связь от вендора заставляет верить в их успех и не позволяет чувствовать себя брошенным на произвол судьбы. Что касается конкретно нашего проекта, то запас времени до боевого релиза платформы позволял нам дальше продолжать миграцию отчетов. Совсем недавно мы решили нашу последнюю проблему и теперь проводим опытно-промышленную эксплуатацию, а до завершения миграции с Power BI осталось около 7 отчетов.

Мой положительный ответ: определенно стоит обновляться до шестой версии. Учитывайте опыт первопроходцев, обращайтесь к вендору с вопросами и предложениями, верьте в успех вашего дела!

Обновить, нельзя оставить! Благодарю за внимание :)