Saltar para o conteúdo principal

Apache HBase

Base de dados NoSQL

Apache HBase icon

O Modelo NoSQL (no SQL ou not only SQL) representa bases de dados não relacionais (ou não somente relacionais, conforme definições mais recentes). Trata-se de uma classe de Base de Dados que disponibiliza mecanismos de armazenamento e recuperação de dados modelados de formas diferentes das relações tabulares usadas pelas bases de dadps relacionais.

Estas bases de dados existem desde a década de 1960, mas alcançaram popularidade na década de 2000, desencadeada pelas necessidades de empresas como Facebook, Google e Amazon.com. São cada vez mais usados em Big Data e aplicações Web em tempo real.

As Bases de Dados NoSQL podem admitir linguagens de consulta similares à SQL.

Figura 1 - Modelos de base de dados
Figura 1 - Modelos de base de dados

Características do Apache HBase​

HBase é uma Base de Dados distribuído, de código aberto, não-relacional ("NoSQL"), orientado a colunas, que executa sobre o HDFS, criado para disponibilizar acesso aleatório eficiente e leitura/escrita em tempo real em grandes conjuntos de dados distribuídos.

Foi criado pela empresa Powerset para hospedar tabelas muito grandes e, posteriormente, absorvido pela Fundação Apache como parte do Projeto Hadoop, tornando-se uma ótima opção para combinar e armazenar dados multi-estruturados e esparsos.

O HBase está integrado nativamente com o Hadoop e funciona perfeitamente ao lado de outros "motores" de acesso a dados, através do YARN. Possui muitos recursos que suportam escalabilidade linear e modular.

Seus Clusters se expandem pela adição de RegionServers que são hospedados em servidores "commodity class" (hardware comum). Se um Cluster se expande de 10 para 20 RegionServers, por exemplo, ele dobra sua capacidade de armazenamento e processamento.

Suas principais características incluem:

  • Leitura e Escrita consistentes: O HBase é um DataStore consistente, o que o torna muito adequado para tarefas como high speed counter aggregation.

  • Fragmentação" automática: As tabelas HBase são distribuídas no Cluster via Regions(regiões), e estas regiões são automaticamente divididas e redistribuidas à medida que os dados "crescem".

  • Tolerância à falhas automática do RegionServer: Os dados de entrada "residem" em regiões disponibilizadas pelos RegionServers . Se um RegionServer falhar, o servidor mestre designará outro para assumir as regiões que foram tratadas pelo RegionServer com falha.

  • Integração Hadoop/HDFS: HBase suporta HDFS nativamente (pronta a usar) como seu sistema de ficheiros distribuídos.

  • Suporte ao MapReduce: : O HBase oferece suporte a processamento fortemente paralelizado via MapReduce, atuando tanto como fonte quanto como coletor.

  • API Java Client: HBase suporta API Java "easy to use" para acesso programático.

  • API Thrift/REST:: HBase suporta Thrift e REST para "front-ends" não-Java.

  • Block-cache e Bloom Filters: HBase oferece suporte para high volume query otimization .

  • Gerenciamento Operacional: HBase provê Web pages integradas para visibilidade operacional e métricas JMX.

  • Alta disponibilidade: HBase provê alta disponibilidade com:

    • Informações de topologia de Cluster altamente disponíveis através de implementações de produção com múltiplas instâncias HMaster e Zookeeper.
    • Distribuição de dados em vários nós garantindo que a perda dum único nó afete somente os dados armazenados nesse nó.
    • HBase HA permite o armazenamento de dados, garantindo que a perda dum único nó não resulte na perda de disponibilidade de dados.
    • O formato HFile armazena dados diretamente no HDFS e pode ser lido ou escrito por Apache Hive, Apache PIg, MapReduce e Apache Tez, favorecendo análises profundas no HBase sem movimentação de dados.
Figura 2 - Interface HBase
Figura 2 - Interface HBase

Arquitetura do Apache HBase​

A arquitetura do HBase também segue o modelo mestre/escravo e é formada por três componentes principais:

  • HMaster (Servidor mestre):: é um processo responsável por designar regiões para Region Servers no Cluster Hadoop para balanceamento de carga. É responsável pela monitorização de todas as instâncias de Region Server no Cluster HBase, e age como uma interface para todas as mudanças de metadados.
    O master tipicamente é executado num servidor dedicado, dentro do Cluster Hadoop.
    Existem outros masters em standby disponíveis para substituição em caso de indisponibilidade e o Zookeeper cuida disso.

    note

    É possível que o master fique inativo por algum tempo e é possível o Cluster Hadoop trabalhar sem ele durante este período, mas é sempre bom reativar o master o mais breve possível, porque ele conduz algumas funcionalidades criticas como:

    • Gerenciamento e monitorização do Cluster Hadoop;
    • Controlo do failover
    • Atribuição de regiões aos Region Servers , com apoio do Zookeeper.
    • Balanceamento de carga das regiões entre os Region Servers.
    • Alterações de esquema e outras operações de Metadados.
    • Operações DDL, como criação e exclusão de tabelas.

  • Regionservers: mantêm as múltiplas regiões designadas pelo HMaster. Várias regiões são combinadas num único RegionServer. São responsáveis pela comunicação cliente e por executar todas as operações relacionadas a dados. Qualquer requisição de leitura ou escrita para as regiões são conduzidas pelo Region Server.
    O Region Server é implementado pelo HRegionServer e executa em todo nó de dados no Cluster HBase. É composto pelos seguintes componentes:

    • Write-Ahead Log (WAL): O WAL(registo de escrita antecipada) regista todas as alterações de dados do HBase. Numa situação normal, ele não é necessário, pois as mudanças de dados são movidas do MemStore para os StoreFiles Entretanto, se um RegionServer travar ou ficar indisponível antes que o MemStore seja liberado, o WAL garante que as mudanças possam ser repetidas. Se a escrita no WAL falhar, toda a operação falha.
      O WAL é anexado a cada Region Server. Usualmente, existe apenas uma única instância de WAL por Region Server. A exceção é o RegionServer que carrega a tabela HBase:meta. A tabela tem seu próprio WAL dedicado.

    • Block Cache:: Block Cache reside no Region Server e é responsável pelo armazenamento de dados acessados com frequência, na memória, auxiliando no incremento da desempenho.
      O Block Cache segue o conceito least recently used(LRU), em que registos menos utilizados recentemente serão removidos.

    • MemStore: É um cache de gravação. Uma memória temporária para todos os dados de entrada. Responsável por armazenar dados ainda não gravados no disco. Existem múltiplos MemStores no Cluster HBase.

    • HFile: São os ficheiros ou células nos quais são armazenados os dados. Quando o MemStore está cheio, grava dados no HFile, no disco.

  • Regions: São o elemento basico de disponibilidade e distribuição de tabelas. São compostos por uma Column Family. Tabelas HBase são divididas por intervalos row key nas regiões. Todas as linhas entre region start key e region end key estarão disponíveis na região. Cada região é designada para um region server , que gerencia as solicitações leitura/escrita para esta região.
    Como regiões são blocos básicos de escalabilidade no HBase, é recomendado um baixo número de regiões por Region Server para garantir alto desempenho. A arquitetura HBase usa um processo de fragmentação automática para manter os dados. Neste processo, sempre que uma tabela HBase fica muito longa, é distribuída pelo sistema com o auxílio do HMaster.

  • Zookeeper: Zookeeper realiza a coordenação distribuída, provendo regiões para os Region Servers e também recuperando regiões, no caso de falha do Region Server, carregando-as em outros Region Servers. Se um cliente deseja partilhar ou permutar com regiões, precisa abordar o Zookeeper antes.
    O serviço HMaster e todos os Region Servers são registados com o serviço ZooKeeper.
    O Cliente acessa o ZooKeeper para conectar-se com Region Servers e HMaster. Em caso de falha num nó do Cluster HBase, o ZKquoram do Zookeeper ativará mensagem de erro e iniciará o repaire failed nodes.
    O serviço ZooKeeper mantém e acompanha todos os Region Servers no Cluster HBase e coleta informações como número de Region Servers , datanodes designados, etc. É também responsável por estabelecer a comunicação cliente com Region Servers , mantendo o controlo de falhas de servidor e partições de rede, informações de configuração, etc.

Figura 3 - Arquitetura HBase
Figura 3 - Arquitetura HBase

Como o Apache HBase funciona​

HBase escala linearmente, exigindo que todas as tabelas tenham uma chave primária. O espaço da chave está dividido em blocos sequenciais que são, então, atribuídos a uma região.

Os RegionServers possuem uma ou mais regiões, de modo que a carga seja distribuída uniformemente em todo o Cluster. Se as chaves dentro de uma região são frequentemente acessadas, o HBase pode subdividir a região de modo que o corte manual de dados não seja necessário.

Os servidores do Zookeeper e HMaster disponibilizam informações sobre a topologia de Cluster aos clientes. Os clientes se conectam a estes e baixam:

  • a lista de RegionServers,
  • as regiões contidas nesses RegionServers, e
  • os intervalos de chaves hospedados pelas regiões.

Como os clientes sabem exatamente onde está cada informação no HBase, podem entrar em contacto diretamente com o RegionServer sem necessidade dum "coordenador central".

Regionserver inclui uma memstore para armazenar em cache as linhas frequentemente acessadas na memória.

Modelo de Dados HBase​

No HBase os dados são armazenados em tabelas, que possuem linhas e colunas, podendo, sua estrutura, ser entendida como um mapa multidimensional.

Seus principais componentes são:

  • Tabelas: Como a arquitetura HBase é orientada a colunas, os dados são armazenados em tabelas que estão no formato tabular. Estas tabelas são declaradas antecipadamente no momento da definição do "esquema". Uma tabela consiste em várias linhas.

  • Rowkey: Uma linha no HBase corresponde a uma Rowkey e uma ou mais colunas com valores associadas a ela. As linhas são classificadas alfabeticamente pela RowKey à medida em que são armazenadas.

  • Colunas: Uma coluna no HBase consiste numa família de colunas (column_family) e um qualificador de coluna delimitados por um caractere ":" (dois pontos). São os diferentes atributos do dataset. Cada Rowkey pode ter um número ilimitado de colunas.

    • As colunas não são definidas previamente na estrutura, como na Base de Dados Relacional.
    • Não é obrigatório que todas as colunas estejam presentes em todas as linhas.
    • As colunas não armazenam valores nulos.
    • Todas as colunas de uma Column Family são armazenadas juntas num ficheiro(HFile) juntamente com a Rowkey.

    Column Family: São o agrupamento de várias colunas. Uma simples requisição de leitura a uma column family dá acesso a todas as colunas daquela familia, tornando rápida e fácil a leitura do dado. Uma tabela deve ter pelo menos uma Column Family, que é criada com a tabela.

  • Qualificadores de coluna (Column Qualifiers): São como títulos das colunas ou nomes de atributos numa tabela normal. Um qualificador de colunas é adicionado a uma column family para disponibilizar o índice para um determinado dado.

  • Célula: É uma combinação entre linha, column family e qualificador de coluna e contém um valor e um timestamp, que representa a versão do valor.

  • Timestamp: O dado é armazenado no modelo de dados HBase com um Timestamp. O Timestamp é escrito ao lado de cada valor e é o identificador para uma determinada versão do valor.

Namespace​

Namespace consiste dum agrupamento lógico de tabelas análogas a uma Base de Dados em sistemas de SGBD relacionais. Essa abstração estabelece as bases para recursos de multilocação:

Operações do Modelo de Dados HBase​

Como todo database, o HBase suporta um conjunto de operações básicas referenciadas como CRUD (Criação, Exclusão, leitura e atualização).

Versões​

Uma tupla (linha, coluna, versão) especifica uma célula. É possível haver um número de células ilimitado, onde a linha e colunas são as mesmas mas o endereço da célula difere em sua dimensão versão.

Joins​

HBase não suporta joins (junções) na forma como os RDBMS. As leituras do HBase são Get e Scan. Para viabilizar o join, existem duas estratégias:

  • Desnormalizar os dados ao gravar no Hbase.
  • Ter tabelas de pesquisa e fazer a junção entre as tabelas HBase e um aplicativo ou código MapReduce.

A melhor estratégia depende do que se deseja fazer.

HBase e Design do Schema​

Projetar um Schema para Bigtable é diferente de projetar um schema para a Base de Dados relacional. No Bigtable, um esquema é um blueprint ou modelo de uma tabela, incluindo a estrutura dos componentes da tabela.

No Bigtable, um esquema é um blueprint ou modelo de uma tabela, incluindo a estrutura dos componentes da tabela a seguir:

  • Rowkeys
  • Grupos de Colunas (incluindo as políticas de coleta de lixo)
  • Colunas

Os principais conceitos que se aplicam ao design do Schema em Bigtable são:

  • Bigtable é uma armazenamento de chave/valor, não um armazenametno relacional. Ele não é compativel com "mesclagens" e as transações são compatíveis apenas com uma única linha.
  • Cada tabela possui apenas um índice: a rowkey. Não há indices secundários. Cada rowkey precisa ser única.
  • As linhas são classificadas lexicograficamente por rowkey, da string que tem menos bytes para a que tem mais.
  • Os grupos de colunas não são armazenados em alguma ordem específica.
  • As colunas são reunidas por grupo e classificadas em ordem lexicográfica dentro desse grupo.
  • A intersecção de uma linha e coluna pode contér várias células com timestamp de data/hora. Cada célula contém uma versão exclusiva e com timestamp dos dados para essa linha e coluna.
  • Todas as operações são atômicas no nível da linha. Uma operação afeta uma linha inteira ou nenhuma linha.
  • O ideal é leituras e gravações distribuídas por igual pelo espaço da linha de uma tabela.
  • As tabelas do Bigtable são esparsas. Uma coluna não ocupa espaço numa linha que não usa a coluna.

A comunidade Hbase indica, para tratar este assunto, o site práticas e recomendações de criação de esquema para maiores detalhes.

Recursos do Apache HBase​

  • Segurança da Interface para o Usuário Web: HBase provê mecanismos para assegurar vários componentes e aspectos e na sua relação com a infraestrutura Hadoop, bem como clientes e recursos externos ao Hadoop.

  • Segurança do acesso pelo cliente ao Apache HBase: As versões mais recentes do Apache HBase suportam autenticação opcional SASL de clientes. A comunidade recomenda a leitura do artigoUnderstanding User Authentication and Authorization in Apache HBase: para maiores detalhes.

  • Segurança no nível de transporte: A partir da versão 2.6.0 o HBase suporta criptografia TLS na comunicação entre o cliente-servidor e Master-RegionServer. TLS é um protocolo criptografico padrão desenhado para prover segurança de comunicações entre redes de computadores.

  • Segurança no acesso ao HDFS e Zookeeper: O HBase requer Zookeeper e HDFS seguros impedir o acesso ou modificação de metadados e dados. HBase use o HDFS para manter seus ficheiros de dados, write ahead logs(WALs) e outros dados. E usa Zookeeper para armazenar algums metadados para operações (endereço master, lock de tabelas, recuperações, etc.)

  • Segurança no acesso aos dados do cliente: A segurança dos dados do cliente também deve ser considerada. Algumas estratégias são oferecidas para isto:

    • Role-based Access Control (RBAC - controlo de Acesso baseado em papéis): Onde usuários e grupos podem ler e gravar num recurso específico ou executar um endpoint coprocessor, usando o paradigma de papéis.

    • Labels de visibilidade que viabilizam a rotulação de células e controlo de acesso às células rotuladas, visando restringir quem pode ler e gravar em determinado subconjunto de dados.

    • Criptografia transparente de dados em repouso no sistema de ficheiros subjacente, tanto HFiles quanto Wal, protegendo dados em repouso de uma invasão.

  • Inmemory compaction (Compactação na memória): A compactação na memória (Aka Acordion) é um novo recurso do HBase - 2.0.0.

  • RegionServer Offheap Read-Write Path (Caminho de leitura e escrita "fora da pilha" RegionServer):
    Para ajudar a reduzir as latências de RPC P99/P999, o Hbase 2.x fez com que o caminho de leitura e escrita usasse um pool de buffers offheap.

  • Backup e Restore : O Backup e Restore do HBase provê a habilidade de criar Backups full e incremental em tabelas do Cluster HBase.

  • Replicação síncrona: A Replicação A replicação no HBase é assincrona. Portanto, se o Cluster Master falhar, o Cluster escravo pode não ter os dados mais atuais. Para garantir consistência o usuário não poderá alternar para o Cluster escravo.

  • APIs: Além das APIs nativas, o HBase suporta APIs externas.

  • Coprocessors:(Co-processadores) O framework de Co-processadores disponibilizam mecanismos para executar códigos customizados diretamente nos RegionServers que gerenciam o dado.

Quando usar o Apache HBase​

O Apache HBase não é adequado para todas as situações.

  • É um bom candidato apenas para situações com um grande volume de dados. Para pequenos e médios volumes de dados, os RDBMS tradicionais podem ser melhores, pois seus dados podem se concentrar num ou dois nós.

  • Não possui tantos recursos extras quantos os RDBMS (colunas digitadas, índices secundários, transações, linguagens avançadas de consulta, etc.).

  • Necessita de estrutura de Hardware adequada. Mesmo o HDFS não funciona bem com menos que 5 DataNodes e 1 NameNode.

Diferença entre Apache HBase e HDFS​

HDFS é um sistema de ficheiros distribuídos adequado para armazenamento de grandes ficheiros. Entretanto, não é um sistema de ficheiros de uso geral e não disponibiliza pesquisas rápidas de registos individuais em ficheiros.

O HBase, por sua vez, é construído sobre o HDFS e disponibiliza pesquisas rápidas de registos (e atualizações) para grandes tabelas.

O HBase, internamente, dispõe seus dados em StoreFiles indexados do HDFS para pesquisas de alta velocidade.

Boas Práticas para o Apache HBase​

  • Hotspotting: Como as linhas do HBase são classificada lexigraficamente por chave de linha (processo que otimiza as varreduras, permitindo que sejam armazenadas linhas relacionadas próximas umas das outras), quando mal projetadas, as chaves de linha podem ser uma fonte de hotspotting (quando uma grande quantidade de tráfego do cliente é direcionada para um nó ou apenas alguns nós, sobrecarregando uma única (ou poucas) máquinas).

    É recomendável projetar padrões de acesso a dados, de forma que o Cluster seja utilizado total e uniformemente.

    Para evitar pontos de acesso nas gravações, é importante projetar chaves de linha de forma que estas estejam na mesma região quando realmente precisam, mas, no quadro geral, os dados sejam gravados em várias regiões do Cluster.

    A Comunidade sugere algumas técnicas para evitar o hotspotting, que podem ser vistasaqui.

  • Seleção de número de Regiões: Na criação de tabelas, no HBase, é possível definir explicitamente o número de regiões para a tabela ou o HBase calculará baseado num algoritmo. É uma boa prática definir o número de regiões para a tabela e isto auxilia, inclusive, na melhoria de desempenho .

  • Escolha o número de column family:
    Quase sempre, temos uma row key e uma column family mas algumas vezes podemos ter mais de uma column family. É boa prática manter o menor número possível de column family e nunca ultrapassar o número de 10 .

  • Balanced Cluster: Um Cluster HBase é considerado "balanceado" quando a maioria dos Region Server tem um número igual de regiões. Você pode desejar ativar o balancer, que balanceará os Clusters a cada 5 minutos.

  • Evitar execução de outro job no Cluster HBase: Os frameworks de integração utilizados para configurar o HBase vêm com outras ferramentas como Hive, Spark, etc. Entratanto, o HBase consome, de forma intensiva, CPU e memória, e, esporadicamente realiza grande acesso sequencial I/O. Portanto, executar outros jobs irá resultar num significativo decremento no desempenho.

  • Evitar compactação "maior", ou completa HBase possui duas formas de compactação: a "menor", que combina um número configurável de Hfiles pequenos num maior e a compactação "maior", quando todos os ficheiros do store são lidos para uma região e gravados num único ficheiro. Isto consome tempo e impede que haja gravações na região até que finalize. É uma boa prática evitar a compactação "maior".

  • Regras práticas para o esquema de tabelas e dimensionamento de Region Servers: Existem diferentes data sets com diferentes padrões de acesso e expectativas de níveis de serviço. Entretanto, a Comunidade apresenta algumas regras gerais que podem ser vistas aqui.

    Além dos itens acima, a Comunidade HBase disponibiliza uma série de recomendações para ajustes do desempenho do HBase, que podem ser lidas aqui.

Detalhes do Projeto Apache HBase​

O HBase foi modelado a partir do Google BigTable e escrito em Java.

Figura 4 - Linguagens do HBase
Figura 4 - Linguagens do HBase

Fontes​