共计 800 个字符，预计需要花费 2 分钟才能阅读完成。
在上篇讲到了，HDFS Delegation Token 问题的解决方法是 Spark-Submit 方式可以进行解决，经过了一段时间的反思和查看 Livy 和 Spark-Submit 两者日志之后，有了一点新发现，并且测试认证了，该方式是可行的，那么是怎么实现的呢？
上篇传输门：地址
上文我有提到 livy spengo 是通过代理的方式实现 Kerberos 的认证的，当使用类似于 Spark-Submit 方式 添加对应的 spark.yarn.keytab 和 spark.yarn.principal Livy 日志中会存在 –proxy-user or –principal 的错误信息，在比对了两种方式的认证日志，发现 Livy 代理方式在 realUser 是 Livy，而 Spark-Submit 方式则为空。
因而联想到了，可能 Livy 代理模式导致这两种结果的不同。在查看 Livy 配置资料之后, livy.impersonation.enabled 配置有关，尝试将该配置项设为 false。在通过上篇中的测试方法，将 dfs.namenode.delegation.key.update-interval，dfs.namenode.delegation.token.max-lifetime，dfs.namenode.delegation.token.renew-interval 进行相应的调小，帮助快速论证结果。需要注意的一点，在测试过程中，Spark 应用是需要发消息，也就是数据，不能仅仅是运行，因为如果不发消息，其实应用是没有在正常运行的，也就不会出现过期的问题了。
实验的结果是该种方式 Livy 是可以解决 HDFS Delegation Token 失效问题的。如果只是使用 Livy 方式提交，上篇中的 HDFS 的配置 hadoop.proxyuser.yarn.hosts=* 是不需要进行相应的修改的，在 HDP 环境中该配置是一个具体的 host 地址。
以上