Рекомендации Apache HBase в Azure HDInsight

В этой статье описан ряд рекомендаций, помогающих оптимизировать производительность Apache HBase в Azure HDInsight.

Оптимизация HBase для чтения последних записанных данных

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

Рекомендации по запросу указывают на то, что для заданного семейства столбцов в таблице > 75 % запросов обрабатывается из memstore. Этот индикатор указывает на то, что даже если происходит сброс на memstore, недавно использованный файл должен быть доступен и находиться в кэше. Сначала данные записываются в систему memstore, после чего система обращается к последним данным. Есть вероятность, что внутренние потоки сброса HBase обнаружат, что для заданного региона достигнут размер 128 МБ (по умолчанию), и это может вызвать сброс. Этот сценарий происходит даже с самыми последними данными, записанными, когда размер memstore составлял около 128 МБ. Поэтому для последующего чтения последних записей может потребоваться чтение из файла, а не из memstore. Поэтому лучше оптимизировать процесс так, чтобы даже недавно очищенные данные могли оставаться в кэше.

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

  1. Задайте для параметра hbase.rs.cacheblocksonwrite значение true. Этот параметр по умолчанию в HDInsight HBase имеет значение true, поэтому убедитесь, что он не сброшен в false.

  2. Увеличьте значение hbase.hstore.compactionThreshold, чтобы избежать активации сжатия. По умолчанию это значение равно 3. Его можно увеличить до более высокого уровня, например 10.

  3. Если вы выполните шаг 2 и установите compactionThreshold, измените hbase.hstore.compaction.max на большее значение, например 100, а также увеличьте до более высокого уровня значение параметра конфигурации hbase.hstore.blockingStoreFiles, например до 300.

  4. Если вы уверены, что вам потребуется считывать только последние данные, установите для параметра конфигурация hbase.rs.cachecompactedblocksonwrite значение Вкл. Этот параметр сообщает системе, что даже в случае сжатия данные должны остаться в кэше. Параметры также можно задавать на уровне семейства.

    В оболочке HBase выполните следующую команду, чтобы задать параметр hbase.rs.cachecompactedblocksonwrite:

    alter '<TableName>', {NAME => '<FamilyName>', CONFIGURATION => {'hbase.hstore.blockingStoreFiles' => '300'}}

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

    Эти конфигурации помогают убедиться, что данные доступны в кэше и что последние данные не проходят сжатие. Если в вашем сценарии возможен TTL, тогда рассмотрите использование сжатия по уровням в зависимости от дат. Дополнительные сведения см. в справочном руководстве по многоуровневому сжатию в Apache HBase.

Оптимизация очереди на сброс данных

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

В пользовательском интерфейсе сервера регионов посмотрите, не превышен ли предельный размер очереди записи на диск, равный 100. Это пороговое значение указывает, что сбросы выполняются медленно, и, возможно, потребуется настроить конфигурацию hbase.hstore.flusher.count. По умолчанию его значение равно 2. Убедитесь, что максимальное число потоков записи на диск не превышает 6.

Кроме того, посмотрите, нет ли рекомендации по настройке количества регионов. Если да, мы рекомендуем попробовать настроить регион, чтобы узнать, помогает ли это ускорить очистку. В противном случае может помочь настройка потоков сброса.

Настройка числа регионов

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

Вот пример сценария:

  • Предположим, что размер кучи для сервера региона составляет 10 ГБ. По умолчанию значение hbase.hregion.memstore.flush.size равно 128M. Значение hbase.regionserver.global.memstore.size по умолчанию — 0.4. Это означает, что из 10 ГБ 4 ГБ выделяется memstore (глобально).

  • Предположим, что действует равномерное распределение нагрузки на запись для всех регионов, и тогда при условии, что каждый регион вырастет до 128 МБ, максимальное количество регионов в этой конфигурации — 32. Если для определенного сервера региона настроено 32 региона, системе лучше не блокировать обновления.

  • После установки этих параметров количество регионов составляет 100. Глобальный объем memstore 4 ГБ теперь разделен на 100 регионов. Таким образом, каждый регион получает только 40 МБ для memstore. Если операции записи выполняются равномерно, система регулярно выполняет запись на диск и уменьшает этот размер до < 40 МБ. При большом количестве потоков очистки скорость сброса данных hbase.hstore.flusher.count может увеличиться.

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

Настройка очереди сжатия

Если размер очереди сжатия HBase периодически превышает 2000, вы можете увеличить количество потоков сжатия.

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

Проверьте параметры hbase.hstore.compaction.throughput.lower.bound и hbase.hstore.compaction.throughput.higher.bound. Если они уже установлены на 50 млн и 100 млн, оставьте их без изменений. Однако если для этих параметров уже заданы меньшие значения (как было в случае со старыми кластерами), измените их на 50 млн и 100 млн соответственно.

Конфигурации — это hbase.regionserver.thread.compaction.small и hbase.regionserver.thread.compaction.large (значения по умолчанию — 1 каждое). Ограничьте максимальное значение для этой конфигурации так, чтобы оно было меньше 3.

Полное сканирование таблицы

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

  • Задайте правильную строку начала и окончания для каждой операции сканирования.

  • Используйте API MultiRowRangeFilter, чтобы выполнять запросы к различным диапазонам в одном вызове сканирования. Дополнительные сведения см. в документации по API MultiRowRangeFilter.

  • В тех случаях, когда требуется полное сканирование таблицы или области, проверьте, нельзя ли не задействовать для этих запросов кэш, чтобы другие запросы, которые его используют, не приводили к исключению из кэша активных блоков. Чтобы убедиться, что проверки не используют кэш, используйте API сканирования с параметром setCaching(false) в коде:

    scan#setCaching(false)

Следующие шаги

Оптимизация Apache HBase с помощью Ambari

  • Last updated on