Consultoria do Apache HBase no Azure HDInsight

Artigo
09/06/2024

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

Otimize o HBase para ler os dados gravados mais recentemente

Se seu caso de uso envolver a leitura dos dados gravados mais recentemente do HBase, esta consultoria pode ajudá-lo. Para alto desempenho, é ideal que as leituras do HBase sejam servidas de memstore, em vez do armazenamento remoto.

O comunicado de consulta indica que, para uma família de colunas em uma tabela específica, > 75% de leituras estão sendo servidas a partir da memstore. Esse indicador sugere que, mesmo que ocorra uma liberação na memstore, o arquivo recente precisa ser acessado e estar no cache. Os dados são gravados primeiro na memstore. O sistema acessa lá os dados recentes. Há uma chance de que os threads de liberação do HBase internos detectem que uma determinada região atingiu o tamanho de 128M (padrão) e pode disparar uma liberação. Esse cenário ocorre até mesmo com os dados mais recentes que foram gravados quando a memstore tinha um tamanho de cerca de 128M. Portanto, uma leitura posterior desses registros recentes pode exigir uma leitura de arquivo em vez de ser feita na memstore. Portanto, é melhor otimizar para que até mesmo dados recentes que foram liberados recentemente possam residir no cache.

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

Defina hbase.rs.cacheblocksonwrite como true. Essa configuração padrão no HBase do HDInsight é true, então, verifique se ele não foi redefinido para false.
Aumente o valorhbase.hstore.compactionThreshold para que você possa evitar a compactação desde o começo. Por padrão, esse valor é 3. Você pode aumentá-lo para um valor mais alto como 10.
Se você seguir a etapa 2 e definir compactionThreshold, altere hbase.hstore.compaction.max para um valor mais alto, como 100, e também aumente o valor da configuração hbase.hstore.blockingStoreFiles para um valor mais alto, como 300.
Se você tiver certeza de que precisa ler apenas os dados recentes, defina a hbase.rs.cachecompactedblocksonwrite configuração para ATIVADO. Essa configuração informa ao sistema que, mesmo que ocorra a compactação, os dados permanecem no cache. As configurações também podem ser definidas no nível da família.

No Shell do HBase, execute o seguinte comando para definir a hbase.rs.cachecompactedblocksonwrite configuração:
```
alter '<TableName>', {NAME => '<FamilyName>', CONFIGURATION => {'hbase.hstore.blockingStoreFiles' => '300'}}
```
O cache de blocos pode ser desativado para uma determinada família em uma tabela. Verifique se ele está ATIVADO para famílias que têm leituras de dados mais recentes. Por padrão, o cache de blocos está ativado para todas as famílias em uma tabela. Caso você tenha desabilitado o cache de blocos para uma família e precise ativá-lo, use o comando alter do Shell do HBase.

Essas configurações ajudam a garantir que os dados estejam disponíveis no cache e que os dados recentes não sejam compactados. 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 o Guia de Referência do Apache HBase: compactação em camadas de data

Otimize a fila de liberação

Essa consultoria indica que as liberações do HBase podem precisar de ajuste. A configuração atual para manipuladores de liberação pode não ser alta o suficiente para lidar com o tráfego de gravação, o que pode levar à lentidão das liberações.

Na interface do usuário do servidor de região, observe se a fila de liberação cresce acima de 100. Esse limite indica que as liberações são lentas e talvez você precise ajustar a configuração hbase.hstore.flusher.count. Por padrão, o valor é 2. Certifique-se de que os threads de liberação máxima não aumentem além de 6.

Além disso, veja se você tem uma recomendação para o ajuste da contagem de regiões. Se sim, sugerimos que você tente o ajuste de região para ver se isso ajuda a obter descargas mais rápidas. Caso contrário, ajustar os threads de liberação pode ajudá-lo.

Ajuste da contagem de regiões

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

Como exemplo de cenário:

Suponha que o tamanho do heap para o servidor de região seja 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. Isso significa que, de 10 GB, 4 GB são alocados para a memstore(globalmente).
Suponha que haja uma distribuição uniforme da carga de gravação em todas as regiões. Presumindo que cada região cresça até 128 MB apenas, o número máximo de regiões nessa configuração é de 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. A memstore global de 4GB agora está dividida em regiões de 100. Efetivamente, cada região obtém apenas 40 MB para memstore. Quando as gravações são uniformes, o sistema faz liberações frequentes e o tamanho menor da ordem é < 40 MB. Ter muitos threads de liberação pode aumentar a velocidade de liberação hbase.hstore.flusher.count.

A consultoria quer dizer que seria bom reconsiderar o número de regiões por servidor, o tamanho do heap e a configuração do tamanho global da memstore, junto com o ajuste dos 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 aumentar para mais de 2000 e ocorrer periodicamente, você poderá aumentar os threads de compactação para um valor maior.

Quando há um número excessivo de arquivos para compactação, ele pode levar a mais uso de heap relacionado ao modo como os arquivos interagem com o sistema de arquivos do Azure. Portanto, é 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 eles já estiverem definidos como 50M e 100M, deixe-os como estão. No entanto, se você tiver determinado essas configurações em um valor mais baixo (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 que essa configuração seja menor que 3.

Verificação de tabela completa

O aviso de verificação de tabela completa indica que mais de 75% das verificações emitidas são verificações completas de tabela/região. 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 de parada apropriada para cada verificação.
Use a API MultiRowRangeFilter para consultar intervalos diferentes em uma chamada de verificação. Para obter mais informações, confira a documentação da API MultiRowRangeFilter.
Nos casos em que você precisa de uma verificação completa de tabela ou de região, verifique se há uma possibilidade de evitar o uso do cache para essas consultas, para que outras consultas que usam o cache não possam remover blocos que estejam ativos. Para garantir que as verificações não usem cache, use a API escanear com a opção setCaching(false) no seu código:
```
scan#setCaching(false)
```

Próximas etapas

Otimize o Apache HBase usando o Ambari

Compartilhar via