Как менялся рынок BI и почему мы решили создать свою Business Intelligence платформу



    Я работаю в «Инфосистемы Джет» около 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 этот баланс достигнут, что дает уверенность, что наши планы по развитию системы удастся воплотить в жизнь.

    Альберт Нурутдинов, архитектор «Инфосистемы Джет»
    Инфосистемы Джет
    Системный интегратор

    Комментарии 16

      +1

      Доброго дня. Честно больше похоже на рекламу. Если же предметно:


      1. Спрос на коробочные bi решения ни куда не снижается, а скорее наоборот растет. А так же обычные диаграммы, бублики так же востребованы. Скажу так, что нужно «уметь готовить» в решениях мастодонтов bi. Очевидный минус это не много компаний могут себе позволить комплексное решение от вендора.
      2. Разработав свою систему bi и начав ее продавать вы лишь добавляете новый продукт в линейке со своими архитектурными ограничениями. А так же с ограничениями в разработке визуализаций.
      3. Реализовать универсальный инструмент bi который из коробки удовлетворит все потребности заказчика без участия разработчиков и напильника это утопия. Всегда найдется кейс графика под который у вас нет или он не подходит по каким либо причинам.
      4. Для меня лично сформировалось виденье, что не нужно стремится строить всеобъемлющий универсальный инструмент включающий в себя все и вся, как не смотри это будет коробка ограниченная виденьем архитектора, а так же писать каждый раз реализацию с нуля трудозатратно, дорого. Ключевой направление это все же работа с данными без привязки к системам визуализации, универсальное, понятное хранилище и легко поддерживаемый транспорт. А от инструментов бизнеса требуется легкость интеграции с этим данными. А так же предопределенный набор шаблонов. То есть в хранилище должны быть данные без всяких крутых инструментов понятные бизнесу, пусть хоть в экселе смотрят если нужно. Новые источники данных легко добавляются. А инструменты визуализации так же легко «насаживаются» на эти данные и несколькими кликами мы получаем например аналитические панели. Или график загрузки цехов.
        Итого, нужно как всегда подготовить данные, а дальше подготовить библиотеку кейсов с шаблонами и каждый уважаемый себя бизнес мог легко выбрать из библиотеки свою панель для анализа.:)
        +1
        Борис, спасибо за обстоятельный комментарий, со многими пунктами согласен, правда, с некоторыми оговорками.
        «Спрос на коробочные bi решения ни куда не снижается, а скорее наоборот растет.»

        Разумеется растет, как и в целом растет рынок. Я ни коим образом не умаляю востребованность вендорских решений. Для многих компаний и задач их будет более чем достаточно. Однако когда речь идет о комплексном решении, где вдобавок порой нужно еще реализовать то, что никто из BI-вендоров для лишь одного заказчика добавлять не будет, возникают проблемы. Главная — ничего с этим не поделаешь, ибо если мы отбрасываем opensource, то свободного пространства для кастомизации у заказчика (и даже, к сожалению, у внедренца) практически нет. Если же opensource нас больше не пугает, то с высокой вероятностью на первом же повороте врезаемся в риск под леденящим душу названием «поддержка».

        «А так же обычные диаграммы, бублики так же востребованы.»

        Не совсем… Вернее, если смотреть на это лишь как на инструмент визуализации, а не анализа, то вы правы. Даже приведенный мной в статье дэшборд это иллюстрирует, там чистая классика. Однако суть была не в этом. Есть инструменты визуализации, которые позволяют гораздо быстрее понять, что не так (или, наоборот, что все идет как надо). Они интерактивные, интуитивные, и, главное (тут можно смахнуть скупую слезу) — кастомные. Их нет в «коробке», и чтобы их добавить, недостаточно знать, как устроена коробка. Вендор имеет свой «roadmap» и в большинстве случаев один заказчик с каким-то (по мнению вендора) экзотическим требованием) в расчет не берется. И не только мы, как внедренцы, сталкиваемся с этой проблемой, уверен, вы тоже, с высокой долей вероятности, «упирались» в ограничения платформенных решений.

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

        Не согласен. Архитектурные ограничения — это всегда хорошо, иначе все рано или поздно развалится. Я планирую описать архитектуру в следующем посте здесь же на хабре, там уже будет удобно поговорить по «конкретике», пока предлагаю поставить этот вопрос «на паузу».

        «Реализовать универсальный инструмент bi, который из коробки удовлетворит все потребности заказчика без участия разработчиков и напильника это утопия. Всегда найдется кейс графика под который у вас нет или он не подходит по каким либо причинам.»

        А здесь согласен. Однако, мы — системный интегратор и автоматизируем бизнес-процессы, у нас много «напильников», но мы, с одной стороны, не хотим их коллекционировать, а, с другой, обязаны довести проект до успешного завершения. А бывают проекты, как говорится, «типовые». У нас так и получилось — фреймворк, куда можно добавлять новые функции. Для типовых задач — типовые инструменты, для нетиповых — добавление новых модулей.

        «Для меня лично сформировалось виденье, что не нужно стремится строить всеобъемлющий универсальный инструмент, включающий в себя все и вся, как не смотри — это будет коробка, ограниченная виденьем архитектора».

        Мы, собственно, и не пытаемся сделать монолит, я бы сказал, напротив, все дополнительные компоненты имеют архитектурно слабую связанность и легко подключаются и отключаются, как детали в конструкторе. Однако после подключения легко настроить потоки данных от них к BI-ядру. Часть этих потоков доступна из коробки, часть конфигурируется под конкретные задачи в рамках создания отчетов либо контрольных панелей. Хранилище — тоже не «черный ящик» (в отличие от некоторых BI-систем, на которые я не буду показывать пальцем), а вполне стандартная OLAP-схема с понятной структурой, к которой, разумеется, можно подключить тот же excel. Я вообще в целом по 4-му пункту не вижу никаких архитектурных противоречий, если уточните, при прочтении какой части статьи у вас оно возникло, дайте знать. Хорошего дня :)
        0

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

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

          На мой взгляд вы почему-то решили, что ситуационный центр и мониторинг можно назвать BI системой.
          Ещё интересно посмотреть на ваше дерево с Гантом — из описания мало что понятно.
          Интересно чего вам не хватило в функционале лидеров BI рынка для написания кастомного визуала?

            +1
            Добрый день. Не совсем так. BI-модуль (в классическом его понимании) у нас в проектах ситуационных центров с точки зрения целевого пользователя — одна из подсистем. Если Вы в теме СЦ, то, наверняка, понимаете специфику. Касаемо Ганта, спасибо за идею, попробуем добавить пару скринов в статью. А вот последний вопрос тянет на отдельную статью — если вкратце — много чего не хватило, как с точки зрения функциональных возможностей, так и в плане внешнего вида. В статье про архитектуру постараюсь коснуться и этого вопроса тоже.
              0

              Спасибо за ответ. Интересно будеть почитать о функциональных ограничениях и внешнем виде. Если будет возможность, то хотелось бы увидеть сравнение с Tableau Extensions и Power BI Custom Visuals (или с аналогичными решениями от qlik, yellowfin и т.п.)

            +1
            А чем был плох Apache Superset в качестве базы для дальнейших разработок? Вообще анализа существующих решений не приведено, нет информации об используемом стеке технологий. Есть лишь «Мы — Ух! Три месяца и в продакшн! При наличии денег у заказчика любая фирма будет согласна писать для них что угодно, включая BI.
              +1
              Все верно, это лишь первая часть, больше общая информация, без погружения в технические детали. Про архитектуру и технологии — чуть позже. Там уже предлагаю обсуждать детально технические аспекты и архитектурные решения. Если интересно — добавляйте в закладки, чтобы не пропустить. :)
                +1
                И да, касаемо Superset добавлю — мы его рассматривали и действительно детально изучали. Это интересно и, вероятно, имеет некий потенциал, но, на наш взгляд — на сегодня это довольно рискованно, полагаю, не нужно объяснять — почему. Надо подождать пару лет, дальше посмотрим.
                  +2

                  А можете чуть подробнее описать риски superset? К сожалению, мне недостаточно очевидно =(

                    +2
                    Основные причины — проекту чуть более 3-х лет, он до сих пор в инкубаторе Apache и еще не одобрен ASF, он при тестировании показался нам сыроватым, плюс заметно отсутствие, скажем так, целостности решения. Даже если взглянуть на код фронтэнда — половина на ts, половина на js (причем без аннотаций типов). Как что-то добавить не форкая проект — непонятно, фиксить что-то есс-но только через пулл реквесты, что долго. Всегда есть риск, что при обновлении версии что-то упадет, что добавляет нашим тестировщикам работы, а ПМ-ам и архитекторам — сложности в планировании проектов. Какой-то четкой дорожной карты у них я не нашел, когда и что они решат добавить или изменить — неясно. И все бы ничего, если бы это был набор небольших библиотек, но superset позиционируется как «fully fledged web BI applicaton». В общем, нам показалось, что его в качестве платформы использовать не получится. Только если брать и использовать «как есть», для довольно узкого круга задач.
                +2

                Кстати стоимость вашего решения где можно увидеть?:)

                  0
                  Цена сильно зависит от масштаба предприятия, набора задач, специфики процессов. Напишите на почту, расскажите, что вам нужно, и мы сделаем прогноз: bi_jet@jet.su
                  0
                  Читаем вторую часть здесь: habr.com/ru/company/jetinfosystems/blog/490186

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое