С момента прошлой публикации пришлось примеряться к ряду различных задач, связанных тем или иным образом с обработкой данных. Задачи совершенно разные, но во всех случаях инструменты 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 для подготовки и передачи «живой» аналитики другим бизнес-подразделениям»

ссылка на оригинал статьи https://habrahabr.ru/post/315870/