Нужно ли еще настраивать параметры конфигурации свечи при использовании Google CloudDataproc?

Question

Для уточнения:

• Обычно при написании заданий на спарк необходимо указывать конкретные значения для различных конфигураций искры, чтобы использовать ресурсы кластера наиболее оптимальным образом.Мы можем сделать это программно при инициализации SparkSession:

  SparkSession.builder .appName (SPARK_APP_NAME) .config ("spark.executor.memory", "1G")

• Что я хотел бы знать, так это то, что мы все еще должны это делать при использовании Cloud Dataproc?Фактически, при создании кластера Dataproc происходит инициализация файла свойств с именем cluster.properies, содержащего такие значения, как spark\:spark.executor.memory=2688m.Итак, мне было интересно, если Dataproc автоматически заполняет эти значения оптимально по отношению к ресурсам кластера, и в этом случае нам не нужно настраивать эти конфигурации свечи вручную / программно?

Answer 1

Ответ - да.Это зависит от поведения вашего спарк-приложения, от того, сколько vm вы запускаете и какой тип vm вы используете.Ниже приведен пример настройки параметра.

default_parallelism=512

PROPERTIES="\
spark:spark.executor.cores=2,\
spark:spark.executor.memory=8g,\
spark:spark.executor.memoryOverhead=2g,\
spark:spark.driver.memory=6g,\
spark:spark.driver.maxResultSize=6g,\
spark:spark.kryoserializer.buffer=128m,\
spark:spark.kryoserializer.buffer.max=1024m,\
spark:spark.serializer=org.apache.spark.serializer.KryoSerializer,\
spark:spark.default.parallelism=${default_parallelism},\
spark:spark.rdd.compress=true,\
spark:spark.network.timeout=3600s,\
spark:spark.rpc.message.maxSize=256,\
spark:spark.io.compression.codec=snappy,\
spark:spark.shuffle.service.enabled=true,\
spark:spark.sql.shuffle.partitions=256,\
spark:spark.sql.files.ignoreCorruptFiles=true,\
yarn:yarn.nodemanager.resource.cpu-vcores=8,\
yarn:yarn.scheduler.minimum-allocation-vcores=2,\
yarn:yarn.scheduler.maximum-allocation-vcores=4,\
yarn:yarn.nodemanager.vmem-check-enabled=false,\
capacity-scheduler:yarn.scheduler.capacity.resource-calculator=org.apache.hadoop.yarn.util.resource.DominantResourceCalculator
  "

gcloud dataproc clusters create ${GCS_CLUSTER} \
       --scopes cloud-platform \
       --image pyspark-with-conda-v2-365 \
       --bucket  spark-data \
       --zone  asia-east1-b  \
       --master-boot-disk-size  500GB \
       --master-machine-type n1-highmem-2 \
       --num-masters  1 \ 
        --num-workers  2 \
       --worker-machine-type n1-standard-8 \
       --num-preemptible-workers 2 \
       --preemptible-worker-boot-disk-size 500GB \
       --properties ${PROPERTIES} 

Answer 2

Dataproc действительно обеспечивает интеллектуальные значения по умолчанию, основанные на типах машин (даже нестандартных типах машин) и форме кластера, которые предназначены для лучшей настройки "один размер подходит всем", которая балансирует между эффективностью большего количества потоков на JVM с ограничениями наобщие пулы ресурсов на JVM;грубо говоря, машины разделены таким образом, чтобы соответствовать 2 исполнителям на машину, и каждому исполнителю предоставляется половина потоков машины (так что можно ожидать, что 2 исполнителя, каждый из которых способен выполнять 4 задачи параллельно на n1-standard-8, например,).

Имейте в виду, что YARN, как известно, неправильно сообщает vcores для многопоточных исполнителей Spark , поэтому вы можете видеть только два занятых YARN "vcores" при выполнении большого задания Spark в Dataproc,но вы можете убедиться, что все ядра действительно используются, посмотрев страницы Spark AppMaster, запустив ps на рабочем месте или посмотрев использование ЦП на странице облачной консоли Dataproc.

Однако эти типы настроекне всегда универсальны на 100% «оптимальны», и Dataproc еще не может автоматически предсказать настройки на основе фактической рабочей нагрузки или исторических рабочих нагрузок, которые вы выполняли.Таким образом, любые настройки, основанные исключительно на форме кластера, не могут быть на 100% оптимальными для всех рабочих нагрузок, которые выполняются в этом кластере.

Короче говоря, в Dataproc вам не нужно беспокоиться об явной оптимизации в большинстве случаев.если вы не пытаетесь действительно выжать каждую унцию эффективности, но в то же время вы всегда можете свободно изменять настройки Dataproc своими собственными свойствами либо при создании кластера, либо при отправке задания, если это необходимо.Несколько моментов, которые следует учитывать:

• Если у вас более высокая нагрузка на процессор по сравнению с нагрузкой на память, рассмотрите возможность использования типов машин типа «highcpu», и Dataproc автоматически назначит каждому исполнителю меньше памяти для каждого процессора.
• Если у вас более высокая нагрузка на память, рассмотрите типы highmem
• Если ваши входные данные не разделяемы и / или сильно сжаты (например, файлы .csv.gz), вы можете с большей вероятностью запуститьв проблемы с памятью, так как обычные вычисления параллелизма не будут знать, взорвется ли входные данные, чтобы быть больше, чем ожидалось.В этих случаях вам может потребоваться переопределить память исполнителя, чтобы она была больше
• Если вы используете подпроцессы или собственные библиотеки, такие как вызов ffmpeg из рабочих задач, тогда задачи будут использовать физическую память за пределами знаний YARN / Spark;вам также может понадобиться настроить ограничения памяти в этих случаях, либо уменьшив количество ядер на исполнителя, либо увеличивая накладные расходы памяти исполнителя.
• Если у вас есть что-то очень ограниченное для ввода-вывода или блокирующее другие асинхронные функции (например, вызов медленноговнешняя веб-конечная точка из ваших задач), тогда вы могли бы извлечь выгоду из запуска ядер для каждого исполнителя;тогда Spark выполняет больше задач, чем процессоров, но если задачи просто ожидают ввода-вывода, это будет полезно для повышения эффективности.