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

R Markdown прочно вошел в инструментальный стек R и воспринимается как базовый компонент. Однако, применительно к R Markdown практически все осуществляют такой же промах. Связка «R Markdown — это html отчет» формируется на первом шаге и дальше именно так и применятся. Реальность несколько многообразнее.

Все предыдущие публикации на habr.

Для начала краткий список ключевых ссылок по теме R Markdown:

• R Markdown homepage
• R Markdown: The definitive guide
• R Markdown Cookbook
• bookdown: Authoring Books and Technical Documents with R Markdown
• Dynamic Documents with R and knitr, Second edition
• R Markdown for Scientists
• Advanced R Markdown Workshop
• knitr: chunk options and package options

Что мы видим? Да, Literate Programming. Текст и код, расчеты на этапе генерации документа, вставка полученных артефактов в генерируемый отчет. Отчеты как стартовая позиция, презентации, сайты и книги как производные артефакты.

На этом можно было бы остановить — возможностей открывается масса. Но у R Markdown есть еще пара отличных способов применения, которые могут существенно расширить список решаемых задач.

Опция 1

Тему эту кратко затрагивал в публикации «R Markdown. Как сделать отчет в условиях неопределенности?». Rmd — такой же текстовый файл, только он собирается через поэтапный процессинг чанков. По сути, это аналог комплекса для полного цикла ремонта дорог. Сняли асфальт, тут же его переработали, добавили нужные компоненты, уложили и укатали. В один проход.

https://www.wirtgen-group.com/ru-ua/news-and-media/wirtgen-group/ctt-2016/

Такое свойство позволяет использовать технику метапрограммирования, когда исходный код будет формировать код для проходчика knitr, который, в свою очередь, будет уже формировать сам документ.

Не надо путать с шаблонизацией, дело куда интереснее. Появляется возможность программно управлять структурой, содержанием и способом отображения. В зависимости от поступаемых на вход данных можно:

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

Под изменением формы подразумевается не простое масштабирование, а именно изменение презентации, например, принудительная смена размеров рендеринга графиков для сохранения детализации, изменение формы представления с гистограмм на линейный, замена графиков на таблицы и т.д. Не забываем, что формы представления существуют разные — .html для просмотра и .docx/.pdf для «твердых копий».

Опция 2

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

Увы, реальный мир накладывает иногда ограничения. Приходится искать компромиссы, жить в рамках приземленных задач и ограниченных бюджетов. Но что отстается неизменным — ожидание выдача результатов на уровне не хуже! И вот тут R Markdown может оказать очень полезную услугу. Что в части ETL, что в части MLOps, да и много еще где.

Дело в том, что Rmd — это всего-лишь способ обертки R/python кода. Обрамили код бэктиками, добавили шапку и все! Утрирую немного, но с технической точки зрения совершенно неважно запускать Rscript script.R или Rscript -e "rmarkdown::render('script.Rmd', params=list(args = myarg))". И это открывает ряд огромных возможностей. В каждой организации существует множество задач, которые на регулярной основе процессят данные. Кроме отчетов, как написано выше, это могут быть разнообразные нетривиальные ETL задачи, валидации и сверки консистентности, операционная аналитика, средства самодиагностики различных ИТ систем и процессов, обучение ML моделей и т.д.

Вместо классических python скриптов можно использовать параметризированные Rmd скрипты. Параметризация позволяет добавить дополнительной гибкости для вызова из командной строки. При этом совершенно бесплатно получается ряд очень важных артефактов на основе html отчетности, которые важны для игры «вдолгую».

1. Мы не ограничены куцыми рамками syslog, каждое исполнение скрипта завершается генерацией полноценного storytelling отчета. В зависимости от выполняемой задачи, в отчете может быть проведена полная и детальная сводка проведенной работы. С текстом, мат. анализом, графиками, таблицами. Как прошел ETL? Какие были ошибки, каковы свойства прокаченных датасетов? Как прошло обучение модели? Какие графики ошибок, какие модели были выбраны, какая точность? А как оно эволюционирует в разрезе неделя к неделе? А как было год назад? Весь такой анализ можно сразу вложить в отчет.
2. Поскольку Rmd является скриптом — он позволяет выполнить все доступные side эффекты: сгенерировать файлы, записать в базу, провести операции на файловой системе, поработать с внешними веб-сервисами.
3. Готовый html отчет, как правило, весит совсем немного — несколько мегабайт. Можно хранить историю ежедневных выполнений вплоть до царя Гороха. Это же ведь крайне важный момент, который всегда всплывает в enterprise. Всегда может возникнуть потребность взглянуть, как оно было год назад. У нас есть код, сейчас взглянем! Да кабы не так. Для воспроизводимых вычислений важен не только код, но и все окружение. Естественно, что со временем и код и окружение эволюционирует — нельзя весь мир поместить в янтарь. Поэтому, имея на руках код для генерации отчета, нет никакой гарантии, что через полгода вперед будет возможность собрать его на нынешних данных. Фактически, html отчет текущего исполнения скрипта является аналогом фотографий машины каршеринга. Вы покатались — и ничего кроме фото не осталось. Что сфотографировали — то с вами и осталось.

Вот он, архив всех операций прогрузки, валидации, обучения,… И все это можно сделать своими руками здесь и сейчас, используя только Rmd + cron, а бэкап архива отчетных результатов сохранять на одну «флешку».

Заключение

Считаете, что все это «workaround»? Возможно. Но такой бюджетный подход прекрасно работает во многих задачах и результат получается в кратчайшие сроки.

Data Governance, Data Lake, MLOps и прочие правильные концепты очень хороши в теории. На практике до них надо дорасти и при этом потратить непомерные бюджеты и запастисть не одним годом времени. И практически невозможно возражать, что набор самодостаточных автономных «агентов» с глубокой самодиагностикой надежнее и стабильнее единого Колосса. Как говорится, «у семи Big Brothers дитя всё в синяках».

Да и сами RStudio активно предлагают подобный подход в своих коммерческих продуктах. Посмотрите прекрасное видео Thomas Mock «Build & Share Data Products Like The World’s Leading Companies with RStudio Team». Примерно с 34-ой минуты идет демонстрация системы для аренды велосипедов и там рассказывается архитектура с применением Rmd для задач ETL.

В open-source редакциях можно самостоятельно на Shiny сваять что-то простое и функциональное:

Пока все строят цифровой космос, реальный бизнес живет в реальном мире и зарабатывает реальные деньги. Если можно сделать быстро, дешево и хорошо — почему не сделать? Как говорится, не одним питоном…