realizar - Flujo de trabajo para el análisis estadístico y la redacción de informes

informe estadistico ejemplo corto

Question

¿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 esto:

1. El cliente encarga un informe que utiliza el 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, los datos y guarda el resultado (por ejemplo, agregar una columna para la población por unidad o subconjunto de los datos según 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, por lo tanto, vuelve a (1).

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

5. Escribir informe incorporando tablas y gráficos.

6. El próximo año, el cliente feliz regresa y quiere una actualización. Esto debería ser tan simple como actualizar los datos iniciales 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, simplemente empiezo un directorio y ad-hoc lo mejor que puedo. Me gustaría un enfoque más sistemático, así que espero que alguien lo haya descubierto ... Utilizo una combinación de hojas de cálculo, SQL, ARCGIS, R y herramientas de Unix.

¡Gracias!

PD:

A continuación se muestra un Makefile básico que busca dependencias en varios conjuntos de datos intermedios (sufijo de w / .RData ) y scripts (sufijo .R ). touch ss07por.csv marcas de tiempo para verificar las dependencias, por lo que si touch ss07por.csv , 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 todavía es un trabajo en progreso, incluido un paso para poner en la base de datos SQL, y un paso para un lenguaje de plantillas como sweave. Tenga en cuenta que Make depende de las pestañas en su sintaxis, por lo tanto, 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=/home/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

Answer 1

"hacer" es genial porque (1) puede usarlo para todo su trabajo en cualquier idioma (a diferencia de, 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 hago latex un archivo, me gusta ver el resultado en unos pocos segundos, no la hora que tomaría volver a crear las figuras.

Answer 2

Añadiré mi voz para sudar. Para un análisis complicado de varios pasos, puede usar un makefile para especificar las diferentes partes. Puede evitar tener que repetir todo el análisis si solo una parte ha cambiado.

Answer 3

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

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

Answer 4

En un nivel más "meta", es posible que le interese el modelo de proceso CRISP-DM .

Answer 5

Estoy de acuerdo con los otros respondedores: Sweave es excelente para redactar informes con R. Y la reconstrucción del 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 plugin StatET para Eclipse para el desarrollo de informes, y Sweave está integrado (Eclipse reconoce el formateado de látex, etc.). En Windows, es fácil de usar MikTEX .

También agregaría, que puede crear informes hermosos 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 de Beamer:

%
/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}

Answer 6

Generalmente rompo mis proyectos en 4 piezas:

1. load.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é cosas en la memoria para el próximo paso.

clean.R: Aquí es donde vive todo lo feo: cuidando los valores perdidos, combinando marcos de datos, manejando valores atípicos.

func.R: contiene todas las funciones necesarias para realizar el análisis real. source() ''ing este archivo no debe tener otros efectos secundarios que cargar las definiciones de funciones. Esto significa que puede modificar este archivo y volver a cargarlo sin tener que volver atrás repita 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 principal motivación para esta configuración es trabajar con datos de gran tamaño por los cuales no desea tener que volver a cargar los datos cada vez que realiza un cambio en un paso posterior. Además, mantener mi código dividido en compartimientos de esta manera significa que puedo volver a un proyecto olvidado hace mucho tiempo y leer rápidamente load.R y averiguar qué datos necesito actualizar, y luego mirar do.R para determinar qué análisis se realizó.

Answer 7

Para crear informes personalizados, he encontrado que es ú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: buenos editores para preparar documentos 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 que dos estrategias son útiles:

• Lea sobre el flujo de trabajo de análisis (por ejemplo, ProjectTemplate , ideas de Josh Reich, mi propia presentación sobre Slides flujo de trabajo R y Video )
• Estudiar ejemplos de informes y discernir el flujo de trabajo
  • Ejemplos de Hadley Wickham
  • Mis ejemplos en github
  • Ejemplos de investigaciones reproducibles enumeradas en Cross Validated

Answer 8

Para escribir un informe preliminar rápido o un correo electrónico a un colega, me parece que puede ser muy eficiente copiar y pegar tramas en MS Word o en un correo electrónico o página wiki; a menudo es mejor una captura de pantalla de 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, escribir funciones R para regenerar fácilmente todas las tramas (como archivos) es muy importante. Se necesita más tiempo para 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.

Answer 9

Si desea ver algunos ejemplos, tengo algunos pequeños (y no tan pequeños) proyectos de análisis y limpieza 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 economía de combustible del EPI
• Una gran colección de datos sobre la crisis de la vivienda
• Clasificaciones de películas de IMDB
• Datos de venta de casas en el área de la bahía

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

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

Si realizo un informe formal, generalmente mantengo R y latex por separado, pero siempre me aseguro de poder source mi código R para producir todo el código y el resultado que necesito para el informe. Para el tipo de informes que hago, me resulta más fácil y más limpio que trabajar con látex.

Answer 10

Solo quería agregar, en caso de que alguien se lo haya perdido, que hay una gran publicación en el blog de aprendizaje sobre la creación de informes repetitivos con el paquete brew de Jeffrey Horner . Matt y Kevin mencionaron cerveza arriba. Realmente no lo he usado demasiado.

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

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

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

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

Answer 11

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

1. crea 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 utilizando devtools :: use_data (object_name). Luego compilo el paquete. A partir de ahora, la biblioteca de llamadas (package_name) hace que estos datos estén disponibles (y no se cargan hasta que sea necesario).

funciones: coloco 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).

do: creo un script que usa los datos y funciones almacenados en mi paquete. (Si los análisis solo tienen que hacerse una vez, puedo poner este script también en la subcarpeta / raw de datos, ejecutarlo y almacenar los resultados en el paquete para que sea más accesible).

Answer 12

Utilizo Sweave para el lado de producción de informes, pero también he estado escuchando sobre el paquete de preparación , aunque aún no lo he investigado.

Esencialmente, tengo una serie de encuestas para las que produzco estadísticas de resumen. Las mismas encuestas, los mismos informes cada vez. Construí una plantilla Sweave para los informes (lo que requiere un poco de trabajo). Pero una vez que el trabajo está terminado, tengo un guión R separado que me permite señalar los nuevos datos. Presiono "Ir", Sweave arroja algunos archivos .tex de puntaje, y ejecuto un pequeño script de Python para editarlos en pdf. Mi predecesor pasó ~ 6 semanas cada año en estos informes; Paso cerca de 3 días (principalmente en la limpieza de datos, los caracteres de escape son peligrosos).

Es muy posible que haya mejores enfoques ahora, pero si decides seguir esta ruta, házmelo saber - He estado pensando en poner algunos de mis cortes de Sweave, y eso sería una buena patada en los pantalones para hacer asi que.

Answer 13

Voy a sugerir algo en un tipo diferente de dirección de los otros remitentes, basado en el 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 los problemas 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 entradas / documentación de tickets como Redmine . Mantener los artefactos relacionados con el proyecto, como las tareas pendientes, los hilos de discusión y los archivos de datos / códigos versionados, puede ser una gran ayuda incluso para proyectos que están muy por fuera de la bailía de "programación" tradicional.

Answer 14

Yo uso plantillas de proyectos junto con R studio, actualmente mine contiene las siguientes carpetas:

• info : pdfs, powerpoints, docs ... que no serán utilizados por ningún script
• 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 en realidad se mostrarán a otra persona
• R : Todos los scripts R
• SAS : Porque a veces tengo que: ''(

Escribí funciones personalizadas para poder llamar a smart_save(x,y) o smart_load(x) para guardar o cargar RDS files smart_load(x) desde la carpeta de data output (archivos nombrados con nombres de variables) para que no me molesten los paths durante mi análisis .

Una función personalizada new_project crea una carpeta de proyecto numerada, copia todos los archivos de la plantilla, renombra el archivo RProj y edita las llamadas setwd , y establece el directorio de trabajo para el nuevo proyecto.

Todos los scripts R están en la carpeta R , estructurados de la siguiente manera:

00_main.R

• setwd
• llama guiones 1 a 5

00_functions.R

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

00_explore.R

• un montón de secuencias de comandos donde estoy probando cosas o explorando mis datos
• Es el único archivo donde puedo mezclar.

01_initialize.R

• Prellenado con una llamada a una secuencia de comandos initialize_general.R más general desde la carpeta de mi plantilla, que carga los paquetes y datos que siempre uso y no me importa tenerlos en mi espacio de trabajo
• carga 00_functions.R (prellenado)
• carga bibliotecas adicionales
• establecer variables globales

02_load data.R

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

03_pull data from DB.R

• Utiliza dbplyr para obtener tablas filtradas y agrupadas de la base de datos
• algunas líneas comentadas precompletas para configurar conexiones y buscar.
• Mantenga las operaciones del lado del cliente al mínimo
• Sin operaciones del lado del servidor fuera de este script
• Muestra qué archivos se han creado en el área de trabajo
• Guarda estas variables para que puedan volver a cargarse más rápido

Una vez hecho esto, query_db un query_db booleano y los datos se volverán a cargar desde RDS próxima vez.

Puede suceder que tenga que convertir los datos a DB, de ser así, crearé pasos adicionales.

04_Build.R

• dplyr datos, todo lo divertido dplyr / tidyr va allí
• muestra qué archivos se han creado en el área de trabajo
• guardar estas variables

Una vez que se ha hecho una vez que apago un booleano de build y los datos se volverán a cargar desde RDS próxima vez.

05_Analyse.R

• Resumir, modelar ...
• reportar archivos excel y csv

95_build ppt.R

• plantilla para el informe de Powerpoint usando el officer

96_prepare markdown.R

• setwd
• Cargar datos
• establecer los parámetros de reducción 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