Иерархический формат данных. Каковы преимущества по сравнению с альтернативными форматами?

Question

Каковы основные преимущества хранения данных в HDF? И каковы основные задачи науки о данных, где HDF действительно подходит и полезен?

Answer 1

Возможно, хороший способ перефразировать вопрос, каковы преимущества по сравнению с альтернативными форматами?

Я думаю, основные альтернативы: база данных, текстовые файлы или другой упакованный/двоичный формат.

Параметры базы данных, которые для рассмотрения, вероятно, представляют собой столбчатый хранилище или NoSQL, или для небольших автономных наборов данных SQLite. Основным преимуществом базы данных является возможность работать с данными, намного больше, чем память, иметь случайный или индексированный доступ, а также быстро добавлять/добавлять/изменять данные. Основное преимущество *dis *заключается в том, что он намного медленнее, чем HDF, для проблем, в которых весь набор данных должен быть прочитал и обрабатывается. Другим недостатком является то, что, за исключением баз данных встроенного стиля, таких как SQLite, база данных-это система (требующая познания, настройки, обслуживания и т. Д.), А не просто самостоятельное хранилище данных.

Параметры формата текстового файла - XML/JSON/CSV. Они кроссплатформенные/язык/инструментарий, и являются хорошим архивным форматом из-за способности быть самоописанием (или очевидным :). Если они несправляются, они огромны (10x-100x HDF), но если они сжаты, они могут быть довольно космическими (сжатый XML примерно такой же, как HDF). Основным недостатком здесь снова является скорость: текст анализа намного медленнее, чем HDF.

Другие двоичные форматы (файлы NPY/NPZ Numpy, файлы BLZ Blaze, буферы протокола, AVRO, ...) имеют очень похожие свойства HDF, за исключением случаев, что они менее широко поддерживаются (может быть ограничена только одной платформой: Numpy) и может иметь конкретные другие ограничения. Как правило, они не предлагают убедительного преимущества.

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

Подводя итог, HDF является хорошим форматом для данных, которые читаются (или написано) обычно в целом; Это Lingua Franca или общий/предпочтительный формат обмена для многих приложений из -за широкой поддержки и совместимости, приличного в качестве архивного формата и очень быстро.

PS, чтобы дать этот практический контекст, мой последний опыт сравнения HDF с альтернативами, определенный небольшой (гораздо меньший, чем размером с память) набор данных, занял 2 секунды, чтобы читать как HDF (и большая часть этого, вероятно, накладных расходов от пандов); ~ 1 минута, чтобы прочитать от JSON; и 1 час написать в базу данных. Конечно, написать в базе данных можно было бы ускорить, но вам лучше иметь хороший DBA! Вот как это работает из коробки.

Answer 2

Одним из преимуществ является широкая поддержка - C, Java, Perl, Python и R имеют привязки HDF5.

Другое преимущество - скорость. Я никогда не видел, чтобы это сравнивал, но HDF должен быть быстрее, чем базы данных SQL.

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

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

Answer 3

Чтобы добавить, проверьте ASDF в частности, их бумага ASDF: новый формат данных для астрономии; ASDF пытается улучшить HDF5, и в статье описываются некоторые недостатки формата HDF5.