todos - operaciones con archivos python

¿En qué se diferencia HDF5 de una carpeta con archivos? (8)

Actualmente estoy evaluando HDF5 así que tenía la misma pregunta.

Este artículo, alejándose de HDF5 , hace más o menos la misma pregunta. El artículo plantea algunos buenos puntos sobre el hecho de que solo hay una implementación única de la biblioteca HDF5 que se desarrolla en circunstancias relativamente opacas según los estándares modernos de código abierto.

Como se puede ver en el título, los autores decidieron alejarse de HDF5, a una jerarquía del sistema de archivos binarios que contienen matrices con metadatos en archivos JSON. Esto a pesar de haber hecho una inversión significativa en HDF5, después de haber tenido sus dedos quemados por la corrupción de datos y problemas de rendimiento.

Estoy trabajando en un proyecto de código abierto que trata de agregar metadatos a las carpetas. La API proporcionada (Python) le permite explorar y acceder a los metadatos como si fuera solo otra carpeta. Porque es solo otra carpeta.

/folder/.meta/folder/somedata.json

Luego me encontré con HDF5 y su derivación Alembic .

Leyendo en HDF5 en el libro Python y HDF5 estaba buscando beneficios para usarlo en comparación con el uso de archivos en carpetas, pero la mayoría de lo que encontré hablaba sobre los beneficios de un formato de archivo jerárquico en términos de su simplicidad al agregar datos a través de su API:

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

O su capacidad para leer solo ciertas partes de la misma a petición (por ejemplo, acceso aleatorio), y la ejecución en paralelo de un solo archivo HDF5 (por ejemplo, para multiprocesamiento)

Puede montar archivos HDF5, https://github.com/zjttoefs/hdfuse5

Incluso cuenta con un concepto de base fuerte y sencillo de Grupos y Conjuntos de datos que de las lecturas de wiki:

Conjuntos de datos, que son matrices multidimensionales de un tipo homogéneo
Grupos, que son estructuras de contenedores que pueden contener conjuntos de datos y otros grupos

Reemplazar el conjunto de datos con archivo y agrupar con la carpeta y todo el conjunto de características me suena como lo que los archivos en las carpetas ya son completamente capaces de hacer.

Por cada beneficio que encontré, ninguno se destacó como exclusivo de HDF5.

Entonces mi pregunta es, si tuviera que darle un archivo HDF5 y una carpeta con archivos, ambos con contenido idéntico, ¿en qué escenario sería mejor HDF5?

Editar:

Habiendo recibido algunas respuestas sobre la portabilidad de HDF5.

Suena adorable y todo, pero todavía no me han dado un ejemplo, un escenario en el que un HDF5 supere una carpeta con archivos. ¿Por qué alguien consideraría usar HDF5 cuando una carpeta es legible en cualquier computadora, cualquier sistema de archivos, a través de una red, compatible con "E / S paralelas", es legible para humanos sin un intérprete HDF5.

Me atrevería a decir que una carpeta con archivos es mucho más portátil que cualquier HDF5.

Editar 2:

Thucydides411 acaba de dar un ejemplo de un escenario donde la portabilidad importa. https://stackoverflow.com/a/28512028/478949

Creo que lo que restaré de las respuestas en este hilo es que HDF5 es ideal para cuando se necesita la estructura organizativa de archivos y carpetas, como en el escenario de ejemplo anterior, con lotes (millones) pequeños (~ 1 byte) estructuras de datos; como números individuales o cadenas. Que compensa lo que los sistemas de archivos carecen al proporcionar un "sub-sistema de archivos" que favorece a los pequeños y a muchos en lugar de a pocos y grandes.

En gráficos por computadora, lo usamos para almacenar modelos geométricos y datos arbitrarios sobre vértices individuales que parecen alinearse bastante bien con su uso en la comunidad científica.

Como alguien que desarrolló un proyecto científico que pasó de utilizar carpetas de archivos a HDF5, creo que puedo arrojar algo de luz sobre las ventajas de HDF5.

Cuando comencé mi proyecto, estaba operando en pequeños conjuntos de datos de prueba, y produciendo pequeñas cantidades de salida, en el rango de kilobytes. Comencé con el formato de datos más fácil, tablas codificadas como ASCII. Para cada objeto que procesé, produje en la tabla ASCII.

Empecé a aplicar mi código a grupos de objetos, lo que significaba escribir varias tablas ASCII al final de cada ejecución, junto con una tabla ASCII adicional que contenía resultados relacionados con todo el grupo. Para cada grupo, ahora tenía una carpeta que se veía así:

En este punto, comencé a encontrarme con mis primeras dificultades. Los archivos ASCII tardan mucho en leer y escribir, y no empaquetan la información numérica de manera muy eficiente, ya que cada dígito toma un byte completo para codificar, en lugar de ~ 3.3 bits. Así que cambié a la escritura de cada objeto como un archivo binario personalizado, lo que aceleró las E / S y disminuyó el tamaño del archivo.

A medida que amplié el procesamiento de grandes cantidades (decenas de miles a millones) de grupos, de repente me encontré lidiando con una gran cantidad de archivos y carpetas. Tener demasiados archivos pequeños puede ser un problema para muchos sistemas de archivos (muchos sistemas de archivos están limitados en la cantidad de archivos que pueden almacenar, independientemente de la cantidad de espacio de disco que haya). También comencé a encontrar que cuando intentaba hacer un postproceso en todo mi conjunto de datos, la E / S de disco para leer muchos archivos pequeños estaba comenzando a tomar una cantidad apreciable de tiempo. Traté de resolver estos problemas consolidando mis archivos, de modo que solo produje dos archivos para cada grupo:

También quería comprimir mis datos, así que comencé a crear archivos .tar.gz para colecciones de grupos.

En este punto, todo mi esquema de datos se estaba volviendo muy engorroso, y existía el riesgo de que si quería entregar mis datos a otra persona, sería un gran esfuerzo explicarles cómo usarlo. Los archivos binarios que contenían los objetos, por ejemplo, tenían su propia estructura interna que existía solo en un archivo README en un repositorio y en un bloc de notas en mi oficina. Quien quiera leer uno de mis archivos binarios de objetos combinados debería conocer el desplazamiento de bytes, el tipo y la endianidad de cada entrada de metadatos en el encabezado y el desplazamiento de bytes de cada objeto en el archivo. Si no lo hicieran, el archivo sería un galimatías para ellos.

La forma en que estaba agrupando y comprimiendo datos también planteaba problemas. Digamos que quería encontrar un objeto. Tendría que ubicar el archivo .tar.gz en el que estaba, descomprimir todo el contenido del archivo en una carpeta temporal, navegar al grupo que me interesaba y recuperar el objeto con mi propia API personalizada para leer mis archivos binarios. . Después de terminar, borraba los archivos descomprimidos temporalmente. No fue una solución elegante.

En este punto, decidí cambiar a un formato estándar. HDF5 era atractivo por varias razones. En primer lugar, podría mantener la organización general de mis datos en grupos, conjuntos de datos de objetos y conjuntos de datos de resumen. En segundo lugar, podría deshacerme de mi API de E / S de archivos binarios personalizada, y simplemente usar un conjunto de datos de matriz multidimensional para almacenar todos los objetos en un grupo. Incluso podría crear matrices de tipos de datos más complicados, como matrices de estructuras C , sin tener que documentar meticulosamente los desplazamientos de bytes de cada entrada. A continuación, HDF5 tiene compresión fragmentada que puede ser completamente transparente para el usuario final de los datos. Debido a que la compresión está fragmentada, si creo que los usuarios van a querer ver objetos individuales, puedo hacer que cada objeto se comprima en un fragmento por separado, de modo que solo se debe descomprimir la parte del conjunto de datos que le interesa al usuario. La compresión fragmentada es una característica extremadamente poderosa.

Finalmente, puedo darle un solo archivo a alguien ahora, sin tener que explicar mucho sobre cómo está organizado internamente. El usuario final puede leer el archivo en Python, C, Fortran o h5ls en la línea de comandos o la GUI HDFView, y ver qué hay dentro. Eso no fue posible con mi formato binario personalizado, sin mencionar mis colecciones .tar.gz.

Claro, es posible replicar todo lo que puede hacer con HDF5 con carpetas, ASCII y archivos binarios personalizados. Eso es lo que originalmente hice, pero se convirtió en un gran dolor de cabeza, y al final, HDF5 hizo todo lo que estaba buscando juntos de una manera eficiente y portátil.

Creo que la principal ventaja es la portabilidad .

HDF5 almacena información sobre sus conjuntos de datos como el tamaño, tipo y endianness de enteros y números de punto flotante, lo que significa que puede mover un archivo hdf5 y leer su contenido, incluso si fue creado en una máquina con una arquitectura diferente.

También puede adjuntar metadatos arbitrarios a grupos y conjuntos de datos. Podría decirse que también puede hacer eso con archivos y carpetas si su sistema de archivos admite atributos extendidos.

Un archivo hdf5 es un archivo único que a veces puede ser más conveniente que tener que comprimir / atacar carpetas y archivos. También hay un inconveniente importante: si elimina un conjunto de datos, no puede reclamar el espacio sin crear un nuevo archivo.

En general, HDF5 es muy adecuado para almacenar grandes conjuntos de números, por lo general conjuntos de datos científicos.

Gracias por hacer esta interesante pregunta. ¿Es portátil una carpeta con archivos porque puedo copiar un directorio en un dispositivo en una Mac y luego ver el mismo directorio y archivos en una PC? Estoy de acuerdo en que la estructura del directorio de archivos es portátil, gracias a las personas que escriben los sistemas operativos, pero esto no está relacionado con los datos en los archivos que son portátiles. Ahora, si los archivos en este directorio son PDF, son portátiles porque hay herramientas que leen y le dan sentido a los pdfs en múltiples sistemas operativos (gracias a Adobe). Pero, si esos archivos son datos científicos en bruto (en ASCII o binario no importa) no son del todo portátiles. El archivo ASCII se vería como un grupo de caracteres y el archivo binario se vería como un galimatías. Si fueran archivos XML o json, serían legibles, porque json es ASCII, pero la información que contienen probablemente no sea portable porque el significado de las etiquetas XML / json puede no ser claro para alguien que no escribió el archivo. Este es un punto importante, los caracteres en un archivo ASCII son portátiles, pero la información que representan no lo es.

Los datos de HDF5 son portátiles, al igual que el pdf, porque hay herramientas en muchos sistemas operativos que pueden leer los datos en archivos HDF5 (al igual que los lectores de PDF, consulte http://www.hdfgroup.org/products/hdf5_tools/index.html ) También hay bibliotecas en muchos idiomas que se pueden utilizar para leer los datos y presentarlos de una manera que tenga sentido para los usuarios, que es lo que hace el lector de Adobe. Hay cientos de grupos en la comunidad HDF5 que hacen lo mismo con sus usuarios (consulte http://www.hdfgroup.org/HDF5/users5.html ).

También se ha discutido aquí sobre la compresión. Lo importante de la compresión en archivos HDF5 es que los objetos se comprimen de forma independiente y solo se descomprimen los objetos que necesita en la salida. Esto es claramente más eficiente que comprimir todo el archivo y tener que descomprimir todo el archivo para leerlo.

La otra pieza crítica es que los archivos HDF5 son autodescriptivos, por lo que las personas que escriben los archivos pueden agregar información que ayuda a los usuarios y a las herramientas a saber qué hay en el archivo. Cuáles son las variables, cuáles son sus tipos, qué software las escribió, qué instrumentos las recopilaron, etc. Parece que la herramienta en la que está trabajando puede leer los metadatos de los archivos. Los atributos en un archivo HDF5 pueden adjuntarse a cualquier objeto en el archivo; no son solo información a nivel de archivo. Esto es enorme Y, por supuesto, esos atributos se pueden leer usando herramientas escritas en muchos idiomas y muchos sistemas operativos.

HDF5 es en última instancia, un formato para almacenar números, optimizado para grandes conjuntos de datos. Las principales fortalezas son el soporte para la compresión (que puede acelerar la lectura y escritura de datos en muchas circunstancias) y las consultas rápidas en el kernel (recuperación de datos que cumplen ciertas condiciones; por ejemplo, todos los valores de presión cuando la temperatura supera los 30 DO).

El hecho de que pueda combinar varios conjuntos de datos en el mismo archivo es solo una conveniencia. Por ejemplo, podría tener varios grupos correspondientes a diferentes estaciones meteorológicas, y cada grupo consistiría en varias tablas de datos. Para cada grupo, tendrías un conjunto de atributos que describen los detalles de los instrumentos, y cada tabla los ajustes individuales. Puede tener un archivo h5 para cada bloque de datos, con un atributo en el lugar correspondiente y le daría la misma funcionalidad. Pero ahora, lo que puede hacer con HDF5 es volver a empaquetar el archivo para realizar consultas optimizadas, comprimirlo todo por completo y recuperar su información a una velocidad vertiginosa. Si tiene varios archivos, cada uno se comprimirá individualmente, y el sistema operativo decidirá el diseño en el disco, que puede no ser el óptimo.

Una última cosa que HDF5 le permite es cargar un archivo (o una pieza) en la memoria exponiendo la misma API que en el disco. Entonces, por ejemplo, puede usar uno u otro back-end dependiendo del tamaño de los datos y la RAM disponible. En su caso, eso equivaldría a copiar la información relevante en / dev / shm en Linux, y usted sería responsable de volver a introducir en el disco cualquier modificación.

Para mí, podemos comparar la carpeta con archivos a HDF5 solo en el contexto relevante de datos científicos donde los datos más importantes son matrices descritas por un conjunto de metadatos.

En el contexto general, Marcus está bien cuando afirma que la carpeta con archivos es mucho más portátil que cualquier HDF5. Añadiré que, en un contexto general, una carpeta con archivo es mucho más accesible que un archivo HDF5. El desafío obvio es que con la carpeta y los archivos "normales", no hay necesidad de una API adicional para acceder a los datos. Eso es simplemente imposible con HDF5 que mantiene los datos y metadatos en el mismo archivo.

Imagine un momento, para leer su archivo pdf, necesita un nuevo lector de PDF que comprenda HDF5. Imagínese, para reproducir su música, ¿necesita un reproductor de música que pueda decodificar HDF5? para ejecutar su secuencia de comandos python, el intérprete python necesita primero decodificar el HDF5? O el total, para iniciar su intérprete de python, ¿su sistema operativo necesita decodificar el HDF5? etc. Simplemente no podré escribir esta respuesta, porque mi sistema operativo no habrá podido iniciar mi navegador web, que no podrá leer sus archivos internos porque anteriormente convertí todo en HDF5 (tal vez un gran HDF5 para todo en mi disco duro).

Almacenar metadatos en un archivo separado tiene la enorme ventaja de funcionar bien con la gran cantidad de archivos de datos y software que ya existen sin ningún dolor de cabeza extra.

Espero que esto ayude.

Sí, la principal ventaja es que HDF5 es portátil. Se puede acceder a los archivos HDF5 por una gran cantidad de otros lenguajes de programación / interpretación, como Python (en el que se basa su API), MATLAB, Fortran y C. Como sugirió Simon, HDF5 se usa ampliamente en la comunidad científica para almacenar grandes conjuntos de datos. En mi experiencia, me parece útil la capacidad de recuperar solo ciertos conjuntos de datos (y regiones). Además, la construcción de la biblioteca HDF5 para E / S paralela es muy ventajosa para el procesamiento posterior de datos brutos en un momento posterior.

Dado que el archivo también es autodescriptivo, es capaz de almacenar no solo datos brutos, sino también la descripción de esos datos, como el tamaño de la matriz, el nombre de la matriz, las unidades y un host de metadatos adicionales.

Espero que esto ayude.

Un juego en el que necesite cargar muchos recursos en la memoria sería un escenario en el cual un HDF5 podría ser mejor que una carpeta con archivos. Cargar datos de archivos tiene costos como tiempo de búsqueda, el tiempo requerido para abrir cada archivo y leer datos del archivo en la memoria. Estas operaciones pueden ser incluso más lentas cuando lee datos de un DVD o Blu-ray. Abrir un solo archivo puede reducir drásticamente esos costos.