Python Pandas vs R

[flip_flop]

Ещё совет. Если действительно что-то и учить сейчас, тогда Спарк. Здесь Вы можете взять тот же Питон или Скалу (я на Скале работаю). В последних релизах (1.6 и выше) Спарк поддерживает дейта фреймы (только работайте уже с новой библиотекой). Аналогия тесная. Либо Спарк на R. Нужны сейчас дистрибутивы технологии. Либо работайте на R с водой. В общем, есть что учить.

Насколько я понял, perasperaadastra не соберается быть датологом-аналитиком, скорее это вспомогательная область для основной предметной области - физики, например, или инженерной деятельности. Поэтому критерии могут быть несколько другие.

[tessob]

Объясните мне пожалуйста зачем учить Spark, если петабайта данных нет и не предвидится? Кто вообще в реальной практике работает с этими петабайтами, кроме поисковиков и социальных сетей?

[flip_flop]

Объясните мне пожалуйста зачем учить Spark, если петабайта данных нет и не предвидится? Кто вообще в реальной практике работает с этими петабайтами, кроме поисковиков и социальных сетей?

Вопрос, конечно, интересный. Спросим физика-лирика, он вроде реально с этим на практике работает.

Кстати, интересный доклад был недавно на инженерной конференции о Machine Learning/Deep Learning. Пока что основное практическое применение - в поисковиках, чтобы подсунуть вам (миллионам/миллиардам потребителей) рекламу на основе ваших смутных предпочтений. Концепция спорная, но вот там, наверное, и крутятся пета- екза- байты

[iDesperado]

Объясните мне пожалуйста зачем учить Spark, если петабайта данных нет и не предвидится? Кто вообще в реальной практике работает с этими петабайтами, кроме поисковиков и социальных сетей?

у нас базы по 50-120 гб в оракле, модели делают в sas dataminer, а дальше руками модели переносятся (переписываются) на оракл или hadoop, потому, что процессить продакшен данные на sas было бы невероятно дорого.
сейчас вот смотрю на спарк и вообще не понимаю чем эти дата сайнтологи занимаются. 16 строк кода разбивают датасет на две части, по одной тренеруют модель (random forest) по второй проверяют работу модели и считают кол-во ошибок. 16 строк. с позиции девелопера просто не понятно что за профессию вы тут обсуждаете.

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

Нет, не в том что он ОО. Он вообще-то multi-paradigm.

Здесь я согласен. Безусловно Питон имеет гораздо больше возможностей. Здесь как бы все ясно. Я так понял, что автору топика универсальность не очень нужна, те. упор в основном на аналитику.

Насколько я понял, perasperaadastra не соберается быть датологом-аналитиком, скорее это вспомогательная область для основной предметной области - физики, например, или инженерной деятельности. Поэтому критерии могут быть несколько другие.

Тогда тем более одного R хватит. Не думаю Питон внесёт что-то новое.

Объясните мне пожалуйста зачем учить Spark, если петабайта данных нет и не предвидится? Кто вообще в реальной практике работает с этими петабайтами, кроме поисковиков и социальных сетей?

Вопрос, конечно, интересный. Спросим физика-лирика, он вроде реально с этим на практике работает.

А как тогда работать, скажем, с десятками миллионов строк в таблице? R уже не потянет (памяти не хватит). Да и алгоритмы будут медленно работать. А таблицы с десятками миллионов строк сейчас уже норма. Ведь современные алгоритмы - это же ещё распараллеливание, ведь не каждый метод можно просто с R скопировать.

[tessob]

у нас базы по 50-120 гб в оракле, модели делают в sas dataminer, а дальше руками модели переносятся (переписываются) на оракл или hadoop, потому, что процессить продакшен данные на sas было бы невероятно дорого.

А физических серверов сколько теперь?

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

у нас базы по 50-120 гб в оракле, модели делают в sas dataminer, а дальше руками модели переносятся (переписываются) на оракл или hadoop, потому, что процессить продакшен данные на sas было бы невероятно дорого.
сейчас вот смотрю на спарк и вообще не понимаю чем эти дата сайнтологи занимаются. 16 строк кода разбивают датасет на две части, по одной тренеруют модель (random forest) по второй проверяют работу модели и считают кол-во ошибок. 16 строк. с позиции девелопера просто не понятно что за профессию вы тут обсуждаете.

Правильно, лишний раз доказывает, что для аналитиков работа с кодом и платформами - лишь инструмент. Основное - это умение грамотно ставить задачи, строить правильные модели, уметь их диагностировать (ну, например, стоит ли строить модель на сильно коррелированных между собой данными) и делать разумные бизнес выводы. А ещё неплохо бы понимать, что за каждым из методов стоит (это не к участникам дискуссии). С этим у аналитиков бывают проблемы.
Кстати модель с 16 строками кода выглядит очень подозрительно. Я бы таким результатам не стал бы доверять.
Одна только "чистка" данных (типа аутлайеров, неполных данных) занимает место. А так прогнать "лес" на одной половине данных, а потом "предсказать" другую ... ну это для программеров. Никакой аналитики тут нет.

[iDesperado]

у нас базы по 50-120 гб в оракле, модели делают в sas dataminer, а дальше руками модели переносятся (переписываются) на оракл или hadoop, потому, что процессить продакшен данные на sas было бы невероятно дорого.

А физических серверов сколько теперь?

у нас две системы, одна на одном большом сервере (оракл), который откровенно дохнет от нагрузки и 8 нод на hadoop, на которые уже несколько моделей перенесены и жгучее желание верхов перетащить остальные.

Правильно, лишний раз доказывает, что для аналитиков работа с кодом и платформами - лишь инструмент. Основное - это умение грамотно ставить задачи, строить правильные модели, уметь их диагностировать (ну, например, стоит ли строить модель на сильно коррелированных между собой данными) и делать разумные бизнес выводы. А ещё неплохо бы понимать, что за каждым из методов стоит (это не к участникам дискуссии). С этим у аналитиков бывают проблемы.
Кстати модель с 16 строками кода выглядит очень подозрительно. Я бы таким результатам не стал бы доверять.
Одна только "чистка" данных (типа аутлайеров, неполных данных) занимает место. А так прогнать "лес" на одной половине данных, а потом "предсказать" другую ... ну это для программеров. Никакой аналитики тут нет.

ну да, я тут схалявил в том плане, что для игры со spark почищенные показатели взял, какие берет в продукции модель.
раз пошла такая пьянка, объясните примитивному девелоперу, это нормально в вашем мире разрабатывать модели на каких-то своих тулзах, а потом на пальцах рассказывать программисту как он эту модель построил и месяцами потом гонять тесты, что бы убедиться что в модели и боевой системе одинаково данные чистятся и модель без описок перенесена ?

[tessob]

А как тогда работать, скажем, с десятками миллионов строк в таблице? R уже не потянет (памяти не хватит). Да и алгоритмы будут медленно работать. А таблицы с десятками миллионов строк сейчас уже норма. Ведь современные алгоритмы - это же ещё распараллеливание, ведь не каждый метод можно просто с R скопировать.

А выборку почему нельзя взять, если в R не влазит? При желании можно же просто несколько семплов взять и усреднить. В итоговом продакшене же на таком объеме не R ни питона уже не будет по-любому. Просто я всегда рассматривал Spark исключительно как кластерное решение. Просто, мне кажется, что накладные расходы на одной машине будут совсем неприемлемые. Может я не прав конечно...

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

[tessob]

раз пошла такая пьянка, объясните примитивному девелоперу, это нормально в вашем мире разрабатывать модели на каких-то своих тулзах, а потом на пальцах рассказывать программисту как он эту модель построил

У нас категорически Нет! Но у нас Спарта под боком, не забалуешь.

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

А выборку почему нельзя взять, если в R не влазит? При желании можно же просто несколько семплов взять и усреднить. В итоговом продакшене же на таком объеме не R ни питона уже не будет по-любому. Просто я всегда рассматривал Spark исключительно как кластерное решение. Просто, мне кажется, что накладные расходы на одной машине будут совсем неприемлемые. Может я не прав конечно...

Можно, конечно. Но опять-таки, как загрузить первоначальный объем данных, скажем, в R? Придётся использовать дополнительную софтину, типа Хайфа или Пиза (там выборку делать). Не очень удобно. По-моему, тройку лет назад читал дискуссию, что лучше делать для машинного обучения, работать ли с выборкой или же грузить все данные. Оба подхода имеют свои плюсы и минусы. Очевидный минус выборки - потеря информации. Если, скажем, строится классификатор, да ещё с несколькими категориями, да ещё данные (по классам) разбалансированы, то балансировка может существенно сократить размер финального набора данных. Так что выборка может не сработать. С другой стороны - производительность. Короче, в теории, безусловно, в большинстве случаев можно и не прибегать к распределенным платформам. Но на практике даже и не на очень больших данных нераспределенные алгоритмы (тот же упомянутый выше лес, например) долго работают. А там ещё крос валидейшен надо сделать, параметры найти (а их порой немало, вложенные циклы гоняешь). Короче, ума времени уйдёт. Короче можно, но нужно ли?

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

Модель с 16 строчками кода может быть потому, что ETL процесс чистит данные отдельно и сгружает все в отдельную таблицу (и это правильно),

В продакшене, может и правильно (когда уже все сделано и все о данных и моделе знаешь). Но когда в стадии разработки, откуда ЕТЛ знает, что мне нужно? Откуда я знаю, что мне нужно? Тогда грузишь все данные и сам копаешься в них. Нет 16 строк не тянут.

[iDesperado]

Модель с 16 строчками кода может быть потому, что ETL процесс чистит данные отдельно и сгружает все в отдельную таблицу (и это правильно),

да, features уже из общих данных подготовлены отдельно, но тут у нас специфика в том, что удалось построить data lake где данные относительно стандартизованы и набор features (в смысле правила ETL ) разработанные для одной базы, используются для анализа и в соседней.

Как в анекдоте про сервис машины: подкрутить гайку - $5, знать какую именно гайку подкрутить - $500.

я детально еще не разобрался, но кажется, что у нас это выглядит так: аналитик выясняет, что в данных откровенный мусор, а что значимое, чего не хватает, после чего формирует набор features, который скармливает sas dataminer. что за магия срабатывает в sas я уверен он понятия не имеет, но на выходе модель.
было бы жутко интересно в кратце а как у вас. я в вполне допускаю, что все не так просто, но есть у меня ощущение, что у нас вот аналитики просто в sas выбирают что-типа комбо бокса "random forest" и новички уже никакой математики и что там под капотом sas не знают. вся задача почистить данные верно и выбрать промежуток по времени для тренировочного набора.

P.S. если кому интересно 16 строчек это вот эти, из example https://spark.apache.org/docs/2.0.2/ml- ... classifier" onclick="window.open(this.href);return false; (Random forest classifier)
лишь свои данные подсунул, но пока не разобрался, результат подозрительно великолепный.

[perasperaadastra]

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

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

P.S. если кому интересно 16 строчек это вот эти, из example https://spark.apache.org/docs/2.0.2/ml- ... classifier" onclick="window.open(this.href);return false; (Random forest classifier)
лишь свои данные подсунул, но пока не разобрался, результат подозрительно великолепный.

Можно ещё код сократить, если данные уже считаны в нужном формате (например, паркете или джейсоне). А так все эти "индексеры" - это чтобы начало превратить категорийные переменный в числовые (0,1,3,...). Затем "горячим" (ну очень горячим) энкодером добавить колонок (например, для N фич N-1 колонка). Затем вместе с целевой колонкой и числовыми данными создать вектор, т.е. формат, который и нужен для МЛ (леса, например). Можно ещё добавить один энкодер, чтобы отделить числовые переменные от категорийных по числу значений. Кстати, ограничение в 32 категории осталось (как было в начальных версиях R для леса). Но это все техника, а не аналитика.

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

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

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

[iDesperado]

Можно ещё код сократить, если данные уже считаны в нужном формате (например, паркете или джейсоне). А так все эти "индексеры" - это чтобы начало превратить категорийные переменный в числовые (0,1,3,...). Затем "горячим" (ну очень горячим) энкодером добавить колонок (например, для N фич N-1 колонка). Затем вместе с целевой колонкой и числовыми данными создать вектор, т.е. формат, который и нужен для МЛ (леса, например). Можно ещё добавить один энкодер, чтобы отделить числовые переменные от категорийных по числу значений. Кстати, ограничение в 32 категории осталось (как было в начальных версиях R для леса). Но это все техника, а не аналитика.

в spark 2.1 вроде больше, у меня строковая колонка вроде в 198 категорий превратилась.
а расскажите, как у вас модели попадают в продакшен ? вы как-то можете экспортировать модель и правила ETL, которые вы использовали в анализе в прод ? может вы экспортируете описание модели, а реализуют уже на других тулзах ? как это вообще происходит по нормальному ?

[iDesperado]

ага, т.е. вы и анализируете RStudio тулами и в работу финальную модель запускаете там же. единственно не понял откуда чистые данные под модель берутся. ETL из продукции загружает в DWH, но он наверно все подряд загружает ? под модель как я понимаю еще нужно выдумывать что-то типа "кол-во полосатых покупок дурачка за 6 месяцев", вместо сырых фактов. хотя не столь важно, наверно так же как в sas, хоть мышой можно накликать.
вобщем ясно, когда покупают лицензии не только на десктоп вариант все выглядит несколько иначе

[Сабина]

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

[Сабина]

Да, модель хранится в RStudio.

ETL не просто перебрасывает данные из продакшн в DW, он их ещё по дороге чистит и превращает в features.

Ага и Spark может быть основой тех же ETL например. Или Kafka streaming или AWs Kinesis streaming в наше время.
Не знаю что тут названо "production", скорее всего collected data store

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

У нас сидит команда аналитиков - все что хочешь 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)). Не совсем понятно, зачем Вы все остальные записи выбрасываете. Опять же вопросы про распределения и корреляции (как/зачем). Но это все определяется поставленными задачами. Как я говорил, распределённые технологии могут помочь, но можно работать и без них.
Вы в свободном плавании или на консалтерскую контору работаете? Это я к тому, не ищет ли Ваша контора новых консалтеров. А то я утомился в своей конторе, пора ...