Меня зовут Сергей Усов. В Газпромбанке я в составе небольшой команды занимаюсь развитием и сопровождением корпоративной BI-системы на базе решения Sigla Vision — российской корпоративной BI-платформы.

Мы хотим поделиться практическими наработками с сообществом пользователей Sigla Vision — сделать работу с системой удобнее и облегчить жизнь администраторам. При этом часть наших подходов может пригодиться и тем ИТ-специалистам (разработчикам, дата-инженерам, аналитикам), которые сопровождают работу технических систем, имеющих в своем составе БД с репозиториями метаданных. Описанные решения являются общеинженерными и могут быть применены не только к корпоративным аналитическим системам.

Это первая статья из цикла, посвященного нашему опыту администрирования Sigla Vision.

Идея и цели цикла статей

Администрирование Sigla Vision в целом похоже на администрирование любой другой BI-системы — со своими особенностями. Штатное администрирование во многом обеспечивается встроенными инструментами «из коробки». Но для нетиповых задач по сопровождению часто приходится создавать кастомные решения — чтобы получать нужную информацию проще и быстрее. Этот процесс адаптации системы к более удобному администрированию и дал название статье.

Мы убеждены: открыто поделиться наработками полезнее, чем держать их только внутри команды. Да, мы потратили немало сил на создание и отладку решения. Но взамен рассчитываем получить конкретные вещи:

от пользователей Sigla Vision, которые возьмут наши разработки себе:

• результаты тестирования в других условиях (другие версии ПО, другие сценарии использования) — чтобы найти ошибки, которые мы не заметили у себя;

• идеи по оптимизации и улучшению кода;

• предложения по расширению функционала для объектов, с которыми мы пока не работали;

от вендоров Sigla Vision:

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

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

Личный опыт и первые версии наработок

С системой FineBI я впервые столкнулся в мае 2023 года: тогда это была версия FineBI 5, а я работал в другой компании — сначала как разработчик, потом как администратор.

Подробнее про тот этап — выбор BI-системы на замену Tableau, миграцию отчетности и первые наработки по объектной модели FineBI — можно прочитать в этой статье.

Тогда мы проделали большой путь по изучению устройства FineDB и LogDB: разобрали основные сущности системы, установили связи между объектами, разработали прикладные отчеты о работе системы.

В конце 2024 года я перешел в Газпромбанк и продолжил развивать наработки по объектной модели — уже на базе Sigla Vision 1.0.20 (в составе Sigla Vision используются исходные коды решения FineBI).

Я также активный участник групп SiglaVisionChat и FineBIChat в Telegram — там можно найти часть моих изысканий по извлечению метаданных из FineDB.

Этот опыт и лег в основу того, о чем пойдет речь дальше.

Почему недостаточно функционала администрирования «из коробки»

Ограничения интерфейса и API

Когда мы говорим об использовании BI-решения, есть три ключевых составляющих:

1. Пользователь  — как субъект всего процесса работы с BI.

2. Дашборд  — как инструмент взаимодействия с данными.

3. Датасет — данные для работы дашбордов.

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

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

Если бы у администратора «из коробки» была вся необходимая информация о состоянии Sigla Vision, вопрос кастомных доработок вообще бы не возник.

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

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

Ключевые сущности и метрики, скрытые от администратора

Чтобы понимать состояние системы и особенности ее работы, важно как минимум знать:

• количество основных сущностей: опубликованные дашборды, их компоненты, источники, подключения, обновления, рассылки;

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

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

Еще одна причина: статистику по просмотрам контента запрашивают и бизнес-подразделения.

Отсутствие данных об изменениях

В FineDB, как правило, хранится только последнее (актуальное) состояние объектов. Для полноценного сопровождения системы этого мало, потому что регулярно нужно:

• получать данные о состоянии системы на определенный момент в прошлом;

• понимать, сколько изменений выполнили пользователи за период.

Теоретически часть этой информации можно вытащить из LogDB, но это сложно и далеко не все нужное там есть.

Предлагаемое решение

Мы предлагаем подход к администрированию Sigla Vision, который позволяет получать гораздо больше информации о различных объектах системы — с учетом их взаимосвязей и истории изменений.

Объектная модель системы

Основная идея — на базе данных из FineDB и LogDB создать отдельные таблицы для всех основных сущностей системы со всеми их свойствами, установить связи между ними, а также разобрать логи ключевых процессов (обновления датасетов, рассылки дашбордов и т. д.).

Для дальнейшего изложения приведем сопоставление некоторых терминов в Sigla Vision (русский) и FineBI (английский). В таблице не отражены случаи однозначного соответствия (например, «Пользователи» и «Users»).

Читать схему проще в обратном порядке — от источников данных к блокам «Пользователь» и «Разработчик», которые работают с дашбордами.

Перечислим основные функциональные особенности Sigla Vision, которые влияют на построение объектной модели:

1. Бизнес-пользователи (Viewers) в основном просматривают готовые отчеты — назовем это «Дашборд как публикация». Дополнительный сценарий — получение файлов рассылок («Дашборд как рассылка»).

2. Разработчики (Designers) создают дашборды Sigla Vision и отчеты FineReport, публикуя их в «Коллекции». Их взаимодействие с контентом — «Дашборд как шаблон» в «Песочнице» разработчика.

3. У каждого разработчика своя область «Песочницы». В ней он работает с «Рабочей книгой», которая содержит шаблоны дашбордов, компоненты, датасеты уровня рабочей книги (SSDS), вычисляемые меры (измерения и индикаторы) и параметры.

4. Датасеты можно объединять с другими датасетами. При этом растет число зависимых датасетов и усложняется иерархия связей.

5. В разделах «Коллекция», «Песочница», «Источники» есть своя иерархия каталогов и размещенных в них объектов.

6. Действует ролевая система разграничения прав, в том числе через роли с учетом иерархий объектов.

7. Для датасетов можно настроить различные обновления.

8. Для дашбордов можно настроить различные рассылки.

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

10. Отчеты FineReport не имеют подробного описания контента в FineDB, но могут использовать подключения Sigla Vision для получения данных. Они интегрируются в «Коллекцию».

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

12. Объекты бывают самостоятельными сущностями (дашборд, датасет с набором индивидуальных свойств) и составными, объединяющими другие сущности по признакам. Например: «Коллекция» (совокупность точек публикации дашбордов на портале с иерархией), «Корзина» (место удаленных объектов) или «Песочница» разработчика (совокупность его «Рабочих книг»).

Функциональная модель Sigla Vision с ее сущностями и объектами устроена достаточно сложно. В следующих статьях мы приведем понятные примеры использования данных объектной модели в разных сценариях сопровождения.

Сущности, включенные в объектную модель:

1. пользователи,

2. роли,

3. разрешения на объекты,

4. рабочие книги,

5. дашборды,

6. компоненты дашбордов,

7. датасеты,

8. подключения,

9. связи дашбордов, компонентов, датасетов, подключений,

10. расписания обновлений,

11. расписания рассылок,

12. логи рассылок,

13. логи обновлений,

14. логи действий в системе,

15. пространства «Коллекция», «Песочница», «Источники», «Корзина».

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

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

Дополнительный функционал

Извлечение данных из нужных таблиц FineDB — простое и эффективное решение, которое минимально влияет на штатный функционал Sigla Vision. Все происходит в пределах одного сервера БД: для работы с дополнительными данными мы создали удобные витрины, обновляемые через одноименные расчетные функции.

На базе этих таблиц и представлений мы также сделали ряд «системных дашбордов» — и для прикладных администраторов, и для некоторых пользовательских ролей.

Для отдельных задач мы дополнительно задействовали триггеры, которые позволяют влиять на пользовательский интерфейс — например, добавлять проверки вводимых значений или запрещать определенные действия.

Практическая ценность и применение

Чтобы показать реальную пользу объектной модели, рассмотрим два типичных примера.

Пример № 1. Выявление причин повышенной нагрузки на сервер

Утилизация процессора подскочила с 30% до 80% в определенные часы. Нужно понять, почему.

Обычный ход анализа примерно такой:

1. Это вызвано Sigla Vision или другим софтом?

2. Штатная работа ПО или сбой?

3. Если штатная — что изменялось в последнее время?

4. Ищем по логам контент, который повлиял на производительность.

5. Анализируем сценарий взаимодействия с контентом.

6. Проверяем гипотезы и устраняем проблемы.

Это рабочий вариант — найти по логам проблемные места и разобраться постфактум.

Но есть и другой путь — более оперативный и даже превентивный. Если отслеживать важные метрики и группы объектов, можно сравнивать их между собой и искать аномалии. Можно получить усредненную статистику работы системы по группам объектов.

Обнаружить причину аномальной работы гораздо проще, когда вы заранее понимаете закономерности и знаете, как система функционирует на уровне объектов.

В нашем случае мы выявили ситуацию: общее число дашбордов за наблюдаемый период выросло всего на 5%, но в новых отчетах количество компонентов оказалось на 50% выше среднестатистического. Именно это и вызвало скачок утилизации процессора. Дополнительно обнаружились частые обращения разных пользователей к этому контенту с многократным использованием DEF-функций. Так мы быстро нашли причины роста потребления ресурсов.

Без автоматизированного учета сущностей разобраться «в моменте» невозможно: непонятно, связаны ли проблемы с количественными изменениями (усложнение вычислений, одновременный доступ больших групп пользователей) или это качественные проблемы, которые нужно решать на уровне оптимизации — силами администраторов или представителей вендора.

Пример № 2. Планирование бюджета на сопровождение BI-системы

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

1. Как росло количество дашбордов?

2. Как часто пользователи с ними работают?

3. Какие подразделения потребляют основную долю вычислительных мощностей?

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

С готовой объектной моделью аналитика для прогнозирования занимает значительно меньше времени и дает более точный результат.

Без нее прогнозирование может стать серьезной проблемой. Все ли данные валидны? Что было вчера, месяц назад, год назад? Отследить динамику объектов через UI невозможно — мониторинг количественных показателей показывает только текущее состояние. Автоматических контрольных срезов на определенные даты в системе нет. Если данные не были зафиксированы ранее, сравнивать текущее состояние просто не с чем. И качество прогнозов страдает.

Вместо заключения

Средствами PostgreSQL мы превратили разрозненные данные из FineDB и LogDB в цельную объектную модель Sigla Vision. Теперь администратор видит не отдельные фрагменты информации, разбросанные по интерфейсам, а единую связную картину: каждый объект — дашборд, компонент, датасет, подключение — со всеми свойствами и взаимосвязями в формате «одна строка — один объект». Плюс полная история изменений.

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

• Объектная модель данных Sigla Vision — устройство модели и примеры ее применения для администрирования.

• Версионирование данных в FineDB — реализация триггеров, которые сохраняют историю изменений и позволяют отразить состояние системы на любую дату.

• Системные дашборды — мониторинг системы, процессов, анализ нагрузки, контроль действий пользователей.

• Контроль и проверки на уровне БД — как с помощью триггеров внедрять дополнительные правила прямо в интерфейс системы: от валидации данных до ограничения операций.

• Аллокация ресурсов и расчет стоимости владения — методика распределения затрат на сопровождение работы системы между подразделениями на основе данных о просмотрах и использовании дашбордов.

Мы не профессиональные разработчики, поэтому SQL-код (для PostgreSQL) публикуем AS IS — как рабочий прототип, открытый для улучшений. Главная ценность наших наработок — не в идеально выверенных скриптах, а в принципах и подходах, которые можно внедрить уже сейчас и доработать под свою специфику.

Все материалы — схемы, описания сущностей, примеры запросов и готовый код — будут сопровождать каждую статью и доступны в репозитории. Уже сейчас там можно найти актуальную схему объектной модели в формате drawio.

Этот цикл статей — приглашение к диалогу. Мы делимся опытом, чтобы вместе с сообществом сделать процесс администрирования Sigla Vision / FineBI более прозрачным и удобным.