Size: a a a

2019 December 10

AZ

Alexey Zinoviev in Moscow Spark
Pavel Klemenkov
Про пятый пункт я совсем не понял. Ну и пусть каждая трансформация возвращает тебе новый объект. Вычислений-то никто не делает, пока ты action не запустишь. Да и каталист с тангстеном относительно хороши, чтобы тупо данные не гонять
Слушай, Catalyst отнюдь не всесилен, стейджей для ML генерится все равно видимо-невидимо, после кэширования, да, что-то скипится, но для меня все это промежуточное говно, повисающее на storage memory или user memory все равно боль. Операции in-place в горячей памяти для алгоритмов решения оптимизационных задач были бы куда лучше. В целом, Spark не очень подходит для ML
источник

SS

Semyon Sinchenko in Moscow Spark
В python ведь тоже все не в одном месте... Pabdas это отдельный проект, scipy отдельный, scikit learn отдельный, statsmodels с аримой тоже отдельно...
источник

AZ

Alexey Zinoviev in Moscow Spark
Semyon Sinchenko
Про стэкинг не согласен - ничего не мешает делать стэкинг через свои Estimator и Model. Благо все модели сами по себе сериализуются. Там это ни разу не сложнее, чем сделать свой ClassifierMixin в scikit-learn.

Про pandas - тоже не считаю это недостатком - у панд своих проблем куча, их API переусложнен и не прозрачен (особенно с их индексами-реиндексами и тд), ещё и меняется с каждой версией. Их костыли с BlockManager тянутся с давних времён, а уж как они память едят... Ну и наконец есть pyarrow, если очень хочется связать с спарком.

Про DL - есть dl4j-spark, который работает из коробки. Инференс есть в MMLSpark на CNTK. И dl4j и cntk можно использовать как бэкэнд для Keras.

Про онлайн обучение не знаю, но в MMLSpark есть VowpalVabbit... Можно его посмотреть.

Про MLLib - ну просто RDD быстрее. Да и вообще, если быть честным, то в Spark нет такого объекта, как DataFrame - это просто RDD[Row], а DataFrame просто синтаксический сахар.

В общем многие утверждения спорные.
Вам хочется ответить на каждый пункт. Да ничего не мешает, и ручками свой MMLSpark майкрософту не мешает и если у вас отдел из 100 спарководов, тоже ничего не мешает, НО. Обычный юзер спарка, который хочет коробку может и не быть гуру ручной реализации стэкинга, вы допускаете это?
источник

AA

Anton Alekseev in Moscow Spark
Pavel Klemenkov
Пункт 3 тоже спорный, ибо когда мы говорим про статистику, подразумеваем явно не датасеты в терайбайты. Хочешь статистики - сэмплируй считай на драйвере.
В любом случае статистика явно хромает, а правильный семплинг это та еще задача.
источник

AZ

Alexey Zinoviev in Moscow Spark
Semyon Sinchenko
Про стэкинг не согласен - ничего не мешает делать стэкинг через свои Estimator и Model. Благо все модели сами по себе сериализуются. Там это ни разу не сложнее, чем сделать свой ClassifierMixin в scikit-learn.

Про pandas - тоже не считаю это недостатком - у панд своих проблем куча, их API переусложнен и не прозрачен (особенно с их индексами-реиндексами и тд), ещё и меняется с каждой версией. Их костыли с BlockManager тянутся с давних времён, а уж как они память едят... Ну и наконец есть pyarrow, если очень хочется связать с спарком.

Про DL - есть dl4j-spark, который работает из коробки. Инференс есть в MMLSpark на CNTK. И dl4j и cntk можно использовать как бэкэнд для Keras.

Про онлайн обучение не знаю, но в MMLSpark есть VowpalVabbit... Можно его посмотреть.

Про MLLib - ну просто RDD быстрее. Да и вообще, если быть честным, то в Spark нет такого объекта, как DataFrame - это просто RDD[Row], а DataFrame просто синтаксический сахар.

В общем многие утверждения спорные.
Про Dl4j, у вас есть работающий прод на Dl4j и Spark, вы запускали и меряли перформанс? Ну это же просто тихий ужас, а смотрели на планы, а сколько джоб там запускается?
источник

SS

Semyon Sinchenko in Moscow Spark
Но ведь в питоне тоже не покрыть все пункты одной либой!
источник

AZ

Alexey Zinoviev in Moscow Spark
Еще раз, моя статья про то, чего нет в Spark ML. Ваши замечания ценны в части, как пофиксить, если чего-то нет, некоторые из них я хочу добавить в статью. Но тот же MMLSpark знают и пользуют очень небольшое число людей и он родился именно из-за анализа этих недостатков (я просто не нашел статьи Майкрософт на аналогичную тему)
источник

AZ

Alexey Zinoviev in Moscow Spark
Semyon Sinchenko
Но ведь в питоне тоже не покрыть все пункты одной либой!
питон может сгореть в аду со своим дайверсити либ, не?
источник

AZ

Alexey Zinoviev in Moscow Spark
Semyon Sinchenko
Но ведь справедливости ради, в scikit learn тоже нет нормального градиентного бустинга... Все используют расширения.

Если мы говорим о sparkML, то корректно включал сюда все активные проекты, которые совместимы с Estimatir и Model из SparkML
Вот тут, конечно, я схитрил, не спорю
источник

AZ

Alexey Zinoviev in Moscow Spark
Как раз думаю писать дальше, как экосистема пытается решить эти проблемы
источник

DG

Denis Gabaydulin in Moscow Spark
Alexey Zinoviev
А причём тут Ignite ML? А про прод. Ну я видел)) и дебажил.
Ну кажется что вся статья затевалась ради этой фразы )
>I happy to present Apache Ignite ML which close these gaps >mentioned above.
источник

SS

Semyon Sinchenko in Moscow Spark
Alexey Zinoviev
Еще раз, моя статья про то, чего нет в Spark ML. Ваши замечания ценны в части, как пофиксить, если чего-то нет, некоторые из них я хочу добавить в статью. Но тот же MMLSpark знают и пользуют очень небольшое число людей и он родился именно из-за анализа этих недостатков (я просто не нашел статьи Майкрософт на аналогичную тему)
Это просто важный вопрос. Должно ли ВСЕ быть в одной либе? Либо может быть вариант как в питоне, когда есть numpy-экосистема, где все совместимо, но развивается как отдельные проекты.

Иначе может выйти ситуация с переусложненным API, где слишком много всего. Свои +- короче
источник

DG

Denis Gabaydulin in Moscow Spark
Ну одна либа удобнее как минимум потому что там не будет адовых проблем совсместимости. Но идеал недостижим, даже если эту суперлибу пишут в одной компании. Чем больше разрабочиков ее делает, тем больше проблем будет появляться.
Хороший знак для экосистем, это если либы между собой "дружат" (интерфейсы, протоколы, способы интеграции) на базе понятных и открытых стандартов.
источник

SS

Semyon Sinchenko in Moscow Spark
Ну насколько я понимаю, позиция разрабов SparkML именно в том, чтобы создать единый стандарт.
источник

SS

Semyon Sinchenko in Moscow Spark
источник

SS

Semyon Sinchenko in Moscow Spark
источник

SS

Semyon Sinchenko in Moscow Spark
Кажется весь вектор их развития в этом комменте. Тут свои +-, но благо сейчас сторонних пакетов, совместимых с Spark уже хватает...
источник

DZ

Dmitry Zuev in Moscow Spark
Semyon Sinchenko
Про стэкинг не согласен - ничего не мешает делать стэкинг через свои Estimator и Model. Благо все модели сами по себе сериализуются. Там это ни разу не сложнее, чем сделать свой ClassifierMixin в scikit-learn.

Про pandas - тоже не считаю это недостатком - у панд своих проблем куча, их API переусложнен и не прозрачен (особенно с их индексами-реиндексами и тд), ещё и меняется с каждой версией. Их костыли с BlockManager тянутся с давних времён, а уж как они память едят... Ну и наконец есть pyarrow, если очень хочется связать с спарком.

Про DL - есть dl4j-spark, который работает из коробки. Инференс есть в MMLSpark на CNTK. И dl4j и cntk можно использовать как бэкэнд для Keras.

Про онлайн обучение не знаю, но в MMLSpark есть VowpalVabbit... Можно его посмотреть.

Про MLLib - ну просто RDD быстрее. Да и вообще, если быть честным, то в Spark нет такого объекта, как DataFrame - это просто RDD[Row], а DataFrame просто синтаксический сахар.

В общем многие утверждения спорные.
Про DataFrame вы заблуждаетесь: DataFrame это Dataset[Row].
источник

DZ

Dmitry Zuev in Moscow Spark
Semyon Sinchenko
Про стэкинг не согласен - ничего не мешает делать стэкинг через свои Estimator и Model. Благо все модели сами по себе сериализуются. Там это ни разу не сложнее, чем сделать свой ClassifierMixin в scikit-learn.

Про pandas - тоже не считаю это недостатком - у панд своих проблем куча, их API переусложнен и не прозрачен (особенно с их индексами-реиндексами и тд), ещё и меняется с каждой версией. Их костыли с BlockManager тянутся с давних времён, а уж как они память едят... Ну и наконец есть pyarrow, если очень хочется связать с спарком.

Про DL - есть dl4j-spark, который работает из коробки. Инференс есть в MMLSpark на CNTK. И dl4j и cntk можно использовать как бэкэнд для Keras.

Про онлайн обучение не знаю, но в MMLSpark есть VowpalVabbit... Можно его посмотреть.

Про MLLib - ну просто RDD быстрее. Да и вообще, если быть честным, то в Spark нет такого объекта, как DataFrame - это просто RDD[Row], а DataFrame просто синтаксический сахар.

В общем многие утверждения спорные.
А Dataset нормальный имеет кучу оптимизаций
источник

SS

Semyon Sinchenko in Moscow Spark
Dmitry Zuev
Про DataFrame вы заблуждаетесь: DataFrame это Dataset[Row].
Да, это я ошибся)
источник