一、场景
原来的Spark Jar任务和PySpark任务提交，需要借助外部执行机器作为“跳板机”，这会产生以下问题：
- 单点故障风险，缺乏高可用性：
- 跳板机作为单一的连接点，一旦发生故障（如硬件故障、网络中断等），将导致整个Spark任务提交流程中断，无法实现高可用性。
- 资源分配集中，无法实现均衡负载：
- 由于所有任务必须通过跳板机提交，资源分配过于集中，容易造成瓶颈。特别是在高负载情况下，跳板机可能成为任务提交和执行的性能瓶颈。
- 缺乏Spark Job的全生命周期管理：
- 无法管理Spark Job，在Dataphin终止Spark_jar任务后，只能结束Dataphin调度系统内的任务，而无法终止跳板机的进程，也无法终止 yarn 上的application
二、解决方案及功能
Dataphin支持通过Spark本地客户端的方式提交Spark Jar和PySpark任务
- 消除单点故障：
- 容器化部署spark客户端，当容器检测到故障时，自动触发恢复过程，启动新的容器，继续提供服务。
- 提升资源利用效率：
- 使用Docker容器实现任务的动态分配和负载均衡，充分利用集群资源，避免资源浪费，也可以跟随系统自动扩容
- 增强对Spark Job监控和管理，管理全生命周期：
- 用户可以方便地进行任务的提交、终止和监控，提升工作效率。
目前Spark执行机器和Spark本地客户端两种模式都支持，如果两个都开启，在任务左上角可以选择需要的客户端版本
如需将原来用执行机器提交的任务 转为本地客户端进行提交，可在任务左上角进行切换，提交并发布后即可生效
