进一步排查问题，需要 在理解作业的底层执行机制的基础上， 大胆猜想，小心求证。

HIVE 作业的执行机制如下：

终端业务用户比如 xyz 提交给 HIVESERVER2 的 SQL作业，经过 HIVESERVER2 的解析编译和优化后，一般会生成 MR/TEZ/SPARK 任务(之所以说一般，是因为有的 SQL 是直接在HIVESERVER2中执行的，不会生成分布式的 MR/TEZ/SPARK 任务)，这些 MR/TEZ/SPARK 任务最终访问底层的基础设施 HDFS 和 YARN 时，一样要经过 kerberos 安全认证;

当启用了 HIVE 的代理机制时(hive.server.enable.doAs=true)，业务终端用户如 xyz 提交的 HIVE SQL 作业底层的 MR/TEZ/SPARK 任务访问 HDFS/YARN 时，HDFS/YARN 验证的是业务终端用户 xyz 的身份 (后续 HDFS/YARN 的权限校验，校验的也是 xyz 用户的权限);

当没有启用 HIVE 的代理机制时(hive.server.enable.doAs=false)，业务终端用户提交的 HIVE SQL 作业底层的 MR/TEZ/SPARK 任务访问 HDFS/YARN 时，需要验证的是 hiveserver2 服务对应的用户，即 hive 的身份 (后续 HDFS/YARN 的权限校验，校验的也是 hive 用户的权限);

至此问题就比较清晰了：

在上述集群环境中，cdh 集群管理员开启了 kerberos 安全认证，即集群中 hdfs/yarn/hive/spark/kafka 等服务的使用，都需要经过kerberso 安全认证;

当 hiveserver2 执行业务用户提交的 sql 作业时，由于业务用户配置了使用 spark 执行引擎，所以 hiveserver2 需要首先为业务用户用户创建 spark 集群;

在上述集群环境中，cdh 集群管理员开启了 hive.server.enable.doAs=true，所以 hiveserver2 创建 spark集群时，spark 集群的 driver 向 yarn 申请资源时，yarn 校验的是 xyz 的身份;

由于 hiveserver2 没有提供一致机制将业务用户 xyz的 principal 和对应的 keytab 透传到 yarn, 所以 yarn 对 xyz 的用户认证失败，没有相应其资源请求，从而 spark driver 因获取不到 yarn资源无法成功启动，自然也就不会回连到spark driver的客户端即hiveserver2，所以才有相关报错："Failed to create spark client for spark session xxx“，“Error while waiting for Remote Spark Driver to connect back to HiveServer2”等。

事实上，细心的小伙伴，能在 hiveserver2 的日志中，查看到 securityManager 验证用户身份的相关日志：