Spark yarn 集群 vs 客户端——如何选择使用哪一个？
Spark yarn cluster vs client - how to choose which one to use?
spark docs 有一段话描述了yarn client 和yarn cluster 的区别：
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.
我假设有两个选择是有原因的。如果是这样，您如何选择使用哪一个？
请用事实证明你的回答是正确的，这样这个问题和答案就符合 Whosebug 的要求。
在 Whosebug 上有一些类似的问题，但是这些问题关注的是两种方法之间的区别，而不是关注一种方法何时比另一种方法更合适。
一种常见的部署策略是从物理上 co-located 与您的工作机器（例如，独立 EC2 集群中的主节点）的网关机器提交您的应用程序。在此设置中，客户端模式是合适的。在客户端模式下，driver 直接在充当集群客户端的 spark-submit 进程中启动。应用程序的输入和输出连接到控制台。因此，这种模式特别适合涉及REPL的应用程序（例如Spark shell）。
或者，如果您的应用程序是从远离工作机器的机器提交的（例如，在本地笔记本电脑上），通常使用集群模式来最小化 drivers 和执行程序之间的网络延迟.请注意，Mesos 集群目前不支持集群模式。目前只有 YARN 支持 Python 应用程序的集群模式。”-- Submitting Applications
我从这里了解到的是，这两种策略都是使用集群来分发任务；不同之处在于 "driver program" 运行s：在本地使用 spark-submit，或者也在集群中。
何时应该使用它们中的任何一个在上面的引用中有详细说明，但我还做了另一件事：对于大罐子，我使用 rsync 将它们复制到集群（甚至主节点）用100倍的网速，然后从集群提交。对于大罐子，这可能比 "cluster mode" 更好。请注意，客户端模式可能不会将 jar 传输到主服务器。在这一点上，2 之间的差异是最小的。当 driver 程序大部分时间处于空闲状态时，客户端模式可能更好，以充分利用本地计算机上的核心并可能避免将 jar 传输到主机（即使在环回接口上，一个大 jar 也需要相当长的时间几秒钟）。使用客户端模式，您可以在任何集群节点上传输 (rsync) jar。
另一方面，如果 driver 非常密集，在 cpu 或 I/O 中，集群模式可能更合适，以更好地平衡集群（在客户端模式下，本地机器会 运行 同时 driver 和尽可能多的工人，使其过载并使本地任务变慢，使得整个工作可能最终等待来自本地计算机的几个任务）。
结论：
- 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.
YARN 上的 Spark 作业 运行
当在 YARN 上 运行ning Spark 时，每个 Spark 执行器 运行s 作为一个 YARN 容器。 MapReduce 调度容器并为每个任务启动 JVM，而 Spark 在同一个容器中托管多个任务。这种方法使任务启动时间缩短了几个数量级。
Spark 在 YARN 上支持 运行ning 的两种模式，“yarn-cluster”模式和“yarn-client” “ 模式。从广义上讲，yarn-cluster 模式适用于生产作业，而 yarn-client 模式适用于交互式和调试用途，您希望立即看到应用程序的输出。
了解差异需要了解 YARN 的 Application Master 概念。在 YARN 中，每个应用程序实例都有一个 Application Master 进程，这是为该应用程序启动的第一个容器。应用程序负责从 ResourceManager 请求资源，并在分配资源时告诉 NodeManager 代表它启动容器。 Application Master 消除了对活动客户端的需求——启动应用程序的进程可以消失，协调从集群上由 YARN 运行ning 管理的进程继续。
在 yarn-cluster 模式下，Application Master 中的驱动程序运行s。这意味着同一个进程负责驱动应用程序和从 YARN 请求资源，并且这个进程 运行s 在 YARN 容器内。启动应用程序的客户端不需要在其整个生命周期中都存在。
纱线集群模式
yarn-cluster 模式不 非常适合交互式地使用 Spark，但 yarn-client 模式 很适合。需要用户输入的 Spark 应用程序，如 spark-shell 和 PySpark，需要 Spark 驱动程序在启动 Spark 应用程序的客户端进程中 运行。在 yarn-client 模式下，Application Master 仅用于从 YARN 请求执行器容器。客户端与这些容器通信以在它们启动后安排工作：
纱线客户端模式
此 table 提供了这些模式之间差异的简明列表：
参考：https://blog.cloudera.com/blog/2014/05/apache-spark-resource-management-and-yarn-app-models/ - Apache Spark 资源管理和 YARN 应用程序模型（web.archive.com 镜像）
在 yarn-cluster 模式下，驱动程序将 运行 在 application master 运行ning 的节点上，而在 yarn-client 模式下，驱动程序将 运行 在集中式网关节点上提交作业的节点。
Ram 和 Chavati/Wai Lee 的两个回答都很有用和有帮助，但在这里我只想补充几点：
关于驱动程序与执行程序的接近度已经写了很多，这是一个重要因素。其他因素是：
- 在作业执行完成之前，驱动程序进程是否会一直存在？
- 如何处理返回的数据？
#1。在 spark client 模式下，驱动程序进程必须在 spark 作业执行期间一直处于 up 和 运行ning 状态。因此，如果您的工作确实很长，需要花费很多时间才能 运行，您需要确保驱动程序进程仍在运行并且 运行ning，并且驱动程序会话不会自动注销。
另一方面，在集群模式下向 运行 提交作业后，进程可能会消失。集群模式将保持运行ning。因此，这通常是生产作业 运行 的方式：作业可以由计时器或外部事件触发，然后作业将 运行 完成，而无需担心进程提交的生命周期火花作业。
#2。在客户端模式下，您可以调用 sc.collect() 从所有执行程序收集所有数据，然后 write/save 将返回的数据保存到本地磁盘上的本地 Linux 文件中。现在这可能不适用于集群模式，因为 'driver' 通常 运行 在不同的远程主机中。因此，写入的数据需要持久化到一个普通的挂载卷（如 GPFS、NFS）或分布式文件系统（如 HDFS）中。如果作业在 Hadoop/YARN 下 运行ning，集群模式更常见的方法是简单地要求每个执行程序将数据持久化到 HDFS，而不是 运行 collect()。当有大量执行程序返回大量数据时，Collect() 实际上存在可伸缩性问题 - 它可能会使驱动程序进程不堪重负。
spark docs 有一段话描述了yarn client 和yarn cluster 的区别：
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.
我假设有两个选择是有原因的。如果是这样，您如何选择使用哪一个？
请用事实证明你的回答是正确的，这样这个问题和答案就符合 Whosebug 的要求。
在 Whosebug 上有一些类似的问题，但是这些问题关注的是两种方法之间的区别，而不是关注一种方法何时比另一种方法更合适。
一种常见的部署策略是从物理上 co-located 与您的工作机器（例如，独立 EC2 集群中的主节点）的网关机器提交您的应用程序。在此设置中，客户端模式是合适的。在客户端模式下，driver 直接在充当集群客户端的 spark-submit 进程中启动。应用程序的输入和输出连接到控制台。因此，这种模式特别适合涉及REPL的应用程序（例如Spark shell）。
或者，如果您的应用程序是从远离工作机器的机器提交的（例如，在本地笔记本电脑上），通常使用集群模式来最小化 drivers 和执行程序之间的网络延迟.请注意，Mesos 集群目前不支持集群模式。目前只有 YARN 支持 Python 应用程序的集群模式。”-- Submitting Applications
我从这里了解到的是，这两种策略都是使用集群来分发任务；不同之处在于 "driver program" 运行s：在本地使用 spark-submit，或者也在集群中。
何时应该使用它们中的任何一个在上面的引用中有详细说明，但我还做了另一件事：对于大罐子，我使用 rsync 将它们复制到集群（甚至主节点）用100倍的网速，然后从集群提交。对于大罐子，这可能比 "cluster mode" 更好。请注意，客户端模式可能不会将 jar 传输到主服务器。在这一点上，2 之间的差异是最小的。当 driver 程序大部分时间处于空闲状态时，客户端模式可能更好，以充分利用本地计算机上的核心并可能避免将 jar 传输到主机（即使在环回接口上，一个大 jar 也需要相当长的时间几秒钟）。使用客户端模式，您可以在任何集群节点上传输 (rsync) jar。
另一方面，如果 driver 非常密集，在 cpu 或 I/O 中，集群模式可能更合适，以更好地平衡集群（在客户端模式下，本地机器会 运行 同时 driver 和尽可能多的工人，使其过载并使本地任务变慢，使得整个工作可能最终等待来自本地计算机的几个任务）。
结论：
- 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
rsyncthe 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.
YARN 上的 Spark 作业 运行
当在 YARN 上 运行ning Spark 时，每个 Spark 执行器 运行s 作为一个 YARN 容器。 MapReduce 调度容器并为每个任务启动 JVM，而 Spark 在同一个容器中托管多个任务。这种方法使任务启动时间缩短了几个数量级。
Spark 在 YARN 上支持 运行ning 的两种模式，“yarn-cluster”模式和“yarn-client” “ 模式。从广义上讲，yarn-cluster 模式适用于生产作业，而 yarn-client 模式适用于交互式和调试用途，您希望立即看到应用程序的输出。
了解差异需要了解 YARN 的 Application Master 概念。在 YARN 中，每个应用程序实例都有一个 Application Master 进程，这是为该应用程序启动的第一个容器。应用程序负责从 ResourceManager 请求资源，并在分配资源时告诉 NodeManager 代表它启动容器。 Application Master 消除了对活动客户端的需求——启动应用程序的进程可以消失，协调从集群上由 YARN 运行ning 管理的进程继续。
在 yarn-cluster 模式下，Application Master 中的驱动程序运行s。这意味着同一个进程负责驱动应用程序和从 YARN 请求资源，并且这个进程 运行s 在 YARN 容器内。启动应用程序的客户端不需要在其整个生命周期中都存在。
纱线集群模式
yarn-cluster 模式不 非常适合交互式地使用 Spark，但 yarn-client 模式 很适合。需要用户输入的 Spark 应用程序，如 spark-shell 和 PySpark，需要 Spark 驱动程序在启动 Spark 应用程序的客户端进程中 运行。在 yarn-client 模式下，Application Master 仅用于从 YARN 请求执行器容器。客户端与这些容器通信以在它们启动后安排工作：
纱线客户端模式
此 table 提供了这些模式之间差异的简明列表：
参考：https://blog.cloudera.com/blog/2014/05/apache-spark-resource-management-and-yarn-app-models/ - Apache Spark 资源管理和 YARN 应用程序模型（web.archive.com 镜像）
在 yarn-cluster 模式下，驱动程序将 运行 在 application master 运行ning 的节点上，而在 yarn-client 模式下，驱动程序将 运行 在集中式网关节点上提交作业的节点。
Ram 和 Chavati/Wai Lee 的两个回答都很有用和有帮助，但在这里我只想补充几点：
关于驱动程序与执行程序的接近度已经写了很多，这是一个重要因素。其他因素是：
- 在作业执行完成之前，驱动程序进程是否会一直存在？
- 如何处理返回的数据？
#1。在 spark client 模式下，驱动程序进程必须在 spark 作业执行期间一直处于 up 和 运行ning 状态。因此，如果您的工作确实很长，需要花费很多时间才能 运行，您需要确保驱动程序进程仍在运行并且 运行ning，并且驱动程序会话不会自动注销。
另一方面，在集群模式下向 运行 提交作业后，进程可能会消失。集群模式将保持运行ning。因此，这通常是生产作业 运行 的方式：作业可以由计时器或外部事件触发，然后作业将 运行 完成，而无需担心进程提交的生命周期火花作业。
#2。在客户端模式下，您可以调用 sc.collect() 从所有执行程序收集所有数据，然后 write/save 将返回的数据保存到本地磁盘上的本地 Linux 文件中。现在这可能不适用于集群模式，因为 'driver' 通常 运行 在不同的远程主机中。因此，写入的数据需要持久化到一个普通的挂载卷（如 GPFS、NFS）或分布式文件系统（如 HDFS）中。如果作业在 Hadoop/YARN 下 运行ning，集群模式更常见的方法是简单地要求每个执行程序将数据持久化到 HDFS，而不是 运行 collect()。当有大量执行程序返回大量数据时，Collect() 实际上存在可伸缩性问题 - 它可能会使驱动程序进程不堪重负。