Меня зовут Андрей Рыжик, я Product Owner BI-направления в компании «Белый код». Эта статья – обзор платформы rapeed: in-memory OLAP-движка с собственным форматом хранения, нестандартной алгеброй связей между источниками и несколькими клиентами поверх единого ядра.
Кто стоит за продуктом
Платформу разрабатывает команда Романа Раевского – основателя «Полиматики» (Polymatica). «Полиматика» была одним из российских OLAP-движков начала 2010-х годов, который в своё время вышел в том числе на европейский рынок. В 2019 году Раевский покинул «Полиматику» и приступил к развитию следующей итерации технологии в новой команде. rapeed – третья по счёту разработка этого подхода к работе с данными.
Что такое rapeed
rapeed – это распределённый in-memory OLAP-движок, разработанный с нуля на C++. Ядро не построено поверх ClickHouse, Greenplum или другой внешней СУБД: и формат хранения, и алгебра операций над данными, и работа с диском реализованы в рамках самой платформы.
Поверх ядра работают три клиента: веб-интерфейс с панелью виджетов, нативное подключение из Microsoft Excel через сводные таблицы, и открытый HTTP API. Это означает, что rapeed может использоваться не только как BI-платформа, но и как расчётный backend для произвольных приложений, которые хотят получать данные с учётом настроенных в ядре связей и метрик.
Платформа зарегистрирована в реестре отечественного ПО Минцифры, разворачивается on-premise в Docker или Kubernetes, имеет русскоязычный интерфейс и поддерживает корпоративное SSO через KeyCloak (SAML, OAuth2). Защита трафика – TLS 1.3.
Архитектура
Распределённое in-memory MPP
rapeed разворачивается на нескольких нодах – виртуальных или физических. Каждая нода хранит часть данных на диске, загружает их для расчётов в общую память и участвует в распределённой обработке запросов. Размер кластера определяется объёмом обрабатываемых данных и числом одновременных пользователей.
В описании продукта движок упоминается как DDT-engine – Distributed Dynamic Tensor engine. Технически это означает, что операции над данными выполняются не построчно над плоскими таблицами, а как операции над многомерными структурами (тензорами), одновременно по нескольким измерениям. Практическое следствие для пользователя – связывание источников разной структуры выполняется без физического объединения таблиц и без размножения строк.
Системные требования
Профиль нагрузки близок к ClickHouse: главное требование – быстрый диск со скоростью чтения от 1 ГБ/с. CPU и оперативная память – стандартные. В описании продукта указывается до 2 миллиардов записей на одну ноду при времени отклика менее 5 секунд. Память выделяется резидентно под рабочие данные; при обновлении источника соответствующий кэш сбрасывается и пересчитывается.
Развёртывание – через Docker или Kubernetes. Поддерживаются основные дистрибутивы Linux, включая Astra Linux и AltLinux.
Ключевая особенность: связи вместо JOIN
Самая нестандартная часть rapeed – это его модель связывания источников. В платформе разделены две сущности: справочники и связи. Они закрывают разные задачи и работают по разному принципу.
Справочники
Справочник в rapeed – это вспомогательная таблица, которая прикрепляется к основному источнику по общему полю-ключу. После прикрепления поля справочника становятся виртуальными полями источника: они доступны во всех запросах, фильтрах и виджетах, но физически в источник не дублируются.
Архитектурное следствие – таблица фактов остаётся узкой. В примере с источником «Чек_1B» в нём лежат только идентификаторы: номер чека, время, id товара, id магазина. Все атрибуты – наименования магазинов, категории товаров, признаки сегментации – приходят из справочников по запросу. Никаких широких денормализованных витрин предзагружать не нужно.
По смыслу справочники близки к JOIN, и пользователю, знакомому с реляционной моделью, разобраться с ними легко. Дальше начинаются принципиальные отличия.
Связи
Связь в rapeed – это самостоятельный объект, у которого нет прямого аналога в SQL. Она соединяет два источника по одному или нескольким полям, при этом источники могут иметь разную гранулярность, и в результате не возникает ни размножения строк (как при JOIN с дублирующими ключами), ни потери данных.
Чтобы было предметно, рассмотрим типичный сценарий «план – факт». Источник фактов – таблица чеков на миллиард строк, с детализацией до каждой покупки. Источник плана – таблица из 12 строк, в которой плановые значения разложены по двум разрезам: категории продукции и ценовому сегменту. У этих двух таблиц нет общих ключей и нет общих справочников. Есть только одно поле, совпадающее по смыслу: «Категория 2».
В интерфейсе rapeed связь между этими двумя источниками создаётся перетаскиванием одного поля на другое. Без ETL, без перегрузки источников, без скриптов.
После создания связи в виджет с разрезом по типам производства добавляется показатель «сумма плана». В демо-данных, на которых проходила презентация, плановые значения были заданы только для части категорий. Для «Стороннего производства» план в источнике присутствовал, и в виджете рядом с фактом по этой категории сразу же появилось рассчитанное плановое значение. Для «Вспомогательного производства» план в источнике отсутствовал, и в виджете напротив этой категории встал прочерк. Что соответствует фактическому состоянию данных: алгоритм не выдумал значение там, где его не было, и не задублировал строки, чтобы заполнить пропуски.
Принципиальных моментов здесь два. Первый – пересчёт виджета произошёл мгновенно после создания связи, без обращения к ETL и без перезагрузки источников. Второй – миллиард строк чеков при этом не размножился по 12 значениям плана: связь работает на уровне агрегатов в движке, а не на уровне реляционного объединения таблиц.
В классическом неассоциативном BI ту же задачу приходится решать двумя путями. Либо в DWH строится широкая витрина через LEFT JOIN с заранее продуманной гранулярностью, и тогда нужен ETL-разработчик, а в результирующей витрине возможны или дубли строк (если ключи не уникальны), или потери. Либо расчёт пишется на стороне BI, выражениями вида set analysis в Qlik или многоэтажными CALCULATE+FILTER в DAX PowerBI – это требует разработчика BI, а не аналитика. rapeed выводит ту же задачу на уровень drag-and-drop в интерфейсе.
Область связей
Поверх механизма связей в платформе реализован отдельный визуальный инструмент – «Область связей». Это виджет, в который перетаскиваются поля из разных источников, и который отображает их взаимосвязи через справочники и пользовательские связи в виде графа. Отношения «многие-ко-многим» считаются и рисуются в реальном времени, по мере того как пользователь добавляет или убирает поля.
В демо-данных этот инструмент сразу показывает нетривиальное пересечение в иерархии товаров. Есть две верхние группы категоризации: «Фуд» и «Собственное производство». В классической отчётности они выглядят как независимые ветки, и интуитивно ожидаешь, что любая товарная группа относится либо к одной из них, либо к другой. На деле же группы «рулеты» и «гарниры» входят одновременно в обе верхние категории – «Область связей» показывает это явно, как пересечение в графе. Не как ошибку в данных, а как фактическое устройство справочника, о котором пользователь, не работавший с ним глубоко, может не подозревать.
Прикладной смысл понятен. Чтобы обнаружить такое пересечение в обычной BI-системе, нужно сначала заподозрить, что оно вообще есть, затем написать SQL-запрос к схеме справочников, затем разобраться, в каких таблицах живёт эта неоднозначность. В «Области связей» это становится видно как побочный эффект работы с данными: пользователь не ищет аномалии целенаправленно, он просто строит модель, а инструмент попутно подсвечивает, что в этой модели устроено нетривиально.
Клиенты поверх движка
Excel
rapeed предоставляет нативное подключение из Microsoft Excel через стандартный механизм сводных таблиц. Excel воспринимает движок как Microsoft SQL Server Analysis Services в режиме Multidimensional: подключается к нему как к OLAP-кубу, отправляет MDX-запросы, получает ответы в той же структуре, которую ожидает от SSAS. На стороне Excel пользователь видит привычную сводную таблицу со всей штатной функциональностью – фильтрами, сортировками, итогами, форматированием.
Принципиально важно, что данные при этом физически не выгружаются в книгу Excel. Сводная таблица обращается к движку rapeed на сервере, где обработка идёт по миллиардам строк, и забирает в книгу только результат агрегации. Ограничение Excel в 1 048 576 строк, таким образом, обходится: оно касается листа Excel, а вычисления выполняются на сервере. Дополнительно есть выгрузка в Excel с сохранением форматирования и экспорт в PDF.
Открытый API
Второй клиент – это любая внешняя система, которая хочет получить данные из rapeed по HTTP. API документирован и покрывает основные операции: получение таблиц, программное создание показателей, управление связями.
Практическое применение – использование rapeed в качестве «движка без интерфейса». Связи и метрики настраиваются в ядре, а фронтенд может быть любым: внутренний портал, мобильное приложение, MCP-сервер для интеграции с LLM, отдельный программный модуль учётной системы.
Веб-интерфейс
Встроенный веб-интерфейс предоставляет панель виджетов: таблицы, сводные таблицы, графики, карты, drill-down, кросс-фильтрация. На сегодня этот интерфейс ориентирован в первую очередь на ad-hoc анализ, а не на сборку презентационных дашбордов с богатым оформлением.
Производительность
Цифры по производительности приведены ниже с оговоркой: это показатели из тестовых инсталляций и описания продукта, а не результаты независимого бенчмарка.
Нагрузочный тест на 1000 пользователей
Команда rapeed опубликовала в своём телеграм-канале Data Play результаты нагрузочного теста, проведённого в рамках апробации платформы у крупного корпоративного заказчика (требования по информационной безопасности у заказчика включают более ста пунктов; конкретное название не раскрывается). Под установку rapeed заказчик выделил одну (мощную) машину, и изначально предполагался тест на 100 одновременных пользователей. Команда rapeed предложила прогнать тот же сценарий на 1000.
Параметры теста:
-
1000 одновременно работающих пользователей;
-
30 итераций на пользователя, по 3 действия в одной итерации;
-
интервал между подключениями пользователей – 5 секунд;
-
объём источника данных – 300 ГБ;
-
основная таблица – 301 244 000 строк, вторая таблица – 27 671 000 строк;
-
сценарий действий – запросы с выборкой всех полей, последовательная итерация по полям с сортировкой, фильтрация по конкретным полям.
Результаты:
-
всего отправлено 90 000 запросов;
-
время ответа – минимум 1,3 секунды, максимум 8,5 секунды, среднее 2,8 секунды;
-
время обработки на одного пользователя – 40–80 секунд за 30 итераций;
-
общее время выполнения – 1 час 36 минут (около 5 600 секунд);
-
максимальная одновременная нагрузка – около 250 пользователей параллельно;
-
все операции выполнены без ошибок.
AI-агенты
Подход rapeed к интеграции AI-агентов отличается от того, что сегодня предлагает большинство BI-вендоров. В классическом сценарии агент получает текстовый запрос пользователя и собирает по нему дашборд. В rapeed эту задачу решать не планируется по простой причине: само создание виджетов в интерфейсе занимает секунды, и заменить эту работу голосовой или текстовой командой технически возможно, но практически медленнее.
Логика здесь общая: интерфейс «глаза-пальцы» работает существенно быстрее, чем интерфейс «глаза-рот». Артикулировать звуки голосом физически медленнее, чем оперировать руками с быстрым визуальным интерфейсом. На встрече Роман иллюстрировал это автомобильной аналогией. Голосовых помощников в машины пытались встроить именно как замену ручным регулировкам: переключению трека, настройке климата, навигации. Пока автомобиль стоит, это работает: можно сказать «включи музыку» и не тянуться к крутилке. Но как только водитель начинает вести, и руки уже заняты управлением, выясняется, что и тут голос всё равно проигрывает быстрому ручному интерфейсу – отвлекает, в итоге выходит медленнее, чем просто нажать кнопку. Поэтому от голосовых помощников в машинах в значительной мере отказались в пользу физических и виртуальных кнопок. Ad-hoc анализ в BI – это, по сути, та же история: пользователю эффективнее работать с интерфейсом руками, чем диктовать действия голосом или текстом.
Роль AI-агента в rapeed планируется другая. Это не генератор виджетов, а аналитический советник. Агент использует знание о структуре связей и дереве метрик и подсказывает пользователю направления исследования: неучтённые разрезы, аномалии, нетипичные отклонения от паттернов. Срок реализации – несколько месяцев. Партнёры, использующие открытый API, уже разрабатывают свои варианты MCP-серверов поверх ядра.
Роадмап
Ближайшие планы команды rapeed – выпуск двух отдельных продуктов поверх существующего ядра.
• rapeed BI – полноценный BI-фронтенд, в котором добавится порядка 15 типов визуализаций и упрощённое управление их настройкой.
• rapeed Data – модуль управления данными: единый центр связей источников и дерево метрик с прослеживаемостью зависимостей между показателями и используемыми ими функциями. Этот модуль ориентирован на администратора и super-пользователя.
Лицензирование
Лицензионная модель построена на трёх метриках: серверная конфигурация (одно- или многосерверная инсталляция), пользователи (с разделением на редакторов и читателей) и объём обрабатываемых данных (с базовым включённым лимитом и отдельным тарифом за каждый дополнительный миллиард строк). Конкретный прайс по всем трём метрикам высылается по запросу.
Лицензии для тестирования передаются бесплатно. Продажа продукта идёт через пилотные проекты, потому что для rapeed важна реальная валидация на инфраструктуре и данных заказчика – заявленные показатели нагрузки и скорости имеет смысл проверять на конкретных сценариях, а не на синтетике.
Резюме
Что выделяет rapeed на рынке. Большинство современных российских BI-платформ построены как визуальный слой над одной из готовых СУБД – чаще всего ClickHouse, иногда Greenplum или PostgreSQL. rapeed устроен иначе: ядро написано с нуля, со своим форматом хранения и своей алгеброй связывания источников. Это редкий подход для текущего рынка, и за ним стоит команда с предметным опытом в области OLAP-движков. Механика связей без JOIN – техническое решение, которое закрывает реальную задачу совмещения данных разной гранулярности без ETL-разработчика и без специализированных выражений на стороне BI.
Что стоит держать в уме при оценке. На сегодня rapeed – это в первую очередь движок и веб-интерфейс ad-hoc анализа. Полноценный BI-фронтенд с богатой библиотекой визуализаций, темами, средствами публикации дашбордов и сторителлинга находится в разработке. Для задач, где важно быстро собрать презентационный дашборд для заказчика, на момент написания статьи rapeed по богатству визуальных средств может уступать зрелым BI с готовыми библиотеками. Для задач, где важна работа с большими объёмами, связывание источников разной гранулярности и интеграция через API или Excel – rapeed заслуживает прицельного тестирования.
Про формулировку «уникальный продукт». В первоначальной рекомендации rapeed описывался как «второй ассоциативный движок в мире наряду с Qlik». Формулировка эффектная, но недостаточно точная: в мире существуют и другие in-memory OLAP-движки с ассоциативными свойствами, и команда rapeed сама не использует это позиционирование. Точнее описать платформу через сочетание свойств: собственный тензорный движок, своя алгебра связей, эмуляция SSAS-протокола для Excel, открытый API и регистрация в реестре отечественного ПО – каждое из этих свойств по отдельности где-то встречается, но в одном продукте такая комбинация на российском рынке нетипична.
ссылка на оригинал статьи https://habr.com/ru/articles/1042524/