Горизонтальное масштабирование ресурсов в rapeed
Что делать, если объем данных продолжает расти, а ресурсы заканчиваются? Или, например, хочется подбавить оперативной памяти, чтобы увеличить пользователям #удовольствие_от_аналитики? Или подоспели новые источники данных и радостно ждут своего переселения в хранилище rapeed?
Всё просто - добавляйте виртуальные машины в контур rapeed, и произойдет следующее:
- процессор и память только что добавленных машин (нод) мгновенно станут использоваться в расчетах;
- диски новых машин начнут наполняться данными при ближайшем сеансе импорта.
Причем импорт так сделан, что пишет данные на самый свободный диск. То есть диски новых нод будут усиленно заполняться данными до достижения равномерного распределения источников между всеми нодами.
Очень простая аналогия - добавление новой ёмкости для потока воды, связанной с другими ёмкостями единой трубой. Без ограничений. Это и есть настоящее горизонтальное масштабирование.

Номинация на Data Awards’25
Меня вместе с rapeed номинировали на премию Data Awards’25. Организаторы выложили интервью со мной про rapeed и его значение для отрасли. Почитайте!
#удовольствие_от_аналитики

У Фейсбука не получилось..
Мы всё время ищем, есть ли в мире еще аналоги нашей технологии. В результате поисков нашли статью 2016 года ученых из Facebook Research Lab, в которой они описывали принципы технологии Cubrick - распределенного OLAP in-memory движка.
Интересно, что пишут математики Facebook о недостатках ROLAP-средств анализа данных: операции «slice-n-dice, roll-ups, drill-down» недоступны пользователям в режиме онлайн, что резко ограничивает свободу работы с данными и, следовательно, количество и качество бизнес-решений.
Технология «не взлетела» дальше тестов - больше о ней упоминаний нет. Есть признаки, что Google тоже пыталась создать распределенный in-memory OLAP по тем же причинам - и у них тоже не получилось. Нам, сделавшим эту технологию и доведшим её до production, интересно почитать описание и математические модели технологий гигантов. Даже видно места, где маститые математики Фейсбука свернули не туда. Но мы им об этом не скажем) - пусть #удовольствие_от_аналитики получают наши пользователи!

Сводная таблица или дашборд?
Вечный холивар в среде BI - что нужно пользователям? Ученые из Facebook пишут, что операции раскрытия/сворачивания, добавления срезов на лету и сквозной сортировки таблицы (примерно так можно перевести с английского «slice-n-dice, roll-ups, drill-down») по определению возможны только в сводной таблице и что только она даёт свободу работы с данными.
Российские вендоры BI-средств поголовно выступают за интерактивные дашборды - видимо, потому, что сводной таблицы из коробки у них нет и каждая сводная таблица - это кастомная разработка на SQL и средствах визуализации.
Если говорить про пользователей, то мы не нашли опросов, которым можно верить. Экспертные оценки западных вендоров (а эксперты кто и где они сейчас?..) говорили, что 80% пользователей сидят в сводных таблицах Excel и им ничего больше не надо. Дашбордами пользовались только руководители или неквалифицированные пользователи - одни не хотели данные крутить, другие не умели. Дашборды при этом создавали и создают сотнями и тысячами, а средний срок жизни одного дашборда - 3,5 открытия (!!!, данные Qlik).
Как вы думаете, что нужнее пользователям? Пишите в комментариях!
#удовольствие_от_аналитики

Сводная таблица или Pivot Table?
Сводная таблица по-английски называется Pivot Table. «Pivot» - заимствованное из французского, а еще раньше из латыни слово, означает «быстрый разворот». То самое «Крууу-гом!». Согласитесь, это очень точно отражает свойство сводной таблицы «быстро разворачиваться» вокруг новых осей - полей, которые выбирает пользователь.
«Сводной» таблицу назвали по-русски, потому что она агрегирует данные из большого источника данных, то есть даёт сводку из него, только важную информацию, опуская детали.
Самый известный пример - безусловно, сводная таблица Excel. Чтобы называться «полнофункциональной», любая другая сводная таблица обязана иметь функционал не меньше, чем в Excel - то есть строить любые многомерные структуры из полей слева и сверху, фильтровать, сворачивать/разворачивать узлы, сортировать и проводить любые вычисления.
У сводной таблицы Excel есть серьезное ограничение - миллион строк (и 16 тысяч столбцов). Это не даёт возможности, например, посмотреть продажи миллионов товаров в разрезе миллионов клиентов, а затем узнать лидеров среди них. Поэтому ею пользуются для «разворачивания» относительно малых полей по количеству элементов - до миллиона.
Очевидно, чтобы подарить пользователям настоящее #удовольствие_от_аналитики, нужно дать больше функциональности, чем обычная сводная таблица Excel, и убрать её ограничения.
Далее посмотрим, какие преимущества в этом отношении даёт сводная таблица rapeed.

Выход rapeed 0.3 (OLAP) - сводная таблица без ограничений
Сегодня, 30 мая 2025 года, выходит сборка rapeed 0.3. Это релиз продукта rapeed OLAP, который включает сводную таблицу без каких-либо ограничений, с возможностью связывания источников по любому набору полей «на лету». В релиз вошли также дополнительные функции по редактированию источников из СУБД и управлению их инкрементной загрузкой, а также множество других изменений.
Также в релиз входит rapeed OLE DB Provider, который дает возможность сводной таблице Excel работать с многомерным аналитическим хранилищем rapeed «из коробки». Все возможности сводной таблицы Excel, описанные ранее, поддерживаются нативно.
Важно, что основой работы и сводной таблицы rapeed, и сводной таблицы Excel является одна и та же API-команда, что гарантирует полное совпадение расчетных значений в обоих инструментах.
У обеих сводных таблиц есть свои преимущества:
⁃ в интерфейсе rapeed можно на лету связывать источники данных по любым полям в любых сочетаниях: например, 4 источника связаны по полю Город, 3 источника - по полю Товар, при этом никаких требований на поля не накладывается, кроме соответствия типа (дата-дата, текст-текст), и от полей не требуется быть ключевыми или уникальными;
⁃ также в построителе выражений rapeed можно задать формулы показателей (метрик) на основе любого количества источников, и использовать эти показатели в Excel;
⁃ в Excel ячейки сводной таблицы можно без ограничений использовать в любых расчетах.
В комментариях к прошлому посту подписчики отмечали, что сводная таблица Excel обычно долго грузит данные с сервера. При работе с rapeed OLAP этой проблемы не возникает, потому что расчеты всего объема данных происходят на сервере, и ядро отдает клиенту - сводной таблице - уже сформированный компактный блок записей для отображения. Это называется пагинация (от слова page, то есть страница). С пагинацией обе сводные таблицы просто летают.
- У вас есть сводная таблица?! Дайте две!
- Пожалуйста! Ваше #удовольствие_от_аналитики)

Безграничный Excel - вживую на миллиардах
Хотите посмотреть, как можно обходить ограничения сводных таблиц Excel? Мы решили с нашим партнёром Glowbyte сделать вебинар, на котором вживую показать работу сводных таблиц с хранилищем rapeed под капотом.
24 июля с 13:00 до 14:30 (а может, и дольше) мы с моим коллегой Никитой Каримовым и Алексеем Сучковым из Glowbyte подробно расскажем и покажем, как в сводной таблице Excel можно делать онлайн-аналитические запросы. Откроем капот и покажем сам двигатель хранилище rapeed, как это работает и что это даёт пользователям Excel.
Регистрируйтесь на вебинар! У нас ограниченное количество мест, но если указать корпоративную почту, то шанс вживую всё увидеть, задать нам любые вопросы и получить #удовольствие_от_аналитики резко возрастёт.

Оглавление канала
Для удобства подписчиков я решил сделать оглавление канала, чтобы вам долго не листать. Закреплю его и буду периодически обновлять.

- История создания rapeed
- Основные проблемы, для решения которых создавался rapeed
- Что такое DOLAP
- Область связей (кхор) - идея и описание работы на примере
- Что не так с BI на основе СУБД? - сравнение реляционного и многомерного подхода к аналитике, вечно актуальная тема
- Проблема источников данных различной гранулярности - первое упоминание связанных полей
- Демо-ролики про связанные поля - можно ли понять связь объектов, которые напрямую не связаны (поставщик - клиенты)
- Решение проблемы частично перезаписываемых данных
- Определение динамического тензорного движка rapeed
- Взрыв мозга - территориальная распределённость серверов не влияет на скорость вычислений
- Психологические особенности восприятия новой технологии
- Тесты rapeed на миллиарде записей на 3 недорогих серверах и 300 пользователей
- Аналитическая платформа rapeed в реестре ПО Минцифры
- Нагрузочные тесты rapeed на 40 000 пользователей на 3 источниках по 4 млрд записей - серия постов о результатах нагрузочных тестов и их интерпретация
- Сайзинг rapeed и горизонтальное масштабирование ресурсов
- Неудачная попытка Facebook создать распределённый OLAP
- Выход rapeed OLAP на рынок

Приходите!
Мы получили на данный момент 406 заявок на вебинар, который состоится послезавтра. Максимальная ёмкость вебинара в Контур.Толк, которым мы пользуемся - 300 участников. Из-за этого мы вынуждены выслать ссылку на вебинар далеко не всем желающим, а только указавшим корпоративный email представителям заказчиков. И даже с учётом этого подтверждений выслано уже 313).
Поэтому я обращаюсь к подписчикам и читателям канала: если вы получили от нас подтверждение и ссылку на вебинар - обязательно приходите!
А тем, кто зарегистрировался, но по какой-то причине от нас подтверждения не получил, я очень благодарен за ваше время и усилия, оставайтесь с нами, дальше будет только интереснее #удовольствие_от_аналитики!

Остатки? Балансы? - MinDate и MaxDate!
Одна из самых популярных расчётных задач - остаток товара (или баланс счёта клиента) на начало или конец периода. Таблицы остатков или балансов у больших компаний обычно очень большого размера - записи должны быть по каждому клиенту и его продукту на каждую дату, а в случае розницы по каждому SKU на каждую дату (а иногда и несколько в день) на каждый склад и магазин. Даже у среднего бизнеса это миллиарды строк, а у крупного - сотни миллиардов. При этом даты остатков или балансов могут различаться от клиента к клиенту или для разных магазинов - у каких-то вчера были операции и остатки менялись, а у каких-то - нет. Поэтому собрать информацию об остатках на начало и/или на конец периода - уже проблема. А если эти остатки нужно соединить с детальными продажами, возвратами и понять, как одно влияет на другое, то задача становится практически невыполнимой.
Но если у вас есть rapeed, то задача решается быстро и просто с использованием функций MinDate и MaxDate. Эти функции показывают значение поля на минимальную и максимальную дату, соответственно. Я записал небольшое видео, где они используются для расчёта (я бы даже сказал, показа) начального и конечного остатка товаров в магазине.
Видео снято в версии rapeed 0.8, которая сейчас готовится к выходу.

Во-первых, это красиво
Проблема всех разработчиков софта в том, что красивый интерфейс никто не замечает. Интерфейс, как правило, отмечают, когда он уродский или неудобный - тогда говорят «ну и уродство!» или «кто ж такое придумал!».
Если повезло и интерфейс продукта хороший, удобный - ну и ладно, им просто будут пользоваться.
При аналитической работе с данными без ограничений особенно важно, чтобы интерфейс «подчёркивал» данные и направлял пользователя играть с ними, сам оставаясь в тени. При этом никто не отменял общих принципов хорошего интерфейса:
⁃ пользователь должен с одного взгляда оценить, как была получена текущая конфигурация данных (читаемость);
⁃ пользователь должен мгновенно понять, что и как можно делать с данными (управляемость);
⁃ результат должен соответствовать намерениям пользователя (прогнозируемость);
⁃ результат должен достигаться минимумом действий (лёгкость использования).
Причём тут красота? Ефремов в «Лезвии бритвы» определяет красоту как наивысшую степень целесообразности, тонкую линию единства противоположностей в борьбе за гармонию, полную скрытой энергии. Без всяких шуток, мы стремимся к гармонии работы с данными, чтобы вы получали подлинное #удовольствие_от_аналитики! Поэтому мы основательно переделали, упростили и сделали более красивым (=целесообразным, читаемым, управляемым…) интерфейс rapeed 0.8, который готовится к выходу.

…Во-вторых, эффективно и целесообразно
В видео показано создание сводной таблицы на данных из двух не связанных между собой источников. Сначала создаются их связи по двум полям, затем - новый показатель, затем - сводная таблица из этих полей и показателей. На всё это тратится абсолютный минимум кликов мыши и прочих действий пользователя. При этом контекст работы полностью понятен. Это и есть #удовольствие_от_аналитики!

Почему 0.8?
В конце мая вышел rapeed 0.3. Почему сейчас выходит версия именно 0.8, а не какая-то другая?
После 0.3 мы планировали выпустить 0.4, в которой будут добавлены динамические справочники (что это такое и в чем их удобство, я подробно опишу на примерах). Это «добавление динамических справочников» вылилось в создание практически готового функционала по работе со связями полей и других объектов. Можно сказать, что в 0.3 был фундамент и 1й этаж, а сейчас это готовое офисное здание класса А - осталось только выбрать и завезти мебель. Еще и команда фронтенда сделала очередное чудо и успела перевести весь интерфейс на красивый новый стиль раньше графика. Добавлено много расчетных функций, которых ждали клиенты - например, MinDate и MaxDate, автоматические считающие баланс на начало/конец периода, гибкую конструкцию IF THEN ELSE ENDIF, динамические составные поля, решающие проблему сложного среднего, и многое другое.
По объему функциональности, внешнему виду, гибкости и удобству выходящая версия должна быть 1.8 по сравнению с вышедшей в мае 0.3. Но, зная, что будет в версии rapeed 1.0, мы решили присвоить ей номер 0.8. Получайте #удовольствие_от_аналитики!

Выход rapeed 0.8 - динамические справочники, семантические связи, новый интерфейс и расчётные функции
Вчера, 09 сентября 2025 г., вышла версия rapeed 0.8. Целое лето и ещё неделю мы создавали наиболее гибкую систему работы с данными: обогащение данных на лету (динамические справочники), отдельные сущности связей полей (семантические связи), составные поля (очень легко считать среднее по Магазин-SKU-месяц), новые расчётные функции и многое другое. Всё это в совершенно новом стиле интерфейса. Новая версия уже установлена у первого из ожидавших клиентов, остальные её получат в ближайшие дни и будут получать истинное #удовольствие_от_аналитики. А мы будем полностью переписывать пользовательскую документацию - буквально всё.

Динамические справочники в rapeed - обогащение данных на лету
В rapeed 0.8 появились динамические справочники, которые решают задачу обогащения больших объёмов данных на лету. Например, если у заказчика большой и постоянно растущий объём данных и при этом ещё и справочники часто меняются, то обновление и репроцессинг кубов MS SSAS на новых справочниках каждый раз может занимать несколько суток (есть такие факты). Кроме обновления больших справочников, часто нужно оперативно добавить какое-то поле в источник данных и посмотреть все данные в его разрезе. Также у больших организаций есть версионность справочников - нужно смотреть прошлогодние данные в новой иерархии или наоборот.
Всё это легко решается с помощью динамических справочников в rapeed. Их коренное отличие - справочники присоединяются к источникам данных на лету в любом количестве по любым полям. Единственное отличие справочника - у него должно быть уникальное поле. Зато справочников может быть сколько угодно!
Источники по-прежнему можно связывать между собой как угодно. Справочники тоже. А если у источников общий справочник, то они уже автоматически связаны по всем его полям. Источники также можно связывать … со справочниками! И здесь уже начинается та самая #игра_с_данными, которая приносит истинное #удовольствие_от_аналитики!
Для иллюстрации я снял видео (4:24 мин) про работу динамических справочников в rapeed, которое опубликовано ниже.

Обновление Add-on и OLE DB Provider для MS Excel - ещё более безграничная и удобная сводная таблица Excel при работе с данными rapeed
Сегодня вышло обновление Add-on и rapeed OLE DB Provider для MS Excel, содержащее множество улучшений для работы с данными rapeed.
Сейчас rapeed OLE DB Provider также работает по безопасному подключению SSL, позволяет выбрать, сколько строк и столбцов загружать для этой сессии подключения и в какой из доступных рабочих областей rapeed работать. Улучшен поиск и фильтрация данных в таблице, а также формат выводимых чисел.
Подробная информация представлена на новостном разделе сайта. Работайте в сводной таблице Excel с данными rapeed, получая ещё большее #удовольствие_от_аналитики!

rapeed на byteoilgas_conf 06 октября
В понедельник 06 октября я выступаю на конференции byteoilgas_conf с докладом «платформа rapeed: альтернативная технология работы с огромными массивами данных и продукты на ее основе». Почему-то и название конференции, и все доклады в программе пишутся с маленькой буквы). Расскажу об иной работе с данными, отличающейся от общепринятой SQL-парадигмы, и почему rapeed - идеальная платформа для работы AI, в отличие от классических реляционных сред. Приходите, с удовольствием пообщаемся лично!
Благодарю организаторов за предоставленную возможность выступления!

Гибкие расчёты остатков и балансов с помощью уровня валидности в OnMinDate/OnMaxDate
Я раньше уже рассказывал о проблеме расчёта остатков - для её решения в rapeed 0.8 мы сделали функции MinDate и MaxDate. После их апробации и общения с клиентами мы их усовершенствовали и переименовали - сейчас это функции OnMinDate и OnMaxDate, возвращающие значения заданного поля на минимальную и максимальную дату и автоматически агрегирующие их. Но не просто агрегирующие, а с учётом нового введённого в функции параметра - уровня валидности.
Что такое уровень валидности? Допустим, вы считаете остатки товаров в магазинах. На каком уровне их допустимо (=валидно) складывать? Можно ли складывать начальный остаток одного товара (SKU) с начальным остатком другого? Если нет, то уровень валидности - это SKU. Это достаточно очевидно.
А если товары есть в остатке во многих магазинах, то валидно ли их складывать? Это уже не так очевидно, но обычно начальные остатки по одному SKU в разных магазинах складывают. Тогда уровень валидности - это комбинация (SKU-Магазин).
Теперь пример из другой сферы. Представьте клиента банка. У него открыто несколько карт, счетов и других банковских продуктов в разных валютах. На каком наборе полей корректно (=валидно) учитывать балансы клиентов для отчётности? В этом случае на уровне (Клиент-Продукт-Валюта), но в зависимости от бизнеса в этот набор могут добавляться и другие поля.
Ситуация становится ещё интереснее, когда отдельно хранятся ежемесячные остатки/балансы, которые можно складывать, и ежедневные, которые складывать нельзя, но и те и другие участвуют в важных расчётах. В этом случае в уровень валидности нужно добавить месяц или дату. Важно, что функции OnMinDate/OnMaxDate, как и все остальные в rapeed, считают всё на лету, поэтому можно экспериментировать, подбирая нужный бизнесу уровень валидности на лету и проверяя агрегацию остатков или балансов на разных уровнях источников и справочников.
Для иллюстрации работы функций OnMinDate/OnMaxDate и уровня валидности я подготовил небольшой видеопример (04:15) - файл Остатки.xlsx из него я использовал ещё для этих видео полуторагодовой давности!) Если вы хотите разобраться, как работают расчёты, вам, скорее всего, придётся пересмотреть видео несколько раз. Ниже на скриншоте приведён конечный результат с корректными данными расчётов в обоих случаях из видеопримера, показывая, как гибко можно управлять расчётом балансов.