Spark count dataframe для оценки выходных разделов, а затем записи, эффективно без кэширования?

Question

Поскольку моя программа spark работает с большим количеством данных, я думаю, что происходит сбой, потому что я выбираю количество выходных разделов по умолчанию для агрегации, а именно 200. Я научился управлять этим, но в идеале это выглядит так, Я бы установил количество выходных разделов в зависимости от объема данных, которые я пишу. Здесь кроется загадка - мне нужно сначала вызвать count() на информационном кадре, а затем write. Это означает, что я могу повторно подготовить его из S3 дважды. Я мог бы cache, а затем count, но я видел искры, когда я кешировал эти данные, кеширование, похоже, использует больше всего ресурсов, тогда как, если я просто напишу это - оно может сделать что-то более оптимальное.

Итак, мои вопросы: если вы считаете, что это достойный подход - сначала делать подсчет (подсчет - это прокси по отношению к размеру на диске), или вам нужно просто жестко закодировать некоторые числа, изменить их, когда вам нужно? И если я собираюсь сначала посчитать, это какой-то умный способ оптимизировать вещи так, чтобы подсчет и запись делились? Кроме кэширования всего кадра данных?

Answer 1

Да, метод подсчета на самом деле правильный путь. В идеале вы хотите, чтобы ваши rdd-разделы имели какой-то значительный размер, например 50 МБ, перед записью. В противном случае вы столкнетесь с «маленькой проблемой с файлом»

Теперь, если у вас большие объемы данных, кеширование в памяти может быть затруднено. Вы можете попробовать MEMORY_AND_DISK, но тогда данные попадут на диск и приведут к замедлению.

Я сталкивался с этим затруднением несколько раз, и каждый раз я выбирал «магическое число» для числа разделов. Число параметризовано, поэтому, когда мне нужно изменить, мне не нужно менять код, достаточно передать другой параметр.

Если вы знаете, что ваш размер данных обычно находится в определенном диапазоне, вы можете установить номер раздела жестко закодированным. Это не идеально, но выполняет свою работу.

Также вы можете качать такие показатели, как размер данных в s3, и если это нарушает какой-то порог, поднять тревогу, тогда кто-то может изменить номер раздела вручную.

Как правило, если вы держите номер раздела умеренно высоким, например 5000, для примерно 500 ГБ данных, которые работают для большого диапазона, то есть от 300 ГБ до 1,2 ТБ данных. Это означает, что, возможно, вам не нужно менять номер раздела слишком часто, если у вас умеренный приток данных.