Поделиться через


Рекомендации 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.

    Эти конфигурации помогают убедиться, что данные доступны в кэше и что последние данные не проходят сжатие. Если в вашем сценарии реализован срок жизни, вы можете использовать сжатие по уровням в зависимости от дат. Дополнительные сведения см. в справочном руководстве по многоуровневому сжатию в 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