В прошлом посте я рассказал об эволюции систем BI и о том, как мы пришли к пониманию, что лучше создать свою платформу, чем приспосабливаться к существующим.
Сегодня, как и обещал, рассказываю об архитектуре нашей новой платформы, которая станет, надеюсь, удачным решением для построения любых BI-систем.
Функциональная архитектура
В системе функционально можно выделить два основных «Ядра».
Ядро визуализации и BI (мы с командой называем его «считалка»). Оно занимается тем, что фильтрует данные, вычисляет факты и измерения, обсчитывает и кеширует агрегаты, и т.д. В целом — самый обыкновенный OLAP. Поддержка вычислений в памяти также имеется. Отдельное место занимает разработанный нами ETL-движок с поддержкой как стандартных способов загрузки (например, SQL, MongoDB запрос, выгрузка из файлов Excel и т.д.), так и загрузки посредством JS-скриптов чего угодно откуда угодно. Как именно? Дело в том, что JS-загрузчик мы «обвязали» специальным API, цель которого — предоставить набор простых в освоении методов, наиболее востребованных для запросов в разные источники, а также трансформации данных (например, транспонирования, объединения, добавления вычисляемых колонок, разного рода математических и статистических функций).
Язык
Javascript? Вы с ума сошли?
Возможно…
Но выбор в качестве языка именно JS и отказ от изобретения еще одного велосипеда, как это часто бывает в BI-платформах, не случаен. Популярность языка сама по себе, простота его освоения (по крайней мере для задач ETL) и большое количество специалистов на рынке оказались для нас решающими факторами. В целом, согласно идеологии нашей платформы, ETL-движок похож на механизм «скриптов загрузки», используемых, к примеру, в QlikView, за исключением языка, на котором эти скрипты пишутся. Я надеюсь, что многие вендоры BI-платформ рано или поздно придут к универсальному языку программирования, но пока работаем с тем, что есть.
Ядро бизнес-логики. Это скорее фреймворк, закрепляющий программную архитектуру и предоставляющий ряд универсальных API, с помощью которых можно добавлять в систему дополнительные прикладные информационно-аналитические компоненты.
Из того, что у нас есть уже сейчас, можно отметить:
- Конструктор и обработчик форм ввода данных
- Среда моделирования и анализа «Что если»
- Система управления поручениями
- Хранилище электронных документов
- Модуль управления проектами и программами проектов
Хотелось бы подчеркнуть, что эти компоненты присутствуют в системе не просто так и не живут своей жизнью. Они тесно связаны как друг с другом, так и непосредственно с системой визуализации и отчетности. По сути они становятся либо поставщиками, либо потребителями данных для нее. К примеру, из системы управления поручениями можно примерно за полчаса-час с нуля составить несложный отчет, отображающий статусы по всем поручениям и список самых злостных лентяев. А из модуля проектного управления вытащить данные по наиболее «пробуксовывающим» проектам и выявить причину отставаний.
Техническая архитектура
Бэкенд приложения работает под управлением Node.JS с вкраплением ряда критичных (с точки зрения производительности) нативных компонент. Как любое Node.JS приложение, система может быть кластеризована, контейнеризована и развернута в любой среде, соответствующей требованиям Node.
Для хранения метаданных можно использовать большинство из популярных реляционных СУБД, мы чаще всего разворачиваем на PostgreSQL. В базе данных хранится вся метаинформация об отчетах, контрольных панелях, ETL-процессах, дополнительных модулях и т.д. Систему можно использовать в том числе как инструмент для наполнения стороннего хранилища данных. Для небольших объемов данных можно организовать визуализацию в режиме ROLAP, то есть напрямую из систем-источников. Также присутствует что-то вроде «ассоциативной модели» QlikView. Если выбрать в качестве источника данных для визуализатора два или более наборов данных, то произойдет их объединение по названиям столбцов в единый набор.
Фронтенд — это классический SPA на React, сопутствующие библиотеки и дополнительные модули самого JET BI. Общение с бэкендом происходит посредством самого обычного REST, часть кода является изоморфной, то есть используется и фронтом, и бэком. Весь код — ES7 с аннотациями типов (Flow), прогоняемый через Babel. Мы отказались от Typescript в пользу Flow, поскольку, когда мы только начинали, последний выводил типы чуть лучше.
Довольно часто (примерно в 80% случаев) мы берем готовые open-source модули и не изобретаем свои (в бэкенде чуть пореже). Это упрощает и удешевляет разработку и поддержку, но несколько уменьшает гибкость. Случались и просчеты, после которых часть библиотек все же в конечном итоге пришлось переписать на собственные.
Заключение
В конце хотелось бы сказать, что меня, как архитектора, радует, что «каркас» системы получился довольно прочным и устойчивым с одной стороны, а с другой — универсальным и обладающим достаточным запасом гибкости (несмотря на обилие вышеупомянутых open-source библиотек). Это как новогодняя елка, на которую мы постоянно развешиваем новые игрушки. Ведь елка должна выдержать игрушки самых разных сортов и мастей, и при этом не упасть под их тяжестью. На мой взгляд, в JET BI этот баланс достигнут, что дает уверенность, что наши планы по развитию системы удастся воплотить в жизнь.
Альберт Нурутдинов, архитектор «Инфосистемы Джет»
Автор: JetHabr
