Partilhar via

Migrar clusters Apache Hadoop locais para o Azure HDInsight - práticas recomendadas de arquitetura

Este artigo fornece recomendações para a arquitetura dos sistemas Azure HDInsight. Faz parte de uma série que fornece práticas recomendadas para ajudar na migração de sistemas Apache Hadoop locais para o Azure HDInsight.

Usar vários clusters otimizados para carga de trabalho

Muitas implantações locais do Apache Hadoop consistem em um único cluster grande que suporta muitas cargas de trabalho. Esse único cluster pode ser complexo e exigir compromissos com os serviços individuais para que tudo funcione em conjunto. A migração de clusters Hadoop locais para o Azure HDInsight requer uma mudança na abordagem.

Os clusters do Azure HDInsight são projetados para um tipo específico de uso de computação. Como o armazenamento pode ser compartilhado entre vários clusters, é possível criar vários clusters de computação otimizados para carga de trabalho para atender às necessidades de diferentes trabalhos. Cada tipo de cluster tem a configuração ideal para essa carga de trabalho específica. A tabela a seguir lista os tipos de cluster suportados no HDInsight e as cargas de trabalho correspondentes.

Carga de trabalho Tipo de cluster HDInsight
Processamento em lote (ETL / ELT) Hadoop, Faísca
Armazenamento de dados Hadoop, Spark, consulta interativa
IoT / Streaming Kafka, Spark
Processamento transacional NoSQL HBase
Consultas interativas e mais rápidas com cache na memória Consulta Interativa
Ciência dos Dados Spark

A tabela a seguir mostra os diferentes métodos que podem ser usados para criar um cluster HDInsight.

Ferramenta Baseado em navegador Linha de Comandos API REST SDK
portal do Azure X
Fábrica de Dados do Azure X X X X
CLI do Azure (versão 1.0) X
Azure PowerShell X
cURL X X
SDK de .NET X
Python SDK X
SDK Java X
Modelos do Azure Resource Manager X

Para obter mais informações, consulte o artigo Tipos de cluster no HDInsight.

Usar clusters a pedido transitórios

Os clusters HDInsight podem ficar sem uso por longos períodos de tempo. Para ajudar a economizar nos custos de recursos, o HDInsight oferece suporte a clusters transitórios sob demanda, que podem ser excluídos assim que a carga de trabalho for concluída com êxito.

Quando você exclui um cluster, a conta de armazenamento associada e os metadados externos não são removidos. O cluster pode ser recriado posteriormente usando as mesmas contas de armazenamento e meta-armazenamentos.

O Azure Data Factory pode ser usado para agendar a criação de clusters HDInsight sob demanda. Para obter mais informações, consulte o artigo Criar clusters Apache Hadoop sob demanda no HDInsight usando o Azure Data Factory.

Desacoplar o armazenamento da computação

As implantações locais típicas do Hadoop usam o mesmo conjunto de máquinas para armazenamento e processamento de dados. Como estão localizados no mesmo local, a computação e o armazenamento devem ser escalados juntos.

Nos clusters HDInsight, o armazenamento não precisa ser alocado junto com a computação e pode estar no Armazenamento do Azure, no Armazenamento do Azure Data Lake ou em ambos. A dissociação do armazenamento da computação tem os seguintes benefícios:

  • Partilha de dados entre clusters.
  • Uso de clusters transitórios, uma vez que os dados não dependem do cluster.
  • Custo de armazenamento reduzido.
  • Dimensionamento do armazenamento e da computação separadamente.
  • Replicação de dados entre regiões.

Os clusters de computação são criados perto dos recursos da conta de armazenamento em uma região do Azure para reduzir o custo de desempenho da separação entre computação e armazenamento. As redes de alta velocidade tornam eficiente para os nós de computação acessarem os dados dentro do armazenamento do Azure.

Utilizar arquivos de metadados externos

Existem dois metastores principais que funcionam com clusters HDInsight: Apache Hive e Apache Oozie. O metastore do Hive é o repositório de esquema central que pode ser usado por mecanismos de processamento de dados, incluindo Hadoop, Spark, LLAP, Presto, e Apache Pig. O metastore do Oozie armazena detalhes sobre o agendamento e o status de tarefas Hadoop em andamento e concluídas.

O HDInsight usa o Banco de Dados SQL do Azure para metastores Hive e Oozie. Há duas maneiras de configurar um metastore em clusters HDInsight:

  1. Metastore padrão

    • Sem custo adicional.
    • O metastore é excluído quando o cluster é excluído.
    • O Metastore não pode ser compartilhado entre clusters diferentes.
    • Usa o Banco de Dados SQL do Azure básico, que tem um limite de cinco DTU.

  2. Metastore externo personalizado

    • Especifique um Banco de Dados SQL do Azure externo como metastore.
    • Os clusters podem ser criados e excluídos sem perder metadados, incluindo o esquema do Hive e os detalhes dos trabalhos do Oozie.
    • Um único metastore db pode ser compartilhado com diferentes tipos de clusters.
    • O Metastore pode ser ampliado conforme necessário.
    • Para obter mais informações, consulte Usar repositórios de metadados externos no Azure HDInsight.

Práticas recomendadas para o Hive Metastore

Algumas práticas recomendadas do metastore do HDInsight Hive são as seguintes:

  • Use um metastore externo personalizado para separar recursos de computação e metadados.
  • Comece com uma instância SQL do Azure de camada S2, que fornece 50 DTU e 250 GB de armazenamento. Se vires um afunilamento, podes escalar o banco de dados.
  • Não compartilhe o metastore criado para uma versão de cluster HDInsight com clusters de uma versão diferente. Diferentes versões do Hive usam esquemas diferentes. Por exemplo, um metastore não pode ser compartilhado com clusters Hive 1.2 e Hive 2.1.
  • Faça backup do metastore personalizado periodicamente.
  • Mantenha o metastore e o cluster HDInsight na mesma região.
  • Monitore o metastore quanto ao desempenho e à disponibilidade usando as ferramentas de Monitoramento do Banco de Dados SQL do Azure, como o portal do Azure ou os logs do Azure Monitor.
  • Execute o ANALYZE TABLE comando conforme necessário para gerar estatísticas para tabelas e colunas. Por exemplo, ANALYZE TABLE [table_name] COMPUTE STATISTICS.

Práticas recomendadas para diferentes cargas de trabalho

  • Considere o uso do cluster LLAP para consultas interativas do Hive com tempo de resposta aprimorado O LLAP é um novo recurso do Hive 2.0 que permite o cache de consultas na memória.
  • Considere usar tarefas do Spark no lugar de tarefas do Hive.
  • Considere substituir consultas baseadas em Impala por consultas LLAP.
  • Considere substituir trabalhos do MapReduce por trabalhos do Spark.
  • Considere substituir trabalhos em lote do Spark de baixa latência usando trabalhos do Spark Structured Streaming.
  • Considere usar o Azure Data Factory (ADF) 2.0 para orquestração de dados.
  • Considere o Ambari para gerenciamento de cluster.
  • Altere o armazenamento de dados do HDFS local para WASB ou ADLS ou ADFS para processar scripts.
  • Considere o uso do Ranger RBAC em tabelas Hive e a realização de auditorias.
  • Considere usar o CosmosDB no lugar do MongoDB ou Cassandra.

Próximos passos

Leia o próximo artigo desta série: