Esta postagem foi publicada originalmente em blogs.apache.org, nós a republicamos aqui em uma forma ligeiramente modificada para sua conveniência:
À primeira vista, a arquitetura Apache HBase parece seguir um modelo mestre/escravo onde o mestre recebe todas as solicitações, mas o trabalho real é feito pelos escravos. Este não é realmente o caso, e neste artigo descreverei quais tarefas são de fato tratadas pelo mestre e pelos escravos.
Regiões e servidores de região
O HBase é o gerenciador de armazenamento do Hadoop que fornece leituras e gravações aleatórias de baixa latência no HDFS e pode lidar com petabytes de dados. Um dos recursos interessantes do HBase é o auto-sharding, que significa simplesmente que as tabelas são distribuídas dinamicamente pelo sistema quando se tornam muito grandes.
A unidade básica de escalabilidade horizontal no HBase é chamada de Região . As regiões são um subconjunto dos dados da tabela e são essencialmente um intervalo contíguo e classificado de linhas armazenadas juntas.
Inicialmente, há apenas uma região para uma tabela. Conforme mostrado abaixo, quando as regiões se tornam muito grandes após a adição de mais linhas, a região é dividida em duas na chave do meio, criando duas metades aproximadamente iguais.
No HBase os escravos são chamados de Servidores de Região . Cada Region Server é responsável por atender a um conjunto de regiões e uma região (ou seja, intervalo de linhas) pode ser atendida apenas por um Region Server.
A arquitetura HBase possui dois serviços principais:HMaster que é responsável por coordenar o cluster e executar as operações administrativas, e o HRegionServer responsável por manipular um subconjunto dos dados da tabela.
HMaster, atribuição de região e balanceamento
Conforme mencionado anteriormente, o HBase Master coordena o Cluster HBase e é responsável pelas operações administrativas.
Um servidor de região pode atender a uma ou mais regiões. Cada região é atribuída a um servidor de região na inicialização e o mestre pode decidir mover uma região de um servidor de região para outro como resultado de uma operação de balanceamento de carga. O mestre também trata as falhas do Region Server atribuindo a região a outro Region Server.
O mapeamento de Regiões e Servidores de Região é mantido em uma tabela de sistema chamada META. Ao ler META, você pode identificar qual região é responsável pela sua chave. Isso significa que para operações de leitura e escrita, o mestre não está envolvido e os clientes podem ir diretamente ao Servidor de Região responsável por servir os dados solicitados.
Localizando uma chave de linha:qual servidor de região é responsável?
Para colocar ou obter uma linha os clientes não precisam entrar em contato com o master, os clientes podem entrar em contato diretamente com o Region Server que trata a linha especificada, ou no caso de uma varredura de cliente, podem contatar diretamente o conjunto de Region Servers responsáveis por tratar do conjunto de chaves:
Para identificar o Region Server, o cliente faz uma consulta na tabela META.
META é uma tabela de sistema usada para rastrear regiões. Ele contém o nome do servidor e um identificador de região que inclui um nome de tabela e a chave de linha inicial. Observando a chave de início e a chave de início da próxima região, os clientes são capazes de identificar o intervalo de linhas contido em uma região específica.
O cliente mantém um cache para os locais da região. Isso evita que os clientes acessem a tabela META toda vez que uma operação na mesma região for emitida. No caso de uma divisão de região ou mudança para outro Servidor de Região (devido a políticas de balanceamento ou atribuição), o cliente receberá uma exceção como resposta e o cache será atualizado buscando as informações atualizadas da tabela META:
Como o META é uma tabela como as demais, o cliente deve identificar em qual servidor o META está localizado. As localizações META são armazenadas em um nó ZooKeeper por atribuição do Mestre, e o cliente lê diretamente o nó para obter o endereço do Servidor de Região que contém META.
O design original do HBase foi baseado no BigTable, com outra tabela chamada -ROOT- contendo os locais META e o Apache ZooKeeper apontando para ela. O HBase 0.96 removeu esse arranjo em favor do ZooKeeper apenas, uma vez que o META não pode ser dividido e, portanto, consiste em uma única região.
API do cliente:responsabilidades do mestre e das regiões
A API do cliente Java HBase tem duas interfaces principais:
- HBaseAdmin permite a interação com o “esquema de tabela” criando/excluindo/modificando tabelas e permite a interação com o cluster atribuindo/desatribuindo regiões, mesclando regiões, solicitando uma limpeza e assim por diante. Essa interface se comunica com o mestre.
- HTable permite que o cliente manipule os dados de uma tabela especificada usando get, put, delete e todas as outras operações de dados. Essa interface se comunica diretamente com os Region Servers responsáveis por manipular o conjunto de chaves solicitado.
Essas duas interfaces têm responsabilidades separadas:HBaseAdmin é usado apenas para executar operações administrativas e se comunicar com o Mestre enquanto o HTable é usado para manipular dados e se comunicar com as Regiões.
Conclusão
Como vimos aqui, ter uma arquitetura Master/Slave não significa que cada operação passe pelo master. Para ler e gravar dados, o cliente HBase, na verdade, vai diretamente para o Region Server específico responsável por manipular as chaves de linha para todas as operações de dados (HTable). O mestre é usado pelo cliente apenas para operações de criação, modificação e exclusão de tabela (HBaseAdmin).
Embora exista o conceito de um mestre, o cliente HBase não depende dele para operações de dados e o cluster pode continuar servindo dados mesmo se o mestre ficar inativo.
Matteo Bertozzi é engenheiro de software na equipe da plataforma e um HBase Committer.
Se você estiver interessado no HBase, certifique-se de se inscrever no HBaseCon 2013 (13 de junho, São Francisco) – O evento da comunidade para colaboradores, desenvolvedores, administradores e usuários do HBase. O espaço é limitado!
