Обновлено Руководство пользователя по версии 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 (помните - в одном чеке были Овощи и Фрукты), и тогда «поедет» и итоговый средний чек. И это происходит сплошь и рядом, если расчёты идут по предагрегированным данным.

Неправильные цифры в BI. Часть четвертая: ловушка процентов и неаддитивных показателей
Еще один класс метрик, которые ломаются при сжатии данных - неаддитивные показатели, такие как конверсия (CR), рентабельность (Margin %) или удержание (Retention Rate).
Казалось бы, очевидно, что складывать или усреднять проценты нельзя. Но в классическом BI это происходит регулярно, когда система пытается работать с предагрегированными витринами.

Рассмотрим пример конверсии продаж. У нас есть два магазина:
Магазин А: Зашло 10 000 человек, купило 200. Конверсия = 2%.
Магазин Б: Зашло 10 человек, купило 5. Конверсия = 50%.
Если данные предагрегируются по датам, то в хранилище ложатся уже готовые проценты. Когда аналитик смотрит конверсию по сети в целом или даже по кусту магазинов, обычный BI либо сложит их (получив абсурдные 52%), либо усреднит по количеству строк ((2% + 50%) / 2 = 26%).
При этом реальная конверсия сети: 205 покупок / 10 010 посетителей = 2,05%.

BI-система, усреднив средние проценты, завысила метрику более чем в 10 раз, потому что потеряла «вес» каждого магазина. То же самое происходит с Retention Rate в когортном анализе - усреднение процентов между крупными и мелкими когортами дает искаженную картину удержания, скрывая реальные оттоки.
Единственное математически верное решение - рассчитывать такие неаддитивные показатели только на основе исходных данных и высчитывать процент только динамически, в момент построения виджета, подобно тому, как высчитывается показатель Обеспеченность в кратком демо-видео rapeed.

Неправильные цифры в BI. Часть пятая: ошибка бесконечных складов (полуаддитивные показатели)
Последний класс проблемных показателей, который я затрону - показатели состояния (snapshots). Это остатки товаров на складах, балансы банковских счетов, количество открытых кредитов.
Их называют полуаддитивными показателями. Причина проста: их можно складывать по объектам (например, суммировать остатки по всем магазинам сети), но их категорически нельзя складывать по оси времени. Если в понедельник на складе лежало 100 ноутбуков, и во вторник их стало 99, то за два дня у вас не стало 199 ноутбуков. Если BI-система просто просуммирует эти строки при просмотре отчета за неделю, бизнес получит ошибку бесконечного склада.
Для решения этой проблемы в классических архитектурах хранилищ строят отдельные, очень тяжелые таблицы-снапшоты (снимки на конец дня, недели, месяца). Но реальная жизнь быстро дискредитирует этот подход.
Рассмотрим простой пример. Мы хотим узнать остатки ноутбуков по сети на конец января.
Магазин №1 отработал штатно, его последняя запись в базе — 31 января, остаток: 10 штук.
Магазин №2 29 января ушел на инвентаризацию (или пропал мобильный интернет), кассы не передавали данные. Его последняя запись об остатках датирована 28 января, остаток: 5 штук.
Что сделает обычный BI? Если в нем настроен расчет "на конец месяца", он запросит данные строго на 31 января. Он найдет 10 ноутбуков в первом магазине, а во втором обнаружит пустоту (NULL). Итоговый отчет покажет 10 штук. Система только что "потеряла" товар на сотни тысяч рублей, потому что не умеет гибко искать ближайшую актуальную дату.
В многомерном MS OLAP (SSAS) для поиска последнего непустого значения по дате приходится прописывать тип агрегации LastNonEmpty глубоко в свойствах куба или писать многоэтажный код на MDX, например, такой:

CREATE MEMBER CURRENTCUBE.[Measures].[Остаток на конец периода] AS
NonEmpty(
Descendants(
[Date].[Calendar].CurrentMember,
[Date].[Calendar].[Date]
),
[Measures].[Базовый остаток]
),
1
).Item(0)
А в современных табличных моделях (DAX в Power BI и SSAS Tabular) пользователям нужно писать формулы с функцией LASTNONBLANK типа таких:
Остаток на конец периода =
CALCULATE (
SUM('Inventory'[Остаток]),
LASTNONBLANK (
'Calendar'[Date],
CALCULATE(SUM('Inventory'[Остаток]))
)
)
Эти вычисления громоздки, ресурсоёмки и требуют, чтобы пользователь был разработчиком и разбирался в нюансах конструкций CALCULATE и строении календарей.

В rapeed всё сделано очень просто - проблема полуаддитивности решается на лету на исходных данных с помощью специальных функций OnMaxDate (остаток на конец периода) и OnMinDate (остаток на начало периода). Никакой код писать не нужно. Всё работает само.

Как они работают? Функция OnMaxDate принимает ключевые параметры: что считаем, уровень валидности (например, составное поле store_id-sku_id) и поле даты.
Когда бизнес-пользователь в виджете выбирает период "Январь" или группирует таблицу по месяцам, rapeed не ищет данные тупо на 31-е число. Система берет заданный уровень валидности и формирует по нему временные коридоры. Внутри каждого коридора для каждого уникального товара в каждом магазине она находит его собственную максимальную дату, когда по нему были данные.
В нашем примере rapeed автоматически поймет, что для Магазина №1 максимальная дата в январе - это 31-е число (берем 10 штук), а для Магазина №2 максимальная дата в этом же коридоре - 28-е число (берем 5 штук).
Только после того, как система найдет эти актуальные срезы для каждого уровня валидности, она корректно их просуммирует. Итог для куста магазинов: 15 штук.
Пользователю больше не нужно думать о том, как правильно сжать данные или писать сложные MDX или DAX-запросы. При любом изменении временных периодов ядро rapeed само определяет их границы и динамически агрегирует остатки, гарантируя абсолютную математическую точность без потерь и задвоений.

Посмотрите это видео, чтобы понять, как можно проверить данные об остатках, меняя уровень валидности.

В этом видео по вашим просьбам показываю реальный расчёт количества уникальных чеков на миллиарде строк

Вот график загрузки ресурсов (процессора и памяти) на этих расчётах. Видно, что система загружает в память с диска, считает и освобождает память.

Неправильные вычисления в BI - теперь на Хабре
Вышла моя статья на Хабре про неправильные вычисления в BI. Примите участие в опросе!

TODAY
Очень часто клиентам нужно сравнить показатели одного периода с другим - например, средние продажи в день или среднюю цену за SKU за прошлый год и за текущий с учетом того, что текущий год еще не закончился. Это называется Y2Y-анализ.
В rapeed для гибкого управления периодами сравнения в формулах можно использовать функцию TODAY с выбором нужной части даты. Учитывая, что система всегда верно считает показатели любой сложности, можно достаточно гибко задавать условия на расчёт показателей, например, для выбора прошлого года такое:
YEAR (Поле Даты) = YEAR (TODAY) - 1
С помощью функций TODAY и NOW и неограниченной вложенности показателей в rapeed можно визуально конструировать сравнения любых периодов, как в примере на скриншоте.

Оглавление канала
История создания 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 - задание уровня валидности на лету
Выход rapeed 1.0
Выход rapeed 1.1 и по-настоящему быстрого и безграничного rapeed OLE DB Provider для Excel
Тесты 1000 одновременных пользователей на 1 машине
Видео-демонстрация основных возможностей rapeed за 12 минут и сводной таблицы Excel на данных rapeed за 2 минуты
Цикл постов «Неправильные цифры в BI» - вечно актуальная тема
Статья на Хабре про неправильные вычисления в BI

rapeed в «Кругах Громова» про self-service
Вышел обзор рынка self-service Круг Громова, где впервые представлен rapeed. Коллеги неплохо написали про наc, спасибо!