Распределенная мультикарта на основе HBase и Hadoop MapReduce - PullRequest
Новая
       41

Распределенная мультикарта на основе HBase и Hadoop MapReduce

0 голосов
/ 28 марта 2012

Мне жаль, что я не очень хорошо понял HBase и Hadoop MapReduce, но я думаю, что вы можете помочь мне найти способ их использования, или, может быть, вы могли бы предложить необходимые мне фреймворки.

Часть I

Есть 1-й поток записей, которые я должен где-то хранить.Они должны быть доступны для некоторых клавиш в зависимости от них.Несколько записей могут иметь один и тот же ключ.Их довольно много.Я должен удалить старые записи по таймауту.

Есть также 2-й поток записей, который тоже очень интенсивный.Для каждой записи (аргумент-запись) мне нужно: получить все записи 1-го strem с ключом записи-аргумента, найти первую соответствующую запись, удалить ее из хранилища 1-го потока, вернуть результат ( res1 ) слияния этих двух записей.

Часть II

3-й поток записей похож на 1-й.Записи должны быть доступны по ключам (отличаются от описанных в части I).Несколько записей, как обычно, будут иметь один и тот же ключ.Их не так много, как в 1-м потоке.Я должен удалить старые записи по таймауту.

Для каждого res1 (аргумент-запись) я должен: получить все записи из 3-го strem с другим ключом этой записи, map эти записи, имеющие res1 в качестве параметра, уменьшают в результате.Записи 3-го потока должны оставаться неизмененными в хранилище.

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

Применимы ли HBase и Hadoop MapReduce в моем случае?И как должно выглядеть такое приложение (базовая идея)?Если ответ «нет», существуют ли рамки для разработки такого приложения?

Пожалуйста, задавайте вопросы, если вы не можете получить то, что я хочу.

1 Ответ

1 голос
/ 29 марта 2012

Я имею в виду технологии хранения данных. Внешние записи, принимающие записи, могут быть без сохранения состояния и, следовательно, легко масштабироваться.

У нас есть потоки записей, и мы хотим присоединиться к ним на лету. Некоторые из записей должны быть сохранены, почему некоторые (насколько я понял - 1-й поток) являются переходными.
Если мы берем масштабируемость и постоянство из уравнения - это можно реализовать в одном Java-процессе, используя HashMap для произвольно доступных данных и TreeMap для данных, которые мы хотим хранить отсортированными
Теперь давайте посмотрим, как это можно отобразить на технологии NoSQL, чтобы получить необходимую масштабируемость и производительность.
HBase распространяется отсортировано карта. Так что это может быть хорошим кандидатом для потока 2. Если мы использовали наш ключ в качестве ключа таблицы hbase - мы получим локальность данных для записей с тем же ключом.
MapReduce поверх HBase также доступен.
Поток 1 выглядит как временные данные с произвольным доступом. Я думаю, что не имеет смысла платить цену постоянства за эти записи - так должно распределяться в хэш-таблице памяти. Например: http://memcached.org/ Возможно элементом памяти будет список записей с тем же ключом.
Я до сих пор не уверен на 100% о требованиях к третьему потоку, но потребность во вторичном индексе (если он известен заранее) может быть реализована на уровне приложения как еще одна распределенная карта.
В двух словах - мое предложение выбрать HBase для данных, которые вы хотите сохранить, и сохранить отсортированные, а также рассмотреть несколько более легких решений для временных (но все еще достаточно больших) данных.

...