SS
Перепутал)
Size: a a a
2019 December 10
DZ
Но из этой ошибки сразу следует что утверждение про RDD построено на неправильных предпосылках
AZ
XGboost, MMLSpark, даже H2O - все может быть встроено в Pipeline SparkML
В точности, внешними интеграциями закрываются такие вопросы. Но именно Spark ML, а не H2O со Sparkling water
AZ
Я никогда не смотрел, но вот не будет ли там кодогенерации в пункте 5, которая уберет создание лишних структур?
Кодогенерация - штука мощная, но и она не все подряд инлайнит и т.д. Дебажил я эту кодогенерацию. Она для SQL-подобного кода ок, но не для многократкных итераций (которые непонятно когда кончатся и с меняющимися параметрами)
AZ
Anton Alekseev
В любом случае статистика явно хромает, а правильный семплинг это та еще задача.
Вах, я вас плюсую, сэмплинг рандомом - еще не сэмплинг. Кажется сэмплинга по стратам тоже нет.
SS
Но из этой ошибки сразу следует что утверждение про RDD построено на неправильных предпосылках
Я читал статью про AngelML on Spark и там китайцы с бенчмарками утверждают как раз, что RDD быстрее. Но это не главный мой посыл все же, это детали
AZ
Ну кажется что вся статья затевалась ради этой фразы )
>I happy to present Apache Ignite ML which close these gaps >mentioned above.
>I happy to present Apache Ignite ML which close these gaps >mentioned above.
палево, кто-то дочитал до конца)
AZ
Это просто важный вопрос. Должно ли ВСЕ быть в одной либе? Либо может быть вариант как в питоне, когда есть numpy-экосистема, где все совместимо, но развивается как отдельные проекты.
Иначе может выйти ситуация с переусложненным API, где слишком много всего. Свои +- короче
Иначе может выйти ситуация с переусложненным API, где слишком много всего. Свои +- короче
Думаю, что не должно быть, но ансамбли-то не сделать, это фу. Это же даже не настоящие трудные алгоритмы со статей перекатывать, это просто пару рабочих дней
PK
Вах, я вас плюсую, сэмплинг рандомом - еще не сэмплинг. Кажется сэмплинга по стратам тоже нет.
sampleBy есть
SS
Думаю, что не должно быть, но ансамбли-то не сделать, это фу. Это же даже не настоящие трудные алгоритмы со статей перекатывать, это просто пару рабочих дней
Ну в scikit тоже GBM нормальный не осилили...)
AZ
Про DataFrame вы заблуждаетесь: DataFrame это Dataset[Row].
А в Java API все есть Dataset))) ML конечно на DataFrames делается, Dataset (в Scala -смысле нам не нужен)
AZ
Ну в scikit тоже GBM нормальный не осилили...)
А нам бы с вами еще разгромную статью про scikit-learn накатать, но кто судия, кто референсная библиотека, которая все вместит, если не scikit-learn (а и на солнце есть изъяны)
DZ
Я читал статью про AngelML on Spark и там китайцы с бенчмарками утверждают как раз, что RDD быстрее. Но это не главный мой посыл все же, это детали
к AngelML еще бы волгу и ваще секс
AZ
лично меня это расстраивает. Понимаете, Spark это вроде Apache, а по факту вотчина Databricks и Databricks здесь по сути сдерживает работу community (про это мой последний пункт). Этой статьи бы не было, если бы PR в Spark ревьювались бы, а алгоритмы (сделанные в коммьюнити) вмердживались
AZ
sampleBy есть
спасибо, я ее как-то пропустил, буду знать, что такое есть
SS
лично меня это расстраивает. Понимаете, Spark это вроде Apache, а по факту вотчина Databricks и Databricks здесь по сути сдерживает работу community (про это мой последний пункт). Этой статьи бы не было, если бы PR в Spark ревьювались бы, а алгоритмы (сделанные в коммьюнити) вмердживались
Я не знаю, хорошо это или плохо. Это проблема многих проектов. Главное, что есть экосистема (которую не надо компилить руками, лишь добавить пару строк в pom.xml) с хорошей документацией. И ИМХО, но в подобных статьях надо все же это учитывать.
AZ
Я читал статью про AngelML on Spark и там китайцы с бенчмарками утверждают как раз, что RDD быстрее. Но это не главный мой посыл все же, это детали
Ну в целом, для ML ничего лучше голого MapReduce с хорошей упаковокй перед посылкой по сети нет. Дело в том, что трансформации в ML сложнее чем манипуляции SQL деревом и в целом Catalyst мало что там может соптимизировать, подвинуть, данные в колонке слишком плотные (вектор блин в одной колонке, даже на 1000 фич), чтобы делать клевые штуки для SIMD и прочие Tungsten-примочки
DZ
Я не знаю, хорошо это или плохо. Это проблема многих проектов. Главное, что есть экосистема (которую не надо компилить руками, лишь добавить пару строк в pom.xml) с хорошей документацией. И ИМХО, но в подобных статьях надо все же это учитывать.
которую не надо компилить руками, лишь добавить пару строк в pom.xmlпочему мне всегда хочется плакать от такого
PK
Ну в целом, для ML ничего лучше голого MapReduce с хорошей упаковокй перед посылкой по сети нет. Дело в том, что трансформации в ML сложнее чем манипуляции SQL деревом и в целом Catalyst мало что там может соптимизировать, подвинуть, данные в колонке слишком плотные (вектор блин в одной колонке, даже на 1000 фич), чтобы делать клевые штуки для SIMD и прочие Tungsten-примочки
Не согласен. Подавляющее большинство ML алгоритмов - это хождение в цикле по одному и тому же датасету. Накладно его все время писать и считывать с диска.
AZ
Не согласен. Подавляющее большинство ML алгоритмов - это хождение в цикле по одному и тому же датасету. Накладно его все время писать и считывать с диска.
Под MapReduce я имел ввиду алгоритм в памяти