Странно. Сколько ни тестировал, Python уступал R по производительности. Причем существенно.
Что я не так делал?

vikkiv,

букв много, даже все прочитал. Но не нашел ответа на посталенный вопрос.

Меряться пиписьками не собираюсь. Вопрос не в том, сколько школьников изучило Python. А в том, что я не так делал, что у меня R существенно по производительности обгонял Python?
Причем, чем длиннее были вектора, больше фильтраций (медианная, скользящим средним, ql-нормальным), трансформаций (Power, BoxCox), интерполяций (Seasonal Decomposition, Kalman Smoothing), кроссвалидаций и т.п. - тем больше по производительности выигрывал R.

Проблемы с параллельностью решаются средствами PostgreSQL и dblink. То есть, R даже принудительно заставляю работать в один поток, но этих потоков запускаю из PostgreSQL функциями на plr по количеству доступных ядер.


Подозреваю, что есть разница в реализации векторов R и массивов Python.


OpenSource R под Linux без проблем собирается с BLAS и MKL. Но зато MS умудряется на один вызов R через sp_execute_external_script тратить почти 30 мс, тогда как plr в PostgreSQL вызывается меньше, чем 1 мс.

Если вызывать plr или plpython, как функции из PostgreSQL, используя параметры-массивы и для исходных данных, и для результатов, то ни pandas ни dataframe просто не нужны. И быстре получается, чем тащить данные из БД средствами R или Python.

Вы не заметили, что сами себе противоречите? Если задачу можно решать в несколько потоков, то совсем не обязательно одним вызовом скармливать ей весь объем данных сразу. Вам просто сложно осознать в голове концепцию того, что массу черновой работы по трансформации и очистке данных можно оставить на стороне SQL, отдавая plr/plpython только те задачи, которые они решают лучше, чем plpgsql. На практике, функции plr/plpython получаются довольно небольшими и простым. Ведь сам алгоритм реализуется в plpgsql. Бессмысленно кормить ту же ARIMA временной серией длиней нескольких сотен элементов. А вот подготовить временную серию длиной не более, чем в 300 элементов из миллиона - с этой задачей справляется plpgsql, задействуя оконные и/или агрегативные функции на R только в некоторые моменты.

Необходимое количество потоков не сложно реализовать через dblink средствами того же PostgreSQL. Это не менее эффективно, чем многопоточность средствами R или Python и позоволяет без особых проблем разпределять задачи не только между локальными ядрами, но и между серверами.

Что касается Spark, я его тоже рассматривал. Но для нашей задачи он оказался мало пригоден. Суть в том, что имея на входе свыше миллиарда событий, ML для тренинга достаются два миллиона разных по составу временных серий. Поэтому затраты на коммуникацию со Spark оказались существенно выше, чем передача в памяти массивов из PostgreSQL в R. Ведь и исходные данные и результаты все равно надо хранить в SQL БД.

P.S. plpython ограничений, по сравнению python почти не имеет. Точнее, это просто использование pyhton на прямую через so. Объективные ограничения возникают только из того, что консоли у такого python нет по определению.

Опять золотой молоток ?

Когда передо мной встала реальная задача, в которой потребовался ML я знал Python, но не знал R.
Но это мне совершенно не помешало за несколько дней изучить R в достаточном для НИОКР объеме.
Когда же я оценил производительность решений на R и Python, то оценил эффективность работы с векторами и матрицами в R и для этого конкретного проекта был выбран R.
На этом же проекты возникли проблемы с производительностью связки MS SQL+R Service. Зная PostgreSQL весьма поверхностно, я не поленился потратить несколько дней на его изучение и сравнить в данном применении связку PostgreSQL+R (plr). Последний выиграл с большим отрывом.

Если на следующем проекте на фазе НИОКР окажется эффективней Python - буду использовать его. Если вдруг окажется эффективней Julia - разберусь и с ней. Если эффективней окажется Spark или ClickHours - буду использовать их.
Никакого желания ограничивать себя "золотым молотком" не испытываю, чего и Вам желаю.

Я всегда искренне считал, что на этапе НИКОР просто необходимо рассматривать альтернативные варианты решения и сравнивать их. А не пытаться подогнать задачи проекта под уже освоенный "золотой молоток".

Александр Бердышев,

так только первую версию в продуктив в декабре запустили. Даже еще не открыли вакансии для ТП.
Сам я собираюсь только помочь в организации поддержки. Все результаты НИОКР обсуждались с руководством, риски учитывались и выбор технологий был санкционирован. Так что, строго говоря, это уже давно не моя головная боль.

Для R специалист уже есть. River Logic + Gurobi тоже. Для PostgreSQL нужно нанимать. Но там тупая арифметика сработала. Попытка решить задачу на MS SQL требовала обязательно Enterprise из-за ограничения на 4 ядра у R Service у Standard. А это свыше 7 тыс. вечнозеленых ежемесячно за 32 ядра, которые еще планируется нарастить до 64-х (на двух серверах). За такие деньги нанять специалиста на поддержку более чем реально.

Эти два предложения противоречат друг другу. Тимлид не имеет никакого права выбирать технологии. Он может только произвести прототипирование и предоставить руководству его результаты.

Тот же PostgreSQL у нас санкционировался на уровне совета директоров. Даже IT директор сам не решился включить его в инфраструктуру.

Как писал уже выше, сработала финансовая сторона, а так же давление со стороны госорганов на импортозамещение. Все же предприятие стратегического значения.
С R, как я уже писал выше, проблем не было, так как он уже использовался в инфраструктуре для финансовой дирекции.

А это то при чем? dblink родной и штатный компонент PostgreSQL. Его то зачем санкционировать? А эксперименты показали, что многопоточность все равно надо управляемым делать. Чтобы не оказалось, что последней было запущенно обучение модели, которое длится час, тогда как остальные, параллельные ей завершились за 5 минут.


И какого размера они могут быть, для того, чтобы был смысл скармливать их той же ARIMA? )))


"Чукча не читатель, чукча писатель?" (с)
Он уже выиграл у альтернатив. 4ТБ БД, свыше миллиарда атомарных событий на входе, фильтрация и трансформация производится за 30 минут. Прогнозирование по выбранным кластеризацией моделям двух миллионов временных серий - за 4 часа. Кластеризация временных серий кроссвалидацией при подборе моделей - за 15 часов. На данный момент второй сервер не запущен, а первый ограничен 24 ядрами. То есть, прогнозируется не менее, чем двукратное сокращение времени на прогнозирование и кластеризацию.
Хотя в целевые показатели (8 часов на прогнозирование и 24 часа на кластеризацию) мы и так вписываемся.


И в этом, как выяснилось, его недостаток.
1. В него надо данные загрузить, тогда как они у меня так и остаются в одной БД
2. Порубить тоже надо с умом, чтобы равномерно грузить узлы, а не долго ждать, пока последняя задача закончится на последнем узле.

Сорри. Только что дошло, что Вы обыкновенный тролль. Это же надо быть полным дебилом, что задавать такой вопрос без целей троллинга.

H5N1,


Ложь. И то, и другое выполняется в среде PostgreSQL. Внешние языки подключаются к PostgreSQL через so и выполняются в его среде.


Ложь. Обмен данныеми происходит через параметры. В крайнем случае - через SPI (Server Programming Interface).


Ложь, так как трансформация данных в памяти на порядок менее ресурсоемка, чем пересылка этих же данных через JDBC.


Ложь. Средств для этого более чем достаточно, начиная с примитивных Crunchy Proxy, Pgpool2 с Kubernetes и т.п. и заканчивая готовыми решения для бизнес аналитики, как CitusDB.


Ложь. Даже если не нравится cstore, то есть тот же CitusDB.


Ложь, так как TOAST так же и компрессиия, а если мы храним данные в массивах, то они точно будут попадать под сжатие TOAST, если специально с этим не бороться.


Ложь, так как в БД в основной своей массе массивы четырехбайтовых real, каждый элемент которых при преобразовании в текст станет занимать в два раза болььше места.

Прошу прощения, но зачем Вы нагло лжете с умным видом?

Днем да. Но это мне даже не интересно, так как взяв из них прогноз на следующие 8 недель я больше к ним не обращаюсь.

Но модели надо, во-первых, обучать/дообучать каждую ночь, во-вторых, надо кластеризовать вектора, заново выбирая модель кроссвалидацией каждую неделю.
Больше всего волнует распределение по вычислительным узлам как раз обучаемых моделей.

На всякий случай, чтобы не быть голословным, приведу пример на одной из табличек.



Row Count Estimate: 1 866 021
Disk Space: 2,2G
Rel Size: 771M





Разница в 18 раз. Устроит?

Во-первых, решение на PostgreSQL не надо было писать. Оно есть.
Во-вторых, если PostgreSQL порождает под каждое соединение свой отдельный процесс (fork) и падение интерпретатора приведет к падению только этого процесса, то MS SQL монолитен, и там есть риск падения всего сервера.

Уверен, что в MS не дураки сидят, и, похоже, сделали такую архитектуру вызова внешних скриптов именно для их изоляции от Database Engine.

Критик,

не тупите. Явно же написано 5434 USD/ year за 2 ядра. Посчитайте для 32 и 64 уже сами.

Поясните Ваш метод расчета рентабельности, пожалуйста.

Обычно, считают сначала сокращение затрат, а уже потом сравнивают их со стоимостью разработки.
Например, в моем случае, уже подтвержденные 5% сокращения затрат на логистику есть 10 миллиардов рублей в год. При том, что бюджет еще 100 миллионов не превысил. То есть достигнутая рентабельность 9900%

H5N1,

потому что незачем лгать публично. Это все равно выясниться, так как легко проверяемо.
Или Вы просто тролль, который несет пургу о том, чего даже не знает?

Откуда эти фантастические 9900% взяты ?
Вы местный клоун или считать не умеете?
Если при бюжете проекта в 100 млн. затраты сократились на 10 млрд, то какая рентабельность проекта?


Этот вопрос в сфере деятельности дирекции по логистике. Я даже не вникал в те документы, которые они предоставили на совет директоров. Только удивился, что так мало, но потом уже разобрались, что ряд диспетчеров саботировали рекомендации по адресации из модели, адресуя вагоны по своему личному разумению, как это делали предыдущие 20 лет. Но это уже отдельная история.


Точно клоун )))
Да, научились в Excel оптимизировать адресацию вагонов )))
Причем 20 лет не могли это сделать, а как только систему внедрили вдруг сумели )))


Естественно. Вы же как-то считали рентабельность только исходя из бюджета проекта, не учитывая сокращения затрат ))))