Проблема с производительностью параллелизма Spark по сравнению с Presto

Мы сравниваем Spark с alluxio и presto с alluxio. Для оценки производительности мы взяли 5 разных запросов (с некоторыми объединениями, группировкой и сортировкой) и выполнили их на наборе данных объемом 650 ГБ в orc.

Среда выполнения Spark настроена таким образом, что у нас есть постоянно работающий контекст Spark, и мы отправляем запросы с помощью REST api (сервер Jetty). Мы не рассматриваем время выполнения первого пакета для этого нагрузочного теста, так как он занимает немного больше времени из-за десериализации задачи и всего остального.

При оценке мы наблюдали, что когда мы выполняли отдельные запросы или даже все эти 5 запросов, выполняемых одновременно, Spark работает очень хорошо по сравнению с presto и завершает все выполнение в два раза быстрее, чем presto.

Но для фактического нагрузочного теста мы выполнили 10 пакетов (один пакет - это 5 запросов, отправленных одновременно) с интервалом пакета 60 секунд. На данный момент presto работает намного лучше, чем Spark. Presto завершил всю работу за ~ 11 минут, а Spark занял ~ 20 минут, чтобы выполнить все задачи.

Мы пробовали разные конфигурации для улучшения искрового параллелизма, например

• Использование 20 пулов с равным распределением ресурсов и циклическая отправка заданий.
• Пытался использовать один пул FAIR и отправил все задания в этот пул по умолчанию, и пусть Spark принимает решение о выделении ресурсов.
• Настройка некоторых свойств искры, таких как spark.locality.wait, и некоторых других свойств искры, связанных с памятью.
• Все задачи - NODE_LOCAL (мы реплицировали данные в alluxio, чтобы это произошло)
• Также попытался поиграть с распределением памяти исполнителя, например, попытался с 35 небольшими исполнителями (5 ядер, 30 ГБ), а также попытался с исполнителями (60 ядер, 200 ГБ).

Но все они имеют одинаковое время выполнения. Мы использовали dstat на всех воркерах, чтобы увидеть, что происходило, когда Spark выполнял задачу, и мы не могли видеть никакой или минимальной активности ввода-вывода или сетевой активности. И ЦП всегда был на 95% + (похоже, что он ограничен ЦП). (Видел почти аналогичный dstat с presto)

Может ли кто-нибудь предложить мне что-то, что мы можем попытаться достичь аналогичных или лучших результатов, чем presto?

И какое объяснение, почему presto лучше работает с параллелизмом, чем Spark? Мы заметили, что первая партия presto занимает больше времени, чем последующие партии. Кэширует ли presto некоторые данные в памяти, искра которой отсутствует? Или план управления ресурсами / выполнения presto лучше, чем Spark?

Примечание. Оба кластера работают с одинаковой конфигурацией оборудования.