O HBase MasterServer - dummies

Iniciando uma discussão da arquitetura HBase (banco de dados Hadoop), descrevendo RegionServers em vez do MasterServer pode surpreendê-lo. O termo RegionServer parece implicar que depende de (e é secundário para) o MasterServer e que, portanto, você deve discutir o MasterServer primeiro. Como a velha canção diz, "não é necessariamente assim. "

Os RegionServers dependem do MasterServer para certas funções, mas não no sentido de um relacionamento mestre-escravo para armazenamento e recuperação de dados. No canto superior esquerdo da figura, observe que os clientes não apontam para o servidor MasterServer, mas apontar para o cluster Zookeeper e RegionServers.

O MasterServer não está no caminho do armazenamento e acesso de dados - esse é o trabalho do cluster do Zookeeper e do RegionServers. Dê uma olhada nas principais funções do MasterServer, que também é um processo de software (ou daemon) como o RegionServers. O MasterServer está para

• Monitorar os RegionServers no cluster HBase: O MasterServer mantém uma lista de RegionServers ativos no cluster HBase.

• Gerencie as operações de metadados: Quando uma tabela é criada ou seus atributos são alterados (configuração de compressão, configurações de cache, versões e mais), o MasterServer lida com a operação e armazena os metadados necessários.

• Atribuir regiões: O MasterServer atribui regiões a RegionServers.

• Gerenciar o failover do RegionServer: Como em qualquer cluster distribuído, você espera que as falhas do nó não ocorram e você planeja para eles de qualquer maneira. Quando os servidores da região falham, o Zookeeper notifica o MasterServer para que as operações de failover e restauração possam ser iniciadas.

• Supervisionar o balanceamento de carga das regiões em todos os RegionServers disponíveis: Você pode lembrar que as tabelas são constituídas por regiões que são distribuídas uniformemente em todos os RegionServers disponíveis. Este é o trabalho do thread do balanceador (ou chore , se você preferir), o qual o MasterServer se ativa periodicamente.

• Gerenciar (e limpar) as tabelas de catálogo: Duas tabelas de catálogo de chaves são usadas pelo sistema HBase para ajudar um cliente a encontrar um par de valores de chave específico no sistema.

  O MasterServer fornece o gerenciamento dessas tabelas críticas em nome do sistema HBase geral.

• Limpe o WAL: O MasterServer interage com o WAL durante o failover RegionServer e limpa periodicamente os logs.

• Fornecer uma estrutura de coprocessador para observar as operações principais: Aqui está outro novo termo para o seu glossário crescente do HBase. Coprocessadores são executados no contexto do MasterServer ou RegionServers. Por exemplo, um coprocessador de observador MasterServer permite que você altere ou amplie a funcionalidade normal do servidor quando ocorrem operações como criação de tabela ou exclusão de tabela. Muitas vezes, os coprocessadores são usados ​​para gerenciar índices de tabela para aplicativos HBase avançados.

Um coprocessador, que é executado no contexto do MasterServer e / RegionServer (ou ambos), pode ser usado para aprimorar a segurança, criar índices secundários e muito mais. Você pode encontrar mais informações sobre coprocessadores em um blog da comunidade HBase.

Tal como acontece com todas as tecnologias Hadoop de código aberto, as operações do MasterServer provavelmente mudarão ao longo do tempo, à medida que a comunidade de engenheiros trabalha em inovações projetadas para melhorar a HBase. A partir desta escrita, no entanto, você agora possui uma lista bastante completa que serve como uma referência de alto nível para o MasterServer.

Finalmente, um ponto mais importante a fazer sobre o HBase MasterServer: pode e deve ser um servidor MasterServer de backup em qualquer cluster HBase. Deve haver apenas um servidor mestre ativo em qualquer momento, de modo que o backup MasterServer é para fins de failover.

Você pode se lembrar que o MasterServer não está no caminho de acesso a dados para clientes HBase. No entanto, você também pode lembrar que o MasterServer é responsável por ações como failover RegionServer e balanceamento de carga. A boa notícia é que os clientes podem continuar a consultar o cluster HBase se o mestre cair, mas para operações de cluster normais, o mestre não deve permanecer pendente durante algum período de tempo.