Mejores prácticas para crear 'Tidy Data'

Hadley Wickham escribió un artículo estelar llamado "Tidy Data" ( enlace ) en JSS el año pasado sobre la manipulación de datos y la obtención de los datos en una condición "óptima" para realizar el análisis. Sin embargo, me preguntaba cuáles eran las mejores prácticas en términos de presentar datos tabulares en un entorno de trabajo. Digamos que su compañero de trabajo le pide que le proporcione algunos datos. ¿Cuáles son algunas reglas generales que utiliza al estructurar esos datos? ¿Las pautas de "Tidy Data" son tan aplicables en los casos en que comparte datos con profesionales que no son de datos? Obviamente, esto es muy específico del contexto, pero estoy preguntando acerca de las 'mejores prácticas' de alto nivel.

Como se puede esperar de Hadley, su artículo contiene una buena definición de datos ordenados y estoy de acuerdo con casi todo en su artículo y creo que no solo es válido para los "profesionales de datos". Sin embargo, algunos de los puntos que señala son relativamente fáciles de solucionar (por ejemplo, con los paquetes que ha creado) si se evitan algunos problemas más fundamentales. La mayoría de estos problemas son el resultado del uso generalizado de Excel. Excel es una herramienta valiosa y tiene sus méritos, pero algunas de sus instalaciones resultan en problemas para los analistas de datos.

Algunos puntos (de mis experiencias):

1. A algunas personas les gustan las hojas de cálculo coloridas y hacen un uso abundante de las opciones de formato. Todo esto está bien, si les ayuda a organizar sus datos y preparar tablas para su presentación. Sin embargo, es peligroso si un color de celda realmente codifica datos. Es fácil perder estos datos y es muy difícil importarlos al software estadístico (por ejemplo, vea esta pregunta en Desbordamiento de pila).
2. A veces obtengo algunos datos bien formateados (después de decirle a la gente cómo prepararlos), pero a pesar de pedirles que usen una columna dedicada o un archivo separado para comentarios, deciden poner un comentario en una columna de valor. No solo necesito lidiar con esta columna de manera especial al importar los datos, sino que el problema principal es que necesitaría desplazarme por toda la tabla para ver dichos comentarios (lo que normalmente no haría). Esto empeora aún más si usan las funciones de comentarios de Excel.
3. Las hojas de cálculo con varias tablas en ellas, varias líneas de encabezado o celdas conectadas dan como resultado un trabajo manual para prepararlas para la importación en el software estadístico. Los buenos analistas de datos generalmente no disfrutan de este tipo de trabajo manual.
4. Nunca, nunca escondas columnas en Excel. Si no son necesarios, elimínelos. Si son necesarios, muéstralos.
5. xls y sus descendientes no son formatos de archivo adecuados para intercambiar datos con otros o archivarlos. Las fórmulas se actualizan cuando se abre el archivo y diferentes versiones de Excel pueden manejar los archivos de manera diferente. En su lugar, recomiendo un archivo CSV simple, ya que casi todo el software relacionado con datos puede importar eso (incluso Excel) y se puede esperar que eso no cambie pronto. Sin embargo, tenga en cuenta que Excel se redondea a dígitos visibles cuando se guarda en un CSV (descartando así la precisión).
6. Si desea facilitarle la vida a los demás, adhiérase a los principios dados en el artículo de Hadley. Tenga una columna de valor para cada variable y columnas de factores que definan estratos.

Probablemente hay varios puntos adicionales que no me vinieron a la mente.

En primer lugar, generalmente soy yo quien obtiene los datos. Entonces esto puede leerse como mi lista de deseos.

• Por lo tanto, mi punto más importante es: hablar con el que va a analizar los datos.

• Eché un vistazo rápido al artículo: gran parte de lo que Hadley escribe podría resumirse en "normalizar su base de datos relacional".

• Pero también menciona que, dependiendo de lo que realmente esté sucediendo, puede ser sensato tener la misma variable en forma larga o amplia.

  Aquí hay un ejemplo: trato con espectros. Desde un punto de vista físico / espectroscópico, el espectro es, por ejemplo, una intensidad en función de la longitud de onda : I = f (λ). Por razones físicas, esta función es continua (y continuamente diferenciable). Una discretización a s particulares ocurre solo por razones prácticas (por ejemplo, computadoras digitales, instrumentos de medición). Esto apuntaría claramente a una forma larga. Sin embargo, mi instrumento mide los diferentes en diferentes canales (de una línea o matriz CCD / detector). El análisis de datos también trata cada como una . Eso estaría a favor de la forma amplia.$I$$λ$$λ_i$$λ_i$$λ_i$

• Sin embargo, existen algunas ventajas prácticas para la visualización / distribución no normalizada de los datos:

  • Puede ser mucho más fácil verificar que los datos estén completos .

  • Las tablas conectadas como en una base de datos relacional normalizada están bien si los datos están realmente en una base de datos (en el sentido del software). Allí, puede poner restricciones que garanticen la integridad. Si los datos se intercambian en forma de varias tablas, en la práctica los enlaces serán un desastre.

  • La normalización de la base de datos elimina las redundancias. En la vida real del laboratorio, las redundancias se utilizan para verificar la integridad.
    Por lo tanto, la información redundante no debe eliminarse demasiado pronto.

  • El tamaño de la memoria / disco parece ser un problema menor hoy en día. Pero también aumenta la cantidad de datos que producen nuestros instrumentos.

    Estoy trabajando con un instrumento que puede producir fácilmente 250 GB de datos de alta calidad en pocas horas. Esos 250 GB están en formato de matriz. Expandir esto a una forma larga lo haría explotar por un factor de al menos 4: cada una de las dimensiones de la matriz (lateral x e y, y longitud de onda λ) se convertirá en una columna, más una columna para la intensidad). Además, mi primer paso durante el análisis de datos suele ser volver a convertir los datos normalizados de formato largo en todo el espectro.

  • Por lo general, el análisis de datos necesitará una forma particular. Es por eso que aconsejo hablar con la persona que analizará los datos.

• El trabajo de limpieza que abordan estos puntos de normalización es tedioso y no es un buen trabajo. Sin embargo, en la práctica, generalmente paso mucho más tiempo en otros aspectos de ordenar

  • Asegurar la integridad y la integridad de los datos en la práctica es una gran parte de mi trabajo de limpieza de datos.

  • Los datos no están en un formato fácil de leer / cambiar entre formatos ligeramente diferentes:

    Obtengo muchos datos en forma de muchos archivos y, por lo general, parte de la información se almacena en el nombre y / o ruta del archivo: el software del instrumento y / o los formatos de archivo producidos no permiten agregar información de manera consistente, por lo que o tiene una tabla adicional (como en una base de datos relacional) que vincula la metainformación a un nombre de archivo o el nombre del archivo codifica información importante.

    Los errores tipográficos o pequeños cambios en el patrón de los nombres de los archivos causan muchos problemas aquí.

  • Ordenar desde el punto de vista de la medición: deshacerse de las mediciones falsas (generalmente causadas por procesos físicos conocidos como alguien que enciende accidentalmente la luz, rayos cósmicos que golpean el detector, cambios de marco de la cámara, ...).