Migrar centenas de terabytes de dados para o Azure Cosmos DB

  • Artigo

APLICA-SE A: NoSQL MongoDB Cassandra Gremlin Tabela

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 caso, o cliente utilizou a API do Azure Cosmos DB para NoSQL.

Antes de migrar toda a carga de trabalho para o Azure Cosmos DB, 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 modelação de dados. Depois de validar a prova de conceito, 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 a modelação de dados, o desempenho de consultas, a escolha da chave de partição, etc. – pode utilizar o conector do Azure Cosmos DB do Azure Data Factory. Se estiver familiarizado com o Spark, também pode optar por utilizar o conector spark do Azure Cosmos DB para migrar dados.

Desafios para 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 evidentes em grandes escalas:

  • Capacidades de aumento horizontal limitadas: para migrar terabytes de dados para o Azure Cosmos DB o mais rapidamente possível e para consumir eficazmente todo o débito aprovisionado, os clientes de migração devem ter a capacidade de aumentar horizontalmente indefinidamente.

  • Falta de controlo de progresso e apontamento de verificação: é importante controlar o progresso da migração e fazer a verificação ao migrar grandes conjuntos de dados. Caso contrário, qualquer erro que ocorra durante a migração irá parar a migração e terá de iniciar o processo do zero. Não seria produtivo reiniciar todo o processo de migração quando 99% já estiver concluído.

  • Falta de fila de letras inativas: em conjuntos de dados grandes, em alguns casos, podem existir problemas com partes dos dados de origem. Além disso, podem existir problemas transitórios com o cliente ou a rede. Qualquer um destes casos não deve fazer com que toda a migração falhe. Embora a maioria das ferramentas de migração tenha capacidades de repetição robustas que se aguardem contra problemas intermitentes, nem sempre é suficiente. Por exemplo, se menos de 0,01% dos documentos de dados de origem tiverem um tamanho superior a 2 MB, fará com que a escrita do documento falhe no Azure Cosmos DB. Idealmente, é útil que a ferramenta de migração mantenha estes documentos "falhados" noutra fila de letras não entregues, que podem ser processados após a migração.

Muitas destas limitações estão a ser corrigidas para ferramentas como o Azure Data Factory, os serviços de Migração de Dados do Azure.

Ferramenta personalizada com biblioteca de executor em massa

Os desafios descritos na secção acima podem ser resolvidos através de uma ferramenta personalizada que pode ser facilmente aumentada horizontalmente em várias instâncias e é resiliente a falhas transitórias. Além disso, a ferramenta personalizada pode colocar em pausa e retomar a migração em vários pontos de verificação. O Azure Cosmos DB já fornece a biblioteca do executor em massa que incorpora algumas destas funcionalidades. Por exemplo, a biblioteca do executor em massa já tem a funcionalidade para lidar com erros transitórios e pode aumentar horizontalmente os threads num único nó para consumir cerca de 500 RUs por nó. A biblioteca do executor em massa também cria partições do conjunto de dados de origem em micro-lotes que são operados de forma independente como uma forma de ponto de verificação.

A ferramenta personalizada utiliza a biblioteca do executor em massa e suporta o aumento horizontal em vários clientes e para controlar erros durante o processo de ingestão. Para utilizar esta ferramenta, os dados de origem devem ser particionados em ficheiros distintos no Azure Data Lake Storage (ADLS) para que os diferentes trabalhadores de migração possam recolher cada ficheiro e ingeri-los no Azure Cosmos DB. A ferramenta personalizada utiliza uma coleção separada, que armazena metadados sobre o progresso da migração para cada ficheiro de origem individual no ADLS e controla quaisquer erros associados aos mesmos.

A imagem seguinte descreve o processo de migração com esta ferramenta personalizada. A ferramenta está em execução num conjunto de máquinas virtuais e cada máquina virtual consulta a coleção de controlo no Azure Cosmos DB para adquirir uma concessão numa das partições de dados de origem. Assim que isto estiver concluído, a partição de dados de origem é lida pela ferramenta e ingerida no Azure Cosmos DB com a biblioteca do executor em massa. Em seguida, a coleção de controlo é atualizada para registar o progresso da ingestão de dados e quaisquer erros encontrados. Depois de processar uma partição de dados, a ferramenta tenta consultar a próxima partição de origem disponível. Continua a processar a partição de origem seguinte 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 controlo contém documentos, conforme mostrado no exemplo seguinte. Verá esses documentos um para cada partição nos dados de origem. Cada documento contém os metadados da partição de dados de origem, como a localização, o estado da migração e os erros (se existirem):

{ 
  "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 a migração de dados

Antes do início da migração de dados, existem alguns pré-requisitos a considerar:

Estimize o tamanho dos dados:

O tamanho dos dados de origem pode não ser exatamente mapeado para o 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 estimar-se o tamanho total dos dados na pós-migração do Azure Cosmos DB.

Por exemplo, se cada documento após a migração no Azure Cosmos DB rondar os 1 KB e se existirem cerca de 60 mil milhões de documentos no conjunto de dados de origem, significa que o tamanho estimado no Azure Cosmos DB será próximo de 60 TB.

Pré-criar contentores com RUs suficientes:

Embora o Azure Cosmos DB aumente horizontalmente o armazenamento automaticamente, não é aconselhável começar a partir do menor tamanho de contentor. Os contentores mais pequenos têm uma menor disponibilidade de débito, o que significa que a migração demoraria muito mais tempo a ser concluída. Em vez disso, é útil criar os contentores com o tamanho de dados final (conforme estimado no passo anterior) e garantir que a carga de trabalho de migração está a consumir totalmente o débito aprovisionado.

No passo anterior. uma vez que o tamanho dos dados foi estimado em cerca de 60 TB, é necessário um contentor de, pelo menos, 2,4 M RUs para acomodar todo o conjunto de dados.

Estimize a velocidade de migração:

Partindo do princípio de que a carga de trabalho de migração pode consumir todo o débito aprovisionado, o aprovisionado ao longo de todo forneceria uma estimativa da velocidade de migração. Continuando o exemplo anterior, são necessárias 5 RUs para escrever um documento de 1 KB na API do Azure Cosmos DB para 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 demorará 125 000 segundos ou cerca de 34 horas.

Caso pretenda que a migração seja concluída dentro de um dia, deve aumentar o débito aprovisionado para 5 milhões de RUs.

Desative a indexação:

Uma vez que 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 desativá-lo completamente durante a migração. Pode desativar a política de indexação do contentor ao alterar o indexingMode para nenhum, conforme mostrado abaixo:

  { 
        "indexingMode": "none" 
  }

Após a conclusão da migração, pode atualizar a indexação.

Processo de migração

Após a conclusão dos pré-requisitos, pode migrar dados com os seguintes passos:

  1. Primeiro, importe os dados de origem para 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 ficheiros com um tamanho de cerca de 200 MB.

  2. A biblioteca do executor em massa pode aumentar verticalmente para consumir 500 000 RUs numa única VM cliente. Uma vez que o débito disponível é de 5 milhões de RUs, 10 VMs do Ubuntu 16,04 (Standard_D32_v3) devem ser aprovisionadas na mesma região onde está localizada a base de dados do Azure Cosmos DB. Deve preparar estas VMs com a ferramenta de migração e o respetivo ficheiro de definições.

  3. Execute o passo de fila numa das máquinas virtuais cliente. Este passo cria a coleção de controlo, que analisa o contentor do ADLS e cria um documento de controlo de progresso para cada um dos ficheiros de partição do conjunto de dados de origem.

  4. Em seguida, execute o passo de importação em todas as VMs cliente. Cada um dos clientes pode assumir a propriedade de uma partição de origem e ingerir os respetivos dados no Azure Cosmos DB. Depois de concluída e o respetivo estado ser atualizado na coleção de controlo, os clientes podem consultar a próxima partição de origem disponível na coleção de controlo.

  5. Este processo continua até que todo o conjunto de partições de origem seja ingerido. Assim que todas as partições de origem forem processadas, a ferramenta deve ser novamente executada no modo de correção de erros na mesma coleção de controlo. Este passo é necessário para identificar as partições de origem que devem ser processadas novamente 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 o passo de importação nas partições falhadas para as voltar a processar.

Assim que a migração estiver concluída, pode validar que a contagem de documentos no Azure Cosmos DB é igual à contagem de documentos na base 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 para o nível exigido pelas operações da carga de trabalho.

Passos seguintes

  • Saiba mais ao experimentar as aplicações de exemplo que consomem a biblioteca do executor em massa em .NET e Java.
  • A biblioteca do executor em massa está integrada no conector spark do Azure Cosmos DB. Para saber mais, veja o artigo Conector spark do Azure Cosmos DB .
  • Contacte a equipa de produtos do Azure Cosmos DB ao abrir um pedido de suporte no tipo de problema "Aconselhamento Geral" e no subtipo de problema "Migrações grandes (TB+)" para obter ajuda adicional com migrações em grande escala.
  • Está a tentar planear a capacidade de uma migração para o Azure Cosmos DB? Pode utilizar informações sobre o cluster de bases de dados existentes para o planeamento de capacidade.