Привет, Хабр!

Это вторая и последняя статья из цикла «Архитектура аналитической платформы». Поговорим об общем устройстве BI-системы и подробнее остановимся на анатомии Modus BI.

Анатомия BI-системы

В классическом DW/BI есть несколько составляющих:

• ETL — система управления данными;

• DWH — хранилище данных;

• BI — платформа, которая выводит, визуализирует данные и строит отчеты.

BI по формату клиентской части делится на 3 вида:

• desktop-клиент – приложение аналитической системы устанавливается на компьютер пользователя;

• портал – аналитическая система выводится на web-приложение;

• мобильное приложение – обычно используется для оперативной работы с аналитической системой на мобильном устройстве. 

Мы в Modus используем web-портал и считаем, что это более современное решение.

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

Ниже рассмотрим составляющие и процессы в них более подробно.

ETL

Для BI-системы не подойдут сырые данные – они должны быть нормализованы и подготовлены. Поэтому удобно совместно с BI использовать ETL инструменты.

С помощью ETL данные переносятся в слои (стейджинговый, ядра) обработки, где они очищаются, структурируются и приводятся в нормализованный вид. Подготовленные для аналитики данные перемещаются в слой отчетности Data marts, часто организованный на OLAP-системах (например, ClickHouse).

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

ETL инструменты можно интегрировать с BI. Это позволяет BI «узнавать» о метаданных слоя отчетности, моделях данных и т.п. без дополнительной настройки.

Источники данных

BI-система может брать данные из различных источников:

• DWH (например, мы работаем с PostgreSQL, Microsoft Sqlserver, ClickHouse, Vertica и т.п.);

• из OLAP-систем по протоколу XMLA;

• из файлов – например, xlsx.

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

Чтобы ускорить взаимодействие и получение данных в наш портал интегрированы различные драйверы для работы с СУБД.

Когда пользователь работает самостоятельно и не может загружать данные в DWH, портал может загрузить информацию в базу из файла xlsx.

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

У нас есть self-service механизм, с помощью которого пользователь может вносить данные в аналитический портал. Для этого достаточно описать набор данных, который будет заполняться, нарисовать форму и разместить на ней элементы. Аналитик или администратор без программирования могут настроить свободные формы ввода данных, а консолидированная информация по ним отобразится в отчетах. При этом можно настроить ограничения как на уровне доступа к самим формам, так и на уровне доступа к данным.

Аналитический портал

Из источников данные попадают в конечный пункт – аналитический портал.

У нас это SPA web-приложение, которое содержит раздел для администрирования и настройки, и непосредственно дашборды с визуализациями.

Портал, как и большинство сайтов, состоит из frontend’а (пользовательский интерфейс и сопровождающие компоненты) и backend’а (та часть, которая отвечает за логику, т.е. всё, что находится на сервере: CMS, API систем сайта, админки и личные кабинеты, и т.п.).

Frontend и backend могут быть написаны на разных языках: стек подбирается, исходя из задач и функциональности. У нас в Modus BI в качестве backend – служба, написанная на Go, а frontend – приложение на React. Для визуализаций используются различные библиотеки для построения чартов – GoJS, AMCharts, на более низком уровне - D3.

Frontend и backend между собой обмениваются данными, обычно, по http-протоколу, зачастую используется подход AJAX. Наш backend предоставляет API, через который front получает все необходимые данных в json.

Важно помнить, что во многом скорость вывода данных зависит не от работы портала, а от скорости их выдачи базой данных. Для маленьких объемов до нескольких миллионов записей не очень важно, какую именно СУБД использовать. Например, у нас обычно иcпользуется PostgreSQL. А для большего объема, например, несколько десятков или сотен миллионов строк, лучше использовать колоночные базы данных и специальные индексы.

Мы можем работать с разными типами СУБД в качестве источника, но отдаем предпочтение колоночным. Например, у нас сейчас есть дата-сеты с несколькими миллиардами строк и аналитика по нему на довольно слабом железе выдается за несколько секунд.

Процессы в аналитическом портале

Аналитический портал включает в себя множество функций. Рассмотрим некоторые из них подробнее.

• Аутентификация пользователя

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

  У нас, например, есть собственная система аутентификации – мы можем заводить пользователей на самом портале. Это самый простой «коробочный» вариант. Еще есть интеграции с SSO-системами. Можно использовать протоколы SAML (самый популярный) или OAuth 2.

• Настройка ролей, доступов и RLS

  Обычно в BI-системах есть 3 роли, под которыми можно работать:

   - пользователи – только просмотр дашбордов;

   - аналитики – могут создавать и просматривать отчеты, разрешенные их профилями доступа;

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

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

При использовании внешних сервисов аутентификации очень важна связь данных пользователя из внешней системы с ролями и настройками в BI-системе. Протоколы SAML и OAuth 2 передают различную информацию, связанную с настройками учетной записи. В Modus BI мы можем настраивать взаимосвязь между передаваемыми настройками и настройками доступа на портале (гибкая модель доступа к данным).

• Хранение настроек и метаданных

  Для хранения метаинформации BIсистема должна иметь внутреннюю базу данных. Это могут быть как классические реляционные СУБД, так и NoSQL базы данных. Мы используем базу метаданных на PostgreSQL. В ней хранятся списки пользователей, настройки, отчеты и т.п.

• Кэширование данных

  Для быстрой отдачи «горячей» информации BI-система может использовать кэширующий слой. В качестве кэша могут использовать как собственные наработки, так и open-source решения.

  У нас в Modus BI также есть слой кэширования. Он сохраняет историю и в следующий раз вернет данные на аналогичный запрос в разы быстрее. Если данных в кэше нет, то они запрашиваются из источника и сохраняются в кэше. Это очень ускоряет работу. Например, получение данных из ClickHouse может занимать 500 миллисекунд-10 секунд, а из кэша - 1-100 миллисекунд.

• Корректировка данных «на лету»

  Часто бывает нужно «поправить» данные в хранилище, не проделывая длинный путь "корректировка в источнике — обновление слоя сырых данных — слой ядра хранилища — витрины". Для этого можно корректировать данные напрямую в дашборде. К примеру, в таблице есть числовой показатель, и пользователь хочет его отредактировать. Он заходит в дашборд, выбирает нужную запись и редактирует показатель. И это изменение сразу же влияет на связанные с ним панели.

• Общий доступ к дашбордам и встраивание в другие ресурсы

  В BI есть возможность сделать отдельные дашборды общедоступными. Это полезно, если вы хотите поделиться своей работой с коллегами или начальством. Также можно встроить дашборды через iframe на сторонние сайты и сервисы, чтобы все пользователи видели графики и диаграммы, например, на сайте компании.

• Конструктор (настройка) дашбордов

  Конструктор дашбордов – это инструмент self-service, с помощью которого пользователь настраивает визуализации и дашборды. Все drill-down`ы, сквозная подсветка курсора (когда мы хотим посмотреть один и тот же показатель на разных диаграммах), настройки дизайна, оформление и т.п. настраиваются при помощи выведенных в интерфейс полей настройки.

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

• Настройка верстки

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

• Фильтрация

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

• Экспорт дашборда и отчетов

  Пользователь может выгрузить один элемент дашборда или весь дашборд целиком. Если предстоит экспорт одного элемента, то его можно вывести в виде картинки или в шаблон Excel-файла: можно заранее установить шаблон оформления в корпоративном стиле. Общий холст дашборда можно выгрузить в виде изображения (png или jpeg) или в презентацию pptx. Это очень удобно, например, для показа на планерках.

Вместо итогов

• BI-система включает в себя ETL-процессы, DWH и непосредственно саму аналитическую платформу, которая может быть в виде десктоп-клиента или web-портала.

• Данные для BI должны быть подготовлены: нормализованы и очищены, иначе вы получите кривую аналитику. Для этого удобно использовать ETL-инструменты. 

• В качестве источника данных для аналитической платформы используются хранилища данных (DWH) и OLAP-системы. В качестве исключения могут использоваться неструктурированные данные, в том числе Excel-файлы.

• Скорость работы BI зависит, помимо прочего, от выбранной СУБД (DWH) и ее архитектуры.

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

BI-системы, в целом – это удобный инструмент для компаний с большим количеством данных или их источников. Это направление сейчас активно развивается в сторону self-service и low(no)-code, поэтому занимает меньше времени по сравнению с классическими методами аналитики «на коленке» в Excel.

Кроме того, системы постоянно развиваются и «обрастают» дополнительным функционалом. Например, мы в этом году планируем выпустить функционал, с помощью которого можно разрабатывать и подгружать в портал свои визуальные компоненты.