Risposte:
Forse un buon modo per parafrasare la domanda è: quali sono i vantaggi rispetto ai formati alternativi?
Le principali alternative sono, credo: un database, file di testo o un altro formato compresso / binario.
Le opzioni del database da considerare sono probabilmente un archivio colonnare o NoSQL o per piccoli set di dati autonomi SQLite. Il vantaggio principale del database è la capacità di lavorare con dati molto più grandi della memoria, di avere accesso casuale o indicizzato e di aggiungere / aggiungere / modificare rapidamente i dati. Il vantaggio principale * dis * è che è molto più lento di HDF, per problemi in cui l'intero set di dati deve essere letto ed elaborato. Un altro svantaggio è che, ad eccezione dei database in stile incorporato come SQLite, un database è un sistema (che richiede amministrazione, configurazione, manutenzione, ecc.) Piuttosto che un semplice archivio di dati autonomo.
Le opzioni del formato del file di testo sono XML / JSON / CSV. Sono multipiattaforma / linguaggio / toolkit e sono un buon formato di archiviazione grazie alla capacità di auto-descriversi (o ovvio :). Se non compressi, sono enormi (10x-100x HDF), ma se compressi, possono essere abbastanza efficienti in termini di spazio (l'XML compresso è quasi uguale all'HDF). Lo svantaggio principale qui è di nuovo la velocità: l'analisi del testo è molto, molto più lenta dell'HDF.
Gli altri formati binari (file numpy npy / npz, file blz blaze, buffer di protocollo, Avro, ...) hanno proprietà molto simili a HDF, tranne che sono meno ampiamente supportati (possono essere limitati a una sola piattaforma: numpy) e possono hanno altre limitazioni specifiche. In genere non offrono un vantaggio convincente.
HDF è un buon complemento per i database, può avere senso eseguire una query per produrre un set di dati di dimensioni approssimativamente di memoria e quindi memorizzarlo nella cache in HDF se gli stessi dati vengano utilizzati più di una volta. Se si dispone di un set di dati che è stato risolto e generalmente elaborato nel suo insieme, archiviarlo come una raccolta di file HDF di dimensioni adeguate non è un'opzione errata. Se si dispone di un set di dati che viene aggiornato spesso, la messa in scena periodica di alcuni di essi come file HDF potrebbe essere comunque utile.
Riassumendo, HDF è un buon formato per i dati letti (o scritti) in genere nel loro insieme; è la lingua franca o formato di scambio comune / preferito per molte applicazioni grazie all'ampio supporto e compatibilità, decente come formato di archiviazione e molto veloce.
PS Per dare a questo contesto pratico, la mia esperienza più recente il confronto tra HDF e alternative, un determinato set di dati di dimensioni ridotte (molto inferiore alla memoria) ha impiegato 2 secondi per essere letto come HDF (e la maggior parte di questo è probabilmente sovraccarico di Pandas); ~ 1 minuto per leggere da JSON; e 1 ora per scrivere nel database. Certamente la scrittura del database potrebbe essere velocizzata, ma è meglio avere un buon DBA! Funziona così fuori dalla scatola.
Uno dei vantaggi è l'ampio supporto: C, Java, Perl, Python e R hanno tutti collegamenti HDF5.
Un altro vantaggio è la velocità. Non l'ho mai visto comparato, ma HDF dovrebbe essere più veloce dei database SQL.
Comprendo che è molto buono se utilizzato con entrambi grandi set di dati scientifici e dati di serie temporali - monitoraggio della rete, monitoraggio dell'utilizzo, ecc.
Non credo ci sia un limite di dimensioni per i file HDF (anche se i limiti del sistema operativo sarebbero comunque applicabili.
Per aggiungere, controlla ASDF in particolare il loro documento ASDF: un nuovo formato di dati per l'astronomia ; ASDF cerca di migliorare HDF5 e il documento descrive alcuni aspetti negativi del formato HDF5.