Partilhar via

Migrar dados do Apache HBase para o Azure Cosmos DB para conta NoSQL

  • Artigo

APLICA-SE A: NoSQL

O Azure Cosmos DB é um banco de dados escalável, distribuído globalmente e totalmente gerenciado. Ele fornece acesso garantido de baixa latência aos seus dados. Para saber mais sobre o Azure Cosmos DB, consulte o artigo de visão geral . Este artigo orienta como migrar seus dados do HBase para a 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 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 recursos

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

HBase Phoenix BD do Cosmos para o Azure
Cluster Cluster Account
Espaço de Nomes Esquema (se habilitado) Base de Dados
Tabela Tabela Contentor/Recolha
Família de colunas Família de colunas N/A
Linha Linha Item/Documento
Versão (Timestamp) Versão (Timestamp) N/A
N/A Chave Primária Chave de Partição
N/A Índice Índice
N/A Índice Secundário Índice Secundário
N/A Vista N/A
N/A Sequence N/A

Comparação e diferenças da estrutura dos dados

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

Chave de linha

  • 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, por 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 dentro de uma Família de Colunas (CF).

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

Carimbo de data/hora

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

  • O Azure Cosmos DB é fornecido com o recurso Alterar feed, que rastreia o registro persistente de alterações em um contêiner na ordem em que ocorrem. Em seguida, disponibiliza a lista ordenada dos documentos que foram alterados, pela ordem pela qual foram modificados.

Formato de dados

  • O formato de dados do HBase consiste em RowKey, Column Family: Column Name, Timestamp, Value. Segue-se um exemplo de uma linha de tabela 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 para 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 para a coleção. O Azure Cosmos DB não tem o conceito de carimbo de data/hora usado para a família ou versão da coluna. Como destacado anteriormente, ele tem suporte de feed de alterações através do qual se pode rastrear/registrar alterações realizadas em um contêiner. Segue-se 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",
}

Gorjeta

O HBase armazena dados na matriz de bytes, portanto, se você quiser migrar dados que contenham caracteres de byte duplo para o Azure Cosmos DB, os dados deverão 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 disponibilidade e desempenho. Do mais forte ao mais fraco, os níveis de consistência suportados são:

  • Forte
  • Estagnação limitada
  • Sessão
  • Prefixo consistente
  • Eventual

Dimensionamento

HBase

Para uma implantação em escala empresarial do HBase, Master; Servidores da região; e o ZooKeeper conduz a maior parte do dimensionamento. Como qualquer aplicativo distribuído, o HBase foi projetado para expansão. O desempenho do HBase é impulsionado principalmente pelo tamanho dos HBase RegionServers. O dimensionamento é impulsionado principalmente por dois requisitos principais: taxa de transferência e tamanho do conjunto de dados que deve ser armazenado no HBase.

BD do Cosmos para o Azure

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

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

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

Você também pode usar a taxa de transferência de provisionamento de dimensionamento automático no Azure Cosmos DB para dimensionar automática e instantaneamente sua taxa de transferência de banco de dados ou contêiner (RU/seg). A taxa de transferência é dimensionada com base no uso sem afetar a disponibilidade, a latência, a taxa de transferência ou o desempenho da carga de trabalho.

Distribuição de dados

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

Azure Cosmos DB O Azure Cosmos DB usa particionamento para dimensionar 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 conter até 20 GB de dados.

Cada partições físicas 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 seu tamanho, localização ou quais partições lógicas elas contêm. As partições lógicas não são divididas entre partições físicas.

Assim como no HBase RowKey, o design da chave de partição é importante para o Azure Cosmos DB. A Chave de Linha do HBase funciona classificando dados e armazenando dados contínuos, e a Chave de Partição do Azure Cosmos DB é um mecanismo diferente porque distribui dados por hash. Supondo que seu aplicativo usando o HBase esteja otimizado para padrões de acesso a dados para o HBase, usar a mesma RowKey para a 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. É obrigatório se você quiser usar a cláusula ORDER BY em mais de um campo. Você também pode melhorar o desempenho de muitas consultas iguais e de intervalo definindo um índice composto.

Disponibilidade

HBase HBase consiste em Master; Servidor da Região; e ZooKeeper. A alta disponibilidade em um único cluster pode ser alcançada tornando cada componente redundante. Ao configurar a redundância geográfica, pode-se implantar clusters HBase em diferentes data centers físicos e usar a replicação para manter vários clusters sincronizados.

Azure Cosmos DB O Azure Cosmos DB não requer nenhuma configuração, como redundância de componentes de cluster. Ele fornece um SLA abrangente para alta disponibilidade, consistência e latência. Consulte SLA do Azure Cosmos DB para obter mais detalhes.

Fiabilidade dos dados

O HBase HBase é construído no Hadoop Distributed File System (HDFS) e os dados armazenados no HDFS são replicados três vezes.

Azure Cosmos DB O Azure Cosmos DB fornece principalmente alta disponibilidade de duas maneiras. Primeiro, o Azure Cosmos DB replica dados entre regiões configuradas na sua conta do Azure Cosmos DB. Em segundo lugar, o Azure Cosmos DB mantém quatro réplicas dos dados na região.

Considerações antes da migração

Dependências do sistema

Esse aspeto do planejamento se concentra em entender as dependências upstream e downstream para a instância do HBase, que está sendo migrada para o Azure Cosmos DB.

Exemplo de dependências a jusante podem ser aplicativos que leem dados do HBase. Eles devem ser refatorados para leitura do Azure Cosmos DB. Estes seguintes pontos devem ser considerados como parte da migração:

  • Perguntas para avaliar dependências - O atual sistema HBase é 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 seu cluster HBase? Essas dependências do sistema precisam ser esclarecidas para determinar o impacto da migração.

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

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 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 seu banco de dados estiver sempre ocupado e você não puder pagar por uma longa interrupção, considere migrar online.

Nota

Este documento abrange apenas a migração offline.

Ao executar a migração de dados offline, isso 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 de desempenho

Esse aspeto do planejamento é entender as metas de desempenho para o HBase e, em seguida, traduzi-las para a semântica do Azure Cosmos DB. Por exemplo: para pressionar "X" IOPS no HBase, quantas Unidades de Solicitação (RU/s) 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 impulsionará o exercício de dimensionamento.

Perguntas a fazer:

  • A implantação do HBase é pesada em leitura ou gravação?
  • Qual é a divisão entre leituras e escritas?
  • Qual é a IOPS alvo 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 sobre implementação

Você pode usar o portal do Azure ou a CLI do Azure para implantar o Azure Cosmos DB para NoSQL. Como o destino da migração é o Azure Cosmos DB para NoSQL, selecione "NoSQL" para a API como um parâmetro ao implantar. Além disso, defina redundância geográfica, gravações em várias regiões e zonas de disponibilidade de acordo com seus requisitos de disponibilidade.

Consideração da rede

O Azure Cosmos DB tem três opções de rede principais. A primeira é uma configuração que usa um endereço IP público e controla o acesso com um firewall IP (padrão). A segunda é uma configuração que usa um endereço IP público e permite o acesso apenas 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 se junta a uma rede privada usando um endereço IP privado.

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

Avalie os dados existentes

Deteção de dados

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

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

Os comandos a seguir mostram como coletar os detalhes acima usando um script de shell hbase e armazená-los no sistema de arquivos local da máquina operacional.

Obtenha 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ê criou um namespace diferente do padrão, ele será gerado no formato "Namespace: Tabela".

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 de pilha, o número de regiões, o número de solicitações como o status do cluster e o tamanho dos dados compactados/descompactados como o status da tabela.

Se você estiver usando o Apache Phoenix no cluster HBase, também precisará coletar dados do Phoenix.

  • Tabela de destinos de migração
  • Esquemas de tabela
  • Índices
  • Chave primária

Conecte-se ao Apache Phoenix em seu cluster

sqlline.py ZOOKEEPER/hbase-unsecure

Obter a lista de tabelas

!tables

Obter os detalhes da tabela

!describe <Table Name>

Obter os detalhes do índice

!indexes <Table Name>

Obter os detalhes da chave primária

!primarykeys <Table Name>

Migrar os dados

Opções de migração

Existem 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
Azure Data Factory HBase < 2 Fácil de configurar. Adequado para grandes conjuntos de dados. Não suporta HBase 2 ou posterior.
Apache Spark Todas as versões Suporta todas as versões do HBase. Adequado para grandes conjuntos de dados. Configuração de faísca necessária.
Ferramenta personalizada com a biblioteca de executores em massa do Azure Cosmos DB Todas as versões Mais flexível para criar ferramentas personalizadas de migração de dados 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 para opções de migração de dados para o Azure Cosmos DB.

Migrar usando o Data Factory

Esta opção é adequada para grandes conjuntos de dados. A biblioteca do Azure Cosmos DB Bulk Executor é usada. Não há pontos de verificação, portanto, se você encontrar algum problema durante a migração, terá que reiniciar o processo de migração desde o início. Você também pode usar o tempo de execução de integração auto-hospedado do Data Factory para se conectar ao HBase local ou implantar o Data Factory em uma VNET gerenciada e conectar-se à sua rede local via VPN ou ExpressRoute.

A atividade de cópia do Data Factory suporta o 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 dos seus dados. Consulte o artigo Copiar e transformar dados no Azure Cosmos DB (API para NoSQL) usando o Azure Data Factory para obter mais detalhes.

Arquitetura para migrar dados do local para o Azure Cosmos DB usando o Data Factory.

Migrar usando o Apache Spark - Apache HBase Connector & Azure Cosmos DB Spark connector

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

Apache Spark – O repositório Apache HBase Connector pode ser encontrado em Apache Spark - Apache HBase Connector

Para o conector do Azure Cosmos DB Spark, 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 spark -shell com o conector Spark HBase e o conector Azure Cosmos DB Spark.

    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 maneira. 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 do HBase. Aqui, o namespace é "padrão" e o nome da tabela é "contatos". A chave de linha é especificada como a chave. Colunas, Família de colunas e 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 Azure Cosmos DB Spark.

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

  8. Faça configurações para gravar 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. Escreva dados DataFrame no Azure Cosmos DB.

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

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

Phoenix

Phoenix é suportado como uma fonte de dados do Data Factory. Consulte os seguintes documentos para obter etapas detalhadas.

Migrar o seu código

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

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

O código do Azure Cosmos DB apresentado aqui é baseado na documentação de exemplos do Azure Cosmos DB para NoSQL: Java SDK v4. Você pode acessar o exemplo de código completo da documentação.

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

Estabeleça 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);

BD do Cosmos para o Azure

// 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));

BD do Cosmos para o Azure

//  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’);

BD do Cosmos para o Azure

O Azure Cosmos DB fornece segurança de tipo 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 é parte do código. Veja o exemplo de código completo.

Use a classe Family para definir o documento e inserir o 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;

BD do Cosmos para o Azure

//  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 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, e 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";

BD do Cosmos para o Azure

No Azure Cosmos DB, as atualizações são tratadas como operações 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());

Eliminar linha/documento

HBase

No Hbase, não há nenhuma maneira de exclusão direta 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";

BD do Cosmos para o Azure

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

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

Consultar linhas/documentos

O HBase HBase permite recuperar várias linhas usando a varredura. Você pode usar Filter para especificar condições detalhadas de verificação. Consulte Filtros de solicitação de cliente para tipos de filtro 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"

BD do Cosmos para o Azure

Operação do 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;

BD do Cosmos para o Azure

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

Outras considerações

Os clusters HBase podem ser usados com cargas de trabalho do HBase e MapReduce, Hive, Spark e muito mais. Se você tiver outras cargas de trabalho com seu 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. Se você estiver usando esses recursos, também precisará migrar seu processamento.

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 às suas necessidades.

  • Coprocessador

    O Coprocessador é uma estrutura que permite executar seu próprio código no Region Server. Usando o Coprocessador, é possível realizar o processamento que estava sendo executado no lado do cliente no lado do servidor, e dependendo do processamento, ele pode ser tornado mais eficiente. Existem dois tipos de Coprocessadores, Observer e Endpoint.

    • Observer

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

    • Ponto final

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

BD do Cosmos para o Azure

  • 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.

  • Acionador

    • Os 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 de banco de dados e um pós-gatilho que é executado após as alterações do item de banco de dados.

  • UDF

    • O Azure Cosmos DB permite definir UDFs (User-Defined Functions). UDFs também podem ser escritos em JavaScript.

Procedimentos armazenados e gatilhos consomem RUs com base na complexidade das operações executadas. Ao desenvolver o processamento do lado do servidor, verifique o uso necessário para obter uma melhor compreensão da quantidade de RU consumida 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 Description
Filtros personalizados Cláusula ONDE Se o processamento implementado pelo filtro personalizado não puder ser alcançado pela cláusula WHERE no Azure Cosmos DB, use UDF em combinação.
Coprocessador (Observador) Acionador Observador é um gatilho que executa antes e depois de um determinado evento. Assim como o Observer oferece suporte a pré e pós-chamadas, o Trigger do Azure Cosmos DB também oferece suporte a pré e pós-disparadores.
Coprocessador (Endpoint) Procedimento Armazenado O ponto de extremidade é um mecanismo de processamento de dados do lado do servidor que é executado para cada região. Isso é semelhante a um procedimento armazenado 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.

Nota

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 partilhada do cliente e do fornecedor da base de dados. Para soluções locais, os clientes precisam fornecer tudo, desde proteção de endpoint até segurança de 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, portanto, pode ser aprimorado de uma maneira diferente do HBase. O Azure Cosmos DB não requer 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:

Controlo de segurança HBase BD do Cosmos para o Azure
Configuração de segurança de rede e firewall Controle o tráfego usando funções de segurança, como dispositivos de rede. Suporta 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 cada banco de dados. Você também pode usar sua ID do Microsoft Entra para autenticar suas solicitações de dados. Isso permite que você autorize solicitações de dados usando um modelo 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 uma distribuição global sem configuração e permite replicar dados para centros de dados em todo o mundo no Azure com a seleção de um botão. Em termos de segurança, a replicação global garante que seus dados estejam protegidos contra falhas locais.
Capacidade de failover de um data center para outro Você mesmo precisa implementar o failover. Se você estiver replicando dados para vários data centers e o data center da região ficar offline, o Azure Cosmos DB rolará automaticamente a operação.
Replicação local de dados em um data center O mecanismo 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 único data center. Você mesmo pode escolher o nível de consistência.
Backups automáticos de dados Não há função de backup automático. Você mesmo precisa implementar o backup de dados. O backup do Azure Cosmos DB é feito regularmente e armazenado no armazenamento com redundância geográfica.
Proteja e isole dados confidenciais Por exemplo, se você estiver usando o Apache Ranger, poderá usar a política 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.
Monitorização de ataques Ele precisa ser implementado usando produtos de terceiros. Usando o log de auditoria e os registros de atividades, você pode monitorar sua conta para atividades normais e anormais.
Resposta a ataques Ele precisa ser implementado usando produtos de terceiros. Quando você entra em contato com o suporte do Azure e relata um ataque potencial, um processo de resposta a incidentes em cinco etapas é iniciado.
Capacidade de cercar geograficamente os dados para aderir às restrições de governança de dados Você precisa verificar as restrições de cada país/região e implementá-las você mesmo. Garante a governança de dados para regiões soberanas (Alemanha, China, governo dos EUA, etc.).
Proteção física de servidores em data centers protegidos Depende do centro de dados onde o sistema está localizado. Para obter uma lista das certificações mais recentes, consulte o site global de conformidade do Azure.
Certificações Depende da distribuição do Hadoop. Consulte a documentação de conformidade do Azure

Monitorização

O HBase normalmente monitora o cluster usando a interface do usuário da Web da métrica do cluster ou com Ambari, Cloudera Manager ou outras ferramentas de monitoramento. O Azure Cosmos DB permite-lhe utilizar o mecanismo de monitorização incorporado na plataforma 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 métricas ou eventos de log de atividades 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, consulte Métricas e tipos de log do Azure Cosmos DB que podem ser coletados pelo Azure Monitor.

Backup e recuperação de desastres

Backup

Há várias maneiras de obter um backup do HBase. Por exemplo, Snapshot, Export, CopyTable, backup offline de dados HDFS e outros backups personalizados.

O Azure Cosmos DB faz backup automático dos dados em intervalos periódicos, o que não afeta o desempenho ou a disponibilidade das operações do 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 após desastre

O HBase é um sistema distribuído tolerante a falhas, mas você deve implementar a recuperação de desastres 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 Desastres, você precisará entender como configurar a Recuperação de Desastres no Azure Cosmos DB e atender aos requisitos do sistema.

O Azure Cosmos DB é um banco de dados distribuído globalmente com recursos internos de recuperação de desastres. Você pode replicar seus dados de banco de dados 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.

A conta do Azure Cosmos DB que usa apenas uma única região pode perder a disponibilidade no caso de uma falha de região. Recomendamos que você configure pelo menos duas regiões para garantir a 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 para 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 é detetado e tratado pelo cliente do Azure Cosmos DB. Estes são momentâneos e não requerem quaisquer alterações da aplicação. Dessa forma, você pode obter uma configuração de disponibilidade que inclua a Recuperação de Desastres para o Azure Cosmos DB. Como mencionado anteriormente, a replicação do HBase pode ser configurada com três modelos, mas o Azure Cosmos DB pode ser configurado com disponibilidade baseada em SLA configurando regiões de gravação única e múltipla.

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

Perguntas mais frequentes

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

API para NoSQL fornece a melhor experiência de ponta a ponta em termos de interface, biblioteca de cliente SDK de serviço. Os novos recursos implementados no Azure Cosmos DB estarão disponíveis pela primeira vez em sua conta API para NoSQL. Além disso, a API para NoSQL suporta análises e fornece separação de desempenho entre cargas de trabalho de produção e análise. Se você quiser usar as tecnologias modernizadas 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?

Pode não ser otimizado como está. No HBase, os dados são classificados pela RowKey especificada, armazenados na Região e divididos em tamanhos fixos. Isso se comporta de forma 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. Consulte a seção Distribuição para obter mais detalhes.

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

No Azure Cosmos DB, você pode adicionar um Índice Composto para classificar seus dados em ordem crescente ou decrescente para melhorar 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 Hive ou Spark. Como posso modernizá-los no Azure Cosmos DB?

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

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 que o HBase. Mas o Azure Cosmos DB fornece a capacidade de acessar o feed de alterações e você pode utilizá-lo para 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 acionar 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óximos passos