Partilhar via

Resolver problemas de desempenho do Apache HBase no Azure HDInsight

  • Artigo

Este artigo descreve várias diretrizes e dicas de ajuste de desempenho do Apache HBase para obter o desempenho ideal no Azure HDInsight. Muitas dessas dicas dependem da carga de trabalho específica e do padrão de leitura/gravação/digitalização. Antes de aplicar alterações de configuração em um ambiente de produção, teste-as minuciosamente.

Insights de desempenho do HBase

Na maioria das cargas de trabalho do HBase, o principal estrangulamento está relacionado com o Registo de Escrita Prévia (WAL). Afeta seriamente o desempenho da escrita. O HDInsight HBase tem um modelo de computação de armazenamento separado. Os dados são armazenados remotamente no Armazenamento do Azure, mesmo que as máquinas virtuais hospedem os servidores de região. Até recentemente, a WAL também era gravada no Armazenamento do Azure. No HDInsight, esse comportamento amplificou esse gargalo. O recurso Gravações aceleradas foi projetado para resolver esse problema. Ele grava a WAL em discos gerenciados pelo SSD Premium do Azure. Isso beneficia tremendamente o desempenho de gravação e ajuda muitos problemas enfrentados por algumas das cargas de trabalho intensivas de gravação.

Para obter melhorias significativas nas operações de leitura, use a Conta de Armazenamento de Blob de Bloco Premium como seu armazenamento remoto. Esta opção só é possível se a funcionalidade WAL estiver ativada.

Compactação

A compactação é outro gargalo potencial que é fundamentalmente acordado na comunidade. Por predefinição, a compactação em maior escala está desativada nos clusters do HDInsight HBase. A compactação está desativada porque, embora seja um processo que consome muitos recursos, os clientes têm total flexibilidade para programá-lo de acordo com suas cargas de trabalho. Por exemplo, eles podem programá-lo fora do horário de pico. Além disso, a localidade de dados não é uma preocupação porque nosso armazenamento é remoto (apoiado pelo Armazenamento do Azure) em vez de para um Hadoop Distributed File System (HDFS) local.

Os clientes devem agendar uma grande compactação de acordo com sua conveniência. Se eles não fizerem essa manutenção, a compactação afetará negativamente o desempenho de leitura a longo prazo.

Para operações de varredura, latências médias muito superiores a 100 milissegundos devem ser motivo de preocupação. Verifique se a compactação principal foi programada com precisão.

Carga de trabalho do Apache Phoenix

Responder às seguintes perguntas irá ajudá-lo a entender melhor sua carga de trabalho do Apache Phoenix:

  • Todas as suas "leituras" estão traduzidas em digitalizações?
    • Em caso afirmativo, quais são as características destes exames?
    • Você otimizou seu esquema de tabela Phoenix para essas varreduras, incluindo indexação apropriada?
  • Você já usou a EXPLAIN instrução para entender os planos de consulta que suas "leituras" geram?
  • As suas gravações são "upsert-selects"?
    • Se assim for, eles também estariam fazendo exames. A latência esperada para exames é em média de aproximadamente 100 milissegundos, em comparação com 10 milissegundos para pontos obtidos na HBase.

Metodologia de teste e monitoramento de métricas

Se você estiver usando benchmarks como o Yahoo! Cloud Serving Benchmark, JMeter ou Pherf para testar e ajustar o desempenho, certifique-se de que:

  • As máquinas clientes não se tornam um gargalo. Para fazer isso, verifique o uso da CPU em máquinas cliente.

  • As configurações do lado do cliente, como o número de threads, são ajustadas adequadamente para saturar a largura de banda do cliente.

  • Os resultados dos testes são registados de forma precisa e sistemática.

Se suas consultas de repente começaram a fazer muito pior do que antes, verifique possíveis bugs no código do seu aplicativo. Está subitamente a gerar grandes quantidades de dados inválidos? Se for, pode aumentar as latências de leitura.

Problemas de migração

Se você estiver migrando para o Azure HDInsight, certifique-se de que sua migração seja feita de forma sistemática e precisa, de preferência por meio de automação. Evite a migração manual. Certifique-se de que:

  • Os atributos de tabela são migrados com precisão. Os atributos podem incluir como compressão, filtros bloom e assim por diante.

  • As configurações de salga nas tabelas Phoenix são mapeadas adequadamente para o novo tamanho do cluster. Por exemplo, o número de buckets de sal deve ser um múltiplo do número de nós de trabalho no cluster. E você deve usar um múltiplo que é um fator da quantidade de hot spotting.

Ajustes de configuração do lado do servidor

No HDInsight HBase, os HFiles são armazenados no armazenamento remoto. Quando há uma falha de cache, o custo das leituras é maior do que os sistemas locais, porque os dados em sistemas locais são apoiados pelo HDFS local. Para a maioria dos cenários, o uso inteligente de caches do HBase (cache de bloco e cache de bucket) foi projetado para contornar esse problema. Nos casos em que o problema não é contornado, usar uma conta blob de bloqueio premium pode ajudar esse problema. O driver de Blob de Armazenamento do Windows Azure depende de determinadas propriedades, como fs.azure.read.request.size buscar dados em blocos com base no que ele determina ser modo de leitura (sequencial versus aleatório), portanto, pode continuar a haver instâncias de latências mais altas com leituras. Através de experimentos empíricos, descobrimos que definir o tamanho do bloco de solicitação de leitura (fs.azure.read.request.size) para 512 KB e corresponder ao tamanho do bloco das tabelas HBase para ser do mesmo tamanho produz o melhor resultado na prática.

Para a maioria dos clusters de nós de grande porte, o HDInsight HBase fornece bucketcache como um arquivo em um SSD Premium local conectado à máquina virtual, que executa regionserverso . O uso de cache off-heap, em vez disso, pode fornecer algumas melhorias. Essa solução alternativa tem a limitação de usar a memória disponível e potencialmente ser menor do que o cache baseado em arquivo, portanto, nem sempre pode ser a melhor escolha.

A seguir estão alguns dos outros parâmetros específicos que ajustamos, e que pareciam ajudar em diferentes graus:

  • Aumente o memstore tamanho do padrão de 128 MB para 256 MB. Normalmente, essa configuração é recomendada para cenários de gravação pesada.

  • Aumente o número de threads dedicados para compactação, da configuração padrão de 1 para 4. Esta configuração é relevante se observarmos compações menores frequentes.

  • Evite bloquear memstore a descarga devido ao limite da loja. Para fornecer esse buffer, aumente a Hbase.hstore.blockingStoreFiles configuração para 100.

  • Para controlar as descargas, utilize as seguintes definições:

    • Hbase.regionserver.maxlogs: 140 (evita rubores devido aos limites de WAL)

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

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

  • Configurações específicas do Phoenix para ajuste do pool de threads:

    • Phoenix.query.queuesize: 10000

    • Phoenix.query.threadpoolsize: 512

  • Outras configurações específicas do Phoenix:

    • Phoenix.rpc.index.handler.count: 50 (se houver pesquisas de índice grandes ou muitas)

    • Phoenix.stats.updateFrequency: 1 hora

    • Phoenix.coprocessor.maxmetadatacachetimetolivems: 1 hora

    • Phoenix.coprocessor.maxmetadatacachesize: 50 MB

  • Tempos limite de RPC: 3 minutos

    • Os tempos limite de RPC incluem o tempo limite de RPC do HBase, o tempo limite do scanner do cliente HBase e o tempo limite de consulta Phoenix.
    • Certifique-se de que o hbase.client.scanner.caching parâmetro está definido para o mesmo valor na extremidade do servidor e na extremidade do cliente. Se eles não forem os mesmos, essa configuração levará a erros de fim de cliente relacionados ao OutOfOrderScannerException. Essa configuração deve ser definida como um valor baixo para varreduras grandes. Definimos esse valor como 100.

Outras considerações

A seguir estão parâmetros adicionais para considerar o ajuste:

  • Hbase.rs.cacheblocksonwrite – por padrão no HDI, essa configuração é definida como true.

  • Configurações que permitem adiar a compactação menor para mais tarde.

  • Configurações experimentais, como ajustar as porcentagens de filas reservadas para solicitações de leitura e gravação.

Próximos passos

Se o problema permanecer sem solução, visite um dos seguintes canais para obter mais suporte:

  • Obtenha respostas de especialistas do Azure através do Suporte da Comunidade do Azure.

  • Conecte-se com @AzureSupport. Esta é a conta oficial do Microsoft Azure para melhorar a experiência do cliente. Ele conecta a comunidade do Azure aos recursos certos: respostas, suporte e especialistas.

  • Se precisar de mais ajuda, você pode enviar uma solicitação de suporte do portal do Azure. Selecione Suporte na barra de menus ou abra o hub Ajuda + suporte . Para obter informações mais detalhadas, consulte Como criar uma solicitação de suporte do Azure. A sua subscrição do Microsoft Azure inclui acesso à gestão de subscrição e suporte de faturação, e o suporte técnico é fornecido através de um dos planos de suporte do Azure.