Выход 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 - среднее за несколько периодов и реальное среднее показаны совпадающими цветами.
В жизни так и происходит - данные сжимают, усредняя по каким-то разрезам, неважно, по каким. И когда пользователи в процессе анализа смотрят эти данные хоть чуть-чуть по-другому, арифметика работает против них.

Неправильные цифры в BI. Часть вторая: ошибочные проверки усреднений
Продолжая пример выше: допустим, что у нас средние чеки сжимаются и хранятся по товарным подгруппам по годам (см. скриншот). Пользователь хочет посмотреть средний чек по подгруппам. Удивительно, но по подгруппе МЯСО ПТИЦА ЗАМОРОЖЕННЫЕ средний чек будет верным! Знаете, почему? Потому что случайно совпали знаменатели дробей, то есть количество чеков в годах. Среднее будет так же верным, если одно количество чеков будет нацело делиться на другое (дроби, математика 6й класс).
Поэтому, выборочно проверив усреднённое среднее, пользователь поверит, что оно считается верно, и будет дальше использовать его в расчётах. А реальные данные, как легко видеть, могут отличаться на десятки процентов! И это в то время, когда торговые сети борются за рост среднего чека на единицы процентов.
Желающие могут проверить правильность формул и расчётов, они в файле ниже.

Файл с данными и расчётами примеров выше

Неправильные цифры в BI. Часть третья: ошибочный подсчёт уникальных значений
Ранее мы разбирали, почему сжатые данные ломают арифметику средних значений. Кратко: A/B + C/D <> (A+B)/(C+D). Но есть еще одна частая бизнес-задача, с которой предагрегированные таблицы не справляются - это подсчёт уникальных объектов (count distinct) - покупателей, чеков, товаров и их различных признаков.
Если считать по исходным сырым данным, проблем нет. Они возникают, когда мы пытаемся получить уникальное количество из заранее агрегированных таблиц при переходе уникального значения между объектами агрегации.
Одно дело - складывать уникальные чеки по магазинам. Один чек гарантированно будет пробит только в одном конкретном магазине. Поэтому, если мы сложим количество уникальных чеков по всем магазинам, мы получим правильный общий итог.
Совсем другое дело - считать уникальные чеки по товарам или товарным группам. В одном чеке легко может быть несколько разных групп (второй чек из выделенных жирным в примере). Если данные сжимаются и хранятся в хранилище в разрезе товарных подгрупп, то этот чек будет добавлен в чеки и для овощей и для фруктов.
Давайте посмотрим на совсем простой пример. У нас есть три чека:

Исходные сырые данные

Номер чека Категория Сумма строки
Чек №101 Бакалея 150
Чек №101 Напитки 100
Чек №102 Напитки 200
Чек №103 Бакалея 300
Чек №103 Заморозка 400

Реальное количество уникальных чеков за день: 3.
Теперь представим, что классическая BI-система «сжала» эти данные для оптимизации и сложила их в витрину. Сырых данных больше нет:

Предагрегированная витрина

Категория Уникальных чеков (Count Distinct order_no)
Бакалея 2 (чеки 101, 103)
Напитки 2 (чеки 101, 102)
Заморозка 1 (чек 103)

Пока бизнес-пользователь смотрит на эту таблицу в разрезе категорий, всё абсолютно верно. Но как только он сворачивает таблицу, чтобы посмотреть общие итоги по магазину, BI-движок просто просуммирует колонку.
Итог BI-системы: 2 + 2 + 1 = 5 уникальных чеков. Реальность: 3 уникальных чека.

В своём примере я использовал последнюю версию Excel, которая уже умеет считать «Число разных значений» (count distinct). Предыдущая версия ещё не умела, а в этой при вставке сводной таблицы надо активировать галочку «Добавить эти данные в модель данных», что бы это ни значило. Тогда Excel верно считает количество уникальных чеков по исходным данным - их 17. Простое суммирование уникальных чеков по магазинам тоже даёт 17 (в одном чеке всегда один магазин). Но если считать, что сырых данных нет, и уникальные чеки сложить по подгруппам, то их станет 18 (помните - в одном чеке были Овощи и Фрукты), и тогда «поедет» и итоговый средний чек. И это происходит сплошь и рядом, если расчёты идут по предагрегированным данным.