HBase
 sql >> Base de Dados >  >> NoSQL >> HBase

Backups online do Apache HBase com CopyTable


CopyTable é um utilitário Apache HBase simples que, sem surpresa, pode ser usado para copiar tabelas individuais dentro de um cluster HBase ou de um cluster HBase para outro. Nesta postagem do blog, falaremos sobre o que é essa ferramenta, por que você gostaria de usá-la, como usá-la e algumas advertências de configuração comuns.

Casos de uso:


CopyTable é em sua essência um trabalho Apache Hadoop MapReduce que usa a interface de caminho de leitura HBase Scan padrão para ler registros de uma tabela individual e os grava em outra tabela (possivelmente em um cluster separado) usando a interface de caminho de gravação HBase Put padrão. Ele pode ser usado para muitas finalidades:
  • Cópia interna de uma tabela (foto do pobre homem)
  • Backup de instância remota do HBase
  • Cópias incrementais da tabela HBase
  • Cópias parciais da tabela HBase e alterações no esquema da tabela HBase

Suposições e limitações:


A ferramenta CopyTable tem algumas suposições e limitações básicas. Primeiro, se estiver sendo usado na situação de vários clusters, ambos os clusters devem estar online e a instância de destino precisa ter a tabela de destino presente com as mesmas famílias de colunas definidas como a tabela de origem.

Como a ferramenta usa varreduras e colocações padrão, o cluster de destino não precisa ter o mesmo número de nós ou regiões. Na verdade, ele pode ter diferentes números de tabelas, diferentes números de servidores de região e pode ter limites de divisão de região completamente diferentes. Como estamos copiando tabelas inteiras, você pode usar configurações de otimização de desempenho, como definir valores maiores de cache do scanner para obter mais eficiência. O uso da interface put também significa que as cópias podem ser feitas entre clusters de diferentes versões secundárias. (0.90.4 -> 0.90.6, CDH3u3 -> CDH3u4) ou versões compatíveis com fio (0.92.1 -> 0.94.0).

Por fim, o HBase fornece apenas garantias ACID em nível de linha; isso significa que enquanto uma CopyTable está em andamento, linhas recém-inseridas ou atualizadas podem ocorrer e essas edições simultâneas serão completamente incluídas ou completamente excluídas. Embora as linhas sejam consistentes, não há garantias sobre a consistência, causalidade ou ordem das colocações nas outras linhas.

Cópia interna de uma tabela (foto do pobre homem)


As versões do HBase até e incluindo as versões 0.94.x mais recentes não suportam a captura instantânea de tabela. Apesar das limitações de ACID do HBase, CopyTable pode ser usado como um mecanismo de snapshot ingênuo que faz uma cópia física de uma tabela específica.

Digamos que temos uma tabela, tableOrig com famílias de colunas cf1 e cf2. Queremos copiar todos os seus dados para tableCopy. Precisamos primeiro criar tableCopy com as mesmas famílias de colunas:
srcCluster$ echo "create 'tableOrig', 'cf1', 'cf2'" | hbase shell

Podemos então criar e copiar a tabela com um novo nome na mesma instância do HBase:

srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --new.name=tableCopy tableOrig

Isso inicia um trabalho de RM que copiará os dados.

Backup de instância remota do HBase


Digamos que queremos copiar dados para outro cluster. Isso pode ser um backup único, um trabalho periódico ou pode ser para inicialização para replicação entre clusters. Neste exemplo, teremos dois clusters separados:srcCluster e dstCluster.

Nesse caso de vários clusters, CopyTable é um processo push — sua origem será a instância do HBase à qual seu hbase-site.xml atual se refere e os argumentos adicionados apontam para o cluster e a tabela de destino. Isso também pressupõe que todos os MR TaskTrackers podem acessar todos os nós HBase e ZK no cluster de destino. Esse mecanismo de configuração também significa que você pode executar isso como um trabalho em um cluster remoto substituindo as configurações hbase/mr para usar as configurações de qualquer cluster remoto acessível e especificar os nós ZK no cluster de destino. Isso pode ser útil se você quiser copiar dados de um cluster HBase com SLAs mais baixos e não quiser executar trabalhos de MR diretamente neles.

Você usará a configuração –peer.adr para especificar o conjunto ZK do cluster de destino (por exemplo, o cluster para o qual você está copiando). Para isso, precisamos do IP e da porta do quorum ZK, bem como do nó ZK raiz do HBase para nossa instância do HBase. Digamos que uma dessas máquinas seja srcClusterZK (listada em hbase.zookeeper.quorum) e que estamos usando a porta de cliente zk padrão 2181 (hbase.zookeeper.property.clientPort) e o pai znode ZK padrão /hbase (zookeeper.znode. pai). (Observação:se você tivesse duas instâncias do HBase usando o mesmo ZK, precisaria de um zookeeper.znode.parent diferente para cada cluster. 
# create new tableOrig on destination cluster
dstCluster$ echo "create 'tableOrig', 'cf1', 'cf2'" | hbase shell
# on source cluster run copy table with destination ZK quorum specified using --peer.adr
# WARNING: In older versions, you are not alerted about any typo in these arguments!
srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --peer.adr=dstClusterZK:2181:/hbase tableOrig

Observe que você pode usar o argumento –new.name com –peer.adr para copiar para uma tabela com nome diferente no dstCluster. 

# create new tableCopy on destination cluster
dstCluster$ echo "create 'tableCopy', 'cf1', 'cf2'" | hbase shell
# on source cluster run copy table with destination --peer.adr and --new.name arguments.
srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable --peer.adr=dstClusterZK:2181:/hbase --new.name=tableCopy tableOrig

Isso copiará os dados do tableOrig no srcCluster para a tabela tableCopy do dstCluster.

Cópias incrementais da tabela HBase


Depois de ter uma cópia de uma tabela em um cluster de destino, como você copia novos dados que são posteriormente gravados no cluster de origem? Ingenuamente, você pode executar o trabalho CopyTable novamente e copiar a tabela inteira. No entanto, CopyTable fornece um mecanismo de cópia incremental mais eficiente que apenas copia as linhas atualizadas do srcCluster para o backup dstCluster especificado em uma janela de tempo. Assim, após a cópia inicial, você pode ter um trabalho cron periódico que copia dados apenas da hora anterior do srcCluster para o dstCuster.

Isso é feito especificando os argumentos –starttime e –endtime. Os tempos são especificados como milissegundos decimais desde o tempo da época unix. 
# WARNING: In older versions, you are not alerted about any typo in these arguments!
# copy from beginning of time until timeEnd 
# NOTE: Must include start time for end time to be respected. start time cannot be 0.
srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable ... --starttime=1 --endtime=timeEnd ...
# Copy from starting from and including timeStart until the end of time.
srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable ... --starttime=timeStart ...
# Copy entries rows with start time1 including time1 and ending at timeStart excluding timeEnd.
srcCluster$ hbase org.apache.hadoop.hbase.mapreduce.CopyTable ... --starttime=timestart --endtime=timeEnd

Cópias parciais da tabela HBase e alterações do esquema da tabela HBase


Por padrão, CopyTable copiará todas as famílias de colunas das linhas correspondentes. CopyTable fornece opções para copiar apenas dados de famílias de colunas específicas. Isso pode ser útil para copiar dados de origem originais e excluir famílias de colunas de dados derivadas que são adicionadas pelo processamento de acompanhamento.

Ao adicionar esses argumentos, copiamos apenas os dados das famílias de colunas especificadas.
  • –families=srcCf1
  • –families=srcCf1,srcCf2

A partir de 0.92.0, você pode copiar enquanto altera o nome da família de colunas:
  • –families=srcCf1:dstCf1
    • copiar de srcCf1 para dstCf1
  • –families=srcCf1:dstCf1,dstCf2,srcCf3:dstCf3
    • copie de srcCf1 para destCf1, copie dstCf2 para dstCf2 (sem renomear) e srcCf3 para dstCf3

Observe que dstCf* deve estar presente na tabela dstCluster!

A partir da versão 0.94.0, novas opções são oferecidas para copiar marcadores de exclusão e incluir um número limitado de versões sobrescritas. Anteriormente, se uma linha fosse excluída no cluster de origem, a exclusão não seria copiada — em vez disso, uma versão antiga dessa linha permaneceria no cluster de destino. Isso aproveita alguns dos recursos avançados da versão 0.94.0.
  • –versões=vers
    • onde vers é o número de versões de células a serem copiadas (o padrão é 1, ou seja, apenas a mais recente)
  • –all.cells
    • copie também marcadores de exclusão e células excluídas

Armadilhas comuns


O cliente HBase nas versões 0.90.x, 0.92.xe 0.94.x sempre usa zoo.cfg se estiver no caminho de classe, mesmo se um arquivo hbase-site.xml especificar outras configurações de quorum do ZooKeeper. Esse “recurso” causa um problema comum no CDH3 HBase porque seus pacotes padrão incluem um diretório onde zoo.cfg reside no classpath do HBase. Isso pode e levou à frustração ao tentar usar CopyTable (HBASE-4614). A solução para isso é excluir o arquivo zoo.cfg do classpath do HBase e especificar as propriedades de configuração do ZooKeeper no arquivo hbase-site.xml. http://hbase.apache.org/book.html#zookeeper

Conclusão


O CopyTable fornece um seguro de recuperação de desastres simples, mas eficaz para implantações do HBase 0.90.x (CDH3). Em conjunto com o recurso de replicação encontrado e suportado no HBase baseado em HBase 0.92.x do CDH4, os recursos incrementais do CopyTable se tornam menos valiosos, mas sua funcionalidade principal é importante para inicializar uma tabela replicada. Embora recursos mais avançados, como instantâneos do HBase (HBASE-50), possam ajudar na recuperação de desastres quando implementados, o CopyTable ainda será uma ferramenta útil para o administrador do HBase.