Как стать автором
Обновить

Комментарии 11

Очень хочется прочитать статью про новый HDFS, и как в нём решена проблема с повышением доступности неймноды, научилась ли она жить в нескольких ДЦ.
Так вот же: hadoop.apache.org/docs/r2.0.2-alpha/hadoop-yarn/hadoop-yarn-site/HDFSHighAvailability.html

В двух словах, имеем две NameNode (active и standby) и общее хранилище, к которому они имеют доступ на чтение/запись. Таким общим хранилищем может быть директория где-нибудь в NFS. Все запросы клиентов идут на active NN, изменения пишутся в общее хранилище, их там подхватывает standby NN. Если active ломается, то standby становится active, перед этим применив все изменения из общего хранилища (если вдруг какие-то не были применены).
DataNode работает и с active, и с standby.
Ненене, про master-slave + nfs фейсбук ещё в прошлом году рассказывал, это не дело. Допустим, у меня 2, или лучше даже 3 ДЦ, хочу, чтобы всё (точнее, меня интересует хранение информации) работало при падении любого из ДЦ и при этом не помирало при несильном моргании сети.

Что-то я недавно слышал про master-master то ли в HDFS, то ли в HBase. Можете порассказывать про это? Я, к сожалению, не силён в экосистеме хадупа, поэтому сходу не знаю, где что искать и как оно должно называться.
master-master/cyclic есть в hbase, но это асинхронный процесс. идея в целом проста: все операции попдают в лог операций (HLog), по мере достижения определенных условий (время, размер) он ротируется и становится доступным для процесса репликации. это HLog передается в кластера-подписчики, которые применяют последовательно операции, сохраненные в этом HLog. Конфликты обновлений разрешаются просто по времени, т.к. это eventual система. Конечно, атомарные изменения будут работать только в пределах одного кластера, и при репликации превратяться в просто Put.
blog.cloudera.com/blog/2012/07/hbase-replication-overview-2/

HA Namenode сделана почти так-же, только nfs хранилище заменили системой из 3+ процессов JournalNode, которые обеспечивают две вещи:
1. Только один писатель в хранилище
2. Запись должна состояться на большинстве нод (quorum > N/2+1)
Остальное осталось без изменений, все так же NameNode две штуки, одна — active, другая — standby

Теоретически, можно попробовать поднять федерацию с 2-3 парами NN, где в каждом ДЦ приложения будут работать только со своей парой NN, а DN будут у них общие, но такое решение прозрачным не назовешь.
Ну и MapReduce в таком режиме работать без правок планировщика не будет, т.к. в ванильном MR нет прямой возможности запустить задачи только в текущем DC, задачи запустяться там, где есть данные. В итоге reduce фаза может начать обмениваться данными через медленный канал.
В MapR есть какая-то поддержка нескольких датацентров, но я не гуру в этом дистрибутиве.
Окто, уж ты то мог бы ножками дойти до нас с Евгением и рассказать :)
ааа… я еще смотрю, ник знакомый.
после нг дойду, щас в отпуске :)
Мне тут подсказали правильную ссылку — issues.apache.org/jira/browse/HDFS-3077
Кто нибудь уже пробовал?
Скажите, а как обстоят дела с быстротой? По-прежнему тратится куча времени на запуск задачи? Т.е. в реалтайме результаты нельзя получить?
Map-Reduce в принципе не предназначен для реалтайма. Гугл тоже это понимает и внутри себя они сделали Colossus. Если нужно именно моментально что-то обсчитывать — посмотрите в сторону twitter storm. Есть и другие похожие штуки, но всё оно основано на пайплайнах, по которым в реалтайме пробегают события-данные.
impala посмотрите.
это развитие hive, существенно быстрее работает.
(хотя еще сильно альфа)
Невозможно читать эти ^W.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории