rapeed: in-memory OLAP-движок с собственной алгеброй связей

Вот важная новость с фронта ИИ: ryzhikad 36 минут назад rapeed: in-memory OLAP-движок с собственной алгеброй связей 10 мин 1. 2K Блог компании ИТ-интегратор Белый код Хранение данных * Data Engineering * Анализ и проектирование систем * Обзор Меня зовут Андрей Рыжик, я Product Owner BI-направления в компании «Белый код». Эта статья – обзор платформы rapeed: in-memory OLAP-движка с собственным форматом хранения, нестандартной алгеброй связей между источниками и несколькими клиентами поверх единого ядра.

Кто стоит за продуктомПлатформу разрабатывает команда Романа Раевского – основателя «Полиматики» (Polymatica). «Полиматика» была одним из российских OLAP-движков начала 2010-х годов, который в своё время вышел в том числе на европейский рынок. В 2019 году Раевский покинул «Полиматику» и приступил к развитию следующей итерации технологии в новой команде.

Технические детали

rapeed – третья по счёту разработка этого подхода к работе с данными. Что такое rapeedrapeed – это распределённый in-memory OLAP-движок, разработанный с нуля на C++. Ядро не построено поверх ClickHouse, Greenplum или другой внешней СУБД: и формат хранения, и алгебра операций над данными, и работа с диском реализованы в рамках самой платформы.

Поверх ядра работают три клиента: веб-интерфейс с панелью виджетов, нативное подключение из Microsoft Excel через сводные таблицы, и открытый HTTP API. Это означает, что rapeed может использоваться не только как BI-платформа, но и как расчётный backend для произвольных приложений, которые хотят получать данные с учётом настроенных в ядре связей и метрик. Платформа зарегистрирована в реестре отечественного ПО Минцифры, разворачивается on-premise в Docker или Kubernetes, имеет русскоязычный интерфейс и поддерживает корпоративное SSO через KeyCloak (SAML, OAuth2).

Защита трафика – TLS 1. АрхитектураРаспределённое in-memory MPPrapeed разворачивается на нескольких нодах – виртуальных или физических. Каждая нода хранит часть данных на диске, загружает их для расчётов в общую память и участвует в распределённой обработке запросов.

Отраслевые последствия

Размер кластера определяется объёмом обрабатываемых данных и числом одновременных пользователей. В описании продукта движок упоминается как DDT-engine – Distributed Dynamic Tensor engine. Технически это означает, что операции над данными выполняются не построчно над плоскими таблицами, а как операции над многомерными структурами (тензорами), одновременно по нескольким измерениям.

Практическое следствие для пользователя – связывание источников разной структуры выполняется без физического объединения таблиц и без размножения строк. Системные требованияПрофиль нагрузки близок к ClickHouse: главное требование – быстрый диск со скоростью чтения от 1 ГБ/с. CPU и оперативная память – стандартные.

В описании продукта указывается до 2 миллиардов записей на одну ноду при времени отклика менее 5 секунд. Память выделяется резидентно под рабочие данные; при обновлении источника соответствующий кэш сбрасывается и пересчитывается. Развёртывание – через Docker или Kubernetes.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.