>> Для UDF используется Jython. Это может ограничить в использовании некоторых библиотек.
наглая ложь, как и для hive все пишется на любом языке который поддерживается jvm, ограничений нету
дополнительно в режиме стриминга hive может гонять данные в любою прилагу которая читае из stdin и пишет в stdout (HDInsight от майкрософта так и работает, только через стриминг на c# можно писать задачи) ссылка на офф доку
lateral view
не помню сильно удобной конструкции в термнах PIG, все остальные агрегаты и тд есть и Hive
к тому же даже кубинг в Hive запилили уже и оконные функции, в пиге до сих пор их нету
Вообще по производительности Pig всегда немного отставал, у Hive был чуть более шустрый оптимизатор запросов, на какое-то время вышли на паритет, но тут вышел на сцену Tez и Project Stinger.
С ORC есть проблемы, так как его только в hive пока можно использовать, хотя в JIRA уже и висит тикет по причесыванию его интерфейса к вменяемому виду, чтобы можно было и из других систем использовать. ORC vs Parquet на данный момент больше холиварный вопрос чем практичный, пока в проде нету статистики кто лучше, так как у них схожести больше чем различий.
>> Рассмотрим это на гипотетическом примере, близком к мобильному маркетингу. Допустим, что есть группа пользователей, из которых 5000 — пользователи iOS, а 10000 — Android. Средняя конверсия составляет 5%: 4% для iOS и 5,5% для Android. Согласитесь, что менеджер по продукту на основе этих данных может принять вполне конкретные решения …и совершить ошибку.
итого 200 ios vs 550 android, андроид пользователей почти в 3 раза больше, и где же тут ошибка менеджера?
>> Initiated in 2009, the NSF-sponsored ASTERIX project has been developing new technologies for ingesting, storing, managing, indexing, querying, and analyzing vast quantities of semi-structured information.
Копирайт во всех файлах тоже от 2009 года.
>> так что не понимаю такое обилие критики
Позиционироваться как открытое решение и держать закрытой google группу с обсуждением как-то у меня не вяжется. Конечно можно запросить приглашение и тд, но иногда хочется сразу посмотреть/погуглить, а уже потом думать связываться или нет, тут же этот сценарий не подходит.
Основная разработка идет несколькими людьми из университетов, разработка больше похожа на «мы вот тут пилим крутую хрень», вся суть в том, что без попыток регулярных прогонов в продакшене все эти разработки так и остаются крутыми на бумаге, попытка запуска в реальном проде сразу подымает пачку нестандартных проблем. Я только рад таким проектам и желаю им удачи, но практика показывает, что большинство университетских начинаний умирает так и не дожив до реального внедрения, хотя идеи которые они обкатывают потом растаскиваются по проектам с большим удовольствием. Конечно есть исключения, но их очень мало, и буду рад если этот проект попадет в их число.
А критика идет в первую очередь на ваш необоснованный оптимизм ;)
>> И совершенно нормальная схема работы паралельной СУБД — генерим один мастер-план запроса, затем раздаем его на кластер, каждый работает отдельно, выполняя физические операторы
ключевым в моей фразе было: «построило псевдо-AST, дальше начинаем интерпретацию этого AST»
добавим сюда ложку полиморфизма (мы же пишем унифицированные функции и тд) и на выходе получаем случай, когда сама работа с диском/сетью отходит на второй план, а основное время кушается cpu в попытке разобраться «что и откуда» надо считать, как это проинтерпретировать и куда потом сложить.
>> По тем же бенчам видно — Shark часто забивает Impala.
против Spark ничего не имею, наоборот только хорошие отзывы, но для структурируемых данных все-таки лучше sql-like решения, ну просто потому что для этого уже есть люди. А shark это попытка прозрачно заменить бекенд для hive с map-reduce на spark. попытка более-менее удачная, но еще не стабилизированна.
ParAxel — платный продукт, Vertica или Neteeza тоже платные с некислой такой ценой. Если уж очень хочется, то сюда можно еще докинуть Teradata и Exadata (Oracle), они тоже молотят со свистом данные, но ценник еще выше.
>> AsterixDB такую-же мощь принесет в мир JSON, но не сразу, естественно.
MemSQL — обещаний вагон было, на практике это шардинг, если пытаться делать join 2х таблиц и результирующий датасет не влазит в память, то запрос обвалится. Ответ одного из разрабов: «да, запрос упадет, но ведь это не главное, главное что сервер продолжит работать». В итоге заявки про процессинг терабайт на нем вызывает улыбку.
NuoDB — обещание acid и всего что только можно, терабайты данных, оптимизации. На практике когда дошло до тестов, то сами разработчики разводили руками от такой «производительности».
MongoDB — заявления о терабайтах и масштабируемости (несколько сотен гигабайт, в принципе нормальный объем), но вот вам 2 сценария:
1) добавляем машинку в реплика сет, данные переливаются на нее за 15 минут, следующие 4 часа строим ПОСЛЕДОВАТЕЛЬНО все индексы на 1 ядре
2) добавляем машинку в шардинг, было 2 шарда по 150гб, ожидем что будет 3 по 100гб. ожидаем… СУТКИ, потому что перелив чанков идет ну просто ужасно медленно, для исключения излишней нагрузки на отдающие машинки.
Поэтому любые заявления о том что «X такую-же мощь принесет в мир Y, но не сразу, естественно» вызывают лишь улыбку, пускай сразу принесут, а уже потом начинают пиарится.
А слабоструктурированное хранение и выборку, так уже давно можно в поле запихать целиком json, а во время аналитики раскладывать это по нужным колонкам (hive,impala,shark уже давно это умеют, просто еще один storage format), а если уж совсем припрет, то одна строка может несколько строк породить в выход.
( cwiki.apache.org/confluence/display/Hive/LanguageManual+LateralView )
Так же почему-то упускают тот же couchbase, он в качестве value хранит json, через view можно и join сделать, хотя конечно к производительности к нему тоже есть претензии.
>> Шардинг они уже сделали, осталось сделать репликацию, что не так долго должно занять.
Проект уже 5 лет развивается, начиная с 2009, я понимаю что разработка базы данных это не в носу ковыряться, но и про быстро не верю.
MongoDB первый выпуск 2009, cassandra 2008, про другие open source решения для аналитики я вообще молчу, они на фоне этого продукта по возрасту вообще дети.
>> Сам храню порядка 50GB, но для сложных «аналитических» запросов.
аналитика зачастую подразумевает неизменяемые данные, тут вам что-то вроде presto (facebook) или impala (cloudera) нужна, вот они не в теории, а на практике уже очень неплохо масштабируются.
>> Движок Hyracks намного эффективнее Hadoop, на TPC-подобном бенче на 2 порядка быстрее, так что полетит.
о да, я даже знаю с чем сравнивали. Hive? =) У хадупа основной проблемой является постоянное насилование диска после map и reduce фаз, а значит построить нормальный join и тд сложно, но со второй версии map-reduce уже не прибит гвоздями, поэтому можно нормальный DAG реализовывать. tez.incubator.apache.org/
По коду AsterixDB местами ужас-ужас (классы устанешь читать название в десяток слов), в работе запросы напоминают hive (заливаем на hdfs xml с планом запроса, каждая нода затянула в себя и построило псевдо AST, дальше начинаем интерпретацию этого AST, все вроде и работает, но работает не сильно шустро). Скорость запросов на больших объемах неплохая у presto и impala, так как первая генерирует байткод для jvm, а вторая llvm псевдокод который компилится прямо в рантайме.
В момент когда бенчмарки обретут нормальный вид, для примера как здесь amplab.cs.berkeley.edu/benchmark/
то можно будет заявлять о превосходстве в скорости выполнения запросов, а до этого…
Конечно это db больше для аналитики, а не для постоянных update как в обычной базе данных, но тогда без отказоустойчивости она вообще пока совсем сырая.
в общем пока у нее не видно четкого позиционирования:
1) отказоустойчивость и масштабирование — монга и кассандра, ну или коучбейз
2) скорость аналитики — импала и престо
3) целостность транзакций — обычный реляционки
если я что-то пропустил, то прошу указать
и еще вопрос: у нас есть таблица, мы запускаем выборку с аналитикой, в этот момент происходит обновления некоторых полей. Что будет у меня в выборке?
с sql я знаю, что получу, так как там есть транзакции
с системами аналитики тоже знаю, так как данные неизменяемы
нет, ну если уж беретесь троллить hadoop, то хоть подойдите правильно:
1) почему bunzip2, а не какой snappy
2) pbzip2 — а где тесты для хадупа с данным кодеком
3) а почему только wc прогнали, который к cpu совсем не требователен, давайте уже что-то действительно интересно и побольше
4) а какие настройки у хадуп кластера и код для MapReduce (получили стандатную конфигурацию с 2мя мэперами на ноду и 512mb по памяти)?
a) компресия вывода map перед reduce снижает нагрузку на диск
б) reuse jvm позволяет избавится от необходимости поднимать на каждый task по новому процессу
в) простейший work count из примеров для того и служит, чтобы показать пример кода, но уж никак не может служить бенчмарком, так как не оптимален по самое немогу, добавляем в пример этап combine и резко получаем неплохой буст, так как практически под ноль снижаем запись на диск после мэперов и трафик между мэпером и редьюсером тоже минимален
p.s. пихать хадуп везде смысла нету, так же и map-reduce не является идеальным алгоритмом, но если уж начинать какую-то технологию троллить, то надо для начала в ней разобраться хорошенько, иначе могут помидорами закидать на простейших
Просто на днях ковырял AceSctream так как хотел настроить телевизору iptv (на свою голову взял Phillips, а там с этим ой как туго если сравнивать с Samsung или LG) и решение мне показалось очень даже интересным, по мере погружения в их архитектуру и форум настроение все больше падало.
Вот только AceStream до сих по не осилил сборку под mac (разработчики уже больше года кормят обещаниями «скоро»), а у автора «дома имеется полный стек продуктов от яблочной компании». К тому же сомневаюсь, что яблочная приставка сумеет воспроизвести поток на телевизор, так как acestream состоит из 3х частей:
1) engine — занимается p2p комуникацией
2) web-plugin — как раз плагин к браузеру
3) player — плейер на основе vlc
в итоге чтобы скормить другим плейерам или как iptv люди занимаются извратом из разряда:
1) поставили engine
2а) поставили какой AceProxy который это все заворачивает в нормальный HttpSream
2б) написали свою обертку для отдачи на нужное устройство
Итого: автор за 10 мин расковырял прилагу и смотрел на 34" каналы, вы предлагаете ему технологию которая на mac os не работает в принципе.
p.s. идеи у acestream может и хорошие, но вот на форуме иногда возникает странное чувство дежавю, больше всего их попытки продвижения и маркетинг напоминают MicroSoft «главное впарить, а пользователь пускай сам разбирается, а если что-то не поддерживаем, то пользователь сам дурак».
Для «мини кластер» имеется demo vm: скачал, запустил, тестируй
На данный момент это идеальный вариант для тех кто хочет просто посмотреть на свежую версию хадупа и пощупать ее.
Каждый кто работал с хадупом знает, что кластер для разработки и для продакшена должен иметь хоть немного похожие машинки, в противном случае про разные извращения с оптимизацией придется забыть, в идеале это 2 одинаковых кластера, в худшем случае у вас такие же машинки, но их меньше. Кластер в виртуалбоксах на одной машине это из разряда фантастики, в этом случае 1 demo-vm c максимум ресурсов.
И зачем нам очередной оферхед от docker?
Особенно если учесть, что для разделения ресурсов внутри ноды cgroup можно использовать (в стандартной поставке уже все идет, 1 параметр в конфигах врубает его).
vargant это вообще в другую степь вас занесло.
для одного клика уже давно придуман Whirr: whirr.apache.org/
для тех кто хочет на голом железе разворачивать более удобным будет: cloudera manager & apache ambari
1) Несмотря на то, что в интернете на иностранных ресурсах есть полно материала про настройку/развертывание Hadoop, большинство из них либо описывают настройку ранних версий (0.X.X и 1.X.X)…
что клоудера уже давно hdfs 2.0 использует, а недавно и yarn по умолчанию включила,
что хортоны свою hdp-2.0 строят на второй ветке.
Пускай вас не пугает некоторая мешанина в версиях, обе эти компании являются наиболее активными разработчиками хадупа и в свои продукты бекпортят патчи которые шли еще только в альфу 2.x ветки. Если патч стабилен и является bugfix, то нечего ждать выхода 2.2.0, у клиентов проблемы и надо их решать.
2) Здесь параметр dfs.replication задает количество реплик, которые будут хранится на файловой системе. Оно не может быть больше, чем количество узлов в кластере.
да без проблем можно поставить сколько угодно много, например при создании har архивов по умолчанию в коде явно забито 20 реплик на индекс. Максимум что вы получите если узлов меньше чем уровень репликации, так это сообщение о том что некоторые блоки не дотягивают то установленного уровня репликации.
3) На каждом узле кластера изменим значения параметра dfs.replication в etc/hadoop/hdfs-site.xml
если вы не собираетесь запускать (именно из консоли конкретной машинки) задачи с тех машинок, то параметр бесполезен, так как нужен в первую очередь для namenode.
p.s. cloudera & hortonwork уже давно предоставляют как rpm со своими репозиториями для быстрого разворачивания кластера, так и автоматические тулзы cloudera manager и ambari соответсвенно. Использование ванильной сборки хадупа больше смахивает на мазохизм, так как крупные компании как раз и занимаются тем, что берут определенную версию и бекпортируют патчи из свежих разработок, а дальше предоставляют определенные гарантии, что ближайшие пару лет они будут вливать security fix в эти сборки и не менять api. Использую ванильную сборку вы получаете достаточно нестабильный продукт и полное отсутсвие поддержки, для примера оочень многие разработчики уже переключились на ветку 3.x, и патчи в 2.2.x попадут лишь очень избирательно, даже которые относятся к bugfix.
один я не понимаю зачем делать это:
«/dfs» поверх LVM на все доступные диски под хранение данных HDFS;
не проще все N дисков подмонтировать в /dfs/{1..N}?
это гарантирует сразу несколько вещей:
1) вылет одного диска вызовет замену только одного диска без перепроверки всего lvm
2) при обновлении хадупа на каждый диск запускается отдельный тред для проверки дискового формата, с lvm и единым разделом мы будем иметь 1 поток
Видели, знаем…
Ограничения: c/c++, windows (intel пиарился, что сделал поверх llvm свою имплементацию стандарта, вот только что-то по этому поводу мало данных)
Сухой итог: привязка к одной платформе и опять же необходимость написания jni обертки для java, а если и алгоритма нету, то пишем все руками + jni.
с++ amp можно лишь рассматривать как частичную более простую замену для CUDA/OpenCL, к java она отношения никакого не имеет.
p.s. если уж припрет сильно что-то посчитать, то с cuda хоть спотовые GPU инстансы у амазона можно взять по дешевке, с amp мы пролетаем, только за полную стоимость windows (дороже на порядок, т.е. в 10 раз).
AMD после первых же презентаций по скрещиванию APU и Java обещали открытие библиотеки в опенсорс, правда они больше показывали про HSA единую интеграцию, а aparapi на тот момент поддерживало только OpenCL. Aparapi в данный момент разрабатывают сотрудники AMD JavaLabs, основной разработчик Gary Frost ( a Software Engineer at AMD ). Нету такого, что открыли и забили, тут больше похоже на ситуацию, когда AMD наняла наиболее активных разработчиков открытых драйверов для видеокарт и теперь они уже на fulltime работают над теми же открытыми драйверами.
Поэтому сказать, что aparapi это ошибка и ее забросили я не могу, по моему мнению она более чем жива.
>> «как, я не могу использовать строки на GPU»
в HSA пускай и обрезанная, но поддержка строк имеется, другой вопрос, что не часто нам для вычислений нужны строки
А можно ссылки на то, где «Ничем хорошим это не закончилось.»?
Просто aparapi развивается достаточно активно, впиливают новые фичи и тд. Я согласен, что по сравнению с обычным OpenCL это достаточно большой оверхед, но всегда все идет на удешевление разработки, и в данном случае это оказывается оправдано.
Вариант 1: полностью согласен
Вариант 2: если уже готовый алгоритм есть, то можно и через jni дергать, проблема если его нету.
Но как-же вариант 3: хотим проверить теорию о том, что в нашем алгоритме gpu может иметь какой профит?
Нанимать c/c++ кодеров с хорошим знаинем CUDA/OpenCL дорого и к тому же усложняет коммуникацию внутри команды, добавляем сюда, что нанимать мы будем только на пару месяцев и увольняем если GPU нам не подходит. Сомнемаюсь что много найдется желающих рискнуть в этом случае. Библиотеки вроде aparapi позволяют набросать концепт сразу на java.
code.google.com/p/aparapi/
Спонируется amd
Компиляция java кода в нативный opencl kernel, дальше уже без разницы это nvidia, amd или вообще arm (вроде как уже запускали). В данный момент работают над поддержкой HSA, а значит открываются еще более широкие возможности по использованию arm soc и dsp. Есть поддержка lambda и java8.
rbcompiler.com/
Rootbeer
Те же яйца aparapi, только в профиль. Правда компиляция в код для opencl и cuda, местами смотрится лучше, местами хуже
openjdk.java.net/projects/graal/
Проект graal
Пишем jit компилер для java bytecode на самой java. В качестве бекендов в разработке компиляция в ptx, который уже потом уйдет в cuda.
В чем новость? в том что IBM сумели заюзать из java cuda и потаются на пару продавить очередной vendor lock-in?
Спасибо, не надо.
если кратко:
1) имеется процесс tasktracker
2) он периодически ломится на удаленную машинку за заданиями
3) на приходящий таск подымает отдельную jvm и выполняет там задание(таск)
4) грохает jvm от таска
так как каждый jobs состоит из большого количества tasks, то оптимально reuse уже поднятую jvm для всех заданий в пределах одного job, так как проблем с класпасом у нас точно не будет, но даже в этом случае сами разработчики предупреждают о потенциальных утечках ресурсов (если ваш код течет, то одно дело утечка в пределах одного таска, и совсем другое когда у вас пару сотен или тысяч тасков отработаться в пределах одной jvm).
Поэтому вопрос про то, как профайлили hadoop мне тоже был бы интересен.
Выбирая из двух зол «затягивание выпуска release-версий» vs «гарантия не выхода» я всегда выбираю первый пункт.
Инструмент должен решать ВАШУ поставленную задачу,
даже если он в бете, даже если на других задачах он падает, но решает ВАШУ конкретную задачу,
то я его беру и использую, так как это всегда лучше, чем оставить задачу без решения.
Приходилось и в Hive лезть сорцы и в Hadoop, когда на наших задачах были проблемы, но никто другой их в установленном бюджете решить не мог.
Архитектура Dryad местами интересна, но уже давно не уникальна.
Спасибо за материал, но задевает сам стиль подачи, когда вся информация несет заряд о том какой Dryad хороший и перспективный.
>> Pig — развертка агрегатов (FLATTEN)
cube
Windowing and Analytics Functions
к тому же перекинуть разработчиков-аналитиков с какой sql базы на большие объемы и hive будет проще, чем застравлять их учить hive и писать свои udf
наглая ложь, как и для hive все пишется на любом языке который поддерживается jvm, ограничений нету
дополнительно в режиме стриминга hive может гонять данные в любою прилагу которая читае из stdin и пишет в stdout (HDInsight от майкрософта так и работает, только через стриминг на c# можно писать задачи) ссылка на офф доку
lateral view
не помню сильно удобной конструкции в термнах PIG, все остальные агрегаты и тд есть и Hive
к тому же даже кубинг в Hive запилили уже и оконные функции, в пиге до сих пор их нету
Вообще по производительности Pig всегда немного отставал, у Hive был чуть более шустрый оптимизатор запросов, на какое-то время вышли на паритет, но тут вышел на сцену Tez и Project Stinger.
С ORC есть проблемы, так как его только в hive пока можно использовать, хотя в JIRA уже и висит тикет по причесыванию его интерфейса к вменяемому виду, чтобы можно было и из других систем использовать. ORC vs Parquet на данный момент больше холиварный вопрос чем практичный, пока в проде нету статистики кто лучше, так как у них схожести больше чем различий.
итого 200 ios vs 550 android, андроид пользователей почти в 3 раза больше, и где же тут ошибка менеджера?
Копирайт во всех файлах тоже от 2009 года.
>> так что не понимаю такое обилие критики
Позиционироваться как открытое решение и держать закрытой google группу с обсуждением как-то у меня не вяжется. Конечно можно запросить приглашение и тд, но иногда хочется сразу посмотреть/погуглить, а уже потом думать связываться или нет, тут же этот сценарий не подходит.
Основная разработка идет несколькими людьми из университетов, разработка больше похожа на «мы вот тут пилим крутую хрень», вся суть в том, что без попыток регулярных прогонов в продакшене все эти разработки так и остаются крутыми на бумаге, попытка запуска в реальном проде сразу подымает пачку нестандартных проблем. Я только рад таким проектам и желаю им удачи, но практика показывает, что большинство университетских начинаний умирает так и не дожив до реального внедрения, хотя идеи которые они обкатывают потом растаскиваются по проектам с большим удовольствием. Конечно есть исключения, но их очень мало, и буду рад если этот проект попадет в их число.
А критика идет в первую очередь на ваш необоснованный оптимизм ;)
ключевым в моей фразе было: «построило псевдо-AST, дальше начинаем интерпретацию этого AST»
добавим сюда ложку полиморфизма (мы же пишем унифицированные функции и тд) и на выходе получаем случай, когда сама работа с диском/сетью отходит на второй план, а основное время кушается cpu в попытке разобраться «что и откуда» надо считать, как это проинтерпретировать и куда потом сложить.
>> По тем же бенчам видно — Shark часто забивает Impala.
против Spark ничего не имею, наоборот только хорошие отзывы, но для структурируемых данных все-таки лучше sql-like решения, ну просто потому что для этого уже есть люди. А shark это попытка прозрачно заменить бекенд для hive с map-reduce на spark. попытка более-менее удачная, но еще не стабилизированна.
ParAxel — платный продукт, Vertica или Neteeza тоже платные с некислой такой ценой. Если уж очень хочется, то сюда можно еще докинуть Teradata и Exadata (Oracle), они тоже молотят со свистом данные, но ценник еще выше.
>> AsterixDB такую-же мощь принесет в мир JSON, но не сразу, естественно.
MemSQL — обещаний вагон было, на практике это шардинг, если пытаться делать join 2х таблиц и результирующий датасет не влазит в память, то запрос обвалится. Ответ одного из разрабов: «да, запрос упадет, но ведь это не главное, главное что сервер продолжит работать». В итоге заявки про процессинг терабайт на нем вызывает улыбку.
NuoDB — обещание acid и всего что только можно, терабайты данных, оптимизации. На практике когда дошло до тестов, то сами разработчики разводили руками от такой «производительности».
MongoDB — заявления о терабайтах и масштабируемости (несколько сотен гигабайт, в принципе нормальный объем), но вот вам 2 сценария:
1) добавляем машинку в реплика сет, данные переливаются на нее за 15 минут, следующие 4 часа строим ПОСЛЕДОВАТЕЛЬНО все индексы на 1 ядре
2) добавляем машинку в шардинг, было 2 шарда по 150гб, ожидем что будет 3 по 100гб. ожидаем… СУТКИ, потому что перелив чанков идет ну просто ужасно медленно, для исключения излишней нагрузки на отдающие машинки.
Поэтому любые заявления о том что «X такую-же мощь принесет в мир Y, но не сразу, естественно» вызывают лишь улыбку, пускай сразу принесут, а уже потом начинают пиарится.
А слабоструктурированное хранение и выборку, так уже давно можно в поле запихать целиком json, а во время аналитики раскладывать это по нужным колонкам (hive,impala,shark уже давно это умеют, просто еще один storage format), а если уж совсем припрет, то одна строка может несколько строк породить в выход.
( cwiki.apache.org/confluence/display/Hive/LanguageManual+LateralView )
Так же почему-то упускают тот же couchbase, он в качестве value хранит json, через view можно и join сделать, хотя конечно к производительности к нему тоже есть претензии.
>> Шардинг они уже сделали, осталось сделать репликацию, что не так долго должно занять.
Проект уже 5 лет развивается, начиная с 2009, я понимаю что разработка базы данных это не в носу ковыряться, но и про быстро не верю.
MongoDB первый выпуск 2009, cassandra 2008, про другие open source решения для аналитики я вообще молчу, они на фоне этого продукта по возрасту вообще дети.
аналитика зачастую подразумевает неизменяемые данные, тут вам что-то вроде presto (facebook) или impala (cloudera) нужна, вот они не в теории, а на практике уже очень неплохо масштабируются.
>> Движок Hyracks намного эффективнее Hadoop, на TPC-подобном бенче на 2 порядка быстрее, так что полетит.
о да, я даже знаю с чем сравнивали. Hive? =) У хадупа основной проблемой является постоянное насилование диска после map и reduce фаз, а значит построить нормальный join и тд сложно, но со второй версии map-reduce уже не прибит гвоздями, поэтому можно нормальный DAG реализовывать. tez.incubator.apache.org/
По коду AsterixDB местами ужас-ужас (классы устанешь читать название в десяток слов), в работе запросы напоминают hive (заливаем на hdfs xml с планом запроса, каждая нода затянула в себя и построило псевдо AST, дальше начинаем интерпретацию этого AST, все вроде и работает, но работает не сильно шустро). Скорость запросов на больших объемах неплохая у presto и impala, так как первая генерирует байткод для jvm, а вторая llvm псевдокод который компилится прямо в рантайме.
В момент когда бенчмарки обретут нормальный вид, для примера как здесь
amplab.cs.berkeley.edu/benchmark/
то можно будет заявлять о превосходстве в скорости выполнения запросов, а до этого…
Конечно это db больше для аналитики, а не для постоянных update как в обычной базе данных, но тогда без отказоустойчивости она вообще пока совсем сырая.
в общем пока у нее не видно четкого позиционирования:
1) отказоустойчивость и масштабирование — монга и кассандра, ну или коучбейз
2) скорость аналитики — импала и престо
3) целостность транзакций — обычный реляционки
если я что-то пропустил, то прошу указать
и еще вопрос: у нас есть таблица, мы запускаем выборку с аналитикой, в этот момент происходит обновления некоторых полей. Что будет у меня в выборке?
с sql я знаю, что получу, так как там есть транзакции
с системами аналитики тоже знаю, так как данные неизменяемы
1) почему bunzip2, а не какой snappy
2) pbzip2 — а где тесты для хадупа с данным кодеком
3) а почему только wc прогнали, который к cpu совсем не требователен, давайте уже что-то действительно интересно и побольше
4) а какие настройки у хадуп кластера и код для MapReduce (получили стандатную конфигурацию с 2мя мэперами на ноду и 512mb по памяти)?
a) компресия вывода map перед reduce снижает нагрузку на диск
б) reuse jvm позволяет избавится от необходимости поднимать на каждый task по новому процессу
в) простейший work count из примеров для того и служит, чтобы показать пример кода, но уж никак не может служить бенчмарком, так как не оптимален по самое немогу, добавляем в пример этап combine и резко получаем неплохой буст, так как практически под ноль снижаем запись на диск после мэперов и трафик между мэпером и редьюсером тоже минимален
p.s. пихать хадуп везде смысла нету, так же и map-reduce не является идеальным алгоритмом, но если уж начинать какую-то технологию троллить, то надо для начала в ней разобраться хорошенько, иначе могут помидорами закидать на простейших
Просто на днях ковырял AceSctream так как хотел настроить телевизору iptv (на свою голову взял Phillips, а там с этим ой как туго если сравнивать с Samsung или LG) и решение мне показалось очень даже интересным, по мере погружения в их архитектуру и форум настроение все больше падало.
1) engine — занимается p2p комуникацией
2) web-plugin — как раз плагин к браузеру
3) player — плейер на основе vlc
в итоге чтобы скормить другим плейерам или как iptv люди занимаются извратом из разряда:
1) поставили engine
2а) поставили какой AceProxy который это все заворачивает в нормальный HttpSream
2б) написали свою обертку для отдачи на нужное устройство
Итого: автор за 10 мин расковырял прилагу и смотрел на 34" каналы, вы предлагаете ему технологию которая на mac os не работает в принципе.
p.s. идеи у acestream может и хорошие, но вот на форуме иногда возникает странное чувство дежавю, больше всего их попытки продвижения и маркетинг напоминают MicroSoft «главное впарить, а пользователь пускай сам разбирается, а если что-то не поддерживаем, то пользователь сам дурак».
На данный момент это идеальный вариант для тех кто хочет просто посмотреть на свежую версию хадупа и пощупать ее.
www.cloudera.com/content/cloudera-content/cloudera-docs/DemoVMs/Cloudera-QuickStart-VM/cloudera_quickstart_vm.html
можно выбрать kvm,virtualbox,vmware образы.
>> то кластер создается для разработки
Каждый кто работал с хадупом знает, что кластер для разработки и для продакшена должен иметь хоть немного похожие машинки, в противном случае про разные извращения с оптимизацией придется забыть, в идеале это 2 одинаковых кластера, в худшем случае у вас такие же машинки, но их меньше. Кластер в виртуалбоксах на одной машине это из разряда фантастики, в этом случае 1 demo-vm c максимум ресурсов.
Особенно если учесть, что для разделения ресурсов внутри ноды cgroup можно использовать (в стандартной поставке уже все идет, 1 параметр в конфигах врубает его).
vargant это вообще в другую степь вас занесло.
для одного клика уже давно придуман Whirr: whirr.apache.org/
для тех кто хочет на голом железе разворачивать более удобным будет: cloudera manager & apache ambari
1) Несмотря на то, что в интернете на иностранных ресурсах есть полно материала про настройку/развертывание Hadoop, большинство из них либо описывают настройку ранних версий (0.X.X и 1.X.X)…
Вы наверное решили так пошутить?
www.cloudera.com/content/support/en/documentation.html#Documentation-CDH4Documentation
hortonworks.com/products/hdp-2/#documentation
что клоудера уже давно hdfs 2.0 использует, а недавно и yarn по умолчанию включила,
что хортоны свою hdp-2.0 строят на второй ветке.
Пускай вас не пугает некоторая мешанина в версиях, обе эти компании являются наиболее активными разработчиками хадупа и в свои продукты бекпортят патчи которые шли еще только в альфу 2.x ветки. Если патч стабилен и является bugfix, то нечего ждать выхода 2.2.0, у клиентов проблемы и надо их решать.
2) Здесь параметр dfs.replication задает количество реплик, которые будут хранится на файловой системе. Оно не может быть больше, чем количество узлов в кластере.
да без проблем можно поставить сколько угодно много, например при создании har архивов по умолчанию в коде явно забито 20 реплик на индекс. Максимум что вы получите если узлов меньше чем уровень репликации, так это сообщение о том что некоторые блоки не дотягивают то установленного уровня репликации.
3) На каждом узле кластера изменим значения параметра dfs.replication в etc/hadoop/hdfs-site.xml
если вы не собираетесь запускать (именно из консоли конкретной машинки) задачи с тех машинок, то параметр бесполезен, так как нужен в первую очередь для namenode.
p.s. cloudera & hortonwork уже давно предоставляют как rpm со своими репозиториями для быстрого разворачивания кластера, так и автоматические тулзы cloudera manager и ambari соответсвенно. Использование ванильной сборки хадупа больше смахивает на мазохизм, так как крупные компании как раз и занимаются тем, что берут определенную версию и бекпортируют патчи из свежих разработок, а дальше предоставляют определенные гарантии, что ближайшие пару лет они будут вливать security fix в эти сборки и не менять api. Использую ванильную сборку вы получаете достаточно нестабильный продукт и полное отсутсвие поддержки, для примера оочень многие разработчики уже переключились на ветку 3.x, и патчи в 2.2.x попадут лишь очень избирательно, даже которые относятся к bugfix.
«/dfs» поверх LVM на все доступные диски под хранение данных HDFS;
не проще все N дисков подмонтировать в /dfs/{1..N}?
это гарантирует сразу несколько вещей:
1) вылет одного диска вызовет замену только одного диска без перепроверки всего lvm
2) при обновлении хадупа на каждый диск запускается отдельный тред для проверки дискового формата, с lvm и единым разделом мы будем иметь 1 поток
Ограничения: c/c++, windows (intel пиарился, что сделал поверх llvm свою имплементацию стандарта, вот только что-то по этому поводу мало данных)
Сухой итог: привязка к одной платформе и опять же необходимость написания jni обертки для java, а если и алгоритма нету, то пишем все руками + jni.
с++ amp можно лишь рассматривать как частичную более простую замену для CUDA/OpenCL, к java она отношения никакого не имеет.
p.s. если уж припрет сильно что-то посчитать, то с cuda хоть спотовые GPU инстансы у амазона можно взять по дешевке, с amp мы пролетаем, только за полную стоимость windows (дороже на порядок, т.е. в 10 раз).
fix
AMD после первых же презентаций по скрещиванию APU и Java обещали открытие библиотеки в опенсорс, правда они больше показывали про HSA единую интеграцию, а aparapi на тот момент поддерживало только OpenCL. Aparapi в данный момент разрабатывают сотрудники AMD JavaLabs, основной разработчик Gary Frost ( a Software Engineer at AMD ). Нету такого, что открыли и забили, тут больше похоже на ситуацию, когда AMD наняла наиболее активных разработчиков открытых драйверов для видеокарт и теперь они уже на fulltime работают над теми же открытыми драйверами.
Поэтому сказать, что aparapi это ошибка и ее забросили я не могу, по моему мнению она более чем жива.
>> «как, я не могу использовать строки на GPU»
в HSA пускай и обрезанная, но поддержка строк имеется, другой вопрос, что не часто нам для вычислений нужны строки
Просто aparapi развивается достаточно активно, впиливают новые фичи и тд. Я согласен, что по сравнению с обычным OpenCL это достаточно большой оверхед, но всегда все идет на удешевление разработки, и в данном случае это оказывается оправдано.
Вариант 1: полностью согласен
Вариант 2: если уже готовый алгоритм есть, то можно и через jni дергать, проблема если его нету.
Но как-же вариант 3: хотим проверить теорию о том, что в нашем алгоритме gpu может иметь какой профит?
Нанимать c/c++ кодеров с хорошим знаинем CUDA/OpenCL дорого и к тому же усложняет коммуникацию внутри команды, добавляем сюда, что нанимать мы будем только на пару месяцев и увольняем если GPU нам не подходит. Сомнемаюсь что много найдется желающих рискнуть в этом случае. Библиотеки вроде aparapi позволяют набросать концепт сразу на java.
code.google.com/p/aparapi/
Спонируется amd
Компиляция java кода в нативный opencl kernel, дальше уже без разницы это nvidia, amd или вообще arm (вроде как уже запускали). В данный момент работают над поддержкой HSA, а значит открываются еще более широкие возможности по использованию arm soc и dsp. Есть поддержка lambda и java8.
rbcompiler.com/
Rootbeer
Те же яйца aparapi, только в профиль. Правда компиляция в код для opencl и cuda, местами смотрится лучше, местами хуже
openjdk.java.net/projects/graal/
Проект graal
Пишем jit компилер для java bytecode на самой java. В качестве бекендов в разработке компиляция в ptx, который уже потом уйдет в cuda.
В чем новость? в том что IBM сумели заюзать из java cuda и потаются на пару продавить очередной vendor lock-in?
Спасибо, не надо.
если кратко:
1) имеется процесс tasktracker
2) он периодически ломится на удаленную машинку за заданиями
3) на приходящий таск подымает отдельную jvm и выполняет там задание(таск)
4) грохает jvm от таска
так как каждый jobs состоит из большого количества tasks, то оптимально reuse уже поднятую jvm для всех заданий в пределах одного job, так как проблем с класпасом у нас точно не будет, но даже в этом случае сами разработчики предупреждают о потенциальных утечках ресурсов (если ваш код течет, то одно дело утечка в пределах одного таска, и совсем другое когда у вас пару сотен или тысяч тасков отработаться в пределах одной jvm).
Поэтому вопрос про то, как профайлили hadoop мне тоже был бы интересен.
после компиляции будет
в первом посте предложение про полное исключение созданий лишних объектов.
Инструмент должен решать ВАШУ поставленную задачу,
даже если он в бете, даже если на других задачах он падает, но решает ВАШУ конкретную задачу,
то я его беру и использую, так как это всегда лучше, чем оставить задачу без решения.
Приходилось и в Hive лезть сорцы и в Hadoop, когда на наших задачах были проблемы, но никто другой их в установленном бюджете решить не мог.
Архитектура Dryad местами интересна, но уже давно не уникальна.
Спасибо за материал, но задевает сам стиль подачи, когда вся информация несет заряд о том какой Dryad хороший и перспективный.