{"id":55302,"date":"2020-01-17T00:00:00","date_gmt":"2020-01-16T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/teoriya-i-praktika-ispolzovaniya-hbase"},"modified":"2020-02-18T14:03:24","modified_gmt":"2020-02-18T11:03:24","slug":"teoriya-i-praktika-ispolzovaniya-hbase","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/teoriya-i-praktika-ispolzovaniya-hbase","title":{"rendered":"Teoria e pr\u00e1tica do uso do HBase","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bom dia! Meu nome \u00e9 Danil Lipovoy, nossa equipe na Sbertech come\u00e7ou a usar HBase como um reposit\u00f3rio de dados operacionais. Durante seu estudo, acumulamos experi\u00eancia que gostar\u00edamos de sistematizar e descrever (esperamos que seja \u00fatil para muitos). Todos os experimentos realizados abaixo foram feitos com as vers\u00f5es HBase 1.2.0-cdh5.14.2 e 2.0.0-cdh6.0.0-beta1. <\/p>\n

    \n
  1. Arquitetura Geral <\/li>\n
  2. Grava\u00e7\u00e3o de Dados em HBASE<\/li>\n
  3. Leitura de Dados de HBASE<\/li>\n
  4. Cache de Dados<\/li>\n
  5. Processamento de Dados em Lote MultiGet\/MultiPut<\/li>\n
  6. Estrat\u00e9gia de Divis\u00e3o de Tabelas em Regi\u00f5es (Split)<\/li>\n
  7. Alta Disponibilidade, Compacta\u00e7\u00e3o e Localidade de Dados<\/li>\n
  8. Configura\u00e7\u00f5es e Desempenho<\/li>\n
  9. Testes de carga<\/li>\n
  10. Como resultado, obtemos um servi\u00e7o de \"monitoramento como servi\u00e7o\", automatizado na linha de produ\u00e7\u00e3o de integra\u00e7\u00e3o cont\u00ednua. O desenvolvedor ou testador precisa apenas definir a lista de m\u00e9tricas em um arquivo JSON, e tudo o mais acontece automaticamente. Obtemos um controle de qualidade transparente dos lan\u00e7amentos: todas as notifica\u00e7\u00f5es sobre desempenho, consumo de recursos ou regress\u00f5es arquitet\u00f4nicas.<\/li>\n<\/ol>\n

    <\/a><\/noindex><\/p>\n

    1. Arquitetura Geral<\/h2>\n

    \n\"Teoria
    \nO Master de backup escuta o heartbeat do ativo no n\u00f3 do ZooKeeper e, em caso de desaparecimento, assume as fun\u00e7\u00f5es de Master. <\/p>\n

    2. Grava\u00e7\u00e3o de Dados em HBASE<\/h2>\n

    \nPrimeiro, consideramos o caso mais simples \u2013 a grava\u00e7\u00e3o de um objeto chave-valor em uma tabela usando put(rowkey). O cliente precisa primeiro descobrir onde est\u00e1 o servidor da regi\u00e3o raiz (Root Region Server - RRS), que armazena a tabela hbase:meta. Essa informa\u00e7\u00e3o \u00e9 obtida do ZooKeeper. Em seguida, ele se conecta ao RRS e l\u00ea a tabela hbase:meta, da qual extrai informa\u00e7\u00f5es sobre qual RegionServer (RS) \u00e9 respons\u00e1vel por armazenar os dados para a chave rowkey na tabela de interesse. Para uso futuro, a meta-tabela \u00e9 armazenada em cache pelo cliente, e, portanto, as chamadas subsequentes s\u00e3o mais r\u00e1pidas, indo diretamente para o RS.<\/p>\n

    Ap\u00f3s o RRS receber a solicita\u00e7\u00e3o, ele primeiramente a escreve no WriteAheadLog (WAL), o que \u00e9 necess\u00e1rio para recupera\u00e7\u00e3o em caso de falha. Em seguida, os dados s\u00e3o salvos no MemStore. Este \u00e9 um buffer na mem\u00f3ria que cont\u00e9m um conjunto classificado de chaves desta regi\u00e3o. A tabela pode ser dividida em regi\u00f5es (parti\u00e7\u00f5es), cada uma contendo um conjunto exclusivo de chaves. Isso permite que, ao distribuir as regi\u00f5es em diferentes servidores, se obtenha um desempenho mais alto. No entanto, apesar da obviedade dessa afirma\u00e7\u00e3o, veremos a seguir que isso n\u00e3o se aplica a todos os casos.<\/p>\n

    Ap\u00f3s a grava\u00e7\u00e3o no MemStore, o cliente recebe uma resposta informando que a grava\u00e7\u00e3o foi conclu\u00edda com sucesso. No entanto, na realidade, ela \u00e9 armazenada apenas no buffer e ser\u00e1 gravada no disco apenas ap\u00f3s um determinado intervalo de tempo ou quando for preenchida com novos dados. <\/p>\n

    \"Teoria
    \nAo executar a opera\u00e7\u00e3o 'Delete', n\u00e3o ocorre a exclus\u00e3o f\u00edsica dos dados. Eles simplesmente s\u00e3o marcados como exclu\u00eddos, e a exclus\u00e3o real acontece no momento da chamada da fun\u00e7\u00e3o major compact, sobre a qual h\u00e1 mais informa\u00e7\u00f5es no item 7.<\/p>\n

    Os arquivos no formato HFile se acumulam no HDFS e, de tempos em tempos, \u00e9 iniciado um processo de minor compact, que apenas junta pequenos arquivos em arquivos maiores, sem excluir nada. Com o tempo, isso se torna um problema que se manifesta apenas ao ler os dados (voltaremos a isso mais adiante). <\/p>\n

    Al\u00e9m do processo de carregamento descrito acima, existe um procedimento muito mais eficiente, que \u00e9 talvez o ponto mais forte deste banco de dados \u2013 o BulkLoad. Isso envolve a cria\u00e7\u00e3o manual de HFiles e seu armazenamento em disco, o que permite uma escalabilidade excelente e velocidades bastante altas. Na verdade, a limita\u00e7\u00e3o aqui n\u00e3o \u00e9 o HBase, mas as capacidades do hardware. Abaixo est\u00e3o os resultados do carregamento em um cluster composto por 16 RegionServers e 16 NodeManagers YARN (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads), vers\u00e3o HBase 1.2.0-cdh5.14.2. <\/p>\n

    \"Teoria
    \n
    \nAqui, \u00e9 vis\u00edvel que aumentando o n\u00famero de parti\u00e7\u00f5es (regi\u00f5es) na tabela, bem como os executores Spark, obtemos um aumento na velocidade de carregamento. A velocidade tamb\u00e9m depende do volume de grava\u00e7\u00e3o. Blocos grandes proporcionam um aumento em termos de MB\/segundo, enquanto blocos pequenos aumentam a quantidade de registros inseridos por unidade de tempo, mantendo todas as outras vari\u00e1veis constantes. <\/p>\n

    Tamb\u00e9m \u00e9 poss\u00edvel iniciar o carregamento em duas tabelas simultaneamente e obter o dobro da velocidade. Abaixo, \u00e9 mostrado que a grava\u00e7\u00e3o de blocos de 10 KB em duas tabelas vai a uma velocidade de cerca de 600 MB\/segundo cada (totalizando 1275 MB\/segundo), que corresponde \u00e0 velocidade de grava\u00e7\u00e3o em uma tabela de 623 MB\/segundo (ver n\u00ba 11 acima).<\/p>\n

    \"Teoria
    \nPor outro lado, a segunda execu\u00e7\u00e3o com grava\u00e7\u00f5es de 50 KB mostra que a velocidade de carregamento cresce de forma insignificante, o que indica uma aproxima\u00e7\u00e3o aos limites m\u00e1ximos. \u00c9 importante considerar que a carga no pr\u00f3prio HBASE \u00e9 praticamente inexistente; tudo o que \u00e9 necess\u00e1rio dele \u00e9, primeiro, fornecer os dados do hbase:meta e, depois, ao adicionar os HFiles, liberar os dados do BlockCache e salvar o buffer MemStore no disco, caso n\u00e3o esteja vazio.<\/p>\n

    3. Leitura de dados do HBASE<\/h2>\n

    \nSe considerarmos que todas as informa\u00e7\u00f5es de hbase:meta j\u00e1 est\u00e3o com o cliente (ver item 2), a consulta vai diretamente para o RS que armazena a chave necess\u00e1ria. Primeiro, a busca \u00e9 realizada no MemCache. Independentemente de haver ou n\u00e3o dados l\u00e1, a busca tamb\u00e9m \u00e9 feita no buffer BlockCache e, se necess\u00e1rio, nos HFiles. Se os dados forem encontrados no arquivo, eles s\u00e3o armazenados no BlockCache e, na pr\u00f3xima solicita\u00e7\u00e3o, ser\u00e3o retornados mais rapidamente. A busca no HFile acontece relativamente r\u00e1pido devido ao uso do filtro de Bloom, ou seja, ao ler um pequeno volume de dados, ele imediatamente determina se esse arquivo cont\u00e9m a chave necess\u00e1ria e, se n\u00e3o, passa para o pr\u00f3ximo.<\/p>\n

    \"Teoria
    \nRecebendo dados dessas tr\u00eas fontes, o RS forma a resposta. Em particular, ele pode transmitir v\u00e1rias vers\u00f5es encontradas de um objeto se o cliente solicitar versionamento.<\/p>\n

    4. Cache de dados<\/h2>\n

    \nOs buffers MemStore e BlockCache ocupam at\u00e9 80% da mem\u00f3ria heap alocada do RS (o restante \u00e9 reservado para tarefas de servi\u00e7o do RS). Se o modo t\u00edpico de uso for tal que os processos escrevam e leiam esses mesmos dados imediatamente, faz sentido diminuir o BlockCache e aumentar o MemStore, pois ao gravar, os dados no cache de leitura n\u00e3o s\u00e3o acessados, o que far\u00e1 com que o uso do BlockCache ocorra com menos frequ\u00eancia. O buffer BlockCache consiste em duas partes: LruBlockCache (sempre on-heap) e BucketCache (geralmente off-heap ou em SSD). O BucketCache deve ser utilizado quando h\u00e1 muitas solicita\u00e7\u00f5es de leitura que n\u00e3o cabem no LruBlockCache, o que leva a um trabalho ativo do Garbage Collector. Contudo, n\u00e3o se deve esperar um aumento dr\u00e1stico de desempenho da utiliza\u00e7\u00e3o do cache de leitura, mas voltaremos a isso no item 8.<\/p>\n

    \"Teoria
    \nO BlockCache \u00e9 \u00fanico para todo o RS, enquanto o MemStore \u00e9 espec\u00edfico para cada tabela (um por cada Column Family).<\/p>\n

    Como est\u00e1 descrito<\/a><\/noindex> Na teoria, ao gravar, os dados n\u00e3o v\u00e3o para o cache e, de fato, esses par\u00e2metros CACHE_DATA_ON_WRITE para a tabela e \"Cache DATA on Write\" para o RS est\u00e3o configurados como false. No entanto, na pr\u00e1tica, se gravarmos dados no MemStore, depois o descarregarmos no disco (limpando assim), e em seguida deletarmos o arquivo resultante, ao executar uma solicita\u00e7\u00e3o get, conseguiremos obter os dados com sucesso. Al\u00e9m disso, mesmo se desativarmos completamente o BlockCache e preenchermos a tabela com novos dados, depois conseguirmos descarregar o MemStore no disco, delet\u00e1-los e solicit\u00e1-los de outra sess\u00e3o, eles ainda ser\u00e3o recuperados de algum lugar. Portanto, o HBase armazena n\u00e3o apenas dados, mas tamb\u00e9m mist\u00e9rios enigm\u00e1ticos.<\/p>\n

    hbase(main):001:0> criar 'ns:magic', 'cf'\nTabela ns:magic criada\nDemorou 1.1533 segundos\nhbase(main):002:0> colocar 'ns:magic', 'key1', 'cf:c', 'tente_me_deletar'\nDemorou 0.2610 segundos\nhbase(main):003:0> esvaziar 'ns:magic'\nDemorou 0.6161 segundos\nhdfs dfs -mv \/data\/hbase\/data\/ns\/magic\/* \/tmp\/trash\nhbase(main):002:0> obter 'ns:magic', 'key1'\n cf:c      timestamp=1534440690218, valor=tente_me_deletar\n<\/code><\/pre>\n
    \nO par\u00e2metro \"Cache DATA on Read\" est\u00e1 definido como falso. Se tiver alguma ideia, fique \u00e0 vontade para discutir nos coment\u00e1rios.<\/p>\n
    5. Processamento em Lote de Dados MultiGet\/MultiPut<\/h2>\n
    \nO processamento de solicita\u00e7\u00f5es individuais (Get\/Put\/Delete) \u00e9 uma opera\u00e7\u00e3o bastante cara, portanto, deve-se tentar agrup\u00e1-las em List ou List, o que pode resultar em um aumento significativo de desempenho. Isso \u00e9 especialmente verdadeiro para opera\u00e7\u00f5es de grava\u00e7\u00e3o, mas h\u00e1 uma armadilha ao ler. No gr\u00e1fico abaixo est\u00e1 o tempo para ler 50.000 registros do MemStore. A leitura foi realizada em um \u00fanico thread e no eixo horizontal est\u00e1 o n\u00famero de chaves na solicita\u00e7\u00e3o. Pode-se ver que ao aumentar para mil chaves em uma \u00fanica solicita\u00e7\u00e3o, o tempo de execu\u00e7\u00e3o diminui, ou seja, a velocidade aumenta. No entanto, com o modo MSLAB ativado por padr\u00e3o, ap\u00f3s esse limite, h\u00e1 uma queda dr\u00e1stica no desempenho, e quanto maior o volume de dados no registro, maior o tempo de execu\u00e7\u00e3o. <\/p>\n
    \"Teoria
    \n
    \nOs testes foram realizados em uma m\u00e1quina virtual, 8 n\u00facleos, vers\u00e3o HBase 2.0.0-cdh6.0.0-beta1.<\/p>\n
    O modo MSLAB foi projetado para reduzir a fragmenta\u00e7\u00e3o do heap, que ocorre devido \u00e0 mistura de dados de gera\u00e7\u00f5es novas e antigas. Para resolver esse problema, ao ativar o MSLAB, os dados s\u00e3o colocados em c\u00e9lulas (chunk) relativamente pequenas e processados em lotes. Como resultado, quando o volume no pacote de dados solicitado excede o tamanho alocado, o desempenho cai drasticamente. Por outro lado, desativar esse modo tamb\u00e9m n\u00e3o \u00e9 desej\u00e1vel, pois levar\u00e1 a pausas devido ao GC em momentos de intenso trabalho com dados. Uma boa sa\u00edda \u00e9 aumentar o tamanho da c\u00e9lula, especialmente ao gravar atrav\u00e9s de put ao mesmo tempo que se l\u00ea. Vale ressaltar que o problema n\u00e3o ocorre se, ap\u00f3s a grava\u00e7\u00e3o, a comando flush que descarrega o MemStore no disco for executada ou se a carga for realizada usando BulkLoad. Na tabela abaixo, mostra-se que solicita\u00e7\u00f5es de dados maiores do MemStore (e com a mesma quantidade) levam a uma desacelera\u00e7\u00e3o. No entanto, aumentando o chunksize, podemos retornar o tempo de processamento ao normal.<\/p>\n
    \"Teoria
    \nAl\u00e9m de aumentar o chunksize, a fragmenta\u00e7\u00e3o dos dados por regi\u00f5es, ou seja, o partitioning das tabelas, ajuda. Isso resulta em um menor n\u00famero de solicita\u00e7\u00f5es para cada regi\u00e3o, e se elas forem armazenadas em uma c\u00e9lula, a resposta permanece boa.<\/p>\n
    6. Estrat\u00e9gia de partitioning de tabelas por regi\u00f5es<\/h2>\n
    \nComo o HBase \u00e9 um reposit\u00f3rio de chave-valor e o particionamento \u00e9 feito pela chave, \u00e9 crucial distribuir os dados uniformemente entre todas as regi\u00f5es. Por exemplo, particionar uma tabela em tr\u00eas partes resultar\u00e1 em tr\u00eas regi\u00f5es:<\/p>\n
    \"Teoria
    \n\u00c0s vezes, isso leva a uma desacelera\u00e7\u00e3o dr\u00e1stica, se os dados carregados posteriormente forem, por exemplo, valores longos que na sua maioria come\u00e7am com o mesmo d\u00edgito, como por exemplo:<\/p>\n
    1000001
    \n1000002
    \n\u2026
    \n1100003<\/p>\n
    Como as chaves s\u00e3o armazenadas como um array de bytes, todas elas come\u00e7ar\u00e3o de forma semelhante e pertencer\u00e3o \u00e0 regi\u00e3o #1 que armazena esse intervalo de chaves. Existem v\u00e1rias estrat\u00e9gias de particionamento:<\/p>\n
    HexStringSplit \u2013 Converte a chave em uma string com codifica\u00e7\u00e3o hexadecimal no intervalo de \"00000000\" => \"FFFFFFFF\" e preenche \u00e0 esquerda com zeros.<\/p>\n
    UniformSplit \u2013 Converte a chave em um array de bytes com codifica\u00e7\u00e3o hexadecimal no intervalo de \"00\" => \"FF\" e preenche \u00e0 direita com zeros.<\/p>\n
    Al\u00e9m disso, \u00e9 poss\u00edvel especificar qualquer intervalo ou conjunto de chaves para particionamento e configurar o auto-partitioning. No entanto, uma das abordagens mais simples e eficazes \u00e9 o UniformSplit e o uso de concatena\u00e7\u00e3o do hash, por exemplo, o par mais significativo de bytes ao passar a chave pela fun\u00e7\u00e3o CRC32(rowkey) e a pr\u00f3pria chave:<\/p>\n
    hash + rowkey<\/p>\n
    Assim, todos os dados ser\u00e3o distribu\u00eddos uniformemente entre as regi\u00f5es. Ao ler, os primeiros dois bytes s\u00e3o simplesmente descartados e a chave original permanece. Al\u00e9m disso, o RS controla a quantidade de dados e chaves na regi\u00e3o e, ao ultrapassar os limites, divide automaticamente em partes. <\/p>\n
    7. Toler\u00e2ncia a falhas e localidade dos dados<\/h2>\n
    \nComo cada conjunto de chaves \u00e9 responsabilidade de apenas uma regi\u00e3o, a solu\u00e7\u00e3o para problemas relacionados a falhas do RS ou desativa\u00e7\u00e3o \u00e9 armazenar todos os dados necess\u00e1rios no HDFS. Quando um RS falha, o mestre detecta isso pela aus\u00eancia de heartbeat no n\u00f3 do ZooKeeper. Em seguida, ele atribui a regi\u00e3o problem\u00e1tica a outro RS, e como os HFiles s\u00e3o armazenados em um sistema de arquivos distribu\u00eddo, o novo propriet\u00e1rio os l\u00ea e continua a servir os dados. No entanto, como parte dos dados pode estar no MemStore e n\u00e3o ter sido gravada nos HFiles, para a recupera\u00e7\u00e3o do hist\u00f3rico de opera\u00e7\u00f5es utiliza-se o WAL, que tamb\u00e9m \u00e9 armazenado no HDFS. Ap\u00f3s a aplica\u00e7\u00e3o das altera\u00e7\u00f5es, o RS pode responder a solicita\u00e7\u00f5es, no entanto, a realoca\u00e7\u00e3o resulta em que parte dos dados e os processos que os atendem estejam em diferentes n\u00f3s, ou seja, a localidade diminui. <\/p>\n
    A solu\u00e7\u00e3o para o problema \u00e9 a major compaction \u2013 este procedimento move arquivos para os n\u00f3s que s\u00e3o respons\u00e1veis por eles (onde suas regi\u00f5es est\u00e3o localizadas), resultando em um aumento repentino na carga sobre a rede e os discos durante esse procedimento. No entanto, o acesso aos dados torna-se significativamente mais r\u00e1pido posteriormente. Al\u00e9m disso, a major_compaction realiza a fus\u00e3o de todos os HFiles em um \u00fanico arquivo dentro da regi\u00e3o, al\u00e9m de limpar dados de acordo com as configura\u00e7\u00f5es da tabela. Por exemplo, \u00e9 poss\u00edvel definir o n\u00famero de vers\u00f5es do objeto a serem mantidas ou o tempo de vida, ap\u00f3s o qual o objeto \u00e9 exclu\u00eddo fisicamente.<\/p>\n
    Este procedimento pode ter um impacto muito positivo na opera\u00e7\u00e3o do HBase. Na imagem abaixo, \u00e9 poss\u00edvel ver como o desempenho degradou devido \u00e0 grava\u00e7\u00e3o ativa de dados. Aqui, 40 threads estavam gravando em uma tabela e 40 threads estavam lendo dados simultaneamente. As threads de grava\u00e7\u00e3o formam cada vez mais HFiles, que s\u00e3o consumidos por outras threads. Como resultado, mais dados precisam ser removidos da mem\u00f3ria e, eventualmente, o GC come\u00e7a a operar, o que praticamente paralisa todo o trabalho. A execu\u00e7\u00e3o da major compaction levou \u00e0 limpeza dos ac\u00famulos formados e \u00e0 recupera\u00e7\u00e3o do desempenho.<\/p>\n
    \"Teoria
    \nO teste foi realizado em 3 DataNodes e 4 RS (CPU Xeon E5-2680 v4 @ 2.40GHz * 64 threads). Vers\u00e3o HBase 1.2.0-cdh5.14.2<\/p>\n
    Vale ressaltar que a execu\u00e7\u00e3o da compacta\u00e7\u00e3o major foi realizada em uma tabela \"viva\", onde dados estavam sendo ativamente escritos e lidos. Nas redes, havia afirma\u00e7\u00f5es de que isso poderia levar a respostas incorretas ao ler dados. Para verificar, foi iniciado um processo que gerava novos dados e os escrevia na tabela. Em seguida, imediatamente lia e verificava se o valor obtido coincidia com o que havia sido gravado. Durante a execu\u00e7\u00e3o desse processo, a compacta\u00e7\u00e3o major foi iniciada cerca de 200 vezes sem que nenhum erro fosse registrado. Pode ser que o problema ocorra raramente e apenas durante alta carga, portanto, \u00e9 mais seguro realmente parar os processos de leitura e escrita de forma planejada e realizar a limpeza, evitando tais quedas no GC.<\/p>\n
    Al\u00e9m disso, a compacta\u00e7\u00e3o major n\u00e3o afeta o estado do MemStore, para liber\u00e1-lo no disco e compact\u00e1-lo \u00e9 necess\u00e1rio usar flush (connection.getAdmin().flush(TableName.valueOf(tblName))).<\/p>\n
    8. Configura\u00e7\u00f5es e desempenho<\/h2>\n
    \nComo j\u00e1 mencionado, o HBase tem o maior sucesso onde n\u00e3o precisa fazer nada durante a execu\u00e7\u00e3o do BulkLoad. No entanto, isso \u00e9 aplic\u00e1vel \u00e0 maioria dos sistemas e pessoas. Entretanto, essa ferramenta \u00e9 mais adequada para o carregamento em massa de dados em grandes blocos, enquanto que, se o processo exige a realiza\u00e7\u00e3o de m\u00faltiplas requisi\u00e7\u00f5es concorrentes de leitura e grava\u00e7\u00e3o, s\u00e3o utilizadas os comandos Get e Put descritos acima. Para determinar os par\u00e2metros ideais, foram realizados testes com diferentes combina\u00e7\u00f5es de par\u00e2metros de tabelas e configura\u00e7\u00f5es:<\/p>\n