Еще примеры использования R для решения практических бизнес-задач22.11.2016 22:35

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


Case #1: Анализ документов (Web-scrapping)

Постановка проектной задачи проста. Необходимо провести экспертный анализ документов, доступных только по запросам на веб портале и по относящимся к исходной задаче составить аналитический отчет. Звучит просто если бы не следующие нюансы:


  1. БД документов недоступна напрямую.
  2. Никакого API к порталу не существует.
  3. Документы по прямой ссылке нельзя адресовать, только через механизм создания сессионного подключения и поиска.
  4. Полный текст документа недоступен, его показ формируется JS скриптами для «постраничного» листания.
  5. По каждому из подходящих документов необходимо, опираясь на plain text 1-ой страницы сделать реферативную сводку по его атрибутам.
  6. Документов ~100 тыс, реально относящихся к задаче ~0.5%, времени на первый релиз ~ 1 неделя.

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


Мы пошли другим путем, а именно, веб-скраппинг средствами R. По поводу веб-скраппинга в интернете и на хабре достаточно много материалов, не буду повторяться. Пример подобной публикации на хабре: «Web Scraping с помощью python».


В классическом подходе для подобных задач используют Perl\Python, но мы решили не делать микс из инструментов, а использовать R в боевых условиях. Задача была решена более чем успешно в таких конечных метриках:


  1. 0.5 дня на анализ портала (структура, запросы, ответы, навигация) средствами разработчиков, встроенных в Chrome\Firefox.
  2. 1 день на разработку R скриптов по подготовке списков документов и их последующему атрибутивному обогащению.
  3. ~8 часов на формирование задач, автоматизированный сбор данных и формирование табличного представления.
  4. ~2 дня на ручное ознакомление со списком, отсечение лишнего и прочтение потенциально подходящих документов. После прочтения неподходящими были признаны лишь пара десятков документов.

Несмотря на то, что документы генерировались динамически (JS), удалось найти лазейку по получению 1-ой страницы, а там были все необходимые атрибуты, и тем самым обойтись без Selenium\PahntomJS. Это существенно ускорило процесс сбора данных.


Более того, поскольку веб-запросы работают в асинхронном режиме, задача была распараллелена (средствами R). Время ~8 часов указано для исполнения на 4-х ядрах, так оно было бы раза в 3 дольше.


Группа «классических» аналитиков упорно продолжает работать…


Технические детали


  1. Для парсинга страниц и выбора необходимого контента использовались различные комбинации методик XPath+regexp.
  2. Весь код составил ~200 строк из которых 50% — комментарии и переносы длинных строк для соблюдения code conventions.
  3. Подключенный явными декларациями набор пакетов: 

library(lubridate)
library(dplyr)
library(tidyr)
library(tibble)
library(readr)
library(stringi)
library(stringr)
library(jsonlite)
library(magrittr)
library(curl)
library(httr)
library(xml2)
library(rvest)
library(iterators)
library(foreach)
library(doParallel)
library(future)

Case #2: Прогнозирование качества фабричной продукции

Постановка задачи также очень проста.


Есть технологическая линия по производству из сырья продукта. В ходе технологического процесса сырье подвергается различной физической обработке, а именно, пресс, формование, хим. обработка, нагрев… Метрики на отдельных процесса измеряются с разной периодичностью, и разными способами. Где-то автоматически, где-то, вручную, например, лабораторный контроль исходного сырья. Совокупно метрик ~50–60 шт. Длительность процесса составляет 1.5–2 часа.


Задача — получить выходную продукцию с заданными физическими параметрами.


Сложности возникают, когда опускаемся чуть ниже:


  1. Точной аналитической модели тех.процессов нет.
  2. Параметры сырья меняются от загрузки к загрузке.
  3. Поддерживается модель заказного производства, когда параметры выходного продукта должны меняться в соответствии с текущим заказом.
  4. «Эксперименты» по перестройке параметров технологической линии по принципу обратной связи оборачиваются бизнесу слишком дорогой ценой. За 1.5–2 часа полного цикла до выхода продукции будет переведена не одна тонна сырья. Если параметры линии выставлены неправильно — будет брак, заказ надо переделывать.

Необходимо правильно выставлять параметры линии сразу со старта производства заказа и корректировать их по мере тех. процесса для нивелирования возможных флуктуаций в процессе производства.


Что имели на входе:


  1. Описание технологического процесса.
  2. Excel «простыни» с элементами VBA автоматизации, содержащих значения параметров при выпуске того или иного заказа. Разные смены и разные фабрики — немного отличающийся стиль заполнения.

Сложная для обычных средств задача средствами R решилась в 2 шага:


  1. Адаптивный импорт excel данных в структурированное представление.
  2. Применение алгоритма RandomForest для построения прогнозной модели.
  3. Редукция списка параметров исходя из результатов прогонов RandomForest и общих физических соображений по техпроцессу.

Полученная точность прогнозирования параметров выходной продукции в размере 3–5% оказалась вполне достаточной и адекватной нормативам.


Для справедливости необходимо отметить, что это все было выполнено в режиме «proof-of-concept». После демонстрации решаемости «нерешаемой» задачи и чуть более детальной проработки решения акцент сместился в область улучшения процедур измерения технических параметров. Это как раз тот случай, когда оперативное применение R позволило расчистить сознание от вторичных цифровых задач и вернуться к первичным проблемам физического мира.


Технические детали


  1. Весь код составил ~150 строк из которых 30% — комментарии и переносы длинных строк для соблюдения code conventions.
  2. Подключенный явными декларациями набор пакетов: 

library(dplyr)
library(lubridate)
library(ggplot2)
library(tidyr)
library(magrittr)
library(purrr)
library(stringi)
library(stringr)
library(tibble)
library(readxl)
library(iterators)
library(foreach)
library(doParallel)
library(zoo)
library(randomForest)

Case #3: Сводная аналитика и верификация в разношерстной продуктивной среде

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


  1. Есть сотни выгрузок из SAP в формате Excel по иерархическим объектам. Форматы выгрузок ориентированы на визуальное восприятие человеком и крайне неудобны для восприятия машиной.
  2. Есть Excel выгрузки из сторонних систем + данные ручного ввода\оцифровки.
  3. Есть данные в базах Access.

Совокупно может быть несколько сотен тысяч\миллионов записей по всем объектам, подлежащим анализу.


Необходимо:


  1. Проводить выверку данных в рамках отдельного отчета по кастомным многопараметрическим правилам.
  2. Проводить кросс-сверку данных из различных источников данных по кастомным многопараметрическим правилам. Результаты расхождений выдавать аналитикам.
  3. Ежемесячно готовить сводные аналитические отчеты на основе всего этого массива информации. Сотни страниц с различными графическими и табличными представлениями
  4. Предоставить инструменты аналитику для оперативной произвольной манипуляции с данными по заранее неизвестным правилам.

Предполагаемые пути решения до начала PoC на базе R:


  • разработка на SAP (прогнозируемый срок исполнения 5–7 лет, не все требования легко закрываются);
  • разработка на access (прогнозируемый срок исполнения 1–1.5 года, не все требования закрываются);
  • разработка на чем-то еще (прогнозируемый срок исполнения ???).

Да, задача масштабная просто потому что много данных и отчетов, отнюдь не на 2 дня.
Для доказательства реализуемости провели за неделю «proof-of-concept» на базе R.


В рамках PoC охватили:


  1. Импорт excel данных с поддержкой «плавающего» формата данных
  2. Импорт access данных.
  3. Реализацию подмножества проверок (числовых, текстовых, комбинированных).
  4. Генерация графических\табличных представлений.
  5. Генерация html\doc представление с графикой, текстом, таблицами.
  6. Интерфейс аналитика для работы с данными

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


Технические детали PoC


  1. Весь код составил ~500 строк из которых 20% — комментарии и переносы длинных строк для соблюдения code conventions.
  2. Время импорта массивов данных — секунды.
  3. Время исполнения проверок — секунды.
  4. Время генерации выходных отчетов (html\doc) — доли минут.
  5. Подключенный явными декларациями набор пакетов: 
    library(dplyr)
library(lubridate)
library(ggplot2)
library(tidyr)
library(magrittr)
library(purrr)
library(stringi)
library(stringr)
library(tibble)
library(readxl)
library(iterators)
library(foreach)
library(doParallel)
library(zoo)
library(gtable)
library(grid)
library(gridExtra)
library(RColorBrewer)
library(futile.logger)

Заключение

Факты есть факты. Можно в R верить, можно не верить; можно сомневаться в возможностях; можно по сто раз проверять и дожидаться, пока с трибун не возвестят, что действовать надо так… Но те, кто наберутся смелости и терпения и заменят старые подходы по обработке данных на платформу R получат многократную экономию и преимущества здесь и сейчас.


Предыдущий пост: «Применение R для подготовки и передачи «живой» аналитики другим бизнес-подразделениям»

Комментарии (3)

  • 22 ноября 2016 в 18:13

    0

    ↑

    ↓

    Технические детали

    Большую часть подгружаемых пакетов можно вызвать одной строкой
    library(tidyverse)
    Это прекрасный свежий пакет от Hadley/RStudio. Подробнее можно почитать в блоге RStudio, в репозитории github или в документации SO.

  • 22 ноября 2016 в 20:08 (комментарий был изменён)

    0

    ↑

    ↓

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

    • 22 ноября 2016 в 20:41

      0

      ↑

      ↓

      Ну если помнить об этих граблях, можно при необходимости писать полностью, типа stats::filter()

© Habrahabr.ru