Workflow pour l'analyse statistique et la rédaction de rapports

Quelqu'un a-t-il une idée des flux de travail pour l'analyse des données liées à la rédaction de rapports personnalisés? Le cas d'utilisation est essentiellement le suivant:

1. Le client commande un rapport qui utilise l'analyse des données, par exemple une estimation de la population et des cartes associées pour un district hydrographique.

2. L'analyste télécharge certaines données, assemble les données et enregistre le résultat (par exemple, en ajoutant une colonne pour la population par unité, ou en regroupant les données en fonction des limites du district).

3. L'analyste analyse les données créées dans (2), se rapproche de son objectif, mais voit que cela nécessite plus de données et revient donc à (1).

4. Rincer à plusieurs reprises jusqu'à ce que les tableaux et les graphiques répondent à l'AQ / CQ et satisfassent le client.

5. Rédiger un rapport intégrant des tableaux et des graphiques.

6. L'année prochaine, l'heureux client revient et souhaite une mise à jour. Cela devrait être aussi simple que de mettre à jour les données en amont par un nouveau téléchargement (par exemple, obtenir les permis de construire de l'année dernière), et d'appuyer sur un bouton «RECALCULER», sauf si les spécifications changent.

Pour le moment, je viens de démarrer un annuaire et de l'ad-hoc du mieux que je peux. Je voudrais une approche plus systématique, j'espère donc que quelqu'un a compris cela ... J'utilise un mélange de feuilles de calcul, d'outils SQL, ARCGIS, R et Unix.

Merci!

PS:

Vous trouverez ci-dessous un Makefile de base qui vérifie les dépendances sur divers ensembles de données intermédiaires (avec .RDatasuffixe) et scripts ( .Rsuffixe). Make utilise des horodatages pour vérifier les dépendances, donc si vous touch ss07por.csv, il verra que ce fichier est plus récent que tous les fichiers / cibles qui en dépendent, et exécutera les scripts donnés afin de les mettre à jour en conséquence. C'est toujours un travail en cours, y compris une étape de mise en base de données SQL, et une étape pour un langage de modélisation comme sweave. Notez que Make repose sur les onglets dans sa syntaxe, alors lisez le manuel avant de couper et coller. Profitez-en et donnez votre avis!

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> rapport.txt

Je décompose généralement mes projets en 4 morceaux:

1. load.R
2. propre.R
3. func.R
4. do.R

load.R: prend en charge le chargement de toutes les données requises. Il s'agit généralement d'un fichier court, lisant des données à partir de fichiers, d'URL et / ou d'ODBC. En fonction du projet à ce stade, j'écrirai l'espace de travail en utilisant save()ou je garderai simplement les choses en mémoire pour l'étape suivante.

clean.R: C'est là que vivent toutes les choses horribles - s'occuper des valeurs manquantes, fusionner des trames de données, gérer les valeurs aberrantes.

func.R: contient toutes les fonctions nécessaires pour effectuer l'analyse réelle. source()Ce fichier ne devrait avoir aucun effet secondaire autre que le chargement des définitions de fonction. Cela signifie que vous pouvez modifier ce fichier et le recharger sans avoir à revenir en arrière et répéter les étapes 1 et 2 qui peuvent prendre beaucoup de temps à s'exécuter pour de grands ensembles de données.

do.R: Appelle les fonctions définies dans func.R pour effectuer l'analyse et produire des graphiques et des tableaux.

La principale motivation de cette configuration est de travailler avec des données volumineuses, de sorte que vous ne voulez pas avoir à recharger les données à chaque fois que vous modifiez une étape ultérieure. De plus, garder mon code compartimenté comme celui-ci signifie que je peux revenir à un projet oublié depuis longtemps et lire rapidement load.R et déterminer quelles données j'ai besoin de mettre à jour, puis regarder do.R pour déterminer quelle analyse a été effectuée.

Si vous souhaitez voir quelques exemples, j'ai quelques petits (et pas si petits) projets de nettoyage et d'analyse de données disponibles en ligne. Dans la plupart des cas, vous trouverez un script pour télécharger les données, un pour les nettoyer et quelques-uns pour l'exploration et l'analyse:

• Noms de bébé de l'administration de la sécurité sociale
• Plus de 30 ans de données sur l'économie de carburant du PEV
• Une grande collection de données sur la crise du logement
• Classements de films de l'IMDB
• Données de vente de maisons dans la région de la baie

Récemment, j'ai commencé à numéroter les scripts, il est donc tout à fait évident dans quel ordre ils doivent être exécutés. (Si je me sens vraiment fantaisiste, je vais parfois faire en sorte que le script d'exploration appelle le script de nettoyage qui à son tour appelle le script de téléchargement, chacun effectuant le travail minimal nécessaire - généralement en vérifiant la présence de fichiers de sortie avec file.exists. Cependant, la plupart du temps, cela semble exagéré).

J'utilise git pour tous mes projets (un système de gestion de code source) donc c'est facile de collaborer avec les autres, de voir ce qui change et de revenir facilement aux versions précédentes.

Si je fais un rapport formel, je garde généralement R et latex séparés, mais je m'assure toujours que je peux sourcemon code R pour produire tout le code et la sortie dont j'ai besoin pour le rapport. Pour les types de rapports que je fais, je trouve cela plus facile et plus propre que de travailler avec du latex.

Je suis d'accord avec les autres intervenants: Sweave est excellent pour la rédaction de rapports avec R. Et reconstruire le rapport avec des résultats mis à jour est aussi simple que de rappeler la fonction Sweave. Il est complètement autonome, y compris toutes les analyses, données, etc. Et vous pouvez contrôler la version de l'ensemble du fichier.

J'utilise le plugin StatET pour Eclipse pour développer les rapports, et Sweave est intégré (Eclipse reconnaît le formatage de latex, etc.). Sous Windows, il est facile d'utiliser MikTEX .

J'ajouterais également que vous pouvez créer de beaux rapports avec Beamer . Créer un rapport normal est tout aussi simple. J'ai inclus un exemple ci-dessous qui extrait des données de Yahoo! et crée un graphique et un tableau (en utilisant quantmod). Vous pouvez créer ce rapport comme ceci:

Sweave(file = "test.Rnw")

Voici le document Beamer lui-même:

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

Je voulais juste ajouter, au cas où quelqu'un l'aurait manqué, qu'il y a un excellent article sur le blog d'apprentissage sur la création de rapports répétitifs avec le package de brassage de Jeffrey Horner . Matt et Kevin ont tous deux mentionné le breuvage ci-dessus. Je ne l'ai pas beaucoup utilisé moi-même.

Les entrées suivent un bon flux de travail, donc cela vaut la peine d'être lu:

1. Préparez les données.
2. Préparez le modèle de rapport.
3. Produisez le rapport.

En fait, produire le rapport une fois les deux premières étapes terminées est très simple:

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

Pour créer des rapports personnalisés, j'ai trouvé utile d'incorporer de nombreux conseils existants suggérés ici.

Génération de rapports: une bonne stratégie pour générer des rapports implique la combinaison de Sweave, make et R.

Editeur: Les bons éditeurs pour la préparation des documents Sweave comprennent:

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

Organisation du code: En termes d'organisation du code, je trouve deux stratégies utiles:

• En savoir plus sur le flux de travail d'analyse (par exemple, ProjectTemplate , les idées de Josh Reich, ma propre présentation sur les diapositives et la vidéo du flux de travail R )
• Étudier des exemples de rapports et discerner le flux de travail
  • Exemples de Hadley Wickham
  • Mes exemples sur github
  • Exemples de recherches reproductibles listées sur Cross Validated

J'utilise Sweave pour la production de rapports, mais j'ai également entendu parler du paquet de bière - même si je ne l'ai pas encore examiné.

Essentiellement, j'ai un certain nombre d'enquêtes pour lesquelles je produis des statistiques sommaires. Mêmes enquêtes, mêmes rapports à chaque fois. J'ai construit un modèle Sweave pour les rapports (ce qui demande un peu de travail). Mais une fois le travail terminé, j'ai un script R séparé qui me permet de signaler les nouvelles données. J'appuie sur "Go", Sweave vide quelques fichiers .tex de score, et j'exécute un petit script Python pour tous les pdflatex. Mon prédécesseur a passé environ 6 semaines chaque année sur ces rapports; Je passe environ 3 jours (principalement sur le nettoyage des données; les caractères d'échappement sont dangereux).

Il est très possible qu'il y ait de meilleures approches maintenant, mais si vous décidez d'emprunter cette voie, faites-le moi savoir - j'ai eu l'intention de mettre en place certains de mes hacks Sweave, et ce serait un bon coup de pied dans le pantalon à faire donc.

Je vais suggérer quelque chose dans une direction différente de celle des autres soumissionnaires, sur la base du fait que vous avez posé des questions spécifiquement sur le flux de travail du projet plutôt que sur les outils . En supposant que vous soyez relativement satisfait de votre modèle de production de documents, il semble que vos défis soient davantage centrés sur les problèmes de suivi des versions, de gestion des actifs et de processus de révision / publication.

Si cela semble correct, je suggérerais de chercher dans un outil intégré de gestion des tickets / source / documentation comme Redmine . Conserver ensemble les artefacts de projet associés tels que les tâches en attente, les fils de discussion et les fichiers de données / code versionnés peut être d'une grande aide même pour des projets bien en dehors du bailliage traditionnel de la «programmation».

Convenu que Sweave est la voie à suivre, avec xtable pour générer des tables LaTeX. Bien que je n'ai pas passé trop de temps à travailler avec eux, le package tikzDevice récemment publié semble vraiment prometteur, en particulier lorsqu'il est associé à pgfSweave (qui, pour autant que je sache, n'est disponible que sur rforge.net pour le moment - il existe un lien vers r-forge à partir de là, mais cela ne répond pas pour moi pour le moment).

Entre les deux, vous obtiendrez une mise en forme cohérente entre le texte et les figures (polices, etc.). Avec Brew, ceux-ci pourraient constituer le Saint Graal de la génération de rapports.

À un niveau plus «méta», vous pourriez être intéressé par le modèle de processus CRISP-DM .

"make" est génial parce que (1) vous pouvez l'utiliser pour tout votre travail dans n'importe quelle langue (contrairement, disons, Sweave et Brew), (2) il est très puissant (assez pour construire tous les logiciels sur votre machine), et (3) cela évite de répéter le travail. Ce dernier point est important pour moi car une grande partie du travail est lente; quand je latex un fichier, j'aime voir le résultat en quelques secondes, pas l'heure qu'il faudrait pour recréer les chiffres.

J'utilise des modèles de projet avec R studio, actuellement le mien contient les dossiers suivants:

• info : pdfs, powerpoints, docs ... qui ne seront utilisés par aucun script
• data input : données qui seront utilisées par mes scripts mais non générées par eux
• data output : données générées par mes scripts pour une utilisation ultérieure mais pas comme un rapport approprié.
• reports : Seuls les fichiers qui seront réellement montrés à quelqu'un d'autre
• R : Tous les scripts R
• SAS : Parce que je dois parfois: '(

J'ai écrit des fonctions personnalisées afin de pouvoir appeler smart_save(x,y)ou smart_load(x)enregistrer ou charger RDS filesvers et depuis le data outputdossier (fichiers nommés avec des noms de variables) afin que je ne sois pas dérangé parpaths pendant mon analyse.

Une fonction personnalisée new_projectcrée un dossier de projet numéroté, copie tous les fichiers du modèle, renomme le RProjfichier et modifie les setwdappels, et définit le répertoire de travail sur un nouveau projet.

Tous les Rscripts sont dans le Rdossier, structuré comme suit:

00_main.R

• setwd
• appelle les scripts 1 à 5

00_functions.R

• Toutes les fonctions et seules les fonctions y vont, s'il y en a trop, je vais les séparer en plusieurs, toutes nommées comme 00_functions_something.R, en particulier si je prévois de faire un paquet à partir de certaines d'entre elles, je les mettrai à part

00_explore.R

• un tas de morceaux de script où je teste des choses ou explore mes données
• C'est le seul fichier où je suis autorisé à être en désordre.

01_initialize.R

• Pré-rempli avec un appel à un initialize_general.Rscript plus général depuis mon dossier de modèles qui charge les packages et les données que j'utilise toujours et que cela ne me dérange pas d'avoir dans mon espace de travail
• charges 00_functions.R(préremplies)
• charge des bibliothèques supplémentaires
• définir des variables globales

02_load data.R

• charges csv/txt xlsx RDS, il y a une ligne commentée préremplie pour chaque type de fichier
• affiche les fichiers qui ont été créés dans l'espace de travail

03_pull data from DB.R

• Utilise dbplyrpour récupérer les tables filtrées et groupées de la base de données
• quelques lignes commentées préremplies pour configurer les connexions et récupérer.
• Gardez les opérations côté client au strict minimum
• Aucune opération côté serveur en dehors de ce script
• Affiche les fichiers créés dans l'espace de travail
• Enregistre ces variables afin qu'elles puissent être rechargées plus rapidement

Une fois que c'est fait, une fois que j'éteins un query_dbbooléen et que les données seront rechargées à partir deRDSprochaine fois.

Il peut arriver que je doive refaire des données vers des bases de données, si c'est le cas, je vais créer des étapes supplémentaires.

04_Build.R

• Data wrangling, tout le plaisir dplyr/ tidyrtout y va
• affiche les fichiers créés dans l'espace de travail
• enregistrer ces variables

Une fois que cela a été fait, buildj'éteins un booléen et les données seront rechargées la RDSprochaine fois.

05_Analyse.R

• Résumez, modélisez ...
• rapport excelet csvfichiers

95_build ppt.R

• modèle de rapport PowerPoint utilisant officer

96_prepare markdown.R

• setwd
• charger des données
• définir les paramètres de démarque si nécessaire
• render

97_prepare shiny.R

• setwd
• charger des données
• définir des paramètres de brillance si nécessaire
• runApp

98_Markdown report.Rmd

• Un modèle de rapport

99_Shiny report.Rmd

• Un modèle d'application

Pour rédiger rapidement un rapport préliminaire ou un e-mail à un collègue, je trouve qu'il peut être très efficace de copier-coller des graphiques dans MS Word ou dans un e-mail ou une page wiki - souvent, le mieux est une capture d'écran bitmap (par exemple sur mac, Apple -Shift- (Ctrl) -4). Je pense que c'est une technique sous-estimée.

Pour un rapport plus final, écrire des fonctions R pour régénérer facilement tous les tracés (sous forme de fichiers) est très important. Cela prend plus de temps pour coder cela.

Sur les problèmes de flux de travail plus larges, j'aime la réponse de Hadley sur l'énumération des fichiers de code / données pour le flux de nettoyage et d'analyse. Tous mes projets d'analyse de données ont une structure similaire.

J'ajouterai ma voix pour sweaver. Pour une analyse complexe et en plusieurs étapes, vous pouvez utiliser un fichier Make pour spécifier les différentes parties. Peut éviter d'avoir à répéter toute l'analyse si une seule partie a changé.

Je fais aussi ce que fait Josh Reich, seulement je le fais en créant mes R-packages personnels, car cela m'aide à structurer mon code et mes données, et il est également assez facile de les partager avec d'autres.

1. créer mon package
2. charge
3. nettoyer
4. les fonctions
5. faire

création de mon package: devtools :: create ('package_name')

load and clean: Je crée des scripts dans le sous-dossier data-raw / de mon package pour charger, nettoyer et stocker les objets de données résultants dans le package en utilisant devtools :: use_data (object_name). Ensuite, je compile le package. Désormais, l'appel de la bibliothèque (package_name) rend ces données disponibles (et elles ne sont chargées que lorsque cela est nécessaire).

fonctions: je place les fonctions pour mes analyses dans le sous-dossier R / de mon package, et n'exporte que celles qui doivent être appelées de l'extérieur (et non les fonctions d'assistance, qui peuvent rester invisibles).

faire: je crée un script qui utilise les données et les fonctions stockées dans mon package. (Si les analyses ne doivent être effectuées qu'une seule fois, je peux également mettre ce script dans le sous-dossier data-raw /, l'exécuter et stocker les résultats dans le package pour le rendre facilement accessible.)