Всем хорош продукт кроме идиотского названия.

Таки не понял, а что эта «платформа для обработки больших объемов данных» делает то?

Ссылка на подробности у меня что-то пока не может открыться.

http://ru.wikipedia.org/wiki/MapReduce

а раньше что было?

добавлены функции sync и flush, необходимые для поддержки журнала транзакций

Для Ъ: раньше не было транзакционности, или раньше она обеспечивалась другими средствами?

Для Ъ: раньше не было транзакционности, или раньше она обеспечивалась другими средствами?

Я тут не большой специалист, но помоему HBase идет с кучей патчей для ядра Hadoop, которые надо накладывать чтобы его завести. Понемногу эти патчи переходят в ядро

Мне на собеседовании в гугле мужик сказал, что hadoop имеет слишком большой оверхед. Они реализовали MapReduce другим способом на одной машине и получили выигрыш перед кластером из нескольких hadoop-машин.

Сам использовал hadoop пару лет назад на работе. Ничего не могу сказать объективно - замерами не занимался, с альтернативами (в том числе какими-либо самописными) не сравнивал.

Тяжелое тормозное поделие со страшными исходниками.

О. теперь гуглить не надо. Спасибо.

а какие ему альтернативы из доступных?

Тяжелое тормозное поделие со страшными исходниками.

аминь

mongodb? А, вообще, от задач зависит

Riak (erlang+c+js), MongoDB (c/c++) и ещё дюжина под разные задачи. Для того, чтобы выполнить на них hello-world не надо бежать в магазин за новыми планками RAM.

имхо это все для разного класса задач

У хадупа и софта, который на нём завязан, есть фундаментальное отличия от всех остальных:

- Хреновая интерактивность выполнения задач. К примеру поднять что-то типа живого поиска на hadoop/hbase нереально даже на среднебольшом объеме данных. Поиск в «личных сообщениях» на фейсбуке тому живое доказательство. Хадупота годится для изолированных задач на жабе, т.е. для мелких поисковых задач, которые не ставит клиент сервиса в реальном времени. Остальные (riak, mongo и т.д.) можно притянуть, а жабу - нет.

- просто невероятная распиаренность.

ну так оно и есть - hadoop это пакетная обработка больших данных, аналитика и т.п. Riak и mongodb на таких объемах и запросах просто не будут работать.

Поиск на FB это мимо кассы - там, по крайней мере раньше, работала Cassandra

3) сорцы некурябельны. Комментов нет. И помнится поймал себя на мысли, что первые 10 тысяч строк кода - это абстрактные фабрики по генерации абстрактных фабрик. Т.е. ничего по делу а уже мегабайты кода. Сорцы - лучшая документация, но с хадупом в этом плане не фортануло.

Там полный фарш с версиями, в т.н. сообществе полный бардак и борьба за влияние.

Недавно тут вышел Hadoop 0.22, который является продолжением 0.21 (на 0.21 в свое время многие подсели). До этого громко и пафосом вышел 0.23, основанный на совершенно другом движке (YARN или MR2). Жутко глючная вещь. Теперь вот, в конце года, появился 1.0, получившейся, по сути, простым переименованием ветки 0.20.*.

То есть имеем три активные версии. Если добавить еще CHD3u2 (очень популярный дистрибутив от Cloudera), который основан на 0.20 + бэкпорты из 0.21 - получим 4. Вся соль в том, что все эти версии не очень то совместимы даже на уровне API, о бинарной совместимости даже заикаться не стоит. Подобрать к этому зоопарку нужную версию HBase с патчами - вообще целое искусство. Дистрибутив от Clouder'ы нельзя запустить под Windows, вообще никак. Остальные можно (Cygwin), но они как-то странно падают через день.

Так что если все так будет продолжаться, то проект можно хоронить. Самое обидное, что свободных альтернатив нет. Все остальное либо полная труха или немного не то (например всем советую GridGain - отличная вещь).

Еще немного раздражает road map - им нужны рекорды, кластеры по 50000 машин и т.д. У меня, как и у существенного числа пользователей, кластер на 5-10 машин. В такой конфигурации Hadoop имеет немалый overhead и врожденные проблемы, которые достаточно просто решить, но всем пофиг.

hadoop это пакетная обработка больших данных, аналитика и т.п. Riak и mongodb на таких объемах и запросах просто не будут работать.

Они работают на ещё бОльших объемах после небольшого допиливания. В Riak есть флаг pre-reduce для сверхбольших объемов данных, в mongodb - свои костыли.

Cassandra

Да, смотрел её. Пустая база и примитивный запрос выполнялись от 150 мс на 4-ядернике. Она фактически труп, твиттер вроде свалиливает с неё, фейсбук уже свалил. Вообще непонятно для чего она развивается.

Не очень согласен. По моим наблюдениям там 60% полного говнокода, остальное очень даже неплохо написано. Другое дело, что сорцы читать сложно, так как о едином стандарте кодирования разработчики, видимо, совсем не слышали. Основная проблема в том, там много архитектурных костылей и просчетов.

Они работают на ещё бОльших объемах после небольшого допиливания. В Riak есть флаг pre-reduce для сверхбольших объемов данных, в mongodb - свои костыли.

Да ну, особенно про mongo что-то не верится. Есть success stories?

Да, смотрел её. Пустая база и примитивный запрос выполнялись от 150 мс на 4-ядернике. Она фактически труп, твиттер вроде свалиливает с неё, фейсбук уже свалил. Вообще непонятно для чего она развивается.

Так Cassandra ж multi-master с поддержкой работы при разрыве между узлами кластера. Кому такое надо у тех и выбора особо нет (фактически выбор между Cassandra, Voldemort и Riak) , а кому нет тем и не надо.

Twitter ее юзает, но для весьма специфических задач.

Hadoop прежде всего для совершенно других вещей. Ни о каком real-time, конечно, речи быть не может. Например, у меня в reducer'е для каждого ключа могут получаться списки по 10Гб данных. Никакой MongoDB со своим JavaScript такой объем не переварит, так как тупо грузит все в память.

Мне на собеседовании в гугле мужик сказал

Как тебя, нубца, туда занесло?

Меня, нубца, туда занесло через приглашение от них. Позвонили, письмо написали - приходи, нубец, стрелять тебя колотить, к нам на собеседование.

Да, можно гвозди микроскопом заколачивать, а потом говорить, что молоток лучше.

Реальные бесплатные альтернативы hadoop в области пакетной обработки терабайтов и петабайтов данных есть ?

Интересно, зачем Амазону Hadoop с поддержкой СУБД Hbase, если они используют Oracle Database? Или нужно читать «поддерживает в_том_числе СУБД Hbase»? Просветите ламера.

Меня, нубца, туда занесло через приглашение от них. Позвонили, письмо написали - приходи, нубец, стрелять тебя колотить, к нам на собеседование.

Не томите душу. Взяли? Хотя вряд ли, ибо таким светилам как Google Employee чисто взападло пастись на всяких там ЛОРах. Они свое ЧСВ теребят другими способами.

Там полный фарш с версиями, в т.н. сообществе полный бардак и борьба за влияние.

Да, знатный зоопарк:

http://www.cloudera.com/blog/2012/01/an-update-on-apache-hadoop-1-0/

Поиск на FB это мимо кассы - там, по крайней мере раньше, работала Cassandra

Вроде как раз касандра там никогда не использовалась, они сразу hbase начали юзать http://highscalability.com/blog/2010/11/16/facebooks-new-real-time-messaging-...

Вообще-то ее в фейсбуке и начали писать, потом от нее отказались

Я в курсе

альтернативы?

Тяжелое тормозное поделие со страшными исходниками.

Это говорит человек сравниваюший Hadoop с MongoDB? )


Hadoop - это быстрое, очень хорошо документированное решение для обработки больших объемов информации к которой можно применить map reduce.

Его не нужно применять для online processing.

Например, то что без map reduce в одной крупной медиа компании отчет на oracle делал более 12 часов, на кластере (всего 5 машин со скромной конфигурацией) на Hadoop делается за 3 часа.

Прелесть Hadoop в том, что он талерантен к сбоям оборудования, вы можите использовать для кластера самые обычные машины (только namenode должен быть надежным), мы например рассматриваем вариант использовать linux машины разработчиков в ночное время для ускорения обсчетов.

Yahoo использует кластеры >1000 машин для своих задач.
Хороших альтернатив для обработки данных такого объема нет.

Мы в кассандра видео храним. Скорость вставки 20мб /c. Разумеется видео вставляется фреймами, 12 в сек нормально, но и эмулировали вставку 1000 объектов по 64 байта - заняло около 1 с. Так что не все так страшно, мистер.