Workflow do analizy statystycznej i pisania raportów

Jeśli chcesz zobaczyć kilka przykładów, mam kilka małych (i nie tak małych) projektów czyszczenia i analizy danych dostępnych online. W większości znajdziesz skrypt do pobierania danych, jeden do czyszczenia, a kilka do eksploracji i analizy: {]}

• Imiona dzieci z ZUS
• 30+ dane dotyczące zużycia paliwa z EPI
• duży zbiór danych o kryzysie mieszkaniowym
• oceny filmów z IMDB
• Dane dotyczące sprzedaży domu w rejonie Zatoki

Ostatnio zacząłem numerować Skrypty, więc jest zupełnie oczywiste, w jakiej kolejności powinny być uruchamiane. (Jeśli mam ochotę, czasami zrobię to tak, że skrypt eksploracji wywoła skrypt czyszczenia, który z kolei wywołuje skrypt pobierania, każdy wykonując minimalną niezbędną pracę-Zwykle sprawdzając obecność plików wyjściowych za pomocą file.exists. Jednak w większości przypadków wydaje się to overkill).

Używam Gita do wszystkich moich projektów (system zarządzania kodem źródłowym), więc łatwo jest współpracować z innymi, zobaczyć co się zmienia i łatwo wrócić do poprzednich wersji.

Jeśli robię formalny raport, Zwykle trzymam R i latex oddzielnie, ale zawsze upewniam się, że mogę source Mój kod R, aby wyprodukować cały kod i wyjście, które są mi potrzebne do raportu. W przypadku raportów, które robię, uważam to za łatwiejsze i czystsze niż praca z lateksem.

Zgadzam się z innymi respondentami: Sweave doskonale nadaje się do pisania raportów za pomocą R. A przebudowa raportu ze zaktualizowanymi Wynikami jest tak prosta, jak ponowne wywołanie funkcji Sweave. Jest całkowicie autonomiczny, w tym wszystkie analizy, dane itp. I możesz kontrolować wersję całego pliku.

Używam wtyczki StatET dla Eclipse do tworzenia raportów, a Sweave jest zintegrowany(Eclipse rozpoznaje formatowanie latex, itp). W systemie Windows, jest łatwy w użyciu MikTEX .

Dodam jeszcze, że za pomocą Beamera można tworzyć piękne raporty. Tworzenie normalnego raportu jest równie proste. Poniżej zamieszczam przykład, który ściąga dane z Yahoo! i tworzy wykres i tabelę (za pomocą quantmod). Możesz zbudować ten raport w następujący sposób:

Sweave(file = "test.Rnw")

Oto sam dokument Beamera:

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

Chciałem tylko dodać, na wypadek gdyby ktoś to przegapił, że na blogu learnr jest świetny post o tworzeniu powtarzalnych raportów z paczką browaru Jeffreya Hornera. Matt i Kevin wspominali brew powyżej. Nie używałem go zbyt często.

Wpisy podążają za ładnym obiegiem pracy, więc warto przeczytać:

1. przygotuj dane.
2. przygotuj szablon raportu.
3. sporządzić raport.

Faktycznie produkując raport po wykonaniu dwóch pierwszych kroków jest bardzo prosty:

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

Do tworzenia raportów niestandardowych, uznałem za przydatne włączenie wielu istniejących wskazówek sugerowanych tutaj.

Generowanie raportów: Dobra strategia generowania raportów obejmuje połączenie Sweave, make i R.

Wydawca: Do dobrych edytorów do przygotowania dokumentów Sweave należą:

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

"Organizacja kodu": {]} Pod względem organizacja kodu, uważam, że przydatne są dwie strategie:

• przeczytaj o przepływie pracy analizy (np. ProjectTemplate , Pomysły Josha Reicha, moja własna prezentacja na temat R workflow slajdy i Video )
• Analizuj przykładowe raporty i rozeznawaj przepływ pracy
  • przykłady Hadleya Wickhama
  • moje przykłady na GitHubie
  • przykłady powtarzalnych badań wymienionych na krzyż Zwalidowane

Używam Sweave do reportażowej strony tego, ale słyszałem również o brew Pakiet-choć jeszcze nie zajrzałem.

Zasadniczo mam szereg ankiet, dla których sporządzam statystyki zbiorcze. Za każdym razem te same badania, te same raporty. Zbudowałem szablon Sweave dla raportów (co wymaga trochę pracy). Ale po zakończeniu pracy mam oddzielny skrypt R, który pozwala mi wskazać nowe dane. Wciskam "Go", Sweave wyrzuca a kilka punktów .pliki tex, a ja uruchomiłem mały skrypt Pythona, aby je wszystkie pdflatex. Mój poprzednik spędził ~6 tygodni każdego roku na tych raportach; spędzam około 3 dni (głównie na czyszczeniu danych; znaki ucieczki są niebezpieczne).

Jest bardzo możliwe, że są teraz lepsze podejścia, ale jeśli zdecydujesz się na tę trasę, daj mi znać - miałem zamiar umieścić kilka moich Sweave hacków, a to byłby dobry kopniak, aby to zrobić.

Zaproponuję coś w innym kierunku niż inni zgłaszający, bazując na tym, że pytałeś konkretnie o obieg pracy nad projektem, a nie Narzędzia. Zakładając, że jesteś stosunkowo zadowolony z modelu produkcji dokumentów, wygląda na to, że Twoje wyzwania mogą być bardziej skoncentrowane na kwestiach śledzenia wersji, zarządzania zasobami i procesu recenzowania/publikowania.

Jeśli to brzmi poprawnie, proponuję przyjrzeć się zintegrowanej ticketing / zarządzanie źródłami / narzędzie dokumentacji, takie jak Redmine . Utrzymywanie powiązanych artefaktów projektu, takich jak oczekujące zadania, wątki dyskusji i wersjonowane Pliki Danych / kodu razem może być wielką pomocą nawet dla projektów spoza tradycyjnego" programowania " bailiwick.

Zgodził się, że Sweave jest drogą do zrobienia, z xtable do generowania tabel LaTeX. Chociaż nie spędziłem z nimi zbyt wiele czasu, niedawno wydany pakiet tikzDevice wygląda naprawdę obiecująco, szczególnie w połączeniu z pgfSweave (który, o ile wiem, jest dostępny tylko na rforge.net w tej chwili jest link do r-forge, ale na razie nie odpowiada).

Między tymi dwoma, będziesz się konsekwentnie formatowanie tekstu i rysunków (czcionki itp.). Z brew, mogą one stanowić Święty Graal generowania raportów.

Na bardziej "meta" poziomie, może zainteresować Cię model procesu CRISP-dm.

"make" jest świetny, ponieważ (1) możesz go używać do całej swojej pracy w dowolnym języku (w przeciwieństwie do, powiedzmy, Sweave i Brew), (2) jest bardzo wydajny (wystarczająco, aby zbudować całe oprogramowanie na komputerze) i (3) pozwala uniknąć powtarzania pracy. Ten ostatni punkt jest dla mnie ważny, ponieważ wiele pracy jest powolne; kiedy latex plik, Lubię zobaczyć wynik w kilka sekund, a nie godzinę, która zajęłaby odtworzyć dane.

Za napisanie szybkiego wstępnego raportu lub e-maila do kolegi uważam, że bardzo wydajne może być kopiowanie i wklejanie Wykresów do MS Word lub e-maila lub strony wiki-często najlepszy jest bitmapowy zrzut ekranu(np. na Macu, Apple-Shift-(Ctrl)-4). Myślę, że to niedoceniana technika.

Dla bardziej końcowego raportu, pisanie funkcji R w celu łatwej regeneracji wszystkich Wykresów (jako plików) jest bardzo ważne. Potrzeba więcej czasu, żeby to zakodować.

Na większe problemy z przepływem pracy, I Jak odpowiedź Hadley ' a na wyliczenie plików kodu/danych do czyszczenia i analizy. Wszystkie moje projekty analizy danych mają podobną strukturę.

Dodam swój głos do sweave. W przypadku skomplikowanej, wieloetapowej analizy można użyć makefile, aby określić różne części. Może zapobiec konieczności powtarzania całej analizy, jeśli tylko jedna część uległa zmianie.

Używam szablonów projektów wraz z R studio, obecnie mój zawiera następujące foldery:

• info : PDF, powerpoints, docs... który nie będzie używany przez żaden skrypt
• data input : dane, które będą używane przez moje Skrypty, ale nie generowane przez nie
• data output: dane generowane przez moje skrypty do dalszego wykorzystania, ale nie jako właściwy raport.
• reports: tylko pliki, które faktycznie zostaną pokazane komuś innemu
• R : Wszystkie R Skrypty
• SAS: Bo czasem muszę: '(

Napisałem własne funkcje, więc mogę wywołać smart_save(x,y) lub smart_load(x), aby zapisać lub załadować RDS files do i z folderu data output (pliki nazwane nazwami zmiennych), więc nie przeszkadza mi paths podczas mojej analizy.

Funkcja niestandardowa new_project tworzy numerowany folder projektu, kopiuje wszystkie pliki z szablonu, zmienia nazwę pliku RProj i edytuje wywołania setwd i ustawia katalog roboczy na nowy projekt.

Wszystkie skrypty R znajdują się w folderze R, o następującej strukturze:

00_main.R

• setwd
• wywołuje Skrypty od 1 do 5

00_functions.R

• wszystkie funkcje i tylko funkcje tam idą, jeśli jest ich zbyt wiele, podzielę je na kilka, wszystkie nazwane tak jak 00_functions_something.R, w szczególności jeśli planuję zrobić pakiet z niektórych z nich, podzielę je

00_explore.R

• kilka fragmentów skryptów, gdzie testuję rzeczy lub przeglądanie moich danych
• to jedyny plik, w którym mogę być brudny.

01_initialize.R

• wstępnie wypełniony wywołaniem bardziej ogólnego skryptu initialize_general.R z folderu szablonu, który ładuje pakiety i dane, których zawsze używam i nie mam nic przeciwko temu, aby mieć je w moim obszarze roboczym
• ładunki 00_functions.R (wstępnie wypełnione)
• ładuje dodatkowe biblioteki
• Ustaw zmienne globalne

02_load data.R

• ładunki csv/txt xlsx RDS, jest wpis do komentarza dla każdy typ pliku
• wyświetla, które pliki zostały utworzone w obszarze roboczym

03_pull data from DB.R

• używa dbplyr do pobierania przefiltrowanych i zgrupowanych tabel z DB
• niektóre wstępnie wypełnione linie komentowane, aby skonfigurować połączenia i pobrać.
• ograniczaj operacje po stronie klienta do minimum
• brak operacji po stronie serwera poza tym skryptem
• wyświetla, które pliki zostały utworzone w obszarze roboczym
• zapisuje te zmienne, aby mogły być reloaded faster

Gdy już to zrobię, wyłączę query_db boolean i dane będą przeładowywane z RDS następnym razem.

Może się zdarzyć, że będę musiał przekierować dane do DBs, jeśli tak, stworzę dodatkowe kroki.

04_Build.R

• data wrangling, all the fun dplyr / tidyr stuff goes there
• wyświetla, które pliki zostały utworzone w obszarze roboczym
• zapisz te zmienne

Gdy już to zrobię, gdy wyłączę build boolean i dane zostaną przeładowane z RDS następnym razem.

05_Analyse.R

• podsumować, model...
• sprawozdanie excel i csv pliki

95_build ppt.R

• szablon dla raportu powerpoint za pomocą officer

96_prepare markdown.R

• setwd
• załaduj dane
• ustaw parametry markdown w razie potrzeby
• render

97_prepare shiny.R

• setwd
• załaduj dane
• ustaw parametry, jeśli potrzebne
• runApp

98_Markdown report.Rmd

• szablon raportu

99_Shiny report.Rmd

• szablon aplikacji

Robię również to, co robi Josh Reich, tylko to robię tworząc moje osobiste Pakiety R, ponieważ pomaga mi to uporządkować mój kod i dane, a także jest dość łatwe dzielenie się nimi z innymi.

1. Utwórz mój pakiet
2. load
3. clean
4. Funkcje
5. do

Tworzenie mojego pakietu: devtools:: create('nazwa_pakietu')

Load and clean: tworzę skrypty w podfolderze data-raw / mojego pakietu do ładowania, czyszczenia i przechowywania danych wynikowych obiekty w pakiecie używając metody devtools:: use_data (object_name). Następnie kompiluję pakiet. Od tej pory wywołanie library (nazwa_pakietu) udostępnia te dane (i nie są one ładowane dopóki nie jest to konieczne).

Functions: umieszczam funkcje do analiz w podfolderze r/ mojego pakietu i eksportuję tylko te, które muszą być wywołane z zewnątrz (a nie funkcje pomocnicze, które mogą pozostać niewidoczne).

Do: tworzę skrypt, który wykorzystuje Dane i funkcje zapisane w moim paczka. (Jeśli analizy muszą być wykonane tylko raz, mogę umieścić ten skrypt również w podfolderze data-raw/, uruchomić go i zapisać wyniki w pakiecie, aby był łatwo dostępny.)