Spark Существует ли какое-либо эмпирическое правило об оптимальном числе разбиений RDD и его количестве?

Question

Есть ли какая-либо связь между количеством элементов, содержащихся в RDD, и его идеальным количеством разделов?

У меня есть RDD, у которого есть тысячи разделов (потому что я загружаю его из исходного файла, состоящего из нескольких небольших файлов, это противоречие, которое я не могу исправить, поэтому мне приходится иметь дело с ним). Я хотел бы переделать его (или использовать метод coalesce). Но я не знаю заранее, какое количество событий будет содержать RDD.
Так что я хотел бы сделать это автоматическим способом. То, что будет выглядеть следующим образом:

val numberOfElements = rdd.count() 
val magicNumber = 100000 
rdd.coalesce(numberOfElements/magicNumber) 

Есть ли правило об оптимальном количестве перегородки РДА и его количества элементов?

Спасибо.

Answer 1

Это не так, поскольку он сильно зависит от приложения, ресурсов и данных. Существуют некоторые жесткие ограничения (like various 2GB limits), но в остальном вам нужно настроить задачу на задачу. Некоторые факторы, которые необходимо учитывать:

• размера одной строки/элемент
• стоимости типичной операции. Если небольшие разделы и операции дешевы, то затраты на планирование могут быть намного выше, чем стоимость обработки данных.
• стоимость обработки раздела при выполнении разделов (например, сортировка) операций.

Если основной проблемой является ряд исходных файлов, то использование какого-либо варианта CombineFileInputFormat может быть лучшей идеей, чем перераспределение/объединение. Например:

sc.hadoopFile(
    path, 
    classOf[CombineTextInputFormat], 
    classOf[LongWritable], classOf[Text] 
).map(_._2.toString) 

Answer 2

Хотя я полностью согласен с zero323, вы по-прежнему можете реализовать какие-то эвристики. Внутри мы взяли размер данных, хранящихся как значение ключа avro, и сжатое и вычисленное количество разделов, так что каждый раздел будет не более 64 МБ (totalVolume/64MB ~ количество разделов). Время от времени мы запускаем автоматическое задание, чтобы пересчитать «оптимальное» количество разделов на каждый тип ввода и т. Д. В нашем случае это легко сделать, поскольку входы из hdfs (s3 будет работать слишком вероятно)

Еще раз это зависит на вашем вычислении и ваших данных, поэтому ваш номер может быть совершенно другим.