Compartilhar via

Migrar dados do Apache HBase para uma conta do Azure Cosmos DB for NoSQL

  • Artigo

APLICA-SE A: NoSQL

O Azure Cosmos DB é um banco de dados escalonável, distribuído globalmente e totalmente gerenciado. Ele fornece acesso garantido de baixa latência aos seus dados. Para saber mais sobre a API do Azure Cosmos DB, veja o artigo de visão geral. Este artigo descreve como migrar seus dados do HBase para uma conta do Azure Cosmos DB for NoSQL.

Diferenças entre o Azure Cosmos DB e o HBase

Antes de migrar, você deve entender as diferenças entre o Azure Cosmos DB e o HBase.

Modelo de recursos

O Azure Cosmos DB tem o seguinte modelo de recursos: Modelo de recursos do Azure Cosmos DB com uma conta, bancos de dados, contêineres e itens.

O HBase tem o seguinte modelo de recursos: Modelo de recursos do HBase com namespace, tabelas, linhas e colunas.

Mapeamento de recurso

A tabela a seguir mostra um mapeamento conceitual entre o Apache HBase, o Apache Phoenix e o Azure Cosmos DB.

HBase Phoenix Azure Cosmos DB
Cluster Cluster Conta
Namespace Esquema (se habilitado) Banco de dados
Tabela Tabela Contêiner/coleção
Família de colunas Família de colunas N/D
Linha Linha Item/documento
Versão (carimbo de data/hora) Versão (carimbo de data/hora) N/D
N/D Chave Primária Chave de Partição
N/D Índice Índice
N/D Índice secundário Índice secundário
N/D Visualizar N/D
N/D Sequência N/D

Comparação e diferenças entre estruturas de dados

As principais diferenças entre a estrutura de dados do Azure Cosmos DB e do HBase são as seguintes:

RowKey

  • No HBase, os dados são armazenados por RowKey e particionados horizontalmente em regiões pelo intervalo de RowKey especificado durante a criação da tabela.

  • O Azure Cosmos DB, do outro lado, distribui dados em partições com base no valor de hash de uma chave de Partição especificada.

Família de colunas

  • No HBase, as colunas são agrupadas em uma Família de colunas (CF).

  • O Azure Cosmos DB (API para NoSQL) armazena os dados como um documento JSON. Portanto, todas as propriedades associadas a uma estrutura de dados JSON se aplicam.

Timestamp

  • O HBase usa o carimbo de data/hora para realizar o controle de versão de várias instâncias de uma determinada célula. Você pode consultar versões diferentes de uma célula usando o carimbo de data/hora.

  • O Azure Cosmos DB é fornecido com o recurso Feed de alterações, que rastreia um registro persistente de alterações em um contêiner na ordem em que ocorrem. Ele gera a lista classificada de documentos que foram alterados na ordem em que eles foram modificados.

Formato dos dados

  • O formato de dados do HBase consiste em RowKey, Família de colunas: Nome da coluna, Carimbo de data/hora, Valor. Veja a seguir um exemplo de uma linha de tabela do HBase:

    ROW                                COLUMN+CELL
1000                              column=Office:Address, timestamp=1611408732448, value=1111 San Gabriel Dr.
1000                              column=Office:Phone, timestamp=1611408732418, value=1-425-000-0002
1000                              column=Personal:Name, timestamp=1611408732340, value=John Dole
1000                              column=Personal:Phone, timestamp=1611408732385, value=1-425-000-0001

  • No Azure Cosmos DB for NoSQL, o objeto JSON representa o formato de dados. A chave de partição reside em um campo no documento e define qual campo é a chave de partição da coleção. O Azure Cosmos DB não tem o conceito de carimbo de data/hora usado para família de colunas ou versão. Como realçado anteriormente, ele tem suporte para feed de alterações por meio do qual é possível rastrear/registrar as alterações realizadas em um contêiner. Segue um exemplo de um documento.

    {
    "RowId": "1000",
    "OfficeAddress": "1111 San Gabriel Dr.",
    "OfficePhone": "1-425-000-0002",
    "PersonalName": "John Dole",
    "PersonalPhone": "1-425-000-0001",
}

Dica

O HBase armazena dados na matriz de bytes e, portanto, se você deseja migrar dados que contenham caracteres de bytes duplos para o Azure Cosmos DB, os dados devem ser codificados em UTF-8.

Modelo de consistência

O HBase oferece leituras e gravações estritamente consistentes.

O Azure Cosmos DB oferece cinco níveis de consistência bem definidos. Cada nível fornece compensações de desempenho e disponibilidade. Do mais forte ao mais fraco, os níveis de consistência com suporte são:

  • Forte
  • Bounded staleness
  • Session
  • Prefixo consistente
  • Eventual

Dimensionamento

HBase

Para uma implantação em escala corporativa do HBase, o Mestre, os servidores de Região e o ZooKeeper movimentam o dimensionamento em massa. Como qualquer aplicativo distribuído, o HBase foi projetado para dimensionar. O desempenho do HBase é principalmente impulsionado pelo tamanho dos RegionServers do HBase. O dimensionamento é orientado principalmente por dois requisitos-chave – a taxa de transferência e o tamanho do conjuntos de dados que devem ser armazenados no HBase.

Azure Cosmos DB

O Azure Cosmos DB é uma oferta paaS da Microsoft e os detalhes de implantação de infraestrutura subjacente são abstraídos dos usuários finais. Quando um contêiner do Azure Cosmos DB é provisionado, a plataforma Azure provisiona automaticamente a infraestrutura subjacente (computação, armazenamento, memória, pilha de rede) para dar suporte aos requisitos de desempenho de determinada carga de trabalho. O custo de todas as operações do banco de dados é normalizado pelo Azure Cosmos DB e expresso por Unidades de Solicitação (ou RUs, abreviado na sigla em inglês).

Para estimar as RUs consumidas por sua carga de trabalho, considere os seguintes fatores:

Há uma calculadora de capacidade disponível para ajudar no exercício de dimensionamento de RUs.

A taxa de transferência de provisionamento de dimensionamento automático no Azure Cosmos DB para escalar a taxa de transferência (RU/s) do seu banco de dados ou contêiner de forma automática e instantânea. A taxa de transferência é escalada com base no uso, sem afetar a disponibilidade, latência, taxa de transferência ou desempenho da carga de trabalho.

Distribuição de dados

HBase O HBase classifica os dados de acordo com a RowKey. Os dados são então particionados em regiões e armazenados em RegionServers. O particionamento automático divide regiões horizontalmente de acordo com a política de particionamento. Isso é controlado pelo valor atribuído ao parâmetro hbase.hregion.max.filesize do HBase (o valor padrão é 10 GB). Uma linha no HBase com uma RowKey determinada sempre pertence a uma região. Além disso, os dados são separados em disco para cada família de colunas. Isso permite uma filtragem no momento da leitura e isolamento da E/S em HFile.

Azure Cosmos DB O Azure Cosmos DB usa particionamento para escalar contêineres individuais no banco de dados. O particionamento divide os itens em um contêiner em subconjuntos específicos chamados "partições lógicas". As partições lógicas são formadas com base no valor da "chave de partição" associada a cada item no contêiner. Todos os itens em uma partição lógica têm o mesmo valor de chave de partição. Cada partição lógica pode armazenar até 20 GB de dados.

Cada partição física contém uma réplica dos seus dados e uma instância do mecanismo de banco de dados do Azure Cosmos DB. Essa estrutura torna seus dados duráveis e altamente disponíveis, e a taxa de transferência é dividida igualmente entre as partições físicas locais. As partições físicas são criadas e configuradas automaticamente, e não é possível controlar o tamanho e o local delas ou quais partições lógicas elas contêm. Partições lógicas não são divididas entre partições físicas.

Assim como na RowKey do HBase, o design da chave de partição é importante para o Azure Cosmos DB. A chave de linha do HBase classifica dados e armazena dados contínuos, e a chave de partição do Azure Cosmos DB é um mecanismo diferente porque distribui dados com hash. Considerando que seu aplicativo que usa o HBase seja otimizado para padrões de acesso a dados do HBase, usar a mesma RowKey como Chave de partição não dará bons resultados de desempenho. Como são dados classificados no HBase, o índice composto do Azure Cosmos DB pode ser útil. Isso é necessário se você quiser usar a cláusula ORDER BY em mais de um campo. Você também pode aprimorar o desempenho de várias consultas de igualdade e de intervalo definindo um índice composto.

Disponibilidade

HBase O HBase consiste em Mestre, Servidor de Região e ZooKeeper. A alta disponibilidade em um único cluster pode ser atingida tornando cada componente redundante. Ao configurar a redundância geográfica, é possível implantar clusters do HBase em diferentes data centers físicos e usar a replicação para manter vários clusters em sincronia.

Azure Cosmos DB O Azure Cosmos DB não exige nenhuma configuração, como redundância de componente de cluster. Ele fornece um SLA abrangente para alta disponibilidade, consistência e latência. Para saber mais detalhes, confira SLA para o Azure Cosmos DB.

Confiabilidade de dados

HBase O HBase é criado no HDFS (Sistema de Arquivos Distribuído Hadoop) e os dados armazenados no HDFS são replicados três vezes.

Azure Cosmos DB O Azure Cosmos DB fornece alta disponibilidade de duas formas principais. Primeiro, o Azure Cosmos DB replica os dados entre as regiões configuradas na sua conta do Azure Cosmos DB. Segundo, o Azure Cosmos DB mantém quatro réplicas dos dados na região.

Considerações antes de migrar

Dependências do sistema

Este aspecto do planejamento se concentra no entendimento das dependências de upstream e downstream para a instância do HBase que está sendo migrada para o Azure Cosmos DB.

Os aplicativos que leem dados do HBase são um exemplo de dependências de downstream. Eles devem ser refatoradas para serem lidos do Azure Cosmos DB. Os pontos a seguir devem ser considerados como parte da migração:

  • Perguntas para avaliar dependências - O sistema HBase atual é um componente independente? Ou ele chama um processo em outro sistema ou é chamado por um processo em outro sistema ou é acessado usando um serviço de diretório? Outros processos importantes estão funcionando no cluster do HBase? Essas dependências do sistema precisam ser esclarecidas para determinar o impacto da migração.

  • O RPO e o RTO para a implantação local do HBase.

Migração offline e online

Para uma migração de dados bem-sucedida, é importante entender as características da empresa que usa o banco de dados e decidir como fazê-lo. Selecione a migração offline se puder desligar completamente o sistema, executar a migração de dados e reiniciar o sistema no destino. Além disso, se o banco de dados estiver sempre ocupado e você não puder pagar uma interrupção prolongada, considere a migração online.

Observação

Este documento trata apenas da migração offline.

A realização de uma migração de dados offline depende da versão do HBase que você está executando no momento e das ferramentas disponíveis. Consulte a seção Migração de Dados para obter mais detalhes.

Considerações sobre desempenho

Este aspecto do planejamento é entender as metas de desempenho do HBase e traduzi-las para a semântica do Azure Cosmos DB. Por exemplo, para atingir "X" IOPS no HBase, quantas RU/s (unidades de solicitação) serão necessárias no Azure Cosmos DB. Há diferenças entre o HBase e o Azure Cosmos DB, este exercício se concentra na criação de uma visão de como as metas de desempenho do HBase serão traduzidas para o Azure Cosmos DB. Isso conduzirá o exercício de colocação em escala.

Perguntas a fazer:

  • A implantação do HBase é pesada para leitura ou gravação?
  • Qual a divisão entre leituras e gravações?
  • O que o IOPS de destino expressa como percentil?
  • Como/quais aplicativos são usados para carregar dados no HBase?
  • Como/quais aplicativos são usados para ler dados do HBase?

Ao executar consultas que solicitam dados classificados, o HBase retornará o resultado rapidamente porque os dados são classificados por RowKey. No entanto, o Azure Cosmos DB não tem esse conceito. Para otimizar o desempenho, você pode usar índices compostos conforme necessário.

Considerações de implantação

Use o portal do Azure ou a CLI do Azure para implantar o Azure Cosmos DB for NoSQL. Como o destino de migração é o Azure Cosmos DB for NoSQL, selecione "NoSQL" para a API como parâmetro na implantação. Além disso, defina a Redundância Geográfica, as Gravações de Várias Regiões e as Zonas de Disponibilidade de acordo com seus requisitos de disponibilidade.

Consideração de rede

O Azure Cosmos DB traz três opções principais de rede. A primeira é uma configuração que usa um endereço IP público e controla o acesso com um firewall de IP (padrão). O segundo é uma configuração que usa um endereço IP público e permite acesso somente a partir de uma sub-rede específica de uma rede virtual específica (ponto de extremidade de serviço). O terceiro é uma configuração (ponto de extremidade privado) que insere uma rede privada usando um endereço IP privado.

Confira os seguintes documentos para obter mais informações sobre as três opções de rede:

Avaliar seus dados existentes

Descoberta de dados

Reúna informações antecipadamente do cluster do HBase existente para identificar os dados que você deseja migrar. Isso pode ajudá-lo a identificar como migrar, decidir quais tabelas migrar, entender a estrutura nessas tabelas e decidir como criar seu modelo de dados. Por exemplo, reúna detalhes como os seguintes:

  • Versão do HBase
  • Tabelas de meta de migração
  • Informações da família de colunas
  • Status da tabela

Os comandos a seguir mostram como coletar os detalhes acima usando um script de shell do Hbase e armazená-los no sistema de arquivos local do computador operacional.

Obter a versão do HBase

hbase version -n > hbase-version.txt

Saída:

cat hbase-version.txt
HBase 2.1.8.4.1.2.5

Obter a lista de tabelas

Você pode obter uma lista de tabelas armazenadas no HBase. Se você tiver criado um namespace diferente do padrão, ele será gerado no formato "Namespace: Table".

echo "list" | hbase shell -n > table-list.txt
HBase 2.1.8.4.1.2.5

Saída:

echo "list" | hbase shell -n > table-list.txt
cat table-list.txt
TABLE
COMPANY
Contacts
ns1:t1
3 row(s)
Took 0.4261 seconds
COMPANY
Contacts
ns1:t1

Identificar as tabelas a serem migradas

Obtenha os detalhes das famílias de colunas na tabela especificando o nome da tabela a ser migrada.

echo "describe '({Namespace}:){Table name}'" | hbase shell -n > {Table name} -schema.txt

Saída:

cat {Table name} -schema.txt
Table {Table name} is ENABLED
{Table name}
COLUMN FAMILIES DESCRIPTION
{NAME => 'cf1', VERSIONS => '1', EVICT_BLOCKS_ON_CLOSE => 'false', NEW_VERSION_BEHAVIOR => 'false', KEEP_DELETED_CELLS => 'FALSE', CACHE_DATA_ON_WRITE => 'false', DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', MIN_VERSIONS => '0', REPLICATION_SCOPE => '0', BLOOMFILTER => 'ROW', CACHE_INDEX_ON_WRITE => 'false', IN_MEMORY => 'false', CACHE_BLOOMS_ON_WRITE => 'false', PREFETCH_BLOCKS_ON_OPEN => 'false', COMPRESSION => 'NONE', BLOCKCACHE => 'true', BLOCKSIZE => '65536'}
{NAME => 'cf2', VERSIONS => '1', EVICT_BLOCKS_ON_CLOSE => 'false', NEW_VERSION_BEHAVIOR => 'false', KEEP_DELETED_CELLS => 'FALSE', CACHE_DATA_ON_WRITE => 'false', DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', MIN_VERSIONS => '0', REPLICATION_SCOPE => '0', BLOOMFILTER => 'ROW', CACHE_INDEX_ON_WRITE => 'false', IN_MEMORY => 'false', CACHE_BLOOMS_ON_WRITE => 'false', PREFETCH_BLOCKS_ON_OPEN => 'false', COMPRESSION => 'NONE', BLOCKCACHE => 'true', BLOCKSIZE => '65536'}
2 row(s)
Took 0.5775 seconds

Obter as famílias de colunas na tabela e suas configurações

echo "status 'detailed'" | hbase shell -n > hbase-status.txt

Saída:

{HBase version}
0 regionsInTransition
active master:  {Server:Port number}
2 backup masters
    {Server:Port number}
    {Server:Port number}
master coprocessors: []
# live servers
    {Server:Port number}
        requestsPerSecond=0.0, numberOfOnlineRegions=44, usedHeapMB=1420, maxHeapMB=15680, numberOfStores=49, numberOfStorefiles=14, storefileUncompressedSizeMB=7, storefileSizeMB=7, compressionRatio=1.0000, memstoreSizeMB=0, storefileIndexSizeKB=15, readRequestsCount=36210, filteredReadRequestsCount=415729, writeRequestsCount=439, rootIndexSizeKB=15, totalStaticIndexSizeKB=5, totalStaticBloomSizeKB=16, totalCompactingKVs=464, currentCompactedKVs=464, compactionProgressPct=1.0, coprocessors=[GroupedAggregateRegionObserver, Indexer, MetaDataEndpointImpl, MetaDataRegionObserver, MultiRowMutationEndpoint, ScanRegionObserver, SecureBulkLoadEndpoint, SequenceRegionObserver, ServerCachingEndpointImpl, UngroupedAggregateRegionObserver]

    [...]

        "Contacts,,1611126188216.14a597a0964383a3d923b2613524e0bd."
            numberOfStores=2, numberOfStorefiles=2, storefileUncompressedSizeMB=7168, lastMajorCompactionTimestamp=0, storefileSizeMB=7, compressionRatio=0.0010, memstoreSizeMB=0, readRequestsCount=4393, writeRequestsCount=0, rootIndexSizeKB=14, totalStaticIndexSizeKB=5, totalStaticBloomSizeKB=16, totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN, completeSequenceId=-1, dataLocality=0.0

[...]

Você pode obter informações úteis de dimensionamento, como o tamanho da memória heap, o número de regiões, o número de solicitações como o status do cluster e o tamanho dos dados compactados/não compactados como o status da tabela.

Se estiver usando o Apache Phoenix no cluster HBase, também será necessário coletar dados do Phoenix.

  • Tabelas de meta de migração
  • Esquemas de tabela
  • Índices
  • Chave primária

Conexão a Apache Phoenix em seu cluster

sqlline.py ZOOKEEPER/hbase-unsecure

Obter a lista de tabelas

!tables

Obter os detalhes das tabelas

!describe <Table Name>

Obter os detalhes do índice

!indexes <Table Name>

Obter os detalhes da chave primária

!primarykeys <Table Name>

Migrar seus dados

Opções de migração

Há vários métodos para migrar dados offline, mas aqui apresentaremos como usar o Azure Data Factory.

Solução Versão de origem Considerações
Fábrica de dados do Azure HBase < 2 Fácil de configurar. Adequada para grandes conjuntos de dados. Não dá suporte ao HBase 2 ou posterior.
Apache Spark Todas as versões Suporte para todas as versões do HBase. Adequada para grandes conjuntos de dados. Instalação do Spark necessária.
Ferramenta personalizada com a biblioteca de executor em massa do Azure Cosmos DB Todas as versões Mais flexível para criar ferramentas de migração de dados personalizadas usando bibliotecas. Requer mais esforço para configurar.

O fluxograma a seguir usa algumas condições para alcançar os métodos de migração de dados disponíveis. Fluxograma das opções para migrar os dados para o Azure Cosmos DB.

Migrar usando o Data Factory

Esta opção é adequada para grandes conjuntos de dados. A biblioteca de executor em massa do Azure Cosmos DB é utilizada. Não há pontos de verificação e, portanto, se você encontrar algum problema durante a migração, será preciso reiniciar o processo de migração desde o início. Você também pode usar o runtime de integração auto-hospedada do Data Factory para se conectar ao HBase local ou implantar o Data Factory em uma VNET Gerenciada e se conectar à sua rede local por meio de VPN ou ExpressRoute.

A atividade Copy do Data Factory oferece suporte ao HBase como fonte de dados. Consulte o artigo Copiar dados do HBase usando o Azure Data Factory para obter mais detalhes.

Você pode especificar o Azure Cosmos DB (API para NoSQL) como o destino para seus dados. Confira o artigo Copiar e transformar dados no Azure Cosmos DB (API para NoSQL) usando o Azure Data Factory para obter mais detalhes.

Arquitetura de migração de dados do local para o Azure Cosmos DB usando o Data Factory.

Migração com o Apache Spark – Conector do Apache HBase e conector do Spark do Azure Cosmos DB

Aqui está um exemplo para migrar seus dados para o Azure Cosmos DB. Ele supõe que o HBase 2.1.0 e o Spark 2.4.0 estão sendo executados no mesmo cluster.

Apache Spark – o repositório do conector do Apache HBase se encontra em Apache Spark - Conector do Apache HBase

Para o conector do Spark do Azure Cosmos DB, consulte o Guia de Início Rápido e baixe a biblioteca apropriada para sua versão do Spark.

  1. Copie hbase-site.xml para o diretório de configuração do Spark.

    cp /etc/hbase/conf/hbase-site.xml /etc/spark2/conf/

  2. Execute o shell do Spark com o conector do Spark do HBase e conector do Spark do Azure Cosmos DB.

    spark-shell --packages com.hortonworks.shc:shc-core:1.1.0.3.1.2.2-1 --repositories http://repo.hortonworcontent/groups/public/ --jars azure-cosmosdb-spark_2.4.0_2.11-3.6.8-uber.jar

  3. Depois que o shell do Spark for iniciado, execute o código Scala da seguinte forma. Importe as bibliotecas necessárias para carregar dados do HBase.

    // Import libraries
import org.apache.spark.sql.{SQLContext, _}
import org.apache.spark.sql.execution.datasources.hbase._
import org.apache.spark.{SparkConf, SparkContext}
import spark.sqlContext.implicits._

  4. Defina o esquema de catálogo do Spark para suas tabelas HBase. Aqui o Namespace é "padrão" e o nome da tabela é "Contatos". A chave de linha é especificada como a chave. As Colunas, a Família de colunas e a Coluna são mapeadas para o catálogo do Spark.

    // define a catalog for the Contacts table you created in HBase
def catalog = s"""{
    |"table":{"namespace":"default", "name":"Contacts"},
    |"rowkey":"key",
    |"columns":{
    |"rowkey":{"cf":"rowkey", "col":"key", "type":"string"},
    |"officeAddress":{"cf":"Office", "col":"Address", "type":"string"},
    |"officePhone":{"cf":"Office", "col":"Phone", "type":"string"},
    |"personalName":{"cf":"Personal", "col":"Name", "type":"string"},
    |"personalPhone":{"cf":"Personal", "col":"Phone", "type":"string"}
    |}
|}""".stripMargin

  5. Em seguida, defina um método para obter os dados da tabela Contatos do HBase como um DataFrame.

    def withCatalog(cat: String): DataFrame = {
    spark.sqlContext
    .read
    .options(Map(HBaseTableCatalog.tableCatalog->cat))
    .format("org.apache.spark.sql.execution.datasources.hbase")
    .load()
 }

  6. Crie um DataFrame usando o método definido.

    val df = withCatalog(catalog)

  7. Em seguida, importe as bibliotecas necessárias para usar o conector do Spark do Azure Cosmos DB.

    import com.microsoft.azure.cosmosdb.spark.schema._
import com.microsoft.azure.cosmosdb.spark._
import com.microsoft.azure.cosmosdb.spark.config.Config

  8. Crie as configurações para gravar os dados no Azure Cosmos DB.

    val writeConfig = Config(Map(   "Endpoint" -> "https://<cosmos-db-account-name>.documents.azure.com:443/",   "Masterkey" -> "<comsmos-db-master-key>",   "Database" -> "<database-name>",   "Collection" -> "<collection-name>",   "Upsert" -> "true" ))

  9. Grave dados do DataFrame no Azure Cosmos DB.

    import org.apache.spark.sql.SaveMode df.write.mode(SaveMode.Overwrite).cosmosDB(writeConfig)

Ele grava em paralelo em alta velocidade e seu desempenho é alto. Por outro lado, observe que ele pode consumir RU/s no lado do Azure Cosmos DB.

Phoenix

O Phoenix tem suporte como fonte de dados do Data Factory. Consulte os seguintes documentos para obter as etapas detalhadas.

Migrar seu código

Esta seção descreve as diferenças entre a criação de aplicativos no Azure Cosmos DB for NoSQL e no HBase. Os exemplos apresentados aqui usam APIs do Apache HBase 2.x e Azure Cosmos DB Java SDK v4.

Esses códigos de exemplo do HBase são baseados naqueles descritos na documentação oficial do HBase.

O código do Azure Cosmos DB apresentado aqui baseia-se na documentação Azure Cosmos DB for NoSQL: exemplos do SDK v4 do Java. Você pode acessar o exemplo completo de códigos na documentação.

Os mapeamentos para a migração de códigos são mostrados aqui, mas as chaves de partição do Azure Cosmos DB e as RowKeys do HBase usadas nestes exemplos nem sempre são bem projetadas. Projete de acordo com o modelo de dados real da fonte de migração.

estabelecer conexão

HBase

Configuration config = HBaseConfiguration.create();
config.set("hbase.zookeeper.quorum","zookeepernode0,zookeepernode1,zookeepernode2");
config.set("hbase.zookeeper.property.clientPort", "2181");
config.set("hbase.cluster.distributed", "true");
Connection connection = ConnectionFactory.createConnection(config)

Phoenix

//Use JDBC to get a connection to an HBase cluster
Connection conn = DriverManager.getConnection("jdbc:phoenix:server1,server2:3333",props);

Azure Cosmos DB

// Create sync client
client = new CosmosClientBuilder()
    .endpoint(AccountSettings.HOST)
    .key(AccountSettings.MASTER_KEY)
    .consistencyLevel(ConsistencyLevel.{ConsistencyLevel})
    .contentResponseOnWriteEnabled(true)
    .buildClient();

Criar banco de dados/tabela/coleção

HBase

// create an admin object using the config
HBaseAdmin admin = new HBaseAdmin(config);
// create the table...
HTableDescriptor tableDescriptor = new HTableDescriptor(TableName.valueOf("FamilyTable"));
// ... with single column families
tableDescriptor.addFamily(new HColumnDescriptor("ColFam"));
admin.createTable(tableDescriptor);

Phoenix

CREATE IF NOT EXISTS FamilyTable ("id" BIGINT not null primary key, "ColFam"."lastName" VARCHAR(50));

Azure Cosmos DB

//  Create database if not exists
CosmosDatabaseResponse databaseResponse = client.createDatabaseIfNotExists(databaseName);
database = client.getDatabase(databaseResponse.getProperties().getId());

//  Create container if not exists
CosmosContainerProperties containerProperties = new CosmosContainerProperties("FamilyContainer", "/lastName");

// Provision throughput
ThroughputProperties throughputProperties = ThroughputProperties.createManualThroughput(400);

//  Create container with 400 RU/s
CosmosContainerResponse databaseResponse = database.createContainerIfNotExists(containerProperties, throughputProperties);
container = database.getContainer(databaseResponse.getProperties().getId());

Criar linha/documento

HBase

HTable table = new HTable(config, "FamilyTable");
Put put = new Put(Bytes.toBytes(RowKey));

put.add(Bytes.toBytes("ColFam"), Bytes.toBytes("id"), Bytes.toBytes("1"));
put.add(Bytes.toBytes("ColFam"), Bytes.toBytes("lastName"), Bytes.toBytes("Witherspoon"));
table.put(put)

Phoenix

UPSERT INTO FamilyTable (id, lastName) VALUES (1, ‘Witherspoon’);

Azure Cosmos DB

O Azure Cosmos DB fornece segurança de tipos por meio do modelo de dados. Usamos o modelo de dados chamado ‘Família‘.

public class Family {
    public Family() {
    }

    public void setId(String id) {
        this.id = id;
    }

    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    private String id="";
    private String lastName="";
}

O acima faz parte do código. Consulte o exemplo completo de códigos.

Use a classe Família para definir o documento e inserir um item.

Family family = new Family();
family.setLastName("Witherspoon");
family.setId("1");

// Insert this item as a document
// Explicitly specifying the /pk value improves performance.
container.createItem(family,new PartitionKey(family.getLastName()),new CosmosItemRequestOptions());

Ler linha/documento

HBase

HTable table = new HTable(config, "FamilyTable");

Get get = new Get(Bytes.toBytes(RowKey));
get.addColumn(Bytes.toBytes("ColFam"), Bytes.toBytes("lastName"));

Result result = table.get(get);

byte[]  col = result.getValue(Bytes.toBytes("ColFam"), Bytes.toBytes("lastName"));

Phoenix

SELECT lastName FROM FamilyTable;

Azure Cosmos DB

//  Read document by ID
Family family = container.readItem(documentId,new PartitionKey(documentLastName),Family.class).getItem();

String sql = "SELECT lastName FROM c";

CosmosPagedIterable<Family> filteredFamilies = container.queryItems(sql, new CosmosQueryRequestOptions(), Family.class);

Atualizar dados

HBase

Para o HBase, use o método append e o método checkAndPut para atualizar o valor. Append é o processo de acrescentar um valor atomicamente ao final do valor atual. checkAndPut compara atomicamente o valor atual com o valor esperado e atualiza somente se eles corresponderem.

// append
HTable table = new HTable(config, "FamilyTable");
Append append = new Append(Bytes.toBytes(RowKey));
Append.add(Bytes.toBytes("ColFam"), Bytes.toBytes("id"), Bytes.toBytes(2));
Append.add(Bytes.toBytes("ColFam"), Bytes.toBytes("lastName"), Bytes.toBytes("Harris"));
Result result = table.append(append)

// checkAndPut
byte[] row = Bytes.toBytes(RowKey);
byte[] colfam = Bytes.toBytes("ColFam");
byte[] col = Bytes.toBytes("lastName");
Put put = new Put(row);
put.add(colfam, col, Bytes.toBytes("Patrick"));
boolearn result = table.checkAndPut(row, colfam, col, Bytes.toBytes("Witherspoon"), put);

Phoenix

UPSERT INTO FamilyTable (id, lastName) VALUES (1, ‘Brown’)
ON DUPLICATE KEY UPDATE id = "1", lastName = "Whiterspoon";

Azure Cosmos DB

No Azure Cosmos DB, as atualizações são tratadas como operações de Upsert. Ou seja, se o documento não existir, ele será inserido.

// Replace existing document with new modified document (contingent on modification).

Family family = new Family();
family.setLastName("Brown");
family.setId("1");

CosmosItemResponse<Family> famResp = container.upsertItem(family, new CosmosItemRequestOptions());

Excluir linha/documento

HBase

No Hbase, não há nenhuma forma direta de exclusão de selecionar a linha por valor. Você pode ter implementado o processo de exclusão em combinação com ValueFilter etc. Neste exemplo, a linha a ser excluída é especificada por RowKey.

HTable table = new HTable(config, "FamilyTable");

Delete delete = new Delete(Bytes.toBytes(RowKey));
delete.deleteColumn(Bytes.toBytes("ColFam"), Bytes.toBytes("id"));
delete.deleteColumn(Bytes.toBytes("ColFam"), Bytes.toBytes("lastName"));

table.dalate(delete)

Phoenix

DELETE FROM TableName WHERE id = "xxx";

Azure Cosmos DB

O método de exclusão por ID do documento é mostrado abaixo.

container.deleteItem(documentId, new PartitionKey(documentLastName), new CosmosItemRequestOptions());

Consultar linhas/documentos

HBase O HBase permite recuperar várias linhas usando a verificação. Você pode usar Filtrar para especificar condições detalhadas de verificação. Consulte Filtros de solicitação de cliente para tipos de filtros internos do HBase.

HTable table = new HTable(config, "FamilyTable");

Scan scan = new Scan();
SingleColumnValueFilter filter = new SingleColumnValueFilter(Bytes.toBytes("ColFam"),
Bytes.toBytes("lastName"), CompareOp.EQUAL, New BinaryComparator(Bytes.toBytes("Witherspoon")));
filter.setFilterIfMissing(true);
filter.setLatestVersionOnly(true);
scan.setFilter(filter);

ResultScanner scanner = table.getScanner(scan);

Phoenix

SELECT * FROM FamilyTable WHERE lastName = "Witherspoon"

Azure Cosmos DB

Operação de filtro

String sql = "SELECT * FROM c WHERE c.lastName = 'Witherspoon'";
CosmosPagedIterable<Family> filteredFamilies = container.queryItems(sql, new CosmosQueryRequestOptions(), Family.class);

Excluir tabela/coleção

HBase

HBaseAdmin admin = new HBaseAdmin(config);
admin.deleteTable("FamilyTable")

Phoenix

DROP TABLE IF EXISTS FamilyTable;

Azure Cosmos DB

CosmosContainerResponse containerResp = database.getContainer("FamilyContainer").delete(new CosmosContainerRequestOptions());

Outras considerações

Os clusters do HBase podem ser usados com cargas de trabalho do HBase e do MapReduce, Hive, Spark e muito mais. Se você tiver outras cargas de trabalho com o HBase atual, elas também precisarão ser migradas. Para obter detalhes, consulte cada guia de migração.

  • MapReduce
  • HBase
  • Spark

Programação do lado do servidor

O HBase oferece vários recursos de programação do lado do servidor. Você também precisará migrar o processamento deles, se estiver usando esses recursos.

HBase

  • Filtros personalizados

    Vários filtros estão disponíveis como padrão no HBase, mas você também pode implementar seus próprios filtros personalizados. Os filtros personalizados podem ser implementados se os filtros disponíveis como padrão no HBase não atenderem aos seus requisitos.

  • Coprocessador

    O Coprocessador é uma estrutura que permite que você execute seu próprio código no Servidor de Região. Usando o Coprocessador, é possível fazer o processamento que estava sendo executado no lado do cliente no lado do servidor e, dependendo do processamento, ele pode ser feito com mais eficiência. Há dois tipos de Coprocessadores: Observador e Participante.

    • Observador

      • O Observador conecta operações e eventos específicos. Esta é uma função para adicionar processamento arbitrário. Este é um recurso semelhante aos gatilhos RDBMS.

    • Ponto de extremidade

      • O Participante é um recurso para estender a RPC do HBase. É uma função semelhante a um procedimento armazenado pelo RDBMS.

Azure Cosmos DB

  • Procedimento armazenado

    • Os procedimentos armazenados do Azure Cosmos DB são escritos em JavaScript e podem executar operações como criar, atualizar, ler, consultar e excluir itens em contêineres do Azure Cosmos DB.

  • Gatilho

    • Gatilhos podem ser especificados para operações no banco de dados. Há dois métodos fornecidos: um pré-gatilho que é executado antes das alterações do item do banco de dados e um pós-gatilho que é executado após a alteração do item do banco de dados.

  • UDF

    • O Azure Cosmos DB permite definir UDFs (Funções Definidas pelo Usuário). As UDFs também podem ser gravadas em JavaScript.

Procedimentos armazenados e gatilhos consomem RUs com base na complexidade das operações executadas. Ao desenvolver o processamento no lado do servidor, verifique o uso necessário para ter um melhor entendimento da quantidade de RUs consumidas por cada operação. Consulte Unidades de solicitação no Azure Cosmos DB e Otimizar custo de solicitação no Azure Cosmos DB para obter detalhes.

Mapeamentos de programação do lado do servidor

HBase Azure Cosmos DB Descrição
Filtros personalizados ONDE cláusula Se o processamento implementado pelo filtro personalizado não puder ser atingido pela cláusula WHERE no Azure Cosmos DB, use a UDF em combinação.
Coprocessador (Observador) Gatilho O Observador é um gatilho executado antes e depois de um evento específico. Assim como o Observador dá suporte a pré e pós-chamadas, o gatilho do Azure Cosmos DB também dá suporte a pré e pós-gatilhos.
Coprocessador (Participante) Procedimento armazenado O Participante é um mecanismo de processamento de dados do lado do servidor executado para cada região. Ele é semelhante a um procedimento armazenado pelo RDBMS. Os procedimentos armazenados do Azure Cosmos DB são escritos em JavaScript. Ele fornece acesso a todas as operações que você pode executar no Azure Cosmos DB por meio de procedimentos armazenados.

Observação

Mapeamentos e implementações diferentes podem ser necessários no Azure Cosmos DB, dependendo do processamento implementado no HBase.

Segurança

A segurança dos dados é uma responsabilidade compartilhada do cliente e do provedor de banco de dados. Para soluções locais, os clientes têm que fornecer tudo, desde a proteção do ponto de extremidade até a segurança do hardware físico, o que não é uma tarefa fácil. Se você escolher um provedor de banco de dados em nuvem PaaS, como o Azure Cosmos DB, o envolvimento do cliente será reduzido. O Azure Cosmos DB é executado na plataforma Azure, de modo que ele possa ser aprimorado de uma forma diferente do HBase. O Azure Cosmos DB não exige que nenhum componente extra seja instalado por segurança. Recomendamos que você considere migrar a implementação de segurança do sistema de banco de dados usando a seguinte lista de verificação:

Controle de segurança HBase Azure Cosmos DB
Configurações de firewall e segurança de rede Controlar o tráfego usando funções de segurança, como dispositivos de rede. Oferece suporte ao controle de acesso baseado em IP baseado em política no firewall de entrada.
Autenticação de usuário e controles de usuário refinados Controle de acesso refinado combinando LDAP com componentes de segurança, como o Apache Ranger. Você pode usar a chave primária da conta para criar recursos de usuário e permissão para banco de dados. Você também pode usar seu Microsoft Entra ID para autenticar suas solicitações de dados. Isso permite a você autorizar solicitações de dados usando um modelo de RBAC refinado.
Capacidade de replicar dados globalmente para falhas regionais Faça uma réplica de banco de dados em um data center remoto usando a replicação do HBase. O Azure Cosmos DB executa a distribuição global sem configuração e permite replicar os dados para data centers em todo o mundo no Azure com a seleção de um botão. Em termos de segurança, a replicação global garante a proteção dos seus dados contra falhas locais.
Capacidade de failover de um data center para outro Você precisa implementar o failover por conta própria. Se você estiver replicando dados para vários data centers e o data center da região ficar offline, o Azure Cosmos DB fará a operação automaticamente.
Replicação de dados locais em um data center O mecanismo do HDFS permite que você tenha várias réplicas entre nós em um único sistema de arquivos. O Azure Cosmos DB replica automaticamente os dados para manter a alta disponibilidade, mesmo em um só data center. Você pode escolher o nível de consistência por conta própria.
Backup de dados automático Não há função de backup automático. Você precisa implementar o backup de dados por conta própria. O backup do Azure Cosmos DB é feito regularmente e mantido no armazenamento com redundância geográfica.
Proteger e isolar dados confidenciais Por exemplo, se estiver usando o Apache Ranger, é possível usar a política do Ranger para aplicar a política à tabela. Você pode separar dados pessoais e outros dados confidenciais em contêineres específicos e ler/gravar ou limitar o acesso somente leitura a usuários específicos.
Monitoramento de ataques Precisa ser implementado usando produtos de terceiros. Com o log de auditoria e os logs de atividade, você pode monitorar as atividades normais e anormais de sua conta.
Resposta aos ataques Precisa ser implementado usando produtos de terceiros. Quando você contata o suporte do Azure e relata um possível ataque, começa um processo de resposta a incidentes de cinco etapas.
Capacidade de limitar os dados geograficamente a fim de aderir a restrições de controle de dados Você precisa verificar as restrições de cada país/região e implementá-las por conta própria. Garante a governança de dados para regiões soberanas (Alemanha, China, US Gov etc.).
Proteção física dos servidores em data centers protegidos Depende do data center onde o sistema está localizado. Para ver uma lista das certificações mais recentes, consulte o Local de conformidade global do Azure.
Certificações Depende da distribuição de Hadoop. Consulte a Documentação de conformidade do Azure

Monitoramento

O HBase geralmente monitora o cluster usando a interface do usuário da Web métrica do cluster ou com a Ambari, o Cloudera Manager ou outras ferramentas de monitoramento. O Azure Cosmos DB permite que você use o mecanismo de monitoramento integrado à plataforma do Azure. Para obter mais informações sobre o monitoramento do Azure Cosmos DB, consulte Monitorar o Azure Cosmos DB.

Se seu ambiente implementar o monitoramento do sistema HBase para enviar alertas, como por email, você poderá substituí-lo por alertas do Azure Monitor. Você pode receber alertas com base em eventos de log de atividades ou métricas para sua conta do Azure Cosmos DB.

Para obter mais informações sobre alertas no Azure Monitor, consulte Criar alertas para o Azure Cosmos DB usando o Azure Monitor

Além disso, confira Tipos de logs e métricas do Azure Cosmos DB que podem ser coletados pelo Azure Monitor.

Backup e recuperação de desastre

Backup

Há várias maneiras de obter um backup do HBase. Por exemplo, Instantâneo, Exportação, CopyTable, Backup offline de dados do HDFS e outros backups personalizados.

O Azure Cosmos DB faz o backup de dados automaticamente em intervalos periódicos e isso não afeta o desempenho ou a disponibilidade das operações de banco de dados. Os backups são armazenados no armazenamento do Azure e podem ser usados para recuperar dados, se necessário. Há dois tipos de backups do Azure Cosmos DB:

Recuperação de desastre

O HBase é um sistema distribuído tolerante a falhas, mas você deve implementar a recuperação de desastre usando Instantâneo, replicação etc. quando o failover é necessário no local de backup no caso de uma falha no nível do data center. A replicação do HBase pode ser configurada com três modelos de replicação: Leader-Follower, Leader-Leader e Cyclic. Se o HBase de origem implementar a recuperação de desastre, você precisará entender como configurá-la no Azure Cosmos DB e atender aos requisitos do sistema.

O Azure Cosmos DB é um banco de dados globalmente distribuído com recursos internos de recuperação de desastre. Você pode replicar seus dados do BD para qualquer região do Azure. O Azure Cosmos DB mantém seu banco de dados altamente disponível no caso improvável de uma falha em algumas regiões.

Uma conta do Azure Cosmos DB que usa apenas uma única região pode perder disponibilidade em caso de falha na região. Recomendamos que você configure pelo menos duas regiões para garantir alta disponibilidade sempre. Você também pode garantir alta disponibilidade para gravações e leituras configurando sua conta do Azure Cosmos DB para abranger pelo menos duas regiões com várias regiões de gravação a fim de garantir alta disponibilidade para gravações e leituras. Para contas de várias regiões que consistem em várias regiões de gravação, o failover entre regiões é detectado e manipulado pelo cliente do Azure Cosmos DB. Elas são momentâneas e não exigem alterações do aplicativo. Dessa forma, você pode obter uma configuração de disponibilidade que inclui a DR para o Azure Cosmos DB. Como já mencionado, a replicação do HBase pode ser configurada com três modelos, mas o Azure Cosmos DB pode ser configurado com a disponibilidade baseada em SLA pela configuração de regiões de gravação única e de várias gravações.

Para obter mais informações sobre Alta Disponibilidade, consulte Como o Azure Cosmos DB oferece alta disponibilidade

Perguntas frequentes

Por que migrar para a API para NoSQL em vez de outras APIs do Azure Cosmos DB?

A API para NoSQL fornece a melhor experiência de ponta a ponta em termos da interface e da biblioteca de clientes do SDK de serviço. Os novos recursos distribuídos para o Azure Cosmos DB estarão disponíveis pela primeira vez na sua conta da API para NoSQL. Além disso, a API para NoSQL dá suporte à análise e fornece a separação de desempenho entre cargas de trabalho de produção e análise. Caso você deseje usar as tecnologias modernizados para criar seus aplicativos, a API para NoSQL é a opção recomendada.

Posso atribuir a RowKey do HBase à chave de partição do Azure Cosmos DB?

Ela pode não ser otimizada como está. No HBase, os dados são organizados pela RowKey especificada, armazenados na Região e divididos em tamanhos fixos. Eles se comportam de maneira diferente do particionamento no Azure Cosmos DB. Portanto, as chaves precisam ser redesenhadas para distribuir melhor os dados de acordo com as características da carga de trabalho. Confira a seção Distribuição para obter mais detalhes.

Os dados são organizados por RowKey no HBase, mas por particionamento por chave no Azure Cosmos DB. Como o Azure Cosmos DB pode obter a classificação e a colocação?

No Azure Cosmos DB, você pode adicionar um índice composto para classificar seus dados em ordem ascendente ou decrescente, a fim de aprimorar o desempenho de consultas de igualdade e intervalo. Consulte a seção Distribuição e o Índice composto na documentação do produto.

O processamento analítico é executado em dados do HBase com o Hive ou o Spark. Como posso modernizá-los no Azure Cosmos DB?

Você pode usar o armazenamento analítico do Azure Cosmos DB para sincronizar automaticamente os dados operacionais com outro armazenamento de colunas. O formato de armazenamento de colunas é adequado para consultas grandes de análise que são executadas de forma otimizada, o que melhora a latência para essas consultas. O Link do Azure Synapse permite que você crie uma solução HTAP livre de ETL vinculando diretamente do Azure Synapse Analytics ao armazenamento analítico do Azure Cosmos DB. Isso permite que você execute uma análise de dados operacionais em grande escala e quase em tempo real. O Synapse Analytics dá suporte aos pools de SQL sem servidor e do Apache Spark no armazenamento analítico do Azure Cosmos DB. Você pode aproveitar esse recurso para migrar seu processamento analítico. Para obter mais informações, consulte Armazenamento analítico.

Como os usuários podem usar a consulta de carimbo de data/hora no HBase para o Azure Cosmos DB?

O Azure Cosmos DB não tem exatamente o mesmo recurso de controle de versão de carimbo de data/hora do HBase. No entanto, o Azure Cosmos DB oferece a capacidade de acessar o feed de alterações, e você pode utilizá-lo para o controle de versão.

  • Armazene cada versão/alteração como um item separado.

  • Leia o feed de alterações para mesclar/consolidar alterações e disparar ações apropriadas a jusante, filtrando com o campo "_ts". Além disso, para a versão antiga dos dados, você pode expirar versões antigas usando TTL.

Próximas etapas