it-swarm.com.de

Wie unterscheidet sich HDF5 von einem Ordner mit Dateien?

Ich arbeite an einem Open Source-Projekt , das sich mit dem Hinzufügen von Metadaten zu Ordnern befasst. Mit der bereitgestellten (Python) -API können Sie Metadaten wie einen anderen Ordner durchsuchen und auf sie zugreifen. Weil es nur ein anderer Ordner ist.

\folder\.meta\folder\somedata.json

Dann bin ich auf HDF5 und dessen Ableitung Alembic gestoßen.

Lesen von HDF5 im Buch Python und HDF5 Ich war auf der Suche nach Vorteilen im Vergleich zur Verwendung von Dateien in Ordnern, aber das meiste, worauf ich stieß, sprach über die Vorteile eines hierarchischen Dateiformats Einfachheit beim Hinzufügen von Daten über die API:

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

Oder die Fähigkeit, nur bestimmte Teile davon auf Anforderung zu lesen (z. B. Direktzugriff) und parallele Ausführung einer einzelnen HDF5-Datei (z. B. für die Mehrfachverarbeitung).

Sie könnten HDF5-Dateien einbinden, https://github.com/zjttoefs/hdfuse5

Es verfügt sogar über ein starkes, aber einfaches Grundlagenkonzept aus Groups und Datasets, das aus dem Wiki lautet:

  • Datensätze, bei denen es sich um mehrdimensionale Arrays eines homogenen Typs handelt 
  • Gruppen, bei denen es sich um Containerstrukturen handelt, die Datensätze und andere Gruppen enthalten können

Ersetzen Sie Dataset durch File und Group durch Folder. Das gesamte Feature-Set klingt für mich so, als wären die Dateien in Ordnern bereits vollständig in der Lage.

Bei allen Vorteilen, die mir begegnet sind, zeichnete sich keiner für HDF5 aus.

Meine Frage ist also, wenn ich Ihnen eine HDF5-Datei und einen Ordner mit Dateien mit identischem Inhalt geben würde. In welchem ​​Szenario wäre HDF5 besser geeignet?

Bearbeiten:

Einige Antworten zur Portabilität von HDF5 erhalten.

Es klingt schön und alles, aber mir wurde noch kein Beispiel gegeben, ein Szenario, in dem ein HDF5 einen Ordner mit Dateien übertrumpfen würde. Warum sollte jemand die Verwendung von HDF5 in Betracht ziehen, wenn ein Ordner auf einem beliebigen Computer lesbar ist, jedes Dateisystem über ein Netzwerk "Parallel I/O" unterstützt und von Menschen ohne HDF5-Interpreter gelesen werden kann?.

Ich würde sagen, ein Ordner mit Dateien ist weitaus portabler als jeder HDF5.

Edit 2:

Thucydides411 gab nur ein Beispiel für ein Szenario, in dem die Portabilität von Belang ist . https://stackoverflow.com/a/28512028/478949

Ich denke, was ich von den Antworten in diesem Thread wegnehme, ist, dass HDF5 gut geeignet ist, wenn Sie die Organisationsstruktur von Dateien und Ordnern benötigen, wie im obigen Beispielszenario mit vielen (Millionen) kleinen (~ 1 Byte). Datenstrukturen; wie einzelne Zahlen oder Zeichenfolgen. Das macht das aus, was Dateisystemen fehlen, indem es ein "Sub-Dateisystem" bereitstellt, das den kleinen und vielen gegenüber den wenigen und den großen den Vorzug gibt.

In der Computergrafik verwenden wir es, um geometrische Modelle und beliebige Daten zu einzelnen Scheitelpunkten zu speichern, die sich anscheinend gut an die Verwendung in der wissenschaftlichen Gemeinschaft anpassen.

48
Marcus Ottosson

Als jemand, der ein wissenschaftliches Projekt entwickelt hat, das von der Verwendung von Ordnern zu HDF5 übergegangen ist, denke ich, dass ich ein wenig Licht auf die Vorteile von HDF5 werfen kann.

Als ich mit meinem Projekt anfing, arbeitete ich mit kleinen Testdatensätzen und produzierte kleine Mengen von Ausgaben im Bereich von Kilobytes. Ich begann mit dem einfachsten Datenformat, Tabellen, die als ASCII codiert waren. Für jedes von mir verarbeitete Objekt habe ich die Tabelle ASCII erstellt.

Ich fing an, meinen Code auf Gruppen von Objekten anzuwenden, was bedeutete, dass am Ende jedes Laufs mehrere ASCII -Tabellen sowie eine zusätzliche ASCII -Tabelle mit Ausgaben für die gesamte Gruppe geschrieben wurden. Für jede Gruppe hatte ich jetzt einen Ordner, der wie folgt aussah:

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

An diesem Punkt fing ich an, meine ersten Schwierigkeiten zu treffen. ASCII -Dateien sind sehr langsam zu lesen und zu schreiben, und sie packen numerische Informationen nicht sehr effizient, da jede Ziffer ein ganzes Byte für die Kodierung und nicht etwa ~ 3,3 Bit benötigt. Ich habe also jedes Objekt als benutzerdefinierte Binärdatei geschrieben, was die E/A und die Dateigröße beschleunigte. 

Als ich mich auf die Verarbeitung einer großen Anzahl (Zehntausende bis Millionen) von Gruppen konzentrierte, befand ich mich plötzlich mit einer extrem großen Anzahl von Dateien und Ordnern. Zu viele kleine Dateien können für viele Dateisysteme ein Problem sein (viele Dateisysteme sind in der Anzahl der Dateien, die sie speichern können, begrenzt, unabhängig davon, wie viel Speicherplatz vorhanden ist). Ich fing auch an zu erfahren, dass, wenn ich versuche, die Nachbearbeitung meines gesamten Datensatzes durchzuführen, die Festplatten-E/A zum Lesen vieler kleiner Dateien eine beträchtliche Zeit in Anspruch nahm. Ich habe versucht, diese Probleme durch Konsolidierung meiner Dateien zu lösen, sodass ich für jede Gruppe nur zwei Dateien produzierte:

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

Ich wollte auch meine Daten komprimieren und fing an, .tar.gz-Dateien für Gruppensammlungen zu erstellen.

Zu diesem Zeitpunkt wurde mein gesamtes Datenschema sehr umständlich, und es bestand die Gefahr, dass ich meine Daten an andere weitergeben wollte. Es würde viel Mühe kosten, ihnen die Verwendung dieser Daten zu erklären. Die Binärdateien, die die Objekte enthielten, hatten beispielsweise eine eigene interne Struktur, die nur in einer README -Datei in einem Repository und auf einem Block in meinem Büro vorhanden war. Wer eine meiner kombinierten Objekt-Binärdateien lesen wollte, müsste den Byte-Offset, den Typ und den Endwert jedes Metadateneintrags im Header sowie den Byte-Offset jedes Objekts in der Datei kennen. Wenn sie es nicht taten, wäre die Akte für sie ein Schwindel.

Die Art und Weise, wie ich Daten gruppierte und komprimierte, war ebenfalls problematisch. Sagen wir, ich wollte ein Objekt finden. Ich müsste die .tar.gz-Datei suchen, in der es sich befand, den gesamten Inhalt des Archivs in einen temporären Ordner entpacken, zu der Gruppe navigieren, an der ich interessiert war, und das Objekt mit meiner eigenen benutzerdefinierten API abrufen, um meine Binärdateien zu lesen . Nachdem ich fertig war, würde ich die temporär entpackten Dateien löschen. Es war keine elegante Lösung.

Zu diesem Zeitpunkt entschied ich mich für ein Standardformat. HDF5 war aus mehreren Gründen attraktiv. Erstens könnte ich die Gesamtorganisation meiner Daten in Gruppen, Objekt-Datasets und Zusammenfassungs-Datasets beibehalten. Zweitens könnte ich meine benutzerdefinierte binäre Datei-E/A-API aufgeben und einfach ein multidimensionales Array-Dataset verwenden, um alle Objekte in einer Gruppe zu speichern. Ich könnte sogar Arrays mit komplizierteren Datentypen erstellen, wie Arrays von C-Strukturen, ohne die Byte-Offsets jedes Eintrags akribisch dokumentieren zu müssen. Als nächstes hat HDF5 eine komprimierte Komprimierung, die für den Endbenutzer der Daten völlig transparent sein kann. Da die Komprimierung groß ist, denke ich, wenn Benutzer einzelne Objekte betrachten möchten, kann jedes Objekt in einem separaten Block komprimiert werden, sodass nur der Teil der Datenmenge dekomprimiert werden muss, an dem der Benutzer interessiert ist. Die Chunk-Komprimierung ist eine äußerst leistungsfähige Funktion.

Schließlich kann ich jetzt nur noch eine einzige Datei an jemanden weitergeben, ohne viel darüber zu erklären, wie sie intern organisiert ist. Der Endbenutzer kann die Datei in Python, C, Fortran oder h5ls in der Befehlszeile oder in der GUI HDFView lesen und sehen, was darin enthalten ist. Das war mit meinem benutzerdefinierten Binärformat nicht möglich, ganz zu schweigen von meinen .tar.gz-Sammlungen.

Natürlich können Sie alles, was Sie mit HDF5 tun können, mit Ordnern, ASCII und benutzerdefinierten Binärdateien replizieren. Das habe ich ursprünglich getan, aber es bereitete mir große Kopfschmerzen, und am Ende erledigte HDF5 alles, was ich auf effiziente und tragbare Weise zusammenputzte.

63
Thucydides411

Vielen Dank, dass Sie diese interessante Frage gestellt haben. Ist ein Ordner mit Dateien portabel, weil ich auf einem Mac ein Verzeichnis auf einen Stick kopieren kann und dann dasselbe Verzeichnis und dieselben Dateien auf einem PC sehen kann? Ich bin damit einverstanden, dass die Dateiverzeichnisstruktur portabel ist, dank der Leute, die Betriebssysteme schreiben. Dies hängt jedoch nicht von den Daten in den portierbaren Dateien ab. Wenn es sich bei den Dateien in diesem Verzeichnis um PDF-Dateien handelt, sind sie portabel, da es Tools gibt, die PDF-Dateien in mehreren Betriebssystemen lesen und verstehen (dank Adobe). Wenn es sich bei diesen Dateien um reine wissenschaftliche Daten handelt (in ASCII oder binär), sind sie überhaupt nicht portabel. Die Datei ASCII würde wie ein Haufen von Zeichen aussehen, und die Binärdatei würde wie Kauderwelsch aussehen. Wenn es sich um XML- oder Json-Dateien handelt, sind sie lesbar, da Json ASCII ist. Die enthaltenen Informationen sind jedoch wahrscheinlich nicht portierbar, da die Bedeutung der XML/Json-Tags für jemanden, der die Datei nicht geschrieben hat, möglicherweise nicht klar ist. Dies ist ein wichtiger Punkt, die Zeichen in einer ASCII -Datei sind portabel, aber die Informationen, die sie repräsentieren, sind nicht.

HDF5-Daten sind ebenso wie das PDF-Format portabel, da es in vielen Betriebssystemen Tools gibt, die die Daten in HDF5-Dateien lesen können (genau wie PDF-Reader siehe http://www.hdfgroup.org/products/hdf5_tools/index) .html ). Es gibt auch Bibliotheken in vielen Sprachen, mit denen die Daten gelesen und auf eine für den Benutzer sinnvolle Weise dargestellt werden können - wie es Adobe Reader tut. Es gibt Hunderte von Gruppen in der HDF5-Community, die dasselbe für ihre Benutzer tun (siehe http://www.hdfgroup.org/HDF5/users5.html ).

Auch hier wurde die Komprimierung diskutiert. Das Wichtigste beim Komprimieren in HDF5-Dateien ist, dass Objekte unabhängig voneinander komprimiert werden und nur die Objekte, die Sie benötigen, bei der Ausgabe dekomprimiert werden. Dies ist eindeutig effizienter als das Komprimieren der gesamten Datei und das Dekomprimieren der gesamten Datei, um sie lesen zu können.

Der andere wichtige Aspekt ist, dass HDF5-Dateien selbstbeschreibend sind. Benutzer, die Dateien schreiben, können Informationen hinzufügen, die Benutzern und Tools helfen, den Inhalt der Datei zu ermitteln. Was sind die Variablen, was sind ihre Typen, welche Software hat sie geschrieben, welche Instrumente wurden gesammelt usw. Es klingt, als könnte das Werkzeug, an dem Sie arbeiten, Metadaten für Dateien lesen. Attribute in einer HDF5-Datei können an jedes Objekt in der Datei angehängt werden - sie sind nicht nur Informationen auf Dateiebene. Das ist riesig. Diese Attribute können natürlich mit Tools gelesen werden, die in vielen Sprachen und vielen Betriebssystemen geschrieben sind.

10
Ted Habermann

Für mich können Ordner und Dateien nur dann in HDF5 verglichen werden, wenn wissenschaftliche Daten relevant sind. Die wichtigsten Daten sind Arrays, die durch einen Satz von Metadaten beschrieben werden.

Im allgemeinen Kontext geht es Marcus gut, wenn er behauptet, Ordner mit Dateien seien weitaus portabler als alle HDF5. Ich füge hinzu, dass in einem allgemeinen Kontext ein Ordner mit einer Datei am weitesten zugänglich ist als eine HDF5-Datei. Die offensichtliche Herausforderung besteht darin, dass bei "normalen" Ordnern und Dateien keine zusätzliche API für den Zugriff auf Daten erforderlich ist. Das ist mit HDF5 einfach unmöglich, da Daten und Metadaten in derselben Datei gespeichert werden.

Stellen Sie sich einen Moment vor, um Ihre PDF-Datei zu lesen, benötigen Sie einen neuen PDF-Reader, der HDF5 versteht. Stellen Sie sich vor, Sie brauchen einen Musik-Player, der HDF5 decodieren kann, um Ihre Musik abzuspielen? Um Ihr Python-Skript auszuführen, muss der Python-Interpreter zuerst den HDF5-Code decodieren. Oder die Summe, um Ihren Python-Interpreter zu starten, muss Ihr Betriebssystem den HDF5 dekodieren? usw. Ich werde diese Antwort einfach nicht schreiben können, da mein Betriebssystem meinen Webbrowser nicht starten konnte, der seine internen Dateien nicht lesen kann, weil ich zuvor alles in HDF5 umgewandelt habe (vielleicht ein großer HDF5 für alles auf meiner Festplatte).

Das Speichern von Metadaten in separaten Dateien hat den großen Vorteil, dass sie mit der großen Menge an Datendateien und Software, die bereits ohne zusätzliche Kopfschmerzen vorhanden ist, gut funktioniert.

Ich hoffe das hilft.

2
innoSPG

Ein Spiel, bei dem Sie viele Ressourcen in den Speicher laden müssen, wäre ein Szenario, in dem ein HDF5 möglicherweise besser ist als ein Ordner mit Dateien. Das Laden von Daten aus Dateien hat Kosten als Suchzeit, die Zeit, die zum Öffnen jeder Datei benötigt wird, und das Lesen von Daten aus der Datei in den Speicher. Diese Vorgänge können beim Lesen von Daten von einer DVD oder Blu-ray noch langsamer sein. Das Öffnen einer einzelnen Datei kann diese Kosten drastisch reduzieren.

1
eap

Ich denke, der Hauptvorteil ist Portabilität .

HDF5 speichert Informationen über Ihre Datasets wie Größe, Typ und Endwert von Ganzzahlen und Fließkommazahlen. Sie können also eine hdf5-Datei verschieben und deren Inhalt lesen, auch wenn sie auf einem Computer mit einer anderen Architektur erstellt wurde.

Sie können auch beliebige Metadaten an Gruppen und Datensätze anhängen. Sie können dies auch mit Dateien und Ordnern tun, wenn Ihr Dateisystem erweiterte Attribute unterstützt.

Eine hdf5-Datei ist eine einzelne Datei, die manchmal praktischer sein kann, als Zip-/tar-Ordner und -Dateien verwenden zu müssen. Dies hat auch einen großen Nachteil: Wenn Sie ein Dataset löschen, können Sie den Speicherplatz nicht wiederherstellen, ohne eine neue Datei zu erstellen.

Im Allgemeinen eignet sich HDF5 gut zum Speichern großer Zahlenfelder, typischerweise wissenschaftlicher Datensätze.

1
Simon

Ich bewerte gerade HDF5, also hatte ich die gleiche Frage.

Dieser Artikel - Weg von HDF5 - stellt die gleiche Frage. Der Artikel bringt einige gute Punkte dazu, dass es nur eine einzige Implementierung der HDF5-Bibliothek gibt, die unter relativ undurchsichtigen Umständen von modernen Open-Source-Standards entwickelt wird.

Wie Sie dem Titel entnehmen können, haben die Autoren beschlossen, von HDF5 zu einer Dateisystemhierarchie von Binärdateien überzugehen, die Arrays mit Metadaten in JSON-Dateien enthalten. Dies war trotz einer erheblichen Investition in HDF5, die durch Korruption der Daten und Leistungsprobleme die Finger verbrannt hatte.

1
Rob Smallshire

Ja, der Hauptvorteil ist, dass HDF5 portabel ist. Auf HDF5-Dateien kann von einem Host aus anderen Programmier-/Dolmetschersprachen wie Python (auf dem Ihre API basiert), MATLAB, Fortran und C zugegriffen werden. Wie von Simon vorgeschlagen, wird HDF5 in der wissenschaftlichen Gemeinschaft umfangreich zum Speichern großer Datensätze verwendet. Nach meiner Erfahrung finde ich die Möglichkeit, nur bestimmte Datensätze (und Regionen) abzurufen. Darüber hinaus ist der Aufbau der HDF5-Bibliothek für parallele E/A sehr vorteilhaft für die spätere Nachbearbeitung von Rohdaten. 

Da die Datei auch selbstbeschreibend ist, kann sie nicht nur Rohdaten speichern, sondern auch eine Beschreibung dieser Daten, wie z. B. die Arraygröße, den Arraynamen, die Einheiten und einen Host mit zusätzlichen Metadaten.

Hoffe das hilft.

0
paulgarias

Ein zu berücksichtigender Faktor ist die Leistung des Festplattenzugriffs. Mit hd5f wird alles in einem kontinuierlichen Bereich der Festplatte gespeichert, wodurch das Lesen von Daten mit weniger Festplattensuche und -rotation schneller erfolgt. Bei der Verwendung von Dateisystemen zum Organisieren von Daten kann es jedoch vorkommen, dass aus vielen kleinen Dateien gelesen wird. Daher ist mehr Festplattenzugriff erforderlich. 

0
vuamitom

HDF5 ist letztendlich ein Format zum Speichern von Zahlen, das für große Datensätze optimiert ist. Die Hauptstärken sind die Unterstützung für die Komprimierung (die das Lesen und Schreiben von Daten in vielen Fällen beschleunigen kann) und die schnellen Abfragen im Kernel (Abrufen von Daten, die bestimmte Bedingungen erfüllen, z. B. alle Druckwerte, wenn die Temperatur über 30 lag.) C).

Die Tatsache, dass Sie mehrere Datensätze in derselben Datei kombinieren können, ist nur eine Annehmlichkeit. Beispielsweise könnten Sie mehrere Gruppen haben, die verschiedenen Wetterstationen entsprechen, und jede Gruppe besteht aus mehreren Datentabellen. Für jede Gruppe haben Sie eine Reihe von Attributen, die die Details der Instrumente beschreiben, und jede Tabelle enthält die einzelnen Einstellungen. Sie können für jeden Datenblock eine h5-Datei mit einem Attribut an der entsprechenden Stelle haben, die Ihnen dieselbe Funktionalität bietet. Mit HDF5 können Sie die Datei jetzt für eine optimierte Abfrage neu packen, das Ganze etwas komprimieren und Ihre Informationen in einer rasenden Geschwindigkeit abrufen. Wenn Sie mehrere Dateien haben, wird jede einzeln komprimiert, und das Betriebssystem entscheidet über das Layout auf der Festplatte. Dies ist möglicherweise nicht das optimale.

Eine letzte Sache, die HDF5 erlaubt, ist das Laden einer Datei (oder eines Teils) in den Speicher, die dieselbe API wie auf der Festplatte verfügbar macht. So können Sie beispielsweise je nach Größe der Daten und verfügbarem RAM das eine oder andere Backend verwenden. In Ihrem Fall wäre das gleichbedeutend mit dem Kopieren der relevanten Informationen nach/dev/shm in Linux, und Sie sind dafür verantwortlich, dass alle Änderungen auf die Festplatte übertragen werden.

0
Davidmh