Почему разделенные файлы паркета занимают больше места на диске?

Question

Я изучаю паркетный файл, используя python и pyarrow. Паркет отлично сжимает и минимизирует дисковое пространство. Мой набор данных - 190 МБ CSV-файла, который при сохранении в виде snappy сжатого файла паркета заканчивается как один файл размером 3 МБ.

Однако, когда я сохраняю свой набор данных как многораздельные файлы, они приводят к объединению гораздо больших размеров (61 МБ).

Вот пример набора данных, который я пытаюсь сохранить:

listing_id |     date     | gender | price
-------------------------------------------
     a     |  2019-01-01  |   M    |   100
     b     |  2019-01-02  |   M    |   100
     c     |  2019-01-03  |   F    |   200
     d     |  2019-01-04  |   F    |   200

Когда я разбил на разделы по дате (более 300 уникальных значений), размер разделенных файлов составит 61 МБ. Каждый файл имеет размер 168.2kB. Когда я делю по полу (2 уникальных значения), размер разделенных файлов составляет всего 3 МБ.

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

Мой env:

- OS: Ubuntu 18.04
- Language: Python
- Library: pyarrow, pandas

Мой источник данных:

https://www.kaggle.com/brittabettendorf/berlin-airbnb-data

# I am using calendar_summary.csv as my data from a group of datasets in that link above

Мой код для сохранения в виде файла паркета:

# write to dataset using parquet
df = pd.read_csv('./calendar_summary.csv')
table = pyarrow.Table.from_pandas(df)
pyarrow.parquet.write_table(table=table, where='./calendar_summary_write_table.parquet')

# parquet filesize
parquet_method1_filesize = os.path.getsize('./calendar_summary_write_table.parquet') / 1000
print('parquet_method1_filesize: %i kB' % parquet_method1_filesize)

Мой код длясохранить как секционированный файл паркета:

# write to dataset using parquet (partitioned)
df = pd.read_csv('./calendar_summary.csv')
table = pyarrow.Table.from_pandas(df)
pyarrow.parquet.write_to_dataset(
    table=table, 
    root_path='./calendar_summary/', 
    partition_cols=['date'])

# parquet filesize
import os
print(os.popen('du -sh ./calendar_summary/').read())

Answer 1

Минимального размера файла не существует, но есть накладные расходы на хранение нижнего колонтитула, и есть упущенная возможность для оптимизации с помощью кодировок и сжатий. Различные кодировки и сжатия основаны на идее, что данные обладают некоторой степенью самоподобия, которую можно использовать, ссылаясь на более ранние подобные случаи. Когда вы разбиваете данные на несколько файлов, каждому из них потребуется отдельная «начальная точка данных», на которую могут ссылаться последующие, поэтому использование диска возрастает. (Обратите внимание, что в этой формулировке есть огромные упрощения, чтобы избежать необходимости специально использовать различные методы, используемые для экономии места, но см. этот ответ для нескольких примеров.)

Другая вещьЭто может иметь огромное влияние на размер файлов Parquet, это порядок, в котором вставляются данные. Сортированный столбец может храниться намного эффективнее, чем случайно упорядоченный. Вполне возможно, что, разбивая данные, вы случайно изменили порядок их сортировки. Другая возможность состоит в том, что вы разбиваете данные по самому атрибуту, по которому они были упорядочены, и это позволило значительно сэкономить место при хранении в одном файле, и эта возможность теряется при разбиении данных на несколько файлов. Наконец, вы должны иметь в виду, что Parquet оптимизирован не для хранения нескольких килобайт данных, а для нескольких мегабайт или гигабайт (в одном файле) или нескольких петабайт (в нескольких файлах).

Если выЕсли вы хотите проверить, как ваши данные хранятся в ваших файлах Parquet, Java-реализация Parquet включает утилиту parquet-tools, предоставляющую несколько команд. Смотрите страницу документации для сборки и начала работы. Более подробные описания отдельных команд напечатаны самим parquet-tools. Наиболее интересными для вас являются команды meta и dump.