Avisos do Apache HBase no Azure HDInsight

Este artigo descreve vários avisos para ajudá-lo a otimizar o desempenho do Apache HBase no Azure HDInsight.

Otimizar o HBase para ler os dados gravados mais recentemente

Se o seu caso de uso envolve a leitura dos dados escritos mais recentemente do HBase, este aviso pode ajudá-lo. Para alto desempenho, é ideal que as leituras do HBase sejam servidas a partir de memstore, em vez do armazenamento remoto.

O aviso de consulta indica que, para uma determinada família de colunas numa tabela, > 75% das leituras são atendidas de memstore. Este indicador sugere que, mesmo que aconteça uma descarga no memstore, o arquivo recente precisa ser acessado e isso precisa estar em cache. Os dados são primeiro gravados em memstore, e o sistema depois acede os dados recentes lá. Há uma chance de que os threads internos do flusher HBase detetem que uma determinada região atingiu o tamanho de 128M (padrão) e possam acionar um flush. Este cenário acontece até mesmo com os dados mais recentes que foram escritos quando o memstore tinha cerca de 128 milhões de tamanho. Portanto, uma leitura posterior destes registos recentes pode exigir uma leitura de arquivo em vez de a partir de memstore. Portanto, é melhor otimizar para que até mesmo os dados recentes que foram liberados recentemente possam residir no cache.

Para otimizar os dados recentes em cache, considere as seguintes definições de configuração:

1. Defina hbase.rs.cacheblocksonwrite como true. Essa configuração padrão no HDInsight HBase é true, portanto, verifique se ela não foi redefinida para false.

2. Aumente o hbase.hstore.compactionThreshold valor para evitar que a compactação ocorra. Por predefinição, este valor é 3. Você pode aumentá-lo para um valor mais alto como 10.

3. Se você seguir a etapa 2 e definir compactionThreshold, mude hbase.hstore.compaction.max para um valor mais alto, por exemplo 100, e também aumente o valor da configuração hbase.hstore.blockingStoreFiles para um valor mais alto, por exemplo 300.

4. Se tiver certeza de que precisa ler apenas os dados recentes, defina hbase.rs.cachecompactedblocksonwrite a configuração como ON. Essa configuração informa ao sistema que, mesmo que a compactação aconteça, os dados permanecem em cache. As configurações também podem ser definidas a nível familiar.

   No Shell do HBase, execute o seguinte comando para definir a configuração hbase.rs.cachecompactedblocksonwrite.

   alter '<TableName>', {NAME => '<FamilyName>', CONFIGURATION => {'hbase.hstore.blockingStoreFiles' => '300'}}
   

5. O cache de blocos pode ser desativado para uma família específica em uma tabela. Certifique-se de que está ativado ON para as famílias que têm as leituras de dados mais recentes. Por padrão, o cache de blocos é ativado para todas as famílias em uma tabela. Caso tenha desativado o cache de bloco para uma família e precise ativá-lo, utilize o comando alter do shell hbase.

   Essas configurações ajudam a garantir que os dados estejam disponíveis em cache e que os dados recentes não sofram compactação. Se um TTL for possível em seu cenário, considere o uso da compactação em camadas de data. Para obter mais informações, consulte Apache HBase Reference Guide: Date Tiered Compaction

Otimize a fila de descarga

Este aviso indica que as descargas de HBase podem necessitar de ajustes. A configuração atual para os controladores de descarga pode não ser suficiente para gerir o tráfego de escrita, o que pode levar a uma lentidão nas operações de descarga.

Na interface do utilizador do servidor de região, observe se a fila de esvaziamento ultrapassa 100. Esse limite indica que as descargas estão lentas e você pode ter que ajustar a hbase.hstore.flusher.count configuração. Por padrão, o valor é 2. Certifique-se de que o número máximo de threads do flusher não aumente além de 6.

Além disso, veja se tem uma recomendação para otimização da contagem de regiões. Se sim, sugerimos que experimente o ajuste da região para ver se isso ajuda em descargas de dados mais rápidas. Caso contrário, ajustar os fios do flusher pode ajudá-lo.

Ajuste da contagem de regiões

O aviso de ajuste de contagem de regiões indica que o HBase bloqueou atualizações e a contagem de regiões pode ser maior do que o tamanho de heap suportado idealmente. Você pode ajustar o tamanho da pilha, o tamanho de memstore, e a contagem de regiões.

Como cenário de exemplo:

• Suponha que o tamanho da pilha para o servidor de região é de 10 GB. Por padrão, o hbase.hregion.memstore.flush.size é 128M. O valor padrão para hbase.regionserver.global.memstore.size é 0.4. O que significa que, dos 10 GB, 4 GB são alocados para memstore (globalmente).

• Suponha que haja uma distribuição uniforme da carga de gravação em todas as regiões, e supondo que cada região cresça apenas até 128 MB, então, o número máximo de regiões nesta configuração é 32 regiões. Se um determinado servidor de região estiver configurado para ter 32 regiões, o sistema evitará melhor o bloqueio de atualizações.

• Com essas configurações em vigor, o número de regiões é 100. O global memstore de 4 GB está agora dividido em 100 regiões. Assim, efetivamente, cada região recebe apenas 40 MB para memstore. Quando as gravações são uniformes, o sistema faz flushes frequentes e tamanho menor da ordem < de 40 MB. Ter muitos fios de descarga pode aumentar a velocidade hbase.hstore.flusher.countde descarga.

O aviso significa que seria bom reconsiderar o número de regiões por servidor, o tamanho da pilha e a configuração de tamanho global memstore, juntamente com o ajuste dos threads de esvaziamento para evitar que as atualizações sejam bloqueadas.

Ajuste da fila de compactação

Se a fila de compactação do HBase crescer para mais de 2000 e acontecer periodicamente, você poderá aumentar os threads de compactação para um valor maior.

Quando há um número excessivo de ficheiros para compactação, tal situação pode levar a uma maior utilização da heap associada à maneira como os ficheiros interagem com o sistema de ficheiros do Azure. Por isso, é melhor concluir a compactação o mais rápido possível. Às vezes, em clusters mais antigos, as configurações de compactação relacionadas ao controlo podem resultar numa taxa de compactação mais lenta.

Verifique as configurações hbase.hstore.compaction.throughput.lower.bound e hbase.hstore.compaction.throughput.higher.bound. Se já estiverem definidos para 50M e 100M, mantenha-os como estão. No entanto, se você definiu essas configurações para um valor mais baixo (o que era o caso com clusters mais antigos), altere os limites para 50M e 100M, respectivamente.

As configurações são hbase.regionserver.thread.compaction.small e hbase.regionserver.thread.compaction.large (os padrões são 1 cada). Limite o valor máximo para esta configuração para ser inferior a 3.

Verificação completa da tabela

O aviso de verificação de tabela completa indica que mais de 75% das verificações emitidas são verificações de tabela/região completas. Você pode revisitar a maneira como seu código chama as verificações para melhorar o desempenho da consulta. Considere as seguintes práticas:

• Defina corretamente a linha de início e fim para cada varredura.

• Use a API de MultiRowRangeFilter para poder consultar intervalos diferentes numa única chamada. Para obter mais informações, consulte a documentação da API MultiRowRangeFilter.

• Nos casos em que você precisa de uma verificação completa de tabela ou região, verifique se há a possibilidade de evitar o uso de cache para essas consultas, para que outras consultas que usam o cache não possam remover os blocos que estão quentes. Para garantir que as verificações não usem cache, use a API de verificação com a opção setCaching(false) em seu código:

  scan#setCaching(false)
  

Próximos passos

Otimize o Apache HBase usando Ambari