Производительность сжатия паркета сгруппирована против плоских данных - PullRequest
2 голосов
/ 02 июля 2019

Не могу получить прямой ответ из сети. Рассмотрим следующий сценарий данных: У меня есть данные, которые содержат user_id и временные метки активности пользователя:

val bigData = Seq( ( "id3",12),
                 ("id1",55),
                 ("id1",59),
                 ("id1",50),
                 ("id2",51),
                 ("id3",52),
                 ("id2",53),
                 ("id1",54),
              ("id2", 34)).toDF("user_id", "ts")

Итак, оригинальный DataFrame выглядит следующим образом:

+-------+---+
|user_id| ts|
+-------+---+
|    id3| 12|
|    id1| 55|
|    id1| 59|
|    id1| 50|
|    id2| 51|
|    id3| 52|
|    id2| 53|
|    id1| 54|
|    id2| 34|
+-------+---+

и вот что я напишу, например, в HDFS \ S3.

Однако я не могу сохранить данные, сгруппированные пользователем, например, так:

bigData.groupBy("user_id").agg(collect_list("ts") as "ts")

Какой результат:

+-------+----------------+
|user_id|              ts|
+-------+----------------+
|    id3|        [12, 52]|
|    id1|[55, 59, 50, 54]|
|    id2|    [51, 53, 34]|
+-------+----------------+

Я могу получить решительный ответ о том, какой метод улучшит хранение / сжатие в файловой системе. Групповой подход выглядит (интуитивно) лучше с точки зрения хранения / сжатия.

Кто-нибудь знает, существует ли абсолютный подход или знает какие-либо критерии или статьи по этому вопросу?

1 Ответ

1 голос
/ 02 июля 2019

Рассмотрим первый случай, когда данные хранятся в плоской структуре. Если вы сортируете данные w.r.r по id, то идентичные идентификаторы будут идти в тот же раздел. Это приведет к сжатию словаря Parquet , что приведет к уменьшению размера.

Более того, если ваш ts ограничен, то паркетный формат сохраняет основу и создает смещения.

Например

50 51 52 60 are the ts
Parquet saves : base: 50, offset: 0, 1, 2, 8

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

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

Например

ts
----
[20], 
[20,40,60,70,80]

паркет создаст отступы для 20 и сохранит тот же самый размер [20,40,60,70,80].

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

...