Відповіді:
Можливо, хороший спосіб перефразовувати питання полягає в тому, які переваги в порівнянні з альтернативними форматами?
Основними альтернативами, на мою думку, є: база даних, текстові файли чи інший запакований / двійковий формат.
Варіанти бази даних, які слід розглянути, - це, ймовірно, стовпчастий сховище або NoSQL, або для невеликих самостійних наборів даних SQLite. Основна перевага бази даних - це можливість працювати з даними, значно більшими за пам'ять, мати випадковий або індексований доступ та швидко додавати / додавати / змінювати дані. Основна перевага * dis * полягає в тому, що він набагато повільніше, ніж HDF, для проблем, в яких потрібно прочитати та обробити весь набір даних. Ще один недолік полягає в тому, що, за винятком баз даних з вбудованим стилем, таких як SQLite, база даних - це система (яка потребує адміністрації, налаштування, обслуговування тощо), а не просте самостійне сховище даних.
Параметри формату текстового файлу - XML / JSON / CSV. Вони є платформою / мовою / інструментарієм і є хорошим архівним форматом завдяки здатності до самоопису (або очевидно :). Якщо вони не стиснуті, вони величезні (10x-100x HDF), але якщо стиснуті, вони можуть бути досить просторовими (стислий XML приблизно такий же, як HDF). Основний недолік тут - швидкість: розбір тексту відбувається набагато, набагато повільніше, ніж HDF.
Інші бінарні формати (npy / npz numpy-файли, файли blz-файлів, протоколи буферів, Avro, ...) мають дуже схожі властивості з HDF, за винятком того, що вони менш підтримуються (можуть бути обмежені лише однією платформою: numpy) і можуть мають інші обмеження. Зазвичай вони не пропонують переконливої переваги.
HDF є хорошим доповненням до баз даних, можливо, має сенс запустити запит для створення набору даних розміром приблизно з пам’яттю, а потім кешувати його у форматі HDF, якщо ті самі дані будуть використовуватися більше одного разу. Якщо у вас є фіксований набір даних, який зазвичай обробляється в цілому, зберігання його як колекції файлів HDF відповідного розміру - не поганий варіант. Якщо у вас є набір даних, який часто оновлюється, періодично розміщувати його як HDF-файли все ще може бути корисно.
Підводячи підсумок, HDF - це хороший формат для даних, які читаються (або записуються), як правило, в цілому; це lingua franca або звичайний / бажаний формат обміну для багатьох програм через широку підтримку та сумісність, пристойний як архівний формат і дуже швидкий.
PS Щоб надати цьому певний практичний контекст, моєму останньому досвіду порівняння HDF з альтернативами, деякий невеликий (набагато менший, ніж розмір пам’яті) набір даних зайняв 2 секунди, щоб прочитати як HDF (і більшість цього, мабуть, накладні витрати від Pandas); ~ 1 хвилина для читання з JSON; і 1 годину для запису в базу даних. Звичайно, запис у базу даних може бути прискорений, але краще мати хороший DBA! Ось як це працює поза коробкою.
Однією з переваг є широка підтримка - C, Java, Perl, Python і R мають прив'язки HDF5.
Ще одна перевага - швидкість. Я ніколи не бачив цього показника, але HDF повинен бути швидшим, ніж бази даних SQL.
Я розумію, що це дуже добре, коли використовується як з великими наборами наукових даних, так і з даними часових рядів - моніторинг мережі, відстеження використання тощо.
Я не вірю, що для файлів HDF є обмеження розміру (хоча обмеження для ОС все одно застосовуються.
Щоб додати, перегляньте ASDF, зокрема їх паперовий ASDF: новий формат даних для астрономії ; ASDF намагається покращити рівень HDF5, і в статті описані деякі недоліки формату HDF5.