Комментарии 14
Код на Java, но все равно очень полезно
Как будто в этом что-то плохое
Не очень понял чем Вам R не угодил? Откуда такая брезгливость?
Проблема R в том, что к продакшену он отношения не имеет, с точки зрения инженера это какой-то неявный вырвиглазный DSL, 95% функционала которого уже давно перенесено в библиотеки в Python. И в большинстве случаев боевая система будет именно на Python, поэтому R там делать особо нечего. Единственная ниша — крайне редкие экзотические модели, которые до сих пор не перенесли.
А как же такое?
И кстати есть мнение коллег по цеху что экосистема R в enterprise задачах бизнеса очень даже работоспособна. С позволения автора привожу ссылки на его статьи (далеко не все статьи) на хабре по этой теме:
RStudio Connect — «фейслифтинг» Shiny для корпоративного применения
Цифровая экономика и экосистема R
А вы уже применяете R в бизнесе?
Еще примеры использования R для решения практических бизнес-задач
Применение R для подготовки и передачи «живой» аналитики другим бизнес-подразделениям
Запрягаем R на службу бизнесу на «1-2-3»
Артем, со всей очевидностью, это утверждение не имеет железобетонной аргументации. Будучи автором упомянутых статей уточню несколько деталей, чтобы внести ясность:
- Не знаю, какие именно промышленные языки подразумеваются и при чем они в контексте конкретных задач. В целом, у нас в команде используются C++, Erlang, Go, Java, JS, Python, R. Опыт успешного использования измеряется десятками лет. Но в тегах про R упоминаются только задачи для R, что логично.
- Промышленные языки (C++, Java) хороши для разработки фундаментального или коробочного ПО. Для бизнес-задач, которые локальны, изменчивы (контекст постоянно "плывет") и связаны с анализом всевозможных "грязных" данных R и Python подходят оптимально. Интересная публикация, если что: What are the Most Disliked Programming Languages?. Если речь идёт ещё и о создании различных АРМ-ов для обычных бизнес-пользователей, то тут Python-у приходится не очень сладко.
- В целом, в бизнес сегменте основным трендом является как раз наличие множества различных частных задач. В этих задачах нет стройной структуры, присущей как промышленной разработке, так и академической среде. Но 80% таких задачек и являются отображением реального бизнеса на цифровую матрицу.
EARL 2017 явно это демонстрирует. - Большие данные не всегда являются свидетельством "белой стороны". Во многих случаях они возникают из-за непонимания сути задач, которые нужно решать, поэтому пытаются собирать всё и вся на всякий случай. Однако, классическая методика проведения эксперимента (физика, химия, биология, ...) подразумевает наличие теории, которая проверяется этим экспериментом. Из теории ясно вытекает, что нужно измерять, как много измерений может потребоваться, какие диапазоны надо проверять, что отсекать. Сам по себе абстрактный эксперимент, без теории, имеет нулевую пользу. Есть хорошее высказывание, что академику Павлову для своей теории не требовалось несколько миллионов собак, ему хватило сорока. Но если действительно требуется собирать и обрабатывать петабайты, то и для этого этого тоже есть различные инструменты.
Что касается Python, то это прекрасный язык. Но он:
- отнюдь не универсален;
- не совсем промышленный. Элементарная попытка задеплоить интегрированное в корпоративный ландшафт python решение на версии, старше той, которая есть в дистрибутивах *nix (в enterprise это обычно RHEL) в условиях полной изоляции от интернета и ограниченном наборе инструментов, в т.ч. запрещено использование докера (обычная ситуация в enterprise сегменте, обусловленная политикой безопасности) требует наличие нескольких бубнов и хотя бы одного шамана. Как пример, в Go можно притащить один exe и не иметь головной боли.
Лог регрессию или дерево решение конвертирую в sql запрос и ставлю на продуктив в БД.
модели на кластер строю и запускаю с помощью sparklyR
problems?
“Без data engineer-а ценность модели аналитика стремится к нулю” — интервью с дата инженером Николаем Марковым