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 do , em vez do memstorearmazenamento remoto.

O aviso de consulta indica que, para uma determinada família de colunas em uma tabela, > 75% das leituras que estão sendo atendidas do memstore. Este indicador sugere que, mesmo que aconteça uma descarga no arquivo recente, o arquivo precisa ser acessado memstore e isso precisa estar em cache. Os dados são primeiro gravados para memstore o sistema acessa 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 desses registros recentes pode exigir uma leitura de arquivo em vez 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 entre em ação. 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 hbase.rs.cachecompactedblocksonwrite a configuração:

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

5. O cache de blocos pode ser desativado para uma determinada família em uma tabela. Certifique-se de que está ativado para as famílias que têm os dados mais recentes lidos. Por padrão, o cache de blocos é ativado para todas as famílias em uma tabela. Caso você tenha desativado o cache de bloco para uma família e precise ativá-lo, use 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 os rubores de HBase podem necessitar de ajustes. A configuração atual para manipuladores de descarga pode não ser alta o suficiente para lidar com o tráfego de gravação que pode levar à lentidão das descargas.

Na interface do usuário do servidor de região, observe se a fila de liberação cresce além de 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 as roscas máximas do flusher não aumentem além de 6.

Além disso, veja se você tem uma recomendação para ajuste de contagem de regiões. Se sim, sugerimos que experimente a afinação da região para ver se isso ajuda em rubores mais rápidos. 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, memstore o tamanho 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 até 128 MB apenas então o número máximo de regiões nessa 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 de threads de liberação 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 arquivos para compactação, isso pode levar a mais uso de heap relacionado à forma como os arquivos interagem com o sistema de arquivos do Azure. Por isso, é melhor concluir a compactação o mais rápido possível. Algumas vezes, em clusters mais antigos, as configurações de compactação relacionadas à limitação podem levar a uma 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, deixe-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 a linha de início e parada adequada para cada verificação.

• Use a API MultiRowRangeFilter para que você possa consultar intervalos diferentes em uma chamada de verificação. 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