В июне 2024 года на конференции Tableau Conference было представлено новое решение Shared Dimensions (общие размерности), которое евангелисты компании объявили самым важнейшим с момента выхода системы бизнес-аналитики на рынок в 2005 году [1]. Характерно, что при этом вообще не упоминается о только что прошедшем «вживлении» механизмов ИИ в продукт, что свидетельствует о важности именно технологии Shared Dimensions для компании.

Речь в Shared Dimensions идет об объединении разнородных источников данных. К стандартным механизмам JOIN добавляются виртуальные размерности MULTIFACT, которые могут по-разному агрегировать факты, если одно и то же поле присутствует в источниках разной гранулярности. За счет искусственного построения таких общих размерностей при создании модели данных почти решается основная проблема практически любого проекта бизнес-аналитики — объединение разнородных источников без «цифрового взрыва» данных. На конференции возможности Shared Dimensions демонстрировались при работе с объемами данных в десятки и сотни тысяч записей.

Почему «почти» решается? У общих размерностей Tableau имеется ряд недостатков (ограничение по объему данных, статическая модель, невозможность отмены операции без удаления схемы данных; и пр.), обусловленных архитектурой движка.

Некоторые термины

Главное предназначение системы бизнес-аналитики, помимо визуализации, — выполнение расчетов над данными: суммирование, фильтрация, подсчет количества уникальных элементов поля, агрегирование в различных разрезах и т. д. Для выполнения расчетов система должна хранить результаты вычислений и исходные данные из источников либо знать местоположение данных [2].

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

Хранилище BI-системы — это место размещения данных источников и результатов вычислений. Если данные хранятся внутри BI-системы в ее собственном формате, то у BI-системы есть свое хранилище. Собственного хранилища у системы может и не быть, но может иметься расчетный движок.

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

Оптимизатор SQL-запросов — программа для ускорения выполнения и упрощения SQL-запросов для конкретной СУБД. В 1997 году компания Sybase в рамках своей флагманской СУБД Sybase Adaptive Server Enterprise впервые в отрасли выпустила оптимизатор SQL-запросов, который затем перешел в Microsoft SQL Server, а потом практически во все промышленные СУБД.

Движки и технологии бизнес-аналитики

Чем друг от друга отличаются продукты из квадрантов Gartner? Собственными движками (engine), которые по-разному работают с данными, предоставляя пользователям различные возможности, а также интерфейсами (UI) и способами взаимодействия с пользователем (UX), которые, безусловно, важны, но вторичны, потому что созданы на основе движка и предназначены для максимально выгодной демонстрации его преимуществ. Более того, часто при выходе очередных версий продукта движок не меняется, а переделываются лишь UI и UX.

Для сохранения конкурентоспособности системы бизнес-аналитики требуется постоянное развитие движка. Например, совсем недавно ведущие игроки дружно заявляли о вживлении искусственного интеллекта в свои продукты, однако после игр с ChatGPT эйфория прошла, а проблемы с ИИ остались — например, в видеоуроках одного из крупнейших поставщиков аналитических систем Palantir половину времени сегодня занимает обсуждение вопросов борьбы с «галлюцинациями» ChatGPT, искажающими ответы ИИ или делающими их бессмысленными. Как оказалось, такие галлюцинации проявляются в более чем половине случаев. Обычно так происходит, когда технологию используют далеко за границами ее применимости — аналитические запросы так называются именно потому, что не похожи на типовые, обычно не повторяют предшествующие и требуют 100% точности ответов [3, 4].

В отличие от пузыря ИИ, на протяжении пары лет надуваемого усилиями аппаратных вендоров, тема упрощения работы с многочисленными разрозненными источниками данных актуальна еще с 2010-х годов — ведущие поставщики (Tableau Prep, Qlik Talend, Power Query и пр.) развивали и активно продолжают развивать средства ETL или соответствующие возможности в своих решениях, предназначенных для self-service ETL. Вероятно и сейчас, вслед за анонсом Tableau технологии Shared Dimensions, другие игроки вскоре объявят об аналогичных инструментах объединения источников различной гранулярности.

В условиях технологических ограничений развитие продуктов бизнес-аналитики на российском рынке идет собственным путем — далеко не каждый производитель имеет возможность инвестировать в развитие собственных движков. Как следствие, наметилась, в частности, тенденция переноса акцента с движка на оптимизатор SQL-запросов, как правило, к СУБД ClickHouse, а также на интерпретатор некоторых DAX-команд в SQL. Самая по себе задача трансляции DAX-команд в SQL весьма наукоемкая, но вторична по сравнению с развитием синтаксиса DAX внутри родной для него экосистемы Microsoft, включающей Power BI и Analysis Services. Переходя на расчеты c помощью SQL-запросов в ClickHouse, вместо создания своих движков, отличающих функциональностью продукта от конкурентов, российские вендоры направляют свои ресурсы на оптимизацию ClickHouse, интерпретацию синтаксиса DAX, копирование интерфейсов западных продуктов либо адаптацию открытых решений под отечественный рынок [5].

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

Спрос и стагнация предложений

Вместе с ростом объемов и разнообразия данных в конкурентных видах бизнеса возрастает и потребность в оперативном анализе данных. Многие компании в этой ситуации не придумали ничего лучше, как создавать свои продукты, технологически ничем не отличающиеся от уже имеющихся на рынке, но гораздо оперативнее реагирующие на собственные потребности. Ситуацию «раскачивает» и государство, поощряя крупный бизнес выделять свои ИТ-структуры в отдельные компании для получения различных преференций. Вот и получается, что каждую неделю на рынке появляется несколько новых российских систем бизнес-аналитики. При этом их технологический стек можно угадать заранее — в качестве расчетного движка и хранилища будет СУБД ClickHouse, визуализация — Apache SuperSet или Yandex Datalens, а для преобразования пользовательских функций в SQL будет использован один из фреймворков на Node.js или Python.

На первый взгляд кажется, что у крупного бизнеса после отказа от продуктов SAP, Oracle и др. нет технологической альтернативы для анализа характерных для него объемов данных (от десятков миллиардов строк), кроме как SQL-запросы к ClickHouse, и программирования в Python и JavaScript либо в своей платформе, либо в покупной, но так ли это?

Стратегия развития, независимая от политики

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

Хорошей проверкой реальной конкурентоспособности любого, в данном случае российского, продукта может быть его виртуальное перемещение на рынки, где западные продукты присутствуют без ограничений. Как российский интерфейсный «аналог» Qlik, у которого расчеты происходят на ClickHouse, будет конкурировать с настоящим Qlik и его ассоциативным движком? Что будет делать продукт с транслятором DAX в плоские SQL-запросы, когда заказчикам станет доступен бесплатный оригинал DAX в виде многомерных продуктов от Microsoft? Таких рынков много — страны СНГ, Ближнего Востока, Азии и Латинской Америки — и на них востребованы многие российские технологии (Telegram, антивирусы, банковские продукты, системы машинного зрения и пр.), но не слышно о BI-продуктах.

Нужно не догонять и копировать, а перегонять, находя новые пути — или размерности в многомерном пространстве возможностей. Не бояться искать и разрабатывать перспективные способы обработки данных, предоставляющие заказчикам неоспоримые преимущества. Только так можно найти заказчиков, которые не откажутся от российских продуктов даже при появлении на рынке серьезных конкурентов.

Именно таким путем пошла, например, компания Rapeed, разработав технологию многомерного распределенного хранения и обработки данных в оперативной памяти (Distributed OLAP, DOLAP). Неотъемлемое свойство DOLAP — простые и универсальные средства связывания полей разрозненных источников данных.

Плюсы российской технологии

При проектировании Rapeed изначально не ставилась задача повторить какой-либо западный продукт или технологию, что вылилось в технологические преимущества.

Shared Dimensions в Tableau подразумевают создание модели данных, то есть статической конструкции, а в Rapeed связывание полей — изначально динамическая операция, причем в каждом рабочем пространстве у пользователя может быть свой набор связанных полей.

Нельзя отменить Shared Dimensions, потому что для этого надо удалить схему данных, а в Rapeed можно связать и развязать поля (рис. 1).

Перегнать, не догоняя
Рис. 1. Связывание полей разных источников в Rapeed. Сводная таблица сразу же показывает информацию из только что связанных источников

Создание Shared Dimension — это материальная операция (требующая создания материального объекта, например записей на жестком диске) создания особой структуры в данных, что для монолитного движка Tableau вынужденное исключение из правил, специально необходимое для решения конкретной задачи объединения разнородных источников данных. Поскольку у Rapeed распределенный DOLAP-движок, то для него связывание полей — это естественная операция, не требующая дополнительной материализации данных.

Имеется еще ряд других технологических нюансов и особенностей реализации Rapeed: простота использования (визуальное перемещение одного поля на другое), универсальность (можно связывать источники любой природы), неограниченное количество связей, работа на любых объемах данных (десятки и сотни миллиардов строк) и др.

Другой продукт ушедшей с российского рынка компании Qlik известен своим ассоциативным движком, замену которому корпоративные заказчики, купившие десятки тысяч лицензий, вот уже два года найти не могут. DOLAP-движок Rapeed не просто повторяет Qlik, а делает шаг вперед — заказчики с сотнями миллиардов записей и десятками тысяч пользователей иногда называют Rapeed 'Qlik++', подразумевая, что ядро системы написано на Си++, при этом логика работы механизмов Data Discovery в российском продукте похожа на работу движка Qlik, предоставляя больше возможностей. Например, супервиджет «Область связей» позволяет визуально находить связи между элементами одного поля через промежуточные источники данных, в частности, отображать цепочки платежей или выявлять бенефициаров (рис. 2).

Перегнать, не догоняя
Рис. 2. Область связей в Rapeed — визуальное выявление связей плательщиков и получателей платежей

Обеспечение непрерывной аналитики бизнес-процессов

В [4] описан процесс работы с данными разной гранулярности, вложенности и детализации, которую обычно выполняют «гражданские» бизнес-аналитики, а также предлагалась технология области связей («Карта Связей») динамического связывания полей и работы с разнородными источниками данных в предположении, что все данные — это единое динамически развивающееся целое. Сегодня продукт Rapeed представляет собой средство онлайн-работы с неограниченными объемами данных, причем, в отличие от Power BI, Qlik и Tableau, пользователям не требуются знания SQL, понимание структуры и совместимости данных разной гранулярности, а необходимо лишь знакомство с Excel. Непрерывность аналитического процесса заключается в том, что можно сразу анализировать данные в их любом состоянии, а затем бесконечно улучшать их качество, объединяя — разъединяя — сравнивая с другими данными в любых разрезах. Условно можно назвать этот процесс «игрой в данные» (dataplay) — именно так и должна выглядеть работа бизнес-аналитика.

***

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

Литература

1. Ken Flerlage, Kirk Munroe: New in Tableau 2024.2 — Shared Dimensions. The Flerlage Twins, 2024. https://www.flerlagetwins.com/2024/06/blog-post.html (дата обращения: 22.09.2024).

2. Валерий Артемьев. Business Intelligence — двадцать лет спустя // Открытые системы.СУБД. — 2023. — № 3. — С. 11–16. URL: https://www.osp.ru/os/2023/03/13057588 (дата обращения: 21.09.2024).

3. Дмитрий Волков. Простые решения для аналитики Больших Данных // Computerworld Россия. — 2017. — № 3. URL: https://www.osp.ru/cw/2017/3/13051623 (дата обращения: 22.09.2024).

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

5. Владимир Озеров. Открытая технология анализа корпоративных данных // Открытые системы.СУБД. — 2023. — № 2. — С. 8–11. URL: https://www.osp.ru/os/2023/02/13057251) (дата обращения: 22.09.2024).

Роман Раевский (rar@rapeed.ai) — эксперт по технологиям бизнес-аналитики (Москва).