spark采用yarn模式部署时采用client和cluster的区别

一、提交方式

spark-submit脚本指定–master参数，实际决定了两个值：

设为--master yarn --deploy-mode client时：yarn-client模式

设为--master yarn --deploy-mode cluster时：yarn-cluster模式

二、运行原理

1、yarn/yarn-client模式：

2、yarn-cluster模式：

三、主要区别

1、yarn(yarn-client)：

带宽角度

这种模式由于driver在你的调度机器上，如果调度机器不在yarn集群机器上部署，driver与executor通信会导致大量的带宽流量产生，spark streaming实时程序或者程序比较多的情况下，网络带宽会打满撑爆，带宽打满的情况下，连锁反应的后果是集群上所有任务都会拖慢，线上事故妥妥的！如果调度机器跟yarn同一集群，推荐这种方式！也方便在调度系统上查看driver的日志。

权限控制角度

在上图中可以看到System Properties的user.name是lijf，上面的代码最后会有写表的操作，写hdfs的用户也就是lijf，因为最后实际执行spark程序executor端的用户就是lijf，控制hdfs读写权限只需要控制lijf用户的读写权限就行了，这里使用的是ranger做权限控制，非常方便。

2、yarn-cluster

带宽角度

这种方式提交spark任务后，启动driver的节点是yarn上的随机节点，由AppMaster启动，无需关注调度机器是否与yarn集群部署在一块。

权限控制角度

这种方式致命的缺点，可以看到System Properties的user.name是yarn，这是由于linux系统本地没有创建提交任务的用户，ugi无法识别用户，最后由yarn统一提交，意思是无论哪个用户提交spark任务，只要本地linux没有创建这个用户，最后executor端读写hdfs都是以yarn的身份，所以集群的权限管理根本没法控制！权限控制不好，删库跑路，完了别告诉我你是干大数据的，线上事故妥妥的！这里控制的是hdfs文件的权限，不要与hive表权限混为一谈，hive表的权限是在drive端去操作catlog控制ddl操作。

四、总结

1、调度与yarn集群共同机器部署，spark的–master参数置为yarn，无需关心linux本地的用户创建问题
2、调度机器与yarn分离部署，调度有的用户需要在yarn集群所有linux系统上创建