我们有一个spark应用程序，它使用spark SQL从HMS表中读取数据，HMS表基于存储在HDFS中的parquet文件构建。spark应用程序运行在一个单独的Hadoop环境中。我们使用委托令牌允许spark应用程序向Kerberos化的HMS/HDFS进行身份验证。我们不能也不能使用keytab直接对spark应用程序进行身份验证。由于委托令牌过期，在一段时间后，我们的spark应用程序将不再能够进行身份验证，并且如果它没有在令牌有效的时间范围内完成，它将失败。
如果我在执行所有后续操作的源 Dataframe 上调用.cache或.persist，我的理解是，这将导致spark将所有数据存储在内存中。如果所有数据都在内存中，它应该不需要进行后续调用来读取HDFS中的leaf文件，并且可以避免身份验证错误。并不是说spark应用程序有自己的本地文件系统，它没有使用远程HDFS源作为其默认文件系统。
关于.cache或.persist行为的假设是否正确，或者是否将数据重写到中间存储的唯一解决方案？
1条答案
按热度按时间kd3sttzy1#
解决Kerberos问题，而不是添加变通办法。我不确定您是如何使用Kerberos主体的，但我会指出文档维护了此问题的解决方案：
长期运行
应用程序如果长时间运行的应用程序的运行时间超过其需要访问的服务中配置的最大委托令牌生存期，则它们可能会遇到问题。
此功能并非在所有地方都可用，尤其是仅在YARN和Kubernetes（客户端和集群模式）以及Mesos（客户端模式）上实现。
Spark支持为这些应用程序自动创建新令牌。有两种方法可以启用此功能。
使用Keytab键
通过为Spark提供主体和keytab（例如，使用带有--principal和--keytab参数的spark-submit），应用程序将维护一个有效的Kerberos登录，该登录可用于无限期地检索委托令牌。
请注意，在集群模式下使用keytab时，它将被复制到运行Spark驱动程序的机器上。对于YARN，这意味着使用HDFS作为keytab的暂存区，因此强烈建议至少对YARN和HDFS进行加密保护。
我还想指出，缓存将减少对HDFS的访问，但如果内存空间不足，可能仍然需要从HDFS读取。如果您因为[原因]而没有解决Kerberos问题，您可能希望使用检查点。它们比缓存慢，但专门用于帮助[有时会失败的长时间运行的进程]克服昂贵的重新计算的障碍。但它们确实需要写入磁盘。这将消除任何重新访问原始HDFS集群的需要。通常，它们在Streaming中用于删除数据沿袭，但它们也在昂贵的长时间运行的spark应用程序中占有一席之地。（您还需要管理它们的清理。）
How to recover with a checkpoint file.