Дальше узнаем, какая была нагрузка на вычислительные мощности и что вообще происходит при расчетах в rapeed
#удовольствие_от_аналитики #тесты_rapeed
#удовольствие_от_аналитики #тесты_rapeed
👍4
Результаты тестов.
Нагрузка на вычислительные мощности
Параллельно с логами в тестах фиксировалась нагрузка на CPU, память и сеть. Потом оценку нагрузки на сеть выключили, поскольку она была крайне низка.
На скриншоте внизу видно, что нагрузка на CPU небольшая: в момент скриншота средняя нагрузка на процессоры контура составляет 6,4%. Система зарезервировала весь процессор под себя (синий фон), но понадобилось только 6,4%. За всё время вычислений загрузка CPU не превышала 15%.
В левой части скриншота виден блок высокой нагрузки - это была авторизация 40 000 пользователей. Поскольку авторизация связана с криптографией и выдачей токенов, то это «дорогая» с точки зрения потребления CPU операция. Поскольку в жизни одновременных авторизаций десятков тысяч пользователей не бывает, то эта информация непосредственно к работе системы не относится.
Потребление памяти стабильно, практически без флуктуаций. Как данные попали в распределенную память нод, так они там и живут. Сессии и задания пользователей памяти дополнительно практически не потребляют.
#удовольствие_от_аналитики #тесты_rapeed
Нагрузка на вычислительные мощности
Параллельно с логами в тестах фиксировалась нагрузка на CPU, память и сеть. Потом оценку нагрузки на сеть выключили, поскольку она была крайне низка.
На скриншоте внизу видно, что нагрузка на CPU небольшая: в момент скриншота средняя нагрузка на процессоры контура составляет 6,4%. Система зарезервировала весь процессор под себя (синий фон), но понадобилось только 6,4%. За всё время вычислений загрузка CPU не превышала 15%.
В левой части скриншота виден блок высокой нагрузки - это была авторизация 40 000 пользователей. Поскольку авторизация связана с криптографией и выдачей токенов, то это «дорогая» с точки зрения потребления CPU операция. Поскольку в жизни одновременных авторизаций десятков тысяч пользователей не бывает, то эта информация непосредственно к работе системы не относится.
Потребление памяти стабильно, практически без флуктуаций. Как данные попали в распределенную память нод, так они там и живут. Сессии и задания пользователей памяти дополнительно практически не потребляют.
#удовольствие_от_аналитики #тесты_rapeed
👍7🔥3
Результаты тестов. Интерпретация и выводы
Тесты безусловно достигли своей цели, полностью доказав, что rapeed на одном контуре (то есть с одной точкой входа для пользователей, или иначе с одним master-ом) способен обслуживать 40 000 пользователей, работающих во «взрывном» режиме с большими источниками данных, причем с большим практическим запасом, сохраняя при этом время отклика менее 2 секунд.
Вторая цель тестов была - оценить, как связывание источников на лету влияет на скорость обработки запросов. Здесь тоже есть результат - технология связанных полей оправдала ожидания.
То, что размер источников - 4 млрд записей, объясняется спецификой задачи и дефицитом места. Если источники будут по 40 млрд, 400 млрд или любого другого размера, нужно будет рассчитать потребность в «железе», импортировать данные - и система будет работать.
Что происходит при расчетах и от чего зависит время отклика? В наших внутренних тестах оно составляло 0,1 сек на 400 млн записей, да и в этих нагрузочных тестах значительная доля откликов выполнялась за доли секунды.
Расчетные операции в rapeed состоят из следующих этапов:
- первичное распределенное чтение данных с диска;
- расчеты внутри нод;
- сетевой обмен внутри распределенной памяти нод;
- расчеты внутри распределенной памяти;
- формирование ответа в формате JSON;
- пересылка ответа потребителю в формате JSON.
Бывают ответы такого большого размера (хоть у нас в ядре и пагинация, то есть задается, сколько первых N элементов нужно), что только их пересылка по сети займет полсекунды - например, раскрытие длинного текстового поля, когда сверху в таблице тоже текстовые поля.
Система адаптируется к пересылкам расчетов определенных конфигураций, и повторно высылает их быстрее. Когда конфликтующих запросов много, на разных уровнях возникают очереди их обработки, и тогда скорость их обработки зависит от десятков практически случайных факторов типа состояния каналов памяти.
Одно можно сказать определенно: архитектура системы была разработана именно под такую нагрузку и под такие задачи и успешно справилась со стресс-тестами.
#удовольствие_от_аналитики #тесты_rapeed
Тесты безусловно достигли своей цели, полностью доказав, что rapeed на одном контуре (то есть с одной точкой входа для пользователей, или иначе с одним master-ом) способен обслуживать 40 000 пользователей, работающих во «взрывном» режиме с большими источниками данных, причем с большим практическим запасом, сохраняя при этом время отклика менее 2 секунд.
Вторая цель тестов была - оценить, как связывание источников на лету влияет на скорость обработки запросов. Здесь тоже есть результат - технология связанных полей оправдала ожидания.
То, что размер источников - 4 млрд записей, объясняется спецификой задачи и дефицитом места. Если источники будут по 40 млрд, 400 млрд или любого другого размера, нужно будет рассчитать потребность в «железе», импортировать данные - и система будет работать.
Что происходит при расчетах и от чего зависит время отклика? В наших внутренних тестах оно составляло 0,1 сек на 400 млн записей, да и в этих нагрузочных тестах значительная доля откликов выполнялась за доли секунды.
Расчетные операции в rapeed состоят из следующих этапов:
- первичное распределенное чтение данных с диска;
- расчеты внутри нод;
- сетевой обмен внутри распределенной памяти нод;
- расчеты внутри распределенной памяти;
- формирование ответа в формате JSON;
- пересылка ответа потребителю в формате JSON.
Бывают ответы такого большого размера (хоть у нас в ядре и пагинация, то есть задается, сколько первых N элементов нужно), что только их пересылка по сети займет полсекунды - например, раскрытие длинного текстового поля, когда сверху в таблице тоже текстовые поля.
Система адаптируется к пересылкам расчетов определенных конфигураций, и повторно высылает их быстрее. Когда конфликтующих запросов много, на разных уровнях возникают очереди их обработки, и тогда скорость их обработки зависит от десятков практически случайных факторов типа состояния каналов памяти.
Одно можно сказать определенно: архитектура системы была разработана именно под такую нагрузку и под такие задачи и успешно справилась со стресс-тестами.
#удовольствие_от_аналитики #тесты_rapeed
👍7🔥4
Результаты тестов. И вишенка на торте!..
Завершающим тестом был «циклический тест на отказ». Представьте: заходит в систему пользователь и начинает довольно интенсивно работать со сводными таблицами: создает их, добавляет поля влево и вверх, сортирует, фильтрует, раскрывает узлы.. И продолжает делать эти действия по циклу до бесконечности. Заходит второй пользователь и начинает довольно интенсивно работать… третий…двадцатый… - и каждый повторяет в цикле эти действия, пока всё новые и новые пользователи входят в систему.
Представили? А мы наблюдаем за этим процессом и фиксируем, когда система перестает справляться с таким наплывом интенсивно работающих пользователей. Контур и источники данных те же.
Как вы думаете, на каком пользователе система перестала справляться (то есть начала выдавать ошибки)? Пишите в комментариях! Правильный ответ будет опубликован в пятницу 21 марта.
#удовольствие_от_аналитики #тесты_rapeed
Завершающим тестом был «циклический тест на отказ». Представьте: заходит в систему пользователь и начинает довольно интенсивно работать со сводными таблицами: создает их, добавляет поля влево и вверх, сортирует, фильтрует, раскрывает узлы.. И продолжает делать эти действия по циклу до бесконечности. Заходит второй пользователь и начинает довольно интенсивно работать… третий…двадцатый… - и каждый повторяет в цикле эти действия, пока всё новые и новые пользователи входят в систему.
Представили? А мы наблюдаем за этим процессом и фиксируем, когда система перестает справляться с таким наплывом интенсивно работающих пользователей. Контур и источники данных те же.
Как вы думаете, на каком пользователе система перестала справляться (то есть начала выдавать ошибки)? Пишите в комментариях! Правильный ответ будет опубликован в пятницу 21 марта.
#удовольствие_от_аналитики #тесты_rapeed
👍3🔥2
rapeed - 100% надежный аналитический сервис
Правильный ответ такой: потолок не найден! Тест работал почти трое суток, добавляя пользователей каждые 30 секунд, и его пришлось прервать по банальной причине: кончилось место на диске для логов. Да, в логах фиксировалась каждая операция, в том числе ответы системы, и файлы логов съели всё место.
За всё время циклического теста на отказ система обработала более 11 000 000 запросов и на все из них (100,00%) выдала верный ответ. Для rapeed неважно, один пользователь работает или десятки тысяч одновременных - система гарантирует верный ответ.
Ответ может быть получен в собственном интерфейсе системы или во внешнем средстве по API. Таким образом, мы доказали, что rapeed - 100% надежный аналитический сервис для любого количества пользователей на любых объемах данных!
#удовольствие_от_аналитики #тесты_rapeed
Правильный ответ такой: потолок не найден! Тест работал почти трое суток, добавляя пользователей каждые 30 секунд, и его пришлось прервать по банальной причине: кончилось место на диске для логов. Да, в логах фиксировалась каждая операция, в том числе ответы системы, и файлы логов съели всё место.
За всё время циклического теста на отказ система обработала более 11 000 000 запросов и на все из них (100,00%) выдала верный ответ. Для rapeed неважно, один пользователь работает или десятки тысяч одновременных - система гарантирует верный ответ.
Ответ может быть получен в собственном интерфейсе системы или во внешнем средстве по API. Таким образом, мы доказали, что rapeed - 100% надежный аналитический сервис для любого количества пользователей на любых объемах данных!
#удовольствие_от_аналитики #тесты_rapeed
🔥10👏6👍5
Зали пушечное видео на www.rapeed.ai
На главной странице нашего обновленного сайта, помимо ключевых преимуществ системы и калькулятора выгоды от её использования, вас встречает небольшое видео живой работы rapeed.
Вопрос к читателям: как вы думаете, что происходит на этом видео?
Пишите свои ответы в комментариях к этому посту!
#удовольствие_от_аналитики
На главной странице нашего обновленного сайта, помимо ключевых преимуществ системы и калькулятора выгоды от её использования, вас встречает небольшое видео живой работы rapeed.
Вопрос к читателям: как вы думаете, что происходит на этом видео?
Пишите свои ответы в комментариях к этому посту!
#удовольствие_от_аналитики
👍5🔥4
Сайзинг rapeed - сколько нужно «железа»?
Данные в rapeed хранятся на диске, а при расчете загружаются и обрабатываются в совокупной оперативной памяти всех нод (виртуальных или физических машин).
Значит, для обработки больших объемов данных системе требуется оперативная память и место на диске. Сколько?
Для первичного расчета мы сделали опросник, в котором можно указать количество записей во всех значимых источниках данных - сколько там дат, чисел и текстовых полей - и получить верхнюю оценку требуемой оперативной памяти и места на диске.
На практике система потребляет в разы меньше памяти, чем занимает дискового пространства.
Во-первых, в память загружаются только те данные, которые нужны для расчетов пользователей. Понятно, что это далеко не весь объем данных, хотя заранее сказать нельзя, какие именно поля потребуются.
Во-вторых, объем занимаемой памяти прямо зависит от плотности данных - доли уникальных значений каждого поля в отношении к количеству записей. Здесь сложно заранее делать какие-то оценки, нужно просто загрузить данные и посмотреть по факту)
В-третьих, система может работать даже в минимальном объеме памяти. При этом новые расчеты будут вытеснять из памяти более старые по принципу FIFO. Если диски быстрые и имеют свой кэш, то пользователи даже не заметят, что данные постоянно грузятся с диска, а небольшой объем памяти интенсивно обновляется. В этом режиме потребность rapeed в памяти несущественно выше обычных СУБД.
Доступная память даёт дополнительный комфорт в работе пользователей - им надо меньше ждать загрузок с диска, хоть это и недолго на современных SSD. Поэтому наш опросник даёт достаточно хороший ориентир по сайзингу с учетом комфорта пользователей - то самое #удовольствие_от_аналитики.
Данные в rapeed хранятся на диске, а при расчете загружаются и обрабатываются в совокупной оперативной памяти всех нод (виртуальных или физических машин).
Значит, для обработки больших объемов данных системе требуется оперативная память и место на диске. Сколько?
Для первичного расчета мы сделали опросник, в котором можно указать количество записей во всех значимых источниках данных - сколько там дат, чисел и текстовых полей - и получить верхнюю оценку требуемой оперативной памяти и места на диске.
На практике система потребляет в разы меньше памяти, чем занимает дискового пространства.
Во-первых, в память загружаются только те данные, которые нужны для расчетов пользователей. Понятно, что это далеко не весь объем данных, хотя заранее сказать нельзя, какие именно поля потребуются.
Во-вторых, объем занимаемой памяти прямо зависит от плотности данных - доли уникальных значений каждого поля в отношении к количеству записей. Здесь сложно заранее делать какие-то оценки, нужно просто загрузить данные и посмотреть по факту)
В-третьих, система может работать даже в минимальном объеме памяти. При этом новые расчеты будут вытеснять из памяти более старые по принципу FIFO. Если диски быстрые и имеют свой кэш, то пользователи даже не заметят, что данные постоянно грузятся с диска, а небольшой объем памяти интенсивно обновляется. В этом режиме потребность rapeed в памяти несущественно выше обычных СУБД.
Доступная память даёт дополнительный комфорт в работе пользователей - им надо меньше ждать загрузок с диска, хоть это и недолго на современных SSD. Поэтому наш опросник даёт достаточно хороший ориентир по сайзингу с учетом комфорта пользователей - то самое #удовольствие_от_аналитики.
👍6👏1
Горизонтальное масштабирование ресурсов в rapeed
Что делать, если объем данных продолжает расти, а ресурсы заканчиваются? Или, например, хочется подбавить оперативной памяти, чтобы увеличить пользователям #удовольствие_от_аналитики? Или подоспели новые источники данных и радостно ждут своего переселения в хранилище rapeed?
Всё просто - добавляйте виртуальные машины в контур rapeed, и произойдет следующее:
- процессор и память только что добавленных машин (нод) мгновенно станут использоваться в расчетах;
- диски новых машин начнут наполняться данными при ближайшем сеансе импорта.
Причем импорт так сделан, что пишет данные на самый свободный диск. То есть диски новых нод будут усиленно заполняться данными до достижения равномерного распределения источников между всеми нодами.
Очень простая аналогия - добавление новой ёмкости для потока воды, связанной с другими ёмкостями единой трубой. Без ограничений. Это и есть настоящее горизонтальное масштабирование.
Что делать, если объем данных продолжает расти, а ресурсы заканчиваются? Или, например, хочется подбавить оперативной памяти, чтобы увеличить пользователям #удовольствие_от_аналитики? Или подоспели новые источники данных и радостно ждут своего переселения в хранилище rapeed?
Всё просто - добавляйте виртуальные машины в контур rapeed, и произойдет следующее:
- процессор и память только что добавленных машин (нод) мгновенно станут использоваться в расчетах;
- диски новых машин начнут наполняться данными при ближайшем сеансе импорта.
Причем импорт так сделан, что пишет данные на самый свободный диск. То есть диски новых нод будут усиленно заполняться данными до достижения равномерного распределения источников между всеми нодами.
Очень простая аналогия - добавление новой ёмкости для потока воды, связанной с другими ёмкостями единой трубой. Без ограничений. Это и есть настоящее горизонтальное масштабирование.
👍8🔥2
Номинация на Data Awards’25
Меня вместе с rapeed номинировали на премию Data Awards’25. Организаторы выложили интервью со мной про rapeed и его значение для отрасли. Почитайте!
#удовольствие_от_аналитики
Меня вместе с rapeed номинировали на премию Data Awards’25. Организаторы выложили интервью со мной про rapeed и его значение для отрасли. Почитайте!
#удовольствие_от_аналитики
🔥17👍7❤3👏2🥰1
У Фейсбука не получилось..
Мы всё время ищем, есть ли в мире еще аналоги нашей технологии. В результате поисков нашли статью 2016 года ученых из Facebook Research Lab, в которой они описывали принципы технологии Cubrick - распределенного OLAP in-memory движка.
Интересно, что пишут математики Facebook о недостатках ROLAP-средств анализа данных: операции «slice-n-dice, roll-ups, drill-down» недоступны пользователям в режиме онлайн, что резко ограничивает свободу работы с данными и, следовательно, количество и качество бизнес-решений.
Технология «не взлетела» дальше тестов - больше о ней упоминаний нет. Есть признаки, что Google тоже пыталась создать распределенный in-memory OLAP по тем же причинам - и у них тоже не получилось. Нам, сделавшим эту технологию и доведшим её до production, интересно почитать описание и математические модели технологий гигантов. Даже видно места, где маститые математики Фейсбука свернули не туда. Но мы им об этом не скажем) - пусть #удовольствие_от_аналитики получают наши пользователи!
Мы всё время ищем, есть ли в мире еще аналоги нашей технологии. В результате поисков нашли статью 2016 года ученых из Facebook Research Lab, в которой они описывали принципы технологии Cubrick - распределенного OLAP in-memory движка.
Интересно, что пишут математики Facebook о недостатках ROLAP-средств анализа данных: операции «slice-n-dice, roll-ups, drill-down» недоступны пользователям в режиме онлайн, что резко ограничивает свободу работы с данными и, следовательно, количество и качество бизнес-решений.
Технология «не взлетела» дальше тестов - больше о ней упоминаний нет. Есть признаки, что Google тоже пыталась создать распределенный in-memory OLAP по тем же причинам - и у них тоже не получилось. Нам, сделавшим эту технологию и доведшим её до production, интересно почитать описание и математические модели технологий гигантов. Даже видно места, где маститые математики Фейсбука свернули не туда. Но мы им об этом не скажем) - пусть #удовольствие_от_аналитики получают наши пользователи!
🔥12👍8🤣4❤3
Сводная таблица или дашборд?
Вечный холивар в среде BI - что нужно пользователям? Ученые из Facebook пишут, что операции раскрытия/сворачивания, добавления срезов на лету и сквозной сортировки таблицы (примерно так можно перевести с английского «slice-n-dice, roll-ups, drill-down») по определению возможны только в сводной таблице и что только она даёт свободу работы с данными.
Российские вендоры BI-средств поголовно выступают за интерактивные дашборды - видимо, потому, что сводной таблицы из коробки у них нет и каждая сводная таблица - это кастомная разработка на SQL и средствах визуализации.
Если говорить про пользователей, то мы не нашли опросов, которым можно верить. Экспертные оценки западных вендоров (а эксперты кто и где они сейчас?..) говорили, что 80% пользователей сидят в сводных таблицах Excel и им ничего больше не надо. Дашбордами пользовались только руководители или неквалифицированные пользователи - одни не хотели данные крутить, другие не умели. Дашборды при этом создавали и создают сотнями и тысячами, а средний срок жизни одного дашборда - 3,5 открытия (!!!, данные Qlik).
Как вы думаете, что нужнее пользователям? Пишите в комментариях!
#удовольствие_от_аналитики
Вечный холивар в среде BI - что нужно пользователям? Ученые из Facebook пишут, что операции раскрытия/сворачивания, добавления срезов на лету и сквозной сортировки таблицы (примерно так можно перевести с английского «slice-n-dice, roll-ups, drill-down») по определению возможны только в сводной таблице и что только она даёт свободу работы с данными.
Российские вендоры BI-средств поголовно выступают за интерактивные дашборды - видимо, потому, что сводной таблицы из коробки у них нет и каждая сводная таблица - это кастомная разработка на SQL и средствах визуализации.
Если говорить про пользователей, то мы не нашли опросов, которым можно верить. Экспертные оценки западных вендоров (а эксперты кто и где они сейчас?..) говорили, что 80% пользователей сидят в сводных таблицах Excel и им ничего больше не надо. Дашбордами пользовались только руководители или неквалифицированные пользователи - одни не хотели данные крутить, другие не умели. Дашборды при этом создавали и создают сотнями и тысячами, а средний срок жизни одного дашборда - 3,5 открытия (!!!, данные Qlik).
Как вы думаете, что нужнее пользователям? Пишите в комментариях!
#удовольствие_от_аналитики
👍5👏3🔥2💯2❤1
Сводная таблица или 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