Neste artigo, fazemos considerações e descrevemos processos para migrar os dados de um cluster do Apache HBase para um cluster do Cloud Bigtable no Google Cloud Platform (GCP).
Antes de começar essa migração, avalie as implicações de desempenho, o design do esquema do Cloud Bigtable, as consequências para sua abordagem de autenticação e autorização e o conjunto de recursos do Cloud Bigtable.
Implicações no desempenho
No processamento de cargas de trabalho típicas, o Cloud Bigtable tem um desempenho altamente previsível. Quando tudo está dentro da normalidade, dependendo do tipo de armazenamento usado pelo cluster, o desempenho esperado para cada nó do cluster do Cloud Bigtable é:
Tipo de armazenamento | Leituras | Gravações | Verificações | |
---|---|---|---|---|
SSD | 10.000 linhas por segundo a 6 ms | ou | 10.000 linhas por segundo a 6 ms | 220 MB/s |
HDD | 500 linhas por segundo a 200 ms | ou | 10.000 linhas por segundo a 50 ms | 180 MB/s |
As estimativas mostradas na lista são baseadas em linhas com 1 KB de dados. Além disso, elas refletem uma carga de trabalho somente leitura ou somente gravação. O desempenho de uma carga de trabalho mista de leituras e gravações pode variar.
Os números relativos ao desempenho são uma referência, não uma regra. O desempenho por nó pode variar com base na carga de trabalho e no tamanho de valor típico de uma solicitação ou resposta. Para saber mais, consulte Noções básicas sobre o desempenho do Cloud Bigtable.
Design de esquema do Cloud Bigtable
Projetar um esquema do Cloud Bigtable não é como criar um esquema para um banco de dados relacional. Antes de projetar seu esquema, analise os conceitos definidos em Como criar seu esquema.
Você também precisa manter o esquema abaixo dos limites de tamanho recomendados. Como diretriz, mantenha linhas únicas abaixo de 100 MB e valores únicos abaixo de 10 MB. Talvez você encontre cenários em que seja preciso armazenar grandes valores. Isso pode impactar o desempenho, porque a extração de grandes valores requer tempo e memória. Avalie esses cenários caso a caso.
Autenticação e autorização
Antes de projetar o controle de acesso para o Cloud Bigtable, analise os processos atuais de autenticação e autorização do HBase.
No Cloud Bigtable, são usados os mecanismos para autenticação padrão do GCP, o Cloud Identity e o Access Management para controle de acesso. Assim, você converte sua autorização atual no HBase para o Cloud IAM. É possível correlacionar a diferentes contas de serviço os grupos atuais do Hadoop que fornecem mecanismos de controle de acesso para o HBase.
O controle de acesso no nível da instância é feito por meio do Cloud Bigtable, mas o controle refinado, no nível da tabela, não. Para ter granularidade no nível de tabela, basta agrupar, em uma instância do Cloud Bigtable, as tabelas que tenham padrão de acesso semelhantes. No entanto, com essa abordagem, talvez você precise usar várias instâncias do Cloud Bigtable para migrar todas as tabelas.
Para ver mais informações, consulte Controle de acesso.
Como migrar o HBase para o Cloud Bigtable
Para migrar seus dados do HBase para o Cloud Bigtable, exporte-os como uma série de arquivos de sequência do Hadoop. Este é um formato de arquivo usado pelo HBase e constituído de pares de chave-valor binários.
Para migrar a tabela do HBase para o Cloud Bigtable, siga estas etapas:
- Colete detalhes do HBase.
- Exporte tabelas do HBase para arquivos de sequência.
- Transfira os arquivos de sequência para o Cloud Storage.
- Importe os arquivos de sequência para o Cloud Bigtable usando o Cloud Dataflow.
- Valide a transferência.
Planejar a migração: coletar detalhes do HBase
Para se preparar para a migração, reúna as seguintes informações do cluster atual do HBase, porque você precisará delas para criar a tabela de destino.
- Lista de tabelas.
- Contagens de linha.
- Contagens de células.
- Detalhes do grupo de colunas, incluindo tempo de vida e número máximo de versões.
Para coletar facilmente esses detalhes em uma tabela de origem, use o seguinte script, que deixa o resultado no HDFS:
#!/usr/bin/env bash # Table Name is the Source HBase Table Name TABLENAME="$1" # Export Directory will be located on HDFS EXPORTDIR="$2" hadoop fs -mkdir -p ${EXPORTDIR} hbase shell << EOQ describe ${TABLENAME} EOQ | hadoop fs -put - ${EXPORTDIR}/${TABLENAME}-schema.json hbase shell << EOQ get_splits ${TABLENAME} EOQ | hadoop fs -put - ${EXPORTDIR}/${TABLENAME}-splits.txt
Exportar a tabela do HBase para o Cloud Storage
Quando você souber as noções básicas das tabelas do HBase a serem migradas, exporte a tabela para arquivos de sequência e mova-a para o Cloud Storage. Antes de migrar dados on-line, execute as etapas a seguir para garantir que o cluster atenda aos pré-requisitos de acesso ao GCP:
-
Instalar o conector do Cloud Storage.
Se quiser migrar dados on-line usando o
distcp
, você precisa instalar e configurar o conector do Cloud Storage. Primeiro, identifique o sistema de arquivos HDFS de gerenciamento dos dados que você quer migrar. Em seguida, determine qual nó cliente no cluster do Hadoop tem acesso a esse sistema de arquivos. Por fim, instale o conector no nó cliente. Para ver os detalhes das etapas de instalação, consulte Como instalar o conector do Cloud Storage. -
Instale o SDK do Cloud.
Para migrar dados com
distcp
ougsutil
, instale o SDK do Cloud no nó cliente do cluster do Hadoop em que a migração será iniciada. Para ver os detalhes das etapas de instalação, consulte a documentação do SDK do Cloud.
Exportar a tabela HBase para o HDFS
Em seguida, exporte a tabela do HBase que você quer migrar para algum lugar no cluster do Hadoop. Vamos supor que o nome da tabela HBase seja [MY_NEW_TABLE]. O diretório de destino está sob seu diretório de usuário no HDFS. Exporte a tabela do HBase como arquivos de sequência usando os seguintes comandos:
TABLENAME="my-new-table" EXPORTDIR=/usr/[USERNAME]/hbase-${TABLENAME}-export hadoop fs -mkdir -p ${EXPORTDIR} MAXVERSIONS=2147483647 cd ${HBASE_HOME} bin/hbase org.apache.hadoop.hbase.mapreduce.Export my-new-table \ /user/hbase-${TABLENAME} \ -export ${MAXVERSIONS} bin/hbase org.apache.hadoop.hbase.mapreduce.Export \ -Dmapred.output.compress=true \ -Dmapred.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec \ -DRAW_SCAN=true \ -Dhbase.client.scanner.caching=100 \ -Dmapred.map.tasks.speculative.execution=false \ -Dmapred.reduce.tasks.speculative.execution=false \ ${TABLENAME} ${EXPORTDIR} ${MAXVERSIONS}
Migrar os arquivos de sequência do HDFS para o Cloud Storage
O próximo passo é transferir os arquivos de sequência para um intervalo do Cloud Storage. Dependendo do tamanho e da origem dos dados, do número de arquivos e da largura de banda disponível, é possível escolher a opção apropriada para mover os arquivos de sequência para o Cloud Storage: Transfer Appliance, distcp
, gsutil
ou Storage Transfer Service.
Usar o Transfer Appliance
Use o Transfer Appliance para migrar os dados quando:
- você quiser controlar a largura de banda de saída com uma programação;
- o tamanho dos dados for maior que 20 TB.
Com essa opção, você não precisa comprar ou provisionar uma rede extra com o Google. O tempo de transferência total, ou seja, tempo de envio do dispositivo, reidratação etc. é de cerca de 100 Mbps.
Para mover dados com o Transfer Appliance, copie os arquivos de sequência para ele e envie o dispositivo de volta ao Google. O Google carrega os dados no GCP. Para saber mais informações, consulte a documentação do Transfer Appliance.
Usar o distcp
Use o distcp
para migrar os dados quando:
- a largura de banda disponível para migração for maior que 100 Mbps;
- o conector do Cloud Storage e o SDK do Cloud puderem ser instalados no ambiente Hadoop de origem;
- o gerenciamento de um novo job do Hadoop para executar a migração de dados for aceitável;
- o tamanho dos dados for menor que 20 TB.
Para mover dados com distcp
, use o nó cliente de cluster do Hadoop configurado com o conector do Cloud Storage para enviar um job MapReduce e copiar os arquivos de sequência para o Cloud Storage:
hadoop distcp hdfs://[NAMENODE]:[NAMENODE_PORT]/[SOURCE_DIRECTORY] \ gs://[BUCKET]/DESTINATION_DIRECTORY]
Usar a gsutil
Use a gsutil
para migrar os dados quando:
- a largura de banda disponível para migração for maior que 100 Mbps;
- o SDK do Cloud puder ser instalado no ambiente Hadoop de origem;
- o gerenciamento de um novo job do Hadoop para executar a migração de dados não for aceitável;
- o tamanho dos dados for menor que 10 TB.
Para mover dados com gsutil
, use seu nó cliente de cluster do Hadoop para iniciar a migração de dados:
TABLENAME="my-new-table" EXPORTDIR=/usr/[USERNAME]/hbase-${TABLENAME}-export gsutil -m cp -r ${EXPORTDIR} gs://[BUCKET]
Usar o Storage Transfer Service
Use o Storage Transfer Service para migrar os dados quando:
- sua fonte de dados for um intervalo do Amazon S3, um local HTTP/HTTPS ou um intervalo do Cloud Storage;
- o tamanho dos dados for menor que 10 TB.
Há três opções no Storage Transfer Service que facilitam as transferências de dados e a sincronização entre origens e coletores de dados. Por exemplo, é possível executar as seguintes ações:
- Programar operações de transferência única ou operações de transferência recorrentes.
- Excluir objetos que estejam atualmente no intervalo de destino se eles não tiverem um objeto correspondente na origem.
- Excluir os objetos de origem depois de transferi-los.
- Agendar a sincronização periódica da origem dos dados com o coletor usando filtros avançados, baseados nas datas de criação dos arquivos, em filtros de nome de arquivo e nas horas do dia em que você prefere importar dados.
Para ver mais informações, consulte esta documentação do Storage Transfer Service.
Criar a tabela de destino
O próximo passo é criar a tabela de destino no Cloud Bigtable.
Primeiro, use a ferramenta de linha de comando gcloud
para instalar a ferramenta cliente cbt
do Cloud Bigtable.
gcloud components update gcloud components install cbt
Em seguida, crie uma tabela no Cloud Bigtable com os grupos de colunas apropriados descobertos anteriormente.
Use as divisões atuais e divida previamente a tabela de destino à medida que você a cria. Isso vai melhorar o desempenho da carga em massa.
Por exemplo, se as divisões atuais forem:
'15861', '29374', '38173', '180922',
'203294', '335846', '641111', '746477',
'807307', '871053', '931689', '1729462', '1952670', '4356485', '4943705',
'5968738', '6917370', '8993145', '10624362', '11309714', '12056747', '12772074',
'14370672', '16583264', '18835454', '21194008', '22021148', '23702800',
'25532516', '55555555'
Configure um projeto padrão e uma instância do Cloud Bigtable para a ferramenta cbt
da sua conta de usuário, da seguinte forma:
$ cat > ${HOME}/.cbtrc << EOF project = [YOUR-GCP-PROJECT] instance = [BIGTABLE-INSTANCE-NAME] EOF
Crie estas divisões na tabela de destino:
cbt -instance my-instance createtable my-new-table \ splits=15861,29374,38173,180922,203294,335846,641111,746477,807307,871053,931689,\ 1729462,1952670,4356485,4943705,5968738,6917370,8993145,10624362,11309714,\ 12056747,12772074,14370672,16583264,18835454,21194008,22021148,23702800,\ 5532516,55555555
Crie grupos de colunas na tabela de destino que correspondam aos grupos que você descobriu anteriormente.
Por exemplo, se você descobriu que há dois grupos de colunas, cf1
e cf2
, crie o grupo de colunas cf1
no Cloud Bigtable:
cbt createfamily my-new-table cf1
Crie o grupo de colunas cf2
assim:
cbt createfamily my-new-table cf2
Depois de criar os grupos de colunas, é importante atualizar a política de coleta de lixo de cada grupo, incluindo a idade máxima e o número máximo de versões para os valores. Você precisa fazer isso mesmo que tenha usado as configurações padrão do HBase para a tabela, porque as ferramentas nativas do Cloud Bigtable têm uma configuração padrão diferente do HBase.
cbt setgcpolicy [TABLE] [FAMILY] ( maxage=[D]| maxversions=[N] )
Importar os dados do HBase para o Cloud Bigtable usando o Cloud Dataflow
Há duas maneiras de importar dados para o Cloud Bigtable. Para saber detalhes, consulte Como importar arquivos de sequência nos documentos do Cloud Bigtable.
Preste atenção nas seguintes dicas:
-
Para melhorar o desempenho do carregamento de dados, defina
maxNumWorkers
. Esse valor ajuda a garantir que o job de importação tenha poder de computação suficiente para ser concluído em um período de tempo razoável, mas não tanto que sobrecarregue o cluster do Cloud Bigtable. -
Durante a importação, monitore o uso da CPU do cluster do Cloud Bigtable. Veja mais informações sobre esse tópico na seção sobre uso da CPU do documento de monitoramento do Cloud Bigtable. Se a utilização da CPU no cluster do Cloud Bigtable for muito alta, talvez seja necessário adicionar nós. O benefício de desempenho dos nós extras pode levar até 20 minutos para ser recebido.
Para ver mais informações sobre o monitoramento da instância do Cloud Bigtable, consulte Como monitorar uma instância do Cloud Bigtable.
Confirmar os dados importados no Cloud Bigtable
Para validar os dados importados, use algumas verificações diferentes:
- Verificação da correspondência da contagem de linhas. O job do Cloud Dataflow vai informar a contagem total de linhas. Esse valor precisa corresponder à contagem de linhas da tabela HBase de origem.
- Verificação pontual com consultas a linhas específicas. É possível selecionar um conjunto específico de chaves de linha da tabela de origem e consultá-las na tabela de destino para verificar se correspondem:
cbt lookup [destination-table] [rowkey1] cbt lookup [destination-table] [rowkey2]
A seguir
- Confira as outras partes do guia de migração do Hadoop:
- Saiba mais sobre o Cloud Storage.