Привет, Хабр! Мы — BI-команда Tele2. В прошлом году, как и многие наши коллеги по рынку, столкнулись с проблемой поиска альтернативы BI-платформам покинувших нас вендоров. О том, как подходить к замене платформы, уже много рассказано здесь и на других ресурсах. В этой статье мы остановимся на конкретном кейсе — как мы решили задачу поиска и последующего анализа действий и полномочий наших пользователей, а также взяли под контроль обновление источников. Под катом мы рассказываем, как собрать датасеты в FineBI, на которых можно построить дашборды о дашбордах и получить данные о посещаемости отчетов, их расположении в директориях и доступах к ним пользователей.

Вернемся к событиям прошлого года. Тогда нам нужно было найти альтернативу всем известной платформе (имя которой нельзя называть). Как ни пытались мы играть с лицензиями и обратить ее в свою веру, в конце июля 2022 года нас все равно ждал переход. Тогда мы приняли решение в пользу FineBI и не пожалели. Об этом можно посмотреть видео на канале наших друзей GlowByte: Все будет Fine! Как не уронить Self-Service, меняя платформу или Как разумно заменить BI: нюансы и возможности.

В процессе эксплуатации мы столкнулись с нетривиальной задачей: как организовать мониторинг технических процессов и действий наших пользователей при администрировании новой BI-платформы? В целом, инструменты администратора платформы позволяют получить данную информацию. К примеру, активность пользователей можно вполне просто посмотреть, используя инструменты на вкладке Manage — Platform Log. Особенно полезны разделы User Behaviour и Template Heat: информация доступна к экспорту в файл из интерфейса.

Однако данных разрезов может быть недостаточно для следующих задач:

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

• если необходимо внедрить ролевую модель, чтобы каждый отдел/создатель видел только свои данные;

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

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

Итак, приступим к пошаговой сборке нашего дата-лего.

Располагаем дашборды в директориях

Cобираем датасет, содержащий опубликованные дашборды и папки (директории), в которых они находятся. Такие данные есть в таблице FineDB fine_authority_object. Она составлена с детализацией до объекта, которым может являться как, например, дашборд, так и директория. Обрабатываем ее с помощью SQL-скрипта. В нашем случае используется PostgreSQL:

• определяем корневые папки (директории)

with 
project as 
(SELECT id as project_id, displayname as project_name
from fine_authority_object
where expandtype=3 and fullpath='decision-directory-root'),

• определяем вложенные папки:

sub_project AS 
(SELECT id as sub_project_id, parentid,  displayname as sub_project_name 
from fine_authority_object
where expandtype=3 and fullpath<>'decision-directory-root'),

• определяем вложенные папки второго уровня:

sub_sub_project AS 
(SELECT id as sub_sub_project_id, parentid,  displayname as sub_sub_project_name 
from fine_authority_object
where expandtype=3 and fullpath<>'decision-directory-root'),

• определяем дашборды:

dashboard AS 
(SELECT id as dashboard_id, parentid,  displayname as dashboard_name 
from fine_authority_object
where expandtype=201)

SELECT 
project_id, project_name, 
'' as sub_project_id, '' as sub_project_name, 
'' as sub_sub_project_id, '' as sub_sub_project_name ,  
dashboard_id, dashboard_name
from project
left join dashboard
ON project.project_id=dashboard.parentid

union all

SELECT 
project_id, project_name,  
sub_project_id,  sub_project_name,
'' as sub_sub_project_id, '' as sub_sub_project_name,  
 dashboard_id, dashboard_name
from project
left join sub_project
on project.project_id=sub_project.parentid
left join dashboard
ON sub_project.sub_project_id=dashboard.parentid

union all

SELECT 
project_id, project_name,  
sub_project_id,  sub_project_name,
sub_sub_project_id, sub_sub_project_name,  
 dashboard_id, dashboard_name
from project
left join sub_project
on project.project_id=sub_project.parentid
left join sub_sub_project
on sub_sub_project.parentid=sub_project.sub_project_id
left join dashboard
ON sub_sub_project.sub_sub_project_id=dashboard.parentid

В результате получается датасет со следующей структурой: id папки (директории) — название папки (директории) — id вложенной папки – название вложенной папки — id вложенной папки второго уровня — название вложенной папки второго уровня — id дашборда — название дашборда. Гранулярность датасета — дашборд.

Формируем датасет пользователей, лицензий, ролей и департаментов

Составим датасет с информацией о пользователях инструмента. Для этого необходимо объединить несколько таблиц FineDB:

• fine_user (id) → fine_user_role_middle (userId). Соединяем таблицу fine_user с информацией о пользователях (id, ФИО, логин, email) с таблицей, содержащей id пользователя и id назначенных ему ролей;

• fine_user (id) → fine_extra_property (relatedId). Соединяем с таблицей, содержащей типы лицензий, выданных пользователям;

• fine_user_role_middle (roleId) →  fine_custom_role (id). Соединяем с таблицей с кастомными ролями (в нашем случае);

• fine_user_role_middle (roleId) → fine_dep_role (id). Соединяем с таблицей, содержащей id роли и id департамента, к которой она дает доступ;

• fine_dep_role (id) → fine_department (id). Соединяем с таблицей с названием департамента, к которому относится пользователь.

Конечный набор включаемых таблиц зависит от потребностей мониторинга и ролевой модели, реализованной в компании.

Объединяем пользователей и их доступы к директориям

В нашей ролевой модели доступы к директориям определяются департаментами, к которым относятся пользователи. Каждой папке соответствует два департамента: один — одноименный, дающий пользователю права на чтение, а второй — с пометкой «create», дающий права на редактирование. Для вложенных папок, доступ к которым ограничен и не предоставляется по умолчанию вместе с доступом к корневой директории, реализована такая же логика.

Пользователям назначаются департаменты на вкладке Users в режиме Edit user.

Поэтому в ходе мониторинга доступов мы опираемся на назначенные пользователям департаменты. Соблюдение правил нейминга позволило объединить датасет с пользователями с доступными им дашбордами в зависимости от названий директорий (project_name, sub_project_name, sub_sub_project_name) и департаментов (поле name в таблице fine_department), а также добавить поле с типом доступа — редактирование или чтение.

Альтернативный вариант — объединение пользователей с доступными им дашбордами через таблицу FineDB fine_authority. Объединять таблицы можно так:

• fine_authority (authorityentityId) → fine_ authority_object (id);

• fine_authority (roleId) → fine _user_role_middle (roleId);

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

Настраиваем контроль посещаемости отчетов и активности пользователей

Данные о действиях пользователей на платформе записываются в таблицах LogDB. Для мониторинга активности пользователей мы используем таблицу fine_record_execute. В ней записываются логи всех действий пользователей c дашбордами на платформе. Стоит обратить внимание на то, что глубина хранения данных составляет 4 месяца. Если необходимо отслеживать динамику в течение более длительного периода, можно самостоятельно формировать витрину, в которую будут выгружаться новые данные при обновлении исходной таблицы.

Fine_record_execute соединяется со сформированными раннее датасетами по полям reportId (id дашборда) и userId (id пользователя). Для мониторинга посещаемости отчетов устанавливаем фильтр fine_record_execute.type = 101 (тип действия – просмотр отчета). Также доступны дата и время действия (поле time), что в дальнейшем позволяет смотреть статистику по различным периодам.

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

Подключаем мониторинг обновлений источников

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

Посмотреть актуальные обновления администратор может на вкладке Update task management в разделе Data Preparation.

Получить данные об обновлении источников можно и из таблиц FineDB: fine_update_task, fine_update_task_detail, fine_update_detail_info. В них хранятся записи о каждом запущенном обновлении источников в FineBI. Глубина хранения данных по умолчанию установлена 1 месяц.

Таблицы соединяются по planId (уникальный идентификатор для каждого таска) через left join к fine_update_task. Важно обратить внимание, что каждый раз при отработке одного и того же обновления даже в рамках одного расписания planId будет разным. PlanId совпадают при обновлении разных источников в рамках одного таска (например, если обновляется датасет, построенный на нескольких таблицах). Для отслеживания расписания обновления одного источника можно использовать поле taskname.

Для мониторинга мы используем следующие поля: 

1. fine_update_task:

   starttime — дата и время начала таска (необходимо привести к типу datetime)

   endtime — дата и время окончания таска (необходимо привести к типу datetime)

   taskname — название обновляемого источника + тип таска (single table/business package/global)

   triggertype — MANUAL/AUTO — таск запущен вручную или расписанием (AUTO —

   расписание)

   rolename — username запустившего обновления (отображается system, если обновление запущено по расписанию)

   runningresult — ALL, если обновление прошло полностью успешно; PART, если частично
   

2. fine_update_task_detail:

   loadname — название обновляемого источника + business package, в котором он лежит 

   loadtype — тип объекта – BASE: basic table; FAST, ETL: self-service data set; RELATION: association

   statetype — статус таска — LOADING: Updating; SUCCESS: Successful; PART_SUCCESS: Partially successful; WAITING: Waiting in line; WRONG: Failed

   tablename — название обновляемого источника

   tableid — id обновляемого источника

   updatetype — тип обновления: FULL — полное обновление; INCREASE — инкрементальное

   errorcode — код ошибки (0, если отработало без ошибок)

   updatecount — количество измененных строк
   

3. fine_update_detail _info:
   
   exceptionprefix — описание ошибки

Мониторить обновления можно с помощью самого FineBI, выводя данные на дашборд. В нашей компании этим занимаются не только администраторы. Разработчики иногда выводят в отчеты информацию о последнем обновлении использованных в нем источников. Помимо мониторинга обновления источников в самом FineBI мы также настроили мониторинг в open-source BI-платформе Grafana.

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

Что получаем в итоге?

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

Или статистика посещаемости дашбордов из разных директорий:

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

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

Делитесь в комментариях, какие подобные задачи вы решали в FineBI и что у вас из этого вышло.