Ao executar qualquer ferramenta de benchmarking de desempenho em seu cluster, uma decisão crítica é sempre qual tamanho do conjunto de dados deve ser usado para um teste de desempenho, e aqui demonstramos por que é importante selecionar um tamanho de conjunto de dados “bom ajuste” ao executar um desempenho do HBase teste em seu cluster.
As configurações do cluster HBase e o tamanho do conjunto de dados podem variar o desempenho de sua carga de trabalho e os resultados do teste no mesmo cluster. Você deve escolher esse tamanho de conjunto de dados com base no que está tentando entender sobre o desempenho do cluster. Para mostrar a diferença entre um conjunto de trabalho que cabe no cache de memória disponível e um que precisa ser lido do armazenamento subjacente, executamos 2 testes de carga de trabalho YCSB com tamanhos de conjuntos de dados escolhidos adequadamente no mesmo cluster de banco de dados de operação CDP Private Cloud Base 7.2.2. Usamos tamanhos de conjunto de dados de 40 GB versus 1 TB e a taxa de transferência para as diferentes cargas de trabalho YCSB é comparada abaixo. No gráfico, quanto maior a barra, melhor a taxa de transferência.
Nota:Taxa de transferência =Operações por segundo
Quando um aplicativo tenta fazer uma leitura de um cluster HBase, o Region Server que trata a solicitação primeiro verifica se os resultados necessários estão em um bloco de dados que já é local para seu processo por meio de seu cache de bloco. Se o bloco de dados estiver presente, a solicitação do cliente pode ser atendida diretamente do cache e isso conta como um acerto no cache. No entanto, se o bloco não for atualmente local para o processo do Region Server, isso será contado como uma falta de cache e deverá ser lido do HFile no armazenamento HDFS. Dependendo da utilização do cache, esse bloco será salvo no cache para solicitações futuras.
Conforme esperado e visto no gráfico de resumo, uma carga de trabalho em que a maioria dos conjuntos de dados cabe no cache tem latências mais baixas e a taxa de transferência é muito maior em comparação com uma carga de trabalho executada em que os dados estão sendo acessados de HFiles no armazenamento hdfs.
Para escolher os tamanhos do conjunto de dados de carga de trabalho para atender bem às nossas metas de teste, é importante verificar os tamanhos dos heaps RegionServer, caches L1 e L2, caches de buffer do SO e definir um tamanho de conjunto de dados apropriado. Depois que uma execução de carga de trabalho YCSB for concluída, um bom parâmetro a ser verificado como forma de verificar se as coisas funcionaram conforme o esperado é quanto dos dados foram atendidos do cache (um acerto de cache) e quanto foi acessado do armazenamento hdfs. Essa proporção de acertos de cache do servidor de região para o total de solicitações de leitura é a proporção de acertos de cache.
Você pode encontrar essas informações na configuração “l1CacheHitRatio” da taxa de acertos do cache L1. Se você tiver caches L1 e L2 definidos em seu cluster, o cache L1 servirá os blocos de índice e o cache L2 servirá os blocos de dados, e você poderá registrar as configurações L1 “l1CacheHitRatio” e L2 “l2CacheHitRatio” para referência.
O restante desta postagem do blog mostrará os detalhes de nossa configuração de teste, escolhendo o tamanho do conjunto de dados e executando o YCSB com esses tamanhos de conjunto de dados.
Configuração de cluster HBase usada para este teste:
- Agrupamento usado : Cluster de 6 nós (1 mestre + 5 servidores de região)
- Descrição: Dell PowerEdge R430, 20c/40t Xenon e5-2630 v4 @ 2,2 GHz, 128 GB de RAM, discos de 4-2 TB
- Segurança: Nenhum configurado (sem Kerberos)
- versão CDP: CDP Private Cloud Base 7.2.2 Cluster HBase de 6 nós com 1 mestre + 5 servidores de região
- JDK usou jdk1.8_232
- Os servidores da região HBase foram configurados com heap de 32 GB
- HBase master foi configurado com heap de 4GB
- O cache L1 com LruBlockCache foi usado com tamanho de cache de 12,3 GB
- O cache L1 total no cluster é de 61 GB (12,3 * 5 =61 GB)
- L2 off heap cache não foi configurado no cluster
Caso de dimensionamento 1:os dados se encaixam completamente no cache disponível no cluster
Em nosso cluster HBase, configuramos um total de 61 GB (12,3 GB * 5) nos 5 servidores de região alocados para o cache de bloco L1. Para um conjunto de dados que cabe completamente no cache, escolhemos um conjunto de dados de 40 GB no tamanho.
Caso de dimensionamento 2:conjunto de dados maior que o cache disponível no cluster
Para o segundo cenário, queremos que os dados sejam muito maiores que o cache disponível. Para escolher um tamanho de conjunto de dados apropriado, examinamos o cache de bloco do HBase configurado e o cache de buffer do SO no cluster. Em nosso cluster HBase fornecido, o cache de bloco L1 configurado é 61G quando agregado nos RegionServers. Os nós do servidor tinham um total de 128 G de RAM cada e qualquer memória não dedicada a um processo do servidor pode ser usada pelo sistema operacional para armazenar efetivamente em cache os blocos HDFS subjacentes e aumentar a taxa de transferência geral. Em nossa configuração de teste, há cerca de 96G de cache do SO disponível em cada nó do servidor da região para essa finalidade (ignorando a memória usada pelos processos DataNode ou SO para simplificar as coisas). Agregando isso nos servidores de 5 regiões, tivemos um potencial de quase 500G para buffers (servidores de 96G * 5 regiões). Assim, escolhemos um tamanho de conjunto de dados de 1 TB, excedendo o cache de bloco configurado e o cache de buffer do SO disponível.
Transformando tamanhos de dados de destino em parâmetros YCSB
No YCSB, uma linha tem 1 KB por padrão, então, dependendo de quantas linhas você carrega na 'tabela de usuário' do YCSB, você pode facilmente estimar o tamanho dos dados da tabela 'tabela de usuário' do YCSB. Portanto, se você fizer upload de 1 milhão de linhas, terá feito upload de 1.000.000 * 1 KB =1 GB de dados na 'tabela de usuário' do YCSB.
Os tamanhos dos conjuntos de dados usados para nossos dois testes foram:
- 40 GB de dados com 40 milhões de linhas
- 1 TB de dados com 1 bilhão de linhas
Metodologia de teste
O CDP Private Cloud Base 7.2.2 foi instalado no cluster de 6 nós e os dados de carga de trabalho com 40 milhões de linhas (tamanho total do conjunto de dados => 40 GB) foram gerados e as cargas de trabalho YCSB foram executadas. Após o carregamento, esperamos a conclusão de todas as operações de compactação antes de iniciar o teste de carga de trabalho.
As cargas de trabalho YCSB que foram executadas no HBase foram
- Carga de trabalho A:50% de leitura e 50% de atualização
- Carga de trabalho C:100% de leitura
- Carga de trabalho F:50% de leitura e 50% de atualização/leitura-modificação-gravação:50/50
- Carga de trabalho somente atualização personalizada:100% de atualização
Cada carga de trabalho do YCSB (A,C,F e UpdateOnly) foi executada por 15 minutos cada, e a execução completa foi repetida 5 vezes sem reinicializações entre as execuções para medir a taxa de transferência do YCSB*. Os resultados mostrados são médias tomadas para as últimas 3 execuções das 5 execuções. As primeiras 2 execuções de teste foram ignoradas para evitar a penalidade da primeira e da segunda execução.
Depois que as execuções de 40 GB foram concluídas, descartamos a tabela de usuários e geramos novamente 1 bilhão de linhas para criar o tamanho do conjunto de dados de 1 TB e reexecutamos os testes com a mesma metodologia no mesmo cluster.
Resultados do teste
Resultados YCSB com 40 GB
No caso de 40 GB, os dados podem caber completamente no cache L1 de 61 GB no cluster. A taxa de acertos do cache L1 observada no cluster durante o teste foi próxima de 99%.
Dica: Para conjuntos de dados menores em que os dados podem caber no cache, também podemos usar a opção cache on load e pré-aquecer o cache para obter uma taxa de acertos de 100% usando a opção de tabela PREFETCH_BLOCKS_ON_OPEN
Executamos cada carga de trabalho do YCSB por 15 minutos a cada 5 vezes e tiramos as médias das últimas 3 execuções para evitar a penalidade da primeira execução.
Resultados vistos com 40G L1 taxa de acerto de cache de 99% nos servidores da região são mostrados abaixo na tabela:
| Operação | Número de operações | Produtividade | Latência média | 95 Latência | 99 Latência |
| (Número de operações/s) | (ms) | (ms) | (ms) | ||
| Carga de trabalho C | 148558364 | 165063 | 0,24 | 0,30 | 0,48 |
| Somente atualização | 56727908 | 63030 | 0,63 | 0,78 | 1,57 |
| Carga de trabalho A | 35745710 | 79439 | 0,40 | 0,54 | 0,66 |
| Carga de trabalho F | 24823285 | 55157 | 0,58 | 0,70 | 0,96 |
Resultados YCSB com conjunto de dados de 1 TB
No caso de 1 TB, os dados não cabem no cache L1 de 61 GB no cluster ou no cache de buffer do SO de 500 GB. A taxa de acertos do cache L1 no cluster observada durante o teste foi de 82-84%.
Executamos cada carga de trabalho por 15 minutos a cada 5 vezes e tiramos as médias das últimas 3 execuções para evitar a penalidade da primeira execução.
Resultados vistos com 1 TB Taxa de acertos do cache L1 82-84% nos servidores da região são mostrados abaixo na tabela:
| Operação | Número de operações | Produtividade | Latência média | 95 Latência | 99 Latência |
| (Número de operações/s) | (ms) | (ms) | (ms) | ||
| Carga de trabalho C | 2727037 | 3030 | 13.19 | 55,50 | 110,85 |
| Somente atualização | 56345498 | 62605 | 0,64 | 0,78 | 1,58 |
| Carga de trabalho A | 3085135 | 6855 | 10,88 | 48,34 | 97,70 |
| Carga de trabalho F | 3333982 | 3704 | 10,45 | 47,78 | 98,62 |
*Throughput (ops/sec) =Nº de operações por segundo
Análise:
Comparando os resultados do teste para os dois tamanhos de conjuntos de dados diferentes acima, podemos ver como a mesma taxa de transferência de carga de trabalho pode variar de 3 mil operações por segundo a 165 mil operações por segundo quando os dados são acessados mais rapidamente a partir do conjunto de dados 40G com cache aquecido versus armazenamento hdfs.
O gráfico abaixo mostra a taxa de transferência e compara como a taxa de transferência mudou para diferentes cargas de trabalho quando executadas com os 2 conjuntos de dados de tamanhos diferentes. No gráfico, quanto maior a barra, melhor a taxa de transferência.
Nota:Taxa de transferência =Operações por segundo
Como visto no gráfico, as cargas de trabalho YCSB que leem dados como Workload A, Workload C e Workload F tiveram uma taxa de transferência muito melhor no caso de 40G, onde os dados cabem facilmente no cache versus o caso de tamanho de dados de 1 TB, onde os dados HFile precisavam ser acessado a partir do HDFS
Observando as taxas de acertos de cache, o conjunto de dados de 40G teve uma taxa de acertos de cache de cerca de 99%, e o conjunto de dados de 1 TB teve uma taxa de acertos de cache de cerca de 85%, então 15% dos dados no caso de 1 TB foram acessados do armazenamento hdfs .
A carga de trabalho somente atualização personalizada do YCSB que executamos teve a mesma taxa de transferência em ambos os casos, pois fazia apenas atualizações e nenhuma leitura.
Durante o desempenho do HBase, observamos atentamente as latências dos percentis 95 e 99. A latência média é apenas a taxa de transferência total dividida pelo tempo total, mas o percentil 95 e o percentil 99 mostram os valores discrepantes reais que afetam a taxa de transferência total da carga de trabalho. No caso de 1 TB, os valores discrepantes de alta latência no percentil 95 e 99 fazem com que a taxa de transferência diminua e, no caso de 40 GB, os acertos de cache de baixa latência no percentil 99 levam a uma taxa de transferência total aumentada.
O gráfico abaixo mostra a comparação de latência para latência média, latência de 95º percentil e latência de 99º percentil e como ela difere para diferentes cargas de trabalho quando executadas com conjuntos de dados de tamanhos diferentes.
No gráfico acima, é difícil ver as barras que representam a latência para o conjunto de dados de 40 GB, pois são extremamente baixas em comparação com a latência observada para o conjunto de dados de 1 TB acessando dados de hdfs.
Traçamos o gráfico de latência usando log dos valores de latência para mostrar a diferença no gráfico abaixo
Como visto acima, as latências são muito menores no caso de 40 GB, onde a taxa de acertos do cache está próxima de 99% e a maioria dos dados de carga de trabalho está disponível no cache. Em comparação com o conjunto de dados de 1 TB, a taxa de acertos do cache foi de cerca de 85%, pois os dados HFile tiveram que ser acessados do armazenamento HDFS.
A latência média e de 99 para Workload C no caso de 40G, em que 99% dos dados são retornados do cache aquecido, foi de cerca de 2 a 4 ms. A latência do percentil 99 para a mesma carga de trabalho C no caso de 1 TB foi de cerca de 100 ms para a carga de trabalho C (carga de trabalho somente leitura).
Isso mostra que um acerto de cache do cache de bloco no heap retorna uma leitura em cerca de 2 ms e uma falha de cache e a obtenção de um registro do HDFS pode levar cerca de 100 ms nesse cluster.
Recomendação:
Ao executar um teste de benchmarking YCSB, o tamanho do conjunto de dados faz uma diferença substancial nos resultados de desempenho e, portanto, dimensionar o teste adequadamente é muito importante. Ao mesmo tempo, observar a taxa de acertos de cache e as diferenças de latência entre a latência mínima e a 99ª o ajudará a encontrar a latência de um acerto de cache em comparação com quando os dados são acessados do armazenamento subjacente no cluster.
Dica:
Para verificar as taxas de acertos de cache de sua carga de trabalho em um servidor de região, você pode usar o comando abaixo
curl http://<region-server-host>:22102/jmx | grep -e l1CacheHitRatio -e l2CacheHitRatio
Você também pode visualizar a taxa de acertos de cache na interface do usuário da Web do HBase seguindo as etapas abaixo:
- Na interface da Web do HBase, clique no servidor da região
- Na seção Block cache, selecione L1 (e L2 se L2 estiver configurado) para revisar as taxas de acertos do cache.
Uma captura de tela mostrando a taxa de acertos do cache do cache do bloco L1 é mostrada abaixo:
Aqui está um link para obter mais informações sobre a captura de tela do HBase mostrada acima e bloquear o cache https://docs.cloudera.com/runtime/7.2.2/configuring-hbase/topics/hbase-blockcache.html
Sobre YCSB
YCSB é uma especificação de código aberto e um conjunto de programas para avaliar os recursos de recuperação e manutenção de programas de computador. É uma ferramenta muito popular usada para comparar o desempenho relativo de sistemas de gerenciamento de banco de dados NoSQL.
Para usar o YCSB para testar o desempenho do Operational Database, confira o blog How to Run YCSB for HBase
