Compartilhar via

Solucionar problemas de desempenho do Apache HBase no Azure HDInsight

  • Artigo

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

Insights de desempenho do HBase

O principal gargalo na maioria das cargas de trabalho do HBase é o WAL (log de gravação antecipada). Ele afeta seriamente o desempenho de gravação. O HBase do HDInsight tem um modelo de computação de armazenamento separado. Os dados são armazenados remotamente no Armazenamento do Azure, embora as máquinas virtuais hospedem os servidores de região. Até recentemente, o WAL também era gravado no Armazenamento do Azure. No HDInsight, esse comportamento amplificava tal gargalo. O recurso de Gravações Aceleradas foi projetado para resolver esse problema. Ele grava o WAL nos discos gerenciados SSD Premium do Azure. Isso beneficia enormemente o desempenho de gravação e ajuda em muitos problemas enfrentados por algumas das cargas de trabalho com uso intensivo de gravação.

Use a Conta do Armazenamento de Blobs de Blocos Premium como o seu armazenamento remoto. Essa opção só será possível se o recurso de WAL estiver habilitado.

Compactação

A compactação é outro gargalo potencial sobre o qual há um consenso fundamental na comunidade. Por padrão, a compactação principal é desabilitada em clusters HBase do HDInsight. A compactação é desabilitada porque, embora seja um processo de uso intensivo de recursos, os clientes têm total flexibilidade para agendá-lo de acordo com as respectivas cargas de trabalho. Por exemplo, eles podem agendá-lo fora do horário de pico. Além disso, a localidade dos dados não é uma preocupação porque nosso armazenamento é remoto (e o backup dele é feito no Armazenamento do Azure) em vez de para um HDFS (Sistema de Arquivos Distribuído do Hadoop) local.

Os clientes devem agendar a compactação principal conforme for mais conveniente para eles. Se eles não fizerem essa manutenção, a compactação afetará negativamente o desempenho de leitura a longo prazo.

Para operações de verificação, as latências médias muito maiores que 100 milissegundos são motivo de preocupação. Verifique se a compactação principal foi agendada com precisão.

Carga de trabalho do Apache Phoenix

Responder às seguintes perguntas ajudará você a entender melhor sua carga de trabalho do Apache Phoenix:

  • Todas as suas "leituras" estão sendo traduzidas para verificações?
    • Em caso afirmativo, quais são as características dessas verificações?
    • Você otimizou o esquema da tabela Phoenix para essas verificações, incluindo a indexação apropriada?
  • Você usou a instrução EXPLAIN para entender os planos de consulta gerados pelas suas "leituras"?
  • Suas gravações são "upsert-selects"?
    • Nesse caso, eles também fariam verificações. A latência esperada para verificações médias de aproximadamente 100 milissegundos, em comparação com dez milissegundos por obtenção de ponto no HBase.

Metodologia de teste e monitoramento de métricas

Se você estiver usando parâmetros de comparação como o Yahoo! Cloud Serving Benchmark, JMeter ou Pherf para testar e ajustar o desempenho, verifique se:

  • Os computadores cliente não se tornam um gargalo. Para fazer isso, verifique o uso da CPU em computadores 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 de teste são registrados de modo preciso e sistemático.

Se as suas consultas passaram a ter desempenho muito pior do que antes, verifique se há bugs em potencial no código do aplicativo. Ele gera repentinamente grandes quantidades de dados inválidos? Se a resposta é sim, as latências de leitura dele podem aumentar.

Problemas de migração

Se você estiver migrando para o Azure HDInsight, assegure-se de que sua migração seja feita sistematicamente e com precisão, preferencialmente por meio de automação. Evite a migração manual. Certifique-se de que:

  • Os atributos de tabela sejam migrados com precisão. Os atributos possam ser incluídos como compactação, filtros de bloom e assim por diante.

  • As configurações de salting em tabelas Phoenix são mapeadas adequadamente para o novo tamanho do cluster. Por exemplo, o número de buckets salt deve ser um múltiplo do número de nós de trabalho no cluster. E você deve usar um múltiplo que seja um fator da quantidade de pontos de acesso.

Ajustes de configuração no lado do servidor

No HBase do HDInsight, os HFiles são armazenados no armazenamento remoto. Quando há um erro de cache, o custo das leituras é maior do que os sistemas locais, pois o backup dos dados em sistemas locais é feito pelo HDFS local. Para a maioria dos cenários, o uso inteligente de caches do HBase (cache de blocos e cache de buckets) foi projetado para contornar esse problema. Nos casos em que o problema não é contornado, o uso de uma conta de blob de blocos Premium pode ajudar a mitigá-lo. O driver do Microsoft Azure Storage Blob depende de determinadas propriedades, como fs.azure.read.request.size para buscar dados em blocos com base no que ele determina como sendo o modo de leitura (sequencial versus aleatório), de modo que podem continuar existindo instâncias de latências mais altas com leituras. Por meio 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 fazer a correspondência do tamanho do bloco das tabelas do HBase para que ele seja do mesmo tamanho produz, na prática, o melhor resultado.

Para a maioria dos clusters de nó de tamanho grande, o HBase do HDInsight fornece bucketcache como um arquivo em um SSD Premium local que é anexado à máquina virtual, que executa regionservers. Alternativamente, o uso do cache off-heap pode fornecer algum aprimoramento. 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, de modo que nem sempre é a melhor opção.

Confira abaixo estão alguns dos outros parâmetros específicos que ajustamos, e isso pareceu ajudar em diferentes níveis:

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

  • Aumentar o número de threads dedicados para compactação, da configuração padrão de 1 para 4. Essa configuração será relevante se observarmos compactações secundárias frequentes.

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

  • Para controlar liberações, use as seguintes configurações:

    • Hbase.regionserver.maxlogs: 140 (evita liberações causadas por 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 de 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 grandes ou muitas pesquisas de índice)

    • Phoenix.stats.updateFrequency: 1 hora

    • Phoenix.coprocessor.maxmetadatacachetimetolivems: 1 hora

    • Phoenix.coprocessor.maxmetadatacachesize: 50 MB

  • Tempos limite de RPC: três minutos

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

Outras considerações

Devemos considerar ajustar os seguintes parâmetros adicionais:

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

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

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

Próximas etapas

Se você não encontrou seu problema ou não conseguiu resolvê-lo, visite um dos seguintes canais para obter mais suporte:

  • Obtenha respostas de especialistas do Azure por meio do Suporte da Comunidade do Azure.

  • Conecte-se ao @AzureSupport. Esta é a conta oficial do Microsoft Azure para aprimoramento da experiência do cliente. Ela se conecta à comunidade do Azure para os recursos certos: respostas, suporte e especialistas.

  • Se precisar de mais ajuda, poderá 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 assinatura do Microsoft Azure inclui acesso ao gerenciamento de assinaturas e ao suporte de cobrança, sendo que o suporte técnico é fornecido por meio de um dos Planos de suporte do Azure.