Spark кеш и неперспективный порядок - PullRequest
0 голосов
/ 18 мая 2018

Я нашел похожую тему: Понимание кэширования Spark

но это все еще не точный мой вопрос.Давайте рассмотрим следующие фрагменты кода: OptionA:

rdd1 = sc.textFile()
rdd1.cache()
rdd2 = rdd1.map().partionBy()
rdd3 = rdd1.reduceBy().map()
rdd2.cache()
rdd1.unpersist()
data = rdd2.collect()

OptionB:

rdd1 = sc.textFile()
rdd1.cache()
rdd2 = rdd1.map().partionBy()
rdd3 = rdd1.reduceBy().map()
rdd2.cache()
data = rdd2.collect()
rdd1.unpersist()

Какой вариант выбрать для предотвращения повторного вычисленияrdd1?На первый взгляд, optionA выглядит нормально, но, учитывая, что операции в spark являются ленивыми, я думаю, что выполнение unpersist перед выполнением действия на rdd2 может привести к необходимости повторного вычисления rdd1 еще раз.С другой стороны, вызов unpersist, как в опции B, может привести к отсутствию свободного места для кэширования rdd2.Пожалуйста, помогите мне выбрать, какой вариант я должен использовать.

1 Ответ

0 голосов
/ 18 мая 2018

Обе опции строго говоря неверны.

Первый, как вы подозреваете, удаляет флаг кэширования до фактического сбора данных.

Второй фактически запускает кэш, но так какВы никогда не оцениваете, что rdd3 кэшированный rdd1 просто сохраняется, и сразу после этого отбрасывается.Удаление rdd1.cache() должно фактически улучшить производительность.Кроме того, rdd2.cache() кажется устаревшим, поскольку результат никогда не используется повторно.

Если textFile загружает данные из дорогого хранилища, вы можете структурировать свой код следующим образом:

rdd1 = sc.textFile(...)
rdd1.cache()

rdd2 = rdd1.map(...).partionBy(...)
rdd3 = rdd1.reduceByKey(...).map(...)

rdd2.someAction()
rdd3.someAction()

rdd1.unpersist()

гдеsomeAction - это действие, которое вы хотите выполнить с конкретным RDD.

...