Главная » Хабрахабр » Конструктивные элементы надежного enterprise R приложения

Конструктивные элементы надежного enterprise R приложения

Естественно, что методы удобные для консольного пошагового применения человеком, который глубоко в теме, оказываются малопригодными для создания приложения для конечного пользователя. Тем, кто работает с R, хорошо известно, что изначально язык разрабатывался как инструмент для интерактивной работы. (говорим R, подразумеваем, в основном, Shiny web приложения).
Однако, не все так плохо. Возможность получить развернутую диагностику сразу по факту ошибки, проглядеть все переменные и трейсы, выполнить вручную элементы кода (возможно, частично изменив переменные) — все это будет недоступно при автономной работе R приложения в enterprise среде. Ряд из них будет описан ниже. Среда R (пакеты и подходы) настолько сильно эволюционировали, что ряд весьма нехитрых трюков позволяет элегантно решать задачу обеспечения стабильности и надежности работы пользовательских приложений.

Является продолжением предыдущих публикаций.

И даже полностью отлаженный алгоритм, обложеные со всех сторон тестами и полностью задокументированный может легко сломаться и выдать ерунду, если ему на вход подсунут кривые данные.
Данные могут поступать на вход как от других информационных систем, так и от пользователей. Основной спектр задач для которых часто применяется R — разнообразная обработка данных. Человек может ошибиться и подсунуть не тот файл, написать в него не то. И, если в первом случае можно требовать соблюдения API и накладывать весьма жесткие ограничения на стабильность информационного потока, то во втором случае от сюрпризов никуда не деться. В этом случае задача еще больше усложняется. 99% пользователей используют в своей работе Excel и предпочитают подсовывать системе именно его, много страничный, с хитрым форматированием. Даты разъезжаются (весьма известная история «Excel’s designer thought 1900 was a leap year, but it was not»). Даже визуально валидный документ может выглядеть с точки зрения машины полной ерундой. Невидимые ячейки и скрытые формулы… И многое другое. Числовые значения хранятся как текст и наборот. Чего стоит только задвоение записей в различных join-ах с кривыми источниками. Предусмотреть все возможные грабли в принципе не получится — фантазии не хватит.

В качестве дополнительных соображенией примем следующие:

  1. Прекрасный документ «An introduction to data cleaning with R», описывающий процесс предварительной подготовки данных. Для дальнейших шагов из него мы выделим наличие двух фаз валидации: техническая и логическая.
    • Техническая валидация заключается в проверке корректности источника данных. Структура, типы, количественные показатели.
    • Логическая валидация может быть многоэтапной, осуществляемой по ходу проведения расчетов, и заключается в проверке соответствия тех или иных элементов данных или их комбинаций различным логическим требованиям.
  2. Одно из базовых правил при разработке пользовательских интерфейсов — формирование максимально полной диагностики в случае ошибок пользователей. Т.е., если уж пользователь загрузил файл, то надо его максимально проверить на корректность и выдать полную сводку со всеми ошибками (желательно еще и объяснить, что где не так), а не падать при первой же проблеме с сообщением вида «Incorrect input value @ line 528493, pos 17» и требовать загрузки нового файла с исправленной этой ошибкой. Такой подход позволяет многократно сократить количество итераций по формированию правильного источника и повысить качество конечного результата.

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

  1. Уже классический dplyr. В простых случаях бывает удобно просто нарисовать pipe c проведением ряда проверок и анализом конечного результата.
  2. Пакет validate для проверки технически корректных объектов на соответствие заданным правилам.

Для технической валидации остановились на следующих подходах:

  1. Пакет checkmate с широким спектром быстрых функций для проведения разнобразных технических проверок.
  2. Явная работа с исключениями «Advanced R. Debugging, condition handling, and defensive programming», «Advanced R. Beyond Exception Handling: Conditions and Restarts» как для проведения полного объема валидации за один шаг, так и для обеспечения стабильности работы приложения.
  3. Использование purr обертки для исключений. Весьма полезно при применении внутри pipe.

В случае языков с динамической типизацией проверку типов приходится делать самостоятельно. В коде, разбитом на функции, важным элементом «defensive programming» является проверка входных и выходных параметров функций. Для проверки data.frame остановились на примерно следующей конструкции (проверка имен и типов). Для базовых типов идеально подходит пакет checkmate, особенно его функции qtest\qassert. Трюк со слиянием имени и типа позволяет сократить количество строк в проверке.

ff <- function(dataframe1, dataframe2): checking '{.y}' parameter with expected structure '{collapse(.x, sep=', ')}'")) rlang::eval_bare(rlang::sym(.y)) %>% assertDataFrame(min.rows=1, min.cols=length(.x)) %>% {assertSetEqual(.x, stri_join(names(.), map_chr(., class), sep=" :: "), .var.name=.y)} # {assertSubset(.x, stri_join(names(.), map_chr(., typeof), sep=" :: "))} }) …
}

class был выбран, поскольку именно он дает дату как Date, а не как число (внутреннее представление). В части функции проверки типов можно выбирать метод по вкусу, сообразуясь с ожидаемыми данными. 'mode' and 'class' and 'typeof' are insufficient».
AssertEqual или AssertSubset выбираются из соображений четкого совпадения колонок или же минимально достаточного. Очень подробно вопрос определения типов данных разбирается в диалоге «A comprehensive survey of the types of things in R.

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

Предыдущая публикация — R как спасательный круг для системного администратора.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Профессиональные навыки, востребованные среди UX-специалистов (срез 2018)

С 29 августа по 07 сентября 2018 сообщество UX SPb (независимое сообщество UX-специалистов Санкт-Петербурга) проводило опрос, направленный на изучение профессиональных навыков специалистов по пользовательским интерфейсам. Сообщество обещало опубликовать результаты. Обещание исполнено 🙂 В исследовании приняли участие 109 респондентов. Опрос проводился ...

От антикварного радио до DIY-колонок: 12 каналов на YouTube про устройство акустики

Сегодня мы подготовили подборку YouTube-каналов, авторы которых рассказывают об устройстве винтажного и современного аудиооборудования: от настройки виниловых проигрывателей до сборки акустических систем. Всех, кому это интересно, приглашаем к просмотру под кат. Фото Nathan Duprey / CC Канал посвящен сборке акустических ...