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

Неправильные цифры в 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. Примите участие в опросе!