Внутренняя БД finebi и аналитика Bi‑системы: опыт Уралсиб Банка

Внутренняя БД FineBI и аналитика самой BI‑системы

Меня зовут Юлианна Валиуллина, я отвечаю за развитие BI‑направления в банке Уралсиб. У нас BI давно вышла за рамки “отчетов для руководства” и стала полноценной платформой самообслуживания.

В банке более 200 разработчиков BI: около 150 из них публикуют дашборды для широкого круга пользователей, остальные используют систему для личной аналитики. В продуктиве работает свыше 1200 дашбордов, а ежемесячная активная аудитория — примерно 1500 пользователей. Большая часть витрин у нас функционирует в режиме spider (extract), доля подключений в direct‑режиме — около 15–20%.

При такой нагрузке поддерживать платформу “вручную” уже невозможно. Нужен высокий уровень автоматизации администрирования, мониторинга и контроля качества. Поэтому мы выстроили отдельный контур внутренней аналитики по самой BI‑системе: кто что делает, какие дашборды живые, где узкие места, какие объекты «мертвые» и только занимают ресурсы.

Ниже — как устроено хранение данных во внутренней БД FineBI, что мы сделали для долгосрочной истории логов и как на этом построили собственную аналитику по работе BI.

---

Как FineBI хранит данные о своей работе

Внутри FineBI фактически существуют две логические базы данных, сильно отличающиеся по типу и назначению:

- FineDB — реляционная БД (метаданные и часть фактов).
- LogDB — файловое хранилище логов (действия пользователей и системные события).

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

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

---

Основная реляционная БД FineDB

FineDB — это “мозг” системы. В ней хранятся:

- параметры платформы;
- объекты и их связи: дашборды, компоненты (виджеты), пользователи, таблицы, датасеты self‑service;
- начиная с версии 5.1.12 — фактовые данные по обновлению таблиц:
- `fine_update_task`,
- `fine_update_task_detail`.

До версии 5.1.12 информация об обновлениях витрин находилась только в LogDB, но затем часть метрик была перенесена в реляционную БД. Это важно учитывать при миграциях и разработке аналитических витрин: один и тот же показатель в разных версиях FineBI может храниться в разных местах.

По умолчанию FineDB разворачивается во встроенной СУБД HSQLDB, но для промышленной эксплуатации производитель рекомендует выносить ее во внешнюю СУБД. Поддерживаются MySQL 5/8, Oracle, Db2, Postgres и др. Мы в боевом контуре используем PostgreSQL как более устойчивое решение для промышленной нагрузки.

---

LogDB — файловое хранилище логов

Вторая сущность — LogDB. Это файловая БД, доступ к которой осуществляется через специальные драйверы (например, swift или ElasticSearch‑совместимый интерфейс — в зависимости от конкретной установки и версии).

В LogDB попадает все, что относится к “поведению” и активности в системе:

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

Если FineDB — это метаданные и конфигурация, то LogDB — это “черный ящик” полетов, где фиксируются все события внутри системы. Именно из LogDB проще всего получать ответы на вопросы вида:

- какие дашборды реально используются;
- в какие часы/дни наблюдаются пики нагрузки;
- какие пользователи являются “тяжелыми” с точки зрения запросов.

---

Проблема глубины хранения логов и межверсионных изменений

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

Наша цель была — сохранить сквозную историю работы BI‑платформы на горизонте нескольких лет, независимо от внутренних изменений или ограничений текущей версии. Нам недостаточно стандартного по умолчанию срока хранения (около месяца): это мало и для аудита, и для анализа трендов, и для диагностики “медленных” деградаций производительности.

Поэтому мы приняли два решения:

1. Расширить глубину хранения логов в самой FineBI.
2. Выводить ключевые логи в отдельное хранилище, в максимально “сыром” виде либо в виде уже подготовленных агрегатов для наших задач.

Таким образом мы обезопасили себя от сюрпризов в будущих релизах: даже если структура внутренних таблиц поменяется, базовая историческая линия уже сохранена у нас.

---

Настройка глубины хранения LogDB

Для LogDB в интерфейсе администрирования предусмотрены настройки политики хранения. После установки системы мы рекомендуем сразу изменить стандартные значения:

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

Там можно задать, сколько времени и каких именно логов сохранять. Мы целимся минимум в несколько месяцев для детализированных событий и в годы — для агрегированных витрин (уже внутри нашего корпоративного DWH).

---

Настройка очистки данных в FineDB

Отдельно управляется политика очистки в самой FineDB. Она задается параметром:

- `SystemOptimizationConfig.clearEntityStrategy`
в таблице `fine_conf_entity`.

Фактически это стратегия удаления данных из основных таблиц FineDB. Если оставить настройки “как есть”, можно внезапно столкнуться с ситуацией, когда часть истории по объектам или задачам обновления будет автоматически очищена.

Мы переопределили это значение, установив более щадящую политику, а критичные данные дополнительно выгружаем в свое хранилище. Это позволяет не зависеть от внутренних housekeeping‑процессов FineBI.

---

Построение единой модели объектов FineBI

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

Мы проделали большую работу:

- изучили структуру FineDB и LogDB;
- описали основные сущности: пользователи, роли, дашборды, директории, таблицы, задачи обновления;
- восстановили связи между ними по ключам, идентификаторам и косвенным признакам;
- собрали набор связанных датасетов внутри самой FineBI, используя механизм Association.

В результате у нас получилась внутренняя “референс‑модель” BI‑платформы: от пользователя и конкретного клика в дашборде до физической таблицы и задачи обновления.

---

Пример датасета по таблицам (Table)

Ниже — упрощенный пример SQL‑выборки, на основе которой мы строим датасет с описанием таблиц в FineBI. Код адаптирован под PostgreSQL:

```sql
select
t.table_id,
t.table_name,
t.table_alias,
t.creator,
t.config_created_time,
t.driver_type,
t.connection_name,
t.db_table_name
from (
select
trim(e.entity_key, '"') as table_id,
trim(n.entity_value, '"') as table_name,
trim((e.entity_value::json->>'name'), '"') as table_alias,
trim((e.entity_value::json->>'creator'), '"') as creator,
trim((e.entity_value::json->>'configCreatedTime'), '"') as config_created_time,
trim((e.entity_value::json->>'driverType'), '"') as driver_type,
trim((e.entity_value::json->>'connectionName'), '"') as connection_name,
trim((e.entity_value::json->>'dbTableName'), '"') as db_table_name
from FINEBI_S_ENTRYCREATE_EN e
left join FINEBI_TRANSNAME_EN n
on e.entity_key = n.entity_key
where n.namespace = 'TableTransferName'
) t;
```

Эта выборка позволяет связать технический идентификатор таблицы с ее “человеческим” именем, автором, используемым подключением и физическим объектом в внешней СУБД. Такие метаданные мы затем объединяем с логами использования, чтобы видеть, какие таблицы реально востребованы и как часто они обновляются.

---

Иерархия директорий и дашбордов

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

Для этого используется рекурсивный запрос к таблице с объектами авторизации. Пример конструкции (общая логика):

```sql
with recursive dir_tree as (
select
fao.id,
null::text as full_path,
fao.expandtype
from fine_authority_object fao
where fao.id = 'decision-directory-root'

union all

select
child.id,
coalesce(dir_tree.full_path || '/' || child.displayname, child.displayname) as full_path,
child.expandtype
from dir_tree
join fine_authority_object child
on child.parentid = dir_tree.id
)
select
id as directory_id,
full_path as directory_path
from dir_tree
where expandtype = 201; -- код сущности "дашборд"
```

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

---

Ограничения ассоциаций в FineBI до 7‑й версии

При построении внутренней модели мы столкнулись с архитектурным ограничением FineBI:
до версии 7 в механизме Association нельзя было напрямую задавать связи “многие‑ко‑многим”.

Это критично для некоторых сущностей, например:

- один пользователь может работать с десятками дашбордов;
- один дашборд может использоваться сотнями пользователей;
- к одной таблице могут привязываться разные датасеты и виджеты.

Чтобы обойти это ограничение, мы пошли по пути:

- ввели промежуточные “связующие” датасеты;
- часть сложных джоинов реализовали на уровне SQL (предварительные витрины);
- далее использовали уже агрегированные таблицы в FineBI как источники для ассоциаций.

Так мы смогли логически реализовать многие‑ко‑многим через несколько слоев, не ломая стандартный функционал.

---

Регулярная и ad‑hoc аналитика по работе BI

Построив единую модель данных, мы сделали две основные линии аналитики:

1. Регулярная эксплуатационная аналитика:
- отчеты по MAU/DAU;
- мониторинг “здоровья” обновлений (доля успешных/неуспешных задач, задержки);
- динамика роста/спада числа дашбордов и таблиц;
- анализ “мертвых” объектов (давно не открывались, не обновлялись).

2. Ad‑hoc аналитика:
- разовые расследования инцидентов (кто что запускал перед падением, была ли вспышка нагрузок);
- оценки влияния конкретных релизов на поведение пользователей;
- анализ гипотез по оптимизации (например, перенос части витрин из direct в extract).

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

---

Какие метрики по BI‑системе реально полезны

На практике оказались особенно полезны следующие показатели:

- Активность пользователей
- количество уникальных пользователей по дням/неделям;
- доля вернувшихся пользователей (retention);
- глубина сессий (число открытых дашбордов, количество примененных фильтров).

- Жизненный цикл дашбордов
- дашборды, которые никто не открывал N дней;
- критически важные витрины (используются более чем X пользователями в день);
- лидеры по нагрузке (количество запросов, время рендеринга).

- Производительность и обновления
- среднее и 95‑й перцентиль времени обновления таблиц;
- количество фейлов обновления по типам ошибок;
- задержка данных относительно источников (data freshness).

- Ресурсная эффективность
- таблицы и датасеты, которые активно обновляются, но почти не используются;
- пересечение логики между разными витринами (где можно унифицировать и вынести общий слой).

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

---