Как HDF5 отличается от папки с файлами?

Я работаю над проектом с открытым исходным кодом, касающимся добавления метаданных в папки. Предоставленный (Python) API позволяет вам просматривать и получать доступ к метаданным, как это была еще одна папка. Потому что это еще одна папка.

\folder\.meta\folder\somedata.json

Затем я наткнулся на HDF5 и его вывод Alembic.

Чтение на HDF5 в книге Python и HDF5 Я искал преимущества использования его по сравнению с использованием файлов в папках, но большая часть то, что я натолкнулся, говорил о преимуществах иерархического файлового формата с точки зрения его простоты в добавлении данных через его API:

>>> import h5py
>>> f = h5py.File("weather.hdf5")
>>> f["/15/temperature"] = 21

Или его способность читать только определенные части по запросу (например, произвольный доступ) и параллельное выполнение одного файла HDF5 (например, для многопроцессорной обработки)

Вы можете монтировать файлы HDF5, https://github.com/zjttoefs/hdfuse5

Он даже имеет сильную, но простую концепцию фундамента Группы и Наборы данных, которые из wiki читают:

Наборы данных, которые являются многомерными массивами однородного типа
Группы, которые представляют собой контейнерные структуры, которые могут хранить наборы данных и другие группы

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

Для каждой выгоды, с которой я столкнулся, никто не выделялся как эксклюзив для HDF5.

Итак, мой вопрос заключается в том, должен ли я предоставить вам один файл HDF5 и одну папку с файлами, как с идентичным контентом, в каком сценарии HDF5 лучше подходит?

Edit:

Получив некоторые ответы о переносимости HDF5.

Звучит прекрасно и все, но мне все еще не предоставлен пример, сценарий, в котором HDF5 выйдет из папки с файлами. Почему кто-то рассматривает использование HDF5, когда папка читается на любом компьютере, любая файловая система по сети поддерживает "параллельный ввод-вывод", читается людьми без интерпретатора HDF5.

Я бы сказал, что папка с файлами гораздо более переносима, чем любой HDF5.

Изменить 2:

Thucydides411 просто привел пример сценария, в котором важна переносимость. qaru.site/info/147994/...

Я думаю, что я отвлекаюсь от ответов в этом потоке, так это то, что HDF5 хорошо подходит, когда вам нужна организационная структура файлов и папок, как в приведенном выше примере сценария, с большими (миллионными) небольшими (~ 1 байт) структуры данных; как отдельные числа или строки. Что он компенсирует нехватку файловых систем, предоставляя "вспомогательную файловую систему", благоприятствующую малым и многим, в отличие от немногих и больших.

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

Ответ 1

Как кто-то, кто разработал научный проект, который перешел от использования папок файлов к HDF5, я думаю, что могу пролить свет на преимущества HDF5.

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

Я начал применять свой код к группам объектов, что означало запись нескольких таблиц ASCII в конце каждого прогона вместе с дополнительной таблицей ASCII, содержащей вывод, относящийся ко всей группе. Для каждой группы у меня теперь была папка, которая выглядела так:

+ group
|    |-- object 1
|    |-- object 2
|    |-- ...
|    |-- object N
|    |-- summary

В этот момент я начал сталкиваться с моими первыми трудностями. Файлы ASCII очень медленны для чтения и записи, и они не очень эффективно собирают числовую информацию, поскольку каждая цифра принимает полный байт для кодирования, а не ~ 3,3 бит. Поэтому я переключился на запись каждого объекта в виде пользовательского двоичного файла, который ускорил ввод-вывод и уменьшил размер файла.

Поскольку я увеличил количество обработанных групп (от десятков тысяч до миллионов), я неожиданно обнаружил, что имею дело с чрезвычайно большим количеством файлов и папок. Слишком много мелких файлов может быть проблемой для многих файловых систем (многие файловые системы ограничены количеством файлов, которые они могут хранить, независимо от того, сколько места на диске). Я также начал выяснять, что когда я попытаюсь выполнить пост-обработку всего моего набора данных, дисковый ввод-вывод для чтения многих небольших файлов начал занимать значительное время. Я попытался решить эти проблемы, объединив мои файлы, так что я создал только два файла для каждой группы:

+ group 1
|    |-- objects
|    |-- summary
+ group 2
|    |-- objects
|    |-- summary
...

Я также хотел сжать свои данные, поэтому начал создавать файлы .tar.gz для коллекций групп.

В этот момент вся моя схема данных становилась очень громоздкой, и был риск, что если я захочу передать свои данные кому-то другому, потребуется много усилий, чтобы объяснить им, как ее использовать. Бинарные файлы, содержащие объекты, например, имели собственную внутреннюю структуру, которая существовала только в файле README в репозитории и на бумажной бумаге в моем офисе. Тот, кто хочет прочитать один из моих двоичных файлов с комбинированными объектами, должен знать смещение байтов, тип и сущность каждой записи метаданных в заголовке и смещение байтов каждого объекта в файле. Если бы они этого не сделали, файл был бы тарабарщиком для них.

То, как я группировался и сжимал данные, также создавал проблемы. Скажем, я хотел найти один объект. Мне нужно было бы найти файл .tar.gz, в котором он был, распакуйте все содержимое архива во временную папку, перейдите к группе, которую меня интересует, и извлеките объект с помощью моего собственного API для чтения моих двоичных файлов, После того, как я закончил, я удалю временные распакованные файлы. Это было не изящное решение.

В этот момент я решил перейти на стандартный формат. HDF5 был привлекательным по ряду причин. Во-первых, я мог бы сохранить общую организацию моих данных в группы, наборы данных объектов и сводные массивы данных. Во-вторых, я мог бы отключить собственный API ввода-вывода двоичного файла и просто использовать многомерный массив данных для хранения всех объектов в группе. Я даже мог создавать массивы более сложных типов данных, например массивы структур C, без необходимости тщательно документировать байтовые смещения каждой записи. Затем HDF5 имеет сжатие, которое может быть полностью прозрачным для конечного пользователя данных. Поскольку сжатие фрагментировано, если я думаю, что пользователи захотят посмотреть на отдельные объекты, я могу иметь каждый объект, сжатый в отдельном фрагменте, так что только часть интересующего пользователя набора данных должна быть распакована. Чрезмерное сжатие - чрезвычайно мощная функция.

Наконец, я могу просто дать один файл кому-то сейчас, не объясняя, как он организован внутри. Конечный пользователь может прочитать файл в Python, C, Fortran или h5ls в командной строке или графическом интерфейсе HDFView и посмотреть, что внутри. Это было невозможно с моим бинарным форматом, не говоря уже о моих коллекциях .tar.gz.

Конечно, возможно реплицировать все, что вы можете сделать с HDF5 с папками, ASCII и пользовательскими двоичными файлами. Это то, что я изначально сделал, но это стало серьезной головной болью, и, в конце концов, HDF5 сделал все, что я собирал вместе эффективным и портативным способом.

Ответ 2

Спасибо, что задали этот интересный вопрос. Является ли папка с файлами переносимой, потому что я могу скопировать каталог на палку на Mac, а затем увидеть тот же каталог и файлы на ПК? Я согласен с тем, что структура каталогов файлов переносима, благодаря людям, которые пишут операционные системы, но это не связано с данными в портативных файлах. Теперь, если файлы в этом каталоге являются pdf файлами, они переносимы, потому что есть инструменты, которые читают и понимают PDF файлы в нескольких операционных системах (благодаря Adobe). Но если эти файлы являются необработанными научными данными (в ASCII или двоичном файле не имеет значения), они вовсе не переносимы. Файл ASCII будет похож на кучу символов, а бинарный файл будет выглядеть как тарабарщина. Если бы были файлы XML или json, они были бы удобочитаемыми, поскольку json - это ASCII, но содержащаяся информация скорее всего не будет переносимой, поскольку значение тегов XML/json может быть непонятным для того, кто не писал файл. Это важный момент, символы в ASCII файле переносимы, но информация, которую они представляют, не является.

Данные HDF5 переносимы, как и в формате pdf, поскольку во многих операционных системах, которые могут считывать данные в файлах HDF5 (например, в формате PDF), есть инструменты, см. http://www.hdfgroup.org/products/hdf5_tools/index.html). Существуют также библиотеки на многих языках, которые могут использоваться для чтения данных и представления их таким образом, который имеет смысл для пользователей - это то, что делает читатель Adobe. В сообществе HDF5 есть сотни групп, которые делают то же самое для своих пользователей (см. http://www.hdfgroup.org/HDF5/users5.html).

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

Другим важным моментом является то, что файлы HDF5 описывают самостоятельно, поэтому люди, которые пишут файлы, могут добавлять информацию, которая помогает пользователям и инструментам знать, что находится в файле. Каковы переменные, каковы их типы, какое программное обеспечение написало их, какие инструменты их собирали и т.д. Похоже, инструмент, над которым вы работаете, может читать метаданные для файлов. Атрибуты в файле HDF5 могут быть прикреплены к любому объекту в файле - это не только информация о уровне файла. Это огромно. И, конечно же, эти атрибуты можно читать с помощью инструментов, написанных на многих языках и многих операционных системах.

Ответ 3

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

В общем контексте Маркус в порядке, когда утверждает, что папка с файлами гораздо более переносима, чем любой HDF5. Я добавлю, что в общем контексте папка с файлом намного доступна, чем файл HDF5. Очевидная проблема заключается в том, что с "нормальной" папкой и файлами нет необходимости в дополнительном API для доступа к данным. Это просто невозможно с HDF5, который хранит данные и метаданные в одном файле.

Представьте себе момент, чтобы прочитать ваш pdf файл, вам нужен новый PDF-ридер, который понимает HDF5? Представьте, что для воспроизведения музыки вам нужен музыкальный проигрыватель, способный декодировать HDF5? для запуска вашего python script, интерпретатору python необходимо сначала декодировать HDF5? Или общее, чтобы запустить ваш интерпретатор python, вашей операционной системе необходимо декодировать HDF5? и т.д. Я просто не смогу написать этот ответ, потому что моя ОС не сможет запустить мой веб-браузер, который не сможет прочитать свои внутренние файлы, потому что раньше превратил все в HDF5 (может быть, большой HDF5 для всего, что есть на моем жестком диске).

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

Надеюсь, это поможет.

Ответ 4

Я считаю, что основным преимуществом является переносимость.

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

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

Файл hdf5 - это один файл, который иногда может быть более удобным, чем наличие папок и файлов zip/tar. Также существует большой недостаток: если вы удалите набор данных, вы не сможете вернуть пространство без создания нового файла.

Как правило, HDF5 хорошо подходит для хранения больших массивов чисел, обычно научных наборов данных.

Ответ 5

Игра, в которой вам нужно загрузить много ресурсов в память, будет сценарий, в котором HDF5 может быть лучше, чем папка с файлами. Загрузка данных из файлов требует затрат в качестве времени поиска, времени, необходимого для открытия каждого файла, и чтения данных из файла в память. Эти операции могут быть еще медленнее при чтении данных с DVD или Blu-ray. Открытие одного файла может значительно сократить эти затраты.

Ответ 6

В настоящее время я оцениваю HDF5, поэтому имел тот же вопрос.

Эта статья - Переход от HDF5 - задает почти такой же вопрос. В статье поднимаются некоторые соображения о том, что существует только одна реализация библиотеки HDF5, которая разрабатывается в относительно непрозрачных условиях по современным стандартам с открытым исходным кодом.

Как вы можете сказать из названия, авторы решили отойти от HDF5 к иерархии файловых систем двоичных файлов, содержащих массивы с метаданными в файлах JSON. Это было несмотря на то, что они внесли значительные инвестиции в HDF5, сжимая пальцы от повреждения данных и проблем с производительностью.

Ответ 7

Да, главным преимуществом является то, что HDF5 является портативным. К файлам HDF5 можно получить доступ к множеству других языков программирования/интерпретации, таких как Python (на котором построен ваш API), MATLAB, Fortran и C. Как предположил Саймон, HDF5 широко используется в научном сообществе для хранения больших наборов данных. По моему опыту, я нахожу способность извлекать только определенные наборы данных (и регионы) полезными. Кроме того, создание библиотеки HDF5 для параллельного ввода-вывода очень выгодно для последующей обработки необработанных данных позднее.

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

Надеюсь, что это поможет.

Ответ 8

HDF5 - это, в конечном счете, формат для хранения чисел, оптимизированный для больших наборов данных. Основными достоинствами являются поддержка сжатия (которая во многих случаях может ускорить чтение и запись данных) и быстрые встроенные запросы (поиск данных, удовлетворяющих определенным условиям, например, все значения давления при температуре выше 30 С).

Тот факт, что вы можете объединить несколько наборов данных в одном файле, является просто удобством. Например, у вас может быть несколько групп, соответствующих различным метеорологическим станциям, и каждая группа, состоящая из нескольких таблиц данных. Для каждой группы у вас будет набор атрибутов, описывающих детали инструментов, а для каждой таблицы - индивидуальные настройки. У вас может быть один файл h5 для каждого блока данных, с атрибутом в соответствующем месте, и он даст вам ту же функциональность. Но теперь, что вы можете сделать с HDF5, нужно переупаковать файл для оптимизации запросов, сжать все это немного и получить информацию с невероятной скоростью. Если у вас есть несколько файлов, каждый из них будет индивидуально сжат, и ОС решит макет на диске, что может быть не оптимальным.

Последнее, что HDF5 позволяет вам загружать файл (или кусок) в память, отображая тот же API, что и на диске. Например, вы можете использовать один или другой бэкэнд в зависимости от размера данных и доступной оперативной памяти. В вашем случае это будет эквивалентно копированию соответствующей информации в /dev/shm в Linux, и вы будете нести ответственность за внесение обратно на диск любых изменений.