¿Cómo mantener controlados los análisis exploratorios de grandes conjuntos de datos?

Cuando comienzo un análisis exploratorio en un gran conjunto de datos (muchas muestras, muchas variables), a menudo me encuentro con cientos de variables derivadas y toneladas de tramas diferentes, y no hay una forma real de realizar un seguimiento de lo que está sucediendo. El código termina como espagueti, porque no hay dirección desde el principio ...

¿Hay algún método recomendado para mantener un análisis exploratorio limpio y ordenado? En particular, ¿cómo manejas múltiples ramas de exploración (incluidas las que eran callejones sin salida) y con diferentes versiones de parcelas?

Como referencia, estoy trabajando en datos geocientíficos (muchas variables a lo largo del tiempo, a veces también en el espacio). Por lo general, trabajo con Python o R, y almaceno todo en git, y también he estado probando el cuaderno de IPython. Sin embargo, sería bueno si las respuestas fueran algo generales y útiles para las personas en todos los campos, con otros tipos de datos (¿grandes?).

Creo que con frecuencia, la tendencia a sentir que has caído en una madriguera de conejo con análisis exploratorios se debe a perder de vista la (s) pregunta (s) sustantiva (s) que estás haciendo. Lo hago yo mismo, de vez en cuando, y luego tengo que recordarme cuáles son mis objetivos. Por ejemplo, ¿estoy tratando de construir un modelo específico o evaluar la idoneidad de uno existente? ¿Estoy buscando evidencia de problemas con los datos (es decir, análisis forense de datos)? O, ¿está esto en las primeras etapas del análisis, donde estoy investigando preguntas específicas de manera informal (por ejemplo, ¿hay una relación entre dos variables?) Antes de pasar a desarrollar un modelo formal? En resumen, si se da cuenta de que está trazando parcelas y tablas pero no puede establecer claramente cuál es su objetivo inmediato o por qué esa trama / tabla es relevante, entonces sabe que '

Intento abordar el análisis exploratorio de datos como lo hago escribiendo, ya sea escribiendo un programa o escribiendo un artículo. En cualquier caso, no comenzaría sin hacer un bosquejo primero. Ese esquema puede cambiar (y con frecuencia lo hace), por supuesto, pero comenzar a escribir sin uno es ineficiente y, a menudo, produce un producto final deficiente.

En la organización WRT, cada analista debe encontrar un flujo de trabajo que funcione para él o ella; hacerlo es IMO más importante que tratar de seguir rígidamente el flujo de trabajo de otra persona (aunque siempre es útil obtener ideas de lo que otros están haciendo). Si está trabajando mediante programación (es decir, escribiendo código que se puede ejecutar para generar / regenerar un conjunto de resultados) y verificando su trabajo en git, entonces ya está muy por delante de muchos en este sentido. Sospecho que es posible que solo necesite dedicar un tiempo a organizar su código, y para eso, sugeriría seguir su esquema. Por ejemplo, mantenga sus archivos de análisis relativamente cortos y específicos, de modo que cada uno responda una pregunta específica (por ejemplo, diagramas de diagnóstico para un modelo de regresión específico). Organícelos en subdirectorios en uno o dos niveles, según el tamaño y la complejidad del proyecto. De esta manera, el proyecto se vuelve autodocumentado; una vista de lista de los directorios, subdirectorios y archivos (junto con el comentario en la parte superior de cada archivo) debería, en teoría, reproducir su esquema.

Por supuesto, en un proyecto grande, es posible que también tenga un código que limpie y administre los datos, el código que ha escrito para estimar un cierto tipo de modelo u otras utilidades que ha escrito, y estos no encajarán en el sustantivo resumen para su análisis de datos, por lo que deben organizarse en una parte diferente de la carpeta de su proyecto.

Actualización: Después de publicar esto, me di cuenta de que no había abordado directamente su pregunta sobre "callejones sin salida". Si realmente decide que un conjunto completo de análisis no tiene valor, entonces si está trabajando en git, siempre puede eliminar los archivos correspondientes con un mensaje de confirmación como "Abandonó esta línea de análisis porque no era productivo." A diferencia de arrugar lo que ha escrito y tirarlo a la basura, siempre puede volver a lo que hizo más adelante, si lo desea.

Sin embargo, creo que encontrará que si procede de un esquema en el que ha pensado un poco, tendrá menos llamados callejones sin salida. En cambio, si pasa tiempo investigando una pregunta que vale la pena y relevante, incluso si esto lleva a un resultado nulo o no resulta como esperaba, probablemente todavía quiera mantener un registro de lo que ha hecho y el resultado (en como mínimo, para que no cometas el error de repetir esto más adelante). Simplemente muévalos al final de su esquema, en una especie de "Apéndice".

No sé qué tan útil será una respuesta general. Estás preguntando cómo hacer algo difícil; Las buenas respuestas probablemente dependerán de la disciplina y probablemente serán largas y matizadas. :)

En lo que respecta a la organización, ya está usando git, por lo que luego debe comenzar a usar un archivo MAKE para ejecutar el análisis. El archivo MAKE establece cómo los diferentes archivos dependen unos de otros (es decir, qué estadísticas se derivan de qué código) y cuando llama make, todo lo que necesita actualizarse lo hará.

Ahora, eso no ayuda con la parte exploratoria. Para EDA, uso (principalmente) R en emacs a través de ESS. Necesita necesita una REPL para EDA. Mi flujo de trabajo es jugar con tramas, estimaciones, etc. en ESS (en un exploratory.Rarchivo de tipo), decidir qué quiero conservar y luego volver a codificarlo para que se pueda ejecutar por lotes. Re: git, no sé cómo lo estás usando, pero uso un único repositorio para cada proyecto (generalmente un solo documento) y elimino la base de mi código para mantener un historial limpio; es decir, yo uso

$ git merge meandering-branch --squash
$ git add -p somefile
$ git rebase -i master
$ git reset HEAD --hard

mucho más que cuando comencé con git, y mucho más de lo que recomendaría a un principiante. Si no está familiarizado con todos esos comandos y opciones, es posible que desee aprender más sobre git. Lo más importante que me ha ayudado es ser disciplinado sobre hacer commits lógicamente distintos; es decir, cada confirmación debe contener todos los cambios que desee deshacer de una vez en el futuro (y no más ni menos).

En cuanto a la exploración real de los datos, he encontrado estos libros útiles e interesantes, y tratan específicamente con grandes conjuntos de datos (al menos en partes):

• Los gráficos de grandes conjuntos de datos , editados por Unwin, Theus y Hofmann. a través de springerlink si tiene acceso, de lo contrario, los capítulos individuales probablemente estén disponibles buscando en Google.

• El manual de visualización de datos , editado por Chen, Härdle y Unwin. también a través de springerlink

• Análisis de datos por Huber (2011).

Dos palabras: mapa conceptual. Esa es la única forma efectiva que he encontrado para dividir y conquistar grandes conjuntos de datos o cualquier concepto realmente complicado. http://en.wikipedia.org/wiki/Concept_maps

Personalmente, pienso mejor en el papel que en la pantalla, así que solo pienso en el mapa de lo que estoy tratando antes de comenzar a hacer un análisis básico. Para un diagrama más profesional, hay muchos programas de mapas mentales http://en.wikipedia.org/wiki/List_of_concept-_and_mind-mapping_software

El mapeo mental tiene varias ventajas:

• me dice lo que tengo en términos de variables "centrales" y variables derivadas (si las hay)
• permite la organización / formulación de un modelo basado en teoría / lógica
• señala qué variables me pueden faltar y / o podría agregar si las relaciones entre las variables principales no funcionan como creo que deberían

Editar :

Como ejemplo, aquí está el mapa conceptual para el análisis factorial: http://www.metacademy.org/graphs/concepts/factor_analysis#focus=factor_analysis&mode=explore Ahora, esto es puramente para aprender el concepto, no para realizar análisis, pero la idea es lo mismo: trazar con anticipación lo que tiene sentido hacer y luego hacerlo.

Si está buscando una versión automatizada / codificada de esto, no creo que exista. No puede automatizar el concepto de modelado cuando intenta comprender un sistema. (Y eso es bueno porque dejaría a muchas personas sin trabajo).

Ya estás usando git: ¿por qué no usar el control de versiones para organizar tu exploración? Cree una nueva rama para cada nueva "rama" de su exploración, y bifurque ramas para diferentes versiones de parcelas también. Este método hará que sea un poco más difícil combinar sus resultados finales, pero siempre puede mantener un directorio sin seguimiento donde pueda colocar las "gemas" de su análisis. Probablemente desee etiquetar de alguna manera sus archivos en este directorio para indicar de qué fork / commit provienen. Este método tiene el beneficio adicional de hacer que sea realmente fácil contrastar diferentes análisis a través del diffcomando.

Buscaría herramientas de Business Intelligence ... donde surjan problemas similares. En particular (almacenes de datos, análisis dimensional,) jerarquías y desgloses.

La idea básica es que intente representar sus datos subyacentes como cantidades acumulables (recuentos, ganancias, etc. en lugar de, por ejemplo, porcentajes). Luego diseña jerarquías para agregar sobre los detalles (por ejemplo, meses / semanas / ...). Esto le permite tener una visión general simple de todos sus datos y luego hacer zoom en áreas particulares. ver, por ejemplo, http://cubes.databrewery.org/ (python) o excel power pivot