我们有一个spark应用程序，它使用spark SQL从基于HDFS中存储的镶木文件构建的HMS表中读取数据。spark应用程序运行在一个独立的hadoop环境中。我们使用委托令牌来允许spark应用程序向Kerberized HMS/HDFS进行身份验证。我们不能也绝不能使用keytab来直接验证spark应用程序。由于委派令牌过期，在一段时间后，我们的spark应用程序将无法再进行身份验证，如果未在令牌有效的时间内完成，则会失败。我的问题是。
如果我在执行所有后续操作的源数据帧上调用.cache或.sistent，我的理解是，这将导致spark将所有数据存储在内存中。如果所有数据都在内存中，则不需要进行后续调用来读取HDFS中的叶文件，从而可以避免身份验证错误。并不是说spark应用程序有自己的本地文件系统，而是没有使用远程HDFS源作为默认fs。
这种关于.cache或.spersistent行为的假设正确吗？还是将数据重写到中间存储的唯一解决方案？
解决Kerberos问题，而不是添加解决方案。我不确定您是如何使用kerberos主体的，但我要指出的是，文档维护了一个解决此问题的解决方案：
长期运行
应用程序长期运行的应用程序可能会如果运行时间超过委派令牌的最长生存期，则会出现问题配置在它需要访问的服务中。
此功能并非在任何地方都可用。特别是，它只是在YARN和Kubernetes上实现(包括客户端和集群模式(，以及使用客户端模式时在Mesos上。
Spark支持自动为这些应用程序。有两种方法可以启用此功能。
使用Keytab
通过向Spark提供主体和键选项卡(例如。使用带有--principal和--keytab参数的spark-submit(应用程序将维护一个有效的Kerberos登录，该登录可用于无限期地检索委派令牌。
请注意，在集群模式下使用键选项卡时，它将被复制到运行Spark驱动器的机器。就YARN而言意味着使用HDFS作为keytab的暂存区域，因此建议对YARN和HDFS进行加密保护最小的
我还指出，缓存将减少对HDFS的访问，但如果内存中没有足够的空间，可能仍然需要从HDFS读取。如果您因为[原因]而没有解决Kerberos问题。您可能希望使用检查点。它们比缓存慢，但专门用于帮助[有时会失败的长时间运行的进程]克服昂贵的重新计算的障碍，但它们确实需要写入磁盘。这将消除重新访问原始HDFS集群的任何需要。通常，它们在流式处理中用于删除数据沿袭，但在昂贵的长期运行的spark应用程序中也有其位置。(你还需要管理他们的清理工作。(
如何使用检查点文件进行恢复。