Ще приклади використання R для вирішення практичних бізнес-задач

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

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.