apache-spark - Spark yarn cluster vs client - 如何选择使用哪一个？

Question

Spark docs有以下段落描述了 yarn 客户端和 yarn 集群之间的区别:

There are two deploy modes that can be used to launch Spark applications on YARN. In cluster mode, the Spark driver runs inside an application master process which is managed by YARN on the cluster, and the client can go away after initiating the application. In client mode, the driver runs in the client process, and the application master is only used for requesting resources from YARN.

我假设有两个选择是有原因的。如果是这样，您如何选择使用哪一种？

请使用事实来证明您的回答是合理的，以便此问题和答案符合 stackoverflow 的要求。

stackoverflow 上有一些类似的问题，但是这些问题关注的是两种方法之间的区别，而不是一种方法何时比另一种更适合。

Answer 1

一种常见的部署策略是从物理上与您的工作机器位于同一位置的网关机器(例如，独立 EC2 集群中的主节点)提交您的应用程序。在此设置中，客户端模式是合适的。在客户端模式下，驱动程序直接在作为集群客户端的 spark-submit 进程中启动。应用程序的输入和输出附加到控制台。因此，这种模式特别适用于涉及 REPL 的应用程序(例如 Spark shell)。

或者，如果您的应用程序是从远离工作机器的机器提交的(例如，在您的笔记本电脑上本地)，通常使用集群模式来最小化驱动程序和执行程序之间的网络延迟。请注意，Mesos 集群目前不支持集群模式。目前只有 YARN 支持 Python 应用程序的集群模式。"-- Submitting Applications

我从中了解到的是，这两种策略都使用集群来分发任务；不同之处在于“驱动程序”的运行位置:使用 spark-submit 在本地运行，或者也在集群中运行。

当你应该使用它们中的任何一个时，上面的引用中有详细说明，但我还做了另一件事:对于大 jar ，我使用了 rsync以 100 倍的网速将它们复制到集群(甚至主节点)，然后从集群提交。对于大 jar 来说，这可能比“集群模式”更好。请注意，客户端模式可能不会将 jar 传输到主控。在这一点上，两者之间的差异很小。当驱动程序大部分时间处于空闲状态时，客户端模式可能会更好，以充分利用本地机器上的内核，并可能避免将 jar 传输到主服务器(即使在环回接口(interface)上，一个大 jar 也需要相当多的时间) .使用客户端模式，您可以在任何集群节点上传输(rsync)jar。

另一方面，如果驱动程序非常密集，在 cpu 或 I/O 中，集群模式可能更合适，以更好地平衡集群(在客户端模式下，本地机器将同时运行驱动程序和尽可能多的工作人员，使其过载并使其本地任务会变慢，从而使整个作业最终可能会等待来自本地计算机的几个任务)。

结论 :

• To sum up, if I am in the same local network with the cluster, I would use the client mode and submit it from my laptop. If the cluster is far away, I would either submit locally with cluster mode, or rsync the jar to the remote cluster and submit it there, in client or cluster mode, depending on how heavy the driver program is on resources.*

AFAIK With the driver program running in the cluster, it is less vulnerable to remote disconnects crashing the driver and the entire spark job.This is especially useful for long running jobs such as stream processing type workloads.