Привет, Хабр! Мы — 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.
Для мониторинга мы используем следующие поля:
fine_update_task:
starttime — дата и время начала таска (необходимо привести к типу datetime)
endtime — дата и время окончания таска (необходимо привести к типу datetime)
taskname — название обновляемого источника + тип таска (single table/business package/global)
triggertype — MANUAL/AUTO — таск запущен вручную или расписанием (AUTO —
расписание)
rolename — username запустившего обновления (отображается system, если обновление запущено по расписанию)
runningresult — ALL, если обновление прошло полностью успешно; PART, если частично
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 — количество измененных строк
fine_update_detail _info:
exceptionprefix — описание ошибки
Мониторить обновления можно с помощью самого FineBI, выводя данные на дашборд. В нашей компании этим занимаются не только администраторы. Разработчики иногда выводят в отчеты информацию о последнем обновлении использованных в нем источников. Помимо мониторинга обновления источников в самом FineBI мы также настроили мониторинг в open-source BI-платформе Grafana.
Такой мониторинг может быть автоматизирован вплоть до создания бота, присылающего уведомление в случае неудачного обновления.
Что получаем в итоге?
Результат, который мы получили, это отчетность с таблицами и графиками, содержащими различные разрезы данных по использованию FineBI в компании. Например, теперь у нас есть данные по количеству пользователей с различными уровнями доступа к директориям:
Или статистика посещаемости дашбордов из разных директорий:
Такие данные мы можем выводить в отчетность как в разрезе директорий и дашбордов, так и в разрезе отдельных пользователей FineBI. Подобный мониторинг необходим администраторам FineBI и бизнес-владельцам отчетностей для контроля уровня интеграции BI-инструмента в процессы компании, обеспечения информационной безопасности и отслеживания активности пользователей.
Как видите, чтобы продвинуться дальше штатного мониторинга по пользовательским данным в системе, необходимо немного потрудиться и проанализировать системные таблицы. Все перечисленное выше – это основа для сборки необходимых вам датасетов, на базе которых вы можете собрать необходимые вам визуализации. А дальше — вопрос эксперимента и фантазии.
Делитесь в комментариях, какие подобные задачи вы решали в FineBI и что у вас из этого вышло.