Как использовать HBase и Hadoop для обслуживания живого трафика и выполнения аналитики? (Один кластер против отдельных кластеров?)

Question

Наша основная цель - использовать Hadoop для аналитики.В этом случае мы выполняем пакетную обработку, поэтому пропускная способность важнее задержки, а это означает, что HBase не всегда подходит (хотя приближение к аналитике в реальном времени звучит привлекательно).Мы играем с Hive, и нам это нравится до сих пор.

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

Я прочитал много отчетов, и этоКажется, что большинство организаций предпочитают иметь отдельные кластеры для обслуживания трафика и для аналитики.Это кажется разумным выбором в целях стабильности, поскольку мы планируем, что многие люди будут писать запросы Hive, а плохо написанные запросы могут потенциально поставить под угрозу оперативные операции.

Теперь мой вопрос: как эти два разных варианта использованиявыверены (обслуживать живой трафик и выполнять пакетную аналитику)?Используют ли организации системы для записи всех данных в два независимых друг от друга кластера?Или это возможно сделать из коробки с одним кластером, в котором некоторые узлы обслуживают живой трафик, а другие - только аналитику?

Я думаю, что мы могли бы получить все поступающие данныев узлы, которые используются для обслуживания живого трафика, и пусть механизмы репликации HDFS управляют копированием данных в узлы, которые используются для аналитики (увеличение репликации выше, чем значение по умолчанию 3, вероятно, имеет смысл в таком сценарии).Hadoop может быть осведомлен о специальных сетевых топологиях, и у него есть функция, позволяющая всегда реплицировать хотя бы одну копию на разные стойки, так что, похоже, это хорошо согласуется с тем, что я описываю.

Узлы, выделенные для живого трафикаможно установить нулевое (или несколько) отображение и уменьшить количество слотов, чтобы все запросы Hive в конечном итоге обрабатывались узлами, выделенными для аналитики.

Узлы, выделенные для аналитики, всегда будут немного отставать от выделенных.к обслуживанию живого трафика, но это, похоже, не проблема.

Имеет ли такое решение смысл?Я думаю, что было бы проще иметь один кластер, чем два, но будет ли это значительно более рискованным?Известны ли случаи, когда компании использовали кластер HBase для обслуживания живого трафика, а также запускали на нем задания пакетной аналитики?

Мне бы хотелось узнать ваше мнение об этом :)!

Спасибо.

РЕДАКТИРОВАТЬ: А как насчет Бриск?Он основан на Cassandra вместо HBase, но, похоже, сделан именно для того, что я описываю (гибридные кластеры).Кто-нибудь работал с этим раньше?Зрел ли он?

- Феликс

Answer 1

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

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

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

Ничто не мешает вам иметь кластер HBase и кластер Hadoop на одной объединительной панели сети. Я предлагаю вместо использования гибридных узлов просто выделить несколько узлов для вашего кластера Hadoop, а некоторые - для вашего кластера Hbase. Передача по сети между ними будет довольно быстрой.

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

Answer 2

Я думаю, что такое решение может иметь смысл, поскольку MR в основном использует процессор, а HBASE - зверь, жаждущий памяти.Что нам нужно - это правильно организовать управление ресурсами.Я думаю, что это возможно следующим образом:
а) Процессор.Мы можем определить максимальное количество картографов / редукторов MR на слот, и, предполагая, что каждый картограф является однопоточным, мы можем ограничить потребление ресурсов процессора MR.Остальные перейдут на HBASE.
б) Память. Мы можем ограничить память для картографов и редукторов, а остальное отдать HBASE.
в) Я думаю, что мы не можем должным образом управлять разделением полосы пропускания HDFS, но я не думаю, что это должно быть проблемой для HBASE-потому что дисковые операции не находятся на критическом пути.