我遇到了一个奇怪的问题，即在一个数据集上调用unpersist()会影响同一代码块中另一个数据集的计数。不幸的是，这发生在一个包含许多数据集的复杂的长期工作期间，所以我不能总结这里的全部内容。我知道这会带来一个难题，但是让我试着勾勒出来。我正在寻找的是一些确认，这种行为是出乎意料的，以及任何有关它为何可能发生或我们如何避免它的想法。
编辑：报告的此问题发生在Spark 2.1.1上，但不会发生在2.1.0上。问题是100％可重复的，但只有在我的项目中有1000行的代码和数据，我正努力将其提炼为一个简洁的例子但尚未能够，我将发布任何更新或重新提交我的问题，如果我找到了什么。完全相同的代码和数据在2.1.0但不是2.1.1中工作的事实让我相信它是由于Spark中的某些东西。
val claims:Dataset = // read claims from file
val accounts:Dataset = // read accounts from file
val providers:Dataset = // read providers from file
val payers:Dataset = // read payers from file
val claimsWithAccount:Dataset = // join claims and accounts
val claimsWithProvider:Dataset = // join claims and providers
val claimsWithPayer:Dataset = // join claimsWithProvider and payers
claimsWithPayer.persist(StorageLevel.MEMORY_AND_DISK)
log.info("claimsWithPayer = " + claimsWithPayer.count()) // 46
// This is considered unnecessary intermediate data and can leave the cache
claimsWithAccount.unpersist()
log.info("claimsWithPayer = " + claimsWithPayer.count()) // 41
基本上，在unpersist()报告的一系列联接中的一个中间数据集上调用Dataset.count()会影响后一个数据集中的行数。
我的理解是unpersist()应该从缓存中删除数据但是它不应该影响其他数据集的计数或内容？这尤其令人惊讶，因为在我解除其他数据之前，我明确地坚持claimsWithPayer。
答案 0 :(得分：1)
我相信您遇到的行为与the change有关，因为“UNCACHE TABLE应该取消缓存引用此表的所有缓存计划”。
我想你可以在SPARK-21478 Unpersist a DF also unpersists related DFs找到更多信息，小李说：
这是设计的。我们不想使用无效的缓存数据。