Сводная таблица Excel на данных rapeed
И для полного #удовольствие_от_аналитики - работа сводной таблицы Excel с данными rapeed: https://disk.yandex.ru/i/LaH1aUbBVnPpxA
И для полного #удовольствие_от_аналитики - работа сводной таблицы Excel с данными rapeed: https://disk.yandex.ru/i/LaH1aUbBVnPpxA
Яндекс Диск
Excel Pivot Demo.mov
Посмотреть и скачать с Яндекс Диска
👍3
Неправильные цифры в BI. Часть первая: ошибочное усреднение средних
Как правило, BI-продукты для бизнес-пользователей работают не на исходных массивах в миллиарды записей, а на таблицах в несколько миллионов строк, в которых основные бизнес-показатели уже предагрегированы и как-то сжаты. Всё вроде хорошо - всё летает и быстро считает. Но при этом всё, что не является суммами или количествами (то есть не является аддитивными показателями), в большинстве случаев считается неправильно. И это фундаментальная проблема подобного подхода.
Возьмём часто встречающийся в рознице показатель - средний чек. В банках это будет среднее время обслуживания или средняя сумма транзакции, в телекоме или e-commerce - средний доход на абонента (ARPU).
Я взял для примера 19 реальных строк чеков (см. скриншот) из 5 магазинов за разное время, даже годы разные. В двух чеках есть по два товара. Наша задача - посчитать средний чек по магазинам вообще, а также в разрезе лет и товарных подгрупп.
Очевидно, что
Если считать по исходным данным, то никаких проблем не возникает. Они возникают, когда исходных данных нет, а есть заранее посчитанные средние чеки за период, как делают практически все крупные ритейлеры.
В моём примере "заранее рассчитаны" средние чеки по магазинам по годам - потому что пользователи смотрят динамику средних чеков в разрезе лет, поэтому так и сохраняют в хранилище. И когда пользователь захочет посчитать средний чек по магазинам (то есть усреднить средние), он видит ошибочные данные. Посмотрите данные по магазинам АФ1, АФ2 и АФ3 - среднее за несколько периодов и реальное среднее показаны совпадающими цветами.
В жизни так и происходит - данные сжимают, усредняя по каким-то разрезам, неважно, по каким. И когда пользователи в процессе анализа смотрят эти данные хоть чуть-чуть по-другому, арифметика работает против них.
Как правило, BI-продукты для бизнес-пользователей работают не на исходных массивах в миллиарды записей, а на таблицах в несколько миллионов строк, в которых основные бизнес-показатели уже предагрегированы и как-то сжаты. Всё вроде хорошо - всё летает и быстро считает. Но при этом всё, что не является суммами или количествами (то есть не является аддитивными показателями), в большинстве случаев считается неправильно. И это фундаментальная проблема подобного подхода.
Возьмём часто встречающийся в рознице показатель - средний чек. В банках это будет среднее время обслуживания или средняя сумма транзакции, в телекоме или e-commerce - средний доход на абонента (ARPU).
Я взял для примера 19 реальных строк чеков (см. скриншот) из 5 магазинов за разное время, даже годы разные. В двух чеках есть по два товара. Наша задача - посчитать средний чек по магазинам вообще, а также в разрезе лет и товарных подгрупп.
Очевидно, что
Средний чек = сумма продаж / количество уникальных чеков.Если считать по исходным данным, то никаких проблем не возникает. Они возникают, когда исходных данных нет, а есть заранее посчитанные средние чеки за период, как делают практически все крупные ритейлеры.
В моём примере "заранее рассчитаны" средние чеки по магазинам по годам - потому что пользователи смотрят динамику средних чеков в разрезе лет, поэтому так и сохраняют в хранилище. И когда пользователь захочет посчитать средний чек по магазинам (то есть усреднить средние), он видит ошибочные данные. Посмотрите данные по магазинам АФ1, АФ2 и АФ3 - среднее за несколько периодов и реальное среднее показаны совпадающими цветами.
В жизни так и происходит - данные сжимают, усредняя по каким-то разрезам, неважно, по каким. И когда пользователи в процессе анализа смотрят эти данные хоть чуть-чуть по-другому, арифметика работает против них.
👍2🔥1
Неправильные цифры в BI. Часть вторая: ошибочные проверки усреднений
Продолжая пример выше: допустим, что у нас средние чеки сжимаются и хранятся по товарным подгруппам по годам (см. скриншот). Пользователь хочет посмотреть средний чек по подгруппам. Удивительно, но по подгруппе МЯСО ПТИЦА ЗАМОРОЖЕННЫЕ средний чек будет верным! Знаете, почему? Потому что случайно совпали знаменатели дробей, то есть количество чеков в годах. Среднее будет так же верным, если одно количество чеков будет нацело делиться на другое (дроби, математика 6й класс).
Поэтому, выборочно проверив усреднённое среднее, пользователь поверит, что оно считается верно, и будет дальше использовать его в расчётах. А реальные данные, как легко видеть, могут отличаться на десятки процентов! И это в то время, когда торговые сети борются за рост среднего чека на единицы процентов.
Желающие могут проверить правильность формул и расчётов, они в файле ниже.
Продолжая пример выше: допустим, что у нас средние чеки сжимаются и хранятся по товарным подгруппам по годам (см. скриншот). Пользователь хочет посмотреть средний чек по подгруппам. Удивительно, но по подгруппе МЯСО ПТИЦА ЗАМОРОЖЕННЫЕ средний чек будет верным! Знаете, почему? Потому что случайно совпали знаменатели дробей, то есть количество чеков в годах. Среднее будет так же верным, если одно количество чеков будет нацело делиться на другое (дроби, математика 6й класс).
Поэтому, выборочно проверив усреднённое среднее, пользователь поверит, что оно считается верно, и будет дальше использовать его в расчётах. А реальные данные, как легко видеть, могут отличаться на десятки процентов! И это в то время, когда торговые сети борются за рост среднего чека на единицы процентов.
Желающие могут проверить правильность формул и расчётов, они в файле ниже.
👍3🔥2
Неправильные цифры в BI. Часть третья: ошибочный подсчёт уникальных значений
Ранее мы разбирали, почему сжатые данные ломают арифметику средних значений. Кратко: A/B + C/D <> (A+B)/(C+D). Но есть еще одна частая бизнес-задача, с которой предагрегированные таблицы не справляются - это подсчёт уникальных объектов (count distinct) - покупателей, чеков, товаров и их различных признаков.
Если считать по исходным сырым данным, проблем нет. Они возникают, когда мы пытаемся получить уникальное количество из заранее агрегированных таблиц при переходе уникального значения между объектами агрегации.
Одно дело - складывать уникальные чеки по магазинам. Один чек гарантированно будет пробит только в одном конкретном магазине. Поэтому, если мы сложим количество уникальных чеков по всем магазинам, мы получим правильный общий итог.
Совсем другое дело - считать уникальные чеки по товарам или товарным группам. В одном чеке легко может быть несколько разных групп (второй чек из выделенных жирным в примере). Если данные сжимаются и хранятся в хранилище в разрезе товарных подгрупп, то этот чек будет добавлен в чеки и для овощей и для фруктов.
Давайте посмотрим на совсем простой пример. У нас есть три чека:
Исходные сырые данные
Теперь представим, что классическая BI-система «сжала» эти данные для оптимизации и сложила их в витрину. Сырых данных больше нет:
Предагрегированная витрина
Пока бизнес-пользователь смотрит на эту таблицу в разрезе категорий, всё абсолютно верно. Но как только он сворачивает таблицу, чтобы посмотреть общие итоги по магазину, BI-движок просто просуммирует колонку.
Итог BI-системы: 2 + 2 + 1 = 5 уникальных чеков. Реальность: 3 уникальных чека.
В своём примере я использовал последнюю версию Excel, которая уже умеет считать «Число разных значений» (count distinct). Предыдущая версия ещё не умела, а в этой при вставке сводной таблицы надо активировать галочку «Добавить эти данные в модель данных», что бы это ни значило. Тогда Excel верно считает количество уникальных чеков по исходным данным - их 17. Простое суммирование уникальных чеков по магазинам тоже даёт 17 (в одном чеке всегда один магазин). Но если считать, что сырых данных нет, и уникальные чеки сложить по подгруппам, то их станет 18 (помните - в одном чеке были Овощи и Фрукты), и тогда «поедет» и итоговый средний чек. И это происходит сплошь и рядом, если расчёты идут по предагрегированным данным.
Ранее мы разбирали, почему сжатые данные ломают арифметику средних значений. Кратко: A/B + C/D <> (A+B)/(C+D). Но есть еще одна частая бизнес-задача, с которой предагрегированные таблицы не справляются - это подсчёт уникальных объектов (count distinct) - покупателей, чеков, товаров и их различных признаков.
Если считать по исходным сырым данным, проблем нет. Они возникают, когда мы пытаемся получить уникальное количество из заранее агрегированных таблиц при переходе уникального значения между объектами агрегации.
Одно дело - складывать уникальные чеки по магазинам. Один чек гарантированно будет пробит только в одном конкретном магазине. Поэтому, если мы сложим количество уникальных чеков по всем магазинам, мы получим правильный общий итог.
Совсем другое дело - считать уникальные чеки по товарам или товарным группам. В одном чеке легко может быть несколько разных групп (второй чек из выделенных жирным в примере). Если данные сжимаются и хранятся в хранилище в разрезе товарных подгрупп, то этот чек будет добавлен в чеки и для овощей и для фруктов.
Давайте посмотрим на совсем простой пример. У нас есть три чека:
Исходные сырые данные
Номер чека Категория Сумма строки
Чек №101 Бакалея 150
Чек №101 Напитки 100
Чек №102 Напитки 200
Чек №103 Бакалея 300
Чек №103 Заморозка 400
Теперь представим, что классическая 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 (помните - в одном чеке были Овощи и Фрукты), и тогда «поедет» и итоговый средний чек. И это происходит сплошь и рядом, если расчёты идут по предагрегированным данным.
👍4❤2🔥1🥰1
Неправильные цифры в 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.
Еще один класс метрик, которые ломаются при сжатии данных - неаддитивные показатели, такие как конверсия (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.
👍2🔥2❤1🥰1
Неправильные цифры в BI. Часть пятая: ошибка бесконечных складов (полуаддитивные показатели)
Последний класс проблемных показателей, который я затрону - показатели состояния (snapshots). Это остатки товаров на складах, балансы банковских счетов, количество открытых кредитов.
Их называют полуаддитивными показателями. Причина проста: их можно складывать по объектам (например, суммировать остатки по всем магазинам сети), но их категорически нельзя складывать по оси времени. Если в понедельник на складе лежало 100 ноутбуков, и во вторник их стало 99, то за два дня у вас не стало 199 ноутбуков. Если BI-система просто просуммирует эти строки при просмотре отчета за неделю, бизнес получит ошибку бесконечного склада.
Для решения этой проблемы в классических архитектурах хранилищ строят отдельные, очень тяжелые таблицы-снапшоты (снимки на конец дня, недели, месяца). Но реальная жизнь быстро дискредитирует этот подход.
Рассмотрим простой пример. Мы хотим узнать остатки ноутбуков по сети на конец января.
Магазин №1 отработал штатно, его последняя запись в базе — 31 января, остаток: 10 штук.
Магазин №2 29 января ушел на инвентаризацию (или пропал мобильный интернет), кассы не передавали данные. Его последняя запись об остатках датирована 28 января, остаток: 5 штук.
Что сделает обычный BI? Если в нем настроен расчет "на конец месяца", он запросит данные строго на 31 января. Он найдет 10 ноутбуков в первом магазине, а во втором обнаружит пустоту (NULL). Итоговый отчет покажет 10 штук. Система только что "потеряла" товар на сотни тысяч рублей, потому что не умеет гибко искать ближайшую актуальную дату.
В многомерном MS OLAP (SSAS) для поиска последнего непустого значения по дате приходится прописывать тип агрегации
А в современных табличных моделях (DAX в Power BI и SSAS Tabular) пользователям нужно писать формулы с функцией LASTNONBLANK типа таких:
Эти вычисления громоздки, ресурсоёмки и требуют, чтобы пользователь был разработчиком и разбирался в нюансах конструкций CALCULATE и строении календарей.
В rapeed всё сделано очень просто - проблема полуаддитивности решается на лету на исходных данных с помощью специальных функций OnMaxDate (остаток на конец периода) и OnMinDate (остаток на начало периода). Никакой код писать не нужно. Всё работает само.
Как они работают? Функция OnMaxDate принимает ключевые параметры: что считаем, уровень валидности (например, составное поле store_id-sku_id) и поле даты.
Когда бизнес-пользователь в виджете выбирает период "Январь" или группирует таблицу по месяцам, rapeed не ищет данные тупо на 31-е число. Система берет заданный уровень валидности и формирует по нему временные коридоры. Внутри каждого коридора для каждого уникального товара в каждом магазине она находит его собственную максимальную дату, когда по нему были данные.
В нашем примере rapeed автоматически поймет, что для Магазина №1 максимальная дата в январе - это 31-е число (берем 10 штук), а для Магазина №2 максимальная дата в этом же коридоре - 28-е число (берем 5 штук).
Только после того, как система найдет эти актуальные срезы для каждого уровня валидности, она корректно их просуммирует. Итог для куста магазинов: 15 штук.
Пользователю больше не нужно думать о том, как правильно сжать данные или писать сложные MDX или DAX-запросы. При любом изменении временных периодов ядро rapeed само определяет их границы и динамически агрегирует остатки, гарантируя абсолютную математическую точность без потерь и задвоений.
Последний класс проблемных показателей, который я затрону - показатели состояния (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 само определяет их границы и динамически агрегирует остатки, гарантируя абсолютную математическую точность без потерь и задвоений.
👍3🔥3👎1
Media is too big
VIEW IN TELEGRAM
Посмотрите это видео, чтобы понять, как можно проверить данные об остатках, меняя уровень валидности.
🔥3👍1
rapeed
Неправильные цифры в BI. Часть третья: ошибочный подсчёт уникальных значений Ранее мы разбирали, почему сжатые данные ломают арифметику средних значений. Кратко: A/B + C/D <> (A+B)/(C+D). Но есть еще одна частая бизнес-задача, с которой предагрегированные…
Media is too big
VIEW IN TELEGRAM
В этом видео по вашим просьбам показываю реальный расчёт количества уникальных чеков на миллиарде строк
🔥3👍2
Неправильные вычисления в BI - теперь на Хабре
Вышла моя статья на Хабре про неправильные вычисления в BI. Примите участие в опросе!
Вышла моя статья на Хабре про неправильные вычисления в BI. Примите участие в опросе!
🔥7👍3
TODAY
Очень часто клиентам нужно сравнить показатели одного периода с другим - например, средние продажи в день или среднюю цену за SKU за прошлый год и за текущий с учетом того, что текущий год еще не закончился. Это называется Y2Y-анализ.
В rapeed для гибкого управления периодами сравнения в формулах можно использовать функцию TODAY с выбором нужной части даты. Учитывая, что система всегда верно считает показатели любой сложности, можно достаточно гибко задавать условия на расчёт показателей, например, для выбора прошлого года такое:
С помощью функций TODAY и NOW и неограниченной вложенности показателей в rapeed можно визуально конструировать сравнения любых периодов, как в примере на скриншоте.
Очень часто клиентам нужно сравнить показатели одного периода с другим - например, средние продажи в день или среднюю цену за SKU за прошлый год и за текущий с учетом того, что текущий год еще не закончился. Это называется Y2Y-анализ.
В rapeed для гибкого управления периодами сравнения в формулах можно использовать функцию TODAY с выбором нужной части даты. Учитывая, что система всегда верно считает показатели любой сложности, можно достаточно гибко задавать условия на расчёт показателей, например, для выбора прошлого года такое:
YEAR (Поле Даты) = YEAR (TODAY) - 1С помощью функций TODAY и NOW и неограниченной вложенности показателей в rapeed можно визуально конструировать сравнения любых периодов, как в примере на скриншоте.
👍3
Оглавление канала
История создания 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
Основные проблемы, для решения которых создавался 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
🔥2👏1
rapeed в «Кругах Громова» про self-service
Вышел обзор рынка self-service Круг Громова, где впервые представлен rapeed. Коллеги неплохо написали про наc, спасибо!
Вышел обзор рынка self-service Круг Громова, где впервые представлен rapeed. Коллеги неплохо написали про наc, спасибо!
👍3🤝3🔥2
Forwarded from Круги Громова | Data & AI Research
Оно показывает, как российские платформы помогают бизнес-пользователям работать автономно во всей архитектуре данных, а не только в BI.
В отчет вошло 20+ российских решений: от BI, ETL и IBP-систем до облачных сервисов и платформ по работе с семантическим слоем. Среди которых: Yandex DataLens, Modus BI/ETL, Loginom, Dat. ax, DataForge,Visiology, PIX BI, Rapeed и другие.
➡️ Отчет поможет понять:
– где self-service – реальная управляемая модель, а где – набор разрозненных функций или маркетинговая декларация,
– какие элементы инфраструктуры критичны и как безопасно интегрировать AI,
– как балансировать свободу пользователя и управляемость среды.➡️ Особое внимание уделено:
– AI в self-service: без бизнес-контекста AI может давать убедительные, но неверные ответы.
– и семантическому слою: пользователю недостаточно просто дать доступ к данным; нужно зафиксировать показатели, правила расчета, связи и ограничения интерпретации.
Используйте готовые ориентиры для оценки зрелости self-service в вашей компании.
Круги Громова | Подписаться и стать частью Data-сообщества
#КругиГромова #ИИ #AgenticAI #SelfService #SemanticLayer
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3👍1
Обзор rapeed на Хабре - впервые про AI
На Хабре вышла статья наших партнёров, ИТ-интегратора «Белый код», посвящённая детальному описанию и анализу rapeed. Партнёры впервые озвучили наш подход к встраиванию AI-агентов в rapeed, в отличие от использования AI в других продуктах, работающих в SQL-парадигме.
Спасибо, партнёры!
На Хабре вышла статья наших партнёров, ИТ-интегратора «Белый код», посвящённая детальному описанию и анализу rapeed. Партнёры впервые озвучили наш подход к встраиванию AI-агентов в rapeed, в отличие от использования AI в других продуктах, работающих в SQL-парадигме.
Спасибо, партнёры!
👍7🤝1
Новый релиз rapeed: справедливая балансировка для 42 миллионов запросов и 5 недель предельной нагрузки
Только что успешно завершилась самая жёсткая программа стресс-тестирования выходящего релиза в истории платформы.
За 5 недель на нашем тестовом кластере выполнилось 42 миллиона запросов в 7 800 сценариях. При 200 одновременных пользователях кластер стабильно обрабатывал до 872 запросов в секунду с нулевым количеством ошибок. Максимальный непрерывный прогон составил 12,1 часа - и всё без единого сбоя.
Самым главным отличием выходящего релиза rapeed является качественный скачок в управлении вычислительными ресурсами - сейчас система, как рачительный хозяин, знает свой бюджет памяти на каждой ноде и может в зависимости от него управлять очередью задач. Одному тяжёлому запросу можно выделить столько ресурсов, чтобы на его времени выполнения это почти не отразилось, а обычные расчёты пользователей (которые раньше его бы ждали) получат при этом прирост скорости до 150%. Мы назвали этот механизм «справедливая балансировка».
Новый релиз rapeed, помимо бюджетирования ресурсов, содержит огромное количество новых функций, поэтому ему присвоен номер 1.6.
О новых возможностях выходящего совсем скоро rapeed 1.6 подробно расскажу в следующих постах. Будет много неожиданного!
Только что успешно завершилась самая жёсткая программа стресс-тестирования выходящего релиза в истории платформы.
За 5 недель на нашем тестовом кластере выполнилось 42 миллиона запросов в 7 800 сценариях. При 200 одновременных пользователях кластер стабильно обрабатывал до 872 запросов в секунду с нулевым количеством ошибок. Максимальный непрерывный прогон составил 12,1 часа - и всё без единого сбоя.
Самым главным отличием выходящего релиза rapeed является качественный скачок в управлении вычислительными ресурсами - сейчас система, как рачительный хозяин, знает свой бюджет памяти на каждой ноде и может в зависимости от него управлять очередью задач. Одному тяжёлому запросу можно выделить столько ресурсов, чтобы на его времени выполнения это почти не отразилось, а обычные расчёты пользователей (которые раньше его бы ждали) получат при этом прирост скорости до 150%. Мы назвали этот механизм «справедливая балансировка».
Новый релиз rapeed, помимо бюджетирования ресурсов, содержит огромное количество новых функций, поэтому ему присвоен номер 1.6.
О новых возможностях выходящего совсем скоро rapeed 1.6 подробно расскажу в следующих постах. Будет много неожиданного!
🔥8👍3🤝3
Новый интерфейс rapeed 1.6: темы и поддержка корпоративных стилей, переход на единый UI Kit и универсальный движок панелей
В выходящем релизе rapeed 1.6 мы не просто «освежили дизайн», а провели честный 100% рефакторинг всего UI, переведя платформу на единый UI Kit.
Все визуальные элементы инвентаризированы по всей системе и вынесены в StoryBook - наш интерактивный каталог компонентов.
Что это даёт на практике?
Монолитность: левая боковая панель, меню, списки и все окна собираются из одних и тех же базовых блоков. Интерфейс выглядит и реагирует на действия ожидаемо и одинаково в любом разделе системы.
Темы оформления: интерфейс полноценно поддерживает темы - от тёмной темы для снижения нагрузки на глаза аналитиков - полуночников до новых светлых палитр. У некоторых пользователей бывают особенности и ограниченности зрительного восприятия - для них добавлены контрастная тема и ещё три специфических.
Корпоративный стиль: благодаря единому UI Kit система теперь мгновенно адаптируется под любой корпоративный стиль (брендбук). Меняете базовые элементы и их параметры - и вся платформа выглядит так, будто создавалась специально для вашей компании.
Теперь движок рабочих областей, панелей виджетов и области связей единый: Miro-подобные (или Figma-подобные, как кому больше нравится) бесконечные рабочие области полностью консистентны с панелями виджетов и областями связей - например, если вы меняете масштаб колёсиком мыши или тачпадом, то он одинаково плавно меняется и у графика, и у панели, и у области связей, вложенных друг в друга. Единое «умное выравнивание», как в PowerPoint, сильно экономит время - привязка и направляющие одинаково работают между панелями виджетов, внутри панелей для виджетов и для столбцов/строк внутри области связей.
Далее расскажу о новых возможностях настройки и администрирования rapeed 1.6.
В выходящем релизе rapeed 1.6 мы не просто «освежили дизайн», а провели честный 100% рефакторинг всего UI, переведя платформу на единый UI Kit.
Все визуальные элементы инвентаризированы по всей системе и вынесены в StoryBook - наш интерактивный каталог компонентов.
Что это даёт на практике?
Монолитность: левая боковая панель, меню, списки и все окна собираются из одних и тех же базовых блоков. Интерфейс выглядит и реагирует на действия ожидаемо и одинаково в любом разделе системы.
Темы оформления: интерфейс полноценно поддерживает темы - от тёмной темы для снижения нагрузки на глаза аналитиков - полуночников до новых светлых палитр. У некоторых пользователей бывают особенности и ограниченности зрительного восприятия - для них добавлены контрастная тема и ещё три специфических.
Корпоративный стиль: благодаря единому UI Kit система теперь мгновенно адаптируется под любой корпоративный стиль (брендбук). Меняете базовые элементы и их параметры - и вся платформа выглядит так, будто создавалась специально для вашей компании.
Теперь движок рабочих областей, панелей виджетов и области связей единый: Miro-подобные (или Figma-подобные, как кому больше нравится) бесконечные рабочие области полностью консистентны с панелями виджетов и областями связей - например, если вы меняете масштаб колёсиком мыши или тачпадом, то он одинаково плавно меняется и у графика, и у панели, и у области связей, вложенных друг в друга. Единое «умное выравнивание», как в PowerPoint, сильно экономит время - привязка и направляющие одинаково работают между панелями виджетов, внутри панелей для виджетов и для столбцов/строк внутри области связей.
Далее расскажу о новых возможностях настройки и администрирования rapeed 1.6.
👍5🔥5👏1
Администрирование rapeed 1.6: полный контроль ресурсов и настройка ядра из интерфейса
В релизе 1.6 управление производительностью сложного вычислительного кластера теперь не требует ручной правки конфигурационных файлов в терминале или перезапуска сервисов. Все средства администрирования объединены в единую панель, полностью переведённую на новый UI Kit.
Теперь администраторам системы доступно:
Тонкая настройка ядра «на лету»: В разделе «Конфигурация» лимиты параллелизма, таймауты, форматы логов и режимы управления памятью меняются прямо из интерфейса. Параметры динамически применяются ко всем узлам кластера. При этом система сама подбирает рекомендуемые значения параметров в зависимости от модели процессора и других характеристик компьютеров.
Online-мониторинг операций: Вкладка «Операции» в реальном времени показывает всё, что обрабатывается ядром в данный момент. Администратор видит динамику нагрузки и, если пользователь запустил аномально тяжёлый запрос, может принудительно остановить эту операцию одной кнопкой. Здесь же доступен архив всех расчётных операций пользователей за всё время в разрезе рабочих областей.
Контроль пользовательских рабочих областей: Прямо в карточке конкретного пользователя администратор теперь видит структуру его рабочих областей, панелей и виджетов. Это в разы ускоряет разбор обращений в техподдержку, помощь в настройке панелей виджетов и внутренний аудит.
Гибкое управление доступом: Новый интерфейс вкладки «Пользователи и группы» работает в наглядном режиме master-detail. Права доступа к данным теперь удобно назначать сразу на уровне групп, в том числе копированием, объединением и переназначением прав.
По требованиям информационной безопасности все значимые действия администраторов автоматически пишутся в сквозной журнал аудита. А из текстов ошибок, которые видят конечные пользователи, полностью вычищены любые внутренние технические детали — адреса, пути и служебные данные.
Далее расскажу про финальную версию rapeed Pivot - веб-заменитель сводных таблиц Excel, а также новые возможности Add-On к Excel.
В релизе 1.6 управление производительностью сложного вычислительного кластера теперь не требует ручной правки конфигурационных файлов в терминале или перезапуска сервисов. Все средства администрирования объединены в единую панель, полностью переведённую на новый UI Kit.
Теперь администраторам системы доступно:
Тонкая настройка ядра «на лету»: В разделе «Конфигурация» лимиты параллелизма, таймауты, форматы логов и режимы управления памятью меняются прямо из интерфейса. Параметры динамически применяются ко всем узлам кластера. При этом система сама подбирает рекомендуемые значения параметров в зависимости от модели процессора и других характеристик компьютеров.
Online-мониторинг операций: Вкладка «Операции» в реальном времени показывает всё, что обрабатывается ядром в данный момент. Администратор видит динамику нагрузки и, если пользователь запустил аномально тяжёлый запрос, может принудительно остановить эту операцию одной кнопкой. Здесь же доступен архив всех расчётных операций пользователей за всё время в разрезе рабочих областей.
Контроль пользовательских рабочих областей: Прямо в карточке конкретного пользователя администратор теперь видит структуру его рабочих областей, панелей и виджетов. Это в разы ускоряет разбор обращений в техподдержку, помощь в настройке панелей виджетов и внутренний аудит.
Гибкое управление доступом: Новый интерфейс вкладки «Пользователи и группы» работает в наглядном режиме master-detail. Права доступа к данным теперь удобно назначать сразу на уровне групп, в том числе копированием, объединением и переназначением прав.
По требованиям информационной безопасности все значимые действия администраторов автоматически пишутся в сквозной журнал аудита. А из текстов ошибок, которые видят конечные пользователи, полностью вычищены любые внутренние технические детали — адреса, пути и служебные данные.
Далее расскажу про финальную версию rapeed Pivot - веб-заменитель сводных таблиц Excel, а также новые возможности Add-On к Excel.
🔥7👏1
Сводные таблицы в rapeed 1.6: полностью интегрированный Pivot и сверхбыстрый, простой в установке Add-On для Excel
В релизе 1.6 полностью убрана функциональная грань между основным интерфейсом платформы (виджетом «Сводная таблица») и двумя другими видами работы со сводными данными: rapeed Pivot - веб-аналог сводной таблицы Excel (для тех, кто с него ушёл, но скучает), и оригинальной сводной таблицы Microsoft Excel.
rapeed Pivot — веб-заменитель сводных таблиц:
• Никаких ограничений: rapeed Pivot полностью переведён на общие компоненты платформы. Теперь в нём доступны все функции основного приложения: создание составных полей, подключение справочников, настройка связей и построитель формул.
• Единый интерфейс: Системная боковая панель и та же навигация дополняют UX от сводной таблицы Excel.
Проще говоря, получился полный аналог сводной таблицы Excel в веб-окружении и со всеми функциями rapeed.
Обновление rapeed OLE DB Provider для Excel и плагина:
• Построение одним запросом: Сводная таблица теперь заполняется одним массированным запросом, а не десятками мелких — скорость выросла многократно даже по сравнению с версией 1.1. где это было впервые реализовано. Это ответ на вопрос, почему у нас именно OLE DB Provider, а не XMLA, имитирующее соединение с MS SSAS - просто сравните скорость работы Excel хотя бы на десятках тысяч строк.
• Интерфейс Excel не блокируется при расчётах ядра: в Excel можно продолжать работать, пока идут вычисления - и при медленной сети, и при самых тяжёлых вычислениях ядра.
• Настройки Add-On: все настройки Add-On и самого OLE DB Provider сведены в одно окно, где их можно легко менять - количество строк (выставлено на максимум 1 048 576) и столбцов (выставлено на 200, можно изменить при необходимости), уровень логирования, количество строк в ответе Drill-Through, тайм-ауты и время повторных запросов. Значения настроек подобраны такие, что их никто не меняет.
• Пользовательская и групповая установка: основной аргумент сторонников XMLA был в том, что для установки OLE DB требовались права администратора машины. Мы это изменили - плагин сейчас ставится в пользовательском режиме (per-user) и больше не требует прав администратора. Также доступна массовая установка плагина на сотни пользовательских машин с помощью групповых политик. Поэтому пользователю устанавливать ничего не надо, но при этом он получает многократное ускорение работы (заполнение данными) сводной таблицы.
А дальше начинается самое интересное в rapeed 1.6 - как многоуровневые, многомерные и «много-показательные» (multi-measure) данные сводных таблиц красиво и быстро презентовать. Тут только одним следующим постом не обойтись!
В релизе 1.6 полностью убрана функциональная грань между основным интерфейсом платформы (виджетом «Сводная таблица») и двумя другими видами работы со сводными данными: rapeed Pivot - веб-аналог сводной таблицы Excel (для тех, кто с него ушёл, но скучает), и оригинальной сводной таблицы Microsoft Excel.
rapeed Pivot — веб-заменитель сводных таблиц:
• Никаких ограничений: rapeed Pivot полностью переведён на общие компоненты платформы. Теперь в нём доступны все функции основного приложения: создание составных полей, подключение справочников, настройка связей и построитель формул.
• Единый интерфейс: Системная боковая панель и та же навигация дополняют UX от сводной таблицы Excel.
Проще говоря, получился полный аналог сводной таблицы Excel в веб-окружении и со всеми функциями rapeed.
Обновление rapeed OLE DB Provider для Excel и плагина:
• Построение одним запросом: Сводная таблица теперь заполняется одним массированным запросом, а не десятками мелких — скорость выросла многократно даже по сравнению с версией 1.1. где это было впервые реализовано. Это ответ на вопрос, почему у нас именно OLE DB Provider, а не XMLA, имитирующее соединение с MS SSAS - просто сравните скорость работы Excel хотя бы на десятках тысяч строк.
• Интерфейс Excel не блокируется при расчётах ядра: в Excel можно продолжать работать, пока идут вычисления - и при медленной сети, и при самых тяжёлых вычислениях ядра.
• Настройки Add-On: все настройки Add-On и самого OLE DB Provider сведены в одно окно, где их можно легко менять - количество строк (выставлено на максимум 1 048 576) и столбцов (выставлено на 200, можно изменить при необходимости), уровень логирования, количество строк в ответе Drill-Through, тайм-ауты и время повторных запросов. Значения настроек подобраны такие, что их никто не меняет.
• Пользовательская и групповая установка: основной аргумент сторонников XMLA был в том, что для установки OLE DB требовались права администратора машины. Мы это изменили - плагин сейчас ставится в пользовательском режиме (per-user) и больше не требует прав администратора. Также доступна массовая установка плагина на сотни пользовательских машин с помощью групповых политик. Поэтому пользователю устанавливать ничего не надо, но при этом он получает многократное ускорение работы (заполнение данными) сводной таблицы.
А дальше начинается самое интересное в rapeed 1.6 - как многоуровневые, многомерные и «много-показательные» (multi-measure) данные сводных таблиц красиво и быстро презентовать. Тут только одним следующим постом не обойтись!
🔥6❤4👏1
rapeed BI: предыстория
Когда стало понятно, что в сводной таблице rapeed можно соединить несоединимое любые показатели в любых разрезах без искажений, я задался вопросом: как можно корректно (без искажений) и просто визуализировать данные сводной таблицы? Она же многомерная, многоуровневая и показателей в ней много, причем у каждого свои оси.
Мониторы у нас плоские. Даже не так - у нас два глаза, расположенные в одной плоскости лица, и именно поэтому у нас плоские экраны. Всё, что связано с 3D, движением и нелинейными размерами, порождается исключительно когнитивными функциями мозга и, стало быть, подвержено когнитивным искажениям. Только сравнение линейных и точечных объектов на плоскости не подвержено искажениям, поэтому основу визуализации данных в бизнесе составляют линейные и точечные графики. Даже площади, особенно круглых фигур, мозг интерпретирует неверно. Углы наклона тоже (вспомним спидометры - почему положение рекомендуемой скорости у них всегда на уровне 10 часов? - чтобы отклонение от неё наиболее явно фиксировалось мозгом). Этим активно пользуются при намеренном искажении информации с помощью нехитрых фокусов, о которых написано очень много.
Я раньше увлекался созданием графиков, которые отображали больше трёх показателей сразу. Разноцветные шары разного размера, висящие в трехмерном пространстве (5 показателей - 3 оси, размер и цвет), и особенно «кольца на цилиндрах», отображавшие 8 показателей сразу (если интересно, в комментариях напишите, найду в архивах). Это было прикольно, но очень сложно для интерпретации - и этим никто не пользовался.
Поэтому отображение многоуровневых многофакторных данных должно использовать средства визуализации, где искажение восприятия данных сведено к минимуму. Их оказалось немало - различные линейные, точечные, диапазонные графики (в том числе универсальный комбо-график, где на одной основе можно вывести любую комбинацию этих типов), графики распределения и связей (Солнечный луч, Радар, Санкей, Хорда, заново изобретённая Орбитальная диаграмма, которая получилась очень удачной) - всего в выходящем rapeed BI 28 разных типов графиков.
Но самое главное - как создавать, менять и перестраивать все эти графики при изменении данных или настроения? Что, каждый график надо настраивать? Нет! В этом основная фишка rapeed BI. И об этом будет следующий пост.
Когда стало понятно, что в сводной таблице rapeed можно соединить несоединимое любые показатели в любых разрезах без искажений, я задался вопросом: как можно корректно (без искажений) и просто визуализировать данные сводной таблицы? Она же многомерная, многоуровневая и показателей в ней много, причем у каждого свои оси.
Мониторы у нас плоские. Даже не так - у нас два глаза, расположенные в одной плоскости лица, и именно поэтому у нас плоские экраны. Всё, что связано с 3D, движением и нелинейными размерами, порождается исключительно когнитивными функциями мозга и, стало быть, подвержено когнитивным искажениям. Только сравнение линейных и точечных объектов на плоскости не подвержено искажениям, поэтому основу визуализации данных в бизнесе составляют линейные и точечные графики. Даже площади, особенно круглых фигур, мозг интерпретирует неверно. Углы наклона тоже (вспомним спидометры - почему положение рекомендуемой скорости у них всегда на уровне 10 часов? - чтобы отклонение от неё наиболее явно фиксировалось мозгом). Этим активно пользуются при намеренном искажении информации с помощью нехитрых фокусов, о которых написано очень много.
Я раньше увлекался созданием графиков, которые отображали больше трёх показателей сразу. Разноцветные шары разного размера, висящие в трехмерном пространстве (5 показателей - 3 оси, размер и цвет), и особенно «кольца на цилиндрах», отображавшие 8 показателей сразу (если интересно, в комментариях напишите, найду в архивах). Это было прикольно, но очень сложно для интерпретации - и этим никто не пользовался.
Поэтому отображение многоуровневых многофакторных данных должно использовать средства визуализации, где искажение восприятия данных сведено к минимуму. Их оказалось немало - различные линейные, точечные, диапазонные графики (в том числе универсальный комбо-график, где на одной основе можно вывести любую комбинацию этих типов), графики распределения и связей (Солнечный луч, Радар, Санкей, Хорда, заново изобретённая Орбитальная диаграмма, которая получилась очень удачной) - всего в выходящем rapeed BI 28 разных типов графиков.
Но самое главное - как создавать, менять и перестраивать все эти графики при изменении данных или настроения? Что, каждый график надо настраивать? Нет! В этом основная фишка rapeed BI. И об этом будет следующий пост.
🔥4👍2