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

Оглавление канала
История создания 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 клика мыши.
Что мы изменили и как?

Тем, кто крутит землю
Всех вас, кто изо всех сил крутил земной шарик вместе с нами - поздравляю с тем, что Земля повернулась в нужную сторону!
В уходящем году вышла версия rapeed 1.0, получила своих первых клиентов и дальше будет завоёвывать мир.
Спасибо вам, что вы с нами! С Новым годом!

Выход rapeed 1.1 - Pivot для любителей Excel, поддержка «раскрыть всё» и улучшения работы
Вышла версия rapeed 1.1, в которой сделаны многочисленные улучшения работы на основе отзывов клиентов, исправлены ошибки, ускорена работа с датами и поддержана функция Excel «раскрыть всё».
В новом релизе пользователь может указать, показывать ли унаследованные поля справочников в источниках - или показывать только их фактический состав. Эта настройка учитывается и при работе с Excel.
Большие улучшения произошли как в интерфейсе сводной таблицы - сейчас можно менять ширину любого столбца независимо и управлять отображением итогов и подытогов - так и в панели виджетов: работа с общей панелью фильтров поддерживается всеми графиками, картами и индикаторами.
Другие изменения произошли «под капотом» и приводят к резкому ускорению работы системы в разных ситуациях, в том числе с использованием сводной таблицы Excel.
Для пользователей, привыкших работать с Excel, в бета-режиме вышел rapeed Pivot - облегченная версия интерфейса работы с данными, визуально и функционально похожая на сводную таблицу Excel, но без пересылки файлов. Подробности о rapeed Pivot - в следующих публикациях! Получайте ещё больше #удовольствие_от_аналитики!

По-настоящему безграничный и быстрый Excel: вышел rapeed OLE DB Provider 1.1
В вышедшем сегодня обновлении rapeed OLE DB Provider версии 1.1 убраны все ограничения, какие только возможно было убрать, повышена скорость работы в 15 раз, а стабильность работы поднята на качественно новый уровень.
Поддержка особенности Excel раскрывать все узлы при добавлении нового поля в сводную таблицу в rapeed 1.1, а также переход на заполнение ячеек в ходе одного запроса позволили ускорить работу rapeed OLE DB Provider от 10 до 200 раз (средневзвешенно по различным полям - в 15 раз). Из-за этого мы убрали настройки количества строк как ненужные - Excel сейчас очень быстро выводит все строки вплоть до своего собственного предела в 1 048 576 строк. Его убрать невозможно, если ваша компания - не Microsoft, да и они почему-то не убирают этот лимит вот уже 20 лет.
Если количество строк в ответе ядра rapeed превышает этот предел, Excel выведет сообщение, что может показать только 1 048 576 строк, и покажет их вместе с итогами, посчитанными ядром на всём массиве данных.
На всём массиве данных сейчас также идёт полнотекстовый поиск среди значений поля - и фильтрация на его основе.
Запрос данных в rapeed сейчас идёт в отдельном потоке и не мешает работать с полученными данными вплоть до перестроения итоговой таблицы, что также повышает стабильность работы. При этом в строке состояния отражаются этапы обработки запроса, и при сотнях тысяч строк пересылки их, если повезёт, можно увидеть - обычно промежуточные этапы не успевают отобразиться и сразу выводится ответ.
Сводная таблица Excel стала быстрым и 100% надёжным интерфейсом работы с данными rapeed, чтобы вы получали истинное #удовольствие_от_аналитики.

Обновлено Руководство пользователя по версии rapeed 1.1. Доступно, как и раньше, на сайте.

На сайте в разделе Новости и статьи появилась масса полезной информации по продукту и эксплуатации rapeed: история версий, политики в отношении уязвимостей и обновлений, руководство по безопасной настройке, сетевые параметры и многое другое.
Документы предназначены для архитекторов, руководителей проектов и ИБ крупных компаний.

Тесты 1000 пользователей на одной машине
Мы сейчас проходим апробацию у одного крупного и очень уважаемого заказчика - одних требований ИБ насчитывается более ста пунктов. Поделюсь с вами в пятничный вечер результатами тестов качества ПО, которые предполагают одновременную работу множества пользователей с системой.
У заказчика выделена одна (мощная, но одна) машина под установку rapeed, поэтому изначально речь шла о 100 пользователях. Мы предложили сделать тесты на 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 пользователей параллельно»

Мне особенно нравятся две последние строчки) С предыдущих масштабных тестов прошло 1,5 года, и система фактически уже совсем другая. Но 100% надёжность осталась такой же.

Шутки вложенных показателей
Сегодня у нас был замечательный вопрос от заказчика: можно ли в одном столбце выводить то сумму, то количество, то среднее значение, или ещё что-то в зависимости от контекста того, что мы видим?
Результат заказчика полностью устроил и даже позабавил, а я решил с вами поделиться)
#удовольствие_от_аналитики

rapeed OLAP за 12 минут
Скорость и #удовольствие_от_аналитики можно ощутить только вживую. На этом видео в течение 12 минут (без единой склейки и монтажа) вы увидите, как работает rapeed с живыми данными: https://disk.yandex.ru/i/9PIvTkiIGD095Q

Сводная таблица Excel на данных rapeed
И для полного #удовольствие_от_аналитики - работа сводной таблицы Excel с данными rapeed: https://disk.yandex.ru/i/LaH1aUbBVnPpxA

Неправильные цифры в BI. Часть первая: ошибочное усреднение средних
Как правило, BI-продукты для бизнес-пользователей работают не на исходных массивах в миллиарды записей, а на таблицах в несколько миллионов строк, в которых основные бизнес-показатели уже предагрегированы и как-то сжаты. Всё вроде хорошо - всё летает и быстро считает. Но при этом всё, что не является суммами или количествами (то есть не является аддитивными показателями), в большинстве случаев считается неправильно. И это фундаментальная проблема подобного подхода.
Возьмём часто встречающийся в рознице показатель - средний чек. В банках это будет среднее время обслуживания или средняя сумма транзакции, в телекоме или e-commerce - средний доход на абонента (ARPU).
Я взял для примера 19 реальных строк чеков (см. скриншот) из 5 магазинов за разное время, даже годы разные. В двух чеках есть по два товара. Наша задача - посчитать средний чек по магазинам вообще, а также в разрезе лет и товарных подгрупп.
Очевидно, что
Средний чек = сумма продаж / количество уникальных чеков.
Если считать по исходным данным, то никаких проблем не возникает. Они возникают, когда исходных данных нет, а есть заранее посчитанные средние чеки за период, как делают практически все крупные ритейлеры.
В моём примере "заранее рассчитаны" средние чеки по магазинам по годам - потому что пользователи смотрят динамику средних чеков в разрезе лет, поэтому так и сохраняют в хранилище. И когда пользователь захочет посчитать средний чек по магазинам (то есть усреднить средние), он видит ошибочные данные. Посмотрите данные по магазинам АФ1, АФ2 и АФ3 - среднее за несколько периодов и реальное среднее показаны совпадающими цветами.
В жизни так и происходит - данные сжимают, усредняя по каким-то разрезам, неважно, по каким. И когда пользователи в процессе анализа смотрят эти данные хоть чуть-чуть по-другому, арифметика работает против них.