Является ли Hadoop хорошим решением для небольших данных?

Question

У нас есть набор данных в MongoDB, что мы уменьшаем карту (в два раза), мы собираемся использовать карту Mongo на данный момент, но я думаю о том, как масштабировать и улучшать производительность в будущем, и я думаю о Hadoop.

Большая часть материала, который я читаю о Hadoop, рассказывает о больших данных, терабайтах материала, когда мы собираемся иметь дело с мегабайтами, 10 с, может быть, 100 тысяч тысяч записей. (Возможно, многие из них работают одновременно, хотя одна задача - небольшая сумма может быть большой).

Мы действительно хотим получить безумную производительность из небольших данных, а не делать большие данные. т. е. получить карту, уменьшающую результаты, которые занимают 10 секунд в MongoDB, чтобы занять секунды или секунды в Hadoop.

Возможно ли это?
Действительно ли Hadoop подходит для этого?
Если нет других технологий, которые сделают это возможным?

Детали точной задачи это необходимо для и моего решения на сегодняшний день, можно найти в этом вопросе: Linear funnel from a collection of events with MongoDB aggregation, is it possible?

Answer 1

Возможно ли это?

NO. Независимо от того, насколько малы ваши данные, всегда будет какая-то начальная задержка при выполнении заданий MR, вызванных тем, что много вещей происходит под капотом, например, проверка путей ввода/вывода, создание сплитов, создание карты и т. Д. И это неизбежно.

Является ли Hadoop подходящим для этого?

NO. Вы не можете ожидать, что Hadoop даст вам результаты на нано или несколько миллисекунд.

Если нет других технологий, которые сделают это возможным?

Если вам нужно что-то очень быстро, и которые хорошо масштабируется лучше взглянуть на Storm.

Answer 2

Большая часть материала, который я читаю о Hadoop, рассказывает о больших данных, терабайтах материала, когда мы собираемся иметь дело с мегабайтами, 10 с, может быть, 100 тысяч тысяч записей.

Одна из вещей, которая дает ему скорость, - это способности кластера с помощью Map Reduce, такие вещи, конечно же, применимы только к «Большим данным» (что бы это ни означало сейчас).

Фактически сокращение карты обычно медленнее, чем скажем, структура агрегации на небольших данных из-за того, сколько времени требуется, чтобы фактически запустить среднюю карту.

Сокращение карты действительно предназначено для чего-то другого, кроме того, что вы делаете.

Вы можете изучить ваши данные в традиционной базе данных и использовать инфраструктуру агрегации баз данных, то есть SQL или MongoDB.

Answer 3

Hadoop не выполнит ваши требования. Первыми вещами являются требования к инфраструктуре и ее администрирование.Стоимость работы с уменьшением карты будет больше на hadoop, чем на Mongo или на другие аналогичные технологии, если ваши данные в MB.

Кроме того, я хотел бы предложить расширить существующую инфраструктуру mongoDB. Гибкие возможности запросов и документов (например, легкие индексы и извлечение данных) не могут быть достигнуты благодаря технологиям Hadoop.

Answer 4

Hadoop 'в целом' движется в направлении обработки с меньшей задержкой, например, через проекты, например, Tez. И есть альтернативы, похожие на хаос, например Spark.

Но для обработки событий, как правило, это означает, что в будущем может быть будущее, см. Storm and Hadoop: Convergence of Big-Data and Low-Latency Processing (см. Также slideshare from Hadoop Summit).

Hadoop - это обширная экосистема. Существуют огромные различия в возможностях между старыми (1.0), новыми (1.3) и краем кровотечения (2.0 и выше). Могут ли некоторые из этих технологий заменить собственный M/R Mongo? Я, конечно, так думаю. Может ли ваша проблема быть разделена на множество параллельных задач (это на самом деле не ясно для меня)? Тогда где-то между Spark/YARN/Tez есть решение, которое пойдет быстрее, поскольку вы бросаете в него больше аппаратных средств.

И, конечно же, за что первый рабочий набор в одном хост-памяти всегда будет многопроцессорные РСУБД, которые будут работать круги вокруг кластеров ...