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

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

• Детские имена из администрации социального обеспечения
• Более 30 лет данных экономии топлива из EPI
• Большая коллекция данных о жилищном кризисе
• Оценки фильмов из IMDB
• Данные о продажах домов в зоне залива

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

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

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

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

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

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

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}

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

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

• Подготовьте данные.
• Подготовьте шаблон отчета.
• Создайте отчет.

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

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

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

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

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

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

Организация кода: Что касается организации кода, я нахожу две полезные стратегии:

• Читайте о рабочем процессе анализа (например, ProjectTemplate, Идеи Джоша Рейха, моя собственная презентация о рабочем процессе R Slides и Video)
• Изучите примеры отчетов и определите рабочий процесс
  • Примеры Хэдли Уикхэма
  • Мои примеры в github
  • Примеры воспроизводимых исследований, перечисленных в Cross Validated

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

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

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

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

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

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

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

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

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

Я добавлю свой голос к sweave. Для сложного многошагового анализа вы можете использовать makefile, чтобы указать разные части. Может помешать повторить весь анализ, если только одна часть изменилась.

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

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

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

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

• info: pdfs, powerpoints, docs... которые не будут использоваться никаким script
• 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

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

01_initialize.R

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

02_load data.R

• загружает csv/txt xlsx RDS, там есть предварительно заполненная строка комментариев для каждого типа файлов
• показывает, какие файлы были созданы в рабочей области

03_pull data from DB.R

• Использует dbplyr для извлечения отфильтрованных и сгруппированных таблиц из DB
• некоторые предварительно заполненные прокомментированные строки для настройки соединений и выборки.
• Удерживайте операции на стороне клиента до минимального уровня
• Никаких операций на стороне сервера вне этого script
• Показывает, какие файлы были созданы в рабочей области
• Сохраняет эти переменные, чтобы их можно было перезагрузить быстрее

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

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

04_Build.R

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

Как только это будет сделано после того, как я отключу логическое build boolean, и данные будут перезагружены с 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

• Шаблон приложения

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

• создать мой пакет
• нагрузки
• чистый
• Функции
• сделать

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

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

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

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