Flujo de trabajo para análisis estadístico y redacción de informes.

¿Alguien tiene conocimiento sobre los flujos de trabajo para el análisis de datos relacionados con la redacción de informes personalizados? El caso de uso es básicamente este:

1. El cliente encarga un informe que utiliza análisis de datos, por ejemplo, una estimación de población y mapas relacionados para un distrito de agua.

2. El analista descarga algunos datos, procesa los datos y guarda el resultado (por ejemplo, agregando una columna para la población por unidad o subconjunto de los datos en función de los límites del distrito).

3. El analista analiza los datos creados en (2), se acerca a su objetivo, pero ve que necesita más datos y vuelve a (1).

4. Enjuague repita hasta que las tablas y los gráficos cumplan con QA / QC y satisfagan al cliente.

5. Escribir informe incorporando tablas y gráficos.

6. El año que viene, el cliente feliz regresa y quiere una actualización. Esto debería ser tan simple como actualizar los datos aguas arriba mediante una nueva descarga (por ejemplo, obtener los permisos de construcción del último año) y presionar el botón "RECALCULAR", a menos que las especificaciones cambien.

Por el momento, solo comienzo un directorio y lo ad-hoc lo mejor que puedo. Me gustaría un enfoque más sistemático, así que espero que alguien lo haya descubierto ... Uso una combinación de hojas de cálculo, SQL, ARCGIS, R y herramientas Unix.

¡Gracias!

PD:

A continuación se muestra un Makefile básico que busca dependencias en varios conjuntos de datos intermedios (con .RDatasufijo) y scripts ( .Rsufijo). Make utiliza marcas de tiempo para verificar las dependencias, por lo que si lo touch ss07por.csvhace, verá que este archivo es más nuevo que todos los archivos / destinos que dependen de él, y ejecutará los scripts dados para actualizarlos en consecuencia. Esto sigue siendo un trabajo en progreso, que incluye un paso para colocar en la base de datos SQL y un paso para un lenguaje de plantillas como sweave. Tenga en cuenta que Make se basa en pestañas en su sintaxis, así que lea el manual antes de cortar y pegar. ¡Disfruta y da tu opinión!

http://www.gnu.org/software/make/manual/html_node/index.html#Top

R = / inicio / wsprague / R-2.9.2 / bin / R

persondata.RData: ImportData.R ../../DATA/ss07por.csv Functions.R
   $ R --slave -f ImportData.R

persondata.Munged.RData: MungeData.R persondata.RData Functions.R
      $ R --slave -f MungeData.R

report.txt: TabulateAndGraph.R persondata.Munged.RData Functions.R
      $ R --slave -f TabulateAndGraph.R> report.txt

Generalmente divido mis proyectos en 4 piezas:

1. carga.R
2. clean.R
3. func.R
4. insecto

load.R: se encarga de cargar todos los datos requeridos. Por lo general, este es un archivo corto, que lee datos de archivos, URL y / o ODBC. Dependiendo del proyecto en este punto, escribiré el espacio de trabajo usando save()o simplemente guardaré las cosas en la memoria para el siguiente paso.

clean.R: Aquí es donde viven todas las cosas feas: cuidar los valores perdidos, fusionar marcos de datos, manejar valores atípicos.

func.R: contiene todas las funciones necesarias para realizar el análisis real. source()El uso de este archivo no debería tener otros efectos secundarios además de cargar las definiciones de funciones. Esto significa que puede modificar este archivo y volver a cargarlo sin tener que volver a repetir los pasos 1 y 2, que pueden tardar mucho tiempo en ejecutarse para grandes conjuntos de datos.

do.R: llama a las funciones definidas en func.R para realizar el análisis y producir gráficos y tablas.

La motivación principal para esta configuración es trabajar con datos grandes en los que no desee tener que volver a cargar los datos cada vez que realice un cambio en un paso posterior. Además, mantener mi código compartimentado de esta manera significa que puedo volver a un proyecto olvidado hace mucho tiempo y leer rápidamente load.R y calcular qué datos necesito actualizar, y luego mirar do.R para determinar qué análisis se realizó.

Si desea ver algunos ejemplos, tengo algunos proyectos pequeños (y no tan pequeños) de limpieza y análisis de datos disponibles en línea. En la mayoría, encontrará un script para descargar los datos, uno para limpiarlo y algunos para explorar y analizar:

• Nombres para bebés de la administración de la seguridad social.
• Más de 30 años de datos de ahorro de combustible del EPI
• Una gran recopilación de datos sobre la crisis de la vivienda.
• Calificaciones de películas del IMDB
• Datos de venta de casas en el área de la bahía

Recientemente comencé a numerar los scripts, por lo que es completamente obvio en qué orden deben ejecutarse. (Si me siento realmente elegante, a veces lo haré para que el script de exploración llame al script de limpieza, que a su vez llama al script de descarga, cada uno haciendo el trabajo mínimo necesario, generalmente comprobando la presencia de archivos de salida con file.exists. Sin embargo, la mayoría de las veces esto parece excesivo).

Utilizo git para todos mis proyectos (un sistema de administración de código fuente), por lo que es fácil colaborar con otros, ver qué está cambiando y volver fácilmente a las versiones anteriores.

Si hago un informe formal, generalmente mantengo R y látex separados, pero siempre me aseguro de que sourcemi código R pueda producir todo el código y la salida que necesito para el informe. Para el tipo de informes que hago, encuentro esto más fácil y más limpio que trabajar con látex.

Estoy de acuerdo con los otros respondedores: Sweave es excelente para escribir informes con R. Y reconstruir el informe con resultados actualizados es tan simple como volver a llamar a la función Sweave. Es completamente autónomo, incluidos todos los análisis, datos, etc. Y puede controlar la versión de todo el archivo.

Utilizo el complemento StatET para Eclipse para desarrollar los informes, y Sweave está integrado (Eclipse reconoce el formateo de látex, etc.). En Windows, es fácil usar MikTEX .

También agregaría que puedes crear hermosos informes con Beamer . Crear un informe normal es igual de simple. Incluí un ejemplo a continuación que extrae datos de Yahoo! y crea un gráfico y una tabla (usando quantmod). Puede compilar este informe así:

Sweave(file = "test.Rnw")

Aquí está el documento Beamer en sí:

% 
\documentclass[compress]{beamer}
\usepackage{Sweave}
\usetheme{PaloAlto} 
\begin{document}

\title{test report}
\author{john doe}
\date{September 3, 2009} 

\maketitle

\begin{frame}[fragile]\frametitle{Page 1: chart}

<<echo=FALSE,fig=TRUE,height=4, width=7>>=
library(quantmod)
getSymbols("PFE", from="2009-06-01")
chartSeries(PFE)
@

\end{frame}


\begin{frame}[fragile]\frametitle{Page 2: table}

<<echo=FALSE,results=tex>>=
library(xtable)
xtable(PFE[1:10,1:4], caption = "PFE")
@

\end{frame}

\end{document}

Solo quería agregar, en caso de que alguien se lo perdiera, que hay una gran publicación en el blog de aprendizaje sobre la creación de informes repetitivos con el paquete de café de Jeffrey Horner . Matt y Kevin mencionaron la preparación anterior. En realidad no lo he usado mucho.

Las entradas siguen un buen flujo de trabajo, por lo que vale la pena leerlo:

1. Prepara los datos.
2. Prepare la plantilla del informe.
3. Producir el informe.

En realidad, producir el informe una vez que se completan los dos primeros pasos es muy simple:

library(tools)
library(brew)
brew("population.brew", "population.tex")
texi2dvi("population.tex", pdf = TRUE)

Para crear informes personalizados, he encontrado útil incorporar muchos de los consejos existentes sugeridos aquí.

Generación de informes: una buena estrategia para generar informes implica la combinación de Sweave, make y R.

Editor: Los buenos editores para preparar documentos de Sweave incluyen:

• StatET y Eclipse
• Emacs y ESS
• Vim y Vim-R
• R Studio

Organización del código: en términos de organización del código, encuentro dos estrategias útiles:

• Lea sobre el flujo de trabajo de análisis (por ejemplo, ProjectTemplate , las ideas de Josh Reich, mi propia presentación sobre diapositivas y video de flujo de trabajo de R )
• Estudie informes de ejemplo y discierna el flujo de trabajo
  • Los ejemplos de Hadley Wickham
  • Mis ejemplos en github
  • Ejemplos de investigaciones reproducibles enumeradas en Cross Validated

Utilizo Sweave para el lado de producción de informes de esto, pero también he escuchado sobre el paquete de cerveza , aunque todavía no lo he investigado.

Esencialmente, tengo varias encuestas para las cuales produzco estadísticas resumidas. Las mismas encuestas, los mismos informes cada vez. Creé una plantilla de Sweave para los informes (que requiere un poco de trabajo). Pero una vez que el trabajo está hecho, tengo un script R separado que me permite señalar los nuevos datos. Presiono "Ir", Sweave descarga algunos archivos .tex de puntuación y ejecuto un pequeño script de Python para pdflatex a todos. Mi predecesor pasó ~ 6 semanas cada año en estos informes; Paso unos 3 días (principalmente en datos de limpieza; los caracteres de escape son peligrosos).

Es muy posible que haya mejores enfoques ahora, pero si decides seguir esta ruta, avísame: he tenido la intención de poner algunos de mis trucos de Sweave, y eso sería una buena patada en los pantalones. entonces.

Voy a sugerir algo en una dirección diferente a la de los otros remitentes, en base al hecho de que usted preguntó específicamente sobre el flujo de trabajo del proyecto , en lugar de las herramientas . Suponiendo que esté relativamente satisfecho con su modelo de producción de documentos, parece que sus desafíos realmente pueden centrarse más en cuestiones de seguimiento de versiones, gestión de activos y proceso de revisión / publicación.

Si eso suena correcto, sugeriría buscar una herramienta integrada de gestión de tickets / fuente / documentación como Redmine . Mantener juntos los artefactos relacionados con el proyecto, como tareas pendientes, hilos de discusión y archivos de datos / códigos versionados, puede ser de gran ayuda incluso para proyectos que se encuentran fuera de la tradicional "programación".

Acordó que Sweave es el camino a seguir, con xtable para generar tablas LaTeX. Aunque no he pasado demasiado tiempo trabajando con ellos, el paquete tikzDevice recientemente lanzado parece realmente prometedor, particularmente cuando se combina con pgfSweave (que, hasta donde sé, solo está disponible en rforge.net en este momento, hay un enlace a r-forge desde allí, pero no está respondiendo para mí en este momento).

Entre los dos, obtendrá un formato consistente entre texto y figuras (fuentes, etc.). Con brew, estos podrían constituir el santo grial de la generación de informes.

A un nivel más "meta", puede interesarle el modelo de proceso CRISP-DM .

"make" es excelente porque (1) puede usarlo para todo su trabajo en cualquier idioma (a diferencia, por ejemplo, Sweave and Brew), (2) es muy poderoso (suficiente para construir todo el software en su máquina), y (3) evita repetir el trabajo. Este último punto es importante para mí porque gran parte del trabajo es lento; Cuando látex un archivo, me gusta ver el resultado en unos segundos, no la hora que tomaría recrear las figuras.

Utilizo plantillas de proyecto junto con R studio, actualmente el mío contiene las siguientes carpetas:

• info : archivos PDF, PowerPoint, documentos ... que ningún script utilizará
• data input : datos que serán utilizados por mis scripts pero no generados por ellos
• data output : datos generados por mis scripts para su uso posterior pero no como un informe adecuado.
• reports : Solo archivos que realmente se mostrarán a otra persona
• R : Todos los scripts R
• SAS : Porque a veces tengo que: '(

Escribí funciones personalizadas para poder llamar smart_save(x,y)o smart_load(x)guardar o cargar RDS filesdesde y hacia la data outputcarpeta (archivos con nombres de variables) para que no me moleste pathsdurante mi análisis.

Una función personalizada new_projectcrea una carpeta de proyecto numerada, copia todos los archivos de la plantilla, cambia el nombre del RProjarchivo y edita las setwdllamadas, y establece el directorio de trabajo en un nuevo proyecto.

Todos los Rscripts están en la Rcarpeta, estructurados de la siguiente manera:

00_main.R

• setwd
• llama a los guiones del 1 al 5

00_functions.R

• Todas las funciones y solo las funciones van allí, si hay demasiadas las separaré en varias, todas con nombres similares 00_functions_something.R, en particular si planeo hacer un paquete con algunas de ellas, las separaré

00_explore.R

• un montón de fragmentos de script donde estoy probando cosas o explorando mis datos
• Es el único archivo donde se me permite estar desordenado.

01_initialize.R

• Precargado con una llamada a un initialize_general.Rscript más general desde mi carpeta de plantillas que carga los paquetes y datos que siempre uso y no me importa tener en mi espacio de trabajo
• cargas 00_functions.R(prellenadas)
• carga bibliotecas adicionales
• establecer variables globales

02_load data.R

• cargas csv/txt xlsx RDS, hay una línea comentada precargada para cada tipo de archivo
• muestra qué archivos se han creado en el espacio de trabajo

03_pull data from DB.R

• Usos dbplyrpara recuperar tablas filtradas y agrupadas de la base de datos
• algunas líneas comentadas prellenadas para configurar conexiones y buscar.
• Mantenga las operaciones del lado del cliente al mínimo
• No hay operaciones del lado del servidor fuera de este script
• Muestra qué archivos se han creado en el espacio de trabajo.
• Guarda estas variables para que puedan recargarse más rápido

Una vez hecho esto, apago un query_dbbooleano y los datos se volverán a cargar la RDSpróxima vez.

Puede suceder que tenga que volver a alimentar los datos a las bases de datos, de ser así, crearé pasos adicionales.

04_Build.R

• Disputa de datos, toda la diversión dplyr/ tidyrcosas van allí
• muestra qué archivos se han creado en el espacio de trabajo
• guardar estas variables

Una vez hecho esto, apago un buildbooleano y los datos se volverán a cargar la RDSpróxima vez.

05_Analyse.R

• Resumir, modelo ...
• informe excely csvarchivos

95_build ppt.R

• plantilla para el informe de PowerPoint usando officer

96_prepare markdown.R

• setwd
• Cargar datos
• establecer parámetros de rebaja si es necesario
• render

97_prepare shiny.R

• setwd
• Cargar datos
• establecer parámetros brillantes si es necesario
• runApp

98_Markdown report.Rmd

• Una plantilla de informe

99_Shiny report.Rmd

• Una plantilla de aplicación

Para escribir un informe preliminar rápido o un correo electrónico a un colega, encuentro que puede ser muy eficiente copiar y pegar trazados en MS Word o en una página de correo electrónico o wiki; a menudo, lo mejor es una captura de pantalla con mapa de bits (por ejemplo, en Mac, Apple -Shift- (Ctrl) -4). Creo que esta es una técnica subestimada.

Para un informe más final, es muy importante escribir funciones R para regenerar fácilmente todos los gráficos (como archivos). Lleva más tiempo codificar esto.

En los problemas de flujo de trabajo más grandes, me gusta la respuesta de Hadley al enumerar los archivos de código / datos para el flujo de limpieza y análisis. Todos mis proyectos de análisis de datos tienen una estructura similar.

Agregaré mi voz al tejido. Para un análisis complicado de varios pasos, puede usar un archivo MAKE para especificar las diferentes partes. Puede evitar tener que repetir todo el análisis si solo una parte ha cambiado.

También hago lo que hace Josh Reich, solo que lo hago creando mis paquetes R personales, ya que me ayuda a estructurar mi código y mis datos, y también es bastante fácil compartirlos con otros.

1. crear mi paquete
2. carga
3. limpiar
4. funciones
5. hacer

creando mi paquete: devtools :: create ('package_name')

cargar y limpiar: creo scripts en la carpeta de datos sin procesar / subcarpeta de mi paquete para cargar, limpiar y almacenar los objetos de datos resultantes en el paquete usando devtools :: use_data (object_name). Luego compilo el paquete. De ahora en adelante, la biblioteca de llamadas (nombre_paquete) hace que estos datos estén disponibles (y no se cargan hasta que sea necesario).

funciones: pongo las funciones para mis análisis en la subcarpeta R / de mi paquete, y exporto solo aquellas que necesitan ser llamadas desde afuera (y no las funciones auxiliares, que pueden permanecer invisibles).

hacer: creo un script que utiliza los datos y funciones almacenados en mi paquete. (Si los análisis solo necesitan hacerse una vez, también puedo poner este script en la carpeta / subcarpeta de datos, ejecutarlo y almacenar los resultados en el paquete para que sea fácilmente accesible).