EMR 上 Spark 批处理作业的优化

Question

我们正在 EMR 集群上运行一个 spark-job，集群配置如下所示。

Resources:
Node Type:CORE - 2 INSTANCES OF
r4.8xlarge
32 vCore, 244 GiB memory, EBS only storage
EBS Storage:32 GiB

Node Type: MASTER
1 Instance of r4.4xlarge
16 vCore, 122 GiB memory, EBS only storage
EBS Storage:32 GiB

Node Type: TASK- 
2 INSTANCES Of 
r4.4xlarge
16 vCore, 122 GiB memory, EBS only storage
EBS Storage:32 GiB

我们在 EMR 控制台上使用以下参数进行 spark-submit：

/usr/bin/spark-submit --deploy-mode cluster --conf spark.sql.parquet.fs.optimized.committer.optimization-enabled=true --conf spark.sql.files.ignoreCorruptFiles=true --driver-memory 5g --master yarn --class class_name s3://location_of_jar -c s3://location of input to jar -w xyz.json

我们认为这些论点没有利用可用的全部可用资源。 任何人都可以通过更改任何 spark-defaults.conf 文件或传递更多参数来建议是否有任何其他优化的方法在 EMR 上执行 spark-submit，以便对所有可用资源进行最佳利用？ 我们一次运行一项工作。 集群上没有运行并行作业

Answer 1

如果不知道每个执行者分配的资源、工作的性质、你正在处理的数据量等，就很难给出正确的建议。 我认为您现在可以做的最好的事情是在创建 EMR 集群的同时安装 ganglia。 ganglia 网络用户界面可通过http://master-public-dns-name/ganglia/

先看cpu和内存使用情况。 如果您为 Spark 作业优化分配资源，然后相应地调整每个执行程序的资源，这将为您提供一个足够好的主意。

可以使用以下方式在 spark-submit 命令中设置执行程序、执行程序内存和内核的数量（这些是示例值）：

--num-executors 10
--executor-cores 1
--executor-memory 5g

查看神经节图表后，您将了解哪些资源被利用不足/过度利用。 相应地更改这些。

如果您不想玩弄这些数字并让 spark 决定最佳组合，那么使用以下几行将动态资源分配设置为 true 可能是值得的：

--conf spark.shuffle.service.enabled=true
--conf spark.dynamicAllocation.enabled=true

这里需要注意的一件事是，yarn 将获得分配给核心 + 任务节点的总内存的 75%。 此外，驱动程序和每个执行程序都有与之相关的内存开销。 查找 spark 文档。 在手动为驱动程序和执行程序分配资源时请记住这一点。

Answer 2

分析spark job第一步是spark-ui 。 因此，请使用tracking url并查看ogs, jobs, executors, streaming 。

http://cluster_manager_host:8088/

如需更详细的内存和 CPU 利用率分析，您也可以使用Gangalia工具。

http://cluster_manager_host/Gangalia

在此之后，您可以做的是：

• 您必须进行自定义配置，例如

  (i) 执行者--conf num-executors x

  (ii) Executors memory --conf executor-memory y

  (iii) 核心数-- conf executor-cores z

  (iv) 启用动态资源分配--conf spark.dynamicAllocation.enabled=true

  (v) 启用最大资源分配--conf maximizeResourceAllocation=true

  (vi) 将serialisation从默认更改为Kryo , --conf org.apache.spark.serializer.KryoSerializer

  (vii) 根据您的配置将分区数量从默认更改为自定义rdd=rdd.repatition(sparkConf.defaultParalallism*2)

• 如果在上面正确配置您的工作后仍然很慢，请更改您的代码并使用正确的函数和对象。 喜欢

  (i) 如果您将数据发送到 Kinesis、DB 或 Kafka 等任何外部目的地，请使用 mapPartitions 或 foreachPatitions 并减少对象创建。

  (ii) 如果您正在调用外部 API，那么也请遵循上述策略。

  (iii) 使用适当的数据结构。

有关更多信息，您可以参考： 这里

我希望这能帮到您。