web-dev-qa-db-fra.com

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

Quelqu'un at-il une quelconque sagesse en matière de flux de travail pour l'analyse de données liée à la rédaction de rapports personnalisés? Le cas d'utilisation est fondamentalement ceci:

  1. Le client commande un rapport qui utilise l'analyse de 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, les compile et enregistre le résultat (par exemple, en ajoutant une colonne pour la population par unité ou en sous-configurant 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 qu'il a besoin de plus de données et revient donc à (1).

  4. Rincez à nouveau jusqu'à ce que les tableaux et les graphiques répondent aux critères QA/QC et satisfont 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 amont par un nouveau téléchargement (par exemple, obtenir les permis de construire de la dernière année) et d'appuyer sur un bouton "RECALCULER", à moins que les spécifications ne changent.

Pour le moment, je commence un répertoire et je l’adapte du mieux que je peux. Je souhaiterais une approche plus systématique, j'espère donc que quelqu'un l'aura compris ... J'utilise un mélange de feuilles de calcul, d'outils SQL, ARCGIS, R et Unix.

Merci!

PS:

Voici un Makefile de base qui vérifie les dépendances sur divers jeux de données intermédiaires (w/.RData suffixe) et les scripts (.R suffixe). 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. Il s’agit toujours d’un travail en cours, comprenant une étape pour la mise en base de données SQL et une étape pour un langage de modélisation tel que sweave. Notez que Make utilise des onglets dans sa syntaxe, lisez donc le manuel avant de couper et de coller. Profitez et donnez vos commentaires!

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 Fonctions .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. SMS
rstatisticsdata-visualization
179
forkandwait

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

  1. charge.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 contenant des données de fichiers, d’URL et/ou ODBC. En fonction du projet à ce stade, je vais écrire l'espace de travail à l'aide de save() ou tout simplement garder les éléments en mémoire pour l'étape suivante.

clean.R: C’est là que vit tout ce qui est laid - 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. 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, répétez les étapes 1 2, qui peuvent prendre beaucoup de temps à exécuter pour des ensembles de données volumineux.

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 sans avoir à recharger les données chaque fois que vous modifiez une étape ultérieure. En outre, en gardant mon code compartimenté de cette manière, je peux revenir à un projet oublié depuis longtemps, lire rapidement load.R, déterminer les données à mettre à jour, puis consulter do.R pour déterminer les analyses effectuées.

193
Josh Reich

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

Récemment, j'ai commencé à numéroter les scripts, il est donc parfaitement évident dans quel ordre ils doivent être exécutés. (Si je me sens vraiment mal à l'aise, 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 excessif).

J'utilise git pour tous mes projets (un système de gestion de code source), il est donc facile de collaborer avec d'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 de pouvoir source mon 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.

94
hadley

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

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

Je voudrais aussi ajouter que vous pouvez créer de beaux rapports avec Beamer . La création d'un rapport normal est tout aussi simple. J'ai inclus un exemple ci-dessous qui extrait les données de Yahoo! et crée un graphique et une table (en utilisant quantmod). Vous pouvez construire ce rapport comme suit:

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}
17
Shane

Je voulais juste ajouter, au cas où quelqu'un l'aurait manqué, que il y a un article génial sur le blog de learnr sur la création de rapports répétitifs avec le paquet infusion de Jeffrey Horner . Matt et Kevin ont tous deux mentionné la bière ci-dessus. Je ne l'ai pas vraiment beaucoup utilisé moi-même.

Les entrées suivent un workflow de Nice, ça vaut donc la peine d'être lu:

  1. Préparez les données.
  2. Préparez 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)
16
Shane

Pour la création de rapports personnalisés, j'ai trouvé utile d'intégrer bon nombre des astuces existantes suggérées 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 rédacteurs pour la préparation de documents Sweave incluent:

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

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

14
Jeromy Anglim

Je vais suggérer quelque chose dans un sens différent des autres auteurs, en vous basant sur le fait que vous avez posé une question précise sur le flux de travail du projet , plutôt que sur 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 de version, de gestion des ressources et de processus de révision/publication.

Si cela semble correct, je suggérerais de rechercher un outil intégré de billetterie/gestion de source/documentation comme Redmine . Garder les artefacts de projet associés tels que les tâches en attente, les fils de discussion et les fichiers de données/codes versionnés peut être d'une grande aide, même pour des projets bien en dehors du système traditionnel de "programmation".

7
rcoder

J'utilise Sweave pour la partie rapportant ceci, mais j'ai aussi entendu parler du paquet breuvage - bien que je ne l'aie pas encore examiné.

J'ai essentiellement un certain nombre d'enquêtes pour lesquelles je produis des statistiques sommaires. Mêmes sondages, mêmes rapports à chaque fois. J'ai construit un modèle Sweave pour les rapports (ce qui nécessite un peu de travail). Mais une fois le travail terminé, j’ai un script R distinct qui me permet de signaler les nouvelles données. J'appuie sur "Go", Sweave efface quelques fichiers .tex de partition et exécute un petit script Python pour les pdflatex. Tous les ans, mon prédécesseur passait environ 6 semaines à ces rapports; je passer environ 3 jours (principalement sur le nettoyage des données; les caractères d'échappement sont dangereux).

Il est très possible qu'il existe de meilleures approches maintenant, mais si vous décidez de suivre cette voie, faites-le-moi savoir - je voulais vous présenter certains de mes piratages Sweave, et ce serait un bon coup de pied à faire alors.

7
Matt Parker

Convenu que Sweave est la voie à suivre, avec xtable pour générer des tables LaTeX. Bien que je n’aie pas passé beaucoup de temps à travailler avec eux, le package récemment publié tikzDevice semble très prometteur, en particulier s’il est associé à pgfSweave (qui, autant que je sache, est disponible uniquement sur rforge.net pour le moment - il existe un lien vers r-forge à partir de là, mais il ne répond pas pour moi pour le 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 la génération de rapports.

5
kmm

"make" est génial car (1) vous pouvez l’utiliser pour tous vos travaux dans n’importe quelle langue (contrairement à Sweave and Brew, par exemple), (2) il est très puissant (suffit à 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 beaucoup de travail est lent; Quand je colle un fichier au latex, j'aime voir le résultat en quelques secondes, pas l'heure qu'il faudrait pour recréer les chiffres.

4
dank

À un niveau plus "méta", le modèle de processus CRISP-DM pourrait vous intéresser.

4
Jouni K. Seppänen

Pour rédiger un rapport préliminaire rapide ou envoyer un e-mail à un collègue, je trouve qu'il peut être très efficace de copier-coller des tracés dans MS Word ou dans un e-mail ou une page wiki. Le mieux est souvent 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 ceci.

Sur les problèmes de flux de travail plus importants, j'aime bien 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.

2
Brendan OConnor

J'utilise des modèles de projet avec R studio, le mien contient actuellement 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 ceux-ci
  • 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 pour pouvoir appeler smart_save(x,y) ou smart_load(x) afin de sauvegarder ou de charger RDS files Dans et à partir du dossier data output (Fichiers nommés avec des noms de variable). ) donc je ne suis pas dérangé par paths lors de 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, édite les appels setwd et définit le répertoire de travail du nouveau projet. .

Tous les scripts R se trouvent dans le dossier R, structuré comme suit:

00_main.R
  • setwd
  • appelle les scripts 1 à 5
00_functions.R
  • Toutes les fonctions et seulement les fonctions y vont, s'il y en a trop, je les sépare en plusieurs, toutes nommées comme 00_functions_something.R, En particulier si je prévois d'en faire un paquet, 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 script initialize_general.R Plus général à partir de mon dossier de modèles, qui charge les packages et les données que j'utilise toujours et que je n'ai pas d'objection à avoir dans mon espace de travail
  • charges 00_functions.R (pré-rempli)
  • charge des bibliothèques supplémentaires
  • définir des variables globales
02_load data.R
  • charges csv/txtxlsxRDS, il existe une ligne commentée préremplie pour chaque type de fichier
  • affiche quels fichiers ont été créés dans l'espace de travail
03_pull data from DB.R
  • Utilise dbplyr pour extraire des tables filtrées et groupées de la base de données
  • certaines lignes commentées préremplies pour établir des connexions et récupérer.
  • Maintenir les opérations côté client au strict minimum
  • Aucune opération côté serveur en dehors de ce script
  • Affiche quels fichiers ont été créés dans l'espace de travail
  • Enregistre ces variables pour qu'elles puissent être rechargées plus rapidement

Une fois que c'est fait une fois, j'éteins un booléen query_db Et les données seront rechargées à partir de RDS la prochaine fois.

Il se peut que je doive ré-alimenter des données dans des bases de données. Si c'est le cas, je créerai des étapes supplémentaires.

04_Build.R
  • Des conflits de données, tout le plaisir dplyr/tidyr
  • affiche quels fichiers ont été créés dans l'espace de travail
  • enregistrer ces variables

Une fois que cela a été fait, j’éteins un build booléen et les données seront rechargées à partir de RDS la prochaine fois.

05_Analyse.R
  • Résumer, modéliser ...
  • rapporte les fichiers Excel et csv
95_build ppt.R
  • modèle pour le rapport PowerPoint utilisant officer
96_prepare markdown.R
  • setwd
  • charger des données
  • définir des paramètres de démarcation si nécessaire
  • render
97_prepare shiny.R
  • setwd
  • charger des données
  • 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
2
Moody_Mudskipper

Je vais ajouter ma voix à gonfler. Pour une analyse complexe en plusieurs étapes, vous pouvez utiliser un makefile pour spécifier les différentes parties. Peut éviter d'avoir à répéter toute l'analyse si une partie seulement a changé.

2
PaulHurleyuk

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

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

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

load and clean: je crée des scripts dans le sous-dossier data-raw/de mon paquet pour charger, nettoyer et stocker les objets de données résultants dans le paquet en utilisant devtools :: use_data (nom_objet). Ensuite, je compile le paquet. À partir de maintenant, l'appel de la bibliothèque (nom_package) rend ces données disponibles (et elles ne sont chargées que si nécessaire).

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

do: 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 placer ce script dans le sous-dossier data-raw /, le lancer et stocker les résultats dans le package pour le rendre facilement accessible.)

0
jciloa