Вам нужно кэшировать фрейм данных, если вы хотите посчитать и позже обработать его

Question

У меня есть пример дела:

val df = ... // read from HDFS / file / ...
println(df.count)
val newDf = df.select // Other transformations... Keep processing the original df.

У меня вопрос: нужно ли кэшировать исходный фрейм данных, если я считаю в середине моего процесса? Я имею в виду, я считаю df, а затем продолжаю преобразовывать и обрабатывать его.
.count означает, что df будет вычислен дважды?

Answer 1

Не зная больше о вашем сценарии использования и ресурсах, трудно дать вам однозначный ответ. Однако это, скорее всего, отрицательно, несмотря на то, что Spark будет обращаться к источнику дважды.

В целом, необходимо учитывать несколько факторов:

• Сколько данных будет загружено при первом проходе. Благодаря эффективному формату ввода на диске Spark (например, Parquet) Spark вообще не нужно полностью загружать набор данных. Это также относится ко многим другим форматам ввода, включая, но не ограничиваясь, читатель JDBC.
• Стоимость кэширования данных с помощью Dataset API довольно высока (поэтому по умолчанию режим хранения равен MEMORY_AND_DISK) и может легко превысить стоимость загрузки данных.
• Влияние на последующую обработку. В общем случае кеширование будет мешать сокращению разделов, уменьшению предикатов и проекциям (см. Есть ли какие-либо проблемы с производительностью, вызывающие энергичную оценку с использованием счетчика в spark? ).

Итак ...

Означает ли .count, что df будет вычислен дважды?

В некоторой степени в зависимости от формата ввода. Простые текстовые форматы (такие как JSON или CSV) потребуют более повторной работы, чем двоичные источники.

нужно ли кэшировать исходный фрейм данных

Обычно нет, если только вы не знаете, что стоимость извлечения данных из хранилища оправдывает недостатки, перечисленные выше.

Принятие окончательного решения требует хорошего понимания вашего конвейера (прежде всего того, как данные будут обрабатываться в нисходящем направлении и как кеширование влияет на это) и показателей, которые вы хотите оптимизировать (задержка, общее время выполнения, денежные затраты на запуск необходимых ресурсов).

Вы должны также рассмотреть альтернативы count, такие как обработка InputMetrics или использование Accumulators.