Formato de texto plano simple, confiable, abierto e interoperable para almacenar datos

17

En una pregunta anterior, pregunté sobre herramientas para editar archivos CSV .

Gavin se vinculó a un comentario sobre la Ayuda R de Duncan Murdoch que sugiere que el Formato de intercambio de datos es una forma más confiable de almacenar datos que CSV.

Para algunas aplicaciones, se necesita un sistema de gestión de bases de datos dedicado. Sin embargo, para proyectos de análisis de datos a pequeña escala, algo más ligero parece más adecuado.

Considere los siguientes criterios para evaluar un formato de archivo:

  • confiable : los datos ingresados ​​deben mantenerse fieles a lo ingresado; los datos deben abrirse consistentemente en diferentes softwares;
  • simple : sería bueno si el formato de archivo es fácil de entender e idealmente se puede leer con un editor de texto simple; Debería ser fácil escribir un programa simple para leer y escribir el formato.
  • abierto : el formato debe estar abierto
  • interoperable : el formato de archivo debe ser compatible con muchos sistemas

Encuentro que los formatos de valores separados por tabulaciones y comas fallan en el criterio de confiabilidad. Aunque supongo que podría culpar a los programas de importación y exportación en lugar del formato de archivo. A menudo me encuentro teniendo que hacer pequeños ajustes a las opciones read.tablepara evitar que algún personaje extraño rompa la carga del marco de datos.

Preguntas

  • ¿Qué formato de archivo satisface mejor estas necesidades?
  • ¿Es el formato de intercambio de datos una mejor alternativa? o tiene sus propios problemas?
  • ¿Hay algún otro formato que sea preferible?
  • ¿Estoy evaluando injustamente TSV y CSV? ¿Existe un conjunto simple de consejos para trabajar con dichos archivos que hacen que el formato del archivo sea más confiable?
project-management Jeromy Anglim
fuente
2
Debo agregar que R no tiene una, write.DIF()así que me temo que es una calle unidireccional.
Restablecer Monica - G. Simpson
1
No entiendo el tema de csv y confiabilidad. ¿Quiere decir que csv no es lo suficientemente estricto? Estricto significa que si las regulaciones para csv fueran lo suficientemente estrictas, cada herramienta que siga estas definiciones podría cargar un archivo sin la necesidad de parámetros adicionales.
steffen
@steffen Quiero decir cosas como: cargar y guardar un archivo csv en algunos programas cambia el archivo csv; cargar archivos csv puede provocar una conversión inapropiada a menos que tenga cuidado; Los archivos csv a veces se rompen cuando se agregan combinaciones extrañas de caracteres sin un escape adecuado. Quizás estoy confundiendo el uso de csv con el formato en sí, aunque he escuchado a personas comentar sobre la falta de un estándar oficial. Por supuesto, me doy cuenta de que en muchos casos funciona bien.
Jeromy Anglim
55
@steffen: CSV no almacena ninguna información sobre el formato o los tipos de datos de los datos almacenados en el archivo. Puede abrir un archivo CSV en dos aplicaciones diferentes y hacer que interprete los datos del archivo de dos maneras diferentes.
Restablecer a Monica - G. Simpson
1
@ JeromyAnglim, creo que cambiar el archivo csv depende de su software, no del formato csv per se.
Roman Luštrik

Respuestas:

9

Me pregunto si hay una colisión de criterio aquí.

Una queja sobre los formatos de archivo como Excel, SQL, etc. es que debe definir los tipos de datos con anticipación para que se comporten bien, lo que va en contra del criterio de "algo más liviano" (ya que entiendo que su restricción es más tiempo relacionado que computacionalmente relacionado).

Por el contrario, el criterio de que no acumule datos o permita que los datos se acumulen requiere cierta verificación de errores. A menos que permita que el sistema descubra automáticamente los tipos de datos (que es esencialmente donde Excel le está fallando), no hay forma de tener su pastel y comérselo también.

OMI, de los dos, el segundo criterio es más importante. La integridad de los datos, una vez violada, hace que el análisis sea difícil o imposible. Las observaciones perdidas o los valores no válidos (si no se verifican correctamente) pueden estropear todo.

En lo que respecta a DIF, el texto sin procesar real no es legible por humanos y sería difícil (IMO) para los humanos ingresar datos.

OMI, deberías darle una sacudida justa a los archivos delimitados. Como se mencionó anteriormente en los comentarios, la "manipulación de datos" es principalmente culpa de un subconjunto de herramientas que está utilizando. Los programas con buen comportamiento no deben destrozar archivos delimitados. La mayor fuente de destrucción es un delimitador mal especificado. Por ejemplo, si sus datos pueden tener comas, un CSV es inapropiado. Si puede tener pestañas, TSV es inapropiado. Para muchos (pero no todos) los programas, puede especificar un delimitador alternativo. Por ejemplo, he usado la tilde (~) en un par de casos difíciles.

russellpierce
fuente
Gracias. Parece que usar un formato de archivo delimitado con el cuidado adecuado puede ser la mejor opción.
Jeromy Anglim
6

Con toda seriedad, consideraría los archivos RData creados por R, ya que encajan

  • confiable (verificar)
  • simple (llámelo empate, el formato es binario)
  • abierto (comprobar: no se abre más que el código fuente R)
  • interoperable (comprobar: funciona en todas partes R funciona)

Lo suficientemente cerca para mí. Si por sistemas te refieres a aplicaciones en lugar de sistema operativo, entonces el último punto es un error.

Ah, y RData es eficiente ya que los archivos ahora están comprimidos de forma predeterminada (que solía ser una opción que estaba desactivada de forma predeterminada).

Dirk Eddelbuettel
fuente
2
RData ciertamente funciona bien con R. Puede ser problemático con respecto al control de versiones. Supongo que la función R dput()proporciona una alternativa de texto sin formato que funcionaría con el control de versiones. Sin embargo, uno de los atractivos de csv / tsv es que cuando comparto un repositorio con datos (por ejemplo, para un artículo de revista), las personas pueden tomar los datos y volver a analizarlos fácilmente utilizando el software que deseen.
Jeromy Anglim
1
Sí, es un asunto enormemente complicado. Creo que la gente ha discutido esto desde los albores de la informática. Pensé dos veces más (y podría ampliar mi respuesta): ProtocolBuffers es bueno para compartir eficientemente con Python, Java, C ++, ... y una gran cantidad de otros lenguajes; Romain y yo cubrimos R. El sitio nuevo mldata.org cubre esto para la investigación en Machine Learning, incluso tienen herramientas que ponen a disposición para convertir. Puede valer la pena echarle un vistazo.
Dirk Eddelbuettel
1
En realidad, SVN toma blobs binarios como archivos pdf, etc. sin problemas. Sospecho que git también lo hace.
Dirk Eddelbuettel
Es bueno saber acerca de las gotas binarias. Todavía sería bueno poder ejecutar diff en archivos de texto y obtener información significativa sobre los cambios. Gracias también por el enlace a mldata.org. Eso se ve interesante.
Jeromy Anglim
Placer. El sitio hermano mloss.org es simplemente genial, si es que esperan obtener tracción para mldata.org. Es el momento adecuado para eso.
Dirk Eddelbuettel
4

En respuesta a la respuesta de Dirk Eddelbuettel, sugiero usar el formato de archivo HDF5 . Es menos simple que el formato RData, o podría decirse, 'más rico', pero ciertamente más interoperable (puede usarse en C, Java, Matlab, etc.). He descubierto que la E / S que involucra grandes archivos HDF5 es muy rápida.

shabbychef
fuente
(+1) ¿Alguna idea sobre su rendimiento en comparación con NetCDF ?
chl
IIRC, que también es el formato interno elegido en mldata.org , con un conjunto de herramientas que convierten. Los convertidores pueden valer la pena. Siempre tuve la sensación de que el soporte R para HDF5 era menos que perfecto.
Dirk Eddelbuettel
@chl Pensé vagamente que NetCDF usaba HDF5 internamente, pero eso no parece ser del todo exacto.
shabbychef
2

No estoy muy seguro de por qué el formato de texto fijo con los metadatos apropiados no cumple con sus criterios. No es tan simple de leer como un delimitador, pero de todos modos necesita metadatos para usar la información. La tarea de escribir la sintaxis para leer el programa simplemente depende de cuán grande y complicada sea la estructura del conjunto de datos. SPSS y Excel tienen una GUI para ayudar con estas tareas.

Solo hay dos errores con los archivos CSV que he encontrado:

  1. Faltan campos sin delimitadores (por lo que cualquier otro campo en ese registro está fuera de lugar, también he tenido este problema con las etiquetas faltantes en XML)
  2. Una coma dentro de una cadena de texto

(si ha encontrado otros problemas, no dude en dar ejemplos)

Dos se resuelve con un delimitador más irregular como sugirió drnexus (una tubería (|) es una que he encontrado antes, pero una tilde (~) funciona igual de bien porque es probable que ninguna se incluya en los campos de cadena). Una es una El problema no se resuelve fácilmente con el software que esté utilizando, y ambos son problemas con la forma en que las personas escribieron los archivos, no el software utilizado para leer los archivos.

También me gustaría decir que estoy de acuerdo con drnexus en este hilo y su respuesta en su otro hilo reciente sobre la edición de estos archivos. Parece que se está quejando del software que usa (particularmente Excel) y solicita almacenar datos en un formato que se ajuste a su software de mal comportamiento. Tal vez la pregunta debería ser cómo hacer que Excel deje de formatear automáticamente los archivos de texto sin formato. Su criterio confiable como me parece es un problema de software con la lectura de archivos de texto sin formato. No uso R para la gestión de datos, pero no me ha costado tanto leer archivos delimitados en SPSS como parece sugerir.

Si los archivos originales no están escritos correctamente, ¿qué le hace esperar que algún software lea el archivo de manera confiable? Y un formato de archivo específico ciertamente no le impedirá escribir incorrectamente los datos al tipo de archivo que elija para comenzar.

Andy W
fuente
(1) Me gustaría poder abrir y cerrar el archivo de datos tan fácilmente como puedo abrir un archivo de datos Rdata, Excel o SPSS. Pasar tiempo caminando a través de un asistente funciona, pero no es el flujo de trabajo simple y confiable que idealmente me gustaría. (2) Sí, estoy de acuerdo en usar un delimitador irregular. En general, Tab es suficiente para mí la mayor parte del tiempo; (3) No tengo grandes problemas con CSV / TSV. Tengo problemas ocasionales que se resuelven fácilmente. Sin embargo, me gustaría no tener que pensar en los problemas de delimitadores y conversión de formatos.
Jeromy Anglim
@ Jeromy Anglim, para el punto n. ° 1, supongo que normalmente solo tiene que hacer esto una vez (a menos que migre entre dos entornos diferentes con frecuencia que no pueden leer o generar los otros archivos). Para el punto 3, los archivos de texto fijos solucionan ese problema. Nunca me he encontrado con una situación en la que SPSS haya formateado un tipo de archivo diferente de forma incorrecta. Si no necesita difundir los archivos, toda esta pregunta es muda, si puede hacer que el archivo se guarde correctamente en cualquier entorno en el que trabaje, ya no hay necesidad de conversión / almacenamiento.
Andy W
1

El problema común con el formato de texto sin formato es que no puede almacenar metadatos. ¿Cómo define los datos faltantes? ¿Cómo define 1 = totalmente en desacuerdo, 2 = en desacuerdo, ... tipos de cosas en formato de texto plano? Con formato de texto plano, debe usar otro documento para definir esos metadatos. Y no es fácil de hacer en XML.

A veces este problema puede ser muy inquietante.

Mi solución es utilizar el formato de datos SPSS, que es autónomo y fácil de editar en SPSS. Sé que esta no es una respuesta correcta a su pregunta, pero he tenido problemas con el mismo problema durante mucho tiempo y esta es mi solución actual.

Jfly
fuente