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) 使用適當的數據結構。

有關更多信息，您可以參考： 這里

我希望這能幫到您。