Решения на базе R, как классические «отчетные», так и в контуре операционной аналитики, очень хорошо себя зарекомендовали в enterprise окружении. Несомненно, значительную роль в этом играет компания RStudio и ее увлеченный коллектив. В коммерческих продуктах RStudio можно не думать об инфраструктурных вопросах, а просто обменять небольшую денежку на готовые решение «из коробки» и положиться на их разработчиков и поддержку. В open-source редакциях, а большинство инсталляций в российских компаниях именно такие, приходится думать про инфраструктурные вопросы самостоятельно.
Решения на R хорошо закрывают нишу «средних данных», когда данных «чуть больше» чем влезает в excel или в ненастроенную реляционку и нужны сложные алгоритмы и процессинг, но когда разворачивать пусковой комплекс бигдаты еще более чем рано. Речь идет о десятках-сотнях террабайт в полном объеме, которые легко умещаются в бэкенд на Cliсkhouse. Важный момент: все находится во внутреннем контуре, в подавляющем большинстве случаев ПОЛНОСТЬЮ отрезанном от интернета.
Является продолжением серии предыдущих публикаций, уточняет публикацию «Конструктивные элементы надежного enterprise R приложения».
Проблематика
Для продуктивного решения необходимо обеспечить воспроизводимость результатов и вычислений. Задача воспроизводимости делится на несколько различных направлений. Крупными блоками можно выделить:
-
инфраструктурная воспроизводимость. Многие вопросы закрываются комбинацией технологий docker + renv + git.
-
программная воспроизводимость. Многие вопросы закрываются технологией пакетов и автотестов.
-
статистическая «похожесть» выдаваемых результатов. Тут уже возникает специфика каждой отдельной задачи. Ниже предложены отдельные моменты, позволяющие ее обеспечить.
В чем заключается сложность?
Алгоритмы, «выкатываемые в продуктив»
-
могут быть многофазными с совокупным временем расчета несколько часов;
-
могут использовать кроме данных из основного бэкенда множество дополнительных неструктурированных источников данных (внешние справочники, excel файлы, технические логи и т.д.);
-
опираются на данные, которые поступают от постоянно изменяемых объектов наблюдения и эволюционируют во времени;
-
могут активно использовать случайные выборки из данных бэкенда;
-
могут в рамках своего жизненного цикла постоянно уточняться и модифицироваться.
-
могут иметь на выходе не один показатель, а семейства таблиц в которых каждая метрика характеризуются своим распределением;
-
оценка корректности работы алгоритма может быть проведена только в конце вычислений, по расчету стат. характеристик выданных таблиц.
В таких случаях крайне затруднительно сделать тестовый набор данных (рефересный снапшот), а для ИТ служб задача бэкапа всего инстанса БД зачастую становится либо крайне дорогой либо непосильной. Приходится дополнять аналитические решения дополнительным модулем статистической самодиагностики, исполняемым как в продуктивном процессе так и по требованию. А также приходится применять широкий спектр средств отладки для быстрой диагностики возникших отклонений, как в prod контуре (постфактум), так и в dev среде.
Контроль в продуктивном контуре
Исходные постулаты
-
Валидация и логирование являются одним из основных способов. Чем раньше будет обнаружена ошибка, тем легче ее локализовать.
-
Техническая и логическая валидация поступающих параметров как при вызове собственных функций, так и при загрузке данных из источников.
-
Валидация стат. характеристик загружаемых источников позволяет обнаружить перекосы уже на этапе ввода.
-
Необходимо выбирать компромисс между глубиной охвата и сложностью проверок и временем их проведения.
-
Маркируйте используемые в расчетах данные и по мере возможности оставляйте на диске временные дампы
data.frame
в критических точках с тем, чтобы можно было повторно «проиграть» непонятную ситуацию при отладке.
Логирование
Существуют несколько популярных пакетов для логирования, каждый может выбрать на свой вкус:
Также есть подходы к логированию warning
и message
, все очень хорошо расписано в документации на указанные пакеты.
Стоит отметить, что в многопоточном исполнении логфайлы могут являться единственным окошком к сути происходящего в другом потоке.
С точки зрения формирования дампов, штатный подход с использованием .Rds
файлов для данных среднего размера (1-1000 Гб Ram) никуда не годится.
Существует 3 хорошие многопоточные альтернативы:
У каждого из формата есть свои сильные стороны — оптимальный вариант можно выбрать исходя из задачи. Какой объект сохраняется, нужен ли межплатформенный доступ, нужен ли последующий выборочный доступ с диска и т.д. Детальные бенчмарки и сравнения можно найти по приведенным ссылкам.
Валидация
Комбинируйте в зависимости от задачи и вкуса:
-
checkmate — физическая + базовая логическая;
-
skimr — базовая логическая;
-
validate — логическая;
-
dplyr / data.table — логическая.
Есть и другие пакеты, если этого будет недостаточно. Любители альтернативных решений могут почитать репозиторий Win-Vector.
Трекинг пайплайнов
Очень часто вычисления проводятся через pipe (%>%
). Все промежуточные результаты скрыты. Если что-то идет не так (а особенно часто «рвет» на слиянии со справочниками по «уникальному ключу», который ни разу не уникальный), то по выходу очень тяжело понять проблемный шаг. В таких случаях помогают пакеты, фиксирующие характеристики объектов, передаваемых посредством .
с шага шаг.
Вот примеры полезных пакетов для трекинга:
-
tidylog. Тут важно, что
tidylog
перехватывает глаголыtidyverse
, поэтому конструкцииdpylr::mutate
останутся без трекинга. -
lumberjack. Сохраняем изменения
Отладка
Есть масса хороших публикаций насчет отладки, например:
-
Книга «Advanced R», гл. «Debugging»
Какие сценарии на практике оказываются крайне востребованными (shiny здесь не затрагиваем)?
-
browser()
. Никаких точек останова в IDE. Хардкорное прерывание в любом месте и в любом сценарии исполнения. Бонусом — доп. трюк ниже. -
debug()
/undebug()
/debugonce()
. Для отладки функций, в т.ч., прилинкованных из пакетов. -
traceback()
. Докапываемся до причины в цепочке ассертов. -
options(datatable.verbose = TRUE)
. Что творится у основной рабочей лошадкиdata.table
под капотом (план запроса, перформанс, ошибки). -
utils::getFromNamespace
и пр. Хирургический скальпель для модификации функций из пакетов. -
Пакеты waldo и diffobj. Прецизионное сравнение небольших объектов.
-
pryr::object_size()
. Честное «взвешивание» объектов. -
Пакет
reprex
. Запрашиваем помощь друга. -
Пакет
gginnards
. Отладка графиков ggplot.
Трюк по использованию browser()
, отлаживаем внутренние циклы data.table
.
library(data.table) library(magrittr) dt <- as.data.table(mtcars) %>% .[, {m <- head(.SD, 2); print(ls()); browser(); m}, by = gear] #> [1] "-.POSIXt" "am" "carb" "Cfastmean" "cyl" "disp" #> [7] "drat" "gear" "hp" "m" "mpg" "print" #> [13] "qsec" "strptime" "vs" "wt" #> Called from: `[.data.table`(., , { #> m <- head(.SD, 2) #> print(ls()) #> browser() #> m #> }, by = gear)
Профилировка
Зачастую профилировка кода с целью повышения производительности помогает найти концептуальные проблемы по применению тех или иных функций. Длительное исполнение за счет неэффективных преобразований внутри функций (своих и чужих) порождает массу проблем и не дает реализовать алгоритм так, как хотелось бы изначально.
-
system.time({…})
Заключение
-
Инструменты и методы приведены.
Но что помогает более всего? Постоянно улучшать методы разработки и написания кода. Компактный, лаконичный, понятный и эффективный код будет содержать куда меньше ошибок. -
Для отдельного класса задач может оказаться целесообразно использовать
make
инструменты. drake/targets
Предыдущая публикация — «Как в enterprise приручить при помощи R технологии process mining?».
ссылка на оригинал статьи https://habr.com/ru/post/543552/
Добавить комментарий