На первый взгляд, это два непересекающихся мира. Но на практике, это не так.

Ниже дан краткий локальный комментарий к хорошей статье «Не спать! Как мы научились тиражировать релизы на 12000 касс за ночь» в части системы мониторинга качества обновления ПО и применению R в этой задаче.

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

Достаточно часто возникает потребность проведения периодических вычислений и подготовки консолидированного отчета по самодостаточным данным. Т.е. по данным, которые хранятся в виде файлов. Это могут быть данные, набранные из открытых источников, различные документы и excel таблицы, выгрузки из корпоративных систем. Данные в сыром виде могут занимать как несколько мегабайт, так и несколько гигабайт. Данные могут быть обезличенными, либо содержать конфиденциальную информацию. В том случае, когда код вычислений помещается в репозиторий, а работа ведется более чем одним человеком более чем на одном компьютере, возникает проблема сохранения консистентности кода и данных. При этом необходимо еще обеспечить соблюдение разных прав доступа к коду и данным. Что делать?

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

Закончились новогодние праздники, можно подвести итоги.
Важный комментарий: Это не реклама, это печальный опыт.

В этом году решили посмотреть на альтернативные елочные концепции и сходили на 'Семейное IT-приключение — Код «Новый год» 2020' от Алгоритмики. Описания и рассказы менеджеров были очень интересными, вроде как намечался увлекательный квест. Хороший повод поддержать детский интерес к алгоритмизации и программированию.

Задавив имевшийся скептицизм, полученный на предыдущих экспериментах с Алгоритмикой, решили дать еще шанс. Но горечь и полученное разочарование от этого мероприятия, которое можно было бы достойно номинировать на "самое провальное мероприятие 2019 года", вынуждают дать краткие комментарии по этому регулярному перформансу, чтобы дать колеблющимся информацию о том, как это было на самом деле, а не махать рекламными слайдами. Ну и где же поделиться впечатлениями от ИТ елки, как не на тематическом ресурсе? Все далее написанное рассматривать как ИМХО.

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

• Вариант 1 — давайте решать частную задачу в общем виде. Решив ее таким образом, мы сможем попутно много чего еще порешать.
• Вариант 2 — давайте для предсказания поведения нелинейной системы притянем сюда прогнозы, ML и массу модных штучек. Круто ведь.

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

Каждый раз, когда начинается разговор об использовании различных БД в качестве источника данных, появляется тема идентификаторов записей, объектов или чего-либо иного. Иногда согласование протокола обмена может рассматриваться участниками несколько месяцев. int-bigint-guid, далее по кругу. Для объемных задач, с учетом того, что нативно в R нет поддержки bigint (емкость ~2^64) выбор правильного представления таких идентификаторов может оказаться критичным в части производительности. Есть ли очевидное и универсальное обходное решение? Ниже несколько практических соображений, которые могут применяться в проектах в качестве лакмусовой бумажки.

Как правило, идентификаторы будут использоваться для трех классов задач:

• группировка;
• фильтрация;
• объединение.

Исходя из этого и оценим различные подходы.

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

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

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

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

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

Сразу отмечу, что тема будет интересна далеко не всем. Кому это неактуально — проходите мимо. У кого будут доп. идеи, было бы интересно тоже ознакомиться. Далее будет ряд задачек, которые были позаимствованы с курсов «Меташколы», математика 3-ий класс. Естественно, что сначала задача решается логическими рассуждениями, потом обсуждается способ решения с применением компьютера.

Важные дополнения по результатам обсуждений ниже:

1. Материал написан с позиции родителя, а не преподавателя. Здесь нет услуг и пиара. Здесь просто набор практических соображений.
2. В качестве инструмента использовался R потому что так было удобнее.

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

Параллельные или распределенные вычисления — вещь сама по себе весьма нетривиальная. И среда разработки должна поддерживать, и DS специалист должен обладать навыками проведения параллельных вычислений, да и задача должна быть приведена к разделяемому на части виду, если таковой существует. Но при грамотном подходе можно весьма ускорить решение задачи однопоточным R, если у вас под руками есть хотя бы многоядерный процессор (а он есть сейчас почти у всех), с поправкой на теоретическую границу ускорения, определяемую законом Амдала. Однако, в ряде случаев даже его можно обойти.

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

Краткая заметка по теме business process mining в контексте роста интереса к концепции "digital twin". В силу периодического выплывания этой темы считаю целесообразным поделиться подходами к решению.

Постановка задачи

Ситуация предельно проста.

• Есть компания X (Y, Z, ...).
• В компании есть бизнес-процессы, автоматизированные различными ИТ системами.
• Есть бизнес-аналитики, которые нарисовали bpmn диаграммы по этим процессам. Если говорить точнее, их собственное "bpmn представление" о том, как эти процессы должны были бы выглядеть.
• Бизнес пользователи хотят иметь какое-то представление (KPI) по этим процессам.

Как докопаться до истины и посчитать эти метрики?

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

Как эффективно работать с json в R?

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

Публикация по выступлению на секции R meetup @ Moscow Data Science Major (Spring 2019).
Вся презентация в pdf формате.

Почему этот вопрос актуален?

Бизнес-кейсы различны, техническая суть одинакова

• Аналитика работы колл-центра
• Аналитика продаж, включая прогнозы
• Антифрод системы
• Business process mining
• Различные аудиты (технические, финансовые)
• Складские и логистические задачи
• Activity-based costing
• Business-process monitoring
• Log-based аналитика
• Capacity management
• Текстовая аналитика (e-mail, service-desk)
• "Гибкие" дашборды и отчеты
• "интеллектуальные шины" между учетными системами (1С, СКУД, SAP, ...) и исполнительными
• ...

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

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

Но рассуждать с бизнесом о нулевых гипотезах и значении p-value совершенно бесполезно и контрпродуктивно.

Как можно по состоянию на февраль 2019 года сделать это максимально просто и быстро имея под руками ноутбук «средней руки»? Заметка реферативная, формул нет.

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

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

Все дело в том, что, в отличии от классических проектов по поставке железа или внедрению вендорских решений, укладывающихся в линейную модель исполнения, задачи, связанные с продвинутой аналитикой (data science) очень трудно формализуются в виде четкого и однозначного ТЗ в виде достаточным для передачи исполнителю. Ситуация отягощается тем, что для реализации задачи требуется интеграция массы различных внутренних ИТ систем и источников данных, часть вопросов и ответов может появиться только после того, как начинается работа с данными и вскрывается реальное положение дел, сильно отличающееся от документальной картины мира. Это все означает, что для написания грамотного ТЗ необходимо провести предварительную часть работы сопоставимую с половиной проекта, посвященную изучению и формализации реальных потребностей, анализу источников данных, их связей, структуры и пробелов. В рамках организаций сотрудников, которые способны провернуть такую масштабную работу, практически не бывает. Вот и получается, что на конкурсы выкладывают совсем сырые требования. В лучшем случае конкурсы отменяются (отправляются на доработку) после цикла уточняющих вопросов. В худшем случае — за громадный бюджет и длинные сроки получается нечто, совершенно не похожее на планы авторов требований. И остаются они у разбитого корыта.

Разумной альтернативой является создания внутри компании команды data science (DS). Если не замахиваться на строительство египетских пирамид, то команда и 2-3 грамотных специалистов может сделать весьма и весьма много. Но тут возникает другой вопрос, как подготовить этих спецов. Ниже хочу поделиться набором успешно апробированных соображений по быстрой подготовке такого «спецназа» с R в качестве оружия.

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

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

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

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

Комментарии в последней публикации «Насколько open-source экосистема R хороша для решения бизнес-задач?» насчет выгрузок в Excel привели к мысли, что имеет смысл потратить время и описать один из апробированных возможных подходов, который можно реализовать не выходя из R.

Ситуация достаточно типична. В компании всегда есть N методик по которым менеджеры вручную стараются строить в Excel отчеты. Даже если их и втоматизировать всегда остается ситуация, когда нужно срочно сделать какой-то новый произвольный срез или сделать представление для какого-либо руководителя в специфическом виде.

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

В силу того, что никакого подходящего инструмента (масса доп. нюансов будет ниже) так и не удалось найти, пришлось сваять «универсальный конструктор» на Shiny+R. В силу универсальности и параметризуемости настроек, такой конструктор можно легко сажать почти на любую систему в любой предметной области.

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

Поводом для публикации послужила запись в блоге Rstudio: «Shiny 1.1.0: Scaling Shiny with async», которая может очень легко пройти мимо, но которая добавляет очень весомый кирпичик в задаче применения R для задач бизнеса. На самом деле, в dev версии shiny асинхронность появилась примерно год назад, но это было как бы несерьезно и «понарошку» — это же dev версия. Перенос в основную ветку и публикация на CRAN является важным подтверждением, что многие принципиальные вопросы продуманы, решены и протестированы, можно спокойно переносить в продуктив и пользоваться.

А что еще есть в R, кроме «бриллианта», что позволяет превратить его в универсальный аналитический инструмент для практических задач?

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

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

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

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

Мотивом для этой публикации послужил доклад «Using the R Software for Log File Analysis» на конференции USENIX, который был обнаружен в интернете при поиске ответов на очередные вопросы. Поскольку была написана целая печатная статья, логично предположить, что тема обладает актуальность. Поэтому решил поделиться примерами решения подобного рода задач, решению которых не придавалось такого значения. Фактически, «заметки на полях».
R, действительно, очень хорошо подходит для подобных задач.

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

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

Неожиданно оказалось, что для одной из задач, которую пришлось решать примерно год назад, а именно оценка «надежности» большого коллектива, нынче есть весьма популярное название «HR аналитика». Актуализируя в рамках новой задачи материалы, вышел на просторах российского интернета на информативный блог по теме HR-аналитики. Собственно говоря, этот блог + обсуждение вопросов с его автором Эдуардом Бабушкиным и послужили отправной точкой для пересмотра проблематики.

Настоящая публикация носит, скорее, дискуссионно-аналитический характер, нежели утверждающий. Какие подходы и методы оптимальны для задачи HR аналитики, что можно сделать средствами R. Эта неоднозначность вызвана тем, что объектом исследования являются не явления природы, а поведение людей, которое не всегда логично и предсказуемо, особенно при переходе от коллектива к отдельному человеку.

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

Естественно, что название является потешным, но, как хорошо известно, в каждой шутке есть доля правды. Сама тема возникла, когда в очередной сотый раз пришлось слышать настойчивое пожелание о том, что необходим «гибкий конструктор отчетов/графиков». После определенного момента проще взять и сделать, чем в очередной раз объяснять, что tidyverse покрывает все необходимые потребности.

Сама постановка задачи предельно проста: обеспечить графический интерфейс для рисования разнообразных графических представлений по произвольным табличным данным. Классическое решение представляет собой две связанные сущности:

• интерфейс с большим-большим количеством менюшек и кнопочек, с множественными закулисными IF для управления взаимными состояниями этих элементов;
• «гибкий плоттер» с большим количеством вложенных IF для отрисовки графиков в соотвествии со скормленным данными и положением кнопочек-ползунков, выставленных в UI.

С одной стороны делать «Yet Another Tableau» совершенно неинтересно. С другой стороны, постановка в стиле «сделать так, чтобы все было, но ничего не надо делать» — типичная задача для ТРИЗ.

В целом, после непродолжительных размышений было выработано решение, которое почти удовлетворяет последней постановке. Само Shiny приложение пока под NDA, свободно публикуемый прототип приведен на картинке.

Две ключевых идеи по упрощению задачи следующие (ничего нового, все уже придумано до нас):

1. вместо статически заданного UI переходим к динамически генерируемому;
2. используем интерпретатор R не только для исходного кода, но и внутри самого кода.

Идея 1. Динамический web-интерфейс

Вариант, когда все управляющие элементы статически заданы и меняется лишь их параметризация (название, состояние, списки, выбранные элементы ...) удобен на этапе дизайна. Все понятно, все очевидно, можно ручками пощупать. Но если допустимые состояния этих элементов очень сильно связано как с исходными данными для анализа (data.frame), так и с состоянием друг друга, мы попадаем в ситуацию весьма большого количества нетривиальных обработчиков событий по каждому элементу. Много-много запутанного кода.

Сделаем по-другому. Вместо UI элементов со сложным поведением раскидываем с помощью uiOutput placeholder-ы, в которые динамически рассчитываем и генерируем с помощью shiny::renderUI представление этого элемента. Все внешние параметры, требуемые для генерации элемента, трактуем как реактивные элементы (reactive). При этом все такие интерактивные элементы выступают в качестве «автономных агентов», которые смотрят на окружение и подстраиваются под него. Пользователь изменил состояние одного элемента — все зависимые стали пересчитывать по очереди свое состояние (мы явно не обрабатываем события, а используем реактивный подход shiny). При изменении их состояния могут возникнуть новые индуцированные изменения. И так, пока все не стабилизируется.

  observeEvent(input$gen_plot, { # код демонстрирует принцип

    escname <- function(x){
      # имена колонок надо закавычить
      # .....
    }

    point_code <- ""
    if(input$shape_type!="__NO_MAPPING__") {
      aes <- c("shape"=escname(input$aes_shape_col), "color"=escname(input$aes_color_col))
      point_code <- buildPointCode(fixed=c("shape"=input$shape_type, "color"=glue("'{input$plot_color}'")), aes=aes)
    }

    line_code <- ""
    if(input$line_type!="__NO_MAPPING__") {
      aes <- c("linetype"=escname(input$aes_linetype_col), "color"=escname(input$aes_color_col))
      line_code <- buildLineCode(fixed=c("linetype"=input$line_type, "color"=glue("'{input$plot_color}'")), aes=aes)
    }

    gcode <- glue("ggplot(data_df(), aes(x=`{input$x_axis_value}`, y=`{input$y_axis_value}`))\\
                  {point_code} {line_code} + xlab('{input$x_axis_label}')") %>%
      style_text(scope="spaces")

    plot_Rcode(gcode)
  })