Flux de travail pour l'analyse statistique et la rédaction de rapport

si vous voulez voir quelques exemples, j'ai quelques petits (et pas si petits) projets de nettoyage et d'analyse de données disponibles en ligne. En plus, vous trouverez un script pour télécharger les données, une pour le nettoyer, et un peu de faire de l'exploration et de l'analyse:

• des noms de Bébés à partir de l'administration de la sécurité sociale
• 30 ans d'économie de carburant des données de l'EPI
• Une grande collection de données sur la crise du logement
• notes de films de L'IMDB
• données sur les ventes 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 envie je vais parfois faire en sorte que le script d'exploration appellera le nettoyage script qui à son tour appelle le script de téléchargement, chacun faisant 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 d'autres, voir ce qui change et facilement revenir aux versions précédentes.

si je fais un rapport officiel, je garde habituellement R et latex séparés, mais je assurez-vous toujours que je peux source mon code R pour produire tout le code et la sortie dont j'ai besoin pour le rapport. Pour le genre 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 répondants: Sweave est excellent pour la rédaction de rapport avec R. et reconstruire le rapport avec des résultats mis à jour est aussi simple que de Ré-appeler 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 latex formating, etc). Sur Windows, c'est facile à utiliser MikTEX .

je voudrais ajouter, que vous pouvez créer de beaux rapports avec le Beamer . Créer un rapport normal est tout aussi simple. J'ai inclus un exemple ci-dessous qui tire des données de Yahoo! et crée un graphique et une table (en utilisant quantmod). Vous pouvez construire 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é, que il y a un grand post sur le blog learnr sur la création de rapports répétitifs avec paquet brew de Jeffrey Horner . Matt et Kevin ont tous deux mentionné brew ci-dessus. Je ne l'ai pas vraiment utilisé moi-même.

les entrées suivent un flux de travail agréable, il est donc bien intéressant de lire:

1. préparer les données.
2. préparer le modèle de rapport.
3. produire le rapport.

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'intégrer plusieurs des 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.

Éditeur:

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

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

• se renseigner sur le déroulement du travail d'analyse (par exemple, ProjectTemplate , Les idées de Josh Reich, ma propre présentation sur R workflow Slides et Vidéo )
• étudier des exemples de rapports et discerner le flux de travail
  • Hadley Wickham les exemples de
  • mes exemples sur github
  • exemples de recherche reproductible figurant sur la liste de validation croisée

j'utilise Sweave pour le rapport produisant côté de cela, mais j'ai aussi entendu parler de la brassage paquet - bien que je n'ai pas encore penché sur elle.

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 Sweave modèle pour les rapports (qui prend un peu de travail). Mais une fois le travail terminé, j'ai un script R séparé qui me permet signalez les nouvelles données. J'appuie sur "Go", Sweave sort quelques points .les fichiers tex, et j'exécute un petit script Python pour les pdflatex. Mon prédécesseur a passé ~6 semaines chaque année sur ces rapports; je passe environ 3 jours (principalement sur les données de nettoyage; caractères de fuite 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 pour le faire.

je vais suggérer quelque chose dans une direction différente de celle des autres déclarants, basé sur le fait que vous avez demandé spécifiquement sur flux de travail du projet , plutôt que outils . En présumant que vous êtes relativement satisfait de votre modèle de production de documents, il semble que vos défis soient davantage axés sur les questions de suivi de version, de gestion des biens et de processus de révision/publication.

si cela cela semble correct, je suggère d'examiner un outil intégré de billetterie / gestion des sources/documentation comme Redmine . Conserver ensemble des artefacts liés au projet, tels que les tâches en attente, les fils de discussion et les fichiers de données/code suivis en versions, peut être d'une grande aide, même pour des projets bien en dehors du traditionnel "Bailliage de programmation".

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

entre les deux, vous obtiendrez un formatage cohérent entre le texte et les figures (polices, etc.). Avec brew, ceux-ci pourraient constituer le Saint Graal de génération de rapport.

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

"faire" est grande, parce que (1) vous pouvez l'utiliser pour tous vos travaux dans n'importe quelle langue (contrairement, disons, Sweave et Brew), (2) il est très puissant (à la construction de tous les logiciels installés sur votre machine), et (3) il évite de répéter le travail. Ce dernier point est important pour moi parce que beaucoup de travail est lent; quand j'ai un fichier latex, j'aime voir le résultat dans quelques secondes, pas l'heure qu'il faudrait pour recréer les chiffres.

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

pour un rapport plus final, il est très important d'écrire des fonctions R pour régénérer facilement toutes les placettes (sous forme de fichiers). Il ne faudra plus de temps pour coder.

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

j'ajouterai ma voix à sweave. Pour une analyse complexe en plusieurs étapes, vous pouvez utiliser un makefile pour spécifier les différentes parties. Peut empêcher d'avoir à répéter toute l'analyse si une seule partie a changé.

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

• info : pdf, présentations powerpoint, documents... qui ne sera utilisé par aucun script
• data input : données qui seront utilisées par mes scripts mais qui ne seront pas générées par eux
• data output : données générées par mes scripts pour utilisation ultérieure mais pas comme un rapport approprié.
• reports : seuls les fichiers qui seront réellement affichés à quelqu'un d'autre
• R : tous les scripts R
• SAS : parce que je dois parfois: "(

j'ai écrit des fonctions personnalisées pour que je puisse appeler smart_save(x,y) ou smart_load(x) pour enregistrer ou charger RDS files vers et depuis le dossier data output (fichiers nommés avec des noms variables) donc je ne suis pas gêné par paths pendant mon analyse.

une fonction personnalisée new_project crée un dossier de projet numéroté, copie tous les fichiers du modèle, renomme le fichier RProj et édite les appels setwd , et définit le répertoire de travail à nouveau projet.

tous les scripts R sont dans le dossier R , structuré comme suit:

---

00_main.R

• setwd
• appels scripts 1 à 5

---

00_functions.R

• toutes les fonctions et seulement les fonctions vont là, s'il y en a trop je vais le séparer en plusieurs, tous nommés comme 00_functions_something.R , en particulier si je projette de faire un paquet de certains d'entre eux je vais les mettre à part

---

00_explore.R

• un tas de morceaux de script où je teste des choses ou j'explore mes données
• c'est le seul dossier où j'ai le droit d'être bordélique.

---

01_initialize.R

• pré-rempli avec un appel à un script plus général initialize_general.R de mon dossier de modèle qui charge les paquets et les données que j'utilise toujours et ne vous dérange pas d'avoir dans mon espace de travail
• charges 00_functions.R (remplies au préalable)
• charge bibliothèques supplémentaires
• ensemble variables globales

---

02_load data.R

• charges csv/txt xlsx RDS , il y a une ligne commentée 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 dbplyr pour récupérer des tableaux filtrés et groupés du DB
• quelques lignes commentées remplies au préalable pour configurer les connexions et le fetch.
• garder les opérations côté client au strict minimum
• Pas de côté de serveur d'opérations en dehors de ce script
• affiche les fichiers qui ont été 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 booléen query_db et les données seront rechargées de RDS la prochaine fois.

il peut arriver que je doive rediriger des données vers DBs, si c'est le cas, je vais créer des étapes supplémentaires.

---

04_Build.R

"1519530920 de Données", les disputes, tout le plaisir dplyr / tidyr choses là
• affiche les fichiers qui ont été créés dans l'espace de travail
• enregistrer ces variables

une fois que c'est fait une fois que j'ai éteint un booléen build et les données seront rechargées de RDS la prochaine fois.

---

05_Analyse.R

• Résumer, le modèle...
• report excel et csv files

---

95_build ppt.R

• modèle de rapport powerpoint utilisant officer

---

96_prepare markdown.R

• setwd
• données de charge
• définir les paramètres de markdown si nécessaire
• render

---

97_prepare shiny.R

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

---

98_Markdown report.Rmd

• Un modèle de rapport

---

99_Shiny report.Rmd

• Un modèle d'application

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

1. créer mon paquet
2. charge
3. propre
4. fonctions
5. faire

créer mon paquet: devtools:: create ('package_name')

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

fonctions: j'ai mis les fonctions pour mes analyses dans le R/ sous-dossier de mon paquet, et n'exporte que celles qui doivent être appelées à partir extérieur (et non les fonctions d'aide, qui peuvent rester invisibles).

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