Quelle est la différence entre HDF5 et un dossier contenant des fichiers?
Je travaille sur un projet open source traitant de l'ajout de métadonnées à des dossiers. L'API fournie (Python) vous permet de parcourir et d'accéder aux métadonnées comme s'il s'agissait d'un autre dossier. Parce que c'est juste un autre dossier.
\folder\.meta\folder\somedata.json
Puis je suis tombé sur HDF5 et sa dérivation Alembic .
Lecture sur HDF5 dans le livre Python et HDF5 Je recherchais les avantages de son utilisation par rapport à l’utilisation de fichiers dans des dossiers, mais la plupart de ce que j’ai rencontré me parlait des avantages d’un format de fichier hiérarchique simplicité dans l'ajout de données via son API:
>>> import h5py
>>> f = h5py.File("weather.hdf5")
>>> f["/15/temperature"] = 21
Ou sa capacité à lire uniquement certaines parties de celui-ci sur demande (par exemple, un accès aléatoire) et l'exécution en parallèle d'un seul fichier HDF5 (par exemple, pour le multitraitement)
Vous pouvez monter des fichiers HDF5, https://github.com/zjttoefs/hdfuse5
Il possède même un concept de base solide et simple, Groupes et Jeux de données, qui se lit comme suit sur wiki:
- Les jeux de données, qui sont des tableaux multidimensionnels de type homogène
- Les groupes, qui sont des structures de conteneur pouvant contenir des jeux de données et D'autres groupes
Remplacez groupe de données par fichier et groupe par dossier. L'ensemble des fonctionnalités me semble être identique à ce que les fichiers des dossiers sont déjà totalement capables de faire.
Pour chaque avantage que j'ai rencontré, aucun ne s'est distingué comme étant exclusif à HDF5.
Ma question est donc la suivante: si je vous donnais un fichier HDF5 et un dossier contenant des fichiers, les deux avec un contenu identique, dans quel scénario HDF5 serait-il plus adapté?
Modifier:
Après avoir obtenu quelques réponses sur la portabilité de HDF5.
Cela semble beau et tout, mais je n'ai toujours pas donné d'exemple, un scénario dans lequel un HDF5 créerait un dossier contenant des fichiers. Pourquoi quelqu'un envisagerait-il d'utiliser HDF5 lorsqu'un dossier est lisible sur n'importe quel ordinateur? Tout système de fichiers, sur un réseau, supporte les "E/S parallèles" et est lisible par l'homme sans interprète HDF5.
J'irais même jusqu'à dire qu'un dossier avec des fichiers est beaucoup plus portable que n'importe quel HDF5.
Edit 2:
Thucydides411 vient de donner un exemple de scénario dans lequel la portabilité est importante . https://stackoverflow.com/a/28512028/478949
Je pense que ce que je retiens des réponses de ce fil de discussion est que HDF5 convient parfaitement lorsque vous avez besoin de la structure organisationnelle des fichiers et des dossiers, comme dans l'exemple de scénario ci-dessus, avec beaucoup (millions) de petits (~ 1 octet). structures de données; comme des nombres individuels ou des chaînes. Qu'il compense ce qui manque aux systèmes de fichiers en fournissant un "système de sous-fichiers" favorisant les plus petits et les plus nombreux, plutôt que les plus petits et les plus grands.
En infographie, nous l’utilisons pour stocker des modèles géométriques et des données arbitraires sur des sommets individuels, ce qui semble bien correspondre à son utilisation dans la communauté scientifique.
En tant que concepteur d’un projet scientifique qui est passé de l’utilisation de dossiers de fichiers à HDF5, je pense pouvoir éclaircir les avantages de HDF5.
Lorsque j'ai commencé mon projet, je travaillais sur de petits jeux de données de test et produisais de petites quantités de sortie, allant de quelques kilo-octets. J'ai commencé avec le format de données le plus simple, des tableaux codés en ASCII. Pour chaque objet que j'ai traité, j'ai produit sur la table ASCII.
J'ai commencé à appliquer mon code à des groupes d'objets, ce qui impliquait l'écriture de plusieurs tables ASCII à la fin de chaque exécution, ainsi qu'une table ASCII supplémentaire contenant la sortie relative au groupe entier. Pour chaque groupe, j'avais maintenant un dossier qui ressemblait à:
+ group
| |-- object 1
| |-- object 2
| |-- ...
| |-- object N
| |-- summary
À ce stade, j'ai commencé à courir dans mes premières difficultés. Les fichiers ASCII sont très lents à lire et à écrire, et ils n'emballent pas les informations numériques de manière très efficace, car chaque chiffre nécessite l'encodage d'un octet complet, plutôt que d'environ 3,3 bits. Je suis donc passé à l'écriture de chaque objet en tant que fichier binaire personnalisé, ce qui a accéléré les E/S et réduit la taille du fichier.
Alors que je développais le traitement d'un grand nombre de groupes (des dizaines de milliers à des millions), je me suis soudainement retrouvé face à un très grand nombre de fichiers et de dossiers. Avoir trop de petits fichiers peut être un problème pour de nombreux systèmes de fichiers (beaucoup de systèmes de fichiers sont limités en nombre de fichiers qu'ils peuvent stocker, quel que soit l'espace disque disponible). J'ai également commencé à constater que, lorsque j'essayais de post-traiter l'ensemble de mes données, l'entrée/sortie disque permettant de lire de nombreux petits fichiers commençait à prendre un temps considérable. J'ai essayé de résoudre ces problèmes en consolidant mes fichiers, de sorte que je ne produisais que deux fichiers par groupe:
+ group 1
| |-- objects
| |-- summary
+ group 2
| |-- objects
| |-- summary
...
Je voulais aussi compresser mes données, alors j'ai commencé à créer des fichiers .tar.gz pour des collections de groupes.
À ce stade, tout mon ensemble de données devenait très encombrant, et il y avait un risque que si je voulais transmettre mes données à quelqu'un d'autre, il faudrait beaucoup d'efforts pour lui expliquer comment l'utiliser. Les fichiers binaires contenant les objets, par exemple, avaient leur propre structure interne qui n'existait que dans un fichier README dans un référentiel et sur un bloc de papier dans mon bureau. Quiconque souhaitait lire l'un de mes fichiers binaires d'objet combiné devait connaître le décalage d'octet, le type et le caractère final de chaque entrée de métadonnées dans l'en-tête, ainsi que le décalage d'octet de chaque objet du fichier. S'ils ne le faisaient pas, le fichier serait un charabia pour eux.
La façon dont je regroupais et compressais les données posait également des problèmes. Disons que je voulais trouver un objet. Je devrais localiser le fichier .tar.gz dans lequel il se trouvait, décompresser l'intégralité du contenu de l'archive dans un dossier temporaire, accéder au groupe qui m'intéressait et récupérer l'objet avec ma propre API personnalisée pour lire mes fichiers binaires. . Après avoir terminé, je supprimerais les fichiers décompressés temporairement. Ce n'était pas une solution élégante.
À ce stade, j'ai décidé de passer à un format standard. HDF5 était attrayant pour un certain nombre de raisons. Tout d'abord, je pourrais conserver l'organisation globale de mes données dans des groupes, des jeux de données d'objet et des jeux de données récapitulatifs. Deuxièmement, je pourrais abandonner mon API d'E/S de fichier binaire personnalisée et utiliser simplement un jeu de données multidimensionnel pour stocker tous les objets d'un groupe. Je pouvais même créer des tableaux de types de données plus complexes, tels que des tableaux de structures C, sans avoir à documenter méticuleusement les décalages d'octets de chaque entrée. Ensuite, HDF5 a une compression fragmentée qui peut être complètement transparente pour l'utilisateur final des données. Étant donné que la compression est fragmentée, si je pense que les utilisateurs veulent examiner des objets individuels, je peux faire en sorte que chaque objet soit compressé dans un fragment séparé, de sorte que seule la partie de l'ensemble de données qui intéresse l'utilisateur doive être décompressée. La compression en bloc est une fonctionnalité extrêmement puissante.
Enfin, je peux simplement donner un seul fichier à quelqu'un maintenant, sans devoir expliquer en détail comment il est organisé en interne. L'utilisateur final peut lire le fichier en Python, C, Fortran ou h5ls sur la ligne de commande ou l'interface graphique HDFView, et voir ce qu'il contient. Cela n’était pas possible avec mon format binaire personnalisé, sans parler de mes collections .tar.gz.
Bien sûr, il est possible de répliquer tout ce que vous pouvez faire avec HDF5 avec des dossiers, ASCII et des fichiers binaires personnalisés. C’est ce que j’ai fait à l’origine, mais c’est devenu un mal de tête majeur, et à la fin, HDF5 a fait tout ce que je klugais ensemble de manière efficace et portable.
Merci d'avoir posé cette question intéressante. Un dossier avec des fichiers est-il portable parce que je peux copier un répertoire sur une clé sur un Mac, puis voir le même répertoire et les mêmes fichiers sur un PC? Je conviens que la structure des répertoires de fichiers est portable, grâce aux personnes qui écrivent des systèmes d'exploitation, mais cela n'a aucun rapport avec les données contenues dans les fichiers portables. Maintenant, si les fichiers de ce répertoire sont des fichiers PDF, ils sont portables car il existe des outils qui lisent et donnent un sens aux fichiers PDF dans plusieurs systèmes d'exploitation (grâce à Adobe). Mais, si ces fichiers sont des données scientifiques brutes (peu importe sous la forme ASCII ou que les fichiers binaires), ils ne sont pas du tout portables. Le fichier ASCII ressemble à un groupe de caractères et le fichier binaire à un charabia. S'ils étaient au format XML ou json, ils seraient lisibles, car json est en ASCII, mais les informations qu'ils contiennent ne seraient probablement pas portables, car la signification des balises XML/json peut ne pas être claire pour quelqu'un qui n'a pas écrit le fichier. C'est un point important, les caractères d'un fichier ASCII sont portables, mais les informations qu'ils représentent ne le sont pas.
Les données HDF5 sont portables, tout comme le pdf, car de nombreux systèmes d'exploitation permettent de lire les données dans des fichiers HDF5 (tout comme les lecteurs de pdf, voir http://www.hdfgroup.org/products/hdf5_tools/index .html ). Il existe également des bibliothèques dans de nombreuses langues qui peuvent être utilisées pour lire les données et les présenter d’une manière qui ait un sens pour les utilisateurs - c’est ce que fait Adobe Reader. Des centaines de groupes de la communauté HDF5 font la même chose pour leurs utilisateurs (voir http://www.hdfgroup.org/HDF5/users5.html ).
Il a également été question ici de compression. La chose importante à propos de la compression dans les fichiers HDF5 est que les objets sont compressés indépendamment et que seuls les objets dont vous avez besoin sont décompressés en sortie. Ceci est clairement plus efficace que de compresser l’ensemble du fichier et de le décompresser pour le lire.
L'autre élément essentiel est que les fichiers HDF5 se décrivent d'eux-mêmes. Ainsi, les personnes qui les écrivent peuvent ajouter des informations qui aident les utilisateurs et les outils à savoir ce qu'il contient. Quelles sont les variables, quels sont leurs types, quels logiciels les ont écrites, quels instruments les ont collectées, etc. On dirait que l'outil sur lequel vous travaillez peut lire les métadonnées des fichiers. Les attributs d’un fichier HDF5 peuvent être attachés à n’importe quel objet du fichier - il ne s’agit pas uniquement d’informations au niveau fichier. C'est énorme. Et, bien sûr, ces attributs peuvent être lus à l'aide d'outils écrits dans de nombreux langages et systèmes d'exploitation.
Pour moi, nous ne pouvons comparer dossier avec fichiers à HDF5 que dans le contexte pertinent des données scientifiques, où les données les plus importantes sont des tableaux décrits par un ensemble de métadonnées.
Dans le contexte général, Marcus va bien quand il affirme que le dossier avec les fichiers est beaucoup plus portable que n'importe quel HDF5. J'ajouterai que dans un contexte général, un dossier avec fichier est de loin le plus accessible qu'un fichier HDF5. Le défi évident est que, avec les dossiers et les fichiers "normaux", aucune API supplémentaire n'est nécessaire pour accéder aux données. Cela est tout simplement impossible avec HDF5 qui conserve les données et les métadonnées dans le même fichier.
Imaginez un instant, pour lire votre fichier pdf, vous avez besoin d’un nouveau lecteur de pdf qui comprend le format HDF5? Imaginez, pour jouer votre musique, vous avez besoin d’un lecteur de musique capable de décoder HDF5? pour exécuter votre script python, l'interpréteur python doit d'abord décoder le HDF5? Ou le total, pour lancer votre interpréteur python, votre système d'exploitation doit-il décoder le HDF5? etc. Je n'aurai tout simplement pas pu écrire cette réponse, car mon système d'exploitation n'aura pas été en mesure de lancer mon navigateur Web, il ne sera pas capable de lire ses fichiers internes car j'avais précédemment converti le tout en HDF5 (peut-être un grand HDF5 pour tout dans mon disque dur).
Stocker des métadonnées dans un fichier séparé présente l’énorme avantage de fonctionner avec l’énorme quantité de fichiers de données et de logiciels existants sans aucun problème supplémentaire.
J'espère que ça aide.
Un jeu dans lequel vous devez charger beaucoup de ressources dans la mémoire serait un scénario dans lequel un HDF5 peut être meilleur qu'un dossier avec des fichiers. Le chargement de données à partir de fichiers a un coût en temps de recherche, en temps nécessaire pour ouvrir chaque fichier et pour lire les données du fichier en mémoire. Ces opérations peuvent être encore plus lentes lors de la lecture de données d'un DVD ou d'un Blu-ray. Ouvrir un seul fichier peut réduire considérablement ces coûts.
Je pense que le principal avantage est la portabilité .
HDF5 stocke des informations sur vos jeux de données, telles que la taille, le type et l’endianité des nombres entiers et des nombres à virgule flottante, ce qui signifie que vous pouvez déplacer un fichier hdf5 et lire son contenu même s’il a été créé sur une machine ayant une architecture différente.
Vous pouvez également attacher des métadonnées arbitraires à des groupes et à des jeux de données. On peut soutenir que vous pouvez également le faire avec des fichiers et des dossiers si votre système de fichiers prend en charge les attributs étendus.
Un fichier hdf5 est un fichier unique qui peut parfois être plus pratique que de devoir zipper des dossiers et des fichiers. Cela présente également un inconvénient majeur: si vous supprimez un jeu de données, vous ne pourrez pas récupérer l'espace sans créer un nouveau fichier.
En règle générale, HDF5 est bien adapté pour stocker de grands tableaux de nombres, généralement des ensembles de données scientifiques.
J'évalue actuellement HDF5, donc la même question.
Cet article - S'éloigner de HDF5 - pose à peu près la même question. L'article soulève quelques points positifs sur le fait qu'il n'existe qu'une seule implémentation de la bibliothèque HDF5 qui est développée dans des conditions relativement opaques par les normes modernes du code source ouvert.
Comme vous pouvez le constater d'après le titre, les auteurs ont décidé de s'éloigner de HDF5 pour adopter une hiérarchie de système de fichiers composée de fichiers binaires contenant des tableaux contenant des métadonnées dans des fichiers JSON. Cela malgré un investissement important dans HDF5, des doigts brûlés par la corruption des données et des problèmes de performances.
Oui, le principal avantage est que HDF5 est portable. Un hôte d'autres langages de programmation/interprétation, tels que Python (sur lequel votre API est construite), MATLAB, Fortran et C, peut accéder aux fichiers HDF5. D'après mon expérience, la possibilité de récupérer uniquement certains jeux de données (et régions) est utile. De plus, la construction de la bibliothèque HDF5 pour les E/S parallèles est très avantageuse pour le post-traitement ultérieur des données brutes.
Comme le fichier est également auto-descriptif, il est capable de stocker non seulement des données brutes, mais également une description de ces données, telles que la taille, le nom du tableau, les unités et un hôte de métadonnées supplémentaires.
J'espère que cela t'aides.
Un facteur à prendre en compte est la performance de l'accès au disque. Avec hd5f, tout est stocké dans une zone continue du disque, ce qui accélère la lecture des données avec moins de recherche et de rotation du disque. D'autre part, l'utilisation du système de fichiers pour organiser les données peut impliquer la lecture de nombreux petits fichiers, ce qui nécessite davantage d'accès au disque.
HDF5 est finalement un format pour stocker des nombres, optimisé pour les grands ensembles de données. Les principaux atouts sont la prise en charge de la compression (qui permet de lire et d’écrire des données plus rapidement dans de nombreuses circonstances) et les requêtes rapides dans le noyau (extraction de données remplissant certaines conditions, par exemple toutes les valeurs de pression lorsque la température dépasse 30 C).
Le fait que vous puissiez combiner plusieurs jeux de données dans le même fichier n’est qu’une commodité. Par exemple, vous pouvez avoir plusieurs groupes correspondant à différentes stations météorologiques, chaque groupe comprenant plusieurs tables de données. Pour chaque groupe, vous disposez d'un ensemble d'attributs décrivant les détails des instruments, et de chaque tableau, les paramètres individuels. Vous pouvez avoir un fichier h5 pour chaque bloc de données, avec un attribut à la place correspondante et cela vous donnerait les mêmes fonctionnalités. Mais maintenant, ce que vous pouvez faire avec HDF5 est de remballer le fichier pour une interrogation optimisée, de compresser légèrement le tout et de récupérer vos informations à une vitesse fulgurante. Si vous avez plusieurs fichiers, chacun d’entre eux sera compressé individuellement et le système d’exploitation décidera de la disposition sur le disque, ce qui risque de ne pas être optimal.
Une dernière chose que HDF5 vous permet est de charger un fichier (ou un morceau) en mémoire exposant la même API que sur le disque. Ainsi, par exemple, vous pouvez utiliser l'un ou l'autre backend en fonction de la taille des données et de la RAM disponible. Dans votre cas, cela équivaudrait à copier les informations pertinentes vers/dev/shm sous Linux et vous seriez responsable de la validation sur disque de toute modification.