Архитектура Modus BI

Поговорим об общем устройстве BI-системы и подробнее остановимся на анатомии BI на примере Modus. Вы узнаете, из каких компонентов состоит аналитический портал, откуда она берет данные и как они превращаются в графики и диаграммы. Поехали!

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

• DWH — хранилище данных
• BI —выводит, визуализирует данные и строит отчеты.
  

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

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

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

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

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

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

Ниже рассмотрим части процесса более подробно.

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

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

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

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

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

• DWH (например, мы работаем с PostgreSQL, Microsoft Sqlserver, ClickHouse, Vertica и т.п.);
• из OLAP-систем по протоколу XMLA;
  
• из файлов – например, xlsx.
  

Аналитический портал может подключаться к различным источникам данных в виде SQL-баз, в которые предварительно помещаются данные.

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

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

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

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

У нас есть self-service механизм, с помощью которого пользователь может вносить данные в аналитический портал.

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

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

У нас это 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.

Зачастую скорость вывода данных зависит не от работы портала, а от скорости их выдачи базой данных DWH. Для маленьких объемов до нескольких миллионов записей не очень важно, какую именно СУБД использовать. Например, у нас обычно и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-файла: можно заранее установить шаблон оформления в корпоративном стиле.

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

• BI-система включает в себя ETL-процессы, DWH и непосредственно саму аналитическую платформу, которая может быть в виде десктоп-клиента или web-портала.
• Данные для BI должны быть подготовлены: нормализованы и очищены, иначе вы получите кривую аналитику. Для этого удобно использовать ETL-инструменты.
  
• В качестве источника данных для аналитической платформы используются хранилища данных (DWH) и OLAP-системы. В качестве исключения могут использоваться неструктурированные данные, в том числе Excel-файлы.
  
• Скорость работы BI зависит, помимо прочего, от выбранной СУБД (DWH) и ее архитектуры.
  
• Кроме визуализации данных у BI-систем есть широкий список функций для работы с данными: настройка ролей доступа пользователей, в том числе и на уровне строк данных (RLS), встраивание в другие сервисы, хранение и редактирование данных, фильтрация, экспорт дашбордов и т.п.
  

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

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