Comments 21
Да, Spark очень радует тем, что постепенно перетягивает народ с других платформ на Scala. Сколько же, если не секрет, занял процесс обучения и перехода к продуктивной разработке на Scala для команды, где изначально этот язык никто не знал?
+1
Нам очень помогли курсы по Scala на coursera + книги по Spark, которые опубликованы на O'Reilly.
Тестовый переход занял 2 месяца, на production переходили дольше, т.к. до версии Spark 1.1.1 все было плохо.
Сейчас переписано 90% функционала. Написано около 15 000 строк кода на Scala. Команда три человека.
Тестовый переход занял 2 месяца, на production переходили дольше, т.к. до версии Spark 1.1.1 все было плохо.
Сейчас переписано 90% функционала. Написано около 15 000 строк кода на Scala. Команда три человека.
+1
А был у кого-нибудь в команде опыт программирования на функциональных языках со статической типизацией? Hashell, OCaml, SML, F#
После Haskell и C++ я начал программировать на Scala за несколько дней, при том что с JVM-языками был мало знаком.
После Haskell и C++ я начал программировать на Scala за несколько дней, при том что с JVM-языками был мало знаком.
0
UFO just landed and posted this here
У нас очень специфический ML, пишем сами, хотя некоторые методы MLlib используем. Из внешних библиотек я планировал протестировать распределенный R. Python или Vowpal Wabbit использовать не хочется по причине возвращению к зоопарку технологий, как было раньше, это очень хорошо для экспериментов, но плохо для production
0
А как обстоят дела у команды с познанием внутренностей JVM и Scala компиляцией? Насколько я помню, поведении JMM описано для Java, есть ли такое же для Scala?
0
Для нас нет никакой необходимости познавать внутренности Scala, внутренности Spark для нас более актуальны, т.к. бывает нужно оптимизировать саму реализацию алгорима. А это больше не сама Scala, а Spark!
0
Судя по очень краткому ответу в рассылке scala-user@ поведение scala совпадает с описанным в JMM.
0
Очень интересно услышать что-то на тему Clojure vs Scala для Bigdata. Особенно у кого есть опыт
+2
Очень интересная статья, спасибо!
А было что-то из Python стека (IPython + Pandas + Sklearn), чего совсем не хватало перехода на Scala? Например, DF from pandas же драматически, вроде, отличается от RDD?
А было что-то из Python стека (IPython + Pandas + Sklearn), чего совсем не хватало перехода на Scala? Например, DF from pandas же драматически, вроде, отличается от RDD?
0
Мне очень не хватало графиков в ipython интерфейсах. DF особо не пользуюсь, все-таки case классы и функциональный подход тоже дают похожий эффект, но конечно не такой как Pandas
0
Очень понравился Zeppelin. Вы его пробовали? Если да, чем не угодил?
0
Я очень много работал с Zeppelin, сейчас я могу сказать, что не понимаю, почему проект попал под крыло Apache.
Недостатки следуюшие:
Недостатки следуюшие:
- очень неудобно строить графики, если вы посмотрите в статье, то увидите, что они намного гибче, можно использовать или R или HighCharts. Не нужно использовать SQL
- когда вы пишите код через pipe, т.е. добавляете операторы через ".", в Zeppelin нужно ставить ее в конце предыдущей строки, а не в начале. Выглядит ужасно
- ISpark — это ipyhton плагин, он очень легковесный и простой, Zeppelin — это «дирижабль кода», заново изобретенный велосипед. Ipython намного лучше
- В Zeppelin одно ядро, когда у вас много пользователей и что-то пошло не так, то перезапуск ядра убьет блокноты других пользователей, в ipython на каждый блокнот пользователя запускается отдельное ядро.
0
Я очень много работал с Zeppelin, сейчас я могу сказать, что не понимаю, почему проект попал под крыло Apache.
Недостатки следующие:
Недостатки следующие:
- очень неудобно строить графики, если вы посмотрите в статье, то увидите, что они намного гибче, можно использовать или R или HighCharts. Не нужно использовать SQL
- когда вы пишите код через pipe, т.е. добавляете операторы через ".", в Zeppelin нужно ставить ее в конце предыдущей строки, а не в начале. Выглядит ужасно
- ISpark — это ipyhton плагин, он очень легковесный и простой, Zeppelin — это «дирижабль кода», заново изобретенный велосипед. Ipython намного лучше
- В Zeppelin одно ядро, когда у вас много пользователей и что-то пошло не так, то перезапуск ядра убьет блокноты других пользователей, в ipython на каждый блокнот пользователя запускается отдельное ядро.
0
Я не до конца понял, делаете ли вы какое-либо предположение о причинно-следственной связи на основании корреляции (или MIC)? Или наличие корреляции само по себе является целью ваших поисков? И можно ли полагаться на то, что такая корреляция сохранится в долгосрочном периоде? Все-таки бизнес будет принимать решения на основе ваших выводов.
0
Sign up to leave a comment.
Анализ данных на Scala. Считаем корреляцию 21-го века