很多 Spark 使用者对两件事一直模糊一是client / cluster到底差在哪二是 STSSpark Thrift Server算不算一种提交模式。这篇文章只讲一件事一次提交Driver 是怎么被启动的STS 又在这个模型里扮演什么角色。一、Spark 提交模式本质上只回答一个问题Spark 里真正干活的有两类 JVMDriver大脑SQL 解析、Stage 拆分、Task 调度这里是最多二开和改造的地方Executor劳工读数据、计算、写数据所谓提交模式不决定“用不用 Spark”只决定Driver JVM 在哪台机器上出生。Driver 是一个进程二、client 模式spark-submit 自己就是 Driver1️⃣ 从敲命令开始spark-submit\--masteryarn\--deploy-mode client\com.xxx.MySparkApp这条命令做了什么启动一个 JVM进程名是SparkSubmit在这个 JVM 里通过反射调用你的MySparkApp.main()main()里new SparkSession()→new SparkContext()到这一步Driver 已经存在了而且就是 spark-submit 这个进程。没有任何远程启动 Driver 的动作。2️⃣ Driver 向 YARN 要资源SparkContext初始化时向 ResourceManager 申请第一个 Container这个 Container 里跑的是ApplicationMasterAM在 client 模式下AM 只干一件事帮 Driver 申请 Executor。3️⃣ Executor 反向连 DriverExecutor 启动后通过 Driver 的 RPC 地址连回来Executor ──RPC──▶ Driverspark-submit 所在机器Driver 负责Driver就像大脑而且当计算任务比较多时任务就会比较重切 Stage下发 Task收集结果AM 全程不参与计算。client 模式一句话总结Driver 在提交机上提交机不关机App 就活着。三、cluster 模式Driver 被塞进 YARN 里1️⃣ 提交机只做“投递”spark-submit\--masteryarn\--deploy-mode cluster\com.xxx.MySparkApp这次spark-submit 进程只把 jar 配置上传到 HDFS向 RM 说“起个 App”然后自己可以立刻退出2️⃣ 第一个 Container 里AM DriverYARN 分配第一个 Container启动的是org.apache.spark.deploy.yarn.YarnClusterApplication在这个 JVM 里创建 SparkContext同时扮演 ApplicationMaster自己调度自己也就是说Driver 的父进程是 YARN不是 spark-submit。3️⃣ Executor 仍然只认 DriverExecutor 启动后连接的是AM Container 里的 Driver RPC 端口。架构变成spark-submit投递员 ↓ YARN ContainerDriver AM ↓ Executorcluster 模式一句话总结Driver 在集群里提交机可以随时走人。四、两种模式的本质差异只看这一句模式Driver 在哪提交机作用client提交机启动 DriverclusterYARN Container只负责提交其他所有差异——日志、稳定性、端口、是否适合生产——都是这个事实的副作用。五、Spark Thrift Server 是什么1️⃣ STS 不是新东西启动 STSstart-thriftserver.sh等价于spark-submit\org.apache.spark.sql.hive.thriftserver.HiveThriftServer2STS 本身就是一个 Spark Application。2️⃣ 它为什么能接受 SQLHiveThriftServer2的main()做了三件事创建SparkSession启动一个 Thrift RPC 服务默认 10000 端口永远不退出BI 工具通过 JDBC 连的是jdbc:hive2://sts-host:10000这个端口后面就是 Driver 自己。 Driver被绑定到了这个Thrift RPC 服务中3️⃣ 每一条 SQL 是什么BI 发 SQL → Driver 收到 → 编译成 SparkPlan →切 Stage → 调度 Task没有新的 Application没有新的 spark-submit。只是 Driver 里多了一个 Job。4️⃣ STS 用的是哪种提交模式生产里几乎都是start-thriftserver.sh--masteryarn--deploy-mode client也就是Driver 在 STS 机器上对外暴露 JDBCExecutor 在 YARN / K8s 上所以 STS 不是第三种提交模式而是一个长期运行的 client-mode Spark Application对外伪装成数据库。六、为什么这个架构容易出问题Driver的职责太重了因为 client 模式的所有特征被“常驻”放大了Driver 单点一个 JVM 服务所有查询结果集先回 Driver再给 JDBC 客户端一个慢 SQL 占满 Driver 内存 → 所有查询一起卡权限、资源、隔离都只能在这个 Driver 内解决STS 的“像数据库”其实是错觉。它更像一个永远不退出的 spark-submit坐在那里等 SQL。七、一句话串起来clientDriver 在提交机跑完就死clusterDriver 在集群提交机可以走STSDriver 在提交机但永远不 exit专门接 JDBC八、如果你只记住一张图JDBC / spark-submit | | RPC v Driver | 调度指令 | Executorclient / STSDriver 在图左边clusterDriver 在图中间补充视角面试/架构用Spark 只有两种提交模式。STS 是“client 模式的常驻服务化”Kyuubi 则是把 STS 拆成“无状态网关 按需 client-mode Engine”。理解到这一步你再看 STS 为什么被换掉就不是“新工具更好”而是“架构假设变了”。