在上篇講到了，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 地址。
以上
