Przepływ pracy do analizy statystycznej i pisania raportów

Czy ktoś ma jakąkolwiek wiedzę na temat przepływów pracy do analizy danych związanych z niestandardowym pisaniem raportów? Przypadek użycia jest w zasadzie taki:

1. Klient zleca raport wykorzystujący analizę danych, np. Szacunkową liczbę ludności i powiązane mapy dla obszaru wodnego.

2. Analityk pobiera niektóre dane, munguje dane i zapisuje wynik (np. Dodając kolumnę dla populacji na jednostkę lub podzbiór danych w oparciu o granice dzielnicy).

3. Analityk analizuje dane utworzone w (2), zbliża się do celu, ale widzi, że potrzebuje więcej danych, i wraca do (1).

4. Powtarzaj płukanie, aż tabele i grafika spełniają QA / QC i zadowolą klienta.

5. Napisz raport zawierający tabele i grafikę.

6. W przyszłym roku szczęśliwy klient powraca i chce aktualizacji. Powinno to być tak proste, jak aktualizacja danych nadrzędnych poprzez nowe pobranie (np. Uzyskanie pozwolenia na budowę z ostatniego roku) i naciśnięcie przycisku „OBLICZ”, chyba że zmienią się specyfikacje.

W tej chwili po prostu uruchamiam katalog i ad-hoc, najlepiej jak potrafię. Chciałbym bardziej systematyczne podejście, więc mam nadzieję, że ktoś to wymyślił ... Używam kombinacji arkuszy kalkulacyjnych, SQL, ARCGIS, R i Uniksa.

Dzięki!

PS:

Poniżej znajduje się podstawowy plik Makefile, który sprawdza zależności od różnych pośrednich zestawów danych (w / .RDataprzyrostek) i skryptów ( .Rprzyrostek). Make używa znaczników czasu do sprawdzania zależności, więc jeśli zobaczysz touch ss07por.csv, że ten plik jest nowszy niż wszystkie zależne od niego pliki / cele, i wykonaj podane skrypty, aby je odpowiednio zaktualizować. Jest to wciąż praca w toku, w tym krok do umieszczenia w bazie danych SQL i krok do szablonów takich jak Sweave. Pamiętaj, że w składni Make opiera się na tabulatorach, dlatego przed wycinaniem i wklejaniem przeczytaj instrukcję. Ciesz się i wyrażaj opinie!

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

Generalnie dzielę swoje projekty na 4 części:

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

load.R: Dba o załadowanie wszystkich wymaganych danych. Zazwyczaj jest to krótki plik, wczytujący dane z plików, adresów URL i / lub ODBC. W zależności od projektu w tym momencie albo wypiszę obszar roboczy, używając, save()albo po prostu zachowam pamięć w następnym kroku.

clean.R: Tutaj żyją wszystkie brzydkie rzeczy - dbanie o brakujące wartości, scalanie ramek danych, obsługa wartości odstających.

func.R: Zawiera wszystkie funkcje potrzebne do przeprowadzenia rzeczywistej analizy. source()zapisanie tego pliku nie powinno mieć żadnych skutków ubocznych poza załadowaniem definicji funkcji. Oznacza to, że możesz zmodyfikować ten plik i załadować go ponownie bez konieczności powtarzania kroków 1 i 2, co może zająć dużo czasu w przypadku dużych zestawów danych.

do.R: Wywołuje funkcje zdefiniowane w func.R w celu przeprowadzenia analizy oraz utworzenia wykresów i tabel.

Główną motywacją tego ustawienia jest praca z dużymi danymi, dzięki czemu nie trzeba ponownie ładować danych za każdym razem, gdy wprowadzasz zmiany w kolejnym kroku. Poza tym utrzymywanie mojego kodu w podziale w ten sposób oznacza, że ​​mogę wrócić do dawno zapomnianego projektu i szybko odczytać obciążenie. R i dowiedzieć się, jakie dane muszę zaktualizować, a następnie spojrzeć na do.R, aby dowiedzieć się, jaka analiza została wykonana.

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 jego wyczyszczenia, a także kilka do eksploracji i analizy:

• Imiona dla dzieci z administracji zabezpieczenia społecznego
• Ponad 30 lat danych dotyczących zużycia paliwa z EPI
• Duży zbiór danych o kryzysie mieszkaniowym
• Oceny filmów z IMDB
• Dane dotyczące sprzedaży domów w rejonie zatoki

Ostatnio zacząłem numerować skrypty, więc jest całkowicie oczywiste, w jakiej kolejności powinny być uruchamiane. (Jeśli czuję się naprawdę fantazyjny, czasami zrobię to, aby skrypt eksploracyjny wywoływał skrypt czyszczący, który z kolei wywołuje skrypt pobierania, z których każdy wykonuje 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 przesadą).

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

Jeśli robię formalny raport, zwykle trzymam R i lateks osobno, ale zawsze upewniam się, że sourcemój kod R może wygenerować cały kod i dane wyjściowe, których potrzebuję do raportu. Dla tego rodzaju raportów uważam, że jest to łatwiejsze i czystsze niż praca z lateksem.

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

Używam wtyczki StatET dla Eclipse do opracowywania raportów, a Sweave jest zintegrowany (Eclipse rozpoznaje formowanie lateksu itp.). W systemie Windows korzystanie z MikTEX jest łatwe .

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

Sweave(file = "test.Rnw")

Oto sam dokument 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}

Chciałem tylko dodać, na wypadek, gdyby ktoś to przegapił, że na blogu dla uczących się znajduje się świetny post na temat tworzenia powtarzalnych raportów z pakietem naparowym Jeffreya Hornera . Matt i Kevin wspomnieli o napoju powyżej. Tak naprawdę nie używałem go zbyt często.

Wpisy przebiegają zgodnie z porządnym obiegiem pracy, więc warto je przeczytać:

1. Przygotuj dane.
2. Przygotuj szablon raportu.
3. Przygotuj raport.

W rzeczywistości wygenerowanie raportu po ukończeniu pierwszych dwóch kroków jest bardzo proste:

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

Przy tworzeniu raportów niestandardowych przydatne okazało się uwzględnienie wielu sugerowanych tutaj porad.

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

Redaktor: Dobrzy redaktorzy do przygotowywania dokumentów Sweave to:

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

Organizacja kodu: pod względem organizacji kodu przydatne są dwie strategie:

• Poczytaj o analizy przepływu pracy (np ProjectTemplate , pomysły Josh Reicha, moja własna prezentacja na R workflow Slajdy i wideo )
• Przeanalizuj przykładowe raporty i rozróżnij przepływ pracy
  • Przykłady Hadleya Wickhama
  • Moje przykłady na github
  • Przykłady powtarzalnych badań wymienionych w Cross Validated

Używam Sweave do tworzenia strony raportu, ale słyszałem również o pakiecie naparu - choć jeszcze go nie analizowałem.

Zasadniczo mam wiele ankiet, dla których tworzę statystyki podsumowujące. Te same ankiety, te same raporty za każdym razem. Zbudowałem szablon Sweave dla raportów (co wymaga trochę pracy). Ale po zakończeniu pracy mam osobny skrypt R, który pozwala mi wskazać nowe dane. Naciskam „Idź”, Sweave zrzuca kilka plików .tex, i uruchamiam mały skrypt Pythona, aby pdflatex je wszystkie. Mój poprzednik spędzał na tych raportach około 6 tygodni rocznie; Spędzam około 3 dni (głównie na czyszczeniu danych; znaki ucieczki są niebezpieczne).

Jest bardzo możliwe, że istnieją teraz lepsze podejścia, ale jeśli zdecydujesz się pójść tą drogą, daj mi znać - miałem na myśli kilka hacków Sweave, i byłoby to dobre kopnięcie w spodnie więc.

Mam zamiar zasugerować coś w innym kierunku niż inni zgłaszający, w oparciu o to, że zapytałeś konkretnie o przebieg projektu , a nie o narzędzia . Zakładając, że jesteś względnie zadowolony ze swojego modelu tworzenia dokumentów, wygląda na to, że Twoje wyzwania mogą bardziej koncentrować się wokół kwestii śledzenia wersji, zarządzania zasobami oraz procesu recenzowania / publikowania.

Jeśli to brzmi poprawnie, sugerowałbym skorzystanie ze zintegrowanego narzędzia do zarządzania biletami / źródłami / dokumentacji, takiego jak Redmine . Przechowywanie powiązanych artefaktów projektu, takich jak oczekujące zadania, wątki dyskusji i wersjonowane pliki danych / kodu, mogą być bardzo pomocne nawet dla projektów znajdujących się poza tradycyjnym programem „bailiwick”.

Zgodzono się, że Sweave jest właściwą drogą, z xtable do generowania tabel LaTeX. Chociaż nie spędziłem zbyt wiele czasu z nimi pracując, ostatnio wydany pakiet tikzDevice wygląda naprawdę obiecująco, szczególnie w połączeniu z pgfSweave (który, o ile wiem, jest obecnie dostępny tylko na rforge.net - istnieje stamtąd link do r-forge, ale w tej chwili nie odpowiada mi).

Pomiędzy nimi uzyskasz spójne formatowanie tekstu i cyfr (czcionek itp.). Wraz z naparami mogą one stanowić świętego Graala generacji raportów.

Na poziomie bardziej „meta” możesz być zainteresowany modelem procesu CRISP-DM .

„make” jest świetny, ponieważ (1) możesz go używać do wszystkich prac w dowolnym języku (w przeciwieństwie do, powiedzmy, Sweave i Brew), (2) jest bardzo wydajny (wystarczający do zbudowania całego oprogramowania na twoim komputerze) i (3) unika powtarzania pracy. Ten ostatni punkt jest dla mnie ważny, ponieważ duża część pracy jest powolna; kiedy lateksuję plik, lubię widzieć wynik w ciągu kilku sekund, a nie godziny, jaką zajęłoby odtworzenie postaci.

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

• info : pdf, powerpoints, docs ... które nie będą używane przez żaden skrypt
• data input : dane, które będą używane przez moje skrypty, ale nie są przez nie generowane
• data output : dane generowane przez moje skrypty do dalszego wykorzystania, ale nie jako prawidłowy raport.
• reports : Tylko pliki, które faktycznie zostaną pokazane komuś innemu
• R : Wszystkie skrypty R.
• SAS : Ponieważ czasami muszę: ”(

Napisałem niestandardowe funkcje, aby móc wywoływać smart_save(x,y)lub smart_load(x)zapisywać lub ładować RDS filesdo iz data outputfolderu (pliki o nazwach zmiennych), więc nie przeszkadza mi to pathspodczas analizy.

Funkcja niestandardowa new_projecttworzy numerowany folder projektu, kopiuje wszystkie pliki z szablonu, zmienia nazwę RProjpliku i edytuje setwdwywołania oraz ustawia katalog roboczy na nowy projekt.

Wszystkie Rskrypty znajdują się w Rfolderze o następującej strukturze:

00_main.R

• setwd
• wywołuje skrypty od 1 do 5

00_functions.R

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

00_explore.R

• kilka fragmentów skryptu, w których testuję rzeczy lub eksploruję moje dane
• To jedyny plik, w którym wolno mi robić bałagan.

01_initialize.R

• Wstępnie wypełnione wywołanie bardziej ogólnego initialize_general.Rskryptu z mojego folderu szablonów, który ładuje pakiety i dane, których zawsze używam, i nie mam nic przeciwko temu, aby mieć w swoim obszarze roboczym
• ładunki 00_functions.R(wstępnie wypełnione)
• ładuje dodatkowe biblioteki
• ustaw zmienne globalne

02_load data.R

• ładuje csv/txt xlsx RDS, dla każdego typu pliku jest wstępnie wypełniony komentarz
• wyświetla pliki, które zostały utworzone w obszarze roboczym

03_pull data from DB.R

• Używa dbplyrdo pobierania filtrowanych i pogrupowanych tabel z bazy danych
• niektóre wstępnie wypełnione wiersze z komentarzem, aby skonfigurować połączenia i pobrać.
• Ogranicz operacje po stronie klienta do minimum
• Brak operacji po stronie serwera poza tym skryptem
• Wyświetla pliki, które zostały utworzone w obszarze roboczym
• Zapisuje te zmienne, aby można je było szybciej załadować

Po wykonaniu tej czynności query_dbwyłączę wartość logiczną, a dane zostaną ponownie załadowane od RDSnastępnego razu.

Może się zdarzyć, że muszę przelać dane do baz danych, jeśli tak, to utworzę dodatkowe kroki.

04_Build.R

• Wranglowanie danych, cała zabawa dplyr/ tidyrrzeczy tam idą
• wyświetla pliki, które zostały utworzone w obszarze roboczym
• zapisz te zmienne

Po wykonaniu tej czynności buildwyłączę wartość logiczną, a dane zostaną ponownie załadowane od RDSnastępnego razu.

05_Analyse.R

• Podsumuj, modeluj ...
• raport exceli csvpliki

95_build ppt.R

• szablon raportu Powerpoint za pomocą officer

96_prepare markdown.R

• setwd
• ładować dane
• w razie potrzeby ustaw parametry przeceny
• render

97_prepare shiny.R

• setwd
• ładować dane
• w razie potrzeby ustaw błyszczące parametry
• runApp

98_Markdown report.Rmd

• Szablon raportu

99_Shiny report.Rmd

• Szablon aplikacji

Aby napisać szybki wstępny raport lub wiadomość e-mail 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 najlepiej jest zrzut ekranu z mapą bitową (np. Na Macu, Apple -Shift- (Ctrl) -4). Myślę, że jest to niedoceniana technika.

Dla bardziej końcowego raportu, pisanie funkcji R w celu łatwego ponownego wygenerowania wszystkich wykresów (jako plików) jest bardzo ważne. Kodowanie zajmuje więcej czasu.

W przypadku większych problemów z przepływem pracy podoba mi się odpowiedź Hadleya na wyliczenie plików kodu / danych dla przepływu czyszczenia i analizy. Wszystkie moje projekty analizy danych mają podobną strukturę.

Dodam mój głos do swave. W przypadku skomplikowanej, wieloetapowej analizy można użyć makefile do określenia różnych części. Może zapobiec powtarzaniu całej analizy, jeśli zmieniła się tylko jedna część.

Robię też to, co robi Josh Reich, tylko to robię, tworząc moje osobiste pakiety R, ponieważ pomaga mi to ustrukturyzować kod i dane, a także dość łatwo jest dzielić się nimi z innymi.

1. utwórz moją paczkę
2. Załaduj
3. czysty
4. Funkcje
5. robić

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

ładuj i czyść: Tworzę skrypty w surowym / podfolderze danych mojego pakietu do ładowania, czyszczenia i przechowywania wynikowych obiektów danych w pakiecie przy użyciu devtools :: use_data (nazwa_obiektu). Następnie kompiluję pakiet. Odtąd wywoływanie biblioteki (nazwa_pakietu) udostępnia te dane (i nie są one ładowane, dopóki nie są konieczne).

funkcje: umieszczam funkcje dla moich analiz w podfolderze R / mojego pakietu i eksportuję tylko te, które trzeba wywołać z zewnątrz (a nie funkcje pomocnicze, które mogą pozostać niewidoczne).

do: Tworzę skrypt, który wykorzystuje dane i funkcje przechowywane w moim pakiecie. (Jeśli analizy muszą być wykonane tylko raz, mogę również umieścić ten skrypt w zasobniku danych / podfolderze, uruchomić go i zapisać wyniki w pakiecie, aby był łatwo dostępny).