Ну DSP в штатах обычно не в Computer Science, а в Electrical Engineering или Computer Engineering. Тут можно очень большой перегруз устроить — если нужен DSP — можно тогда в нем и учить комплексное пространство.
Вообще всегда знал, что хаскелисты — люди агресивные, такой вам вопрос на встречу — с чего вы взяли, что функциональное программирование — это круто? По-моему логическое программирование ничем не хуже. Можно турнир устроит — Haskell vs. Prolog.
Вы думаете монады в 21-ом веке изобрели? Теории множества и теории баз данных (где теория моделей присутствует) вполне хватит, чтобы быстро понять все что нужно из теории категорий.
CPS (Continuation Passing Style) изобрели в 1975 году
Лямда-калькулус давно не проходят в университетах, зачем он нужен? Хватит других калькулусов, более полезных, тот же реляционный калькулус.
Если вы чисто хотите функциональными языками заниматься — может тогда стоит скорректировать программу, но имо не сильно.
1) 1.0 — я имею ввиду, что без Spark, у меня была инфа, что спарк включат в Хадуп, но это пока не случилось.
2) Ну я неплохо понимаю фишку, но так же понимаю и все накладные расходы + очень крутую кривую обучения. И если у вас по сути одноразовая задача + она наивно-параллельна (это не совсем ваш случай, но практически такой) — то гораздо проще *очень* быстро все сделать на более простых инструментах. Вы же сначала все в базу заливаете, а потом 1 раз по ней обучитесь, и зачем столько страданий?
ScikitLearn не паралелится — он на одном узле. Если его использовать для скоринга — то просто кучу процессов на каждом узле можно запустить, а потом забрать данные куда надо, или прямо из узлов уже писать в СУБД. Для параллельного обучения он не годится.
3) Ну а какое вы параллельное обучение сверху map-reduce запустите, если не Mahaout?
4) А что хорошего есть в Mahaout, причем качественного? Я пытался на нем делать ALS — и там ни производительность, ни качество алгоритмов не соответствовала рекламным заявлениям.
2) я же написал — движок, то есть процессор, а не хранилище. Но на самом деле основная масса MPP DBMS используется для аналитики, тем не особо нужны транзакции. Так что тут уже 1 шаг.
3) я привел пример groupBy, причем здесь reshuffling? GroupBy много разных имплементаций — если будет интегрировано свое хранилище с мета-данными то можно разшардить данные так, что они будут в пределах одного ключа для группировки лежать на одном узле. MergeJoin может ничего не сортировать, если данные идут из отсортированного индекса, например B-Tree. Далее — когда у нас здоровенный план запроса с кучей joins — можно 1 раз для всех сделать сортировку, и потом ей пользоваться, конечно, если ключи будут совпадать — а это очень частый случай (куча outerjoin-ов и группировкой например — часто хватит одной сортировки на весь план выполения).
4) broadcast очень полезны, по сути — это барьерная синхронизация из MPI. Я не писал, что их нет в хадупе, хотя не знал, что они там есть. Особо никогда за хадупом не следил.
5) маркетинга много, но тому есть резон. Уровень людей, которые делают стэк Спарка намного серьезнее, чем Хадупа.
2) В Спарке есть все операторы реляционной алгебры + дополнителные операторы для BlinkDB
3) Возможны другие имплементации groupBy — например если все уже отсортировано по ключу — не надо ничего делать. Такой оператор появится — например когда будут merge-joins
4) Нет, не забили, видел 3-х месячной давности презентацию
5) Прочитайте про broadcast variables и accumulators
6) да, кратко, чтобы можно было быстро прочесть и дальше изучать
Нет, как на машинное обучение? Чисто для машинного обучение не надо ни компилятор писать, ни СУБД, ни операционку. Как раз я за универсальность.
К языкам программирования отношение не пренебрежительное — это мой накопленный опыт, можно отдельную статью про это написать. Вкраце — почему Скала? В обучении хочется с минимальными трудностями решать сложные задачи. Если вы доказатель теорем будете писать на C, у вас это займет в 10x больше времени, чем на Питоне. И зачем терять время? Но на Питоне вы не напишете высоко-производительный код и у вас никаких статических проверок. Скала — совмещает оба — можно заниматься ситемным программированием на ней, и можно писать AI код.
Перейти со Скала на C++/Java не так сложно (но очень неприятно!)
Есть разные подходы к преподаванию линейной алгебры, в штатах очень часто делаю курс для инженеров с вычислительной составляющей. Но тоже, не перегибая палку. Когда вляпались — тогда уже можно изучать. Вот например курс MIT, правда я бы его упростил существенно: убрал дифуры, комплексные пространства, и т.п.
Да, вот вы и перечислили почти все места. Еще неплохо обстоят дела в Институте Проблем Передачи Информации и в Институте Системного Программирования. Это, увы, очень и очень немного…
Деньги — уж извините, штука важная, и без них всегда один исход — все уезжают в штаты.
Линейную алгебру я включил. Оптимизацию тоже. А все остальное — отдельными курсами не стоит мне кажется — чего-то понадобится конкретное — можно изучить.
Да, не всю терминологию на русском еще освоил :)
По поводу MSc/PhD — нет, программа, курсы одна и та же, требования по PhD чуть выше.
Насчет Jordana — я не про PhD писал — это отдельная тема, я пропагандирую универсальность, и смесь инженера/ученого. У нас в России почти негде заниматься исследованиями в области машинного обучения (и получать при этом разумные деньги на жизнь)
Не было много времени разбираться с коннектором — была надежда, что заработает хорошо из коробки. С чем столкнулись:
1. Не смогли собрать .jar чтобы не конфликтовал с Spark SQL, поэтому сразу вылетел SQL функционал
2. Ладно, для начала SQL не нужен был — перелопачиваем все таблицы. Делаем RDD, читаем, сохраняем в HDFS.
2.1. На одном узле все отлично.
2.2. На кластере вылетает с ошибкой, что файл уже существует на HDFS.
3. Ок, сохранять в HDFS нам и не нужно — читаем, map, пишем обратно:
3.1. На одном узле работает отлично
3.2. На кластере — job выполняется успешно, без ошибок. Ничего в Кассандру не попадает. Это вообще кошмар. Особенно то, что Spark рапортует, что все успешно.
В общем пока поставили на паузу. Появится время — вернемся к этому вопросу. Но вообще впечатление нехорошее
CPS (Continuation Passing Style) изобрели в 1975 году
Лямда-калькулус давно не проходят в университетах, зачем он нужен? Хватит других калькулусов, более полезных, тот же реляционный калькулус.
Если вы чисто хотите функциональными языками заниматься — может тогда стоит скорректировать программу, но имо не сильно.
1) 1.0 — я имею ввиду, что без Spark, у меня была инфа, что спарк включат в Хадуп, но это пока не случилось.
2) Ну я неплохо понимаю фишку, но так же понимаю и все накладные расходы + очень крутую кривую обучения. И если у вас по сути одноразовая задача + она наивно-параллельна (это не совсем ваш случай, но практически такой) — то гораздо проще *очень* быстро все сделать на более простых инструментах. Вы же сначала все в базу заливаете, а потом 1 раз по ней обучитесь, и зачем столько страданий?
ScikitLearn не паралелится — он на одном узле. Если его использовать для скоринга — то просто кучу процессов на каждом узле можно запустить, а потом забрать данные куда надо, или прямо из узлов уже писать в СУБД. Для параллельного обучения он не годится.
3) Ну а какое вы параллельное обучение сверху map-reduce запустите, если не Mahaout?
4) А что хорошего есть в Mahaout, причем качественного? Я пытался на нем делать ALS — и там ни производительность, ни качество алгоритмов не соответствовала рекламным заявлениям.
P.S. В общем такое впечатление, что будете стрелять базукой (старой модели) по воробьям. И как бы не получилось такой ситуации: aadrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html
2) я же написал — движок, то есть процессор, а не хранилище. Но на самом деле основная масса MPP DBMS используется для аналитики, тем не особо нужны транзакции. Так что тут уже 1 шаг.
3) я привел пример groupBy, причем здесь reshuffling? GroupBy много разных имплементаций — если будет интегрировано свое хранилище с мета-данными то можно разшардить данные так, что они будут в пределах одного ключа для группировки лежать на одном узле. MergeJoin может ничего не сортировать, если данные идут из отсортированного индекса, например B-Tree. Далее — когда у нас здоровенный план запроса с кучей joins — можно 1 раз для всех сделать сортировку, и потом ей пользоваться, конечно, если ключи будут совпадать — а это очень частый случай (куча outerjoin-ов и группировкой например — часто хватит одной сортировки на весь план выполения).
4) broadcast очень полезны, по сути — это барьерная синхронизация из MPI. Я не писал, что их нет в хадупе, хотя не знал, что они там есть. Особо никогда за хадупом не следил.
5) маркетинга много, но тому есть резон. Уровень людей, которые делают стэк Спарка намного серьезнее, чем Хадупа.
2) В Спарке есть все операторы реляционной алгебры + дополнителные операторы для BlinkDB
3) Возможны другие имплементации groupBy — например если все уже отсортировано по ключу — не надо ничего делать. Такой оператор появится — например когда будут merge-joins
4) Нет, не забили, видел 3-х месячной давности презентацию
5) Прочитайте про broadcast variables и accumulators
6) да, кратко, чтобы можно было быстро прочесть и дальше изучать
ocw.mit.edu/courses/mathematics/18-06-linear-algebra-spring-2010/
К языкам программирования отношение не пренебрежительное — это мой накопленный опыт, можно отдельную статью про это написать. Вкраце — почему Скала? В обучении хочется с минимальными трудностями решать сложные задачи. Если вы доказатель теорем будете писать на C, у вас это займет в 10x больше времени, чем на Питоне. И зачем терять время? Но на Питоне вы не напишете высоко-производительный код и у вас никаких статических проверок. Скала — совмещает оба — можно заниматься ситемным программированием на ней, и можно писать AI код.
Перейти со Скала на C++/Java не так сложно (но очень неприятно!)
Да, вот вы и перечислили почти все места. Еще неплохо обстоят дела в Институте Проблем Передачи Информации и в Институте Системного Программирования. Это, увы, очень и очень немного…
Деньги — уж извините, штука важная, и без них всегда один исход — все уезжают в штаты.
Да, не всю терминологию на русском еще освоил :)
По поводу MSc/PhD — нет, программа, курсы одна и та же, требования по PhD чуть выше.
Насчет Jordana — я не про PhD писал — это отдельная тема, я пропагандирую универсальность, и смесь инженера/ученого. У нас в России почти негде заниматься исследованиями в области машинного обучения (и получать при этом разумные деньги на жизнь)
Весь мир переходит на Spark, а мы учим умирающий Hadoop 1.0.
На задаче, где не нужен Hadoop (спокойно можно за неделю сделать систему на gnu parallel + scikit learn. Ну конечно там с параллельным обучением не ахти, но еще большой вопрос — оно в этой задаче нужно?)
У Mahaout-а нету шансов выжить — посмотрите хотя бы какую поддержку Спарк получает: www.datanami.com/2015/02/25/apache-spark-ecosystem-continues-to-build/?utm_source=rss&utm_medium=rss&utm_campaign=apache-spark-ecosystem-continues-to-build
Имо намерения самые хорошие, но в результате что получится — большой вопрос.
Не было много времени разбираться с коннектором — была надежда, что заработает хорошо из коробки. С чем столкнулись:
1. Не смогли собрать .jar чтобы не конфликтовал с Spark SQL, поэтому сразу вылетел SQL функционал
2. Ладно, для начала SQL не нужен был — перелопачиваем все таблицы. Делаем RDD, читаем, сохраняем в HDFS.
2.1. На одном узле все отлично.
2.2. На кластере вылетает с ошибкой, что файл уже существует на HDFS.
3. Ок, сохранять в HDFS нам и не нужно — читаем, map, пишем обратно:
3.1. На одном узле работает отлично
3.2. На кластере — job выполняется успешно, без ошибок. Ничего в Кассандру не попадает. Это вообще кошмар. Особенно то, что Spark рапортует, что все успешно.
В общем пока поставили на паузу. Появится время — вернемся к этому вопросу. Но вообще впечатление нехорошее