Hbase scan vs Mapreduce для вычислений на лету

Question

Hbase scan vs Mapreduce для вычислений на лету

1

Мне нужно вычислить совокупность по таблице HBase.

Скажем, у меня есть эта таблица hbase: 'metadata' Column family: M column: n

Здесь объект метаданных имеет список строк

метаданные класса {теги списка;

}

Мне нужно вычислить количество тегов, для которых я думал использовать либо использование mapreduce, либо сканирование по hbase напрямую.

Результат должен быть возвращен " на лету". Так какой я могу использовать в этом сценарии? Сканировать через hbase и вычислить совокупность или mapreduce?

Mapreduce в конечном счете собирается сканировать hbase и вычислять счет.

Каковы плюсы и минусы использования любого из них?

divyaravi 21 нояб. 2014, в 16:09

Источник

0

Определите «на лету».
nelsonda 25 нояб. 2014, в 20:06
0

Вычислять при вызове API, а не планировать работу.
divyaravi 03 дек. 2014, в 18:30

Теги:

java

performance

hadoop

hbase

mapreduce

1 ответ

Ещё вопросы

Вычислять при вызове API, а не планировать работу.

Rubén Moraleda · Accepted Answer · 2014-12-27T11-47-00.000Z

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

Начнем с того, что MapReduce - это запланированное задание самостоятельно, вы не сможете вернуть ответ "на лету", ожидайте, что Task Tracker не менее 15 секунд будет инициализировать задание.

В конце концов, MapReduce Job будет делать то же самое: сканирование HBase, разницу между выполнением сканирования в прямом направлении и MapReduce - это просто паралеллизация и локализация данных, что выделяется, когда у вас есть миллионы/миллиарды строк. Если вашим запросам требуется прочитать несколько тысяч последовательных строк для их агрегации, вы можете просто выполнить сканирование, и, вероятно, у него будет приемлемое время отклика, но для более крупных наборов данных это будет невозможно сделать во время запроса,

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

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