Apache HBase é o banco de dados Hadoop e é baseado no Hadoop Distributed File System (HDFS ). O HBase possibilita o acesso aleatório e a atualização de dados armazenados no HDFS, mas os arquivos no HDFS só podem ser anexados e são imutáveis depois de criados. Então você pode perguntar, como o HBase fornece leituras e gravações de baixa latência? Nesta postagem do blog, explicamos isso descrevendo o caminho de gravação do HBase — como os dados são atualizados no HBase.
O caminho de gravação é como um HBase conclui as operações put ou delete. Esse caminho começa em um cliente, passa para um servidor de região e termina quando os dados eventualmente são gravados em um arquivo de dados HBase chamado HFile . Incluídos no design do caminho de gravação estão os recursos que o HBase usa para evitar a perda de dados no caso de uma falha do servidor regional. Portanto, entender o caminho de gravação pode fornecer informações sobre o mecanismo de prevenção de perda de dados nativo do HBase.
Cada tabela HBase é hospedada e gerenciada por conjuntos de servidores que se enquadram em três categorias:
- Um servidor mestre ativo
- Um ou mais servidores mestre de backup
- Muitos servidores de região
Os servidores de região contribuem para manipular as tabelas do HBase. Como as tabelas do HBase podem ser grandes, elas são divididas em partições chamadas regiões. Cada servidor de região lida com uma ou mais dessas regiões. Observe que, como os servidores de região são os únicos servidores que fornecem dados de tabela do HBase, uma falha do servidor mestre não pode causar perda de dados.
Os dados do HBase são organizados de maneira semelhante a um mapa classificado, com o espaço de chave classificado particionado em diferentes fragmentos ou regiões. Um cliente HBase atualiza uma tabela chamando os comandos put ou delete. Quando um cliente solicita uma alteração, essa solicitação é roteada imediatamente para um servidor regional por padrão. No entanto, programaticamente, um cliente pode armazenar em cache as alterações no lado do cliente e liberar essas alterações nos servidores da região em um lote, desativando o autoflush. Se o autoflush estiver desativado, as alterações serão armazenadas em cache até que o flush-commits seja invocado ou o buffer esteja cheio dependendo do tamanho do buffer definido programaticamente ou configurado com o parâmetro “hbase.client.write.buffer”.
Como a chave de linha é classificada, é fácil determinar qual servidor de região gerencia qual chave. Uma solicitação de alteração é para uma linha específica. Cada chave de linha pertence a uma região específica que é atendida por um servidor de região. Assim, com base na chave put ou delete, um cliente HBase pode localizar um servidor de região adequado. Primeiramente, ele localiza o endereço do servidor de região que hospeda a região -ROOT- do quorum do ZooKeeper. A partir do servidor da região raiz, o cliente descobre a localização do servidor da região que hospeda a região -META-. A partir do servidor de meta-região, finalmente localizamos o servidor de região real que atende à região solicitada. Este é um processo de três etapas, portanto, a localização da região é armazenada em cache para evitar essa série cara de operações. Se o local armazenado em cache for inválido (por exemplo, recebemos alguma exceção de região desconhecida), é hora de realocar a região e atualizar o cache.
Depois que a solicitação é recebida pelo servidor da região correta, a alteração não pode ser gravada em um HFile imediatamente porque os dados em um HFile precisam ser classificados pela chave de linha. Isso permite a busca por linhas aleatórias de forma eficiente ao ler os dados. Os dados não podem ser inseridos aleatoriamente no HFile. Em vez disso, a alteração deve ser gravada em um novo arquivo. Se cada atualização fosse gravada em um arquivo, muitos arquivos pequenos seriam criados. Tal solução não seria escalável nem eficiente para mesclar ou ler posteriormente. Portanto, as alterações não são gravadas imediatamente em um novo HFile.
Em vez disso, cada alteração é armazenada em um local na memória chamado memstore , que oferece suporte a gravações aleatórias de maneira barata e eficiente. Os dados no memstore são classificados da mesma maneira que os dados em um HFile. Quando o memstore acumula dados suficientes, todo o conjunto classificado é gravado em um novo HFile no HDFS. A conclusão de uma grande tarefa de gravação é eficiente e aproveita os pontos fortes do HDFS.
Embora a gravação de dados no memstore seja eficiente, ela também apresenta um elemento de risco:as informações armazenadas no memstore são armazenadas na memória volátil, portanto, se o sistema falhar, todas as informações do memstore serão perdidas. Para ajudar a mitigar esse risco, o HBase salva as atualizações em um registro de gravação antecipada (WAL ) antes de gravar as informações no memstore. Dessa forma, se um servidor de região falhar, as informações armazenadas no memstore desse servidor podem ser recuperadas de seu WAL.
Observação:por padrão, o WAL está habilitado, mas o processo de gravação do arquivo WAL no disco consome alguns recursos. O WAL pode estar desabilitado, mas isso só deve ser feito se o risco de perda de dados não for uma preocupação. Se você optar por desabilitar o WAL, considere implementar sua própria solução de recuperação de desastres ou esteja preparado para a possibilidade de perda de dados.
Os dados em um arquivo WAL são organizados de forma diferente do HFile. Os arquivos WAL contêm uma lista de edições, com uma edição representando um único put ou delete. A edição inclui informações sobre a alteração e a região à qual a alteração se aplica. As edições são gravadas cronologicamente, portanto, para persistência, as adições são anexadas ao final do arquivo WAL armazenado no disco. Como os arquivos WAL são ordenados cronologicamente, nunca há necessidade de gravar em um local aleatório dentro do arquivo.
À medida que os WALs crescem, eles são eventualmente fechados e um novo arquivo WAL ativo é criado para aceitar edições adicionais. Isso é chamado de “rolar” o arquivo WAL. Depois que um arquivo WAL é rolado, nenhuma alteração adicional é feita no arquivo antigo.
Por padrão, o arquivo WAL é rolado quando seu tamanho é cerca de 95% do tamanho do bloco HDFS. Você pode configurar o multiplicador usando o parâmetro:“hbase.regionserver.logroll.multiplier”, e o tamanho do bloco usando o parâmetro:“hbase.regionserver.hlog.blocksize”. O arquivo WAL também é rolado periodicamente com base no intervalo configurado “hbase.regionserver.logroll.period”, uma hora por padrão, mesmo que o tamanho do arquivo WAL seja menor que o limite configurado.
Restringir o tamanho do arquivo WAL facilita a reprodução eficiente do arquivo se for necessária uma recuperação. Isso é especialmente importante durante a reprodução do arquivo WAL de uma região porque, enquanto um arquivo está sendo reproduzido, a região correspondente não está disponível. A intenção é eventualmente gravar todas as alterações de cada arquivo WAL no disco e persistir esse conteúdo em um HFile. Depois disso, o arquivo WAL pode ser arquivado e, eventualmente, excluído pelo encadeamento do daemon LogCleaner. Observe que os arquivos WAL servem como medida de proteção. Os arquivos WAL só precisam ser reproduzidos para recuperar atualizações que, de outra forma, seriam perdidas após uma falha do servidor regional.
Um servidor de região atende a muitas regiões, mas não possui um arquivo WAL para cada região. Em vez disso, um arquivo WAL ativo é compartilhado entre todas as regiões atendidas pelo servidor da região. Como os arquivos WAL são rolados periodicamente, um servidor de região pode ter muitos arquivos WAL. Observe que há apenas um WAL ativo por servidor de região em um determinado momento.
Assumindo a raiz padrão do HBase de “/hbase”, todos os arquivos WAL para uma instância do servidor de região são armazenados na mesma pasta raiz, que é a seguinte:
/hbase/.logs/<host>, <port>,<startcode>
Por exemplo:
/hbase/.logs/srv.example.com,60020,1254173957298
Os arquivos de log do WAL são nomeados da seguinte forma:
/hbase/.logs/<host>, <port>,<startcode>/<host>%2C <port>%2C<startcode>.<timestamp>
Por exemplo:
/hbase/.logs/srv.example.com,60020,1254173957298/srv.example.com%2C60020%2C1254173957298.1254173957495
Cada edição no arquivo WAL tem um ID de sequência exclusivo. Este id aumenta para preservar a ordem das edições. Sempre que um arquivo de log é rolado, o próximo id de sequência e o nome do arquivo antigo são colocados em um mapa na memória. Essas informações são usadas para rastrear o ID de sequência máximo de cada arquivo WAL para que possamos descobrir facilmente se um arquivo pode ser arquivado posteriormente, quando algum memstore for liberado para o disco.
As edições e seus IDs de sequência são exclusivos em uma região. Sempre que uma edição é adicionada ao log do WAL, o ID de sequência da edição também é registrado como o último ID de sequência gravado. Quando o memstore é liberado para o disco, o último id de sequência gravado para essa região é apagado. Se o último ID de sequência gravado no disco for o mesmo que o ID de sequência máximo de um arquivo WAL, pode-se concluir que todas as edições em um arquivo WAL para essa região foram gravadas no disco. Se todas as edições de todas as regiões em um arquivo WAL tiverem sido gravadas em disco, fica claro que nenhuma divisão ou reprodução será necessária e o arquivo WAL pode ser arquivado.
A rolagem do arquivo WAL e a liberação do memstore são duas ações separadas e não precisam acontecer juntas. No entanto, não queremos manter muitos arquivos WAL por servidor de região para evitar uma recuperação demorada em caso de falha do servidor de região. Portanto, quando um arquivo WAL é rolado, o HBase verifica se há muitos arquivos WAL e decide quais regiões devem ser liberadas para que alguns arquivos WAL possam ser arquivados.
Neste post, explicamos o caminho de gravação do HBase, que é como os dados no HBase são criados e/ou atualizados. Algumas partes importantes dele são:
- Como um cliente localiza um servidor de região,
- Memstore que suporta gravações aleatórias rápidas,
- Arquivos WAL como forma de evitar a perda de dados em caso de falhas no servidor da região.
Falaremos sobre os formatos HFile, divisão de arquivos WAL e assim por diante nos próximos posts.
