Запрягаємо R на службу бізнесу на «1-2-3»

Справжній піст є, фактично, резюме, підіб'є підсумки попередніх «технологічних» публікацій [1, 2, 3, 4, 5] і виникли дискусій і обговорень. Останні показали, що завдань у яких застосування R могло б надати вагому допомогу бізнесу дуже і дуже багато. Однак, навіть у тих випадках, коли R використовується, далеко не завжди для цього застосовуються сучасні можливості R.
Ніша для застосування R в бізнесі відкрита і дуже актуальна як на заході, так і в Росії.
Чому це твердження особливо цікаво для Росії?
1. Йде активний процес імпортозаміщення, контрольований на рівні міністерств і уряду. Багато вважатимуть за краще використовувати з дозволеного списку, ніж придумувати обґрунтування і доводити необхідність придбання закордонного ЗА, нехай і трохи кращого, ніж російські аналоги. А до держкомпаніям увагу на порядок пильніше.
2. На жаль, немає реляцій, що криза закінчилася і починається підйом. Затягнути паски — це так. А значить бюджетів на дорогі іграшки і не дуже-то передбачається. При цьому рішення задач ніхто не скасовує, кількість і амбіційність завдань швидше тільки збільшується.
3. Бізнес цілком справедливо вважає, що якщо вже ІТ не створює конкурентних переваг, то хоча б має допомагати оперативно готувати інформаційне поле для ручного або автоматизованого прийняття рішень. При цьому запити бізнесу часто досить прозаїчні і невибагливі, щоб залучати нобелівських лауреатів для їх вирішення.
Фактично, для впевненого плавання в «цифровому» море бізнесу необхідна лише локальна «зшивання» інформаційного простору і формування інтерактивних вистав для спрощення процесу прийняття рішень в контексті досить обмеженого набору питань і процесів.
У цілому, ситуацію з прийняттям рішень можна описати наступним чином:
  • У будь-якій компанії кожен працівник щодня приймає безліч важливих бізнес-рішень.
  • Час для прийняття рішення невелика (секунди-годинник).
  • Не завжди питання формулюється у чіткій та однозначній формі.
  • Прийняття рішення може вимагати складної математичної обробки даних.
Технологічно цей процес описується ланцюжком «Збір — Процесинг — Моделювання і Аналіз — Візуалізація\вивантаження».
Локальність «зшивання» призводить до того, що використання потужних промислових ETL\BI\BigData рішень виявляється абсолютно невиправданим ні з технічної, ні з економічної точки зору.
Для того, щоб посадити грядку морквини, не треба орати десяток гектарів землі.
З іншого боку, такий контекст є дуже комфортним для екосистеми R і виконується раз. Для бізнесу підхід «1-2-3» можна викласти в наступній картинкою (бізнес любить картинки):
«3 кроки»
При використанні R технологічно майже все одно, які джерела даних та які там формати, наскільки вони чисті, що і як треба намалювати і вивести. Можна практично все. Головне — мати сформульовану бізнес-завдання.
Повертаємося до практичного прикладу
В якості демонстрації застосування вищевказаного підходу звернемося ще раз до теми, згадуваної раніше в пості «Інструменти Data Science як альтернатива класичної інтеграції ІТ систем», а саме, наприклад консолі агронома в рамках однієї з підзадач сучасного напрямку «Прецизійне Землеробство».
Сама по собі підзавдання звучить вельми прозаїчно: «Оптимізувати іригацію полів з урахуванням особливостей вирощуваної культури, фенологічних фаз і кліматичних умов (минуле, теперішнє, прогноз) для підвищення якості врожаю і зниження витрат».
Звичайно, що ІТ-аналітика підсистема є лише однією з підсистем. Повний комплекс охоплює і завдання вибору оптимиальной методики і безпосереднього вимірювання фізичних показників вологості грунту (що саме по собі є непростим) і параметрів навколишнього середовища, автономну роботу датчиків і передачу телеметрії по радіоканалу з урахуванням масштабів полів (одиниці-десятки кілометрів), дешевизна + компактність + робота без зміни батарейки протягом всього сезону, оптимізацію розміщення датчиків і захисту їх від різноманітних впливів, включаючи підвищений інтерес місцевих жителів, а також облік балансу води в рослинах (грубо, поглинання — випаровування). Але всі ці завдання виходять за рамки теми цієї публікації.
Отже, консоль агронома. Все зроблено на R + Shiny + DeployR. Приклад робочої версії консолі наведено на наступному скріншоті:
«Smart Agriculture»
Все виглядає просто і тривіально рівно до тих пір, поки не поринеш у деталі. А саме в деталях і проявляється пропонований підхід локальної зшиванню даних.
1. Немає ніякого глобального сховища з жорсткою моделлю даних, що містить всю-всю-всю інформацію. Навпаки, є набір автономних або напівавтономних підсистем, що містять підмножина інформації у своєму власному вигляді.
2. Оскільки консоль агронома і відображена в ній інформація потрібна тоді, коли є кому дивитися, то сам додаток виступає в якості нескінченного циклу для диспетчера повідомлень. Консоль динамичесая, перевірка необхідності перерахунку проводиться по таймеру, оновлення елементів відбувається автоматично, з використанням реактивних (reactive) елементів платформи Shiny. При цьому автономна операційна аналітика живе на R сервері в незалежному від консолі режимі.
3. Поточна погода. Дані беруться з декількох джерел, включаючи веб джерела (REST API) і дані фактичних сенсорів на полі (log\csv + git). Так як всі датчики на полі економлять батарейки і виходять на зв'язок в своєму власному режимі, дані в консоль надходять в асинхронному режимі. В якості сховища польових даних використовувався репозиторій git.
4. Для оперативного аналізу інтерфейс містить, в тому числі, керуючі елементи відображеними зрізами. Весь перерахунок відбувається за фактом зміни налаштувань.
5. GIS-карта з встановленими датчиками на полі. Багатошарова карта (саме тут в якості підкладки OpenStreet) з накладеним інфраструктурою польових датчиків, і динамічно пересчитываемыми показниками цих датчиків, такими як: поточний статус, поточні показання, час знімання показань. Метаінформація для про датчиках виходить з хмарної системи обліку IoT обладнання. З-за досить складною внутрішньої логічної структури об'єктів IoT платформи для отримання даних про сенсорах необхідно виконати ланцюжок з 3-4 REST API запитів з проміжною обробкою.
6. Табличне подання для виведення подієвої інформації: показання, логи, рекомендації, проблеми, пронозы. Кожен тип виведеної інформації виходить або з окремого джерела підключення, збір, парсинг, передобробка), або є результатом роботи мат. алгоритмів (наприклад, прогнози і рекомендації).
7. Область даних (праворуч) об'єднує в єдину консоль інформацію, отриману і оброблену з десятка різних джерел:
  • Дані про історичних показниках погоди. Використовуються дані польових сенсорів (txt + git) і дані про погоду з відкритих веб-джерел. В силу того, що на безкоштовних акаунтів (після попереднього аналізу декількох веб-джерел) далеко не скрізь є глибока історія, а ідея платити $100-150 в місяць за доступ до погодних даними сільгоспвиробників ніяк не радує, був піднятий окремий процес накопичення історичних веб-даних на основі моніторингу поточних (REST API -> txt + git). І, природно, при конфлікті даних з різних джерел необхідно його вирішувати. В якості одного з основних джерел ми зупинилися на Open Weather Map — OWM
  • Прогнозна частина також викликала ряд запитань. Різні джерела дають різну інформацію з різної гранулярностью. Не всі джерела дають прогноз опадів мм. Якщо дають, то не всі дають погодинну. Можуть видавати агрегати. Їх треба якось зводити.
  • зокрема, OWM при запиті опадів видає 3-х годинний агрегат мм, починаючи з моменту фіксації. Якщо говорити про минуле, то момент фіксації також може бути виданий випадковий. Таким чином, отримуємо довільний часовий ряд з 3-х годинним агрегатами і великою кількістю повторів, за яким необхідно відновити погодинну картину.
  • Дані від сенсорів надходять по різних каналах. Самі датчики «живуть» в асинхронному режимі (екномія батарейок), тому від них поступають в режимі потоку, без можливості примусового опитування. Негарантированность каналів зв'язку (всі в полі, іноді поганий зоні покриття) і різні версії апаратних платформ датчиків призводять до того, що для аналізу необхідно забирати дані зі всіх потенційних сховищ. На даний момент дані з сенсорів надходять в git (структирированный вигляд і логи) і в хмарну платформу управління IoT пристроями.
  • Дані з сенсорів (а на полі їх варто не 2 і не 5) проходять попередню математичну обробку. В силу специфіки вимірювання вологості грунту і неможливість прямих вимірювань (з певним застереженням для ЯМР або радіометричних методів), результат опосередкованих вимірювань сильно залежить від стуктурно властивостей грунту. Необхідно визначити достовірність показань кожного з датчиків, спираючись як на його приватні калібрувальні криві, так і на історичні дані, очікувані показники, дані за здійсненою поливу та інформації від інших датчиків на полі.
Висновок
На заході співтовариство R, а також коло розв'язуваних завдань, експоненціально розвивається. Open-source активно наступає. Для ознайомлення з новинками в частині R можна в якості стартового майданчика використовувати агрегатор R-bloggers. Ось, наприклад, дуже цікавий свіжий бізнес-пост: «Using R to detect fraud at 1 million transactions per second».
У Росії є всі передумови до використання R в завданнях бізнесу, але поки що відносно слабка community. З іншого боку, активна і допитлива аудиторія Хабра є найкращим провідником сучасних ІТ технологій на території нашої країни.
Саме час спробувати вирішити існуючі в ваших компаніях завдання по-новому, з застосуванням нових інструментів, і почати обмінюватися набутим досвідом. Обговорення питань і незрозумілих моментів у відкритих дискусіях цьому тільки посприяє.
p.s. до Речі, тепер семантика пакету
dplyr
доступна і для роботи з Apach Spark. Вийшов пакет
sparkly
, що забезпечує цю прозорість.
Джерело: Хабрахабр

0 коментарів

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