O Cloudera Data Platform (CDP) fornece uma solução pronta para uso que permite que as implantações do Apache HBase usem o Amazon Simple Storage Service (S3) como sua principal camada de persistência para salvar dados de tabela. O Amazon S3 é um armazenamento de objetos que oferece um alto grau de durabilidade com uma estrutura de custo pay-per-use. Não há nenhum componente do lado do servidor para executar ou gerenciar para o S3 — tudo o que é necessário é a biblioteca de cliente do S3 e as credenciais da AWS. No entanto, o HBase requer um sistema de arquivos consistente e atômico, o que significa que ele não pode usar diretamente o S3 porque é um armazenamento de objetos eventualmente consistente. Tanto o CDH quanto o HDP forneceram apenas o HBase usando o HDFS porque houve impedimentos de longa data que impediram o HBase de usar o S3 nativamente. Para resolver esses problemas, criamos uma solução pronta para uso que estamos entregando pela primeira vez via CDP. Quando você inicia um cluster de banco de dados operacional (HBase) no CDP, HBase StoreFiles (os arquivos de apoio para tabelas HBase) são armazenados no S3 e os logs de gravação antecipada (WAL) do HBase são armazenados em uma instância HDFS executada junto com o HBase normalmente.
Descreveremos brevemente cada componente que entra nessa arquitetura e a função que cada um cumpre.
O adaptador do sistema de arquivos S3A é fornecido pelo Hadoop para acessar dados no S3 por meio das APIs FileSystem padrão. O adaptador S3A permite que aplicativos escritos em APIs do Hadoop acessem dados no S3 usando um URI no formato “s3a://my_bucket/” em vez de “hdfs://namenode:8020/” como no HDFS. A capacidade de especificar um “sistema de arquivos” padrão a ser usado torna as migrações de estilo “lift-and-shift” de clusters locais com HDFS para clusters baseados em nuvem com S3 extremamente simples. O HBase pode ser configurado com um local de armazenamento básico (por exemplo, um diretório no HDFS ou um bucket do S3) para todos os dados do aplicativo que permitem que o HBase funcione da mesma forma, independentemente de esses dados estarem no HDFS ou no S3.
O S3Guard faz parte do projeto Apache Hadoop que fornece uma lista de diretórios consistente e status de objeto para o adaptador S3A, transparente para o aplicativo. Para fazer isso, o S3Guard usa um banco de dados consistente e distribuído para rastrear as alterações feitas no S3 e garante que um cliente sempre veja o estado correto do S3. Sem o S3Guard, o HBase pode não ver um novo StoreFile que foi adicionado a uma tabela HBase. Se o HBase não observar um arquivo temporariamente, isso pode causar perda de dados no HBase. No entanto, o S3guard não fornece tudo o que o HBase precisa para usar o S3.
HBase Object Store Semantics (ou apenas “HBOSS”) é um novo projeto de software sob o projeto Apache HBase construído especificamente para preencher a lacuna entre o S3Guard e o HBase. HBOSS é uma fachada em cima do adaptador S3A e S3Guard que usa um bloqueio distribuído para garantir que as operações do HBase possam atomicamente manipular seus arquivos no S3. Um exemplo em que o HBase requer atomicidade é uma renomeação de diretório. Com o cliente S3, uma renomeação é implementada como uma cópia dos dados de origem para o destino, seguida de uma exclusão dos dados de origem. Sem o bloqueio fornecido pelo HBOSS, o HBase pode ver a operação de renomeação em andamento, o que pode causar perda de dados. Para realizar esse bloqueio distribuído, o HBOSS usa o Apache ZooKeeper. A reutilização do ZooKeeper ocorre por design, pois o HBase já requer uma instância do ZooKeeper para garantir que todos os serviços do HBase estejam operando juntos. Assim, a incorporação do HBOSS não requer carga adicional de gerenciamento de serviços e fecha a lacuna sobre o que o HBase exige para usar o S3 com o S3Guard.
Configurar o HBase para usar o S3 para seus StoreFiles traz muitos benefícios para nossos usuários. Um desses benefícios é que os usuários podem dissociar seu armazenamento e computação. Se houver momentos em que nenhum acesso ao HBase for necessário, o HBase poderá ser encerrado de forma limpa e todos os recursos de computação recuperados para eliminar qualquer custo de operação. Quando o acesso HBase é necessário novamente, o cluster HBase pode ser recriado, apontando para os mesmos dados no S3. Na inicialização, o HBase pode reinicializar-se apenas a partir dos dados no S3.
Usar o S3 para armazenar HBase StoreFiles tem alguns desafios. Um desses problemas é o aumento da latência para uma pesquisa aleatória em um arquivo no S3 em comparação com o HDFS. O aumento da latência no acesso ao S3 resultaria em um HBase Gets and Scans demorando mais do que normalmente levaria com HDFS. As latências S3 variam de 10 a 100 milissegundos em comparação com o intervalo de 0,1 a 9 milissegundos com HDFS. O CDP pode reduzir o impacto dessa latência do S3 configurando automaticamente o HBase para usar o BucketCache. Com o BucketCache habilitado, as latências do S3 são experimentadas apenas na primeira vez que um StoreFile é lido do S3. Depois que o HBase ler um arquivo, ele tentará armazenar em cache os dados brutos para substituir as leituras lentas do S3 por leituras rápidas da memória local. Quando um cluster HBase é iniciado via CDP, ele é configurado automaticamente para armazenar em cache os dados lidos recentemente do S3 na memória para fornecer leituras mais rápidas de dados “quentes”.
Estamos extremamente satisfeitos em fornecer esses novos recursos aos nossos usuários. Experimente o HBase em execução no S3 no modelo de banco de dados operacional no CDP hoje mesmo!
