Я столкнулся со странной проблемой, когда вызов 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
перед тем, как отменить сохранение других данных.
claimsWithPayer
детерминирован (достаточно), то постоянство не должно иметь никакого эффекта, и это ошибка. В противном случае это, вероятно, непонимание семантики. Вам решать, так это или нет. Если вы можете уменьшить проблему до чего-то управляемого, я бы порекомендовал отправить это в список разработчиков. Если что-то изменилось между 2.1.0 и 2.1.1, более вероятно, что кто-то ответственный сможет распознать проблему. - person zero323   schedule 24.09.2017