Python Pandas vs R

[Физик-Лирик]

У нас сидит команда аналитиков - все что хочешь R, Питон, you name it.
Они сильно зависят от девелоперов, которые поддерживают data collection pipeline. Мне всегда было интересно понять насколько таким аналитикам важно понимать как работает spark, tensorflow etc ?

В принципе, не нужно. Это нужно дейта инженерам. Скорее они поддерживают поток данных нежели девелоперы (хотя смотря кого как называть). Аналитики (дейта сайнтисты) разрабатывают модели. Им нужно понимать методики. Понимание платформы - хорошо, но глубина необязательна. Разделение труда, короче.

[tessob]

Можно, конечно...

Мне тогда даже интересно как выглядит ваш рабочий процесс. Просто, мне не совсем понятно зачем нужно в R одновременно иметь все записи постоянно. Я, как правило, работаю у клиента on-site и из благ цивилизации у меня там только тачка, ноут (i7 + 16Gb) и чумадан. Соответственно, когда я получаю данные мне из всех n-миллионов записей нужно взглянуть только на 3-5 тысяч. Этого мне достаточно, чтоб определить состав данных, взаимную корреляцию, типы данных, распределения, попробовать разные алгоритмы и т.д.. После этого я сажусь и отдельно пишу все преобразования для данных в отдельном jar-нике. В результате получаю новую инкарнацию данных (new_.csv), к которым уже можно применять модели не беспокоясь о чистоте и пр. Потом менее десятка раз прогоняю модель на всех данных и заталкиваю результат в продакшн. Если данных реально много и ноутбука не хватает, то использую облако.

У меня как-то так обычно. Извиняюсь, если сумбурно.

[tessob]

О! Я тут вспомнил, как-то приходили чуваки, которые обещали, что их продукт сможет взять данные производства и выдать осмысленные рекомендации по решению проблем в автоматическом режиме! Это случайно не САСовцы были?

Я, естественно, не знаю, кто к Вам приходил, но сейчас все консальтеры этим и занимаются. Хлебом их не корми, дай за триста баков в час рекомендаций настрогать. Хоть в автоматическом, хоть в ручном. За дополнительные сто баков в час могут и Песнь сложить. Главное плати.

О! Я смотрю Вы для себя определились с тем, "Чем predictive analytics принципиально отличается machine learning".

[tessob]

Разделение труда - вредно. Я никому не доверю чистить мою дату

Полностью согласен! А то как в анекдоте получается: "Идут два врача по больнице, один знает куда ставить клизму, а другой как".

[Физик-Лирик]

Разделение труда - вредно. Я никому не доверю чистить мою дату

Полностью согласен! А то как в анекдоте получается: "Идут два врача по больнице, один знает куда ставить клизму, а другой как".

Чистить данные - безусловно, задача аналитика (я на самом деле дейта сайнтиста имею в виду, но буду продолжать использовать термин аналитик). По крайней мере, на этапе построения модели. Однако, сами данные из "базы" обеспечиваются дейта инженером. Аналитик работает с данными и строит модель. В продакшене в принципе вся чистка может быть произведена на этапе ЕТЛ, когда как бы "всё ясно".

Мне тогда даже интересно как выглядит ваш рабочий процесс. Просто, мне не совсем понятно зачем нужно в R одновременно иметь все записи постоянно. Я, как правило, работаю у клиента on-site и из благ цивилизации у меня там только тачка, ноут (i7 + 16Gb) и чумадан. Соответственно, когда я получаю данные мне из всех n-миллионов записей нужно взглянуть только на 3-5 тысяч. Этого мне достаточно, чтоб определить состав данных, взаимную корреляцию, типы данных, распределения, попробовать разные алгоритмы и т.д.

Скорее, это от задач зависит. Если из 10 миллионов записей Вы вытягиваете только несколько тысяч, то статистическая ошибка уже немалая, скажем, если нужно определить среднее или пропорции (исключительно в качестве примера). Все-таки она убивает медленно с увеличением размера выборки (1/sqrt(n)). Не совсем понятно, зачем Вы все остальные записи выбрасываете. Опять же вопросы про распределения и корреляции (как/зачем). Но это все определяется поставленными задачами. Как я говорил, распределённые технологии могут помочь, но можно работать и без них.
Вы в свободном плавании или на консалтерскую контору работаете? Это я к тому, не ищет ли Ваша контора новых консалтеров. А то я утомился в своей конторе, пора ...

[perasperaadastra]

Извините за оффтоп, просто тут возник один вопрос по R... Как правильно взять индексы тех данных, у которых в колонке Description содержится "Metro"? Если бы было только "Metro", то можно через which(df$Description=="Metro"). Но что если в строке содержится "Blah Metro Blah"? Правильно ли я понимаю, что grep("Metro", df$Description) мой друг? Или есть что-нибудь получше?

[tessob]

Скорее, это от задач зависит. Если из 10 миллионов записей Вы вытягиваете только несколько тысяч, то статистическая ошибка уже немалая, скажем, если нужно определить среднее или пропорции (исключительно в качестве примера). Все-таки она убивает медленно с увеличением размера выборки (1/sqrt(n)). Не совсем понятно, зачем Вы все остальные записи выбрасываете. Опять же вопросы про распределения и корреляции (как/зачем). Но это все определяется поставленными задачами. Как я говорил, распределённые технологии могут помочь, но можно работать и без них.

Я в курсе про статистическую ошибку. Если принимать во внимание генеральную совокупность, то это просто катастрофа наверное, но приходится работать с тем, что есть. И данные я не выбрасываю. Я просто до того момента пока не решу что именно я собираюсь сделать использую свои 3-5 тысяч, а когда готовлю продуктивную модель, разумеется, использую все 100% данных.

Про распределения и корреляции можно долго. С корреляцией чуть проще, если она очень близка к +/-1, то достаточно только одной из переменных. Попробуйте визуально представить распределение точек в трехмерном пространстве, если по двум осям они коррелируют 0,97. Такие мелочи иногда прилично искажают модели. С распределениями все веселее и менее однозначно. Если признаки распределены равномерно, то можно просто брать и не думать. Но если появляются горбы... Иногда такие умилительные картины появляются на гистограммах с финансовой отчетностью, в которой сидят бухгалтерские приписки. В общем, если горб один и ровный, то снайпер честно пытался попасть в цель. Если горбов больше, или явная асимметрия, то снайпер явно чудил. Если сравнить распределения по разным временным интервалам, то можно даже понять когда он начал чудить и посчитать на сколько примерно он начудил.

Вы в свободном плавании или на консалтерскую контору работаете? Это я к тому, не ищет ли Ваша контора новых консалтеров. А то я утомился в своей конторе, пора ...

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

[Физик-Лирик]

Извините за оффтоп, просто тут возник один вопрос по R... Как правильно взять индексы тех данных, у которых в колонке Description содержится "Metro"? Если бы было только "Metro", то можно через which(df$Description=="Metro"). Но что если в строке содержится "Blah Metro Blah"? Правильно ли я понимаю, что grep("Metro", df$Description) мой друг? Или есть что-нибудь получше?

Думаю лучше использовать gregexpr

[Физик-Лирик]

Про распределения и корреляции можно долго. С корреляцией чуть проще, если она очень близка к +/-1, то достаточно только одной из переменных. Попробуйте визуально представить распределение точек в трехмерном пространстве, если по двум осям они коррелируют 0,97. Такие мелочи иногда прилично искажают модели. С распределениями все веселее и менее однозначно. Если признаки распределены равномерно, то можно просто брать и не думать. Но если появляются горбы... Иногда такие умилительные картины появляются на гистограммах с финансовой отчетностью, в которой сидят бухгалтерские приписки. В общем, если горб один и ровный, то снайпер честно пытался попасть в цель. Если горбов больше, или явная асимметрия, то снайпер явно чудил. Если сравнить распределения по разным временным интервалам, то можно даже понять когда он начал чудить и посчитать на сколько примерно он начудил.

На самом деле, корреляция переменных не является проблемой для машинного обучения. Если интересно, можно обсудить. Если вкратце, то многие методы "проглатывают" их без проблем. Проблемы могут возникнуть в линейных методах, но они решаются регуляризацией (лассо, ридж регрессия например). Я бы сказал, основная проблема в интерпретации результатов. Например, как ведут себя p-values коэффициентов линейной регрессии, если есть две переменные с высокой корреляцией, но каждая переменная является "важной" для объяснения целевой функции.

Строить матрицу ковариации ... а если есть тысяча переменных многие из которых категорийные. Не уверен. Гистограммы для тысячи переменных? Геморно всё это.

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

Интересные задачи. Мне все интересно, хотя моя область явно иная. Люблю учить новое.
Просто скучно стало в своей конторе. Масштаб уже не тот.

[Сабина]

Разделение труда - вредно. Я никому не доверю чистить мою дату

Недавно читала статью с названием Engineers shouldn't write ETL, полностью согласна.

И кто в данной ситуации есть engineers ? Аналитики или .. ?

[Сабина]

Разделение труда - вредно. Я никому не доверю чистить мою дату

Полностью согласен! А то как в анекдоте получается: "Идут два врача по больнице, один знает куда ставить клизму, а другой как".

С постановщиками клизм такое может и пройдет, а вот с heart surgery наврядли. Хирург, пытающийся одновременно делать пациенту анастезию, просто непрофессионален увы

[perasperaadastra]

Извините за оффтоп, просто тут возник один вопрос по R... Как правильно взять индексы тех данных, у которых в колонке Description содержится "Metro"? Если бы было только "Metro", то можно через which(df$Description=="Metro"). Но что если в строке содержится "Blah Metro Blah"? Правильно ли я понимаю, что grep("Metro", df$Description) мой друг? Или есть что-нибудь получше?

Думаю лучше использовать gregexpr

Спасибо, попробую.

[perasperaadastra]

>Буду там у них девочка подай-принеси.

Хуже. Будут отпускать сексистские шуточки. У французов с этим весьма вольно. Сам наблюдал у стажеров.

[Сабина]

Разделение труда - вредно. Я никому не доверю чистить мою дату

Недавно читала статью с названием Engineers shouldn't write ETL, полностью согласна.

И кто в данной ситуации есть engineers ? Аналитики или .. ?

Нет, data engineers, не аналитики.

Смысл в том, что написание ETL - это грязная, но важная работа. Если ETL пишут люди, которые не строят потом модели, то оно будет написано намного эффективнее, чем если писать будет аналитик, но! рано или поздно с ETL произойдёт одно из двух: или инженеры заскучают и уйдут, или они не уйдут, но значит они плохие инженеры. И поломают процесс, а аналитики даже знать не будут.

Короче, скучную работу должен делать тот, кто понимает, зачем она ему нужна, и чтобы иметь полный контроль на процессор. Я лично на работе control freak, и никому не верю. Все сама-сама. Да, менее эффективно и вообще медленно, зато я точно знаю что делаю.

Но ведь ест места где "менее эффективно и вообще медленно" - это просто смерть бизнеса

[tessob]

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

У меня уже был похожий "спор" с приятелем. Ту как, если слесаря выпьют, то идут настраивать карбюратор... В общем, мы взяли линейную функцию, потом рандомом добавили еще один Х, сильно коррелирующий с первым. Потестили разные алгоритмы. Поняли, что это не спортивно и добавили еще измерений и еще шума. Потестили еще и производительность. В итоге оба пришли к выводу, что стоит в процессе подготовки данных выкидывать лишний мусор из модели.