Многие отечественные компании стоят сегодня перед проблемой выбора [1] российской платформы бизнес-аналитики как для выполнения новых проектов, так и замены уже имеющихся решений на базе платформ от Qlik, Tableau, Microsoft Power BI, Oracle BI и др. Ни одна из российских платформ пока еще не позволяет полностью заменить всю функциональность западных решений. Как найти отличия между двумя десятками присутствующих сегодня на отечественном рынке платформ бизнес-аналитики и выбрать наиболее подходящее решение?

Использование бизнес-аналитики продиктовано стремлением руководителей принимать решения на основе данных, и если в компании уже выстроена практика бизнес-анализа на базе какой-либо платформы, то лицам, принимающим решения, неважно, что «под капотом» у соответствующей системы, главное — результат. Если же речь идет о миграции, вызванной прекращением поддержки платформы, то, конечно, важно при минимальных трудозатратах сохранить работоспособность системы бизнес-аналитик. Для организаций, в которых только формируется практика бизнес-анализа — еще немало аналитиков продолжают работать с диаграммами в Excel [2], важно минимизировать затраты на внедрение новой системы и быстро получить результат, например в виде монетизации данных [3].

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

Запросы

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

Наибольшие сложности миграции возникают, если приходится полностью пересматривать всю архитектуру системы. Например, одни инструменты отправляют аналитические запросы на сторону СУБД — Superset, Metabase и Mondrian, а другие используют собственный аналитический движок, позволяющий забирать данные из хранилищ и сразу их обрабатывать на своем уровне либо на уровне Microsoft Power BI, Qlik, Tableau и пр. Наличие в платформе собственного движка имеет ряд преимуществ:

  • высокая производительность — чем сложнее запрос, тем медленнее его будет обрабатывать внешняя СУБД;
  • независимость от источников данных;
  • возможность оптимизации аналитических запросов;

создание интерактивных средств работы для аналитиков за счет более гибкого управления моделью данных и витринами.

Если в платформе нет собственного движка, то запросы исполняются либо непосредственно на источниках данных, либо на уровне корпоративного хранилища и при миграции на подобную платформу могут возникнуть дополнительные сложности. С одной стороны, на растущих объемах данных перенос логики на уровень хранения может привести к значительному снижению производительности платформы бизнес-аналитики и ограничить простор для маневра при кратном росте объемов анализируемых данных. С другой, отсутствие собственного движка означает при миграции необходимость переписывания логики запросов. Часто «под капотом» у такой платформы оказывается не изящная аналитическая формула, а сложный SQL-запрос, учитывающий специфику конкретной СУБД: Oracle, PostgreSQL, MySQL, Microsoft SQL Server и пр.

Конечно, если задачи миграции берет на себя системный интегратор или разработчик аналитической платформы, проблем можно поначалу избежать — подрядчик перепишет все запросы и поможет запустить новую платформу. Однако работать с подобной экосистемой будет сложно — каждый новый запрос и каждое очередное уточнение потребуется снова переводить на язык SQL или отображать в программном коде. Именно поэтому при разработке движка третьей версии Visiology изначально обеспечивалась поддержка аналитического языка DAX, что, как минимум, позволяет просто скопировать формулы из Power BI [2].

Работа с хранилищем данных

Важный аспект развертывания системы бизнес-аналитики — организация работы с корпоративным хранилищем данных. Если у платформы нет своего движка, то архитектура хранилища будет определяться особенностями конкретной эксплуатации (редкие запросы над большими объемами, частые запросы, работа большого количества пользователей, подключение различных источников данных, особенности фильтрации, выборки данных по различным критериям и т. п.) и потребуется тщательная оптимизация СУБД, а значит — дополнительные ресурсы. Проект миграции может затянуться, а его стоимость — вырасти за счет дополнительных лицензий, которые могут потребоваться при развертывании хранилища данных.

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

Tableau

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

Tableau часто используется как система визуализации, подключенная к внешнему хранилищу данных, позволяя работать как в режиме extract (c перезагрузкой данных в собственное хранилище и обработкой данных движком Tableau), так и в режиме live с трансляцией запросов через SQL и исполнением на СУБД.

Если архитектура системы бизнес-аналитики предусматривает работу с внешним хранилищем и коннектором extract, то возможна миграция на Visiology с обработкой в памяти. Если система работала в режиме live, то кроме перехода на Visiology 2.30 пользователь получает инструмент SQL Backend, с помощью которого можно подключить платформу к хранилищам на базе таких СУБД, как PostgreSQL, MySQL, OracleDB и ClickHouse. Таким образом, для большинства приложений можно перенести визуализацию с минимальными изменениями в текущей ИТ-инфраструктуре, однако придется перерабатывать сами витрины данных.

Версия Visiology 2.30 пока не позволяет добиться таких же расширенных возможностей самообслуживания, как в Tableau, однако подобный функционал будет доступен в версии 3.0 — инструменты подготовки витрин, виджетов и формул бизнес-аналитики. Тем не менее ряд российских компаний (например, «СберМегаМаркет») мигрировали на платформу Visiology, решив задачи подготовки отчетности и аналитики, попутно снизив затраты на сопровождение решения.

 

Qlik

В России были относительно популярны решения экосистемы Qlik, например Qlik Sense — гибкий инструмент визуализации с расширенными возможностями самообслуживания, который может применяться на базе существующего хранилища данных как отдельное средство визуализации и как инструмент хранения таблиц с данными в собственном проприетарном формате QVD (QlikView Data). Архитекторы Qlik потратили много сил на оптимизацию этого формата, позволяющего компактно хранить информацию — например, файлы в нем занимают меньше места, чем в формате csv или в таких внешних СУБД, как PostgreSQL или MySQL. Кроме этого обеспечивается быстрая загрузка QVD-файлов в любое приложение экосистемы Qlik, что позволяет работать без внешнего хранилища. В этом смысле архитектура Qlik похожа на архитектуру Visiology, где предусмотрена оптимизация данных на уровне движка, а начиная с версии 3.0 — оптимизация под СУБД ClickHouse.

Вместе с тем в большинстве проектов с Qlik для работы с данными используется собственный внутренний движок этой платформы, что таит в себе подводные камни. Одна из возможностей Qlik — наличие языка скриптов QLS (Qlik Load Script) для поддержки загрузки данных, позволяющего не только забирать данные из различных источников, но и преобразовывать их: объединять таблицы, создавать новые поля в таблицах, выполнять сложные расчеты и пр. Однако чем дольше и глубже в компании использовались возможности QLS, тем сложнее будет замена Qlik на любую российскую платформу бизнес-аналитики — перенести накопленные наработки по загрузке данных не получится и их в любом случае придется создавать заново.

Тем не менее на отечественном рынке появились готовые решения для упрощения сложных миграций с Qlik, например, компания BI2BUSINESS предложила универсальный подход для развертывания накопленной в текстах QLS экспертизы на альтернативных платформах, протестировав связку Loginom, СУБД PostgreSQL, Visiology и подтвердив возможность создания качественного аналога.

Итого

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

Проектов миграции систем бизнес-аналитики сегодня много, а их выполнение облегчается благодаря наличию в Visiology поддержки обработки в памяти (in-vemory), средств прямого подключения к внешним СУБД, среды визуализации и уже накопленному опыту применения платформы в различных отраслях. Например, только за 2022 год 200 компаний мигрировали на Visiology.

Движение по пути миграции, например, на платформу Visiology 3 можно осуществлять по двум направлениям. Компании, у которых еще действуют лицензии на текущую платформу, могут развертывать у себя Visiology 3, конструировать первые витрины, знакомиться с системой и постепенно переносить свою экспертизу, используя средства самообслуживания, графический редактор модели данных и поддержку формул DAX. Компании, вынужденные срочно мигрировать, могут вести проекты на платформе Visiology 2 — можно продолжать работу с системой бизнес-аналитики, а при соблюдении рекомендаций по работе с данными впоследствии перейти на третью версию.

Power BI

Microsoft Power BI — наиболее распространенная в России платформа: доступность в составе пакета Office 365, изобилие материалов и обширное сообщество. Однако сейчас работа с этой платформой возможна лишь в настольной версии или локальной серверной.

Миграция на Visiology 3 упростилась благодаря поддержке языка запросов DAX, хорошо знакомого большинству бизнес-аналитиков, — пользователь может непосредственно взять формулу из Power BI и вставить ее в соответствующую графу Visiology 3. Создание модели данных также происходит достаточно просто — с помощью графического редактора TOM (Tabular Object Model) можно установить связи между таблицами данных, перетягивая их одну на другую.

Oracle и SAP

Компании Oracle и SAP предлагают в своих пакетах как СУБД и бизнес-системы, так и собственные движки бизнес-аналитики, поэтому миграция экспертизы бизнес-аналитики с этих платформ на российские решения может оказаться весьма трудоемкой.

В отличие от Qlik или Power BI нельзя перенести даже часть экспертизы SAP BI или Oracle BI — в их основе заложены собственные архитектурные принципы. Кроме того, компании, заменяющие решения бизнес-аналитики на базе этих платформ, чаще всего вынуждены решать проблему полного перехода на альтернативные системы других поставщиков. Как правило, внедрение таких систем следует выполнять после переноса основных бизнес-процессов, например, на 1C. В этом случае можно использовать как внешнее хранилище данных, так и уже работающий с Visiology коннектор 1С ATK BIView автоматической генерации модели данных из 1С для ее использования в различных системах бизнес-аналитики: QlikView/Qlik Sense, Tableau, Power BI и пр.

Однако в Visiology имеются средства работы с внешними СУБД, включая и Oracle. Например, можно включить специальный режим работы движка SQL Backend, позволяющий напрямую обращаться за данными во внешнюю СУБД. Благодаря этому новые проекты бизнес-аналитики на российской платформе можно выполнять, используя данные, уже накопленные в той или иной СУБД.

***

Сегодня у российских заказчиков уже имеется большой выбор инструментов бизнес-аналитики — в 2022 году специалисты BIConsult насчитали 20 отечественных платформ, и их число растет. Интерфейсы некоторых из этих инструментов напоминают интерфейсы ушедших с рынка Qlik или Tableau, но при выборе системы и принятии решения о миграции важно оценить не только «внешность», но и начинку.

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

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

Литература

1. Сергей Шестаков, Александр Тютюнник. Системы бизнес-аналитики: проблема выбора // Открытые системы.СУБД. — 2021. — № 4. — С. 34–36. URL: https://www.osp.ru/os/2021/04/13056077 (дата обращения: 21.03.2023).

2. Иван Вахмянин. Excel vs бизнес-аналитика // Открытые системы.СУБД. — 2020. — № 1. — С. 28–29. URL: https://www.osp.ru/os/2020/01/13055349 (дата обращения: 21.03.2023).

3. Роман Раевский. Непрерывная бизнес-аналитика: как монетизировать данные // Открытые системы.СУБД. — 2020. — № 4. — С. 30–33. URL: https://www.osp.ru/os/2020/04/13055706 (дата обращения: 22.03.2023).

Алексей Никитин (nikitin@visiology.com) – генеральный директор, компания Visiology (Москва). Статья подготовлена на основе материалов выступления на конференции «Качество данных 2023».