Я реализую Apache Spark Планирование в вот так (Scala code):
// group into list of 10 items...
val maxSimultaneousSubmitAndMonitorThreadsInDriver = 10
// ... in order to throttle the number of threads submitting and monitoring apps at a time
val lists = myList grouped maxSimultaneousThreadsInDriver
for (aList <- lists) {
// pick a list, then convert it to Scala Parallel list
aList.par.foreach { // so 10 threads MAX at a time, that can handle job submission and monitoring
case (file_name) => {
// in each driver thread, create different Spark session
val sparkChild = sparkMain.newSession()
// then do specific stuff with such session
val childDF = sparkChild.read.parquet( filename + "_directory/*.parquet")
...
}
}
}
Итак, как вы знаете, с концепцией Планирование в такой экземпляр одного драйвера может контролировать несколько приложений Spark. поэтому У меня может быть несколько приложений Spark, которые запускаются одновременно . (В моем случае каждое приложение Spark может затем выполнять очень специфические c задачи на чтение файла, основываясь на имени, в зависимости от бизнес-правил).
Планировщик по умолчанию настроен в режиме FIFO:
По умолчанию планировщик Spark выполняет задания в режиме FIFO. Каждое задание делится на «этапы» (например, сопоставление и уменьшение фаз), и первое задание получает приоритет над всеми доступными ресурсами, в то время как его этапы имеют задачи для запуска, затем второе задание получает приоритет, например c. Если заданиям, находящимся в начале очереди, не нужно использовать весь кластер, более поздние задания могут начать выполняться сразу же [...]
Такое решение работает для меня. Однако я нашел Планирование искры в немного медленно . Например, когда я вижу вкладку Spark UI Executors , я вижу, что большую часть времени используются только несколько ядер.
Это противоположность классическим приложениям Spark, которые у меня естественным образом полностью загружают ЦП почти все время!
Итак, мой последний вопрос, как оптимизировать производительность Планирование искры в пределах ?
Что я пробовал:
- изменение
maxSimultaneousSubmitAndMonitorThreadsInDriver, чтобы регулировать число потоков, которые отправляют и отслеживают приложение в данный момент времени - пытается увеличить
spark.scheduler.listenerbus.eventqueue.capacity - пытается увеличить / уменьшить
spark.default.parallelism - пытается увеличить / уменьшить
spark.sql.shuffle.partitions
Если я увеличу количество потоков, которые могут одновременно отправлять и отслеживать приложения Spark (с помощью системы управления газом), я получаю OOM.
Относительно spark.default.parallelism и spark.sql.shuffle.partitions, я не знаю, как выбрать соответствующее значение. Если я НЕ Планирование в (только с одним приложением на драйвер), то значение, которое я установлю, вероятно, будет 192 (число ядер), чтобы иметь хорошие результаты.
Но с Планирование в пределах неясно. Каждое представленное задание является небольшим, и параллелизм 192 для каждого задания кажется излишним (и медленным?) ..
Любая информация будет принята с благодарностью