Я работаю в «Инфосистемы Джет» около 7 лет, большую часть из которых проектировал и внедрял BI-решения и системы, на них построенные: ситуационные центры, информационно-аналитические системы и всё, что создано, чтобы собирать и анализировать данные. За это время у меня накопился ряд историй и наблюдений на тему особенностей BI-проектов, о которых хотелось бы рассказать.
История 1
Заказчик – крупная территориально распределенная компания. Задача – собирать информацию, формировать отчеты, контрольные панели, а также автоматизировать пару бизнес-процессов. Планировали собрать всё это из решений разных вендоров. Так мы думали до тех пор, пока не явились на установочную встречу.
На ней выяснилось, что от нас требуется реализовать полноценный ситуационный центр с огромным количеством кастомного кода и скрестить порядка 10 вендорских решений, часть из которых уже внедрены. И, что самое неприятное, надо было написать ядро системы с нуля, потому что использовать систему управления метаданными выбранного BI-решения было невозможно. Нам просто не хватало того, что было доступно «из коробки».
Проблема заключалась также в том, что часто требовались довольно сложные отчеты. С этим кое-как удалось справиться штатными функциями вендорских решений. Потом выяснилось, что нужны еще и контрольные панели (дэшборды), причем размером на всю стену (3x9 видеокубов), обновляемые в реальном времени и часто динамической структуры (вылезать за пределы видеостены или предлагать пользователю скроллинг, разумеется, непозволительно).
В этом проекте контрольные панели нам в итоге пришлось реализовать вручную, на чистом HTML/JS, без использования BI-функциональности вендора. Решение оказалось вынужденным, безусловно плохо поддерживаемым. Кстати, именно те наработки дали толчок к созданию нами собственной BI-системы.
Вернемся к видеостене: вся эта красота дополнялась миксом из BI-отчетов, офисных документов, экранов ВКС, ГИС, кусков нашей кастомной функциональности вроде модуля реагирования на инциденты, управления поручениями, дежурной сменой и т.д. Вроде справились и даже начали развивать новое для себя направление – информационно-аналитические системы. Как выяснилось, классический BI-подход к ним далеко не всегда применишь. Как раз об этом будет следующая история.
История 2
Прошли годы, и наконец-то произошел серьезный сдвиг в части требований к BI-платформам. Заказчикам надоело, что BI-решения по сути являются в подавляющем большинстве автономными, оторванными от общей ИТ-инфраструктуры инструментами. Требовались сопряженные между собой НЕмонолитные решения. Никто не хотел «садиться на иглу» одного вендора. Заказчики требовали свободы и потенциальной заменимости одного решения другим.
Рынок осознал, что физически невозможно в одном решении совместить все те функции, которые нужны заказчику, именно с теми возможностями, которые предлагает вендор. В частности, это начали понимать госструктуры, министерства и прочие ведомства. Требовалось что-то, что позволит за приемлемый бюджет и небольшие сроки обеспечить не только визуализацию и анализ данных, но и автоматизацию бизнес-процессов аналитики.
В особенности это коснулось ситуационных центров высших должностных лиц на разных уровнях управления. К ситуационным центрам стали предъявлять всё больше требований. Наличие видеостен и коммутаторов к ним перестало быть достаточным условием. Требовалась серьезная аналитика, которая должна была быть удобной, простой, понятной и, главное – быстрой, поскольку решения в СЦ должны приниматься за секунды. Тогда мы и пришли к выводу, что нужно делать собственную подсистему. Сначала она еще не была отдельным продуктом, не имела названия, но имела четко очерченную функциональность и архитектурные принципы.
Мы провели ряд пилотных проектов в субъектах РФ, шлифуя нашу платформу. Мы объединили BI-функции с функциями автоматизации процессов, не пытаясь охватить все возможные процессы организаций: нашей целью было создание информационно-аналитической системы, задачи которой не в том, чтобы, к примеру, автоматизировать складской учет, а в том, чтобы дать топ-менеджменту и аналитикам инструменты, с помощью которых можно понять, что происходит в организации, что с этим можно сделать, как оценить правильность действий и спрогнозировать, к чему они приведут. И об этом в третьей истории.
Пример дашборда.
Так это выглядит на экране.
История 3
Задача – автоматизация проектов по ремонту сложной, отчасти военной техники и анализ хода исполнения этих проектов. Средняя длительность каждого такого ремонта – 1 год. Использовать MS Project и ему подобные – нельзя. Причем не только по причине импортозамещения, а еще и ввиду того, что объем кастомизации, который требовался заказчику, был слишком велик. В первую очередь это касалось ограничений, валидаций, уникальных бизнес-процессов, да и самой структуры данных.
И снова мы обратились к нашей платформе, добавив к ней еще одну собственную разработку, подсистему управления проектами. Написана она была нами чуть ранее, с нуля, и использовалась в пилотных проектах, но требовала основательной настройки (благо заказчик довольно четко понимал, что именно ему нужно). Отличало эту подсистему то, что благодаря возможностям базовой платформы оказалось на удивление быстро внедрить и растиражировать весь комплекс. От момента постановки задачи до ввода в эксплуатацию прошло 3 месяца. Речь идет не только о самом учете и актуализации планов ремонта, но и об отчетах разного вида, часть из которых, к слову, довольно изощренные.
Например, потребовалось создать так называемую «Производственную диаграмму». Ее цель – мониторить загрузку цехов и выявлять «узкие места». С виду это обычный BI-отчет, в котором сведены в виде дерева и выстроены в единую временную шкалу все активные проекты, каждый из которых – полноценная разворачиваемая диаграмма Ганта. Если кто-то мне подскажет, где найти что-то похожее у «мастодонтов» BI-платформ либо среди OpenSource-компонентов, я пожму ему руку.
Мы проанализировали потребности в визуализации, и с грустью поняли, что нужно писать свой визуализатор. Думаю, ни для кого не секрет, что заказчикам уже давно не интересны стандартные графики и «бублики». Пора признать, что все больше задач требует индивидуального подхода и индивидуальных решений. Безусловно, решения вендоров позволяют наращивать их платформы, но, во-первых, не всегда в нужном объеме, а во-вторых, какими усилиями?
Как быть?
Я считаю, пришло время гибридных решений, которые для простых задач предоставляют понятные и удобные пользовательские интерфейсы, а для более сложных – дают своего рода каркас, или фреймворк, с использованием которого уже реализуется то, что надо, причем без ограничений со стороны вендора. Если только это не архитектурные ограничения (конечно, важность последних неоспорима).
Сделать такую BI-платформу – настоящее искусство, и я не утверждаю, что мы ее уже сделали. Это лишь то, к чему мы стремимся. Если кто-то уже сделал что-то подобное, буду благодарен, если вы поделитесь своим опытом в комментариях к этому посту.
А сейчас я расскажу об архитектуре нашей платформы Jet 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 этот баланс достигнут, что дает уверенность, что наши планы по развитию системы удастся воплотить в жизнь.
Альберт Нурутдинов, архитектор «Инфосистемы Джет»
С предложениями и вопросами обращайтесь на bi_jet@jet.su