Сводная таблица или Pivot Table?
Сводная таблица по-английски называется Pivot Table. «Pivot» - заимствованное из французского, а еще раньше из латыни слово, означает «быстрый разворот». То самое «Крууу-гом!». Согласитесь, это очень точно отражает свойство сводной таблицы «быстро разворачиваться» вокруг новых осей - полей, которые выбирает пользователь.
«Сводной» таблицу назвали по-русски, потому что она агрегирует данные из большого источника данных, то есть даёт сводку из него, только важную информацию, опуская детали.
Самый известный пример - безусловно, сводная таблица Excel. Чтобы называться «полнофункциональной», любая другая сводная таблица обязана иметь функционал не меньше, чем в Excel - то есть строить любые многомерные структуры из полей слева и сверху, фильтровать, сворачивать/разворачивать узлы, сортировать и проводить любые вычисления.
У сводной таблицы Excel есть серьезное ограничение - миллион строк (и 16 тысяч столбцов). Это не даёт возможности, например, посмотреть продажи миллионов товаров в разрезе миллионов клиентов, а затем узнать лидеров среди них. Поэтому ею пользуются для «разворачивания» относительно малых полей по количеству элементов - до миллиона.
Очевидно, чтобы подарить пользователям настоящее #удовольствие_от_аналитики, нужно дать больше функциональности, чем обычная сводная таблица Excel, и убрать её ограничения.
Далее посмотрим, какие преимущества в этом отношении даёт сводная таблица rapeed.
Сводная таблица по-английски называется Pivot Table. «Pivot» - заимствованное из французского, а еще раньше из латыни слово, означает «быстрый разворот». То самое «Крууу-гом!». Согласитесь, это очень точно отражает свойство сводной таблицы «быстро разворачиваться» вокруг новых осей - полей, которые выбирает пользователь.
«Сводной» таблицу назвали по-русски, потому что она агрегирует данные из большого источника данных, то есть даёт сводку из него, только важную информацию, опуская детали.
Самый известный пример - безусловно, сводная таблица Excel. Чтобы называться «полнофункциональной», любая другая сводная таблица обязана иметь функционал не меньше, чем в Excel - то есть строить любые многомерные структуры из полей слева и сверху, фильтровать, сворачивать/разворачивать узлы, сортировать и проводить любые вычисления.
У сводной таблицы Excel есть серьезное ограничение - миллион строк (и 16 тысяч столбцов). Это не даёт возможности, например, посмотреть продажи миллионов товаров в разрезе миллионов клиентов, а затем узнать лидеров среди них. Поэтому ею пользуются для «разворачивания» относительно малых полей по количеству элементов - до миллиона.
Очевидно, чтобы подарить пользователям настоящее #удовольствие_от_аналитики, нужно дать больше функциональности, чем обычная сводная таблица Excel, и убрать её ограничения.
Далее посмотрим, какие преимущества в этом отношении даёт сводная таблица rapeed.
👍10✍3❤1👏1
Выход rapeed 0.3 (OLAP) - сводная таблица без ограничений
Сегодня, 30 мая 2025 года, выходит сборка rapeed 0.3. Это релиз продукта rapeed OLAP, который включает сводную таблицу без каких-либо ограничений, с возможностью связывания источников по любому набору полей «на лету». В релиз вошли также дополнительные функции по редактированию источников из СУБД и управлению их инкрементной загрузкой, а также множество других изменений.
Также в релиз входит rapeed OLE DB Provider, который дает возможность сводной таблице Excel работать с многомерным аналитическим хранилищем rapeed «из коробки». Все возможности сводной таблицы Excel, описанные ранее, поддерживаются нативно.
Важно, что основой работы и сводной таблицы rapeed, и сводной таблицы Excel является одна и та же API-команда, что гарантирует полное совпадение расчетных значений в обоих инструментах.
У обеих сводных таблиц есть свои преимущества:
⁃ в интерфейсе rapeed можно на лету связывать источники данных по любым полям в любых сочетаниях: например, 4 источника связаны по полю Город, 3 источника - по полю Товар, при этом никаких требований на поля не накладывается, кроме соответствия типа (дата-дата, текст-текст), и от полей не требуется быть ключевыми или уникальными;
⁃ также в построителе выражений rapeed можно задать формулы показателей (метрик) на основе любого количества источников, и использовать эти показатели в Excel;
⁃ в Excel ячейки сводной таблицы можно без ограничений использовать в любых расчетах.
В комментариях к прошлому посту подписчики отмечали, что сводная таблица Excel обычно долго грузит данные с сервера. При работе с rapeed OLAP этой проблемы не возникает, потому что расчеты всего объема данных происходят на сервере, и ядро отдает клиенту - сводной таблице - уже сформированный компактный блок записей для отображения. Это называется пагинация (от слова page, то есть страница). С пагинацией обе сводные таблицы просто летают.
- У вас есть сводная таблица?! Дайте две!
- Пожалуйста! Ваше #удовольствие_от_аналитики)
Сегодня, 30 мая 2025 года, выходит сборка rapeed 0.3. Это релиз продукта rapeed OLAP, который включает сводную таблицу без каких-либо ограничений, с возможностью связывания источников по любому набору полей «на лету». В релиз вошли также дополнительные функции по редактированию источников из СУБД и управлению их инкрементной загрузкой, а также множество других изменений.
Также в релиз входит rapeed OLE DB Provider, который дает возможность сводной таблице Excel работать с многомерным аналитическим хранилищем rapeed «из коробки». Все возможности сводной таблицы Excel, описанные ранее, поддерживаются нативно.
Важно, что основой работы и сводной таблицы rapeed, и сводной таблицы Excel является одна и та же API-команда, что гарантирует полное совпадение расчетных значений в обоих инструментах.
У обеих сводных таблиц есть свои преимущества:
⁃ в интерфейсе rapeed можно на лету связывать источники данных по любым полям в любых сочетаниях: например, 4 источника связаны по полю Город, 3 источника - по полю Товар, при этом никаких требований на поля не накладывается, кроме соответствия типа (дата-дата, текст-текст), и от полей не требуется быть ключевыми или уникальными;
⁃ также в построителе выражений rapeed можно задать формулы показателей (метрик) на основе любого количества источников, и использовать эти показатели в Excel;
⁃ в Excel ячейки сводной таблицы можно без ограничений использовать в любых расчетах.
В комментариях к прошлому посту подписчики отмечали, что сводная таблица Excel обычно долго грузит данные с сервера. При работе с rapeed OLAP этой проблемы не возникает, потому что расчеты всего объема данных происходят на сервере, и ядро отдает клиенту - сводной таблице - уже сформированный компактный блок записей для отображения. Это называется пагинация (от слова page, то есть страница). С пагинацией обе сводные таблицы просто летают.
- У вас есть сводная таблица?! Дайте две!
- Пожалуйста! Ваше #удовольствие_от_аналитики)
🔥13👍3🎉2⚡1
Безграничный Excel - вживую на миллиардах
Хотите посмотреть, как можно обходить ограничения сводных таблиц Excel? Мы решили с нашим партнёром Glowbyte сделать вебинар, на котором вживую показать работу сводных таблиц с хранилищем rapeed под капотом.
24 июля с 13:00 до 14:30 (а может, и дольше) мы с моим коллегой Никитой Каримовым и Алексеем Сучковым из Glowbyte подробно расскажем и покажем, как в сводной таблице Excel можно делать онлайн-аналитические запросы. Откроем капот и покажемсам двигатель хранилище rapeed, как это работает и что это даёт пользователям Excel.
Регистрируйтесь на вебинар! У нас ограниченное количество мест, но если указать корпоративную почту, то шанс вживую всё увидеть, задать нам любые вопросы и получить #удовольствие_от_аналитики резко возрастёт.
Хотите посмотреть, как можно обходить ограничения сводных таблиц Excel? Мы решили с нашим партнёром Glowbyte сделать вебинар, на котором вживую показать работу сводных таблиц с хранилищем rapeed под капотом.
24 июля с 13:00 до 14:30 (а может, и дольше) мы с моим коллегой Никитой Каримовым и Алексеем Сучковым из Glowbyte подробно расскажем и покажем, как в сводной таблице Excel можно делать онлайн-аналитические запросы. Откроем капот и покажем
Регистрируйтесь на вебинар! У нас ограниченное количество мест, но если указать корпоративную почту, то шанс вживую всё увидеть, задать нам любые вопросы и получить #удовольствие_от_аналитики резко возрастёт.
👍12🔥6
Оглавление канала
Для удобства подписчиков я решил сделать оглавление канала, чтобы вам долго не листать. Закреплю его и буду периодически обновлять.
- История создания rapeed
- Основные проблемы, для решения которых создавался rapeed
- Что такое DOLAP
- Область связей (кхор) - идея и описание работы на примере
- Что не так с BI на основе СУБД? - сравнение реляционного и многомерного подхода к аналитике, вечно актуальная тема
- Проблема источников данных различной гранулярности - первое упоминание связанных полей
- Демо-ролики про связанные поля - можно ли понять связь объектов, которые напрямую не связаны (поставщик - клиенты)
- Решение проблемы частично перезаписываемых данных
- Определение динамического тензорного движка rapeed
- Взрыв мозга - территориальная распределённость серверов не влияет на скорость вычислений
- Психологические особенности восприятия новой технологии
- Тесты rapeed на миллиарде записей на 3 недорогих серверах и 300 пользователей
- Аналитическая платформа rapeed в реестре ПО Минцифры
- Нагрузочные тесты rapeed на 40 000 пользователей на 3 источниках по 4 млрд записей - серия постов о результатах нагрузочных тестов и их интерпретация
- Сайзинг rapeed и горизонтальное масштабирование ресурсов
- Неудачная попытка Facebook создать распределённый OLAP
- Выход rapeed OLAP на рынок
Для удобства подписчиков я решил сделать оглавление канала, чтобы вам долго не листать. Закреплю его и буду периодически обновлять.
- История создания rapeed
- Основные проблемы, для решения которых создавался rapeed
- Что такое DOLAP
- Область связей (кхор) - идея и описание работы на примере
- Что не так с BI на основе СУБД? - сравнение реляционного и многомерного подхода к аналитике, вечно актуальная тема
- Проблема источников данных различной гранулярности - первое упоминание связанных полей
- Демо-ролики про связанные поля - можно ли понять связь объектов, которые напрямую не связаны (поставщик - клиенты)
- Решение проблемы частично перезаписываемых данных
- Определение динамического тензорного движка rapeed
- Взрыв мозга - территориальная распределённость серверов не влияет на скорость вычислений
- Психологические особенности восприятия новой технологии
- Тесты rapeed на миллиарде записей на 3 недорогих серверах и 300 пользователей
- Аналитическая платформа rapeed в реестре ПО Минцифры
- Нагрузочные тесты rapeed на 40 000 пользователей на 3 источниках по 4 млрд записей - серия постов о результатах нагрузочных тестов и их интерпретация
- Сайзинг rapeed и горизонтальное масштабирование ресурсов
- Неудачная попытка Facebook создать распределённый OLAP
- Выход rapeed OLAP на рынок
👍9🔥2🙏1
Снимок экрана 2025-07-22 в 10.30.20.png
29.9 KB
Приходите!
Мы получили на данный момент 406 заявок на вебинар, который состоится послезавтра. Максимальная ёмкость вебинара в Контур.Толк, которым мы пользуемся - 300 участников. Из-за этого мы вынуждены выслать ссылку на вебинар далеко не всем желающим, а только указавшим корпоративный email представителям заказчиков. И даже с учётом этого подтверждений выслано уже 313).
Поэтому я обращаюсь к подписчикам и читателям канала: если вы получили от нас подтверждение и ссылку на вебинар - обязательно приходите!
А тем, кто зарегистрировался, но по какой-то причине от нас подтверждения не получил, я очень благодарен за ваше время и усилия, оставайтесь с нами, дальше будет только интереснее #удовольствие_от_аналитики!
Мы получили на данный момент 406 заявок на вебинар, который состоится послезавтра. Максимальная ёмкость вебинара в Контур.Толк, которым мы пользуемся - 300 участников. Из-за этого мы вынуждены выслать ссылку на вебинар далеко не всем желающим, а только указавшим корпоративный email представителям заказчиков. И даже с учётом этого подтверждений выслано уже 313).
Поэтому я обращаюсь к подписчикам и читателям канала: если вы получили от нас подтверждение и ссылку на вебинар - обязательно приходите!
А тем, кто зарегистрировался, но по какой-то причине от нас подтверждения не получил, я очень благодарен за ваше время и усилия, оставайтесь с нами, дальше будет только интереснее #удовольствие_от_аналитики!
👍7🔥3👎1🥰1🥴1
Остатки? Балансы? - MinDate и MaxDate!
Одна из самых популярных расчётных задач - остаток товара (или баланс счёта клиента) на начало или конец периода. Таблицы остатков или балансов у больших компаний обычно очень большого размера - записи должны быть по каждому клиенту и его продукту на каждую дату, а в случае розницы по каждому SKU на каждую дату (а иногда и несколько в день) на каждый склад и магазин. Даже у среднего бизнеса это миллиарды строк, а у крупного - сотни миллиардов. При этом даты остатков или балансов могут различаться от клиента к клиенту или для разных магазинов - у каких-то вчера были операции и остатки менялись, а у каких-то - нет. Поэтому собрать информацию об остатках на начало и/или на конец периода - уже проблема. А если эти остатки нужно соединить с детальными продажами, возвратами и понять, как одно влияет на другое, то задача становится практически невыполнимой.
Но если у вас есть rapeed, то задача решается быстро и просто с использованием функций MinDate и MaxDate. Эти функции показывают значение поля на минимальную и максимальную дату, соответственно. Я записал небольшое видео, где они используются для расчёта (я бы даже сказал, показа) начального и конечного остатка товаров в магазине.
Видео снято в версии rapeed 0.8, которая сейчас готовится к выходу.
Одна из самых популярных расчётных задач - остаток товара (или баланс счёта клиента) на начало или конец периода. Таблицы остатков или балансов у больших компаний обычно очень большого размера - записи должны быть по каждому клиенту и его продукту на каждую дату, а в случае розницы по каждому SKU на каждую дату (а иногда и несколько в день) на каждый склад и магазин. Даже у среднего бизнеса это миллиарды строк, а у крупного - сотни миллиардов. При этом даты остатков или балансов могут различаться от клиента к клиенту или для разных магазинов - у каких-то вчера были операции и остатки менялись, а у каких-то - нет. Поэтому собрать информацию об остатках на начало и/или на конец периода - уже проблема. А если эти остатки нужно соединить с детальными продажами, возвратами и понять, как одно влияет на другое, то задача становится практически невыполнимой.
Но если у вас есть rapeed, то задача решается быстро и просто с использованием функций MinDate и MaxDate. Эти функции показывают значение поля на минимальную и максимальную дату, соответственно. Я записал небольшое видео, где они используются для расчёта (я бы даже сказал, показа) начального и конечного остатка товаров в магазине.
Видео снято в версии rapeed 0.8, которая сейчас готовится к выходу.
👍4
Во-первых, это красиво
Проблема всех разработчиков софта в том, что красивый интерфейс никто не замечает. Интерфейс, как правило, отмечают, когда он уродский или неудобный - тогда говорят «ну и уродство!» или «кто ж такое придумал!».
Если повезло и интерфейс продукта хороший, удобный - ну и ладно, им просто будут пользоваться.
При аналитической работе с данными без ограничений особенно важно, чтобы интерфейс «подчёркивал» данные и направлял пользователя играть с ними, сам оставаясь в тени. При этом никто не отменял общих принципов хорошего интерфейса:
⁃ пользователь должен с одного взгляда оценить, как была получена текущая конфигурация данных (читаемость);
⁃ пользователь должен мгновенно понять, что и как можно делать с данными (управляемость);
⁃ результат должен соответствовать намерениям пользователя (прогнозируемость);
⁃ результат должен достигаться минимумом действий (лёгкость использования).
Причём тут красота? Ефремов в «Лезвии бритвы» определяет красоту как наивысшую степень целесообразности, тонкую линию единства противоположностей в борьбе за гармонию, полную скрытой энергии. Без всяких шуток, мы стремимся к гармонии работы с данными, чтобы вы получали подлинное #удовольствие_от_аналитики! Поэтому мы основательно переделали, упростили и сделали более красивым (=целесообразным, читаемым, управляемым…) интерфейс rapeed 0.8, который готовится к выходу.
Проблема всех разработчиков софта в том, что красивый интерфейс никто не замечает. Интерфейс, как правило, отмечают, когда он уродский или неудобный - тогда говорят «ну и уродство!» или «кто ж такое придумал!».
Если повезло и интерфейс продукта хороший, удобный - ну и ладно, им просто будут пользоваться.
При аналитической работе с данными без ограничений особенно важно, чтобы интерфейс «подчёркивал» данные и направлял пользователя играть с ними, сам оставаясь в тени. При этом никто не отменял общих принципов хорошего интерфейса:
⁃ пользователь должен с одного взгляда оценить, как была получена текущая конфигурация данных (читаемость);
⁃ пользователь должен мгновенно понять, что и как можно делать с данными (управляемость);
⁃ результат должен соответствовать намерениям пользователя (прогнозируемость);
⁃ результат должен достигаться минимумом действий (лёгкость использования).
Причём тут красота? Ефремов в «Лезвии бритвы» определяет красоту как наивысшую степень целесообразности, тонкую линию единства противоположностей в борьбе за гармонию, полную скрытой энергии. Без всяких шуток, мы стремимся к гармонии работы с данными, чтобы вы получали подлинное #удовольствие_от_аналитики! Поэтому мы основательно переделали, упростили и сделали более красивым (=целесообразным, читаемым, управляемым…) интерфейс rapeed 0.8, который готовится к выходу.
👍6❤3🔥3💯1
rapeed-new-UI.mp4
98.1 MB
…Во-вторых, эффективно и целесообразно
В видео показано создание сводной таблицы на данных из двух не связанных между собой источников. Сначала создаются их связи по двум полям, затем - новый показатель, затем - сводная таблица из этих полей и показателей. На всё это тратится абсолютный минимум кликов мыши и прочих действий пользователя. При этом контекст работы полностью понятен. Это и есть #удовольствие_от_аналитики!
В видео показано создание сводной таблицы на данных из двух не связанных между собой источников. Сначала создаются их связи по двум полям, затем - новый показатель, затем - сводная таблица из этих полей и показателей. На всё это тратится абсолютный минимум кликов мыши и прочих действий пользователя. При этом контекст работы полностью понятен. Это и есть #удовольствие_от_аналитики!
👍7🔥4❤2
Почему 0.8?
В конце мая вышел rapeed 0.3. Почему сейчас выходит версия именно 0.8, а не какая-то другая?
После 0.3 мы планировали выпустить 0.4, в которой будут добавлены динамические справочники (что это такое и в чем их удобство, я подробно опишу на примерах). Это «добавление динамических справочников» вылилось в создание практически готового функционала по работе со связями полей и других объектов. Можно сказать, что в 0.3 был фундамент и 1й этаж, а сейчас это готовое офисное здание класса А - осталось только выбрать и завезти мебель. Еще и команда фронтенда сделала очередное чудо и успела перевести весь интерфейс на красивый новый стиль раньше графика. Добавлено много расчетных функций, которых ждали клиенты - например, MinDate и MaxDate, автоматические считающие баланс на начало/конец периода, гибкую конструкцию IF THEN ELSE ENDIF, динамические составные поля, решающие проблему сложного среднего, и многое другое.
По объему функциональности, внешнему виду, гибкости и удобству выходящая версия должна быть 1.8 по сравнению с вышедшей в мае 0.3. Но, зная, что будет в версии rapeed 1.0, мы решили присвоить ей номер 0.8. Получайте #удовольствие_от_аналитики!
В конце мая вышел rapeed 0.3. Почему сейчас выходит версия именно 0.8, а не какая-то другая?
После 0.3 мы планировали выпустить 0.4, в которой будут добавлены динамические справочники (что это такое и в чем их удобство, я подробно опишу на примерах). Это «добавление динамических справочников» вылилось в создание практически готового функционала по работе со связями полей и других объектов. Можно сказать, что в 0.3 был фундамент и 1й этаж, а сейчас это готовое офисное здание класса А - осталось только выбрать и завезти мебель. Еще и команда фронтенда сделала очередное чудо и успела перевести весь интерфейс на красивый новый стиль раньше графика. Добавлено много расчетных функций, которых ждали клиенты - например, MinDate и MaxDate, автоматические считающие баланс на начало/конец периода, гибкую конструкцию IF THEN ELSE ENDIF, динамические составные поля, решающие проблему сложного среднего, и многое другое.
По объему функциональности, внешнему виду, гибкости и удобству выходящая версия должна быть 1.8 по сравнению с вышедшей в мае 0.3. Но, зная, что будет в версии rapeed 1.0, мы решили присвоить ей номер 0.8. Получайте #удовольствие_от_аналитики!
👍5🔥3
Выход rapeed 0.8 - динамические справочники, семантические связи, новый интерфейс и расчётные функции
Вчера, 09 сентября 2025 г., вышла версия rapeed 0.8. Целое лето и ещё неделю мы создавали наиболее гибкую систему работы с данными: обогащение данных на лету (динамические справочники), отдельные сущности связей полей (семантические связи), составные поля (очень легко считать среднее по Магазин-SKU-месяц), новые расчётные функции и многое другое. Всё это в совершенно новом стиле интерфейса. Новая версия уже установлена у первого из ожидавших клиентов, остальные её получат в ближайшие дни и будут получать истинное #удовольствие_от_аналитики. А мы будем полностью переписывать пользовательскую документацию - буквально всё.
Вчера, 09 сентября 2025 г., вышла версия rapeed 0.8. Целое лето и ещё неделю мы создавали наиболее гибкую систему работы с данными: обогащение данных на лету (динамические справочники), отдельные сущности связей полей (семантические связи), составные поля (очень легко считать среднее по Магазин-SKU-месяц), новые расчётные функции и многое другое. Всё это в совершенно новом стиле интерфейса. Новая версия уже установлена у первого из ожидавших клиентов, остальные её получат в ближайшие дни и будут получать истинное #удовольствие_от_аналитики. А мы будем полностью переписывать пользовательскую документацию - буквально всё.
1🔥8👍4
Динамические справочники в rapeed - обогащение данных на лету
В rapeed 0.8 появились динамические справочники, которые решают задачу обогащения больших объёмов данных на лету. Например, если у заказчика большой и постоянно растущий объём данных и при этом ещё и справочники часто меняются, то обновление и репроцессинг кубов MS SSAS на новых справочниках каждый раз может занимать несколько суток (есть такие факты). Кроме обновления больших справочников, часто нужно оперативно добавить какое-то поле в источник данных и посмотреть все данные в его разрезе. Также у больших организаций есть версионность справочников - нужно смотреть прошлогодние данные в новой иерархии или наоборот.
Всё это легко решается с помощью динамических справочников в rapeed. Их коренное отличие - справочники присоединяются к источникам данных на лету в любом количестве по любым полям. Единственное отличие справочника - у него должно быть уникальное поле. Зато справочников может быть сколько угодно!
Источники по-прежнему можно связывать между собой как угодно. Справочники тоже. А если у источников общий справочник, то они уже автоматически связаны по всем его полям. Источники также можно связывать … со справочниками! И здесь уже начинается та самая #игра_с_данными, которая приносит истинное #удовольствие_от_аналитики!
Для иллюстрации я снял видео (4:24 мин) про работу динамических справочников в rapeed, которое опубликовано ниже.
В rapeed 0.8 появились динамические справочники, которые решают задачу обогащения больших объёмов данных на лету. Например, если у заказчика большой и постоянно растущий объём данных и при этом ещё и справочники часто меняются, то обновление и репроцессинг кубов MS SSAS на новых справочниках каждый раз может занимать несколько суток (есть такие факты). Кроме обновления больших справочников, часто нужно оперативно добавить какое-то поле в источник данных и посмотреть все данные в его разрезе. Также у больших организаций есть версионность справочников - нужно смотреть прошлогодние данные в новой иерархии или наоборот.
Всё это легко решается с помощью динамических справочников в rapeed. Их коренное отличие - справочники присоединяются к источникам данных на лету в любом количестве по любым полям. Единственное отличие справочника - у него должно быть уникальное поле. Зато справочников может быть сколько угодно!
Источники по-прежнему можно связывать между собой как угодно. Справочники тоже. А если у источников общий справочник, то они уже автоматически связаны по всем его полям. Источники также можно связывать … со справочниками! И здесь уже начинается та самая #игра_с_данными, которая приносит истинное #удовольствие_от_аналитики!
Для иллюстрации я снял видео (4:24 мин) про работу динамических справочников в rapeed, которое опубликовано ниже.
👍5🔥2❤1✍1
Обновление Add-on и OLE DB Provider для MS Excel - ещё более безграничная и удобная сводная таблица Excel при работе с данными rapeed
Сегодня вышло обновление Add-on и rapeed OLE DB Provider для MS Excel, содержащее множество улучшений для работы с данными rapeed.
Сейчас rapeed OLE DB Provider также работает по безопасному подключению SSL, позволяет выбрать, сколько строк и столбцов загружать для этой сессии подключения и в какой из доступных рабочих областей rapeed работать. Улучшен поиск и фильтрация данных в таблице, а также формат выводимых чисел.
Подробная информация представлена на новостном разделе сайта. Работайте в сводной таблице Excel с данными rapeed, получая ещё большее #удовольствие_от_аналитики!
Сегодня вышло обновление Add-on и rapeed OLE DB Provider для MS Excel, содержащее множество улучшений для работы с данными rapeed.
Сейчас rapeed OLE DB Provider также работает по безопасному подключению SSL, позволяет выбрать, сколько строк и столбцов загружать для этой сессии подключения и в какой из доступных рабочих областей rapeed работать. Улучшен поиск и фильтрация данных в таблице, а также формат выводимых чисел.
Подробная информация представлена на новостном разделе сайта. Работайте в сводной таблице Excel с данными rapeed, получая ещё большее #удовольствие_от_аналитики!
👍6
rapeed на byteoilgas_conf 06 октября
В понедельник 06 октября я выступаю на конференции byteoilgas_conf с докладом «платформа rapeed: альтернативная технология работы с огромными массивами данных и продукты на ее основе». Почему-то и название конференции, и все доклады в программе пишутся с маленькой буквы). Расскажу об иной работе с данными, отличающейся от общепринятой SQL-парадигмы, и почему rapeed - идеальная платформа для работы AI, в отличие от классических реляционных сред. Приходите, с удовольствием пообщаемся лично!
Благодарю организаторов за предоставленную возможность выступления!
В понедельник 06 октября я выступаю на конференции byteoilgas_conf с докладом «платформа rapeed: альтернативная технология работы с огромными массивами данных и продукты на ее основе». Почему-то и название конференции, и все доклады в программе пишутся с маленькой буквы). Расскажу об иной работе с данными, отличающейся от общепринятой SQL-парадигмы, и почему rapeed - идеальная платформа для работы AI, в отличие от классических реляционных сред. Приходите, с удовольствием пообщаемся лично!
Благодарю организаторов за предоставленную возможность выступления!
🔥6👍3
Гибкие расчёты остатков и балансов с помощью уровня валидности в OnMinDate/OnMaxDate
Я раньше уже рассказывал о проблеме расчёта остатков - для её решения в rapeed 0.8 мы сделали функции MinDate и MaxDate. После их апробации и общения с клиентами мы их усовершенствовали и переименовали - сейчас это функции OnMinDate и OnMaxDate, возвращающие значения заданного поля на минимальную и максимальную дату и автоматически агрегирующие их. Но не просто агрегирующие, а с учётом нового введённого в функции параметра - уровня валидности.
Что такое уровень валидности? Допустим, вы считаете остатки товаров в магазинах. На каком уровне их допустимо (=валидно) складывать? Можно ли складывать начальный остаток одного товара (SKU) с начальным остатком другого? Если нет, то уровень валидности - это SKU. Это достаточно очевидно.
А если товары есть в остатке во многих магазинах, то валидно ли их складывать? Это уже не так очевидно, но обычно начальные остатки по одному SKU в разных магазинах складывают. Тогда уровень валидности - это комбинация (SKU-Магазин).
Теперь пример из другой сферы. Представьте клиента банка. У него открыто несколько карт, счетов и других банковских продуктов в разных валютах. На каком наборе полей корректно (=валидно) учитывать балансы клиентов для отчётности? В этом случае на уровне (Клиент-Продукт-Валюта), но в зависимости от бизнеса в этот набор могут добавляться и другие поля.
Ситуация становится ещё интереснее, когда отдельно хранятся ежемесячные остатки/балансы, которые можно складывать, и ежедневные, которые складывать нельзя, но и те и другие участвуют в важных расчётах. В этом случае в уровень валидности нужно добавить месяц или дату. Важно, что функции OnMinDate/OnMaxDate, как и все остальные в rapeed, считают всё на лету, поэтому можно экспериментировать, подбирая нужный бизнесу уровень валидности на лету и проверяя агрегацию остатков или балансов на разных уровнях источников и справочников.
Для иллюстрации работы функций OnMinDate/OnMaxDate и уровня валидности я подготовил небольшой видеопример (04:15) - файл Остатки.xlsx из него я использовал ещё для этих видео полуторагодовой давности!) Если вы хотите разобраться, как работают расчёты, вам, скорее всего, придётся пересмотреть видео несколько раз. Ниже на скриншоте приведён конечный результат с корректными данными расчётов в обоих случаях из видеопримера, показывая, как гибко можно управлять расчётом балансов.
Я раньше уже рассказывал о проблеме расчёта остатков - для её решения в rapeed 0.8 мы сделали функции MinDate и MaxDate. После их апробации и общения с клиентами мы их усовершенствовали и переименовали - сейчас это функции OnMinDate и OnMaxDate, возвращающие значения заданного поля на минимальную и максимальную дату и автоматически агрегирующие их. Но не просто агрегирующие, а с учётом нового введённого в функции параметра - уровня валидности.
Что такое уровень валидности? Допустим, вы считаете остатки товаров в магазинах. На каком уровне их допустимо (=валидно) складывать? Можно ли складывать начальный остаток одного товара (SKU) с начальным остатком другого? Если нет, то уровень валидности - это SKU. Это достаточно очевидно.
А если товары есть в остатке во многих магазинах, то валидно ли их складывать? Это уже не так очевидно, но обычно начальные остатки по одному SKU в разных магазинах складывают. Тогда уровень валидности - это комбинация (SKU-Магазин).
Теперь пример из другой сферы. Представьте клиента банка. У него открыто несколько карт, счетов и других банковских продуктов в разных валютах. На каком наборе полей корректно (=валидно) учитывать балансы клиентов для отчётности? В этом случае на уровне (Клиент-Продукт-Валюта), но в зависимости от бизнеса в этот набор могут добавляться и другие поля.
Ситуация становится ещё интереснее, когда отдельно хранятся ежемесячные остатки/балансы, которые можно складывать, и ежедневные, которые складывать нельзя, но и те и другие участвуют в важных расчётах. В этом случае в уровень валидности нужно добавить месяц или дату. Важно, что функции OnMinDate/OnMaxDate, как и все остальные в rapeed, считают всё на лету, поэтому можно экспериментировать, подбирая нужный бизнесу уровень валидности на лету и проверяя агрегацию остатков или балансов на разных уровнях источников и справочников.
Для иллюстрации работы функций OnMinDate/OnMaxDate и уровня валидности я подготовил небольшой видеопример (04:15) - файл Остатки.xlsx из него я использовал ещё для этих видео полуторагодовой давности!) Если вы хотите разобраться, как работают расчёты, вам, скорее всего, придётся пересмотреть видео несколько раз. Ниже на скриншоте приведён конечный результат с корректными данными расчётов в обоих случаях из видеопримера, показывая, как гибко можно управлять расчётом балансов.
👍2🔥2
OnMinMaxDate.png
232.4 KB
Скриншот, иллюстрирующий различные уровни валидности остатков на одинаковых данных
👍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
Основные проблемы, для решения которых создавался 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 - задание уровня валидности на лету
👍5👏1
AMD Epyc и пятничный баттл «одна нода vs три ноды»
Буквально каждый архитектор данных у наших клиентов перед заказом железа задаёт один и тот же вопрос: «А может, сделать всё-таки один мощный сервер и на одной ноде систему запускать?»
Теоретические рассуждения и прошлые опыты после выхода новой версии уже не сильно убеждают, поэтому мы решили сравнить работу rapeed на одном и том же оборудовании, на идентичных данных и с абсолютно одинаковыми настройками, с одной лишь разницей - в одном случае три ноды, а в другом - одна.
Также мы недавно перешли на новый сервер с процессором AMD Epyc 9454, памятью типа DDR5 и NVMe-дисками, сделанными специально под эту серию процессоров.
Год назад я писал, что первичная загрузка данных для расчёта с диска на процессоре Intel Xeon занимает 5-7 секунд, а следующие расчёты (в том числе другими пользователями) выполняются за 1-2 секунды. И все архитекторы интересуются именно первичной загрузкой данных. Только её мы сейчас и тестировали, честно очищая все кэши перед каждой операцией.
Так вот, Epyc, танцуя, затаптывает Xeon под плинтус - первичная загрузка миллиарда записей, да ещё с динамическими справочниками, да ещё и с самим расчётом - всё это в сумме занимает 1,75 секунды! Это так же на трёх нодах, как и раньше. В связи с чем мы уже предлагаем всем клиентам брать именно машины с Epyc и дисками для него (либо другими быстрыми NVMe-дисками).
Но самое интересное, что система вновь доказала свою распределённую природу. Конфигурация из трёх нод на всех операциях была быстрее однонодовой на 30-40% и выше. Причём на расчётах COUNT DISTINCT три ноды опережали одну уже в 2,5 раза!
Подробные результаты тестирования интересующиеся могут получить по запросу, написав нам в канале или на сайте. Хороших выходных!
Буквально каждый архитектор данных у наших клиентов перед заказом железа задаёт один и тот же вопрос: «А может, сделать всё-таки один мощный сервер и на одной ноде систему запускать?»
Теоретические рассуждения и прошлые опыты после выхода новой версии уже не сильно убеждают, поэтому мы решили сравнить работу rapeed на одном и том же оборудовании, на идентичных данных и с абсолютно одинаковыми настройками, с одной лишь разницей - в одном случае три ноды, а в другом - одна.
Также мы недавно перешли на новый сервер с процессором AMD Epyc 9454, памятью типа DDR5 и NVMe-дисками, сделанными специально под эту серию процессоров.
Год назад я писал, что первичная загрузка данных для расчёта с диска на процессоре Intel Xeon занимает 5-7 секунд, а следующие расчёты (в том числе другими пользователями) выполняются за 1-2 секунды. И все архитекторы интересуются именно первичной загрузкой данных. Только её мы сейчас и тестировали, честно очищая все кэши перед каждой операцией.
Так вот, Epyc, танцуя, затаптывает Xeon под плинтус - первичная загрузка миллиарда записей, да ещё с динамическими справочниками, да ещё и с самим расчётом - всё это в сумме занимает 1,75 секунды! Это так же на трёх нодах, как и раньше. В связи с чем мы уже предлагаем всем клиентам брать именно машины с Epyc и дисками для него (либо другими быстрыми NVMe-дисками).
Но самое интересное, что система вновь доказала свою распределённую природу. Конфигурация из трёх нод на всех операциях была быстрее однонодовой на 30-40% и выше. Причём на расчётах COUNT DISTINCT три ноды опережали одну уже в 2,5 раза!
Подробные результаты тестирования интересующиеся могут получить по запросу, написав нам в канале или на сайте. Хороших выходных!
🔥7👍2