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 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 menores, para validar modelagem de dados, desempenho de consulta, escolha de chave de partição, etc., você 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 interromperá a migração e você terá que iniciar 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 letra morta: em grandes conjuntos de dados, em alguns casos pode haver problemas com partes dos dados de origem. Além disso, pode haver problemas transitórios com o cliente ou a rede. Qualquer um desses casos não deve fazer com que toda a migração falhe. Embora a maioria das ferramentas de migração tenha recursos robustos de repetição que protegem contra problemas intermitentes, nem sempre é suficiente. Por exemplo, se menos de 0,01% dos documentos de dados de origem tiverem mais de 2 MB de tamanho, isso fará com que a gravação do documento falhe no Azure Cosmos DB. Idealmente, é útil para a ferramenta de migração persistir esses documentos "falhados" para outra fila de letra morta, 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 seção acima podem ser resolvidos usando uma ferramenta personalizada que pode ser facilmente dimensionada em várias instâncias e é resiliente 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 usa a biblioteca de executores em massa e suporta dimensionamento em vários clientes e para rastrear 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 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, o tamanho total dos dados no Azure Cosmos DB pós-migração pode ser estimado.

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.

Pré-crie contêineres com RUs suficientes:

Embora o Azure Cosmos DB dimensione o armazenamento automaticamente, não é aconselhável iniciar a partir do menor tamanho de contêiner. Contêineres menores têm menor disponibilidade de taxa de transferência, o que significa que a migração levaria muito mais tempo para ser concluída. Em vez disso, é útil criar os contêineres com o tamanho final dos dados (conforme estimado na etapa anterior) e certificar-se de que a carga de trabalho de migração está consumindo totalmente a taxa de transferência provisionada.

Na etapa anterior. uma vez que o tamanho dos dados foi estimado em cerca de 60 TB, é necessário um recipiente de pelo menos 2,4 M 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, 5 RUs são necessárias para escrever um documento de 1 KB na API do Azure Cosmos DB para conta NoSQL. 2,4 milhões de empresas ferroviárias permitiriam uma transferência de 480 000 documentos por segundo (ou 480 MB/s). Isso significa que a migração completa de 60 TB levará 125.000 segundos ou cerca de 34 horas.

Caso deseje que a migração seja concluída em um dia, você deve aumentar a taxa de transferência provisionada para 5 milhões de RUs.

Desative a indexação:

Como a migração deve ser concluída o mais rápido possível, é aconselhável minimizar o tempo e as RUs gastos 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 para alguns termos selecionados ou desativá-la completamente durante a migração. Você pode desativar a política de indexação do contêiner alterando o indexingMode para none como mostrado abaixo:

  { 
        "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 da 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 em uma das máquinas virtuais cliente. Esta etapa cria a coleção de rastreamento, que verifica o contêiner ADLS e cria um documento de controle de progresso para cada um dos arquivos 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. Depois que ela for concluída e seu status for atualizado na coleção de rastreamento, os clientes poderã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. Esta etapa é necessária 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, você deve executar novamente a etapa de importação nas partições com falha para regerá-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 para o 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 executores em massa está integrada ao conector Spark do Azure Cosmos DB, para saber mais, consulte o artigo Conector do Azure Cosmos DB Spark .
  • Entre em contato com a equipe de produto do Azure Cosmos DB abrindo um tíquete de suporte no tipo de problema "General Advisory" e no subtipo de problema "Large (TB+) migrations" para obter ajuda adicional 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.