Павел Велихов PavelVelikhov

А как замену HDFS не смотрели? Этот момент очень интересует

Вообще появилась профессия Data Engineer, которая в себя включает две выше-описанные

Хороший специалист по Big Data должен еще очень хорошо работать с Small Data

ДА, но очень сухой и not much fun

Исчесление. По сути relational calculus = set comprehension в функциольных языках

Диалог с американским профессором:

Professor: Teamwork is essential. The choice of programming languages is also curious. Why Scala?
1d ago

Pavel Velikhov Yeah, thanks, I forgot about teamwork, a lot of projects in: compilers, operating systems, databases, definitely teams of two. Scala: its really nice to have both a low-level language and a high-level language. You can build pretty-much systems code...more
1d ago
Pavel Velikhov
Pavel Velikhov I did though listen to a lecture about Scala's collections and map operator, which is in a complete state of mess, but I hope they will fix it soon.
1d ago

Professor: Agreed. I would also add a course on software testing and just as you had mentioned a formal methods, which is missing from your synopsis. For example, I would add a course on theorem proving (automated or interactive) and/or model checking and/or using theorem proving or model checking for program analysis. I have experience trying to teach all of these, will email you if interested. For a functional language, I would go with either Lisp (as it is classic) or Haskell (as I am in Scotland). I would not chose Scala, since despite the idea being good, there are quite a few things to fix.
1d ago

I put theorem proving into AI and Database Theory, so from my experience there would be no need for such class — expect a couple seminars on applying the techniques to the specific problem. I like Haskell as a language and I'm aware of some serious flaws in Scala (I was very optimistic about it when they started). But it gives all Java libraries and frameworks and its much much easier to get a job with Scala skills.

Мнение программиста, закончевшего MIT:

Да тяжело поспорить с материалом ибо во-первых сам только бакалавр, во-вторых, смотрю на все через линзу MIT, в-третьих, тут многое — дело вкуса.

Из того что заметил:
— у нас первый курс по теме был достаточно тероетический, проводился на scheme и по этой книжке: en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs
Выбор scheme был интересен т.к. этому языку мало где учат (что позволяет уравновесить возможности разных студентов) но при этом на нем можно написать очень глубокие вещи — символическую манипуляцию, и тд. Одна из задачек заключалась в том чтобы написать интерпретатор scheme на scheme. Так же scheme использовался для курса по искусственному интеллекту.

Ну эт было давно — в недавнее время со scheme перешли на python и старички начали жаловаться что мол «падает у нас качество и мало мы издеваемся над юнцами».

По алгоритмам вот этот курс очень понравился — он на undergrad уровне но там есть и про b-tree и про randomization чуток:
stellar.mit.edu/S/course/6/sp14/6.046/materials.html

Еще понравился курс computer language engineering: ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-035-computer-language-engineering-spring-2010/lecture-notes/
Тут цель — написать свой собственный компилятор — с оптимизацией и переводом на ассемблер. И это включает в себя обучение ассемблера. И сразу появляется резон выучить эту нечисть.

Вот еще интересный рисунок — как картину обучения видит MIT
www.eecs.mit.edu/docs/ug/6-3.pdf

То есть в принципе — меньше внимания уделяется конкретным языкам (C++ и SQL вообще не упоминаются) но больше теории и практики на конкретных задачах (напиши интерпретатор, напиши компилятор, хоть и на Java, напиши простенькое ядро и тд)…

По базам данных у нас курс только elective — а я, не зная что это мне потом пригодится, так его и не взял. Зато брал криптографию. Вот эт тоже было интересно! Чуть не помер.

Вот так-с… does this help?

Вот мнения аспиранта из Brown, который учился в МГУ:

Добавлю мои пять копеек. Наверное, больше не с точки зрения «сделай сам», а как человек покрутившийся здесь в graduate school.
Снача немного воды.

Имхо, MSc нужен только тем, у кого нет достаточного образования после бакалавратуры. Дело не в специализации. Средний бакалавр помимо major еще получает и minor, со всеми вытекающими. А еще курсы по истории и искусству может взять. У него просто может не быть достаточно знаний. У нас, в Брауне, были MSc-шники, у которых CS был лишь minor, и им хотелось переквалификации. Я, как PhD студент, обязан был брать курсы. Это было жутко лишнее, и только занимало время. После МГУ-шной подготовки курсы смотрелись как детский сад. Я не пытаюсь быть элитистом и говорить про «лучшее математическое образование в мире». Математические курсы, которые я брал: комбинаторика, дискретная вероятность, приближенные алгоритмы, были очень загружены. В этом основное отличие от России: нужно много пахать в течение семестра. Но материал воспринимался вторично, и мне казалось, что курсы идут ооочень медленно. Вывод: если вы учились (не зубрили, забивали или ещё что), в приличном Российском ВУЗе с приличной программой, MSc с математическими курсами вам нафиг не сдался.

Немного воды про курсы. Оставим математику, вернёмся к более техническим вещам. В Российском образовании этого реально не хватает. Имхо, основной аргумент идёт так: мы научили человека мыслить логично, а в практичных вещах он и сам разберётся. Фишка в том, что разобраться во всём объёме сложно. Поэтому взять курс с какой-то выжимкой по предмету может очень помочь. Практики чисто в виде implementation в России точно не хватает. В Штатах, в курсе по СУБДам могут спокойно попросить дополнить движок новыми оптимизациями или новыми методами хранения. В курсе по сетям могут попросить реализовать TCP/IP. В курсе по ОС реализовать куски операционки. В моё время в России этим никто не занимался, что плохо. Потому что это позволяет понять как всё устроено на практике. Программирование было, но мало. Ещё одна фича graduate school, которая мне очень понравилась: собственные проекты. Если брать graduate курс, то часто могут попросить придумать и реализовать небольшой проектик, можно в команде. На статью не хватит, но работать практически научит. Вывод: я бы не сказал, что программа в России прямо сильно страдает, это можно исправить. Но вот практическую составляющую поднимать нужно, она там нулевая. Одно но: деньги. В Штатах на курсе присутствует орава платных TA-ев, которые способны все эти проекты проверять. Одному-двум человекам справиться сложно, особенно профессорам или аспирантам.

Теперь немного критики. Можно себе представить MSc таким вот гениальным инженером, но на практике это не так. В Штатах развитой капитализм. В первую очередь MSc-шники приносят деньги. В связи с этим никто не будет требовать слишком много из страха потерять народ. Я общался и делал что-то совместное с «мастерами». Уровень часто низкий. Как всегда, всё зависит от человека. Честно говоря, среди бакалавров, имхо, гораздо больше смышлёных ребят. Многие люди воспринимают MSc просто как карьерный move, ради корочки. Профессионал выходит соответствующий. Кстати, где-то comprehensive экзамены есть, где-то нет. В Брауне, например, нет. Достаточно взять какое-то количество курсов из разных дисциплин. Опционально можно ещё сделать какой-нибудь проект и написать тезис. Всё. Имхо, это правильно. Comprehensive exams по принципу знал-сдал-забыл --просто зубрёжка, которая в реальности ничего не проверяет. Зачем сдавать одно и то же по два раза? В любом случае, не стоит забывать, что Штатовские вузы — просто брэнд, со всеми рекламами, рейтингами и прочей фигнёй. Проработка курсов в своём роде тоже грамотный маркетинг. Не стоит думать, что выпускник какого-нибудь Stanford в десять раз круче всех остальных. У него просто корочка красивее. Человеческий фактор важнее ВУЗовского.
1 hr · Like · 1

Alexander Kalinin Предложенный выше курс мне понравился. Я не уверен, что всё это легко выполнимо в рамках ВУЗовской программы. Каждый курс будет слишком нагружен. Плюс, теоретику часто не нужны ЯП или ассемблер. Например, если он занимается графами. Хотя я сторонник глубокой специализации (разумеется, с учётом необходимых базовых областей). Для всего остального существует collaboration. Собственно, проще всего — понять что нужно, посмотреть course prerequisites, и составить программу. С остальным можно познакомиться самостоятельно и если потребуется. Имхо, главный скилл хорошего профессионала --умение быстро находить информацию и обучаться. Забывать что-то и не знать чего-то никогда не стыдно.

Книжки и курсы:
1) По алгоритмам добавил бы Седжвика. У него есть очень хороший курс по алгоритмам на Java, что делает его доступным. И да, нижние границы для сортировки он выводит Курс на Coursera тоже есть.
2) По теории вычислений: Arora, Barak «Computational Complexity: A Modern Approach». Хорошо написана, хотя некоторым сложновато. Она поновее заодно.
3) Книжка про «Approximate algorithms», которую ты приводишь, --про _приближённые_, а не рандомные алгоритмы. Основной Грааль там в том, что бы выполнять polynomial-time approximation (PTAS) с любым уровнем приближения (эпсилон), если возможно. Многие из приближённых алгоритмов не рандомны, для многих существует де-рандомизация. Плюс, многие рандомные алгоритмы не являются приближёнными. Книжку читал ещё до того, как вышла
4) Про ЯП и компиляторы. Не вижу архи-большой необходимости спускаться в ассемблер для всех, если честно. Особенностей много, в зависимости от архитектуры. Если ты берёшь только ANTLR или JavaCC, ты теряешь LALR-грамматики. Это упущение. Вообще, C/C++ не страшный. Более того, в большинстве нормальных мест его очень активно используют. На Bison написать грамматику можно не медленнее чем на Java-свистульках. Вообще, как можно больше стоит учить про параллельное программирование и соответствующие алгоритмы.
5) В архитектуре я не вижу смысла проектировать CPU в обязательном порядке. А вот узнать про особенности архитектур стоит. Разница между ARM и x86-64, например, значительная. Например, с точки зрения orderings. Не зная этого, не будешь хорошо программировать параллельно. Там же и узнаешь про кэши и их когерентность, что для multi-core становится всё важнее.
6) В AI вообще ничего не вижу про Constraint Programming. А тема, замечу, важная. И да, 8 (и не только 8) ферзей нормальный солвер по местам расставит Туда же, в принципе, входят LP и MIP, так что это относится к оптимизации, которую ты упомянул.

Извиняюсь за каламбур Что-то, наверное, пропустил. Я считаю, что в MSc «топовых ВУЗов» заложено слишком много веры, и не стоит их считать за золотой стандарт. Самостоятельно или в ВУЗе практике всё равно не обучишься, хотя базовые знания помогут более-менее разбираться в теме. По мне, так когда начинаешь заниматься чем-то реальным, знания приходят очень быстро и более естественно.

У нас осталась очень сильная математическая школа все равно, если есть тяга к знаниям — всего можно добиться

Ну IT = бизнес образование по сути, на одном science без бизнеса далеко не уедешь

Очень интересно про Германию, там всегда была мощная школа по Computer Science, но все никак не получается там сделать конкурент силиконовой долины. А прямо совсем похож, или какие-то отличия? Немецких студентов, приезжающих в штаты на PhD обычно отличала особенно сильная математическая подготовка.

Спасибо за развернутый апдейт.

С линейной регрессией думается мне, что сэмплом, которые влезет в память одного узла можно обойтись — а срокинг можно наивно-параллельно пустить. Ну дело ваше конечно.

На parallel поднимал все очень быстро, конечно быстрее Hadoop и Spark

+1 сразу бы так написали :)
Очень интересно, не знал что немцы чего-то делают вообще…

Математики для computer science мало не бывает. Но нельзя сначала закончить мехмат, а потом учить computer science. Да и на мехмате не все выдерживают одну абстракцию без практического приложения. Вот посмотрите книжку Виану по теории баз данных — там очень хорошая математика, но вся сразу в приложении.

Ну спора тут мало — HIVE именно сверху шафлов, и сделать на них нормальный dbms не получится.
И UC Berkley — это серьезные ребята, я им верю

Если вы не поняли — это была провокация. Давайте оставим место конструктивным дискуссиям.

Не говорю отказываться, но не изучать абстрактно. То есть понадобилось — тогда уже изучить. Тут похожий подход нужен, как в физике — берем аппарат тогда, когда он нужен, а не заранее не пойми зачем.

Пока вы не развеяли мои сомнения в том, что вы знаете, что такое монады.

О да, срезал, как у Бунина… ZFC со всеми объектами нормально работает, видимо вы не в курсе.

Ну DSP в штатах обычно не в Computer Science, а в Electrical Engineering или Computer Engineering. Тут можно очень большой перегруз устроить — если нужен DSP — можно тогда в нем и учить комплексное пространство.

И еще в догонку — дайте пожалуйста формальное определение монады в формализме ZFC а не в теории категорий.

Вообще всегда знал, что хаскелисты — люди агресивные, такой вам вопрос на встречу — с чего вы взяли, что функциональное программирование — это круто? По-моему логическое программирование ничем не хуже. Можно турнир устроит — Haskell vs. Prolog.

Вы думаете монады в 21-ом веке изобрели? Теории множества и теории баз данных (где теория моделей присутствует) вполне хватит, чтобы быстро понять все что нужно из теории категорий.

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

1) уже забыл, где видел

2) я же написал — движок, то есть процессор, а не хранилище. Но на самом деле основная масса MPP DBMS используется для аналитики, тем не особо нужны транзакции. Так что тут уже 1 шаг.

3) я привел пример groupBy, причем здесь reshuffling? GroupBy много разных имплементаций — если будет интегрировано свое хранилище с мета-данными то можно разшардить данные так, что они будут в пределах одного ключа для группировки лежать на одном узле. MergeJoin может ничего не сортировать, если данные идут из отсортированного индекса, например B-Tree. Далее — когда у нас здоровенный план запроса с кучей joins — можно 1 раз для всех сделать сортировку, и потом ей пользоваться, конечно, если ключи будут совпадать — а это очень частый случай (куча outerjoin-ов и группировкой например — часто хватит одной сортировки на весь план выполения).

4) broadcast очень полезны, по сути — это барьерная синхронизация из MPI. Я не писал, что их нет в хадупе, хотя не знал, что они там есть. Особо никогда за хадупом не следил.

5) маркетинга много, но тому есть резон. Уровень людей, которые делают стэк Спарка намного серьезнее, чем Хадупа.

Да, слышал хорошая книга — правда по оглавлению почти такая же, как в ссылке.

1) Хмм… да, читал ананс давно, что будут включать, но не включили. Но уже есть другие дистрибутивы со Спарком

1) Он в Hadoop 2.0

2) В Спарке есть все операторы реляционной алгебры + дополнителные операторы для BlinkDB

3) Возможны другие имплементации groupBy — например если все уже отсортировано по ключу — не надо ничего делать. Такой оператор появится — например когда будут merge-joins

4) Нет, не забили, видел 3-х месячной давности презентацию

5) Прочитайте про broadcast variables и accumulators

6) да, кратко, чтобы можно было быстро прочесть и дальше изучать

А это перевод статьи?

P.S. Вот например курс MIT по линейной алгебре (но такой, перебор). Более простные курсы — часто недобор.
ocw.mit.edu/courses/mathematics/18-06-linear-algebra-spring-2010/

Нет, как на машинное обучение? Чисто для машинного обучение не надо ни компилятор писать, ни СУБД, ни операционку. Как раз я за универсальность.

К языкам программирования отношение не пренебрежительное — это мой накопленный опыт, можно отдельную статью про это написать. Вкраце — почему Скала? В обучении хочется с минимальными трудностями решать сложные задачи. Если вы доказатель теорем будете писать на C, у вас это займет в 10x больше времени, чем на Питоне. И зачем терять время? Но на Питоне вы не напишете высоко-производительный код и у вас никаких статических проверок. Скала — совмещает оба — можно заниматься ситемным программированием на ней, и можно писать AI код.

Перейти со Скала на C++/Java не так сложно (но очень неприятно!)

Есть разные подходы к преподаванию линейной алгебры, в штатах очень часто делаю курс для инженеров с вычислительной составляющей. Но тоже, не перегибая палку. Когда вляпались — тогда уже можно изучать. Вот например курс MIT, правда я бы его упростил существенно: убрал дифуры, комплексные пространства, и т.п.

Да, вот вы и перечислили почти все места. Еще неплохо обстоят дела в Институте Проблем Передачи Информации и в Институте Системного Программирования. Это, увы, очень и очень немного…

Деньги — уж извините, штука важная, и без них всегда один исход — все уезжают в штаты.

Реально, книги Кнута как учебники никто не использует.

Кнута очень уважаю, как и Колмогорова :) Почитайте Колмогорова :)

Линейную алгебру я включил. Оптимизацию тоже. А все остальное — отдельными курсами не стоит мне кажется — чего-то понадобится конкретное — можно изучить.

Да, не всю терминологию на русском еще освоил :)

По поводу 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 рапортует, что все успешно.

В общем пока поставили на паузу. Появится время — вернемся к этому вопросу. Но вообще впечатление нехорошее

Генератор и впрямь плохое название, в Питоне 3 генераторы — это совершенно другой зверь. Жаль, что никак не найдется нормальный термин для comprehension

Это они в исходниках пишут, а у меня инсайдерская инфа.

Прямо в продакшн они не лезут, но у них иду проекты с Фейсбуком и Oracle Labs.

В последнее время очень немало университетиских проектов идет прямо в индустрию — Ingres, Postgres, C-Store, H-Store, Berkley Spark+Shark, и другие.