Существует способ дублирования данных таблицы на каждом узле кластера? Мне нужно выполнить тест производительности с максимальной степенью локальности данных. По умолчанию HBase распространяет данные на небольшой части узлов кластера (на 1 или 2 узла), возможно, потому, что мои данные не очень большие (~ 2 ГБ). Я знаю, что Hbase предназначен для гораздо больших наборов данных, но в этом случае это требование для меня.Дублирование таблицы Hbase
Есть много хорошо читает * о нем (см конец поста), но я постараюсь объяснить это своими словами;)
HBase не несет ответственности за репликацию данных, Hadoop HDFS, и по умолчанию настроен с коэффициентом репликации 3, то есть все данные будут храниться как минимум в 3 узлах.
местонахожденияданных является ключевым аспектом, чтобы получить хорошую производительность, но достижение максимальной локальности данных легко: вам нужно только colocate вашего Hbase Regionservers (RS), а также к Hadoop DataNodes (DN), поэтому, все ваши Д.Н. должен иметь также роль РС. После того, как вы это сделаете, HBase автоматически переместит данные там, где это необходимо (на крупные блокировки), чтобы достичь локальности данных, и это все, если каждый RS имеет данные регионов, которые он обслуживает локально, у вас будет локализация данных.
Даже если у вас есть данные, реплицированные на несколько DN, каждая область (и строки, которые они содержат) будет обслуживаться только одним RS, неважно, что у вас есть коэффициент репликации 3, 10 или 100 ... Чтение строки, принадлежащей к области # 1, всегда будет касаться одного и того же RS, и это будет тот, который размещает этот регион (который будет считывать данные локально из HDFS из-за локализации данных). Если RS хостинг этот регион идет вниз, регион будет присвоен другой RS автоматически (поскольку данные также реплицируются на другой DN)
Что вы можете сделать, это разделить таблицы, таким образом, каждый RS имеет даже ведра строк (областей), назначенных ему, так что как можно больше разных РС работает одновременно, когда вы читаете или записываете данные, увеличивая общую пропускную способность до тех пор, пока вы не всегда попадаете в те же регионы (так называемый серверный хотспоттер **)).
Таким образом, вы всегда должны начинать с обеспечения того, чтобы все регионы вашей таблицы были привязаны к разным RS, и они получают одинаковый объем запросов R/W. Как только вы это сделаете, вы можете разделить таблицу на несколько регионов один раз, пока у вас не будет четного количества регионов на всех РС вашего кластера (вам может потребоваться назначить их вручную, если вы не довольны балансировщиком нагрузки).
Просто напомните, что даже если у вас есть отличное распределение регионов, вы все равно можете иметь низкую производительность, если ваш шаблон доступа к данным неправильный (или он неравномерный) и не достигает всех регионов равномерно, в конце концов все зависит от вашего приложения.
(*) Рекомендуемый читает:
(**) Для того, чтобы избежать RS hotspotting мы всегда разрабатываем наши столы, чтобы иметь не монотонно возрастающей строки ключи, поэтому строки 1, 2, 3 ... N размещены в разных регионах, общий подход заключается в использовании идентификатора MD5 (id) + в качестве строки. Этот подход имеет собственный набор недостатков: вы не можете сканировать первые 10 строк, потому что они соленые.