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

Видеопример по расчёту остатков с разными уровнями валидности

Скриншот, иллюстрирующий различные уровни валидности остатков на одинаковых данных

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

AMD Epyc и пятничный баттл «одна нода vs три ноды»
Буквально каждый архитектор данных у наших клиентов перед заказом железа задаёт один и тот же вопрос: «А может, сделать всё-таки один мощный сервер и на одной ноде систему запускать?»
Теоретические рассуждения и прошлые опыты после выхода новой версии уже не сильно убеждают, поэтому мы решили сравнить работу rapeed на одном и том же оборудовании, на идентичных данных и с абсолютно одинаковыми настройками, с одной лишь разницей - в одном случае три ноды, а в другом - одна.
Также мы недавно перешли на новый сервер с процессором AMD Epyc 9454, памятью типа DDR5 и NVMe-дисками, сделанными специально под эту серию процессоров.
Год назад я писал, что первичная загрузка данных для расчёта с диска на процессоре Intel Xeon занимает 5-7 секунд, а следующие расчёты (в том числе другими пользователями) выполняются за 1-2 секунды. И все архитекторы интересуются именно первичной загрузкой данных. Только её мы сейчас и тестировали, честно очищая все кэши перед каждой операцией.
Так вот, Epyc, танцуя, затаптывает Xeon под плинтус - первичная загрузка миллиарда записей, да ещё с динамическими справочниками, да ещё и с самим расчётом - всё это в сумме занимает 1,75 секунды! Это так же на трёх нодах, как и раньше. В связи с чем мы уже предлагаем всем клиентам брать именно машины с Epyc и дисками для него (либо другими быстрыми NVMe-дисками).
Но самое интересное, что система вновь доказала свою распределённую природу. Конфигурация из трёх нод на всех операциях была быстрее однонодовой на 30-40% и выше. Причём на расчётах COUNT DISTINCT три ноды опережали одну уже в 2,5 раза!
Подробные результаты тестирования интересующиеся могут получить по запросу, написав нам в канале или на сайте. Хороших выходных!

Выход rapeed 1.0 - рабочие области + ролевая модель, интеграция с Active Directory, панели виджетов, условия на значения полей и многое другое
После выхода версии 0.3, ядро которой обрабатывало миллиарды записей за субсекундное время,
и версии 0.8 с динамическими справочниками, которая упрощает работу с данными сложной структуры -
версия rapeed 1.0, выходящая сегодня, закрывает потребности Enterprise-клиентов в создании индивидуального контекста работы для каждого пользователя и коллективной работы групп пользователей в рамках корпоративной среды данных.
В составе rapeed 1.0 вышла следующая функциональность:
⁃ Интеграция с Active Directory (AD) с помощью KeyCloak. За аутентификацию пользователя, как и положено в корпоративной среде, отвечает AD, за авторизацию работы в rapeed - KeyCloak, за права пользователя в rapeed - сочетание ролевых моделей AD и rapeed;
⁃ Рабочие области. Рабочая область задаёт контекст работы пользователя с данными, или, проще говоря, какие источники данных, поля, показатели, связи и другие объекты пользователь видит и может ими пользоваться. Рабочие области можно публиковать и копировать полностью или частично, они бывают личными или общими. Например, из рабочей области по умолчанию (Default) можно создать несколько общих рабочих областей для каждого отдела со своими источниками и справочниками, администраторы отделов могут внутри этих рабочих областей раздать права каждому пользователю, включая права на значения полей (RLS или, точнее, VLS, см. следующий пункт), а пользователи себе для комфортной работы (например, в сводных таблицах Excel) могут оставить только нужные поля в личной рабочей области;
⁃ Система управления ролевой моделью и правами доступа. Доступно назначение ролей и прав вплоть до конкретных значений полей. Обычно это называется Row-Level Security (доступ на уровне строк), RLS, но более корректно говорить о Value-Level Security (доступ на уровне значений), VLS;
⁃ Панели виджетов. Это логическое объединение виджетов в группу с единым пространством фильтров, в том числе автоматических (возникающих из отметок пользователя в виджетах) и пользовательских (в том числе по полям и связям, отсутствующим в виджетах). В рабочей области может быть неограниченное количество панелей виджетов;
⁃ Условия на значения полей. Помимо значений на ячейки таблицы, задаваемых с помощью вложенных операторов IF/THEN/ELSE, в rapeed 1.0 появились условия на значения полей в источнике. Например, можно считать сумму, но только в январе-феврале 2024 года и только по конкретным категориям. При этом выводить этот показатель система будет как любой другой в динамически задаваемом контексте (например, определяемом раскрытием уровня сводной таблицы). Условия на значения полей - это фактически использование альтернативных массивов данных для показателей в одном виджете.
Система будет доступна для установки клиентам на этой неделе.
Получайте настоящее #удовольствие_от_аналитики! Встречайте rapeed 1.0!

Знак Почёта
Это папин орден СССР «Знак почёта» за его 9 авторских изобретений. Я до вчерашнего дня не знал, что у него есть этот орден. Как он сказал, «Да нечем особо хвастаться».
Я пока отстаю от него - у меня только 4 патента. Отец ещё в детстве внушил мне уважение к профессии «Инженер» - как я позже узнал, это слово происходит от латинского «озарение, божье провидение». Так и есть. И мне еще есть к чему стремиться! Хотя области у нас разные - в том числе и из-за папиных изобретений 70х-80х годов до Москвы сейчас не долетают беспилотники.

Запись выступления на byteoilgas conf_
Организаторы byteoilgas conf_’25 выложили запись моего выступления. За полчаса получилось рассказать (в том числе на примерах) о главных особенностях платформы, почему она прорывная и что даёт клиентам.

Безгранично вложенные показатели в rapeed
Иногда так хочется что-нибудь взять и поделить! Взять эдак одну выборку значений с одними условиями и сложить их, умножить на сложный коэффициент эффективности, где в числителе свои условия выборки, допустим, клиентов, а в знаменателе, вишь как, другая выборка, скажем, диапазонов дат, и поделить на динамически выбранные тут же максимальные значения из прошлых лет!
Хотелось вам такое? Или приходилось по необходимости?
Легче, чем в rapeed, вряд ли где-то можно это сделать. В вышедшей версии 1.0 формулы показателей можно разбивать на логические части (например, на те, которые этак по-залихватски описаны выше) и для каждой части, вплоть до отдельной функции, задавать своё название, формулу и условия - а в результирующей формуле использовать ранее сохранённые показатели как части формулы и.. ещё один набор условий.
Получается структура вложенных показателей, что резко упрощает создание сотен бизнес-показателей в крупных компаниях.
Для иллюстрации можно было бы добавить скриншот либо очень сложного показателя, либо очень простого, но состоящего из нескольких вложенных, которые, в свою очередь, тоже состоят из нескольких вложенных. Спрашивайте - покажем и так и так. Тут уже у каждого пользователя свой подход и своё #удовольствие_от_аналитики.

Drill-through в Excel из обогащённого источника rapeed
В обновлении Add-On для Excel появилась возможность drill-through из ячейки сводной таблицы. Система выводит на новом листе первые 1000 строк, сформировавших значение в ячейке, причём сразу вместе с прикреплёнными справочниками.
В видео ниже (44 секунды) приведён краткий пример работы drill-through.

Ещё раз про уровень валидности
На одном из проектов (очень крупная FMCG-компания) оказалось, что стандартная логика расчёта остатков не работает. Стандартная логика - это когда на каждый товар ищется максимальная дата, по которой есть запись об остатке этого товара, и затем все эти остатки корректно суммируются в любых разрезах.
У клиента оказался специфический расчёт - каждый контрагент (дистрибутор) присылает ему информацию об остатках товара на своих складах с разной периодичностью и разным набором наименований. И считается, что если вчера у дистрибутора А были остатки товаров Б и В, а сегодня - товаров Г и Д, то в остатках на конец периода нужно учитывать только товары Г и Д. Сегодняшняя судьба товаров Б и В никого не интересует.
У клиента остатки считались с помощью функции OnMaxDate с указанным уровнем валидности - sku, как раз на основе стандартной логики расчёта. И результаты не сходились - по датам сходились, по дистрибуторам иногда сходились, но чаще всего нет. После понимания бизнес-логики на получение верного результата в расчётах ушло 5 минут и 2 клика мыши.
Что мы изменили и как?