Устранение проблем с производительностью Apache HBase в Azure HDInsight

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

Анализ производительности HBase

Основным узким местом в большинстве рабочих нагрузок HBase является журнал упреждающей записи (WAL). Он серьезно влияет на производительность записи. В HDInsight HBase используется разделенная модель вычислений и хранилища. Данные хранятся удаленно в службе хранилища Azure даже несмотря на то, что региональные серверы размещены на виртуальных машинах. До недавнего времени данные WAL также записывались в службу хранилища Azure. В HDInsight это усугубляло описанное узкое место. Для решения этой проблемы предназначена функция ускоренной записи. Он записывает WAL на управляемые диски SSD (цен. категория "Премиум") Azure. Это очень сильно повышает производительность и помогает решать многие проблемы, с которыми сталкиваются некоторые рабочие нагрузки с интенсивными операциями записи.

Чтобы значительно повысить эффективность операций чтения, используйте в качестве удаленного хранилища учетную запись хранилища блочных BLOB-объектов категории "Премиум". Это возможно, только если включена функция WAL.

Сжатие

Еще одним потенциальным узким местом, признаваемым всем сообществом, является сжатие. По умолчанию масштабные операции сжатия в кластерах HDInsight HBase отключены. Сжатие отключено, поскольку несмотря на ресурсоемкость этого процесса клиенты могут абсолютно гибко планировать его в соответствии со своими рабочими нагрузками. Например, они могут назначить его на часы наименьшей нагрузки. Кроме того, локализация данных не представляет проблемы, так как хранилище является удаленным (на базе службы хранилища Azure), а не локальной распределенной файловой системой Hadoop (HDFS).

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

Для операций сканирования следует обращать внимание на среднее значение задержки, значительно превышающее 100 миллисекунд. Проверьте, правильно ли планируются масштабные операции сжатия.

Рабочая нагрузка Apache Phoenix

Лучше понять рабочую нагрузку Apache Phoenix помогут ответы на вопросы ниже.

• Все ли операции чтения превращаются в операции сканирования?
  • Если да, каковы характеристики этих операций сканирования?
  • Оптимизирована ли схема таблицы Phoenix для таких операций сканирования, включая соответствующую индексацию?
• Вы использовали инструкцию EXPLAIN, чтобы проанализировать планы запросов, создаваемые вашими операциями чтения?
• Являются ли ваши операции записи операциями верхней выборки?
  • Если да, то они также приводят к сканированию. Ожидаемая средняя задержка для операций сканирования составляет приблизительно 100 миллисекунд — по сравнению с 10 миллисекундами для точечных операций получения в HBase.

Метод тестирования и мониторинг метрик

Если вы используете для тестирования и настройки производительности такие эталоны, как Yahoo! Cloud Serving Benchmark, JMeter или Pherf, убедитесь в выполнении перечисленных ниже условий.

• Клиентские компьютеры не являются узким местом. Для этого проверьте загрузку ЦП на клиентских компьютерах.

• Параметры на стороне клиента, например количество потоков, настраиваются соответствующим образом, чтобы повысить пропускную способность клиента.

• Результаты тестов фиксируются точно и систематически.

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

Проблемы с миграцией

Если вы переходите на Azure HDInsight, проводите миграцию систематически и точно, желательно с помощью службы автоматизации. Старайтесь избегать миграции вручную. Убедитесь, что выполнены следующие условия:

• Атрибуты таблиц переносятся точно. Атрибуты могут включать параметры сжатия, фильтры Блума и т. д.

• Параметры добавления случайных данных ("соли") в таблицах Phoenix переносятся в соответствии с новым размером кластера. Например, число сегментов соли должно быть кратно количеству рабочих узлов в кластере. Также следует использовать множитель, который является коэффициентом интенсивности оперативного выявления.

Настройка параметров на стороне сервера

В HDInsight HBase файлы HFile хранятся в удаленном хранилище. При промахе кэша стоимость операций чтения выше, чем в локальных системах, так как данные в локальных системах находятся в локальной HDFS. В большинстве сценариев обойти эту проблему позволяет интеллектуальное использование кэшей HBase (кэш блоков и кэш контейнеров). В тех случаях, когда обойти проблему не удается, может помочь использование учетной записи блочных BLOB-объектов уровня "Премиум". Драйвер Azure Storage Blob для Windows использует определенные свойства, например fs.azure.read.request.size, для извлечения данных в блоках в зависимости от того, что он определяет как режим чтения (последовательного и случайного), поэтому при чтении могут продолжать возникать увеличенные задержки. Экспериментальным путем мы выяснили, что наилучший результат на практике дает установка размера блока для запросов чтения (fs.azure.read.request.size) на уровне 512 КБ и настройка для блока таблиц HBase того же размера.

Для большинства кластеров с узлами большого размера в HDInsight HBase доступен bucketcache в виде файла на локальном SSD (цен. Категория "Премиум"), подключенном к виртуальной машине, где работает regionservers. Добиться некоторого улучшения помогает использование кэша без кучи. С таким решением связано ограничение в виде доступной памяти, которая может быть меньше, чем файловый кэш, поэтому этот вариант не всегда является наилучшим выбором.

Ниже приведены некоторые другие параметры, которые мы настраивали и которые в разной степени доказали свою полезность.

• Увеличьте размер memstore с 128 МБ (по умолчанию) до 256 МБ. Как правило, этот режим рекомендуется использовать для сценариев с интенсивной записью.

• Увеличьте число потоков, выделенных для сжатия, со значения по умолчанию (1) до 4. Этот параметр важен, если часто выполняются небольшие операции сжатия.

• Старайтесь не блокировать запись memstore на диск из-за ограничения хранилища. Чтобы обеспечить этот буфер, увеличьте значение параметра Hbase.hstore.blockingStoreFiles до 100.

• Для управления сбросом на диск используйте следующие параметры.

  • Hbase.regionserver.maxlogs: 140 (предотвращение сброса из-за ограничений WAL)

  • Hbase.regionserver.global.memstore.lowerLimit: 0,55

  • Hbase.regionserver.global.memstore.upperLimit: 0,60

• Конфигурации пула потоков для Phoenix:

  • Phoenix.query.queuesize: 10000

  • Phoenix.query.threadpoolsize: 512

• Другие настройки для Phoenix:

  • Phoenix.rpc.index.handler.count: 50 (при большом числе операций поиска в индексе)

  • Phoenix.stats.updateFrequency: 1 час

  • Phoenix.coprocessor.maxmetadatacachetimetolivems: 1 час

  • Phoenix.coprocessor.maxmetadatacachesize: 50 МБ

• Значения времени ожидания RPC: 3 минуты

  • Значения времени ожидания RPC включают время ожидания RPC для HBase, время ожидания клиентского сканера HBase и время ожидания запроса в Phoenix.
  • Задайте для параметра hbase.client.scanner.caching одинаковое значение как на стороне сервера, так и на стороне клиента. Если они не совпадают, это приводит к ошибкам на клиенте, связанным с OutOfOrderScannerException. Для масштабных операций сканирования для этого параметра следует задать низкое значение. Мы установили его на уровне 100.

Другие замечания

Ниже приведены дополнительные параметры, которые также можно настроить.

• Hbase.rs.cacheblocksonwrite — по умолчанию для HDI этот параметр имеет значение true.

• Параметры, позволяющие отложить незначительные операции сжатия.

• Экспериментальные параметры, такие как настройка доли очереди (в процентах), зарезервированной для запросов на чтение и запись.

Дальнейшие действия

Если устранить проблему не удается, дополнительные сведения можно найти в одном из следующих источников:

• Получите ответы специалистов Azure на сайте поддержки сообщества пользователей Azure.

• Подключение с помощью @AzureSupport. Это официальная учетная запись Microsoft Azure для работы с клиентами. Благодаря ей сообщество Azure получает нужные ресурсы: ответы, поддержку и советы экспертов.

• Если вам нужна дополнительная помощь, отправьте запрос в службу поддержки на портале Azure. Выберите Поддержка в строке меню или откройте центр Справка и поддержка. Дополнительные сведения см. в статье Создание запроса на поддержку Azure. Доступ к средствам управления подписками и поддержка выставления счетов уже включены в вашу подписку Microsoft Azure, а техническая поддержка предоставляется в рамках одного из планов Службы поддержки Azure.