Partilhar via

Migrar centenas de terabytes de dados para o Azure Cosmos DB

  • Aplica-se a: ✅ NoSQL, ✅ MongoDB, ✅ Apache Cassandra, ✅ Apache Gremlin, ✅ Table

O Azure Cosmos DB pode armazenar terabytes de dados. Pode realizar uma migração de dados de grande escala para mover a carga de trabalho de produção para o Azure Cosmos DB. Este artigo descreve os desafios envolvidos na migração de dados de grande escala para o Azure Cosmos DB e apresenta-lhe a ferramenta que o ajuda com os desafios e que migra os dados para o Azure Cosmos DB. Neste estudo de caso, o cliente usou a API do Azure Cosmos DB para NoSQL.

Antes de migrar toda a carga de trabalho para o Azure Cosmos DB, você pode migrar um subconjunto de dados para validar alguns dos aspetos, como a escolha da chave de partição, o desempenho da consulta e a modelagem de dados. Depois de validar a prova de conceito, você pode mover toda a carga de trabalho para o Azure Cosmos DB.

Ferramentas para migração de dados

Atualmente, as estratégias de migração do Azure Cosmos DB diferem com base na escolha da API e no tamanho dos dados. Para migrar conjuntos de dados mais pequenos – para validar modelação de dados, desempenho de consultas, escolha de chaves de partição, etc. – pode usar o conector Azure Cosmos DB do Azure Data Factory. Se você estiver familiarizado com o Spark, também poderá optar por usar o conector Spark do Azure Cosmos DB para migrar dados.

Desafios para as migrações em grande escala

As ferramentas existentes para migrar dados para o Azure Cosmos DB têm algumas limitações que se tornam especialmente aparentes em grandes escalas:

  • Recursos de expansão limitados: para migrar terabytes de dados para o Azure Cosmos DB o mais rápido possível e consumir efetivamente toda a taxa de transferência provisionada, os clientes de migração devem ter a capacidade de expandir indefinidamente.

  • Falta de acompanhamento do progresso e ponto de verificação: é importante acompanhar o progresso da migração e ter um ponto de verificação durante a migração de grandes conjuntos de dados. Caso contrário, qualquer erro que ocorra durante a migração impede a migração, e tens de começar o processo do zero. Não seria produtivo reiniciar todo o processo de migração quando 99% dele já foi concluído.

  • Falta de fila de mensagens mortas: em grandes conjuntos de dados, pode haver problemas com partes dos dados de origem em alguns casos. Além disso, pode haver problemas transitórios com o cliente ou a rede. Nenhum destes casos deve causar o fracasso total da migração. Apesar de a maioria das ferramentas de migração dispor de capacidades robustas de reintento que protegem contra problemas intermitentes, isso nem sempre é suficiente. Por exemplo, se menos de 0,01% dos documentos de dados de origem forem superiores a 2 MB, isso faz com que a escrita do documento falhe no Azure Cosmos DB. Idealmente, é útil para a ferramenta de migração persistir estes documentos 'falhados' para outra fila de cartas mortas, que pode ser processada após a migração.

Muitas dessas limitações estão sendo corrigidas para ferramentas como o Azure Data factory, os serviços de Migração de Dados do Azure.

Ferramenta personalizada com biblioteca de executores em massa

Os desafios descritos na secção anterior podem ser resolvidos usando uma ferramenta personalizada que pode ser facilmente escalada em múltiplas instâncias e que é resistente a falhas transitórias. Além disso, a ferramenta personalizada pode pausar e retomar a migração em vários pontos de verificação. O Azure Cosmos DB já fornece a biblioteca de executores em massa que incorpora alguns desses recursos. Por exemplo, a biblioteca de executores em massa já tem a funcionalidade de lidar com erros transitórios e pode dimensionar threads em um único nó para consumir cerca de 500 K RUs por nó. A biblioteca de executores em massa também particiona o conjunto de dados de origem em microlotes que são operados independentemente como uma forma de ponto de verificação.

A ferramenta personalizada utiliza a biblioteca do executor de operações em massa e permite o dimensionamento em vários clientes, além de monitorizar erros durante o processo de ingestão. Para usar essa ferramenta, os dados de origem devem ser particionados em arquivos distintos no Azure Data Lake Storage (ADLS) para que diferentes operadores de migração possam pegar cada arquivo e ingeri-los no Azure Cosmos DB. A ferramenta personalizada faz uso de uma coleção separada, que armazena metadados sobre o progresso da migração para cada arquivo de origem individual no ADLS e rastreia quaisquer erros associados a eles.

A imagem a seguir descreve o processo de migração usando essa ferramenta personalizada. A ferramenta está sendo executada em um conjunto de máquinas virtuais e cada máquina virtual consulta a coleção de rastreamento no Azure Cosmos DB para adquirir uma concessão em uma das partições de dados de origem. Feito isso, a partição de dados de origem é lida pela ferramenta e ingerida no Azure Cosmos DB usando a biblioteca de executores em massa. Em seguida, a coleta de rastreamento é atualizada para registrar o progresso da ingestão de dados e quaisquer erros encontrados. Depois que uma partição de dados é processada, a ferramenta tenta consultar a próxima partição de origem disponível. Ele continua a processar a próxima partição de origem até que todos os dados sejam migrados. O código-fonte da ferramenta está disponível no repositório de ingestão em massa do Azure Cosmos DB.

Configuração da ferramenta de migração

A coleção de acompanhamento contém documentos, conforme mostrado no exemplo a seguir. Você verá esses documentos um para cada partição nos dados de origem. Cada documento contém os metadados para a partição de dados de origem, como sua localização, status de migração e erros (se houver):

{ 
  "owner": "25812@bulkimporttest07", 
  "jsonStoreEntityImportResponse": { 
    "numberOfDocumentsReceived": 446688, 
    "isError": false, 
    "totalRequestUnitsConsumed": 3950252.2800000003, 
    "errorInfo": [], 
    "totalTimeTakenInSeconds": 188, 
    "numberOfDocumentsImported": 446688 
  }, 
  "storeType": "AZURE_BLOB", 
  "name": "sourceDataPartition", 
  "location": "sourceDataPartitionLocation", 
  "id": "sourceDataPartitionId", 
  "isInProgress": false, 
  "operation": "unpartitioned-writes", 
  "createDate": { 
    "seconds": 1561667225, 
    "nanos": 146000000 
  }, 
  "completeDate": { 
    "seconds": 1561667515, 
    "nanos": 180000000 
  }, 
  "isComplete": true 
}

Pré-requisitos para migração de dados

Antes do início da migração de dados, há alguns pré-requisitos a serem considerados:

Estimar o tamanho dos dados:

O tamanho dos dados de origem pode não corresponder exatamente ao tamanho dos dados no Azure Cosmos DB. Alguns documentos de exemplo da origem podem ser inseridos para verificar o tamanho dos dados no Azure Cosmos DB. Dependendo do tamanho do documento de exemplo, pode-se estimar o tamanho total dos dados no Azure Cosmos DB após a migração.

Por exemplo, se cada documento após a migração no Azure Cosmos DB tiver cerca de 1 KB e se houver cerca de 60 bilhões de documentos no conjunto de dados de origem, isso significaria que o tamanho estimado no Azure Cosmos DB seria próximo de 60 TB.

Prepare antecipadamente contêineres com RUs suficientes.

Embora o Azure Cosmos DB escale automaticamente o armazenamento, não é aconselhável começar pelo menor tamanho do contentor. Contentores menores têm menor capacidade de largura de banda, o que significa que a migração demoraria muito mais a concluir. Em vez disso, é útil criar os contentores com o tamanho final dos dados (de acordo com o estimado no passo anterior) e garantir que a tarefa de migração está a consumir totalmente a largura de banda provisionada.

No passo anterior, como o tamanho dos dados foi estimado em cerca de 60 TB, é necessário um contentor com pelo menos 2,4 milhões de RUs para acomodar todo o conjunto de dados.

Estimar a velocidade de migração:

Supondo que a carga de trabalho de migração possa consumir toda a taxa de transferência provisionada, o provisionado ao longo forneceria uma estimativa da velocidade de migração. Continuando o exemplo anterior, são necessárias cinco RUs para escrever um documento de 1 KB na API Azure Cosmos DB para a conta NoSQL. 2.4 milhões de RUs permitiriam uma transferência de 480 000 documentos por segundo (ou 480 MB/s). Isto significa que a migração completa de 60 TB demora 125.000 segundos, ou cerca de 34 horas.

Caso deseje que a migração seja concluída dentro de um dia, deve-se aumentar o throughput provisionado para 5 milhões de RUs.

Desative a indexação:

Como a migração deve ser concluída o mais rapidamente possível, é aconselhável minimizar o tempo e as RUs gastas na criação de índices para cada um dos documentos ingeridos. O Azure Cosmos DB indexa automaticamente todas as propriedades, vale a pena minimizar a indexação a alguns termos selecionados ou desligá-lo completamente durante a migração. Pode desativar a política de indexação do contentor alterando o indexingMode para nenhum, como mostrado aqui:

  { 
        "indexingMode": "none" 
  }

Após a conclusão da migração, você poderá atualizar a indexação.

Processo de migração

Depois que os pré-requisitos forem concluídos, você poderá migrar dados com as seguintes etapas:

  1. Primeiro, importe os dados da origem para o Armazenamento de Blobs do Azure. Para aumentar a velocidade de migração, é útil paralelizar entre partições de origem distintas. Antes de iniciar a migração, o conjunto de dados de origem deve ser particionado em arquivos com tamanho em torno de 200 MB.

  2. A biblioteca de executores em massa pode ser dimensionada para consumir 500.000 RUs em uma única VM cliente. Como a taxa de transferência disponível é de 5 milhões de RUs, 10 VMs (Standard_D32_v3) do Ubuntu 16.04 devem ser provisionadas na mesma região onde seu banco de dados do Azure Cosmos DB está localizado. Você deve preparar essas VMs com a ferramenta de migração e seu arquivo de configurações.

  3. Execute a etapa de fila numa das máquinas virtuais do cliente. Esta etapa cria a coleção de rastreamento, que analisa o contentor ADLS e cria um documento de acompanhamento de progresso para cada ficheiro de partição do conjunto de dados de origem.

  4. Em seguida, execute a etapa de importação em todas as VMs cliente. Cada um dos clientes pode assumir a propriedade de uma partição de origem e ingerir seus dados no Azure Cosmos DB. Uma vez concluído e o seu estado atualizado na coleção de rastreamento, os clientes podem então consultar a próxima partição de origem disponível na coleção de rastreamento.

  5. Este processo continua até que todo o conjunto de partições de origem tenha sido ingerido. Uma vez que todas as partições de origem são processadas, a ferramenta deve ser executada novamente no modo de correção de erros na mesma coleção de rastreamento. Este passo é necessário para identificar as partições de origem que devem ser reprocessadas devido a erros.

  6. Alguns destes erros podem dever-se a documentos incorretos nos dados de origem. Estes devem ser identificados e corrigidos. Em seguida, deve executar novamente a etapa de importação nas partições com falha para reingeri-las.

Depois que a migração for concluída, você poderá validar se a contagem de documentos no Azure Cosmos DB é igual à contagem de documentos no banco de dados de origem. Neste exemplo, o tamanho total no Azure Cosmos DB foi de 65 terabytes. Após a migração, a indexação pode ser ativada seletivamente e as RUs podem ser reduzidas ao nível exigido pelas operações da carga de trabalho.

Próximos passos

  • Saiba mais experimentando os aplicativos de exemplo que consomem a biblioteca de executores em massa em .NET e Java.
  • A biblioteca de execução em massa está integrada no conector Spark do Azure Cosmos DB, para saber mais, veja o artigo do Azure Cosmos DB Spark connector.
  • Contacte a equipa de produto do Azure Cosmos DB abrindo um ticket de suporte sob o tipo de problema "General Advisory" e o subtipo de problema "Large (TB+) migrations" para obter mais ajuda com migrações em grande escala.
  • Tentando fazer o planejamento de capacidade para uma migração para o Azure Cosmos DB? Você pode usar informações sobre seu cluster de banco de dados existente para planejamento de capacidade.
  • Last updated on