Apache Spark 2.1 — атрибуты Scala Longy/Heavy для объекта Row

Мы написали искровое приложение на Scala 2.11, которое работает на автономном кластере Spark 2.1.0. Согласно дизайну/требованиям, мы построили объект строки, имеющий много прямых столбцов, таких как 100, и есть несколько вложенных столбцов, где некоторые из вложенных столбцов также тяжелые, например, с последовательностью от 20 до 30 тысяч. Существует также соответствующий класс case для работы с наборами данных Spark.

Например:

Row(column_01,
    column_02...
    .....column_150, 
        column_151 = Seq,
        column_152 = Seq...column_160 = Seq)

где некоторые из Seq имеют размер от 20k до 30k.

Меня мало беспокоит, как эти длинные/тяжелые атрибуты для объекта строки влияют на производительность? Какие оптимизации мы можем сделать в коде для повышения производительности? Любые предложения по настройке кластера?

Мы уже работаем над следующими оптимизациями:

  1. увеличение количества разделов
  2. Использование формата файла паркета с быстрым сжатием

parquet apache-spark apache-spark-sql apache-spark-2.0
person veerat    schedule 09.11.2017    source источник

Ответы (2)


arrow_upward
1
arrow_downward

У Spark нет особых проблем с тяжелыми строками. Мы без проблем управляем петабайтами данных в глубоко вложенных строках с сотнями полей.

Есть несколько вещей, которые следует иметь в виду:

  1. По возможности отдавайте предпочтение структурам, а не картам, поскольку в Parquet структуры автоматически выравниваются, а карты сложнее создавать экземпляры.

  2. Если вам нужно обрабатывать все данные в строке большую часть времени и вы можете использовать исключительно наборы данных, вы, как правило, получите лучшую производительность, чем при использовании фреймов данных, и стоит инвестировать в классы case, чтобы включить кодирование/декодирование набора данных.

  3. Для запросов, которым требуется только небольшая часть данных, запустите df.explain(), чтобы увидеть, не извлекает ли Spark слишком много, например всю структуру, когда требуется только одно поле структуры. На момент написания этой статьи с этим были некоторые проблемы. Обычно их можно обойти, переписав преобразование/запрос, чтобы явно выбрать минимальный набор данных, необходимых в первую очередь.

  4. По возможности избегайте вложенных массивов, так как их обработка может усложниться. Массивы сами по себе не проблема.

person Sim    schedule 11.11.2017

arrow_upward
0
arrow_downward

Вы используете паркет, который является столбчатым, поэтому вы можете использовать синтаксис фрейма данных для выбора только тех столбцов, которые вам нужны для обработки и работы с ними. Если вы используете набор данных с использованием синтаксиса «dataframe.as [класс]», тогда десериализуется вся строка, что может быть дорого, если есть слишком много столбцов. Вы также можете выбрать несколько столбцов, используя набор данных, но вам нужно будет преобразовать его в класс, который имеет эти свойства.

person Salim    schedule 17.01.2020