Fluxo de trabalho para análise estatística e elaboração de relatórios


186

Alguém tem alguma noção dos fluxos de trabalho para análise de dados relacionados à elaboração de relatórios personalizados? O caso de uso é basicamente este:

  1. O cliente envia um relatório que utiliza análise de dados, por exemplo, uma estimativa populacional e mapas relacionados a um distrito de água.

  2. O analista baixa alguns dados, mescla os dados e salva o resultado (por exemplo, adicionando uma coluna para população por unidade ou subconjuntando os dados com base nos limites do distrito).

  3. O analista analisa os dados criados em (2), aproxima-se de seu objetivo, mas vê que precisa de mais dados e volta para (1).

  4. Enxágue repetidamente até que as tabelas e gráficos atendam ao controle de qualidade / qualidade e satisfaçam o cliente.

  5. Escreva um relatório incorporando tabelas e gráficos.

  6. No próximo ano, o cliente satisfeito volta e quer uma atualização. Isso deve ser tão simples quanto atualizar os dados upstream com um novo download (por exemplo, obter as licenças de construção do ano passado) e pressionar um botão "RECALCULAR", a menos que as especificações mudem.

No momento, apenas inicio um diretório e ad-hoc o melhor que posso. Gostaria de uma abordagem mais sistemática, por isso espero que alguém tenha entendido isso ... Uso uma mistura de planilhas, SQL, ARCGIS, R e ferramentas Unix.

Obrigado!

PS:

Abaixo está um Makefile básico que verifica dependências em vários conjuntos de dados intermediários (com .RDatasufixo) e scripts ( .Rsufixo). O Make usa registros de data e hora para verificar as dependências; portanto, se você touch ss07por.csv, ele verá que esse arquivo é mais novo que todos os arquivos / destinos que dependem dele e executará os scripts fornecidos para atualizá-los adequadamente. Este ainda é um trabalho em andamento, incluindo uma etapa para inserção no banco de dados SQL e uma etapa para uma linguagem de modelagem como sweave. Observe que o Make depende de guias em sua sintaxe; portanto, leia o manual antes de cortar e colar. Aproveite e dê 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


11
Oh meu. quem entra aqui, cuidado : as respostas sobre essa pergunta foram excelentes cinco anos atrás. Eles agora estão todos completamente ultrapassada. Atualmente, eu desaconselharia fortemente seguir qualquer uma das respostas aqui. Agora existem ferramentas muito melhores disponíveis. Para começar, vou me referir a um projeto de exemplo usando Makefiles e Knitr .
Konrad Rudolph

R Notebooks , drivers odbc , git e git lfs são os mais enviados para esse problema.
DaveRGP

Eu recomendo fortemente a configuração do projeto de acordo com os princípios descritos, por exemplo, aqui ( github.com/ropensci/rrrpkg ). A assim chamada "Compedium pesquisa" é dádiva de Deus ao fazer ciência de dados reprodutíveis
Kresten

Respostas:


195

Geralmente, divido meus projetos em quatro partes:

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

load.R: cuida do carregamento de todos os dados necessários. Normalmente, este é um arquivo curto, que lê dados de arquivos, URLs e / ou ODBC. Dependendo do projeto, neste momento, escreverei a área de trabalho usando save()ou manterei as coisas na memória para a próxima etapa.

clean.R: É aqui que vivem todas as coisas feias - cuidando dos valores que faltam, mesclando quadros de dados, lidando com outliers.

func.R: Contém todas as funções necessárias para executar a análise real. source()Esse arquivo não deve ter efeitos colaterais além de carregar as definições de função. Isso significa que você pode modificar esse arquivo e recarregá-lo sem precisar voltar às etapas 1 e 2 repetidas, o que pode levar muito tempo para ser executado em grandes conjuntos de dados.

do.R: Chama as funções definidas em func.R para executar a análise e produzir gráficos e tabelas.

A principal motivação para essa configuração é trabalhar com dados grandes, nos quais você não deseja recarregar os dados toda vez que fizer uma alteração em uma etapa subsequente. Além disso, manter meu código compartimentado dessa maneira significa que eu posso voltar para um projeto esquecido e ler rapidamente o load.R, descobrir quais dados eu preciso atualizar e depois analisar o do.R para descobrir qual análise foi executada.


12
Esse é realmente um bom fluxo de trabalho. Eu lutei para projetar um fluxo de trabalho e, quando pergunto às pessoas à minha volta, elas geralmente respondem: "o que? Fluxo de trabalho? Hein?" Então acho que eles não pensam muito nisso. Vou adotar o modelo Reichian LCFD.
JD Longo

1
este é muito parecido com o meu trabalho, tenho muitas vezes um script de importação, roteiro análise e roteiro de relatórios
kpierce8

4
LCFD: Dados menos incrustados
William Doane

2
Existe um belo vídeo de apresentação + slides de Jeromy Anglim que incorpora esse fluxo de trabalho aqui. Vcasmo.com/video/drewconway/10362 #
David LeBauer


95

Se você quiser ver alguns exemplos, tenho alguns projetos pequenos (e não tão pequenos) de limpeza e análise de dados disponíveis on-line. Na maioria dos casos, você encontrará um script para baixar os dados, um para limpá-los e alguns para explorar e analisar:

Recentemente, comecei a numerar os scripts, por isso é completamente óbvio em que ordem eles devem ser executados. (Se estou me sentindo realmente elegante, às vezes faço com que o script de exploração chame o script de limpeza, que por sua vez chama o script de download, cada um fazendo o trabalho mínimo necessário - geralmente verificando a presença de arquivos de saída file.exists. No entanto, na maioria das vezes isso parece exagero).

Eu uso o git para todos os meus projetos (um sistema de gerenciamento de código-fonte) para facilitar a colaboração com outras pessoas, ver o que está mudando e reverter facilmente para as versões anteriores.

Se eu faço um relatório formal, geralmente mantenho R e látex separados, mas sempre me certifico de que posso usar sourcemeu código R para produzir todo o código e saída necessários para o relatório. Para os tipos de relatórios que eu faço, acho isso mais fácil e limpo do que trabalhar com látex.


Eu comentei sobre Makefiles acima, mas você pode querer dar uma olhada neles - é a linguagem tradicional de verificação de dependência. Além disso - vou tentar aprender ggplot2 - parece ótimo!
forkandwait

Eu gosto da idéia de ter uma maneira de especificar dependências entre arquivos, mas ter que aprender m4 é uma grande desvantagem. Eu gostaria que houvesse algo como Raken escrito em R.
Hadley

2
Para dependências, você também pode fazê-lo nos arquivos R. Em vez de fazer source("blah.R"), verifique se a variável exigido (s) existem em primeiro lugar: if (!exists("foo")) { source("blah.R") }. Isso evita re-executar dependências se elas já tiverem sido executadas.
precisa saber é o seguinte

17

Concordo com os outros respondentes: Sweave é excelente para escrever relatórios com R. E reconstruir o relatório com resultados atualizados é tão simples quanto chamar novamente a função Sweave. É completamente independente, incluindo todas as análises, dados, etc. E você pode controlar a versão do arquivo inteiro.

Eu uso o plugin StatET do Eclipse para desenvolver os relatórios e o Sweave é integrado (o Eclipse reconhece a formatação de látex, etc.). No Windows, é fácil usar o MikTEX .

Eu também acrescentaria que você pode criar relatórios bonitos com o Beamer . Criar um relatório normal é igualmente simples. Incluí um exemplo abaixo que extrai dados do Yahoo! e cria um gráfico e uma tabela (usando quantmod). Você pode criar este relatório da seguinte maneira:

Sweave(file = "test.Rnw")

Aqui está o próprio documento 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}

6
Não acredite que um relatório Sweave seja reproduzível até que você o teste em uma máquina limpa. É fácil ter dependências externas implícitas.
31119 John D. Cook

16

Eu só queria acrescentar, caso alguém tenha perdido, que há um ótimo post no blog learnr sobre a criação de relatórios repetitivos com o pacote de cervejas de Jeffrey Horner . Matt e Kevin mencionaram a bebida acima. Na verdade, eu não usei muito isso.

As entradas seguem um bom fluxo de trabalho, portanto vale a pena ler:

  1. Prepare os dados.
  2. Prepare o modelo de relatório.
  3. Produza o relatório.

Na verdade, a produção do relatório após a conclusão das duas primeiras etapas é muito simples:

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

Ao corrigir um pequeno erro gramatical, atrapalhei o endereçamento wordpress.com. Portanto, o link correto é learnr.wordpress.com/2009/09/09/…
learnr

14

Para criar relatórios personalizados, achei útil incorporar muitas das dicas existentes sugeridas aqui.

Gerando relatórios: Uma boa estratégia para gerar relatórios envolve a combinação de Sweave, make e R.

Editor: bons editores para a preparação de documentos Sweave incluem:

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

Organização de código: Em termos de organização de código, considero duas estratégias úteis:


7

Eu uso o Sweave no lado de produção de relatórios, mas também tenho ouvido falar sobre o pacote de fermentação - embora ainda não o tenha examinado.

Essencialmente, tenho várias pesquisas para as quais produzo estatísticas resumidas. Mesmas pesquisas, mesmos relatórios sempre. Criei um modelo Sweave para os relatórios (o que exige um pouco de trabalho). Mas, uma vez concluído o trabalho, tenho um script R separado que me permite apontar os novos dados. Pressiono "Go", o Sweave despeja alguns arquivos .tex, e corro um pequeno script Python para pdflatex todos. Meu antecessor passava ~ 6 semanas por ano nesses relatórios; Passo cerca de três dias (principalmente na limpeza de dados; caracteres de escape são perigosos).

É muito possível que haja abordagens melhores agora, mas se você decidir seguir esse caminho, avise-me - eu pretendo colocar alguns dos meus hacks Sweave, e isso seria um bom chute nas calças. tão.


Adoraria ver alguns desses "hacks Sweave". Está me dando dor de cabeça!
Brandon Bertelsen

7

Vou sugerir algo em uma direção diferente dos outros remetentes, com base no fato de que você perguntou especificamente sobre o fluxo de trabalho do projeto , em vez de ferramentas . Supondo que você esteja relativamente satisfeito com seu modelo de produção de documentos, parece que seus desafios podem estar mais centrados em questões de rastreamento de versão, gerenciamento de ativos e processo de revisão / publicação.

Se isso parecer correto, sugiro procurar uma ferramenta integrada de gerenciamento de bilhetes / documentação / documentação como o Redmine . Manter artefatos de projetos relacionados, como tarefas pendentes, encadeamentos de discussão e arquivos de dados / código com versão juntos, pode ser uma grande ajuda, mesmo para projetos bem fora do bailiwick de "programação" tradicional.


5

Concordou que o Sweave é o caminho a seguir, com o xtable para gerar tabelas LaTeX. Embora eu não tenha passado muito tempo trabalhando com eles, o pacote tikzDevice, lançado recentemente , parece realmente promissor, principalmente quando associado ao pgfSweave (que, até onde eu sei, só está disponível no rforge.net no momento - existe um link para r-forge a partir daí, mas não está respondendo para mim no momento).

Entre os dois, você terá uma formatação consistente entre texto e figuras (fontes, etc.). Com a fermentação, estes podem constituir o santo graal da geração de relatórios.


O pgfSweave está atualmente no "limbo do desenvolvimento", pois os desenvolvedores não tiveram tempo de incorporar o novo tikzDevice. Por enquanto, sugerimos o uso do tikzDevice em documentos Sweave normais - o usuário precisa assumir a responsabilidade de abrir / fechar o dispositivo e \ incluindo {} a saída resultante.
Sharpie

@ Sharpe: Alguma atualização no status de desenvolvimento do pgfSweave? Parece ótimo, mas não parece funcionar em nenhum sistema que eu tentei.
Ari B. Friedman

@ gsk3 O outro desenvolvedor tem sido muito ativo em manter o pgfSweave atualizado e fez muito trabalho desde que publiquei esse comentário. Cabeça sobre a github.com/cameronbracken/pgfSweave para acompanhar o desenvolvimento. Se o pacote não estiver funcionando para você, gostaríamos de receber um relatório de bug para que possamos corrigi-lo.
Sharpie 31/03

@ Sharpie: Ótimo, obrigado. Encaminhei sua mensagem para meu amigo, que trabalhou mais do que eu. Se ele não enviar um relatório de bug em breve, eu o reunirei. Parece um ótimo pacote; obrigado por todo o trabalho duro.
Ari B. Friedman


4

"make" é ótimo porque (1) você pode usá-lo para todo o seu trabalho em qualquer idioma (ao contrário, digamos, Sweave and Brew), (2) é muito poderoso (o suficiente para criar todo o software em sua máquina) e (3) evita repetir o trabalho. Este último ponto é importante para mim, porque muito do trabalho é lento; quando coloco um arquivo em latex, gosto de ver o resultado em alguns segundos, e não a hora que levaria para recriar as figuras.


+1 para fazer; No entanto, não considero o make incompatível com o Sweave. Antes, quando produzo relatórios, faço chamadas Sweave (e outras coisas).
Jeromy Anglim

3

Eu uso modelos de projeto junto com o R studio, atualmente o meu contém as seguintes pastas:

  • info : pdfs, powerpoints, documentos ... que não serão usados ​​por nenhum script
  • data input : dados que serão usados ​​pelos meus scripts, mas não gerados por eles
  • data output : dados gerados pelos meus scripts para uso posterior, mas não como um relatório adequado.
  • reports : Apenas arquivos que serão realmente mostrados a outra pessoa
  • R : Todos os scripts R
  • SAS : Porque às vezes tenho que: '(

Escrevi funções personalizadas para poder chamar smart_save(x,y)ou smart_load(x)salvar ou carregar RDS filespara e da data outputpasta (arquivos nomeados com nomes de variáveis) para não me incomodar pathsdurante a análise.

Uma função personalizada new_projectcria uma pasta de projeto numerada, copia todos os arquivos do modelo, renomeia o RProjarquivo e edita as setwdchamadas e define o diretório de trabalho para o novo projeto.

Todos os Rscripts estão na Rpasta, estruturados da seguinte maneira:


00_main.R
  • setwd
  • chama scripts 1 a 5

00_functions.R
  • Todas as funções e apenas as funções vão para lá, se houver muitas, eu a separarei em várias, todas nomeadas como 00_functions_something.R, em particular, se eu pretender criar um pacote com algumas delas, eu as separarei

00_explore.R
  • um monte de pedaços de script em que estou testando coisas ou explorando meus dados
  • É o único arquivo em que posso ficar bagunçado.

01_initialize.R
  • Pré-preenchido com uma chamada para um initialize_general.Rscript mais geral da minha pasta de modelo que carrega os pacotes e dados que eu sempre uso e não me importo de ter no meu espaço de trabalho
  • cargas 00_functions.R(pré- carregadas )
  • carrega bibliotecas adicionais
  • definir variáveis ​​globais

02_load data.R
  • carrega csv/txt xlsx RDS, há uma linha comentada pré-preenchida para cada tipo de arquivo
  • exibe quais arquivos foram criados na área de trabalho

03_pull data from DB.R
  • Usa dbplyrpara buscar tabelas filtradas e agrupadas do banco de dados
  • algumas linhas comentadas pré-preenchidas para configurar conexões e buscar.
  • Mantenha as operações do lado do cliente no mínimo
  • Nenhuma operação do lado do servidor fora deste script
  • Exibe quais arquivos foram criados na área de trabalho
  • Salva essas variáveis ​​para que possam ser recarregadas mais rapidamente

Uma vez feito isso, eu desligo um query_dbbooleano e os dados serão recarregados da RDSpróxima vez.

Pode acontecer que eu tenha que realimentar os dados para os bancos de dados. Nesse caso, criarei etapas adicionais.


04_Build.R
  • Disputa de dados, toda a diversão dplyr/ tidyrmaterial vai para lá
  • exibe quais arquivos foram criados na área de trabalho
  • salve essas variáveis

Uma vez feito isso, eu desligo um buildbooleano e os dados serão recarregados da RDSpróxima vez.


05_Analyse.R
  • Resuma, modelo ...
  • relatório excele csvarquivos

95_build ppt.R
  • modelo de relatório do powerpoint usando officer

96_prepare markdown.R
  • setwd
  • Carregar dados
  • definir parâmetros de remarcação, se necessário
  • render

97_prepare shiny.R
  • setwd
  • Carregar dados
  • defina parâmetros brilhantes, se necessário
  • runApp

98_Markdown report.Rmd
  • Um modelo de relatório

99_Shiny report.Rmd
  • Um modelo de aplicativo

2

Para escrever um relatório ou email preliminar rápido para um colega, acho que pode ser muito eficiente copiar e colar plotagens no MS Word ou em uma página de email ou wiki - geralmente é melhor uma captura de tela de bitmap (por exemplo, no mac, Apple -Shift- (Ctrl) -4). Eu acho que essa é uma técnica subestimada.

Para um relatório mais final, escrever funções R para regenerar facilmente todos os gráficos (como arquivos) é muito importante. Leva mais tempo para codificar isso.

Nas questões maiores do fluxo de trabalho, gosto da resposta de Hadley na enumeração dos arquivos de código / dados para o fluxo de limpeza e análise. Todos os meus projetos de análise de dados têm uma estrutura semelhante.


2

Vou adicionar minha voz para sweave. Para análises complicadas e de várias etapas, você pode usar um makefile para especificar as diferentes partes. Pode impedir a repetição de toda a análise se apenas uma parte tiver sido alterada.


0

Eu também faço o que Josh Reich faz, apenas faço isso criando meus pacotes R pessoais, pois me ajuda a estruturar meu código e dados, e também é muito fácil compartilhá-los com outras pessoas.

  1. crie meu pacote
  2. carga
  3. limpar \ limpo
  4. funções
  5. Faz

criando meu pacote: devtools :: create ('package_name')

load and clean: eu crio scripts na subpasta / pasta de dados do meu pacote para carregar, limpar e armazenar os objetos de dados resultantes no pacote usando devtools :: use_data (object_name). Então eu compilo o pacote. A partir de agora, a biblioteca de chamada (package_name) disponibiliza esses dados (e eles não são carregados até que seja necessário).

funções: eu coloco as funções para minhas análises na subpasta R / do meu pacote e exporto apenas aquelas que precisam ser chamadas de fora (e não as funções auxiliares, que podem permanecer invisíveis).

do: eu crio um script que usa os dados e funções armazenados no meu pacote. (Se as análises precisarem ser feitas apenas uma vez, também posso inserir esse script na subpasta / pasta de dados, executá-lo e armazenar os resultados no pacote para torná-lo facilmente acessível.)

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.