Migrar dados do Cassandra para uma conta do Azure Cosmos DB for Apache Cassandra usando o Azure Databricks

APLICA-SE AO: Cassandra

A API do Cassandra no Azure Cosmos DB se tornou uma ótima opção para cargas de trabalho corporativas em execução no Apache Cassandra por vários motivos:

• Nenhuma sobrecarga de gerenciamento e monitoramento: elimina a sobrecarga de gerenciar e monitorar configurações em arquivos de SO, JVM e YAML e suas interações.

• Economia de custos significativa: é possível economizar custos com o Azure Cosmos DB, incluindo os custos de VMs, largura de banda e todas as licenças aplicáveis. Você não precisa gerenciar os custos de data centers, servidores, armazenamento de SSD, rede e eletricidade.

• Capacidade de usar o código e as ferramentas existentes: o Azure Cosmos DB oferece compatibilidade no nível de protocolo com as ferramentas e os SDKs existentes do Cassandra. Essa compatibilidade garante que seja possível usar a base de código existente com o Azure Cosmos DB for Apache Cassandra mediante alterações básicas.

Há muitas formas de migrar cargas de trabalho de banco de dados de uma plataforma para outra. Azure Databricks é uma oferta de plataforma como serviço (PaaS) para o Apache Spark que oferece um modo de realizar migrações offline em grande escala. Este artigo descreve as etapas necessárias para migrar dados de keyspaces e tabelas nativos do Apache Cassandra para o Azure Cosmos DB for Apache Cassandra usando o Azure Databricks.

Prerequisites

• Provisionar uma conta do Azure Cosmos DB para Apache Cassandra.

• Revisar os conceitos básicos de conexão com o Azure Cosmos DB for Apache Cassandra.

• Examinar os recursos com suporte no Azure Cosmos DB for Apache Cassandra para garantir a compatibilidade.

• Certifique-se de que você já criou keyspaces e tabelas vazios na conta de destino do Azure Cosmos DB for Apache Cassandra.

• Use cqlsh para validação.

Criação de um workspace do Azure Databricks

Você pode seguir as instruções para provisionar um workspace do Azure Databricks. Você pode usar a computação padrão disponível ou criar um novo recurso de computação para executar seu notebook. Selecione um runtime do Databricks compatível com pelo menos o Spark 3.0.

Adicionar dependências

Você precisa adicionar a biblioteca do Conector do Apache Spark para Cassandra ao seu ambiente de computação para se conectar tanto aos pontos de extremidade nativos quanto aos pontos de extremidade do Cassandra do Azure Cosmos DB. Em sua computação, selecione Bibliotecas>Instalar Novo>Maven e, em seguida, adicione com.datastax.spark:spark-cassandra-connector-assembly_2.12:3.0.0 as coordenadas do Maven.

Selecione Instalar e reinicie a computação quando a instalação for concluída.

Criar um Notebook Scala para migração

Crie um Notebook Scala no Databricks. Substitua os parâmetros de configuração do Cassandra de origem e de destino pelas credenciais correspondentes, e pelos keyspaces e tabelas de origem e de destino. Em seguida, execute o código a seguir:

import com.datastax.spark.connector._
import com.datastax.spark.connector.cql._
import org.apache.spark.SparkContext

// source cassandra configs
val nativeCassandra = Map( 
    "spark.cassandra.connection.host" -> "<Source Cassandra Host>",
    "spark.cassandra.connection.port" -> "9042",
    "spark.cassandra.auth.username" -> "<USERNAME>",
    "spark.cassandra.auth.password" -> "<PASSWORD>",
    "spark.cassandra.connection.ssl.enabled" -> "false",
    "keyspace" -> "<KEYSPACE>",
    "table" -> "<TABLE>"
)

//target cassandra configs
val cosmosCassandra = Map( 
    "spark.cassandra.connection.host" -> "<USERNAME>.cassandra.cosmos.azure.com",
    "spark.cassandra.connection.port" -> "10350",
    "spark.cassandra.auth.username" -> "<USERNAME>",
    "spark.cassandra.auth.password" -> "<PASSWORD>",
    "spark.cassandra.connection.ssl.enabled" -> "true",
    "keyspace" -> "<KEYSPACE>",
    "table" -> "<TABLE>",
    //throughput related settings below - tweak these depending on data volumes. 
    "spark.cassandra.output.batch.size.rows"-> "1",
    "spark.cassandra.output.concurrent.writes" -> "1000",
    //"spark.cassandra.connection.remoteConnectionsPerExecutor" -> "1", // Spark 3.x
    "spark.cassandra.connection.connections_per_executor_max"-> "1", // Spark 2.x
    "spark.cassandra.concurrent.reads" -> "512",
    "spark.cassandra.output.batch.grouping.buffer.size" -> "1000",
    "spark.cassandra.connection.keep_alive_ms" -> "600000000"
)

//Read from native Cassandra
val DFfromNativeCassandra = sqlContext
  .read
  .format("org.apache.spark.sql.cassandra")
  .options(nativeCassandra)
  .load
  
//Write to CosmosCassandra
DFfromNativeCassandra
  .write
  .format("org.apache.spark.sql.cassandra")
  .options(cosmosCassandra)
  .mode(SaveMode.Append) // only required for Spark 3.x
  .save

Troubleshoot

Limitação de taxa (erro 429)

Você talvez veja um código de erro 429 ou o texto de erro "taxa de solicitação é grande" mesmo que você tenha reduzido as configurações para os valores mínimos. Os seguintes cenários podem causar limitação de taxa:

• A taxa de transferência alocada para a tabela é inferior a 6.000 unidades de solicitação . Mesmo nas configurações mínimas, o Spark pode gravar a uma taxa de aproximadamente 6.000 unidades de solicitação ou mais. Se você provisionou uma tabela em um keyspace com taxa de transferência compartilhada, é possível que essa tabela tenha menos de 6.000 RUs disponíveis no tempo de execução.

  Verifique se a tabela para a qual você está migrando disponha de pelo menos 6.000 RUs quando você executar a migração. Se necessário, aloque unidades de solicitação dedicadas para essa tabela.

• Distorção de dados excessiva com grande volume de dados. Se você tiver uma grande quantidade de dados para migrar para uma determinada tabela, mas tiver uma distorção significativa nos dados (ou seja, um grande número de registros sendo gravados para o mesmo valor de chave de partição), ainda poderá enfrentar uma limitação de taxa mesmo que tenha várias unidades de solicitação provisionadas na tabela. As unidades de solicitação são divididas igualmente entre as partições físicas, e um grande desvio de dados pode congestionar as solicitações em uma única partição.

  Nesse cenário, reduza as configurações da taxa de transferência mínima no Spark e force a migração para execução lenta. Esse cenário pode ser mais comum quando você está migrando tabelas de referência ou de controle, em que o acesso é menos frequente e a distorção pode ser elevada. No entanto, se um desvio significativo estiver presente em qualquer outro tipo de tabela, talvez você queira examinar seu modelo de dados para evitar problemas de partição quente para a carga de trabalho durante operações em estado estável.

Próximas Etapas 

• Provisionar largura de banda para contêineres e bancos de dados
• Estimar RU/s usando o Planejador de Capacidade do Azure Cosmos DB
• Escala Elástica no Azure Cosmos DB para Apache Cassandra