спасение сжатого JSON от искры - PullRequest
       10

спасение сжатого JSON от искры

0 голосов
/ 15 сентября 2018

из Spark RDD, я хочу подготовить и заархивировать данные JSON в AWS S3. Имеет смысл только сжать его, и у меня есть процесс, работающий с использованием GzipCodec hadoop, но есть вещи, которые заставляют меня нервничать по этому поводу.

Когда я смотрю на сигнатуру типа org.apache.spark.rdd.RDD.saveAsTextFile здесь:

https://spark.apache.org/docs/2.3.0/api/scala/index.html#org.apache.spark.rdd.RDD

тип подписи:

def saveAsTextFile(path: String, codec: Class[_ <: CompressionCodec]): Unit

но когда я проверяю доступные кодеки сжатия здесь:

https://spark.apache.org/docs/2.3.0/api/scala/index.html#org.apache.spark.io.CompressionCodec

родительская черта CompressionCodec и все подтипы говорят:

Проводной протокол для кодека не гарантированно совместим во всех версиях Spark. Это предназначено для использования в качестве утилиты внутреннего сжатия в одном приложении Spark

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

Сигнатура типа говорит, что кодек должен быть подтипом CompressionCodec ... но я попробовал следующее, чтобы сохранить как .gz, и он отлично работает, хотя GzipCodec от hadoop не <: CompressionCodec.

import org.apache.hadoop.io.compress.GzipCodec
rdd.saveAsTextFile(bucketName, classOf[GzipCodec])

мои вопросы:

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

1 Ответ

0 голосов
/ 15 сентября 2018

Ну, для начала, вы связаны с RDD или вы можете использовать DataSets / DataFrames?

С DataFrames вы можете использовать что-то вроде

 df.write.format("json").
    option("compression", "org.apache.hadoop.io.compress.GzipCodec").
    save("...")

Однако есть несколько соображений,Сжатие - это хорошо, но если файлы, которые вы генерируете, очень большие, вы должны иметь в виду, что gzip не является форматом с разделением, то есть, если вы захотите позже обработать этот файл, он должен быть прочитан однимработник.Например, если ваш файл не разделяемый и имеет размер 1 ГБ, для его обработки потребуется T время, если бы он был разделяемым (например, LZO, Snappy или BZip2), его можно обработать в T / N, где N - количество разбиений(при условии блоков 128 МБ, это будет около 8).Вот почему Hadoop использует SequenceFiles (которые разделяются и используют gzip в одном блоке), и поэтому предпочтительным сжатым форматом при сохранении в S3 обычно является Parquet.Файлы паркета меньше, чем Gzip-файлы, и их можно разделить, то есть их содержимое может обрабатываться несколькими рабочими.Вы по-прежнему можете использовать текстовые файлы в формате gzip, но держите их в диапазоне ~ 100/200 Мбайт.

В конце концов, это действительно зависит от того, что вы планируете делать с данными в S3.

Будет ли это запрашиваться?В этом случае паркет является гораздо лучшим выбором в качестве формата.

Будет ли он считываться / копироваться в другие системы, которые не понимают паркет?Тогда сжатие GZIP в порядке.И он стабилен, вам не нужно беспокоиться об этом.Вы можете попробовать это самостоятельно, сохранить пример данных на S3, вы все равно можете открыть его с помощью любого инструмента gzip.

...