Comments 9
Для динамической аллокации еще полезно знать про опцию spark.dynamicAllocation.cachedExecutorIdleTimeout, потому что если экзекутор закэшировал данные, то по истечению executorIdleTimeout он не будет остановлен.
И указывать 20 гигабайт и 5 ядер - странная необоснованная практика. Например, я (тоже почти ничем не обоснованно, да) чаще использую 4 ядра и 10 гигабайт, и в 99% случаев этого достаточно.
Слух про оптимальные 5 ядер - он давно ходит по интернету. И всегда все ссылаются на одну и туже статью, где это основано на утверждении, что если больше 5 ядер выделить, то HDFS будет якобы плохо. Только вот измерений там никаких нет, и в итоге непонятно, каким образом вообще на HDFS может влиять то, сколько ядер выделено на один executor.
Я уже не говорю о том, что в принципе, spark может не работать с HDFS, в частном случае. А например, читать данные из реляционной БД по JDBC, или скажем из HBase, ну или из кафки. В общем, заниматься чем-то другим.
А еще практически все подобные тексты исходят из того, что кластер находится в полном нашем распоряжении. В то время как в реальности, под управлением Yarn, вы можете запросить больше ресурсов, чем выделено для вашей Yarn очереди (а не имеющихся в кластере), и будете именно что ждать в очереди, пока ресурсы освободятся. Так что тема стояния в очереди вообще не раскрыта.
Да, я не хочу сказать, что 5 ядер вообще смысла не имеют. Я хочу сказать, что конкретно 5 ядер ни на чем не основаны. И еще, если вы увеличиваете число ядер - то вы должны и память на executor практически пропорционально увеличить. А это уже повлечет определенные негативные последствия. То есть, какой-то оптимум тут скорее всего есть, но каков он конкретно - зависит от многих параметров, и в первую очередь от профиля нагрузки - т.е. от того, чем ваше приложение вообще занимается.
И сколько вы у себя по итогу ядер на экзекутор вделяете? Больше 5? Замеры не делали?
Задумался, что тоже воспринимаю как истину "не больше 5, дальше производительность не увеличивается все равно". Не знал даже, что это утверждение заждится всего на одном первоисточнике
Основной мой посыл в том, что это число зависит от профиля нагрузки приложения. То есть, если причина ограничения в 5 в производительности HDFS - то зачем мне пять ядер, если у меня в ряде случаев приложение занимается тем, что читает данные миллионами строк из реляционной БД по JDBC, и кладет в кафку? А может у конкретного приложения и HDFS нет вообще.
Нет, у нас скорее как правило меньше. Потому что чтение из БД это наше одно из основных занятий у приложения.
Про слух про оптимальные 5 ядер я думаю в курсе все, кто использует pyspark :)
В идеале при регулярных расчетах надо все обвесить мониторингами потребления памяти, процессоров, смотреть, есть ли spill. И еще исходить из баланса времени расчета, ресурсов и человеческих договоренностей, ведь на кластере мы никогда не бываем в одиночестве.
При разовых расчетах всем хочется быстрее получить результат, но тут опять же надо учитывать тот баланс ресурсов, времени и загруженности кластера.
А чтобы не стоять в очереди, достаточно иметь один экзекутор, одно ядро и гигабайт памяти. Только вот зачем?
Про слух про оптимальные 5 ядер я думаю в курсе все, кто использует pyspark :)
Я пишу на Java/Scala, если что, та же фигня :)
Число возможных вариантов далеко не бесконечно, от 1 до числа ядер на узле кластера (минус константа). И где-то там очевидно оптимум есть. И я даже не исключаю, что иногда он равен пяти.
И да, вопрос мониторинга был поднят возможно в первой статье на эту тему, что мне попалась на хабре с год назад.
Только вот зачем?
Тут на самом деле имелось в виду, что мы знаем параметры очереди Yarn (хотя с учетом наследования от родительской очереди определить их далеко не тривиально). И ориентироваться при выборе ресурсов вполне можем на очередь, а не на параметры голого кластера. В зависимости от текущего профиля его нагрузки. Но это сложный вопрос, и у меня нет на него даже примерных ответов.
Спасибо большое за фидбек, по поводу spark.dynamicAllocation.cachedExecutorIdleTimeout мы планируем рассказать по данному параметру в следующей статье, что касается выбора 5 ядер, выбрано в рамках практических решений, плюс также был выполнен тест, в виде простой задачи которая также описана, в случае с 5ю ядрами результат оказался самым эффективным, никто не запрещает уменьшать или увеличивать, также хочу отметить что данная статья подходит больше для молодых специалистов, которые не выполняют сложных расчетов, и делают базовые запросы вызова и вывода результатов
Небольшое замечание: собираете результаты с помощью функции toPandas() может быть конкретно вы в вашем случае, но это далеко не самая широко используемая функция. Это ещё pandas должен быть установлен. По умолчанию используется родная функция collect()
Подбираем параметры сессии в Apache Spark, чтобы не стоять в очереди