Мы тестируем искры с Alluxio и Presto с Alluxio. Для оценки производительности мы взяли 5 разных запросов (с некоторыми объединениями, сгруппированными и отсортированными) и выполнили его для набора данных 650 ГБ в orc.
Среда исполнения Spark настроена таким образом, что у нас постоянно работает контекст spark, и мы отправляем запросы с использованием REST api (сервер Jetty). Мы не рассматриваем время первого пакета для этого нагрузочного теста, поскольку оно занимает немного больше времени из-за десериализации задач и всего остального.
Что мы наблюдали при оценке, так это то, что когда мы выполняли отдельные запросы или даже все эти 5 запросов выполнялись одновременно, spark работает очень хорошо по сравнению с presto и заканчивает все выполнение в два раза быстрее, чем Presto.
Но для теста фактической нагрузки мы выполнили 10 пакетов (один пакет - это 5 запросов, отправленных одновременно) с интервалом 60 секунд. На данный момент Presto работает намного лучше, чем искра. Presto закончил всю работу за ~ 11 минут, а искра занимает ~ 20 минут, чтобы выполнить всю задачу.
Мы пытались использовать различные конфигурации для улучшения параллелизма, например
- Использование 20 пулов с равным распределением ресурсов и отправка заданий в циклическом режиме.
- Попытка использования одного пула FAIR и отправка всех заданий в этот пул по умолчанию, и пусть spark принимает решение о распределении ресурсов
- Настройка некоторых искровых свойств, таких как
spark.locality.wait и некоторых других искровых свойств, связанных с памятью.
- Все задачи - NODE_LOCAL (мы реплицировали данные в alluxio, чтобы это произошло)
- Также попытался воспроизвести arround с выделением памяти для исполнителя, как и для 35 небольших исполнителей (5 ядер, 30G), а также для (60core, 200G) исполнителей.
Но все приводят к одному и тому же времени выполнения.
Мы использовали dstat на всех рабочих, чтобы увидеть, что происходило, когда искра выполняла задачу, и мы не могли видеть минимального ввода-вывода или сетевой активности. И процессор всегда был на уровне 95% + (похоже, он ограничен на процессоре). (Видел почти аналогично dstat out с presto)
Может кто-нибудь предложить мне что-то, что мы можем попытаться достичь аналогичных или лучших результатов, чем Presto?
И есть ли какое-то объяснение, почему presto работает лучше с параллелизмом, чем spark? Мы заметили, что первая партия Presto занимает больше времени, чем последующие партии. Presto кеширует некоторые данные в памяти, искры которых нет? Или план управления / выполнения ресурсов presto лучше, чем spark?
Примечание. Оба кластера работают с одинаковой аппаратной конфигурацией