ПИКантная миграция: путь от Tableau к FineBI

Введение

Меня зовут Усов Сергей. Я администратор системы FineBI в компании «ПИК Диджитал», которая предоставляет сервис сквозной аналитики для большого количества подразделений нашей группы компаний из более чем 4000 ИНН. По совместительству отвечаю за разработку и сопровождение ETL для бизнес-процессов компании на СУБД SQL Server, Postgres, мониторинг доступности ресурсов, а также работу системы оркестрации Airflow. Являюсь активным участником сообщества FineBI GlowByte.

До начала администрирования FineBI я уже имел хороший опыт работы в области анализа данных, проектирования прикладных структур и автоматизации процессов. Среди знаний и навыков можно отметить PowerShell, Bash, VBS, Python, Airflow, SQL-аналитику и разработку, построение BI-решений, реверс-инжиниринг, разработку ПО, а также опыт мониторинга работы различных технических систем. Всё это мне пригодилось в итоге при сопровождении системы FineBI.

Часть 1. Переход на Fine BI

FineBI была выбрана компанией ПИК в ноябре 2022 года основной системой сквозной аналитики вместо ушедшей с российского рынка системы Tableau благодаря нашему ИТ-партнеру — интегратору GlowByte. На выбор платформы во многом повлияла известная степень схожести функционала. Хочется сразу отметить, что FineBI стремительно эволюционирует и сейчас является гораздо более стройной и надёжной системой, чем в момент своего появления в нашей компании.

На тот момент в FineBI работало порядка 50 разработчиков и более 800 пользователей. При этом более 40% пользователей составляли руководители всех звеньев.

В течение всего 2023 года продолжался переход с системы Tableau на FineBI всеми командами разработки при участии аналитиков GlowByte. На первом этапе к миграции было заявлено свыше 800 дашбордов. Это была сложная многоэтапная работа для всех команд разработки и сопровождения инфраструктуры.

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

Показатели на конец декабря 2024 по FineBI:

1. Свыше 1100 пользователей.
2. Порядка 60 разработчиков.
3. Свыше 1500 дашбордов.
4. Более 5000 датасетов, из которых свыше 290 — в режиме прямого подключения к источникам.
5. 160 различных подключений к источникам.
6. Шесть типов СУБД (SQL Server, Postgresql, MySQL, Clickhouse, Greenplum, HP Vertica).
7. Более 6500 запланированных обновлений на каталоги и датасеты, в том числе в формате cron.
8. Максимальное количество одновременно работающих пользователей — свыше 250.
9. Среднее число визитов в систему в день составляет ~1900.
10. Активных пользователей в течение месяца — свыше 500.

В 2022 году первая конфигурация сервера FineBI имела следующий вид:

1. только PROD-контур без тестовой среды,
2. версия 5.1.29,
3. режим моностенда,
4. Windows-платформа,
5. без использования Tomcat,
6. использование внешней БД на MySQL.

В период эксплуатации данной реализации команда неоднократно сталкивалась с двумя проблемами:

• «прожорливости» системы к ресурсу ЦП (для системы неоднократно увеличивалось количество виртуальных ЦП начиная с 20 и заканчивая 50),
• зависанием ПО в Windows при длительной работе без перезагрузок в режиме логирования INFO.

Первая проблема решалась строгим контролем плана расписания обновлений. Это затрагивало как получение данных, так и расчёт показателей BI непосредственно в FineBI. Для её решения мы неоднократно использовали не только встроенные средства мониторинга, но и привлекали к анализу представителей вендора на основе логов системы, а также дампов процессов Java (например, jstack). Мы осуществляли многократное ручное управление зависшими обновлениями, а также неприлично большими и сложными загрузками. Хочется отметить быструю скорость реакции на устранение деградации сервиса нашим ИТ-партнером GlowByte, а также компанией-разработчиком продукта FanRuan.

Вторая проблема предположительно могла быть решена при использовании Tomcat вместо режима standalone. Но здесь были проблемы, связанные с некорректной установкой JVM, что влияло на возможность корректной настройки Tomcat. Возможности снятия с эксплуатации единственной PROD-среды более чем на два часа мы не располагали. В то время как перенастройка ВМ могла занять даже больше времени, чем запланировано.

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

Почему не решали проблему с переносом приложения на Tomcat? Мы практически уже подготовили всё для перехода на FineBI более новой, шестой версии для Linux-платформы. Поэтому не стали проводить данных работ по перенастройке с длительной остановкой сервиса.

Вторая реализация сервера стала более совершенной:

1. отдельные контуры PROD и TEST,
2. для PROD-контура — кластерная отказоустойчивая реализация на 7 ВМ,
3. для TEST-контура — моностенд на 3 ВМ,
4. версия 6.0.16,
5. Linux-платформа,
6. с использованием Tomcat,
7. использование внешней БД Postgres для размещения FineDB.

Что изменилось:

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

Ниже приведена текущая структурная схема PROD-контура:

В августе 2024 года мы обновились без каких-либо проблем до версии 6.0.19.
По опыту эксплуатации данной реализации с февраля 2024 можно сказать, что 6.0.19 на Linux ведёт себя в разы стабильней прошлой версии на Windows.

Какие выводы мы сделали для себя и рекомендуем другим?

1. Ставьте PROD-решения FineBI на Linux.
2. Устанавливайте Tomcat из tar-архива, а не репозитория.
3. Настройте мониторинг доступности узлов системы.

Часть 2. Мониторинг работы системы

Цель — работа 24 на 7

Одной из важнейших задач сопровождения корпоративного сервиса является достижение максимально возможного значения доступности системы. В идеале это 24/7. Фактически это время уменьшается технологическими перерывами, которые могут быть плановыми и внеплановыми.

Пример плановых перерывов:

1. перезагрузка после обновления настроек системы,
2. при выполнении запланированных работ с ОС,
3. при выполнении запланированных работ по настройке ПО FineBI.

Внеплановые перерывы являются крайне нежелательными для PROD-среды и сказываются напрямую на качестве предоставляемого сервиса.

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

Из вариантов мониторинга существуют встроенный мониторинг и алертинг в FineBI либо реализация через внешние сервисы и интеграции.

Встроенные блоки мониторинга работы системы FineBI

Существует ряд встроенных средств мониторинга о состоянии системы. Перечислим часть из них.

UPDATE TASK MANAGEMENT (ИЗ PUBLIC DATA)
Мониторинг завершённых с ошибкой задач с учётом общего процента ошибок. Накладываем условия: завершенные с ошибкой и временной интервал.

Далее задаём сортировку по полю Historical Failure Rate для отбора проблемных датасетов и формируем список датасетов на доработку или удаление. Передаём их разработчикам.

LOAD SURVEILLANCE (ИЗ LOAD MANAGEMENT)
В данном разделе контролируем загрузку ЦП и потребление ОЗУ на интервале последние 30 минут. Настраиваем оповещение о проблемах в этом же блоке на почту.

MEMORY SESSION (ИЗ LOAD MANAGEMENT)
Смотрим количество сессий пользователей и потребление ими ресурсов внутри памяти JAVA engine. Проверяем достижение лимита памяти.

HEALTH INSPECTION (ИЗ INTELLIGENT o&m)
Проверяем встроенным функционалом правильность установки параметров системы и возможности оптимизации. При необходимости применяем рекомендации путём внесения правок в настройки.

Здесь также имеется возможность формирования файловых отчётов с HTML-вёрсткой.

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

Внешние сервисы
Для мониторинга мы используем:

1. Zabbix,
2. Grafana,
3. Airflow + Python,
4. FineOps.

Zabbix «из коробки» поможет мониторить такие параметры платформы для ПО, как утилизация ЦП, использование оперативной памяти и дискового пространства, а также мониторинг URL-точек входа в сервис. Алертинг для событий по email и в Telegram также имеется.
Grafana также может использовать данные БД, собираемые другими агентами мониторинга, для формирования дашбордов и метрик. Позволяет сводить на одном графике разнородные параметры разных систем, что является большим плюсом по мониторингу. Имеет гибкие возможности по настройке оповещений на основе триггеров, в том числе по email и телеграмм.

FineOps — это отличное решение по мониторингу, позволяющее мониторить не только параметры ВМ, где развернут сервис, но и погружаться в онлайн-режиме в мониторинг процессов JVM. Позволяет даже просматривать файлы дампа процессов jstack, что является большим плюсом. Простой в своей настройке и подключению к ПО FineBI 6 версии.

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

Правильный подход

Что выбрать для мониторинга? Проще — встроенное. Сложнее — внешнее. Правильнее будет совмещение инструментариев встроенного и внешнего мониторинга и алертинга в рамках определённых регламентов.

Часть 3. Объектная модель системы в БД

Сравнение БД FineBI и Tableau

Так как перед использованием FineBI был опыт использования Tableau, то напрашивается сравнение структур объектных моделей системы в БД для данных систем.

Можно отметить, что ключевым отличием по возможности мониторинга работы Tableau является предельно подробная БД по основным сущностям системы с описаниями для таблиц «из коробки». FineBI предоставляет в пользование существенно менее удобную систему, в которой администратору предлагается разобраться самостоятельно.

По сути, в FineBI присутствует только техническая система хранения информации для работы с ПО, и она не адаптирована под цели полноценного администрирования системы на основе данных БД.

В 2024 году вендор предоставил возможность формирования ряда системных таблиц с информацией о сущностях системы и иерархиях в формате датасетов на основе подключаемых классов java. Решение в целом правильное, но есть некоторые сложности с первоначальной настройкой. Подключается к платформе с помощью FineReport. Из минусов отметим, что данные хранятся во внутреннем формате датасетов, а не таблицах БД. Поэтому для ряда кейсов мониторинга потребуется дополнительная синхронизация их с данными в таблицах БД. Мы подключали его на тест, но решили не использовать на PROD-среде, так как большая часть кейсов была решена нами в рамках данных из FineDB и LogDB.

В FineBI существуют две связанные концептом БД — FineDB и LogDB. При этом это разные БД по своей организации. FineDB — это реляционная БД, в то время как LogDB — это файловая БД, доступная только через драйвер swift. В FineDB, в основном, содержатся параметры, объекты и связи объектов. В LogDB содержатся события изменений, которые разработчик ПО посчитал нужным логировать. Отмечу, что полная история переходов записей может быть получена только при мониторинге каждой записи управляющих структур FineDB. Данной реализации не предусмотрено.

Избыточность структур FineDB подразумевает, что БД ориентирована, в первую очередь, на работу с ПО. Поэтому часть таблиц БД мало информативна и содержит по факту только 2−3 значимых свойства сущности.

В Tableau БД одна. Она более простая по своей организации и содержит выделенные базовые сущности. Правка сущностей на уровне БД способна изменять их свойства.

В случае с FineBI примечательна ситуация, что вендор по общему правилу не рекомендует вносить самостоятельно какие-либо изменения в БД. Но иногда он даёт на это прямые указания, как в случае с внесением изменений в настроечные параметры (таблица fine_conf_entity БД FineDB). То есть корректировка управляющих структур теоретически возможна, но с этим есть сложности.


Описание FineDB

На сайте вендора существует в целом достаточно полное описание БД на английском и китайском языках. При этом готовых кейсов сбора основных сущностей и формирования связей в интернете крайне мало. По некоторым вопросам их вообще нет.

В связи с необходимостью мониторинга внутреннего состояния объектов системы нами была проведена большая работа по приведению в единое целое разрозненной и связанной неявно информации об основных сущностях и отношениях между ними на основании документации по БД FineDB, LogDB, а также собственных изысканий по интеграции с нашими процессами. По части вопросов мы обращались к GlowByte и разработчику ПО.

Подробнее вопросы о структуре БД, особенностях и практических кейсах для FineDB, а также LogDB будут рассмотрены в последующих публикациях позднее.

Системные отчёты для мониторинга

Объединение информации позволило разработать группы системных отчётов, отражающих отдельные аспекты работы системы. Мы активно используем их в своей работе и готовы поделиться наработками. При этом реализация конечного решения всегда остаётся за командой сопровождения. Вариантов организации FineDB уже сейчас как минимум четыре: на основе бесплатных MySQL, Oracle, SQL Server и платного решения на Postgres. Это разные диалекты построения SQL-запросов и формирования процедур.

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

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

Условно их можно разделить на группы:

1. Мониторинг доступов УЗ на объекты через всю схему ролей (с целью проверки и планирования).
2. Мониторинг использования:

• учётных записей,
• дашбордов,
• датасетов,
• подключений,
• API,
• других объектов системы.

3. Мониторинг нагрузки системы через потребление ресурса:

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

4. Алертинг на критичные сбои в нормальной работе приложения.

Базовые сущности

Список базовых сущностей системы:

1. дашборды;
2. компоненты (в версии старше 6.0);
3. датасеты, производные от первичных источников данных разных уровней,
4. первичные источники данных (таблицы БД, SQL выборки, Excel и CSV Server Dataset);
5. подключения к источникам (БД, файловые коннекторы, в т. ч. swift);
6. ролевые группировки УЗ:

• группы,
• позиции,
• роли;

7. разрешения УЗ на объекты;
8. связи вышеперечисленных объектов между собой, в том числе построение иерархии объектов;
9. расписания обновлений на каталоги и непосредственно датасеты.

Неправильно сказать, что в системе отсутствует информация о сущностях, но часть кейсов требует глубокого погружения в структуру БД FineDB. Я предпочёл бы иметь готовые кейсы построения таблиц данных работы системы «из коробки» вместо самостоятельного построения структур и их потенциальной повторной сборке от одной «мажорной» версии к другой. Так как вендор оставляет на своё усмотрение изменение состава и структуры используемых таблиц, то это приводит к тому, что часть кейсов сборки структур и связей напрямую из FineDB версии 5 не может быть воспроизведена в версии 6.
Потенциально данные преобразования могут произойти и при переходе между «минорными» версиями. Это способно нарушать уже собранные решения при описании модели системы. Таким образом, это потенциально может нарушить отдельные части функционала системной отчётности.

Вопросы построения базовых сущностей для версии 6.0.+ мы рассмотрим подробнее в последующих статьях.

Сложности выделения базовых сущностей и связей

Сложности при анализе данных FineBI через БД существуют и имеют определённые степени градации от малозначимых до практически нерешаемых.

Вряд ли решаемы в рамках текущей организации FineDB:

1. Отсутствие в БД исчерпывающей информации о всех свойствах объектов и их связей. Например, до сих пор нет информации в FineDB об объёме занимаемых датасетов, последней дате обновления кэша данных Direct.
2. В БД записываются только завершённые задачи обновления. Успешные или с ошибкой. Старт незавершенного обновления датасета в БД в данной таблице не отражён.

Существовала проблема построения Origin Dataset, так как прямого указания на построение связи датасетов нами найдено в сети не было. В декабре 2024 нам в целом удалось её решить.

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

Последовательность шагов для получения расписаний:

• экстракция сущностей,
• построение иерархии датасетов и каталогов,
• привязка расписания на датасеты и их родительские каталоги,
• выделение часов запланированного старта из структур расписания обновлений simple и cron.

Часть 4. Примеры практических кейсов сопровождения системы

Планирование потребления ресурса ЦП системы
В случае падения производительности системы FineBI и увеличения отклика Web-интерфейса необходимо выяснить причину.

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

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

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

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

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

Аналитика прав пользователей и групп на сущности дашбордов

Иногда требуется предоставлять в табличном виде организацию всех доступов к объектам УЗ. Есть варианты использования плагина выгрузки от вендора или формирования данных напрямую из FineDB. При этом потребуется правильная иерархия объектов и корректное отнесение имеющихся разрешений учётных ролей на объекты. В целом задача вполне решаемая и подразумевают кастомный подход с расширением на категории пользователей согласно организационной структуре компании.

Подключение внешнего мониторинга к БД FineDB

Несмотря на возможность использования функционала DataAlert в базовом виде и в виде плагина, плюсы дополнительного оповещения ботами по email или в Telegram всё же имеются. В связи с этим на часть состояний БД нами были настроены оповещения, например, о формировании очереди обновлений или о превышении лимитов УЗ на сервере.

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

Коррекция данных структур БД

FanRuan (вендор ПО) не рекомендует напрямую корректировать БД FineDB. Тем не менее, часть конфигураций системы находится в таблице fine_conf_entity, и при изменении некоторых из них вендор напрямую указывает на необходимость добавления или изменения в данной таблице.

Коварство данной таблицы в том, что там не только изменяемые параметры, но и кэшированные данные. В FineBI 5 версии в ней кэшировалось больше данных, чем в 6 версии. Изменение кэшированных данных в данной таблице не вносит изменения в конфигурацию. Они повторно кэшируются. Это источник, в первую очередь, для чтения данных.

Внутри БД возможно создание других таблиц со вспомогательным функционалом (списки, правила и так далее). Важно при этом разделять пространство самой системы и доработок функционала либо префиксами таблиц, либо выносить на другие схемы БД.

Стоит отметить, что коррекция БД напрямую не оставляет сведений о действиях в LogDB. Данный факт всегда стоит учитывать.

Что можно корректировать? Например, заполнение таблицы пользователей fine_user согласно правилам, принятым в компании. По факту, это табличное редактирование карточки, идентичное отображаемому в веб-форме.

Добавление версионности таблиц

Так как FineDB содержат данные преимущественно о состоянии системы, то отслеживание изменений в таблицах на основе триггеров является хорошим решением. Для этого используется версионная таблица, идентичная наблюдаемой. В неё заносятся при событиях after insert, delete, update данные об изменениях: событие, УЗ, время. Заполненная таким образом таблица позволит восстановить изменения в данных БД, дополнительно дублируя/расширяя возможности мониторинга событий LogDB.

Также возможна обработка ненагруженных таблиц триггерами before insert, delete, update, чтобы не допустить коррекцию данных отдельными УЗ или ввести расширенную обработку.

Данный кейс, вероятно, мы также рассмотрим отдельным постом.

Эпилог

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

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

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

Надеемся, кейс был наглядным и полезным. Больше полезной информации о работе FineBI вы найдете в нашем сообществе FineBIChat.