E-MapReduce:Migrar clusters Hadoop para clusters DataLake

Informações básicas

O E-MapReduce (EMR) Next-Gen Console é a plataforma de big data open source nativa da nuvem de próxima geração do EMR. Ela oferece uma nova experiência de usuário, plataforma de desenvolvimento, modelo de recursos e cenários de análise. Para obter detalhes sobre seus recursos, consulte Anúncio: O EMR Next-Gen Console já está disponível.

O EMR on ECS, um dos principais modelos de recursos do EMR, inclui diversas atualizações funcionais. Em particular, o EMR Next-Gen Console introduz novos cenários de cluster — DataLake, Dataflow, OLAP e Custom — que melhoram significativamente a eficiência do gerenciamento de clusters e o desempenho do motor em comparação com os cenários de clusters legados (como Hadoop e Data Science). Os clusters DataLake são uma versão atualizada dos clusters de data lake legados baseados em Hadoop. Após a atualização para clusters DataLake, você obtém vários benefícios. Para uma comparação detalhada de recursos, consulte Clusters DataLake.

Preparações

Revisar a arquitetura do cluster legado

Revise sua arquitetura de big data atual, esclareça o cenário de aplicação do cluster legado e observe o seguinte:

• Escopo e versões dos serviços: Registre os serviços e suas respectivas versões em execução em cada cluster legado para avaliar a compatibilidade da atualização e os requisitos de atualização de recursos.

• Tipo de metadados: Confirme o tipo de metadados utilizado pelo cluster legado (DLF ou RDS autogerenciado) para planejar estratégias de integração e migração do sistema de gerenciamento de metadados na nova arquitetura.

• Arquitetura de armazenamento de dados: Analise a arquitetura de armazenamento de dados do cluster legado (HDFS local, OSS ou modo de bloco JindoFS) para orientar o design do caminho de migração de dados.

• Arquitetura de autenticação e autorização de usuários: Confirme se serviços como OpenLDAP, Ranger ou Kerberos estão em uso para que a nova arquitetura possa herdar perfeitamente os mecanismos de segurança existentes.

• Sistema de agendamento: Confirme seu sistema atual de desenvolvimento e agendamento para manter um agendamento de tarefas consistente e fluido durante a migração.

Caso tenha vários clusters legados para atualizar, migre-os um por vez para garantir a continuidade e a estabilidade dos negócios. Com base nas necessidades reais e prioridades do negócio, crie uma sequência e um plano de migração práticos para realizar uma transição suave dos clusters legados para os novos clusters.

Revisar detalhes do cluster legado

• Visualize informações de configuração da instância do cluster

  Ao criar um novo cluster na nova plataforma, reutilize as informações básicas da instância do cluster legado. Para mais detalhes, consulte Criar um novo cluster. Exceto pelas configurações de software e hardware — que exigem atenção especial — utilize configurações idênticas para os demais parâmetros tanto nos clusters legados quanto nos novos.

  Nas páginas Basic Information e Nodes do cluster legado EMR on ECS, revise as configurações do cluster e dos grupos de nós, com foco no seguinte:

  Tipo de configuração	Nome da configuração	Detalhes a revisar
  Configuração de software	Versão do cluster Versão do serviço Lista de componentes efetivamente utilizados Tipo de metadados do Hive	Lista de serviços atualmente em uso no cluster e suas versões correspondentes.
  Configuração de hardware	Zona onde o cluster reside Tipo de instância e método de faturamento para cada grupo de nós	A zona do cluster e as especificações de hardware para cada grupo de nós — por exemplo, CPU, memória, disco do sistema e disco de dados.

• (Opcional) Exportar configurações de componentes de serviço do cluster

  Durante a operação e manutenção rotineira, é comum personalizar configurações padrão de componentes de serviço ou adicionar configurações customizadas conforme necessidades específicas. Para migrar essas configurações entre clusters eficientemente, use o recurso de exportação de configurações do EMR para exportar em lote todas as definições do cluster legado. Em seguida, durante a inicialização do novo cluster, importe essas definições em lote para replicar rapidamente as configurações dos componentes de serviço. Alternativamente, após iniciar o novo cluster com sucesso, ajuste manualmente cada configuração de serviço na interface de gerenciamento de serviços.

  1. Exporte as configurações de serviço.

     Consulte Exportar e importar configurações de serviço para exportar arquivos de configuração dos componentes de serviço desejados com um único clique.

     Nota

     • Select Configuration Files: Selecione apenas os arquivos de configuração editados. Seleções múltiplas são permitidas.

     • Export Mode: O cluster Hadoop atual não oferece suporte à opção exporting only custom or modified configurations.

     • Export Format: Escolha o formato JSON para facilitar a importação no novo cluster.

     Os parâmetros do arquivo de configuração exportado estão descritos na tabela a seguir.

     Parâmetro	Descrição
     ApplicationName	Nome do serviço.
     ConfigFileName	Nome do arquivo de configuração.
     ConfigItemKey	Nome do item de configuração.
     ConfigItemValue	Valor específico definido para o item de configuração.

  2. Edite o arquivo de configuração.

     Revise cuidadosamente as informações de configuração exportadas, mantenha apenas os itens necessários aplicáveis ao novo ambiente e exclua as configurações desnecessárias.

     • Ao ajustar parâmetros de recursos relacionados ao YARN, alinhe-os rigorosamente às especificações reais de hardware do cluster. Garanta que os valores dos parâmetros importados sejam adequados para o novo cluster.

     • Se existirem configurações relacionadas ao JindoFS (por exemplo, Credential Provider), ajuste-as de acordo com as configurações do OSS/OSS-HDFS. Para mais detalhes, consulte Configurar Credential Provider do OSS/OSS-HDFS.

  3. Aplique o arquivo de configuração editado em (Opcional) Configuração personalizada de software como configurações predefinidas para o novo cluster.

• (Opcional) Revisar ações de bootstrap

  Durante a fase de Visualize informações de configuração da instância do cluster, verifique se o cluster legado possui scripts de bootstrap configurados. Caso existam ações de bootstrap, avalie cuidadosamente a função de cada script para determinar se ele deve ser reutilizado no novo cluster.

  Para scripts necessários no novo cluster, faça os seguintes ajustes para garantir a execução correta:

  • Atualize nomes e caminhos de pacotes JAR relacionados às versões de componentes open source. Para caminhos de arquivos nas plataformas legada e nova, consulte Caminhos de arquivo comuns.

  • Se o script baixar arquivos do OSS, atualize os comandos correspondentes do OSS. Para mais detalhes, consulte Scripts de execução de ação de bootstrap.

  Após modificar o script, faça upload dele para o OSS e insira o endereço atualizado do OSS durante a criação do novo cluster.

  Importante

  Antes de implantar o script de bootstrap em um cluster de produção, valide-o em um ambiente de testes.

• (Opcional) Revisar regras de Auto Scaling do cluster legado

  Se houver regras de Auto Scaling configuradas para o cluster legado, revise-as — com foco na contagem máxima de instâncias, contagem mínima de instâncias, desligamento gracioso, método de acionamento e regras de acionamento — e reconfigure o Auto Scaling após criar o novo cluster. Para mais detalhes, consulte Criar uma política personalizada de Auto Scaling.

  1. Acesse a página do Auto Scaling.

     1. Faça login no console do E-MapReduce.

     2. Clique em nome do cluster desejado.

     3. Clique em aba Auto Scaling.

  2. Revise as regras de Auto Scaling.

     Na aba Auto Scaling, clique em Configure Rule na coluna Actions do grupo de nós que possui regras de Auto Scaling configuradas. Concentre-se nos seguintes pontos:

     • Contagem máxima de instâncias

     • Contagem mínima de instâncias

     • Desligamento gracioso

     • Método de acionamento

     • Regras de acionamento (scale-out, scale-in)

  Nota

  Parâmetros como método de seleção de instância, tipo de faturamento, tipo de instância e desligamento gracioso são configurados no painel de propriedades do grupo de nós no novo cluster. Para mais detalhes, consulte Gerencie grupos de nós.

• (Opcional) Revisar métricas de carga do cluster legado

  Analise as métricas de carga de recursos do cluster para observar o uso diário de recursos no cluster legado e avaliar os requisitos de hardware para o novo cluster. Como alternativa, realize uma migração suave igualando inicialmente as especificações de hardware do cluster legado e ajustando posteriormente a configuração de hardware do novo cluster com base na utilização real de recursos.

  • Método 1: Visualize monitoramento do cluster

    Verifique as métricas de carga do cluster, com foco no uso do YARN e do HDFS. Para mais detalhes, consulte Visualize métricas de monitoramento de serviço.

  • Método 2: Visualize relatórios diários do EMR Doctor

    Os relatórios diários do EMR Doctor fornecem uma análise global de recursos de computação, recursos de agendamento do YARN e recursos de armazenamento do HDFS. É possível revisar o volume total de dados, a distribuição de dados quentes/frios e a distribuição de tarefas de computação. Para mais detalhes, consulte Visualize relatórios diários e análises do cluster.

    Nota

    O EMR Doctor deve estar instalado nos clusters legados. Para mais detalhes, consulte Ative o EMR Doctor (tipo de cluster Hadoop).

Defina o plano e o cronograma de migração

Com base na sua carga de trabalho atual de big data e na configuração de cada cluster legado, defina o alvo final da migração e esclareça os seguintes pontos-chave. Utilize essas informações para planejar adequadamente os recursos humanos e o cronograma.

• Versão do produto e escopo de serviços do novo cluster. Para compatibilidade de serviços, consulte Versões do produto e serviços opcionais.

• Opção de metadados do novo cluster (DLF ou RDS autogerenciado)

• Solução de armazenamento do novo cluster (OSS-HDFS ou OSS)

Etapa 1: Construir o cluster do novo ambiente

Crie um novo cluster

Para etapas detalhadas e descrições de parâmetros, consulte Criar um cluster. Preencha os parâmetros com base nos detalhes de configuração do cluster coletados durante a etapa de Visualize informações de configuração da instância do cluster. Preste atenção especial aos seguintes parâmetros.

• Versões do produto e serviços opcionais

  Com base na lista de serviços coletada durante a etapa de Visualize informações de configuração da instância do cluster, consulte as informações de compatibilidade para selecionar o escopo e as versões de serviços apropriados para o novo cluster.

  • Notas de compatibilidade de componentes

    À medida que os serviços da comunidade open source evoluem, alguns serviços em cenários DataLake utilizam versões superiores às do Hadoop. A tabela a seguir mostra os intervalos de retrocompatibilidade. Utilize as versões de software do seu cluster legado juntamente com esta tabela para determinar as versões de serviço do novo cluster.

    Serviço do cluster legado	Intervalo de retrocompatibilidade 1	Intervalo de retrocompatibilidade 2	Intervalo de retrocompatibilidade 3	Intervalo de retrocompatibilidade 4
    Spark	2.x	3.x	-	-
    Hive	2.x	3.x	-	-
    Tez	Totalmente compatível em todas as versões	-	-	-
    Delta Lake	0.6.x	0.8.0–1.1.0	-	-
    Iceberg	0,12.x	0,13.x	-	-
    Hudi	0.6.x	0.8.x	0.9.x	0.10.x
    Sqoop	Totalmente compatível em todas as versões	-	-	-
    Ranger	1.x	2.x	-	-
    OpenLDAP	Totalmente compatível em todas as versões	-	-	-

    Nota

    • Intervalo de retrocompatibilidade indica que, dentro desse intervalo, versões superiores são compatíveis com versões inferiores.

    • As informações de compatibilidade acima servem apenas como referência. Consulte a documentação oficial da comunidade open source para obter detalhes oficiais.

    • Devido a mudanças na atividade da comunidade open source e à evolução tecnológica, alguns serviços open source não são mais suportados na nova plataforma EMR.

      Por exemplo, Hue, Zeppelin e Oozie. Migre para o EMR Notebook ou EMR Workflow, ou implante os motores correspondentes manualmente no cluster.

  • Selecione uma versão adequada do produto

    Importante

    Se os requisitos de versão de software forem atendidos, escolha a versão mais recente do produto EMR para acessar recursos mais completos.

    Em cenários DataLake, o Alibaba Cloud EMR oferece duas séries: EMR-3.x e EMR-5.x. Cada série inclui várias versões de produtos com diferentes serviços integrados e versões distintas. Ao construir um novo cluster, selecione uma versão do produto com base no seu cenário de aplicação de data lake e nos requisitos de compatibilidade de serviços desejados. A tabela a seguir mostra o mapeamento entre as versões da plataforma legada e da nova plataforma.

    Versão do cluster legado	Versão correspondente do novo cluster
    EMR-3.35.0: YARN 2.8.5, HDFS 2.8.5, Hive 2.3.7, Spark 2.4.7	Série EMR-3.x
    EMR-5.6.0: YARN 3.2.1, HDFS 3.2.1, Hive 3.1.2, Spark 3.2.1	Série EMR-5.x

  • Notas sobre seleção de HDFS e OSS-HDFS

    Nas versões 5.12.1 e posteriores, bem como 3.46.1 e posteriores do EMR, é possível escolher HDFS ou OSS-HDFS como método de armazenamento do cluster nos serviços opcionais.

    Com base na solução de armazenamento definida em Defina o plano e o cronograma de migração, selecione o serviço correspondente ao configurar os serviços opcionais durante a criação do novo cluster.

    Método de armazenamento do cluster na nova plataforma	Seleção de serviço
    OSS	OSS-HDFS
    OSS-HDFS	OSS-HDFS

    Nota

    Ao selecionar OSS-HDFS no parâmetro Optional Services, configure o Root Storage Directory of Cluster selecionando um Bucket com OSS-HDFS ativado como caminho raiz de armazenamento do cluster.

• Selecione metadados

  A nova plataforma EMR suporta as seguintes opções de armazenamento de metadados. Escolha com base na solução de armazenamento de metadados definida em Defina o plano e o cronograma de migração. Se for necessária a migração de metadados, consulte Migração de metadados após criar o novo cluster.

  Método de armazenamento de metadados	Descrição
  Metadados unificados DLF (recomendado)	Os metadados são armazenados no Data Lake Formation (DLF). Se a plataforma legada já utiliza o DLF, configure o mesmo catálogo de dados DLF. O novo cluster conecta-se automaticamente aos mesmos metadados após a criação, eliminando a necessidade de migração.
  RDS autogerenciado	Utilize uma instância autogerenciada do Alibaba Cloud RDS como banco de metadados. Ao selecionar esta opção, configure os parâmetros existentes do RDS. Para mais detalhes, consulte Configurar RDS autogerenciado.
  MySQL integrado	Os metadados são armazenados em um banco de dados MySQL local no cluster. Importante Esta opção destina-se apenas a testes. Não a utilize em ambientes de produção.

• (Opcional) Configuração personalizada de software

  Se você exportou configurações de serviço do cluster legado ou planeja pré-configurar definições durante a criação do cluster, ative a configuração personalizada de software no fluxo de trabalho de criação do novo cluster e cole as configurações editadas na caixa de entrada. Para mais detalhes, consulte Configurar software personalizado.

• Configuração de hardware

  Durante a fase de Visualize informações de configuração da instância do cluster, compreenda totalmente as configurações de hardware para cada nó. Para diferentes tipos de nós — Master, Core e Task — selecione recursos de hardware apropriados com base nas necessidades do negócio.

  • Ao criar um novo cluster, utilize as famílias de instâncias ECS e tipos de disco em nuvem mais recentes para aproveitar os recursos de hardware mais novos.

  • Para adicionar mais grupos de nós com a mesma função, utilize o recurso de adição de grupos de nós após a criação do cluster.

  • Vincular rede pública: Ative esta opção por grupo de nós. Uma vez ativada, todos os nós do grupo recebem endereços IP públicos.

    Ative a vinculação de rede pública para o grupo de nós Master para fazer login no nó mestre pela rede pública ou utilizar os recursos de links de acesso e mapeamento de portas do EMR.

(Opcional) Crie um novo Gateway

Os Gateways são usados principalmente para enviar jobs aos clusters de computação e fornecer isolamento. Se você utilizava um cluster Gateway na plataforma legada, crie um Gateway na nova plataforma conforme descrito abaixo.

A nova plataforma oferece opções de implantação de Gateway mais flexíveis, permitindo implantar Gateways em instâncias ECS existentes com sincronização automática das configurações do cluster de computação. Para simplificar a implantação do Gateway, o EMR fornece uma ferramenta chamada EMR-CLI, que ajuda a configurar facilmente um Gateway em instâncias ECS existentes do Alibaba Cloud. Para mais detalhes, consulte Usar EMR-CLI para personalizar a implantação do Gateway.

Etapa 2: Migração e validação

Após construir o ambiente do novo cluster, migre metadados, dados e jobs do cluster legado.

Migração de metadados

Tanto as plataformas EMR legada quanto a nova suportam três métodos de gerenciamento de metadados: RDS autogerenciado, DLF e MySQL integrado. Para a nova plataforma, recomendamos fortemente o uso do serviço de metadados DLF. Com base nos métodos de gerenciamento de metadados utilizados nos clusters legados e novos, utilize as seguintes abordagens de migração.

Método de metadados da plataforma legada	Método de metadados da nova plataforma	Método de migração
DLF	DLF	Nenhuma migração de dados é necessária. Garanta que o novo cluster aponte para o mesmo catálogo de dados DLF do cluster legado.
Banco de metadados unificado	DLF	Para mais detalhes, consulte Anúncio de migração de metadados do EMR.
MySQL local	DLF	Para mais detalhes, consulte Migração de metadados.
RDS autogerenciado	DLF	Para mais detalhes, consulte Migração de metadados.

Migração de dados

Após criar o novo cluster, utilize os seguintes métodos de migração com base nas diferenças de armazenamento entre os clusters legados e novos para garantir uma migração de dados precisa e bem-sucedida.

Armazenamento do cluster legado	Armazenamento da nova plataforma	Método de migração
OSS	OSS	Nenhuma migração de dados é necessária.
OSS	OSS-HDFS	Utilize a ferramenta guia do usuário do JindoDistCp para a migração de dados.
JindoFS Block	OSS-HDFS
HDFS	OSS-HDFS

Validação da integridade dos dados

Nota

Se nenhuma migração de dados for necessária para o novo cluster, pule esta etapa de validação.

Após concluir a migração de dados, valide a integridade dos dados do HDFS e dos bancos/tabelas do Hive. Caso seja detectada inconsistência de dados, tome medidas imediatas — como reexecutar jobs afetados ou restaurar dados ausentes.

Escolha um método de validação com base nos seus requisitos específicos.

Requisito de validação	Método de validação
Validação de arquivos	Compare valores de checksum para garantir que os arquivos permaneçam inalterados e sem danos durante a migração.
Validação aproximada de dados	Avalie rapidamente a consistência geral dos dados verificando estatísticas no nível da tabela — por exemplo, contagem total de linhas (count), soma de colunas numéricas, valor médio (avg), mínimo (min) e máximo (max).
Validação detalhada de dados	Realize verificação linha por linha para garantir que todos os itens de dados correspondam exatamente ao cluster de source, proporcionando verificações mais profundas de integridade e precisão.

Migração de jobs

Para garantir que os jobs do cluster legado sejam executados corretamente no novo cluster, aplique as seguintes estratégias de migração com base no seu sistema de agendamento e ambiente:

• Se você utiliza o Data Studio legado do EMR, migre para o EMR Workflow. Para mais detalhes, consulte Anúncio: Migrar do Data Studio legado do EMR.

• Caso utilize outro ambiente de desenvolvimento (por exemplo, Alibaba Cloud DataWorks ou uma plataforma autoconstruída), siga o guia de migração fornecido por esse ambiente.

  Consulte atentamente a documentação específica de migração da sua plataforma e ajuste as configurações — como a troca de informações do cluster de computação — para garantir que os jobs sejam agendados e executados corretamente no novo cluster.

Etapa 3: Validação paralela em execução dupla

Para minimizar o impacto potencial nos negócios em produção durante a migração do cluster, realize uma validação em execução dupla entre os clusters legado e novo. Isso envolve replicar o tráfego de produção para o novo cluster e executar jobs simultaneamente para validar abrangentemente a consistência dos dados e a correção dos negócios.

Como os métodos de validação em execução dupla variam conforme seu ambiente de desenvolvimento, características do negócio e necessidades de processamento de dados, recomendamos fortemente projetar um plano de validação em execução dupla flexível, adaptado ao seu cenário e requisitos específicos.

Etapa 4: Desativar o cluster legado

Após validar com sucesso os dados e as operações de negócio, prossiga com a transição. Transfira gradualmente as cargas de trabalho de jobs do cluster legado para o novo cluster, aumentando incrementalmente o volume de processamento no novo cluster até que todos os negócios sejam executados de forma estável nele.

Uma vez que todos os negócios tenham sido totalmente migrados e o cluster legado esteja ocioso, desative-o com segurança seguindo o procedimento de Liberar cluster.