Рабочий процесс для статистического анализа и написания отчетов

Есть ли у кого-нибудь мудрость в рабочих процессах для анализа данных, связанных с написанием пользовательских отчетов? Вариант использования в основном такой:

  1. Клиент заказывает отчет, в котором используется анализ данных, например, оценка численности населения и соответствующие карты для акватории.

  2. Аналитик загружает некоторые данные, анализирует их и сохраняет результат (например, добавление столбца для населения на единицу или поднабор данных на основе границ района).

  3. Аналитик анализирует данные, созданные в (2), приближается к своей цели, но видит, что нужно больше данных, и поэтому возвращается к (1).

  4. Промывка повторяется до тех пор, пока таблицы и графики не соответствуют требованиям QA/QC и не удовлетворят клиента.

  5. Написать отчет, включающий таблицы и графики.

  6. В следующем году счастливый клиент возвращается и хочет обновления. Это должно быть так же просто, как обновить исходные данные новой загрузкой (например, получить разрешения на строительство за последний год) и нажать кнопку "ПЕРЕЧИСЛИТЬ", если спецификации не изменятся.

На данный момент я просто запускаю каталог и делаю его как можно лучше. Мне нужен более систематический подход, поэтому я надеюсь, что кто-то это понял... Я использую сочетание электронных таблиц, инструментов SQL, ARCGIS, R и Unix.

Спасибо!

PS:

Ниже приведен основной Makefile, который проверяет зависимости от различных промежуточных наборов данных (с .RData суффикс) и сценарии (.R суффикс). Make использует временные метки для проверки зависимостей, так что если вы touch ss07por.csv, он увидит, что этот файл новее всех файлов / целей, которые зависят от него, и выполнит заданные сценарии, чтобы соответствующим образом обновить их. Это все еще в стадии разработки, включая этап для помещения в базу данных SQL и шаг для языка шаблонов, такого как sweave. Обратите внимание, что Make использует вкладки в своем синтаксисе, поэтому прочитайте руководство, прежде чем вырезать и вставить. Наслаждайтесь и оставляйте отзывы!

http://www.gnu.org/software/make/manual/html_node/index.html

R=/ дом / 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

14 ответов

Решение

Я обычно разбиваю свои проекты на 4 части:

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

load.R: заботится о загрузке всех необходимых данных. Обычно это короткий файл, считывающий данные из файлов, URL-адресов и / или ODBC. В зависимости от проекта на этом этапе я либо выписываю рабочее пространство, используя save() или просто сохранить вещи в памяти для следующего шага.

clean.R: Это то место, где живут все эти уродливые вещи - забота о пропущенных значениях, объединение фреймов данных, обработка выбросов.

func.R: содержит все функции, необходимые для фактического анализа. source()Использование этого файла не должно иметь никаких побочных эффектов, кроме загрузки определений функций. Это означает, что вы можете изменить этот файл и перезагрузить его, не возвращаясь к повторным шагам 1 и 2, которые могут занять много времени для работы с большими наборами данных.

do.R: вызывает функции, определенные в func.R, для выполнения анализа и создания диаграмм и таблиц.

Основной мотивацией для этой установки является работа с большими данными, в результате чего вам не нужно загружать данные каждый раз, когда вы вносите изменения в последующий шаг. Кроме того, поддерживая разделение моего кода таким образом, я могу вернуться к давно забытому проекту и быстро прочитать load.R и выяснить, какие данные мне нужно обновить, а затем посмотреть на do.R, чтобы выяснить, какой анализ был выполнен.

Если вы хотите увидеть несколько примеров, у меня есть несколько небольших (и не очень) проектов по очистке и анализу данных, доступных онлайн. В большинстве случаев вы найдете скрипт для загрузки данных, один для его очистки и несколько для исследования и анализа:

Недавно я начал нумерацию скриптов, поэтому совершенно очевидно, в каком порядке они должны выполняться. (Если я чувствую себя действительно странно, я иногда делаю так, чтобы сценарий исследования вызывал сценарий очистки, который, в свою очередь, вызывает сценарий загрузки, каждый из которых выполняет минимально необходимую работу - обычно проверяя наличие выходных файлов с помощью file.exists, Тем не менее, в большинстве случаев это кажется излишним).

Я использую git для всех своих проектов (система управления исходным кодом), поэтому легко сотрудничать с другими, видеть, что меняется, и легко откатываться до предыдущих версий.

Если я делаю официальный отчет, я обычно держу R и латекс отдельно, но я всегда удостоверяюсь, что могу source мой код R, чтобы произвести весь код и вывод, который мне нужен для отчета. Для отчетов, которые я делаю, я считаю это проще и чище, чем работать с латексом.

Я согласен с другими респондентами: Sweave отлично подходит для написания отчетов с R. А перестроить отчет с обновленными результатами так же просто, как повторно вызвать функцию Sweave. Он полностью самодостаточен, включая весь анализ, данные и т. Д. И вы можете контролировать версию всего файла.

Я использую плагин StatET для Eclipse для разработки отчетов, и Sweave интегрирован (Eclipse распознает формирование латекса и т. Д.). В Windows легко использовать MikTEX.

Я также добавил бы, что вы можете создавать красивые отчеты с Beamer. Создать обычный отчет так же просто. Ниже приведен пример, который извлекает данные из Yahoo! и создает диаграмму и таблицу (используя QuantMod). Вы можете построить этот отчет так:

Sweave(file = "test.Rnw")

Вот сам документ 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}

Я просто хотел добавить, на случай, если кто-то пропустит это, что есть отличный пост в блоге учащегося о создании повторяющихся отчетов с пакетом варки Джеффри Хорнера. Мэтт и Кевин оба упомянули выше. Я на самом деле не использовал это сам.

Записи следуют за хорошим рабочим процессом, поэтому его стоит прочитать:

  1. Подготовьте данные.
  2. Подготовьте шаблон отчета.
  3. Подготовить отчет.

На самом деле создание отчета после завершения первых двух шагов очень просто:

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

Для создания пользовательских отчетов я счел полезным включить многие из существующих советов, предложенных здесь.

Генерация отчетов. Хорошая стратегия создания отчетов включает комбинацию Sweave, make и R.

Редактор: Хорошие редакторы для подготовки документов Sweave включают в себя:

  • StatET и Eclipse
  • Emacs и ESS
  • Вим и Вим-Р
  • R Studio

Организация кода: с точки зрения организации кода, я считаю две стратегии полезными:

Я собираюсь предложить что-то в другом направлении от других авторов, основываясь на том факте, что вы спрашивали конкретно о рабочем процессе проекта, а не об инструментах. Предполагая, что вы относительно довольны своей моделью производства документов, похоже, что ваши проблемы действительно могут быть сосредоточены вокруг вопросов отслеживания версий, управления активами и процесса рецензирования / публикации.

Если это звучит правильно, я бы посоветовал обратиться к интегрированному инструменту создания билетов / управления исходным кодом / документации, например, Redmine. Хранение связанных артефактов проекта, таких как отложенные задачи, потоки обсуждений и версионные файлы данных / кода, может быть очень полезным даже для проектов, выходящих далеко за рамки традиционного "программирования".

Я использую Sweave для создания отчетов, но я также слышал о пакете варева - хотя я еще не изучал его.

По сути, у меня есть ряд опросов, по которым я составляю сводную статистику. Те же опросы, те же отчеты каждый раз. Я создал шаблон Sweave для отчетов (который требует немного работы). Но как только работа завершена, у меня есть отдельный R-скрипт, который позволяет мне указать новые данные. Я нажимаю "Go", Sweave выгружает несколько файлов.tex и запускаю небольшой скрипт на Python для их pdflatex. Мой предшественник тратил ~6 недель каждый год на эти отчеты; Я трачу около 3 дней (в основном на очистку данных; экранирующие символы опасны).

Вполне возможно, что сейчас есть более подходящие подходы, но если вы решите пойти по этому пути, дайте мне знать - я собирался поднять некоторые из моих хаков Свив, и это было бы хорошим ударом в штаны. так.

Договорились, что Sweave - это путь, с xtable для генерации таблиц LaTeX. Хотя я не потратил слишком много времени на работу с ними, недавно выпущенный пакет tikzDevice выглядит действительно многообещающе, особенно в сочетании с pgfSweave (который, насколько я знаю, в настоящее время доступен только на rforge.net - есть ссылка на r-forge оттуда, но в данный момент она мне не отвечает).

Между ними вы получите согласованное форматирование текста и рисунков (шрифты и т. Д.). С варевом, они могут составить священный грааль генерации отчетов.

На более "мета" уровне вас может заинтересовать модель процесса CRISP-DM.

Я использую шаблоны проектов вместе с R studio, в настоящее время мой содержит следующие папки:

  • info: pdfs, powerpoints, docs... которые не будут использоваться ни одним скриптом
  • data input: данные, которые будут использоваться моими скриптами, но не генерируются ими
  • data output: данные, сгенерированные моими сценариями для дальнейшего использования, но не в качестве правильного отчета.
  • reports: Только файлы, которые действительно будут показаны кому-то еще
  • R: Все R скрипты
  • SAS: Потому что мне иногда приходится:'(

Я написал пользовательские функции, чтобы я мог вызвать smart_save(x,y) или же smart_load(x) сохранить или загрузить RDS files к и от data output папка (файлы с именами переменных), поэтому меня не беспокоит paths во время моего анализа.

Пользовательская функция new_project создает пронумерованную папку проекта, копирует все файлы из шаблона, переименовывает RProj файл и редактирует setwd звонки и установите рабочий каталог для нового проекта.

Все R сценарии в R папка, структурированная следующим образом:


00_main.R
  • setwd
  • вызывает сценарии с 1 по 5

00_functions.R
  • Все функции и только функции идут туда, если их слишком много, я разделю их на несколько, все названные как 00_functions_something.Rв частности, если я планирую сделать пакет из некоторых, я разложу их

00_explore.R
  • куча фрагментов скриптов, где я тестирую вещи или изучаю свои данные
  • Это единственный файл, где мне разрешено быть грязным.

01_initialize.R
  • Предварительно заполнено с призывом к более общему initialize_general.R скрипт из папки с моими шаблонами, который загружает пакеты и данные, которые я всегда использую, и не возражаю
  • грузы 00_functions.R (Укажите)
  • загружает дополнительные библиотеки
  • установить глобальные переменные

02_load data.R
  • грузы csv/txtxlsxRDSесть предварительно заполненная строка комментария для каждого типа файла
  • отображает, какие файлы были созданы в рабочей области

03_pull data from DB.R
  • Пользы dbplyr получить отфильтрованные и сгруппированные таблицы из БД
  • некоторые предварительно заполненные закомментированные строки для установки соединений и выборки.
  • Сделайте операции на стороне клиента минимальными
  • Нет операций на стороне сервера вне этого скрипта
  • Показывает, какие файлы были созданы в рабочей области
  • Сохраняет эти переменные, чтобы они могли быть перезагружены быстрее

Как только это будет сделано, как только я выключу query_db логический и данные будут перезагружены с RDS в следующий раз.

Может случиться так, что мне придется передавать данные в БД. Если это так, я создам дополнительные шаги.


04_Build.R
  • Спор данных, все самое интересное dplyr / tidyr вещи идут туда
  • отображает, какие файлы были созданы в рабочей области
  • сохранить эти переменные

Как только это будет сделано, как только я выключу build логический и данные будут перезагружены с RDS в следующий раз.


05_Analyse.R
  • Подводя итог, модель...
  • доклад excel а также csv файлы

95_build ppt.R
  • шаблон для отчета PowerPoint с использованием officer

96_prepare markdown.R
  • setwd
  • загрузить данные
  • установить параметры уценки, если это необходимо
  • render

97_prepare shiny.R
  • setwd
  • загрузить данные
  • установить блестящие параметры при необходимости
  • runApp

98_Markdown report.Rmd
  • Шаблон отчета

99_Shiny report.Rmd
  • Шаблон приложения

"make" - это здорово, потому что (1) вы можете использовать его для всей своей работы на любом языке (в отличие, скажем, от Sweave и Brew), (2) он очень мощный (достаточно для сборки всего программного обеспечения на вашем компьютере), и (3) это избегает повторения работы. Этот последний пункт важен для меня, потому что большая часть работы идет медленно; когда я латексирую файл, мне нравится видеть результат через несколько секунд, а не час, который потребуется для воссоздания цифр.

Для написания быстрого предварительного отчета или электронного письма коллеге, я считаю, что может быть очень эффективно копировать и вставлять графики в MS Word, электронную почту или вики-страницу - часто лучше всего использовать растровый снимок экрана (например, на Mac, Apple-Shift-(CTRL)-4). Я думаю, что это недооцененная техника.

Для более окончательного отчета очень важно написание R-функций для простого восстановления всех графиков (в виде файлов). Это займет больше времени, чтобы закодировать это.

Что касается более крупных проблем рабочего процесса, мне нравится ответ Хэдли на перечисление файлов кода / данных для процесса очистки и анализа. Все мои проекты анализа данных имеют схожую структуру.

Я добавлю свой голос, чтобы вспыхнуть. Для сложного многоэтапного анализа вы можете использовать make-файл для указания различных частей. Может предотвратить повторение всего анализа, если изменилась только одна часть.

Я также делаю то, что делает Джош Рейх, только я делаю это, создавая свои персональные R-пакеты, так как это помогает мне структурировать мой код и данные, а также довольно легко делиться ими с другими.

  1. создать мой пакет
  2. нагрузка
  3. чистый
  4. функции
  5. делать

создание моего пакета: devtools::create('имя_пакета')

загрузка и очистка: я создаю сценарии в подпапке data-raw/ моего пакета для загрузки, очистки и сохранения результирующих объектов данных в пакете с помощью devtools::use_data(object_name). Затем я компилирую пакет. Отныне вызов библиотеки (имя_пакета) делает эти данные доступными (и они не загружаются до тех пор, пока они не понадобятся).

Функции: я помещаю функции для своих анализов в подпапку R/ моего пакета и экспортирую только те, которые должны вызываться извне (а не вспомогательные функции, которые могут оставаться невидимыми).

do: я создаю скрипт, который использует данные и функции, хранящиеся в моем пакете. (Если анализ нужно выполнить только один раз, я могу также поместить этот сценарий в подпапку data-raw/, запустить его и сохранить результаты в пакете, чтобы сделать его легко доступным.)

Другие вопросы по тегам