一、场景
原来的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本地客户端两种模式都支持,如果两个都开启,在任务左上角可以选择需要的客户端版本
如需将原来用执行机器提交的任务 转为本地客户端进行提交,可在任务左上角进行切换,提交并发布后即可生效