Pull to refresh

Comments 21

Да, Spark очень радует тем, что постепенно перетягивает народ с других платформ на Scala. Сколько же, если не секрет, занял процесс обучения и перехода к продуктивной разработке на Scala для команды, где изначально этот язык никто не знал?
Нам очень помогли курсы по Scala на coursera + книги по Spark, которые опубликованы на O'Reilly.
Тестовый переход занял 2 месяца, на production переходили дольше, т.к. до версии Spark 1.1.1 все было плохо.
Сейчас переписано 90% функционала. Написано около 15 000 строк кода на Scala. Команда три человека.
А был у кого-нибудь в команде опыт программирования на функциональных языках со статической типизацией? Hashell, OCaml, SML, F#
После Haskell и C++ я начал программировать на Scala за несколько дней, при том что с JVM-языками был мало знаком.
Со статической типизацией — нет.
UFO just landed and posted this here
У нас очень специфический ML, пишем сами, хотя некоторые методы MLlib используем. Из внешних библиотек я планировал протестировать распределенный R. Python или Vowpal Wabbit использовать не хочется по причине возвращению к зоопарку технологий, как было раньше, это очень хорошо для экспериментов, но плохо для production
UFO just landed and posted this here
До streaming пока руки не дошли, нужно с Kafka разобраться. Storm пробовать точно не будем, т.к. мы решили использовать только Spark компоненты.
UFO just landed and posted this here
У нас есть свой GitHub, там есть один проект для Spark. В Spark коммиты пока не делаем, т.к. это время разработчиков. Мы стартап, который уже самоокупился, поэтому не можем разбрасываться рабочим временем.
UFO just landed and posted this here
А как обстоят дела у команды с познанием внутренностей JVM и Scala компиляцией? Насколько я помню, поведении JMM описано для Java, есть ли такое же для Scala?
Для нас нет никакой необходимости познавать внутренности Scala, внутренности Spark для нас более актуальны, т.к. бывает нужно оптимизировать саму реализацию алгорима. А это больше не сама Scala, а Spark!
Судя по очень краткому ответу в рассылке scala-user@ поведение scala совпадает с описанным в JMM.
Очень интересно услышать что-то на тему Clojure vs Scala для Bigdata. Особенно у кого есть опыт
Очень интересная статья, спасибо!

А было что-то из Python стека (IPython + Pandas + Sklearn), чего совсем не хватало перехода на Scala? Например, DF from pandas же драматически, вроде, отличается от RDD?
Мне очень не хватало графиков в ipython интерфейсах. DF особо не пользуюсь, все-таки case классы и функциональный подход тоже дают похожий эффект, но конечно не такой как Pandas
Очень понравился Zeppelin. Вы его пробовали? Если да, чем не угодил?
Я очень много работал с Zeppelin, сейчас я могу сказать, что не понимаю, почему проект попал под крыло Apache.
Недостатки следуюшие:
  • очень неудобно строить графики, если вы посмотрите в статье, то увидите, что они намного гибче, можно использовать или R или HighCharts. Не нужно использовать SQL
  • когда вы пишите код через pipe, т.е. добавляете операторы через ".", в Zeppelin нужно ставить ее в конце предыдущей строки, а не в начале. Выглядит ужасно
  • ISpark — это ipyhton плагин, он очень легковесный и простой, Zeppelin — это «дирижабль кода», заново изобретенный велосипед. Ipython намного лучше
  • В Zeppelin одно ядро, когда у вас много пользователей и что-то пошло не так, то перезапуск ядра убьет блокноты других пользователей, в ipython на каждый блокнот пользователя запускается отдельное ядро.
Я очень много работал с Zeppelin, сейчас я могу сказать, что не понимаю, почему проект попал под крыло Apache.
Недостатки следующие:
  • очень неудобно строить графики, если вы посмотрите в статье, то увидите, что они намного гибче, можно использовать или R или HighCharts. Не нужно использовать SQL
  • когда вы пишите код через pipe, т.е. добавляете операторы через ".", в Zeppelin нужно ставить ее в конце предыдущей строки, а не в начале. Выглядит ужасно
  • ISpark — это ipyhton плагин, он очень легковесный и простой, Zeppelin — это «дирижабль кода», заново изобретенный велосипед. Ipython намного лучше
  • В Zeppelin одно ядро, когда у вас много пользователей и что-то пошло не так, то перезапуск ядра убьет блокноты других пользователей, в ipython на каждый блокнот пользователя запускается отдельное ядро.
Я не до конца понял, делаете ли вы какое-либо предположение о причинно-следственной связи на основании корреляции (или MIC)? Или наличие корреляции само по себе является целью ваших поисков? И можно ли полагаться на то, что такая корреляция сохранится в долгосрочном периоде? Все-таки бизнес будет принимать решения на основе ваших выводов.
Sign up to leave a comment.