Ответы:
Возможно, хороший способ перефразировать вопрос, каковы преимущества по сравнению с альтернативными форматами?
Я думаю, что основными альтернативами являются: база данных, текстовые файлы или другой упакованный / двоичный формат.
Варианты базы данных, которые следует учитывать, - это, вероятно, столбчатое хранилище, или 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 является хорошим форматом для данных, которые обычно считываются (или записываются) в целом; это лингва франка или общий / предпочтительный формат обмена для многих приложений благодаря широкой поддержке и совместимости, приличный как архивный формат и очень быстрый.
PS Чтобы дать этому некоторый практический контекст, мой последний опыт сравнения HDF с альтернативами, определенному небольшому (намного меньшему, чем объем памяти), набору данных потребовалось 2 секунды для чтения как HDF (и большая часть этого, вероятно, излишняя для Pandas); ~ 1 минута для чтения из JSON; и 1 час для записи в базу данных. Конечно, запись в базу данных может быть ускорена, но вам лучше иметь хорошего администратора базы данных! Вот как это работает из коробки.
Одним из преимуществ является широкая поддержка - C, Java, Perl, Python и R имеют привязки HDF5.
Еще одно преимущество - скорость. Я никогда не видел его в тестах, но HDF должен быть быстрее, чем базы данных SQL.
Я понимаю, что это очень хорошо, когда используется как с большими наборами научных данных, так и с данными временных рядов - мониторинг сети, отслеживание использования и т. Д.
Я не верю, что существует ограничение по размеру для файлов HDF (хотя ограничения ОС все равно будут применяться.
Чтобы добавить, посмотрите ASDF, в частности, их документ ASDF: новый формат данных для астрономии ; ASDF пытается улучшить HDF5, и в статье описываются некоторые недостатки формата HDF5.