Производительность сжатия, связанная с размером блока в файлах hdf5

Я хотел бы задать вопрос о производительности сжатия, которая связана с размером блока файлов hdf5.

У меня есть 2 файла hdf5 со следующими свойствами. Оба они содержат только один набор данных, называемый «данными».

"Данные" файла А:

  1. Тип: Скалярный набор данных HDF5
  2. Количество размеров: 2
  3. Размер: 5094125 x 6.
  4. Максимум. размерный размер: Неограниченный x Неограниченный
  5. Тип данных: 64-битная с плавающей запятой
  6. Разделение на части: 10000 x 6
  7. Сжатие: уровень GZIP = 7

"Данные" файла B:

  1. Тип: Скалярный набор данных HDF5
  2. Количество размеров: 2
  3. Размер: 6720 x 1000.
  4. Максимум. размерный размер: Неограниченный x Неограниченный
  5. Тип данных: 64-битная с плавающей запятой
  6. Разделение на части: 6000 x 1
  7. Сжатие: уровень GZIP = 7

Размер файла A: HDF5 ---- 19 МБ CSV ----- 165 МБ

Размер файла B: HDF5 ---- 60 МБ CSV ----- 165 МБ

Оба они показывают отличное сжатие хранимых данных по сравнению с файлами csv. Однако степень сжатия файла A составляет около 10% от исходного csv, в то время как степень сжатия файла B составляет лишь около 30% от исходного csv.

Я пробовал использовать другой размер блока, чтобы сделать файл B как можно меньше, но мне кажется, что 30% - это оптимальная степень сжатия. Я хотел бы спросить, почему файл A может достичь большего сжатия, а файл B - нет.

Если файл B тоже может достичь, каков должен быть размер блока?

Это какое-то правило для определения оптимального размера фрагмента HDF5 для сжатия?

Спасибо!


compression hdf5 chunking
person C.T.    schedule 28.05.2013    source источник
comment
Я предполагаю, что сжатие, вероятно, также зависит от сходства данных внутри определенного фрагмента. Так что сложно сказать, почему есть разница. Для получения дополнительной информации о фрагментировании и производительности см .: - github.com/h5py/h5py / wiki / Guide-To-Compression - hdfgroup.org/HDF5 /doc/UG/index.html - pytables.org/moin/HowToUse#Presentations   -  person Ümit    schedule 29.05.2013
comment
Спасибо, согласен, разницу сложно объяснить, хотя степень сжатия действительно низкая. Кроме того, мне интересно, связано ли это с размером набора данных, скажем, 100 x 100 и 1000 x 10 могут иметь разные характеристики сжатия даже с одними и теми же данными внутри.   -  person C.T.    schedule 03.06.2013

Ответы (1)


arrow_upward
10
arrow_downward

На самом деле разбиение на части не влияет на степень сжатия per se, за исключением того, как описывает @ Ümit. Разделение на части влияет на производительность ввода-вывода. Когда сжатие применяется к набору данных HDF5, оно применяется к целым фрагментам по отдельности. Это означает, что при чтении данных из одного фрагмента в наборе данных весь фрагмент должен быть распакован - возможно, потребуется гораздо больше операций ввода-вывода, в зависимости от размера кеша, формы фрагмента и т. Д.

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

person Yossarian    schedule 31.05.2013
comment
Я согласен с тем, что разбиение на части связано с производительностью ввода-вывода больше, чем с производительностью сжатия. Что касается производительности ввода-вывода, у меня есть еще один вопрос: если размер набора данных фиксирован, например 10000 x 6, я думаю, что размер блока (1000,6) подходит, поскольку я читаю его по строкам. Однако, если измерение носит динамический характер, скажите «нет». столбцов и строк со временем будет увеличиваться. Каким должен быть размер чанка? - person C.T.; 03.06.2013
comment
Да, это хороший размер. Увеличиваются ли они каждый раз на фиксированную величину? Если они это сделают, я бы посоветовал начать с этого размера. Например, если вы всегда увеличиваете размеры на (500, 3), делайте свои чанки (500, 3). Это также зависит от того, больше ли вы читаете, чем пишете, или наоборот. Если это одна запись, много чтения, например, приведите ваши фрагменты в соответствие с тем, как вы читаете данные. Конечно, вы все равно можете сделать некоторые измерения и уточнить размер блока! - person Yossarian; 03.06.2013
comment
Кроме того, в отличие от распространенного мнения, сжатие может улучшить производительность чтения. Но это только при условии, что размер вашего блока соответствует способу чтения данных (см. Комментарии @Yossarian). Причина, по которой чтение сжатых данных может быть быстрее, чем несжатых, заключается в том, что библиотеки быстрого многопоточного сжатия (например, blosc в pyTables или lzf в h5py) очень быстрые и эффективные. С огромными наборами данных узким местом на самом деле является ввод-вывод, а не производительность процессора, которая важна для сжатия. См. эту статью. - person Ümit; 03.06.2013
comment
Я понимаю. Я создал несколько файлов hdf5 с одинаковыми данными и разным размером блока и сравнил их размеры и время чтения. Можно добиться высокого сжатия при хорошей производительности чтения. Я планирую разбить данные по предполагаемому измерению, которое читается каждый раз. Спасибо за вашу помощь! - person C.T.; 04.06.2013