Рекомендации 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 ГБ для (глобально) выделяется memstore 4 ГБ.

  • Предположим, что действует равномерное распределение нагрузки на запись для всех регионов, и тогда при условии, что каждый регион вырастет до 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