Pull to refresh
-2
0

Добавлю еще способ обращения к R, не только из Python. Пакет plumber помогает быстро создать веб-сервис с REST API.
Из минусов — нет асинхронности. Но недавно наткнулся на пакет promises, при помощи которого в сочетании с future можно писать асинхронные промисы в стиле JS.
Никак руки не дойдут их совместить. Может кто-то уже пробовал? Поделитесь опытом.


Еще интересно, как эффективнее передавать большие таблицы в этом случае. JSON через http или текстовым файлом (csv или feather). Например, в H2O.ai передача данных между клиентом и сервером происходит через текстовый файл (по крайней мере в R API). Есть бенчмарки или каки-то очевидные соображения по этому поводу?

Про scala согласен. R знаю хорошо, spark — нет, поэтому прокомментировать не могу.

P.S. Кто-то снизил мне карму. Похоже из-за этого комментария. Спасибо…
Решая задачи с помощью R, мы поняли, что это язык не для высоконагруженных приложений. В новых задачах мы используем Python и другие технологии, которые с R несовместимы.

Если имеете в виду приложения с большим кол-вом одновременных обращений, то вы правы, R не для этого. Если речь об обработке больших объемов данных, то позволю себе поспорить – R может быть быстрее и эффективнее Python.


Предположу, что вы используете dplyr для обработки данных. Хэдли Викхэм сделал и продолжает делать очень много для развития R. dplyr и другие пакеты из tidyverse (или “hadleyverse”) очень полезны и сильно облегчают жизнь. Негативный эффект – люди думают, что все необходимые пакеты есть в tidyverse. Как результат, я уже несколько раз сталкивался с тем, что люди, имеющие опыт разработки и анализа данных в R, ничего не слышали про пакет data.table.


data.table — один из самых быстрых инструментов обработки данных в оперативной памяти одного сервера. Он написан на native C. Сравнение data.table с dplyr, pandas и spark sql можно посмотреть здесь. Скорость – это только половина преимущества data.table. Вторая половина – эффективное использование памяти.


Паша Стеценко из H2O.ai сейчас разрабатывает data.table для Python на основе пакета data.table для R. Но он сейчас только в стадии альфа. Презентацию можно посмотреть здесь.


Конечно, R и data.table подходят для обработки данных, только если данные влезают в оперативную память одного сервера (и data.table здесь очень эффективен и экономичен). Но это ограничение справедливо и для Python. При бОльших масштабах нужны уже кластерные решения – spark, flint и др. У spark есть api и для R и для Python.

Использую R в связке с PostgreSQL. RPostgreSQL уже несколько лет не обновляется. Вместо него рекомендую RPostgres. К тому же он быстрее.

Будет здорово, если вы чуть понятнее опишете данные от Утконоса. В частности не понятно описание «словарь для коррекции «Сырье/Товар ID» между файлом заказов и данных о складах». Там есть два поля «Диапазон» и «Сырье». В какую сторону надо делать маппинг?

Учитывая сжатые сроки, хотелось бы потратить время на решение бизнес задачи, а не разгадывание ребуса с описанием данных.
Написать elastic net или lasso (L1) с нуля сложнее, чем ridge (L2), потому что там есть часть с коэффициентами по модулю, который не дифференцируется в нуле. Да и незачем писать с нуля, если уже есть glmnet, в которой реализована логистическая и другие регрессии с elastic net, lasso и ridge регуляризацией и k-fold кросс-валидацией.
Знакома проблема черного/белого ящика, когда нужно строить объяснимую для бизнеса модель, хоть и работаю с другой отраслью (ритейл).
Для увеличения точности может помочь стакинг, когда результаты одного или нескольких «белых ящиков» подаются на вход другого «белого ящика». Если модель можно разложить на понятные компоненты. Например, в спросе на товары можно выделить сезонность, веса дней недель, эластичность по цене и т. д.
Не пробовали использовать elastic net регуляризацию для выбора переменных? См. ссылки 1 и 2 ниже.

Я использую не Python, а R, но вроде в scikit-learn должна быть встроена elastic net регуляризация для логистической регрессии.
В любом случае, есть библиотека glmnet (см. ссылку 3), где реализована логистическая регрессия с кросс-валидацией и elastic net регуляризацией. По утверждению авторов, это еще и одна из самых быстрых реализаций (ссылка 4).

Ссылки:
1. en.wikipedia.org/wiki/Elastic_net_regularization
2. web.stanford.edu/~hastie/Papers/B67.2%20(2005)%20301-320%20Zou%20&%20Hastie.pdf
3. glmnet-python.readthedocs.io/en/latest/glmnet_vignette.html
4. web.stanford.edu/~hastie/Papers/glmnet.pdf
Спасибо за подтверждение моего комментария и за развернутый ответ. Прокомментирую ваш ответ:

1. Если руководитель производства из вашего примера в лоб конвертирует прогноз в производственный план, то ему лучше уволиться;) Использование прогноза не подразумевает превращение этого прогноза напрямую в план поставок / производства. Нужно ещё учесть текущий запас, дисперсию прогноза спроса, сроки (поставки / производства / …), стоимость заниженного и завышенного запаса. Делать это можно по-разному, зависит от математической подготовки и софта, имеющегося в распоряжении. Думается мне, что в вашей модели так или иначе косвенным образом используется хоть какой-то прогноз.

2. Да, более детальный прогноз имеет большую дисперсию, но это не значит, что он бесполезен. Возвращаясь к примеру Zara, в их модели управления запасами используется прогноз на уровне неделя-магазин-SKU (SKU на уровне размера артикула, т.е. самом детальном). Для информации, в фэшн ритейле прогноз спроса на этом уровне детализации может быть порядка 0.1 шт или даже 0.01 шт. Сигма там превышает мат. ожидание в несколько раз. Тем не менее используют…
Модель прогноза там, кстати, не особо сложная. Фраза «главное — не запутаться в формулах» относилась не к прогнозу, а к модели оптимизации запасов, в которой этот прогноз используется. Она учитывает не только факторы, которые я перечислил выше, но и некоторые другие. В итоге возникает задача дискретной оптимизации (для решения которой используется оптимизационной движок IBM iLog).

3. Порадовал ваш аргумент, что «прогнозирование на операционном уровне создают мнимое чувство безопасности». Но это же недостаток не прогноза, а того человека, который управляет запасами, основываясь на основе чувств и ощущений. Управлять запасами надо на основе фактов и расчетов.

Перефразирую известную фразу. Вы не любите прогнозы? Да вы просто не умеете их готовить!
Аргументирование в пользу отказа от прогноза на операционном уровне строится на том, что потенциальные клиенты не знают, что у прогноза помимо мат. ожидания есть еще такая характеристика, как дисперсия, и не учитывают других факторов (стоимость завышенного, заниженного запаса, а также операционных расходов). А таких людей, к сожалению, большинство (но не на хабре, надеюсь). Зато люди покупаются на красивые слова про «теорию ограничений». Ваш бизнес, наверное, прёт?)

Специалисты из MIT (да-да, того самого, Массачусетского) в свое время разработали для Zara модель управления запасами магазинов (!) на основе прогноза. Хотя, казалось бы, такой прерывистый, сезонный и непредсказуемый спрос, как в фэшн ритейле, еще поискать надо. Особенно в Zara, где новые продукты запускаются в продажу каждую неделю и могут прожить в магазине меньше месяца.

Описание модели можно найти в открытом доступе. Там есть и описание модели, и корректные расчеты повышения эффективности. Главное — не запутаться в формулах;)

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity