По поводу листинга скажу больше: в одном случае он реализует UDF функцию для Pig (не лучший выбор), а в другом уже использует шарпы с предоставленной оберткой.
Почему не udf для hive (под хайв они зачастую достаточно короткие)?
Почему не голый MR (для среднего тоже будет элементарно, можно глянуть пример WordCount, в редьюсе посчитать сумму и на выходе отдать деление, а не сумму)?
Но ответ кроется в авторах листинга: M. Isard, Y. Yu, одни из основных разработчиков Dryad, то есть уже показана предвзятость.
Про MPI/GPU vs Dryad/Hadoop сравнение тоже по-моему не совсем корректно, связки GPU+Hadoop потенциально даже применимы, но вот на практике все проекты останавливаются на ресеч и бета стадиях (можно погуглить, несколько полуживых 2-3 летней давности + пару фирм предоставляющих консалтинг без описания use cases), так как сама парадигма map-reduce не очень хорошо вяжется с gpu подходом.
Так же согласен с вами в том, что на данный момент идет сравнение "Dryad мог бы" и "Hadoop и экосистема делает".
Высказывание автора: И все эти инструменты предоставляют зачастую дублирующиеся решения для задач узкого характера (по сути, обхода ограничений) вместо предоставления единого универсального инструмента решения как парсинга логов, так и подсчета PageRank и анализа графов
Мне тоже режет ухо, так можно на любую вещь сказать, что она предоставляет дублирующий интерфейс:
1. специализированный набор ключей в автомастерской, некоторые дублируют функцию друг друга
2. языки высокого уровня, чем им asm не угодил, ведь предоставляет все необходимые примитивы
3. набор различных фреймворков под разные задачи, пускай в некоторых сферах они и пересекаются
MR & YARN — низкоуровневые примитивы
Pig — императивное описание тасков, работаем со стримом данных
Hive — декларативное, работаем как с sql
Giraph — работа с графовым представлением данных
Storm — event processing, данные обрабатываются еще до сохранения на диск, ациклический граф
Spark — в первую очередь итеративные алгоритмы и машинное обучение, высокая скорость за счет хранения в распределенной таблице в памяти
vs
Dryad & DryadLINQ — абстракция над данными и вычислениями, реализации алгоритмов еще не написаны.
Хотя по поводу 3го пункта с поклонниками ms и c# трудно спорить, так как считают, что есть единственно правильный путь и решение (фреймворк)
За Dryad я наблюдал очень давно, так как альтернативные реализации всегда полезно знать, но все что там было уже давно реализованно в других продуктах, нету только работы через SharedMemory, но по мне это очень спорное решение, уж лучше тогда через pipe работать (что и ожидается в хадупе для обмена данными на одном хосте между task и data нодами). В остальном же, хотели получить достаточно большой комбайн на все случаи жизни, но как и любые попытки обхватить необъятное она провалилась.
p.s. Посмотрел я на этот Naiad и дальше простейшей демки ничего полезного представить они не могут. Опять идет сравнение внутренней разработки и "мы возможно будем делать" с работающей системой для анализа графов.
не понял, что я именно должен найти в листиге jit?
то что сортировка занимает время сравнимое со всем поиском?
по поводу кода:
0) вносим ваши изменения для матчера
1) смотрим какой порядок выбора предложен после сортировки
2) enum RecordFields { CODE, AGE, AMOUNT, GENDER, HEIGHT } // порядок который мы получим после анализа предикатов
3) отключаем сортировку
4) время поиска с оптимальным профилем 9-10ms
на этом фоне 30ms c включенной сортировкой как-то смотрится печально, так как теряем почти 20ms на ней
даже с неоптимальным профилем выдаем 20ms
если посмотреть на первоначальный вариант «профайла», то видно что там порядок полей с сортировкой и так попадает на оптимальный, т.е. тут мы теряем только 15ms на сортировку, что сравнимо с временем выполнения всего кода.
так что преждевременные оптимизации далеко не всегда идут во благо
p.s. еще есть косяк теста в том, что у нас массив полей неизменяемый и jit начинает уже подстраиваться под него =) поэтому по хорошему нужно еще и его регулярно перегенеривать, конечно если это у нас база данных, а не фиксированный набор полей.
p.p.s. как получить асм я представляю и уж если пошла такая пьянка на разминку мозгов: тыц
в чем причина, что incrementnFieldCall так проседает относительно incrementnFieldCall2, ведь согласно логики производительность должна быть равна
баг уже зарепорчен, но вот поковырять asm вам должно быть прикольно
с одной стороны я понимаю ЗАЧЕМ это все сделано, но цитируя TheShade:
– “Real world strikes back!”
– Исследуем взаимодействие софта с железом на типичных данных
• Производительность уже нельзя предсказать
• Производительность можно только измерить
замерил 20ms с отключенной сортировкой vs 31ms с включенной
p.s. конечно по хорошему нужно допилить jmh, но пока в качестве костыля увеличил количество прогревов
for (int i = 0; i < 100; i++) {
long millis1 = System.currentTimeMillis();
store.find2(finder);
long endMillis1 = System.currentTimeMillis();
System.out.println(«Elapsed time (warm) :» + (endMillis1 — millis1) + «ms»);
}
в итоге с отключенной сортировкой действительно первых пару раз еще выполняется быстрее, но потом выходит на стабильное значение в 30-31ms (с 17ms в первой попытке), в то время как с отключенной сортировкой опускается до 19-20ms (33ms в первой попытке).
ну хотите фактов, давайте обсудим статью и рассмотрим факты:
1) Dryad адаптирован и используется в Bing, Microsoft AdCenter, Kinect, Windows HPC Server 2008 R2 (последнее, известно достоверно).
WTF ??? какой кинект, если мы говорим про кластера и распределенную обработку
2) потому что Dryad — не Hadoop: модель map/reduce — только частный случай для Dryad, в то время как для Hadoop – это единственно возможная модель выполнения.
в заголовке указали, что mr единственным решением был только до появления ярна, а в выводах забыли, нехорошо как-то, под хадуп ярном и обход графа уже запилили и рекурсивные алгоритмы, когда вывод с одной ноды сразу стримом гонится на другую для свертки, не ожидая остальных.
3) сложность адаптации для работы в realtime-режиме
берем spark, для рекурсивных заданий это реально молния, есть проект по замене mesos на yarn из хадупа, в итоге получаем хорошую скорость близкую к реалтайм, заюзав sharkвместо hive еще и sql подмножество хапаем.
А еще для пущего эфекта добавим в кашу такой проект как impala (имеет пачку плюшек для работы с большими данными: mpp, p2p, оптимизированный формат хранения parquet (тоже подглядели у гугла, есть компрессия данных и rle для чисел)).
4) Задание в Dryad runtime представляет собой направленный ациклический граф, где вершины представляют собой программы, а ребра графа – каналы данных
что-то мне это напомнинает, а впомнил, storm от твитера для евент процессинга, но
5) и, вероятно, принципиальная невозможность работы с потоковыми данными.
ЧТО??? О_о имея такую архитектуру не запилить работу с потоковыми данными, особенно на фоне хорошей парадигмы и либы Rx, да они наверное издеваются
6) в Hadoop свертка не может начаться пока все map-задания не будут окончены
верно, дальше на вашем слайде и в описании показано Speculative Execution, когда таск (map или reduce) запускается параллельно с уже имеющимся медленным таском в надежде выиграть время, фича доступна уже в первой версии хадупа.
7) Open-source лицензии, потому что это изначально другой тип продукта (но бесплатный доступ по академической лицензии все же есть);
ой да не смешите, какой другой тип продукта? хотя если вы имели в виду: «продукт для того, чтобы залочить кого на себе и стричь бабло», то тогда я полностью согласен, не тот это продукт.
8) Других заявлений про дальнейшую поддержку Dryad или, напротив, однозначный отказ от поддержки, на протяжении прошлого (2012) и этого года замечено не было.
ага, то есть слов и действий: «для больших вычислений мы будем использовать хадуп, ради того чтобы его под виндой запускать в azure мы даже неплохо бабла отвалим hortonwork» уже недостаточно, чтобы решить что продукт издох. Раз есть devel-preview которая неподдерживается и сорцов нету, то считаем проект живым. Нет, ну неужели вы это серьезно? Имеющиеся (но не доказанные) внедрения на фоне остановки развития продукта вызывают лишь жалость к тем, кто залочился на данном продукте, а соскочить не может.
Сколько раз уже можно повторять: Hadoop — это не MapReduce + HDFS, Hadoop — это ЭКОСИСТЕМА.
так что: ДА, по характеристикам Dryad устарел лет на 10
Если вас обидело то, что я назвал «настройку рабочего места» админским таском, то извините, я приводил пример «первой помощи» и сам понимаю, что это не работа настоящего администратора.
По поводу клауда, сюда уже примешался ответ на реплику выше, с которой не совсем согласен:
>> Если не брать в расчёт корпорации с гигантской инфраструктурой, то программисты прекрасно обходятся сами, а с консьюмеризацией технологий и распространением облачных сервисов потребность в администраторах будет уменьшаться.
>> а о том, что есть вещи, в которых разработчики редко разбираются хорошо (да и не должны, в общем-то),
Вот именно что не должны зачастую, для этого и возникают профессии на стыке технологий. Админ и программист — это ортогональные отрасли, одно не исключает другого, но часто бывает, что и не дополняет.
эникейщиной это можно назвать когда знаешь другие вещи достаточно глубоко, а с позиции обычного человека это более чем администрирование.
мой пример показывает «первую помощь», а не админские таски.
с настройкой iptables вы вообще пошутили, java программист может написать и полностью оттестировать свое веб приложение разрабатывая на винде + локальном tomcat, а запустить его могут и на линухе (iptables) и на фряхе или солярисе (ipfw), теперь предлагаете каждому веб девелоперу еще и админские курсы проходить по всем системам? а еще есть нюанс, что написанное десктопное приложение под винду при желании можно автоматом продеплоить в группу через AD, так что давайте и его в обязательную программу включим.
iptables и друзья это уже реальная работа админа и я только рад, что эта область тоже развивается, те кто говорят что админы исчезнут из-за появления облаков и paas забывают одну простую вещь: чтобы эти облака появились и работали корректно, за ними стоят хорошие группы как программистов, так и админов на обслуживании. Сложность никуда никогда не исчезает, просто она уходит на другой уровень.
build engineer это в данный момент одно из популярных направлений развития администраторов, devops другое, в обоих этих направлениях человек это уже не просто админ или программист, это смесь знаний разработки и знаний администрирования (смешать в пропорциях нужных для задачи, но не взбалтывать). но продолжают существовать и чистые администраторы, и я не вижу ничего плохого когда человек концентрируется на одном «как сделать хороший продукт», а вопросы «нужно посмотреть чтобы на диске было место, проверить после деплоя разерешение на запись в папки, настроить master-slave на базе, настроить iptables на доступ только ограниченным портам и nginx для кеширования статики» оставить профессионалам
ну давайте продолжать мысль: установить софт которым пользуешься сможет каждый, поставить антивирус тоже, браузер и базовые вещи из разряда первой помощи еще не видел чтобы вызывали проблему.
>> Или прямой доступ к памяти для них нечто невероятное
вы сходу ответите различия между ETL vs ELT vs OLTP? или вопросы оптимизации базы данных (DBA)?
другие занимаются web и не сталкиваются ни с большими объемами, ни в ручным управлением памяти, у них задача стоит в корректной верстке и быстроте загрузки страницы (уменьшить количество запросов на сервер, оптимизировать css чтобы меньше раз пробегало по дереву и тд)
третий занимается распределенными системами, стоят вопросы надежности, балансировки нагрузки и тд
четвертый работает на embedded с c/c++ & asm и пошлет лесом всех вышестоящих после слов javascript, database, dht, у него другие задачи.
Но самое главное: каждый из них может набросать какой простейший скрипт если нужно, вот сложнее в чужую область никто не полезет, но другим ВСЕГДА будет говорить «А вы разве не знали _подставить_по_вкусу_…? Это же каждый школьник должен знать, не говоря уже про программиста»
вот посмотришь, в древнем мире и даже в средние века были лекари, один лекарь и все дела
а теперь развели всяких специальностей: хирурги, психиатры, педиатры
любое развитие отрасли и усложнение ее заставляет все больше развиваться специализации, это нормальный процес
а не проще в этом случае перейти на PostgreSQL или MongoDB?
у них обоих есть расширения для индексации 2d и 2dSphere координат, выборка в итоге достаточна шустрая, без лишних телодвижений
Странно, но вот я когда меня приглашают на собеседование зачастую уже сам говорю, что сильно менять не планирую, но пообщаться если меня частично устраивает их проект готов. Заглянув на собеседование можно решить сразу несколько вопросов:
1) составить по крайней мере базовое представление о компании
2) составить базовое представление о людях и уровне их квалификации
3) засветиться самому (то что вас текущий проект не устроит еще ни о чем не говорит, может оказаться что очень скоро у них откроется действительно интересная для ВАС позиция и они уже будут знать куда обращаться), имеется несколько хороших контактов после таких общений
4) проверить в первую очередь свою самооценку (на рынке хватает как тех кто завышенно о себе думает, так и тех кто действительно что-то знает, но боится показать это)
да, это все относится когда не ты сам напрашиваешься на собеседование, а тебя приглашают и сразу все понимают и приглашают в первую очередь «познакомиться».
>> адовое собеседование на 2 часа
ну были у меня и по 3 часа, когда техническое из базовых вопросов постепенно перетекает в общее обсуждение техник и подходов разработки и инструментов. К этому моменту собеседование обычно превращается в локальный обмен опытом, в процессе которого ты для себя открываешь кое-что новое, но и собеседующим можешь рассказать тоже много полезного.
всегда считал конференции в первую очередь пиаром, но уж никак не способом заработка
для того и спонсоры чтобы покрыть разницу в бюджете между билетами проданными и стоимостью организации
вопрос в том, что для некоторых с учетом билетов и жилья стоимость конференций получается отнють не такой какая она стоит на сайте, а можно смело суммарные траты умножать на 5 от стоимости билета и брать отпуск/отгулы на 2-3 дня минимум
покупать записи за стоимость участия это вообще больше попахивает бредом, а со скидкой следуя вашей логике продавать тоже не стоит
ну на счет " материалы только для участников." я бы хотел задать встречный вопрос: а как же быть тем кто не в питере?
С одной стороны интересная конференция, с другой в апреле-мае пройдут java one, javaee, jpoint, где доклады частично пересекаются, на все не съездишь если ты не в питере-москве живешь, а так хоть видео можно было бы посмотреть тех докладов которые не видел.
По-моему данные инструменты не относятся к разряду «необходимо знать», скорее к «желательно знать о существовании».
А вот что необходимо, так это:
1) принципы map-reduce и итеративных алгоритмов
2) ну и действительно инструменты:
hadoop для batch обработки, доп инструменты для него hive и pig
storm и spark для реалтайм процессинга,
druid и impala для реалтаймовых выборок с sql подобным синтаксисом
то что перечислено в статье это обертки, которые можно использовать для того чтобы агрегировать потоки данных от приложений и последующей простой визуализации, а следовательно и целевая аудитория отнють не «программист, работающий с Big Data», а «разработчик приложений (в основном мобильных), которое может генерировать потоки данных, а сам разработчик не знает куда их залить и что с ними можно сделать»
так я был разработчиком у которого стояла задача ускорить это все «счастье»: «вот у нас есть что-то, нужно найти почему так плохо работает, должно работать быстро и не падать на таймаутах» =)
в итоге переписано все на чистую java (почти полный копипаст, так как в большем уже все отлажено было) и прямо в xml процесса указываем какие хэндлеры дергать, производительность увеличилась более чем на порядок.
несколько jvm это действительно уход от проблемы, но сроки поджимали и нужно было предоставить отчеты сколько может держать сервис и что проблемы со скоростью у проекта выше по стеку
Для нагрузочного тестирования уже приходилось пару раз подымать независимые jmeter, так как бывало что подвисали отдельные треды, несколько jmeter с меньшим количеством потоков работали хорошо.
Хотелось бы дополнительно уточнить по поводу производительности BeanShell своим опытом:
Имеется:
1. jboss jbpm (количество воркеров больше 30ки)
2. бизнес процесс в котором некоторые состояния и условия написаны на BeanShell
3. пару тысяц процессов на выполнение
Вопрос: где будет затык?
Оказалось, что в BeanShell, но отнють не скорость его работы как «интерпретатора», так как жизненный цикл скрипта выглядит примерно так:
1. берем скрипт
2. разбираем и компилим его в валидный class файл
3. отправляем на выполнение
и вот пункт 2 оказывается проходит через синглтон, то есть выполнение еще можно в несколько потоков, а вот компилироваться у вас будет в 1 поток, а остальные будут стоять курить.
Так что сам BeanShell быстрый, а вот большое количество разнородных небольших скриптов положит ваше нагрузочное тестирование в 2 счета.
по поводу демпинга — возможно, индусы любят занижать планку, но также замечено, что и заказчики далеко не всегда ведутся на того кто дает меньше
по поводу впарить — не согласен
пускай я там и не долго, но на оба проекта которые мне понравились я прошел,
третий сейчас в замороженном состоянии, так как заказчик сам не знает полностью требования, но отношения уже у нас сложились неплохие.
Если под «впаривать» вы понимаете грамотное сопроводительное письмо с примерным объяснением как вы уже сразу понимаете проект и что будете делать чтобы проект закончился успешно, при необходимости сразу уточняете некоторые скользкие вопросы, то в моем понимании это «хороший тон», а не впаривание. Да и заказчики относятся к таким соискателям на порядок лучше, чем к тем кто нажимает «принять» и одна фраза «усё буде у лучшем виде, ты только плати»
Возможно если заниматься сугубо фрилансом будут заметны и другие стороны, но пока я просматриваю проекты которые мне интересны с точки зрения изучения новых технологий или поковыряться в качестве хобби, так как текущее рабочее место меня полностью устраивает =)
Можно узнать чем вас обидела Cloudera?
слишком агрессивное настроение чувствуется по отношению к ней.
По поводу утверждений, что это всего-лишь набор апачевских проектов, а сами они ничего не делали, вы не правы:
1. Flume — система для event процессинга, зародилась в cloudera и позже отдана в инкубатор апача
2. Hue — удобная веб обвязка поверх хадупа, пига и хайва, также зародилась в cloudera и отдана в инкубатор
3. Sqoop — система для синхронизации-переливки данных между хадупом (файлы на хдфс, хайв, пиг, хбэйс) и обычными реляционками, вплоть до создания схемы, зародился и развивался в cloudera и отдан в инкубатор
Дополнительно в пределах cdh3 или cdh2 вы имеете полную совместимость своих джобов и работу без проблем, в мире hadoop с этим большая проблема, особенно когда версии выпускают часто и какая активная сказать никто не может, а стоит выйти новой версии разработчики забивают на предыдущие. Для миграции между версиями имеются исчерпывающие мануалы. Cloudera же вливает гигантское количество багфиксов в виде бэкпорта в свои продукты, так же имеются бэкпорты отдельных улучшений из следующих нестабильных версий в существующие стабильные. Все наработки по хадуповскому стеку открыты, бери и скачивай в сорцах, изменяй и пересобирай. Исключением является консоль управления, но она появилась когда была уже версия cdh3, причем была уже не первый месяц. Так что я бы рассматривал Cloudera в качестве RedHat для рынка hadoop решений. Один из ведущих разработчиков Todd Lipcon работает у них, все направления развития и новинки в тестировании и достижении хадупа как платформы очень четко просматриваются в его твитере.
Использовал cdh2 и cdh3, их стабильность по сравнению с ванильным хадупом это было что-то, сравнивать с cdh4 не берусь так как ушел с того проекта, но сомневаюсь в том, что Cloudera выпустила сырой продукт на рынок, уж слишком они серьезно подходят к делу, да и не жалеют отдавать свои наработки в открытый доступ.
Чем же будет Hortonworks еще покажет время, активность у них неплохая, но слишком молоды еще.
А вообще в мире BigData для меня выделяются:
1. hadoop — cloudera
2. cassandra — datastax
Почему не udf для hive (под хайв они зачастую достаточно короткие)?
Почему не голый MR (для среднего тоже будет элементарно, можно глянуть пример WordCount, в редьюсе посчитать сумму и на выходе отдать деление, а не сумму)?
Но ответ кроется в авторах листинга: M. Isard, Y. Yu, одни из основных разработчиков Dryad, то есть уже показана предвзятость.
Про MPI/GPU vs Dryad/Hadoop сравнение тоже по-моему не совсем корректно, связки GPU+Hadoop потенциально даже применимы, но вот на практике все проекты останавливаются на ресеч и бета стадиях (можно погуглить, несколько полуживых 2-3 летней давности + пару фирм предоставляющих консалтинг без описания use cases), так как сама парадигма map-reduce не очень хорошо вяжется с gpu подходом.
Так же согласен с вами в том, что на данный момент идет сравнение "Dryad мог бы" и "Hadoop и экосистема делает".
Высказывание автора:
И все эти инструменты предоставляют зачастую дублирующиеся решения для задач узкого характера (по сути, обхода ограничений) вместо предоставления единого универсального инструмента решения как парсинга логов, так и подсчета PageRank и анализа графов
Мне тоже режет ухо, так можно на любую вещь сказать, что она предоставляет дублирующий интерфейс:
1. специализированный набор ключей в автомастерской, некоторые дублируют функцию друг друга
2. языки высокого уровня, чем им asm не угодил, ведь предоставляет все необходимые примитивы
3. набор различных фреймворков под разные задачи, пускай в некоторых сферах они и пересекаются
MR & YARN — низкоуровневые примитивы
Pig — императивное описание тасков, работаем со стримом данных
Hive — декларативное, работаем как с sql
Giraph — работа с графовым представлением данных
Storm — event processing, данные обрабатываются еще до сохранения на диск, ациклический граф
Spark — в первую очередь итеративные алгоритмы и машинное обучение, высокая скорость за счет хранения в распределенной таблице в памяти
vs
Dryad & DryadLINQ — абстракция над данными и вычислениями, реализации алгоритмов еще не написаны.
Хотя по поводу 3го пункта с поклонниками ms и c# трудно спорить, так как считают, что есть единственно правильный путь и решение (фреймворк)
За Dryad я наблюдал очень давно, так как альтернативные реализации всегда полезно знать, но все что там было уже давно реализованно в других продуктах, нету только работы через SharedMemory, но по мне это очень спорное решение, уж лучше тогда через pipe работать (что и ожидается в хадупе для обмена данными на одном хосте между task и data нодами). В остальном же, хотели получить достаточно большой комбайн на все случаи жизни, но как и любые попытки обхватить необъятное она провалилась.
p.s. Посмотрел я на этот Naiad и дальше простейшей демки ничего полезного представить они не могут. Опять идет сравнение внутренней разработки и "мы возможно будем делать" с работающей системой для анализа графов.
в последующих вызовах сразу забирает из кеша полученный класс
можно конечно написать sb.append для отдельных составляющих, но тогда снижается читабельность
то что сортировка занимает время сравнимое со всем поиском?
по поводу кода:
0) вносим ваши изменения для матчера
1) смотрим какой порядок выбора предложен после сортировки
2) enum RecordFields { CODE, AGE, AMOUNT, GENDER, HEIGHT } // порядок который мы получим после анализа предикатов
3) отключаем сортировку
4) время поиска с оптимальным профилем 9-10ms
на этом фоне 30ms c включенной сортировкой как-то смотрится печально, так как теряем почти 20ms на ней
даже с неоптимальным профилем выдаем 20ms
если посмотреть на первоначальный вариант «профайла», то видно что там порядок полей с сортировкой и так попадает на оптимальный, т.е. тут мы теряем только 15ms на сортировку, что сравнимо с временем выполнения всего кода.
так что преждевременные оптимизации далеко не всегда идут во благо
p.s. еще есть косяк теста в том, что у нас массив полей неизменяемый и jit начинает уже подстраиваться под него =) поэтому по хорошему нужно еще и его регулярно перегенеривать, конечно если это у нас база данных, а не фиксированный набор полей.
p.p.s. как получить асм я представляю и уж если пошла такая пьянка на разминку мозгов:
тыц
в чем причина, что incrementnFieldCall так проседает относительно incrementnFieldCall2, ведь согласно логики производительность должна быть равна
баг уже зарепорчен, но вот поковырять asm вам должно быть прикольно
– “Real world strikes back!”
– Исследуем взаимодействие софта с железом на типичных данных
• Производительность уже нельзя предсказать
• Производительность можно только измерить
замерил 20ms с отключенной сортировкой vs 31ms с включенной
p.s. конечно по хорошему нужно допилить jmh, но пока в качестве костыля увеличил количество прогревов
for (int i = 0; i < 100; i++) {
long millis1 = System.currentTimeMillis();
store.find2(finder);
long endMillis1 = System.currentTimeMillis();
System.out.println(«Elapsed time (warm) :» + (endMillis1 — millis1) + «ms»);
}
в итоге с отключенной сортировкой действительно первых пару раз еще выполняется быстрее, но потом выходит на стабильное значение в 30-31ms (с 17ms в первой попытке), в то время как с отключенной сортировкой опускается до 19-20ms (33ms в первой попытке).
гитхаб
отключение данной сортировки уменьшает время выборки с 33ms до 15ms
1) Dryad адаптирован и используется в Bing, Microsoft AdCenter, Kinect, Windows HPC Server 2008 R2 (последнее, известно достоверно).
WTF ??? какой кинект, если мы говорим про кластера и распределенную обработку
2) потому что Dryad — не Hadoop: модель map/reduce — только частный случай для Dryad, в то время как для Hadoop – это единственно возможная модель выполнения.
в заголовке указали, что mr единственным решением был только до появления ярна, а в выводах забыли, нехорошо как-то, под хадуп ярном и обход графа уже запилили и рекурсивные алгоритмы, когда вывод с одной ноды сразу стримом гонится на другую для свертки, не ожидая остальных.
3) сложность адаптации для работы в realtime-режиме
берем spark, для рекурсивных заданий это реально молния, есть проект по замене mesos на yarn из хадупа, в итоге получаем хорошую скорость близкую к реалтайм, заюзав sharkвместо hive еще и sql подмножество хапаем.
А еще для пущего эфекта добавим в кашу такой проект как impala (имеет пачку плюшек для работы с большими данными: mpp, p2p, оптимизированный формат хранения parquet (тоже подглядели у гугла, есть компрессия данных и rle для чисел)).
4) Задание в Dryad runtime представляет собой направленный ациклический граф, где вершины представляют собой программы, а ребра графа – каналы данных
что-то мне это напомнинает, а впомнил, storm от твитера для евент процессинга, но
5) и, вероятно, принципиальная невозможность работы с потоковыми данными.
ЧТО??? О_о имея такую архитектуру не запилить работу с потоковыми данными, особенно на фоне хорошей парадигмы и либы Rx, да они наверное издеваются
6) в Hadoop свертка не может начаться пока все map-задания не будут окончены
верно, дальше на вашем слайде и в описании показано Speculative Execution, когда таск (map или reduce) запускается параллельно с уже имеющимся медленным таском в надежде выиграть время, фича доступна уже в первой версии хадупа.
7) Open-source лицензии, потому что это изначально другой тип продукта (но бесплатный доступ по академической лицензии все же есть);
ой да не смешите, какой другой тип продукта? хотя если вы имели в виду: «продукт для того, чтобы залочить кого на себе и стричь бабло», то тогда я полностью согласен, не тот это продукт.
8) Других заявлений про дальнейшую поддержку Dryad или, напротив, однозначный отказ от поддержки, на протяжении прошлого (2012) и этого года замечено не было.
ага, то есть слов и действий: «для больших вычислений мы будем использовать хадуп, ради того чтобы его под виндой запускать в azure мы даже неплохо бабла отвалим hortonwork» уже недостаточно, чтобы решить что продукт издох. Раз есть devel-preview которая неподдерживается и сорцов нету, то считаем проект живым. Нет, ну неужели вы это серьезно? Имеющиеся (но не доказанные) внедрения на фоне остановки развития продукта вызывают лишь жалость к тем, кто залочился на данном продукте, а соскочить не может.
Сколько раз уже можно повторять: Hadoop — это не MapReduce + HDFS, Hadoop — это ЭКОСИСТЕМА.
так что: ДА, по характеристикам Dryad устарел лет на 10
Если вас обидело то, что я назвал «настройку рабочего места» админским таском, то извините, я приводил пример «первой помощи» и сам понимаю, что это не работа настоящего администратора.
По поводу клауда, сюда уже примешался ответ на реплику выше, с которой не совсем согласен:
>> Если не брать в расчёт корпорации с гигантской инфраструктурой, то программисты прекрасно обходятся сами, а с консьюмеризацией технологий и распространением облачных сервисов потребность в администраторах будет уменьшаться.
>> а о том, что есть вещи, в которых разработчики редко разбираются хорошо (да и не должны, в общем-то),
Вот именно что не должны зачастую, для этого и возникают профессии на стыке технологий. Админ и программист — это ортогональные отрасли, одно не исключает другого, но часто бывает, что и не дополняет.
мой пример показывает «первую помощь», а не админские таски.
с настройкой iptables вы вообще пошутили, java программист может написать и полностью оттестировать свое веб приложение разрабатывая на винде + локальном tomcat, а запустить его могут и на линухе (iptables) и на фряхе или солярисе (ipfw), теперь предлагаете каждому веб девелоперу еще и админские курсы проходить по всем системам? а еще есть нюанс, что написанное десктопное приложение под винду при желании можно автоматом продеплоить в группу через AD, так что давайте и его в обязательную программу включим.
iptables и друзья это уже реальная работа админа и я только рад, что эта область тоже развивается, те кто говорят что админы исчезнут из-за появления облаков и paas забывают одну простую вещь: чтобы эти облака появились и работали корректно, за ними стоят хорошие группы как программистов, так и админов на обслуживании. Сложность никуда никогда не исчезает, просто она уходит на другой уровень.
build engineer это в данный момент одно из популярных направлений развития администраторов, devops другое, в обоих этих направлениях человек это уже не просто админ или программист, это смесь знаний разработки и знаний администрирования (смешать в пропорциях нужных для задачи, но не взбалтывать). но продолжают существовать и чистые администраторы, и я не вижу ничего плохого когда человек концентрируется на одном «как сделать хороший продукт», а вопросы «нужно посмотреть чтобы на диске было место, проверить после деплоя разерешение на запись в папки, настроить master-slave на базе, настроить iptables на доступ только ограниченным портам и nginx для кеширования статики» оставить профессионалам
>> Или прямой доступ к памяти для них нечто невероятное
вы сходу ответите различия между ETL vs ELT vs OLTP? или вопросы оптимизации базы данных (DBA)?
другие занимаются web и не сталкиваются ни с большими объемами, ни в ручным управлением памяти, у них задача стоит в корректной верстке и быстроте загрузки страницы (уменьшить количество запросов на сервер, оптимизировать css чтобы меньше раз пробегало по дереву и тд)
третий занимается распределенными системами, стоят вопросы надежности, балансировки нагрузки и тд
четвертый работает на embedded с c/c++ & asm и пошлет лесом всех вышестоящих после слов javascript, database, dht, у него другие задачи.
Но самое главное: каждый из них может набросать какой простейший скрипт если нужно, вот сложнее в чужую область никто не полезет, но другим ВСЕГДА будет говорить «А вы разве не знали _подставить_по_вкусу_…? Это же каждый школьник должен знать, не говоря уже про программиста»
вот посмотришь, в древнем мире и даже в средние века были лекари, один лекарь и все дела
а теперь развели всяких специальностей: хирурги, психиатры, педиатры
любое развитие отрасли и усложнение ее заставляет все больше развиваться специализации, это нормальный процес
у них обоих есть расширения для индексации 2d и 2dSphere координат, выборка в итоге достаточна шустрая, без лишних телодвижений
1) составить по крайней мере базовое представление о компании
2) составить базовое представление о людях и уровне их квалификации
3) засветиться самому (то что вас текущий проект не устроит еще ни о чем не говорит, может оказаться что очень скоро у них откроется действительно интересная для ВАС позиция и они уже будут знать куда обращаться), имеется несколько хороших контактов после таких общений
4) проверить в первую очередь свою самооценку (на рынке хватает как тех кто завышенно о себе думает, так и тех кто действительно что-то знает, но боится показать это)
да, это все относится когда не ты сам напрашиваешься на собеседование, а тебя приглашают и сразу все понимают и приглашают в первую очередь «познакомиться».
>> адовое собеседование на 2 часа
ну были у меня и по 3 часа, когда техническое из базовых вопросов постепенно перетекает в общее обсуждение техник и подходов разработки и инструментов. К этому моменту собеседование обычно превращается в локальный обмен опытом, в процессе которого ты для себя открываешь кое-что новое, но и собеседующим можешь рассказать тоже много полезного.
для того и спонсоры чтобы покрыть разницу в бюджете между билетами проданными и стоимостью организации
вопрос в том, что для некоторых с учетом билетов и жилья стоимость конференций получается отнють не такой какая она стоит на сайте, а можно смело суммарные траты умножать на 5 от стоимости билета и брать отпуск/отгулы на 2-3 дня минимум
покупать записи за стоимость участия это вообще больше попахивает бредом, а со скидкой следуя вашей логике продавать тоже не стоит
С одной стороны интересная конференция, с другой в апреле-мае пройдут java one, javaee, jpoint, где доклады частично пересекаются, на все не съездишь если ты не в питере-москве живешь, а так хоть видео можно было бы посмотреть тех докладов которые не видел.
А вот что необходимо, так это:
1) принципы map-reduce и итеративных алгоритмов
2) ну и действительно инструменты:
hadoop для batch обработки, доп инструменты для него hive и pig
storm и spark для реалтайм процессинга,
druid и impala для реалтаймовых выборок с sql подобным синтаксисом
то что перечислено в статье это обертки, которые можно использовать для того чтобы агрегировать потоки данных от приложений и последующей простой визуализации, а следовательно и целевая аудитория отнють не «программист, работающий с Big Data», а «разработчик приложений (в основном мобильных), которое может генерировать потоки данных, а сам разработчик не знает куда их залить и что с ними можно сделать»
в итоге переписано все на чистую java (почти полный копипаст, так как в большем уже все отлажено было) и прямо в xml процесса указываем какие хэндлеры дергать, производительность увеличилась более чем на порядок.
несколько jvm это действительно уход от проблемы, но сроки поджимали и нужно было предоставить отчеты сколько может держать сервис и что проблемы со скоростью у проекта выше по стеку
а под БП я понимал jbpm и два.
Для нагрузочного тестирования уже приходилось пару раз подымать независимые jmeter, так как бывало что подвисали отдельные треды, несколько jmeter с меньшим количеством потоков работали хорошо.
Имеется:
1. jboss jbpm (количество воркеров больше 30ки)
2. бизнес процесс в котором некоторые состояния и условия написаны на BeanShell
3. пару тысяц процессов на выполнение
Вопрос: где будет затык?
Оказалось, что в BeanShell, но отнють не скорость его работы как «интерпретатора», так как жизненный цикл скрипта выглядит примерно так:
1. берем скрипт
2. разбираем и компилим его в валидный class файл
3. отправляем на выполнение
и вот пункт 2 оказывается проходит через синглтон, то есть выполнение еще можно в несколько потоков, а вот компилироваться у вас будет в 1 поток, а остальные будут стоять курить.
Так что сам BeanShell быстрый, а вот большое количество разнородных небольших скриптов положит ваше нагрузочное тестирование в 2 счета.
по поводу впарить — не согласен
пускай я там и не долго, но на оба проекта которые мне понравились я прошел,
третий сейчас в замороженном состоянии, так как заказчик сам не знает полностью требования, но отношения уже у нас сложились неплохие.
Если под «впаривать» вы понимаете грамотное сопроводительное письмо с примерным объяснением как вы уже сразу понимаете проект и что будете делать чтобы проект закончился успешно, при необходимости сразу уточняете некоторые скользкие вопросы, то в моем понимании это «хороший тон», а не впаривание. Да и заказчики относятся к таким соискателям на порядок лучше, чем к тем кто нажимает «принять» и одна фраза «усё буде у лучшем виде, ты только плати»
Возможно если заниматься сугубо фрилансом будут заметны и другие стороны, но пока я просматриваю проекты которые мне интересны с точки зрения изучения новых технологий или поковыряться в качестве хобби, так как текущее рабочее место меня полностью устраивает =)
слишком агрессивное настроение чувствуется по отношению к ней.
По поводу утверждений, что это всего-лишь набор апачевских проектов, а сами они ничего не делали, вы не правы:
1. Flume — система для event процессинга, зародилась в cloudera и позже отдана в инкубатор апача
2. Hue — удобная веб обвязка поверх хадупа, пига и хайва, также зародилась в cloudera и отдана в инкубатор
3. Sqoop — система для синхронизации-переливки данных между хадупом (файлы на хдфс, хайв, пиг, хбэйс) и обычными реляционками, вплоть до создания схемы, зародился и развивался в cloudera и отдан в инкубатор
Дополнительно в пределах cdh3 или cdh2 вы имеете полную совместимость своих джобов и работу без проблем, в мире hadoop с этим большая проблема, особенно когда версии выпускают часто и какая активная сказать никто не может, а стоит выйти новой версии разработчики забивают на предыдущие. Для миграции между версиями имеются исчерпывающие мануалы. Cloudera же вливает гигантское количество багфиксов в виде бэкпорта в свои продукты, так же имеются бэкпорты отдельных улучшений из следующих нестабильных версий в существующие стабильные. Все наработки по хадуповскому стеку открыты, бери и скачивай в сорцах, изменяй и пересобирай. Исключением является консоль управления, но она появилась когда была уже версия cdh3, причем была уже не первый месяц. Так что я бы рассматривал Cloudera в качестве RedHat для рынка hadoop решений. Один из ведущих разработчиков Todd Lipcon работает у них, все направления развития и новинки в тестировании и достижении хадупа как платформы очень четко просматриваются в его твитере.
Использовал cdh2 и cdh3, их стабильность по сравнению с ванильным хадупом это было что-то, сравнивать с cdh4 не берусь так как ушел с того проекта, но сомневаюсь в том, что Cloudera выпустила сырой продукт на рынок, уж слишком они серьезно подходят к делу, да и не жалеют отдавать свои наработки в открытый доступ.
Чем же будет Hortonworks еще покажет время, активность у них неплохая, но слишком молоды еще.
А вообще в мире BigData для меня выделяются:
1. hadoop — cloudera
2. cassandra — datastax