hadoop - yarn Spark 作业调度较慢

Question

我有两个具有以下配置的 mapr 集群，

cluster 1: hosted on aws, 3 nodes with 32g of memory/32 cores each
cluster 2: hosted on bare-metal servers, 8 nodes with 128g of memory/32 cores each

我在两个集群上通过 yarn 运行一段 pyspark 代码

df=hc.sql("select * from hive_table")
df.registerTempTable("df")
df.cache().count()
for: 100times
    result=hc.sql('select xxxx from df')
    result.write.saveAsTable('some hive table', mode='append')

以上代码在 spark 中提交了 100 个新作业(在 yarn 之上运行)。在集群 1 上，整个操作在 30 分钟内完成，但在更大的集群 2 上，完成相同操作需要 90 分钟。检查后，我发现虽然每个作业花费的时间几乎相同(在集群 2 中快一点)，但在 2 中每个作业之间的时间比 1 长得多。

可能的原因，

1. 驱动程序和执行程序节点之间的延迟？ -- 我正在运行
   yarn 客户端模式
2. 驱动程序内存不足或我在 yarn 上启动 spark 集群的方式有误？

如何提交作业？

Cluster 1: /opt/mapr/spark/spark-1.6.1/bin/spark-submit --master yarn --deploy-mode client --num-executors 10 --executor-memory 10g --executor-cores 5 --driver-memory 10g --driver-cores 10 --conf spark.driver.maxResultSize="0" --conf spark.default.parallelism="100" --queue default

Cluster 2: /opt/mapr/spark/spark-1.6.1/bin/spark-submit --master yarn --deploy-mode client --num-executors 10 --executor-memory 80g --executor-cores 28 --driver-memory 25g --driver-cores 25 --conf spark.driver.maxResultSize="0" --conf spark.default.parallelism="100" --queue default

附言:只贴了部分代码。代码中还有其他模块。总的来说，集群 2 处理代码的速度比集群 1 快 3 倍，所以我不认为“一般”速度有问题。

我的问题更具体到作业之间的“时间”。例如，上面的代码运行 100 个 spark-sql 作业，每个作业在集群 2 中平均花费 2 秒，在集群 1 中平均花费 5 秒。与集群 1 相比，集群 2 中每个作业之间的时间太长了。

Answer 1

在你的伪代码中我没有看到任何与驱动程序相关的操作(假设执行者将数据保存到分布式文件系统)

请注意:

1. 您 df.cache() 但您似乎没有使用缓存的 df。
2. 您的 yarn-client 配置似乎有问题。

看起来您正在尝试使用比可用更多的执行程序内存和内核。

在集群 #1 中，有 3 个 32GB 内存的节点，你的执行代码是:--num-executors 10 --executor-memory 10g

最好的情况是您将拥有 9 个执行程序，每个执行程序具有 10GB 的 RAM。每个节点上最多 3 个执行程序。我假设您每个节点只能执行 2 个执行程序(因为从 32GB 的 RAM 开始，超过 2GB 的内存将用于 yarn 、开销等，因此将剩下不到 29GB ==> 2 个容器每个 10GB)

==> Cluster #1 将有 6 到 9 个执行器

在集群#2 中，有 5 个节点，128GB RAM，你的执行代码是:--num-executors 10 --executor-memory 80g

最好的情况是您将拥有 5 个具有 80GB RAM 的执行程序。每个执行者在一个节点上。

由于集群 #1 有更多的执行器(即使它们更小)，它可能运行得更快(取决于您的应用程序)

减少集群 #2 中的执行程序内存和内核，同时增加执行程序的数量应该会提供更好的性能。