Привет, Хабр!  Меня зовут Юлианна Валиуллина и я главный эксперт по развитию BI в банке Уралсиб.

Для начала немного о нас: мы практикуем self-service подход, в банке более 200 разработчиков, из них 150 имеют опубликованные дашборды, остальные делают аналитику для себя. Более 1200 опубликованных дашбордов, MAU около 1500. Большая часть дашбордов в нашем банке работает в spider(extract) режиме, доля direct 15-20%.

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

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

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

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

Структура таблиц FineBI

В FineBI реализовано хранение данных в двух разных по своей организации БД. FineDB – это реляционная БД. По умолчанию FineDB хранится во встроенной СУБД HSQLDB. Существует возможность подключения внешних СУБД – MySQL5, MySQL8, Oracle, Db2, Postgres, мы используем Postgres.

В FineDB содержатся параметры, объекты и связи между ними - дашборд, компонент (виджет), пользователь, таблица, self-service dataset. А также начиная с версии 5.1.12  фактовые данные об истории обновления таблиц fine_update_task, fine_update_task_detail (до версии 5.1.12 эта информация  в хранилась LogDB).

LogDB – файловая БД, доступная через драйвер swift или elastic search.

LodDB содержит остальные логи: действия пользователей, обновления датасетов, загрузка дашбордов в браузере.

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

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

Для LogDB это можно сделать с помощью интерфейса конфигурирования  System management  >  Platform log  > Global setting (English  https://help.fanruan.com/finebi-en/doc-view-4706.html)

глубина логов
глубина логов

Для изменения глубины хранения таблиц FineDB необходимо в таблице fine_conf_entity переопределить переменную SystemOptimizationConfig.clearEntityStrategy, которая определяет стратегию удаления таблиц FineDB. (English https://help.fanruan.com/finebi-en/doc-view-5235.html)

FineDB

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

Мы построили связанные датасеты (связь через механизм Association) по всем значимым объектам системы.

Приведу код некоторых из датасетов со схемы выше.

Table (таблицы)
select tableid
       , tablename
       , tablealias
       , creator
       , configCreatedTime
       , driverType
       , connectionName
       , dbTableName
from
(   select trim(e.entity_key, '"') tableid
       , trim('"' from n.entity_value) tablename
       , trim (e.entity_value::json->>'name', '"') as tablealias
       , trim (e.entity_value::json->>'creator', '"') as creator
       , trim (e.entity_value::json->>'configCreatedTime', '"') as configCreatedTime
       , trim (e.entity_value::json->>'driverType', '"') as driverType
       , trim (e.entity_value::json->>'connectionName', '"') as connectionName
      , trim (e.entity_value::json->>'dbTableName', '"') as dbTableName
from FINEBI_S_ENTRYCREATE_EN e
left join FINEBI_TRANSNAME_EN n on e.entity_key = n.entity_key
where  n.namespace = 'TableTransferName'
  ) t

 Directory (дашборды с путем в directory)

with recursive r as (
        select  id,
            null as chain,
            expandtype
        from fine_authority_object
        where id = 'decision-directory-root'
        union
        select c.id,
            coalesce(r.chain || '/' || c.displayname, c.displayname) as chain,
            c.expandtype
        from r
        join fine_authority_object as c on c.parentid = r.id)
    select
        id as directoryid,
        chain as directorypath
    from r
    where expandtype = 201 -- Дашборд

 Как это выглядит в FineBI.

В FineBI до 7 версии отсутствует возможность сделать связь многие-ко-многим через ассоциации, поэтому я реализовала ассоциацию многие-ко-многим через связующие таблицы:

associations2
associations2

Начиная с 6-ой версии FinebI появились датасеты системных конфигураций (Chinese https://help.fanruan.com/finebi-tw/doc-view-1661.html) с информацией о сущностях системы и связях между ними на основе подключаемых классов java. 

Вверсиях 6.0.10 и более поздних набор конфигурационных датасетов встроен в папку «Public Data > Function Data > User Access Log > Resource Configuration Information» и может использоваться непосредственно, не требуя дополнительных шагов.
Если в вашей установке нет этого набора датасетов, то можно добавить их, следуя инструкции см. (Chinese https://help.fanruan.com/fineops-tw/doc-view-117.html).

Далее привожу список этих датасетов, начиная с наиболее полезных:

Table Name

Class file name

Опубликованные дашборды с директорией

BIReportMountIndex.class

Таблицы всех типов, id, alias, name, drivertype, type, даты создания и последнего редактирования, текст sql, путь

BIConfigTableIndex.class

Дашборды id, name, даты создания и последнего редактирования, subject_id, путь

BIReportConfigIndex.class

Подключение(connections)

BITableConnectionIndex.class

Зависимость датасетов (parent-child)

BITableDependencyIndex.class

Сабжекты

BISubjectIndex.class

Документы Analysis Document

BIDocConfigIndex.class

Компоненты

BIWidgetConfigIndex.class

Переходы lineage

BISubjectConsanguinityIndex.class

BIReportMountIndex

BIConfigTableIndex

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

LogDB

(English https://help.fanruan.com/finebi-en/doc-view-1134.html)

Самые полезные для нас таблицы:

fine_records_execute – действия пользователей всех типов, типы (code) перечислены на странице https://help.fanruan.com/finebi-en/doc-view-1134.html, в новых версиях добавляются новые типы. Эти данные могут иметь широкое применение – от простой аналитики просмотров дашбордов, до анализа сложных и редких действий разработчиков.

fine_engine_performance – логи выполнения задач расчета компонента в браузере (информация об отслеживании событий, связанная с затратой времени на расчеты). То есть информация о том, как быстро дашборд отображается в браузере у каждого пользователя. Это один из ключевых KPI нашего подразделения.

Оффтоп, как долго рассчитываются компоненты, и что на это влияет, можно посмотреть в Performance Analysis (English https://help.fanruan.com/finebi-en/doc-view-1294.html).

Регулярная аналитика

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

Активность BI-пользователей: отслеживаем показатели от базовых – количество пользователей, количество дашбордов, длительность сессии, среднее количество просмотров, время, проведенное в системе, до более сложных – регулярность,  длительность сессии, количество действий за сессию.

Нагрузка на сервер – это дашборд, который показывает ключевые KPI нашей команды - отсутствие большой задержки при открытии дашбордов пользователями и обновление всех датасетов в системе с задержкой не более часа в рабочее время. Дашборд показывает агрегированные показатели в формате календаря.

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

Ad-hoc аналитика

Подготовленные датасеты по сущностям BI-системы позволяют нам быстро строить ad-hoc дашборды по любому вопросу, касающемуся происходящего на сервере FineBI, например: отследить неиспользуемый контент, сломанные датасеты, самые долгие обновления таблиц, повторяющиеся sql-запросы, типы чартов, используемые в дашбордах и прочее.

Приведу несколько кейсов, для чего мы применяем эти данные.

1) Для увеличения производительности сервера. Было создано два дашборда по неиспользуемому контенту и по дублям данных. Собрали данные и теперь высылаем каждому разработчику информацию о том, что ему можно улучшить - сломанные датасеты, медленно обновляемые, повторяющиеся данные (дубли датасетов), таблицы, не используемые в дашбордах или используемые в дашбордах, которые давно не просматриваются.

2) Эту информацию мы использовали и для марафона BI Challenge: 80 героев, 1000 дашбордов и море данных в Уралсиб x FineBI.

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

Вся описанная работа - это не просто техническая настройка BI-системы. Наша ключевая цель как команды - обеспечить пользователям максимально быстрое получение value из данных. Именно поэтому мы выстраиваем связанные датасеты, создаём разные типы дашбордов и глубоко анализируем использование системы и её производительность. Это позволяет нам проактивно находить узкие места, убирать неиспользуемый контент, оптимизировать обновления и повышать скорость работы дашбордов ещё до того, как проблемы заметит пользователь. В результате BI-платформа становится управляемой и прозрачной экосистемой, встроенной в процессы банка, а self-service аналитика масштабируемой и устойчивой. Такой подход снижает операционные затраты, повышает доверие к данным и позволяет бизнесу получать ценность из аналитики быстро, предсказуемо и легко.