Есть ли у кого-нибудь мудрость в рабочих процессах для анализа данных, связанных с записью пользовательских отчетов? Практический пример:
Клиент отправляет отчет, в котором используется анализ данных, например. оценка популяции и соответствующие карты для водного округа.
Аналитик загружает некоторые данные, обрабатывает данные и сохраняет результат (например, добавление столбца для совокупности на единицу или подмножество данных на основе границ округа).
Аналитик анализирует данные, созданные в (2), приближается к своей цели, но видит, что для этого требуется больше данных, и поэтому возвращается к (1).
Повторно промойте, пока таблицы и графика не соответствуют QA/QC и не удовлетворяют клиенту.
Напишите отчет, содержащий таблицы и графику.
В следующем году счастливый клиент возвращается и хочет обновления. Это должно быть так же просто, как обновить данные восходящего потока путем новой загрузки (например, получить разрешения на строительство за последний год) и нажать кнопку "RECALCULATE", если технические изменения не изменились.
На данный момент я просто запускаю каталог и рекламирую его как можно лучше. Я хотел бы получить более систематический подход, поэтому я надеюсь, что кто-то это понял... Я использую сочетание электронных таблиц, инструментов SQL, ARCGIS, R и Unix.
Спасибо!
PS:
Ниже приведен базовый Makefile, который проверяет зависимости для разных промежуточных наборов данных (суффикс w/ .RData
) и скриптов (суффикс .R
). Для использования зависимостей используйте метки времени, поэтому, если вы touch ss07por.csv
, он увидит, что этот файл более новый, чем все файлы/цели, которые зависят от него, и выполните указанные сценарии, чтобы соответствующим образом обновить их. Это все еще продолжается, включая шаг для ввода в базу данных SQL и шаг для языка шаблонов, например sweave. Обратите внимание, что Make полагается на вкладки в своем синтаксисе, поэтому прочитайте руководство перед резкой и вставкой. Наслаждайтесь и дайте отзывы!
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
Я вообще разбиваю свои проекты на 4 части:
load.R: берет на себя загрузку всех необходимых данных. Обычно это короткий файл, считывающий данные из файлов, URL-адресов и/или ODBC. В зависимости от проекта на этом этапе я либо выпишу рабочую область с помощью save()
, либо просто сохраним вещи в памяти для следующего шага.
clean.R: Здесь живет весь уродливый материал - забота о недостающих значениях, слияние кадров данных, обработка выбросов.
func.R: Содержит все функции, необходимые для выполнения фактического анализа. source()
'В этом файле не должно быть никаких побочных эффектов, кроме загрузки определений функций. Это означает, что вы можете изменить этот файл и перезагрузить его без необходимости повторять шаги 1 и 2 повторения, которые могут занять много времени для больших наборов данных.
do.R: Вызывает функции, определенные в func.R, для выполнения анализа и создания диаграмм и таблиц.
Основная мотивация для этой настройки - работа с большими данными, при которой вы не хотите перезагружать данные каждый раз, когда вы делаете изменения на следующий шаг. Кроме того, сохранение моего кода таким образом означает, что я могу вернуться к давно забытому проекту и быстро прочитать load.R и выяснить, какие данные мне нужно обновить, а затем посмотреть на do.R, чтобы выяснить, какой анализ был выполнен.
Если вы хотите увидеть несколько примеров, у меня есть несколько небольших (и не очень маленьких) проектов по очистке и анализу данных, доступных в Интернете. В большинстве случаев вы найдете script для загрузки данных, один для их очистки, а некоторые - для исследования и анализа:
Недавно я начал нумерацию скриптов, так что это совершенно очевидно, в каком порядке их нужно запускать. (Если я чувствую себя действительно фантазией, я иногда делаю так, чтобы исследование 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 включают:
Организация кода: Что касается организации кода, я нахожу две полезные стратегии:
Я собираюсь предложить что-то в другом направлении от других отправителей, исходя из того, что вы конкретно задавали вопрос о рабочем процессе проекта, а не о инструментах. Предполагая, что вы относительно довольны своей моделью создания документов, похоже, что ваши проблемы действительно могут быть сосредоточены вокруг проблем отслеживания версий, управления активами и процесса просмотра/публикации.
Если это звучит правильно, я бы предложил изучить интегрированный инструмент для управления сайтом/источником/документацией, например 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... которые не будут использоваться никаким scriptdata 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
00_functions.R
00_functions_something.R
, в частности, если я планирую сделать пакет из некоторых из них, я разберу их00_explore.R
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Как только это было сделано после отключения буфера query_db
и данные будут перезагружены с RDS
в следующий раз.
Может случиться так, что я должен пересылать данные в БД, если так, я создам дополнительные шаги.
04_Build.R
dplyr
/tidyr
идут тудаКак только это будет сделано после того, как я отключу логическое build
boolean, и данные будут перезагружены с RDS
в следующий раз.
05_Analyse.R
excel
и csv
файлы95_build ppt.R
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, а также в исходную/подпапку данных, запустить его и сохранить результаты в пакете, чтобы сделать его легко доступным.)