Spark SQL: объем памяти кеш-памяти улучшается с помощью «упорядочить по»

У меня есть два сценария, в которых я 23 GB разделил parquet данные и читаю несколько columns & caching их заранее, чтобы впоследствии запустить серию последующих запросов.

Настройка:

  • Кластер: 12 узлов ЭМИ
  • Версия Spark: 1.6
  • Конфигурации Spark: по умолчанию
  • Конфигурации запуска: одинаковые для обоих случаев

Случай 1:

val paths = Array("s3://my/parquet/path", ...)
val parqFile = sqlContext.read.parquet(paths:_*)
parqFile.registerTempTable("productViewBase")
val dfMain = sqlContext.sql("select guid,email,eventKey,timestamp,pogId from productViewBase")
dfMain.cache.count

С SparkUI считанные входные данные составляют 6,2 ГБ, а размер кэшированного объекта - 15,1 ГБ.

Случай 1:

val paths = Array("s3://my/parquet/path", ...)
val parqFile = sqlContext.read.parquet(paths:_*)
parqFile.registerTempTable("productViewBase")
val dfMain = sqlContext.sql("select guid,email,eventKey,timestamp,pogId from productViewBase order by pogId")
dfMain.cache.count

Начиная с SparkUI объем считываемых входных данных составляет 6,2 ГБ, а размер кэшированного объекта - 5,5 ГБ.

Любое объяснение или ссылка на код этого поведения?


sql performance apache-spark apache-spark-sql scala
person Mohitt    schedule 26.03.2016    source источник

Ответы (1)


arrow_upward
3
arrow_downward

На самом деле это относительно просто. Как вы можете прочитать в руководстве по SQL:

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

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

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

Различные аспекты столбчатого сжатия Spark описаны в _ 1_ и, как вы можете видеть, _ 2_ действительно является одной из доступных схем сжатия.

Итак, здесь есть две части:

  • # P7 #
    # P8 #

  • Сортировка может объединять похожие записи в кластеры, делая сжатие намного более эффективным.

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

person zero323    schedule 26.03.2016
comment
Не специалист по столбчатому хранению, но похоже на чудо, что упорядоченные данные в одном столбце вызвали трехкратное сжатие. Не могли бы вы поделиться какими-либо подробностями или ссылками на код, с которыми я могу отлаживать / экспериментировать? - person Mohitt; 26.03.2016
comment
@Mohitt есть ли сериализация? - person eliasah; 26.03.2016
comment
Нет явной сериализации. Все по умолчанию. - person Mohitt; 26.03.2016
comment
Можете ли вы попробовать поэкспериментировать, используя Kryo на примере? Необработанное кэширование связано с накладными расходами и может занимать в 2-4 раза больше места при сохранении. - person eliasah; 26.03.2016
comment
@Mohitt Я немного расширил ответ, но это зависит от разных факторов. Лично я бы порекомендовал просмотреть несколько книг о In-Memory Data Managemen, написанных проф. Хассо Платтнер. Обычно это безумно дорогое удовольствие, но многие главы доступны бесплатно в качестве материалов курса. - person zero323; 26.03.2016