#удовольствие_от_аналитики #тесты_rapeed

#удовольствие_от_аналитики #тесты_rapeed

#удовольствие_от_аналитики #тесты_rapeed

#удовольствие_от_аналитики #тесты_rapeed

Аналитическая платформа Rapeed - в реестре российского ПО Минцифры
Вот это подарок так подарок для нас для всех! С Новым годом!!
Подробности >>
#удовольствие_от_аналитики

Вот раньше..)
С Романом Дидычем (Optimacros) и Алексеем Арустамовым (Loginom) обсуждаем нейросети и качество данных.

Разработка продукта
Разработка любого коммерческого продукта, и прежде всего Enterprise-продукта - это конусовидная спираль. Чем больше делаешь, тем больше делать на следующем шаге. И периодически возвращаешься почти туда же, откуда начинал.
#удовольствие_от_аналитики

Привет вновь присоединившимся подписчикам!
Чтобы вы не листали до начала канала, вот ссылка на первую публикацию)
А здесь скоро будет информация о тестах на 40 000 пользователей, работающих на одном контуре системы с двумя источниками по 4 млрд записей каждый. Продолжаем!
#удовольствие_от_аналитики

40 000 «трёхруких» пользователей на 3 источниках по 4 млрд записей - нагрузочные тесты rapeed
В декабре мы проводили тесты производительности системы на 300 пользователях на наших серверах. На самом деле мы готовились к гораздо более масштабным нагрузочным тестам, которыми мы занимались после этого вместе с крупным государственным заказчиком (спасибо вам огромное, коллеги!). И вот, наконец, мы их сделали!
Задачей тестов было промоделировать поведение целого города аналитиков из 40 000 пользователей, которые одновременно работают с rapeed, решая аналитические задачи - создать сводную таблицу различных конфигураций, раскрыть её, отсортировать, отфильтровать, построить другую таблицу на другом источнике, сделать подобные действия с ней, затем СВЯЗАТЬ эти источники по нескольким полям на лету, затем построить на этих связанных источниках сводную таблицу и опять её сортировать и фильтровать.
В ходе создания скрипта для тестов мы решили сделать пользователей трёхрукими, держащими по три мышки сразу, создавая одновременно три разных таблицы и делая в них разные операции. В жизни, конечно, люди работают медленно и делают паузы между действиями - но при таких паузах каждый тест длился бы по двое суток! Поэтому запросы на построение таблиц от каждого пользователя высылались пакетом. Более того, для моделирования одновременной нагрузки на систему мы объединяли по 333 и 500 пользователей в блоки.
Логика сценария выглядела так: от каждого пользователя в блоке генерировались запросы на создание, фильтрацию, раскрытие и сортировку трёх таблиц. При этом узлы, по которым происходило раскрытие и фильтрация, менялись от пользователя к пользователю перебором значений. Максимальное число одновременно посылаемых запросов к системе доходило до 30 000 (тридцати тысяч).
После отправки всех запросов собирались ответы системы для текущего блока пользователей - и запускался новый блок трёхруких аналитиков-пулемётов).
Пользователи работали на двух источниках данных по 4 млрд записей в каждом. У источников некоторые поля совпадали (одно из них Дата) - их связывали для получения показателя, рассчитываемого по двум источникам.
Такой сценарий выбрали, чтобы с лихвой перекрыть все возможные ситуации с одновременной работой пользователей и исследовать работу системы на больших источниках данных при интенсивной аналитической нагрузке. Нам также было интересно понять, какое влияние оказывает связывание полей на скорость расчетов.
Отдельным бонусом шла задача исследовать поведение системы при работе с источником, содержащим около 50 длинных текстовых полей - влияют ли длинные поля на производительность.
Каждая команда от каждого пользователя фиксировалась в логе (время, тип, другие параметры, в том числе уникальный номер Trace_Id), также собирались ответы системы (время обработки и Trace_Id).
По результатам тестов не было зафиксировано ни одного ошибочного ответа - система в 100% случаях отработала корректно и дала верные результаты расчетов.
Для запусков тестов коллеги выделили 25 виртуальных серверов, каждый с процессором Intel Xeon Gold 5220R CPU @ 2.20GHz, память 64 Гбайт, SSD 62 Гбайт. Общая распределенная память контура системы – 1 600 Гбайт. Плановая скорость сети - 100 Мбит/с. В ходе тестов фиксировались: загрузка CPU, использование памяти и сетевой трафик в среднем на контур и на каждой ноде.
Не знаю, проводил ли кто-то до этого в России нагрузочные тесты аналитической платформы в такой конфигурации. В некоторые моменты это напоминало DDOS-атаку аналитическими запросами! Мы получили крайне интересные результаты, о которых - в следующих постах.
#удовольствие_от_аналитики #тесты_rapeed

Результаты тестов. Скорость импорта и почему она такая
Начнем с импорта. Внизу в системном ответе видно, что источники, в которых по 5 полей и по 4 млрд записей, импортируются примерно за 6 часов:
ССЧ Большой = 6 часов 10 минут
Начислено большой = 5 часов 59 минут
⁃ и скорость импорта для них составляет 11,1 млн записей в минуту или 0,68 млрд записей/час.
Источник из 26 длинных текстовых полей (с кодовым названием «широкий») и 500 млн записей закачался за 5 часов 7 минут, и для него скорость составила 1,6 млн записей в минуту.
Для сравнения источников надо сказать, что в базе PostgreSQL, из которой производился импорт, этот «широкий» источник занимал больше места, чем «большие», и для дальнейшего его увеличения просто не было места на диске.
_________________
"data_sources": [
{
"id": "МСП синтетические",
"name": "МСП синтетические",
"state": "VALID",
"type": "PGSQL",
"rows_count": "500000000",
"created": "2025-02-27 19:06:45",
"updated": "2025-02-28 00:14:04",
…
},
{
"id": "ССЧ Большой",
"name": "ССЧ Большой",
"state": "VALID",
"type": "PGSQL",
"rows_count": "4000000512",
"created": "2025-02-03 10:07:36",
"updated": "2025-02-03 16:17:37",
…
},
{
"id": "Начислено Большой",
"name": "Начислено Большой",
"state": "VALID",
"type": "PGSQL",
"rows_count": "4000001024",
"created": "2025-02-03 21:33:03",
"updated": "2025-02-04 03:32:45",
…
}
_____________________
Импорт в rapeed можно представить как распределительный пылесос. Одним широким входным концом трубы импорт постоянно засасывает у источника данные блоками по 10 000 записей, а множеством отдающих труб отдает эти блоки нодам по кругу. Из-за такой параллельно-распределенной архитектуры скорость импорта максимально приближена к скорости драйвера СУБД-источника или, в случае файлового источника, к скорости чтения файлов с диска с учетом ограничений со стороны сети. Естественно, что пересылать по трубе сети блоки записей из пяти полей средней длины гораздо быстрее, чем из 26 длинных полей.
На нашем контуре импорт аналогичных пяти полей из MS SQL идет со скоростью 21,4 млн записей в минуту или 1,28 млрд записей/час - почти в два раза быстрее:
_________________
{
"id": "Пример чеков",
"name": "Пример чеков",
"state": "VALID",
"type": "MSSQL",
"rows_count": "365440448",
"created": "2025-03-08 18:38:07",
"updated": "2025-03-08 18:55:01",
…
}
_____________________
Импорт в rapeed - инкрементный. В случае больших источников данных первичная загрузка накопленных объемов может занимать существенное время. Зато объем ежедневных обновлений уже не будет таким большим.
Далее разберем среднее время отклика системы в тестах.
#удовольствие_от_аналитики #тесты_rapeed

Результаты тестов.
Среднее время отклика системы
За всё время тестов система выполнила более 2,5 миллионов запросов get_table во «взрывном» режиме. Запросы были к разным источникам (в том числе к связанным по двум полям), на разные действия и разной сути: таблицы разной конфигурации с нуля построить, раскрыть их, отфильтровать и отсортировать. Завершённый отклик системы - это JSON с данными таблицы, пришедший в интерфейс. Измерялось время посылки запроса (при этом формировался уникальный Trace_Id) и время получения JSON c этим Trace_Id.
Среднее время отклика в этих условиях будет скорее качественным показателем.
На массиве данных всех тестов среднее время отклика системы составило 1,3 секунды. Напомню, каждый запрос - это сводная таблица на одном или двух источниках по 4 млрд записей в условиях обработки до 30 000 одновременных запросов. Это примерно как классическая сервировка стола в условиях расстрела взводом автоматчиков)
Если посмотреть динамику среднего времени оклика по источникам (1й, 2й и составной), то она выглядит так (масштаб осей разный!):
#удовольствие_от_аналитики #тесты_rapeed

#удовольствие_от_аналитики #тесты_rapeed

Из этих графиков можно сделать два неожиданных вывода:
1. Получается, что при блоке из 500 пользователей время отклика меньше, чем на блоке из 333 (!!!)
2. Время отклика на составном источнике с двумя связанными полями меньше, чем сумма времён обработки двух исходных источников.
О втором факте мы знали и раньше, но первый факт неожиданный и пока объяснению не поддаётся.

Интересно проанализировать время отклика на каждом источнике в разрезе операций. На графиках распределения среднего времени отклика по количеству запросов в секунду каждая операция выделена своим цветом. При этом можно видеть, какое максимальное количество запросов в секунду выполнял контур и какое среднее время отклика у них было - 107 запросов в секунду при среднем времени 0.78 сек на запрос при блоке 333 пользователях и 100 запросов в секунду при 1.38 сек при блоке в 500 пользователей:
#удовольствие_от_аналитики #тесты_rapeed

#удовольствие_от_аналитики #тесты_rapeed

#удовольствие_от_аналитики #тесты_rapeed

При сравнении быстродействия в разрезе операций хорошо бы учитывать не только среднее время, но и минимальное с максимальным для оценки разброса значений.
Ниже привожу пример такого анализа. Для него хорошо подойдет область связей - в таблице нужно раскрывать каждый узел, а здесь есть полный список операций со всеми показателями, связанных с источниками:
#удовольствие_от_аналитики #тесты_rapeed

#удовольствие_от_аналитики #тесты_rapeed

Дальше узнаем, какая была нагрузка на вычислительные мощности и что вообще происходит при расчетах в rapeed
#удовольствие_от_аналитики #тесты_rapeed

Результаты тестов.
Нагрузка на вычислительные мощности
Параллельно с логами в тестах фиксировалась нагрузка на CPU, память и сеть. Потом оценку нагрузки на сеть выключили, поскольку она была крайне низка.
На скриншоте внизу видно, что нагрузка на CPU небольшая: в момент скриншота средняя нагрузка на процессоры контура составляет 6,4%. Система зарезервировала весь процессор под себя (синий фон), но понадобилось только 6,4%. За всё время вычислений загрузка CPU не превышала 15%.
В левой части скриншота виден блок высокой нагрузки - это была авторизация 40 000 пользователей. Поскольку авторизация связана с криптографией и выдачей токенов, то это «дорогая» с точки зрения потребления CPU операция. Поскольку в жизни одновременных авторизаций десятков тысяч пользователей не бывает, то эта информация непосредственно к работе системы не относится.
Потребление памяти стабильно, практически без флуктуаций. Как данные попали в распределенную память нод, так они там и живут. Сессии и задания пользователей памяти дополнительно практически не потребляют.
#удовольствие_от_аналитики #тесты_rapeed

#удовольствие_от_аналитики #тесты_rapeed

Результаты тестов. Интерпретация и выводы
Тесты безусловно достигли своей цели, полностью доказав, что rapeed на одном контуре (то есть с одной точкой входа для пользователей, или иначе с одним master-ом) способен обслуживать 40 000 пользователей, работающих во «взрывном» режиме с большими источниками данных, причем с большим практическим запасом, сохраняя при этом время отклика менее 2 секунд.
Вторая цель тестов была - оценить, как связывание источников на лету влияет на скорость обработки запросов. Здесь тоже есть результат - технология связанных полей оправдала ожидания.
То, что размер источников - 4 млрд записей, объясняется спецификой задачи и дефицитом места. Если источники будут по 40 млрд, 400 млрд или любого другого размера, нужно будет рассчитать потребность в «железе», импортировать данные - и система будет работать.
Что происходит при расчетах и от чего зависит время отклика? В наших внутренних тестах оно составляло 0,1 сек на 400 млн записей, да и в этих нагрузочных тестах значительная доля откликов выполнялась за доли секунды.
Расчетные операции в rapeed состоят из следующих этапов:
- первичное распределенное чтение данных с диска;
- расчеты внутри нод;
- сетевой обмен внутри распределенной памяти нод;
- расчеты внутри распределенной памяти;
- формирование ответа в формате JSON;
- пересылка ответа потребителю в формате JSON.
Бывают ответы такого большого размера (хоть у нас в ядре и пагинация, то есть задается, сколько первых N элементов нужно), что только их пересылка по сети займет полсекунды - например, раскрытие длинного текстового поля, когда сверху в таблице тоже текстовые поля.
Система адаптируется к пересылкам расчетов определенных конфигураций, и повторно высылает их быстрее. Когда конфликтующих запросов много, на разных уровнях возникают очереди их обработки, и тогда скорость их обработки зависит от десятков практически случайных факторов типа состояния каналов памяти.
Одно можно сказать определенно: архитектура системы была разработана именно под такую нагрузку и под такие задачи и успешно справилась со стресс-тестами.
#удовольствие_от_аналитики #тесты_rapeed