Определение оптимального количества разделов Spark на основе рабочих, ядер и размера DataFrame

Question

В Spark-land существует несколько аналогичных, но разных концепций, связанных с тем, как работа обрабатывается на разных узлах и выполняется одновременно. В частности, есть:

• Узел Спарк драйвера (sparkDriverCount)
• количество рабочих узлов доступны для искрового кластера (numWorkerNodes)
• Число искровых исполнителей (numExecutors)
• DataFrame эксплуатируется на всех рабочих/исполнителей, одновременно (dataFrame)
• число строк в dataFrame (numDFRows)
• Количество разделов на dataFrame (numPartitions)
• И, наконец, количество ядер процессора доступны на каждый работник узлов (numCpuCoresPerWorker)

Я считаю, , что все кластеры имеют Свечи один-and only-one Spark Driver, а затем 0+ рабочих узлов. Если я ошибаюсь, начните с исправления! Предполагая, что я более или менее корректен, давайте запишем здесь несколько переменных. Предположим, у нас есть Spark-кластер с 1 драйвером и 4 рабочими узлами, и каждый рабочий узел имеет 4 ядра процессора (так что в общей сложности 16 ядер процессора). Таким образом, «данный» здесь:

sparkDriverCount = 1 
numWorkerNodes = 4 
numCpuCores = numWorkerNodes * numCpuCoresPerWorker = 4 * 4 = 16 

Учитывая, что в качестве установки мне интересно, как определить несколько вещей. В частности:

• Какова взаимосвязь между numWorkerNodes и numExecutors? Существует ли известное/общепринятое отношение работников к исполнителям? Есть ли способ определить numExecutors с учетом numWorkerNodes (или любых других входов)?
• Есть ли известное/общепринятое/оптимальное отношение от numDFRows до numPartitions? Как вычислить «оптимальное» количество разделов на основе размера dataFrame?
• Я слышал от других инженеров, что общее «эмпирическое правило»: numPartitions = numWorkerNodes * numCpuCoresPerWorker, любая правда? Другими словами, он предписывает, что на 1 ядре процессора должно быть 1 раздел.

Answer 1

Да, a spark Приложение имеет one and only Driver.

Какая связь между numWorkerNodes и numExecutors?

Работник может размещать несколько исполнителей, вы можете думать о нем как о работнике как о машине/узле вашего кластера, а исполнитель должен быть процессом (выполняющим в ядре), который выполняется на этом рабочем месте.

Так что `numWorkerNodes < = numExecutors '.

Есть ли рацион для них?

Лично, работая в поддельной кластере, где мой ноутбук был водитель и виртуальная машина в тот же ноутбук был рабочий, и в промышленном кластере> 10k узлов, я не сделал вам нужно заботиться об этом, так как кажется, что spark позаботится об этом.

Я просто использовать:

--num-executors 64 

когда я запускаю/представить свой сценарий и spark знает, я думаю, сколько рабочих он должен вызвать (конечно, принимая во внимание другие параметры, а также и характер машин).

Таким образом, лично я не знаю такого отношения.

---

Есть ли известный/общепринятым/оптимальное соотношение numDFRows к numPartitions?

Я не знаю одного, но, как правило, вы могли бы рассчитывать на продукт #executors по # executor.cores, а затем умножить на 3 или 4. Конечно, это эвристический. В pyspark это будет выглядеть следующим образом:

sc = SparkContext(appName = "smeeb-App") 
total_cores = int(sc._conf.get('spark.executor.instances')) * int(sc._conf.get('spark.executor.cores')) 
dataset = sc.textFile(input_path, total_cores * 3) 

Как один вычислить «оптимальное» количество разделов на основе размера DataFrame?

Это отличный вопрос. Конечно, трудно ответить, и это зависит от ваших данных, кластера и т. Д., Но, как обсуждалось, here с собой.

Слишком мало перегородок, и у вас будут огромные куски данных, особенно когда вы имеете дело с bigdata, тем самым помещая ваше приложение в стресс.

Слишком много перегородок, и у вас будет большое давление, так как все метаданные, которые должны быть сгенерированы из hdfs, значительно увеличиваются по мере увеличения количества разделов (поскольку он поддерживает временные файлы и т. Д.). ^*

Так что вы хотите слишком найти сладкое пятно для количества разделов, что одна из частей тонкой настройки приложения. :)

«Правило большого пальца»: numPartitions = numWorkerNodes * numCpuCoresPerWorker, это правда?

А, я писал эвристику выше, прежде чем видеть это. Так что это уже ответили, но учтите разницу и исполнитель.

---

^* Я просто неуспешно сегодня: Prepare my bigdata with Spark via Python, при использовании слишком много разделов вызвало Active tasks is a negative number in Spark UI.