Flusso di lavoro per analisi statistiche e stesura di report

Qualcuno ha saggezza sui flussi di lavoro per l'analisi dei dati relativi alla scrittura di report personalizzati? Il caso d'uso è sostanzialmente questo:

1. Il cliente commissiona un rapporto che utilizza l'analisi dei dati, ad esempio una stima della popolazione e mappe correlate per un distretto idrico.

2. L'analista scarica alcuni dati, mescola i dati e salva il risultato (ad es. Aggiungendo una colonna per popolazione per unità o sottoponendo i dati in base ai confini del distretto).

3. L'analista analizza i dati creati in (2), si avvicina al suo obiettivo, ma vede che ha bisogno di più dati e quindi torna a (1).

4. Risciacquare ripetizione fino a quando le tabelle e la grafica non soddisfano il QA / QC e soddisfano il cliente.

5. Scrivi un rapporto che includa tabelle e grafici.

6. L'anno prossimo il cliente felice ritorna e desidera un aggiornamento. Questo dovrebbe essere semplice come aggiornare i dati a monte con un nuovo download (ad esempio ottenere i permessi di costruzione dall'ultimo anno) e premere un pulsante "Ricalcola", a meno che le specifiche non cambino.

Al momento, ho appena avviato una directory e ad hoc la migliore possibile. Vorrei un approccio più sistematico, quindi spero che qualcuno l'abbia capito ... Uso un mix di fogli di calcolo, strumenti SQL, ARCGIS, R e Unix.

Grazie!

PS:

Di seguito è riportato un Makefile di base che verifica le dipendenze da vari set di dati intermedi (con .RDatasuffisso) e script ( .Rsuffisso). Make utilizza i timestamp per controllare le dipendenze, quindi, se lo fai touch ss07por.csv, vedrà che questo file è più recente di tutti i file / destinazioni che dipendono da esso ed esegue gli script forniti per aggiornarli di conseguenza. Questo è ancora un lavoro in corso, incluso un passaggio per l'inserimento nel database SQL e un passaggio per un linguaggio di modello come sweave. Nota che Make si basa sulle schede nella sua sintassi, quindi leggi il manuale prima di tagliare e incollare. Divertiti e dai un feedback!

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

In genere divido i miei progetti in 4 pezzi:

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

load.R: si occupa del caricamento di tutti i dati richiesti. In genere si tratta di un breve file, che legge i dati da file, URL e / o ODBC. A seconda del progetto, a questo punto, scriverò l'area di lavoro usando save()o semplicemente terrò le cose in memoria per il passaggio successivo.

clean.R: Qui vivono tutte le cose brutte: prendersi cura dei valori mancanti, unire i frame di dati, gestire i valori anomali.

func.R: contiene tutte le funzioni necessarie per eseguire l'analisi effettiva. source()'questo file non dovrebbe avere effetti collaterali oltre a caricare le definizioni delle funzioni. Ciò significa che è possibile modificare questo file e ricaricarlo senza dover ripetere i passaggi 1 e 2 che possono richiedere molto tempo per l'esecuzione di set di dati di grandi dimensioni.

do.R: chiama le funzioni definite in func.R per eseguire l'analisi e produrre grafici e tabelle.

La motivazione principale per questa configurazione è quella di lavorare con dati di grandi dimensioni in cui non si desidera ricaricare i dati ogni volta che si passa a un passaggio successivo. Inoltre, mantenere il mio codice suddiviso in compartimenti in questo modo significa che posso tornare a un progetto a lungo dimenticato e leggere rapidamente load.R ed elaborare quali dati devo aggiornare, quindi guardare do.R per capire quale analisi è stata eseguita.

Se vuoi vedere alcuni esempi, ho alcuni piccoli (e non così piccoli) progetti di pulizia e analisi dei dati disponibili online. Nella maggior parte, troverai uno script per scaricare i dati, uno per ripulirlo e alcuni per fare esplorazione e analisi:

• Nomi del bambino dall'amministrazione della sicurezza sociale
• Oltre 30 anni di dati di risparmio di carburante dall'EPI
• Una grande raccolta di dati sulla crisi immobiliare
• Classificazioni dei film dall'IMDB
• Dati di vendita di case nella Bay Area

Di recente ho iniziato a numerare gli script, quindi è del tutto ovvio in quale ordine dovrebbero essere eseguiti. (Se mi sento davvero di fantasia a volte lo farò in modo che lo script di esplorazione chiamerà lo script di pulizia che a sua volta chiama lo script di download, ognuno facendo il minimo lavoro necessario, di solito controllando la presenza di file di output con file.exists. Tuttavia, la maggior parte delle volte sembra eccessivo).

Uso git per tutti i miei progetti (un sistema di gestione del codice sorgente), quindi è facile collaborare con gli altri, vedere cosa sta cambiando e tornare facilmente alle versioni precedenti.

Se eseguo un report formale, di solito mantengo separati R e latex, ma mi assicuro sempre di poter utilizzare il sourcemio codice R per produrre tutto il codice e l'output necessari per il report. Per il tipo di rapporti che faccio, lo trovo più facile e più pulito che lavorare con il lattice.

Concordo con gli altri rispondenti: Sweave è eccellente per scrivere report con R. E ricostruire il report con risultati aggiornati è semplice come richiamare la funzione Sweave. È completamente autonomo, comprese tutte le analisi, i dati, ecc. E puoi controllare la versione dell'intero file.

Uso il plugin StatET per Eclipse per lo sviluppo dei report e Sweave è integrato (Eclipse riconosce la formattazione del lattice, ecc.). Su Windows, è facile usare MikTEX .

Vorrei anche aggiungere che puoi creare bellissimi report con Beamer . La creazione di un rapporto normale è altrettanto semplice. Ho incluso un esempio di seguito che estrae i dati da Yahoo! e crea un grafico e una tabella (usando quantmod). Puoi creare questo rapporto in questo modo:

Sweave(file = "test.Rnw")

Ecco il documento Beamer stesso:

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

Volevo solo aggiungere, nel caso in cui qualcuno lo avesse mancato, che sul blog di Learnr ci fosse un ottimo post sulla creazione di rapporti ripetitivi con il pacchetto di birra di Jeffrey Horner . Matt e Kevin hanno menzionato entrambi la birra sopra. Non l'ho usato molto da solo.

Le voci seguono un buon flusso di lavoro, quindi vale la pena leggere:

1. Prepara i dati.
2. Preparare il modello di report.
3. Produrre il rapporto.

Realizzare il rapporto una volta completati i primi due passaggi è molto semplice:

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

Per la creazione di report personalizzati, ho trovato utile incorporare molti dei suggerimenti esistenti suggeriti qui.

Generazione di report: una buona strategia per la generazione di report prevede la combinazione di Sweave, make e R.

Editor: buoni editor per la preparazione di documenti Sweave includono:

• StatET ed Eclipse
• Emacs ed ESS
• Vim e Vim-R
• R Studio

Organizzazione del codice: in termini di organizzazione del codice, trovo utili due strategie:

• Leggi il flusso di lavoro di analisi (ad esempio, ProjectTemplate , idee di Josh Reich, la mia presentazione su diapositive e video sul flusso di lavoro R )
• Studiare esempi di report e discernere il flusso di lavoro
  • Gli esempi di Hadley Wickham
  • I miei esempi su github
  • Esempi di ricerche riproducibili elencate su Cross Validated

Uso Sweave per la produzione di report, ma ho anche sentito parlare del pacchetto brew , anche se non l'ho ancora esaminato.

In sostanza, ho una serie di sondaggi per i quali produco statistiche riassuntive. Stessi sondaggi, stessi rapporti ogni volta. Ho creato un modello Sweave per i report (che richiede un po 'di lavoro). Ma una volta terminato il lavoro, ho uno script R separato che mi consente di evidenziare i nuovi dati. Premo "Go", Sweave scarica alcuni file .tex di punteggio e eseguo un piccolo script Python per pdflatex tutti. Il mio predecessore trascorreva ~ 6 settimane all'anno su questi rapporti; Trascorro circa 3 giorni (principalmente sulla pulizia dei dati; i caratteri di escape sono pericolosi).

È molto probabile che ora ci siano approcci migliori, ma se decidi di seguire questa strada, fammi sapere - avevo intenzione di mettere su alcuni dei miei hack Sweave, e sarebbe un bel calcio nei pantaloni da fare così.

Suggerirò qualcosa in una direzione diversa rispetto agli altri utenti, in base al fatto che hai chiesto specificamente sul flusso di lavoro del progetto , piuttosto che sugli strumenti . Supponendo che tu sia relativamente soddisfatto del tuo modello di produzione di documenti, sembra che le tue sfide possano davvero essere più incentrate su questioni relative al monitoraggio della versione, alla gestione delle risorse e al processo di revisione / pubblicazione.

Se questo sembra corretto, suggerirei di esaminare uno strumento integrato di gestione dei ticket / documentazione / documentazione come Redmine . Mantenere insieme gli artefatti di progetto correlati come attività in sospeso, discussioni e file di dati / codice con versione può essere di grande aiuto anche per i progetti ben al di fuori del tradizionale bailiwick di "programmazione".

Concordato che Sweave è la strada da percorrere, con xtable per la generazione di tabelle LaTeX. Anche se non ho trascorso troppo tempo a lavorare con loro, il pacchetto tikzDevice recentemente rilasciato sembra davvero promettente, in particolare se abbinato a pgfSweave (che, per quanto ne so, è disponibile solo su rforge.net in questo momento - c'è un link a r-forge da lì, ma al momento non risponde per me).

Tra i due, otterrai una formattazione coerente tra testo e figure (caratteri, ecc.). Con la birra, questi potrebbero costituire il santo graal della generazione di report.

A un livello più "meta", potresti essere interessato al modello di processo CRISP-DM .

"make" è fantastico perché (1) puoi usarlo per tutto il tuo lavoro in qualsiasi lingua (a differenza, diciamo, Sweave and Brew), (2) è molto potente (abbastanza per costruire tutto il software sulla tua macchina), e (3) evita di ripetere il lavoro. Quest'ultimo punto è importante per me perché molto del lavoro è lento; quando latex un file, mi piace vedere il risultato in pochi secondi, non l'ora che ci vorrebbe per ricreare le figure.

Uso i modelli di progetto insieme a R studio, attualmente il mio contiene le seguenti cartelle:

• info : pdf, powerpoint, documenti ... che non verranno utilizzati da nessuno script
• data input : dati che verranno utilizzati dai miei script ma non generati da essi
• data output : dati generati dai miei script per un ulteriore utilizzo ma non come un rapporto corretto.
• reports : Solo i file che verranno effettivamente mostrati a qualcun altro
• R : Tutti gli script R.
• SAS : Perché a volte devo: '(

Ho scritto funzioni personalizzate in modo da poter chiamare smart_save(x,y)o smart_load(x)salvare o caricare RDS filesda e verso la data outputcartella (file denominati con nomi di variabili) in modo da non essere disturbato dapaths durante la mia analisi.

Una funzione personalizzata new_projectcrea una cartella di progetto numerata, copia tutti i file dal modello, rinomina il RProjfile e modifica le setwdchiamate e imposta la directory di lavoro sul nuovo progetto.

Tutti gli Rscript sono nella Rcartella, strutturati come segue:

00_main.R

• setwd
• chiama gli script da 1 a 5

00_functions.R

• Tutte le funzioni e solo le funzioni vanno lì, se ce ne sono troppe le separerò in più, tutte con un nome simile 00_functions_something.R, in particolare se ho intenzione di creare un pacchetto da alcune di esse le metterò a parte

00_explore.R

• un mucchio di blocchi di script in cui sto testando cose o esplorando i miei dati
• È l'unico file in cui mi è permesso essere disordinato.

01_initialize.R

• Precompilato con una chiamata a uno initialize_general.Rscript più generale dalla mia cartella dei modelli che carica i pacchetti e i dati che uso sempre e che non mi dispiace avere nel mio spazio di lavoro
• carichi 00_functions.R(precompilati)
• carica librerie aggiuntive
• impostare variabili globali

02_load data.R

• carica csv/txt xlsx RDS, c'è una riga commentata precompilata per ogni tipo di file
• mostra quali file sono stati creati nell'area di lavoro

03_pull data from DB.R

• Utilizza dbplyrper recuperare tabelle filtrate e raggruppate dal DB
• alcune righe commentate precompilate per impostare connessioni e recuperare.
• Mantenere le operazioni lato client al minimo indispensabile
• Nessuna operazione sul lato server al di fuori di questo script
• Visualizza i file che sono stati creati nell'area di lavoro
• Salva queste variabili in modo che possano essere ricaricate più velocemente

Una volta che è stato fatto una volta query_dbspengo un valore booleano e i dati verranno ricaricati daRDSprossima volta.

Può succedere che devo inviare nuovamente i dati ai DB, in tal caso creerò ulteriori passaggi.

04_Build.R

• Wrangling dei dati, tutto il divertimento dplyr/ tidyrroba va lì
• visualizza quali file sono stati creati nell'area di lavoro
• salva queste variabili

Una volta che è stato fatto una volta buildspengo un valore booleano e i dati verranno ricaricati dalla RDSprossima volta.

05_Analyse.R

• Riassumi, modello ...
• report excele csvfile

95_build ppt.R

• modello per report powerpoint utilizzando officer

96_prepare markdown.R

• setwd
• caricare dati
• impostare i parametri di markdown, se necessario
• render

97_prepare shiny.R

• setwd
• caricare dati
• impostare parametri brillanti, se necessario
• runApp

98_Markdown report.Rmd

• Un modello di report

99_Shiny report.Rmd

• Un modello di app

Per scrivere un rapido rapporto preliminare o e-mail a un collega, trovo che possa essere molto efficiente copiare e incollare grafici in MS Word o in una pagina di posta elettronica o wiki - spesso è meglio uno screenshot bitmap (ad esempio su Mac, Apple -Shift- (Ctrl) -4). Penso che questa sia una tecnica sottovalutata.

Per un rapporto più finale, la scrittura di funzioni R per rigenerare facilmente tutti i grafici (come file) è molto importante. Ci vuole più tempo per codificare questo.

Sui problemi del flusso di lavoro più ampio, mi piace la risposta di Hadley sull'enumerazione dei file di codice / dati per il flusso di pulizia e analisi. Tutti i miei progetti di analisi dei dati hanno una struttura simile.

Aggiungerò la mia voce per sweave. Per un'analisi complessa in più passaggi è possibile utilizzare un makefile per specificare le diverse parti. Può impedire di ripetere l'intera analisi se è cambiata solo una parte.

Faccio anche quello che fa Josh Reich, solo che lo faccio creando i miei pacchetti R personali, poiché mi aiuta a strutturare il mio codice e i miei dati, ed è anche abbastanza facile condividerli con gli altri.

1. crea il mio pacchetto
2. caricare
3. pulito
4. funzioni
5. fare

creando il mio pacchetto: devtools :: create ('nome_pacchetto')

load and clean: creo script nel data-raw / sottocartella del mio pacchetto per caricare, pulire e archiviare gli oggetti dati risultanti nel pacchetto usando devtools :: use_data (nome_oggetto). Quindi compilo il pacchetto. D'ora in poi, chiamando la libreria (nome_pacchetto) rende disponibili questi dati (e non vengono caricati fino a quando non è necessario).

funzioni: metto le funzioni per le mie analisi nella sottocartella R / del mio pacchetto ed esporta solo quelle che devono essere chiamate dall'esterno (e non le funzioni di aiuto, che possono rimanere invisibili).

do: creo uno script che utilizza i dati e le funzioni memorizzati nel mio pacchetto. (Se le analisi devono essere eseguite una sola volta, posso inserire questo script anche nella cartella dati / raw, eseguirlo e archiviare i risultati nel pacchetto per renderlo facilmente accessibile).