Dataset.unpersist() неожиданно влияет на количество других RDD

Я столкнулся со странной проблемой, когда вызов 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 перед тем, как отменить сохранение других данных.


person Uncle Long Hair    schedule 24.09.2017    source источник
comment
Примерно вот так не годится. Пожалуйста, попробуйте работать с минимально воспроизводимым примером - это либо серьезная ошибка корректностиследует сообщить с достаточным количеством информации, чтобы определить источник проблемы ) или это ваша ошибка (например, предположение о детерминированном поведении, когда Spark не дает никаких гарантий), и работа над минимальным примером должна дать некоторые подсказки. Также убедитесь, что вы используете последнюю дополнительную версию.   -  person zero323    schedule 24.09.2017
comment
Как и многие другие проблемы Spark, это происходит только с определенными данными и обстоятельствами. Я работал много часов, чтобы привести его к краткому примеру, но пока не смог. Мой вопрос касается семантики кеша Spark, сохранения и удаления, аналогичного этому вопросу stackoverflow. com/questions/29903675/   -  person Uncle Long Hair    schedule 24.09.2017
comment
Итак, как я уже сказал: если каждый предок claimsWithPayer детерминирован (достаточно), то постоянство не должно иметь никакого эффекта, и это ошибка. В противном случае это, вероятно, непонимание семантики. Вам решать, так это или нет. Если вы можете уменьшить проблему до чего-то управляемого, я бы порекомендовал отправить это в список разработчиков. Если что-то изменилось между 2.1.0 и 2.1.1, более вероятно, что кто-то ответственный сможет распознать проблему.   -  person zero323    schedule 24.09.2017


Ответы (1)


Я считаю, что поведение, с которым вы сталкиваетесь, связано с изменением для "UNCACHE TABLE следует удалить из кэша все кэшированные планы, которые ссылаются на эту таблицу».

Я думаю, вы можете найти больше информации в SPARK-21478 Unpersist a DF также unpersist Related DF где Сяо Ли сказал:

Это по дизайну. Мы не хотим использовать недопустимые кэшированные данные.

person Jacek Laskowski    schedule 24.09.2017
comment
Спасибо, это на самом деле похоже на причину, хотя в этих ошибках они конкретно не упоминают о влиянии на количество RDD. Я продолжу работать над дистилляцией моего примера. Кстати, я думаю, что это довольно радикальное изменение в выпуске x.x.x. В примечаниях к выпуску говорится, что он содержит исправления стабильности, но это изменение дестабилизирует. - person Uncle Long Hair; 25.09.2017