Привет, Хабр! Это вторая и последняя статья из цикла «Архитектура аналитической платформы». Поговорим об общем устройстве BI-системы и подробнее остановимся на анатомии Modus BI.  В классическом DW/BI есть несколько составляющих: ETL — система управления данными; DWH — хранилище данных; BI — платформа, которая выводит, визуализирует данные и строит отчеты.  BI по формату клиентской части делится на 3 вида: desktop-клиент – приложение аналитической системы устанавливается на компьютер пользователя; портал – аналитическая система выводится на web-приложение; мобильное приложение – обычно используется для оперативной работы с аналитической системой на мобильном устройстве.   Мы в Modus используем web-портал и считаем, что это более современное решение.  Если очень упростить работу 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-запросы в набор данных, его описание возвращается в виде полей, которые мы можем определить синонимами, переименовывать или изменять их типы. Затем эти поля будут использованы для конфигурации дашбордов.  Чтобы ускорить взаимодействие и получение данных в наш портал интегрированы различные драйверы для работы с СУБД. Когда пользователь работает самостоятельно и не может загружать данные в 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.  Кроме того, системы постоянно развиваются и «обрастают» дополнительным функционалом. Например, мы в этом году планируем выпустить функционал, с помощью которого можно разрабатывать и подгружать в портал свои визуальные компоненты.  Product Owner