Migrar clusters do Apache Hadoop no local para o Azure HDInsight – melhores práticas de arquitetura
Este artigo apresenta recomendações para a arquitetura dos sistemas do Azure HDInsight. Faz parte de uma série que fornece melhores práticas para ajudar na migração de sistemas Do Apache Hadoop no local para o Azure HDInsight.
Utilizar vários clusters otimizados para cargas de trabalho
Muitas implementações do Apache Hadoop no local consistem num único cluster grande que suporta muitas cargas de trabalho. Este cluster único pode ser complexo e pode exigir compromissos para os serviços individuais para que tudo funcione em conjunto. A migração de clusters do Hadoop no local para o Azure HDInsight requer uma alteração na abordagem.
Os clusters do Azure HDInsight foram concebidos para um tipo específico de utilização de computação. Uma vez que o armazenamento pode ser partilhado em vários clusters, é possível criar vários clusters de computação otimizados para cargas de trabalho para satisfazer as necessidades de diferentes tarefas. Cada tipo de cluster tem a configuração ideal para essa carga de trabalho específica. A tabela seguinte lista os tipos de cluster suportados no HDInsight e as cargas de trabalho correspondentes.
| Carga de trabalho | Tipo de Cluster do HDInsight |
|---|---|
| Processamento em lotes (ETL/ELT) | Hadoop, Spark |
| Armazenamento de dados | Hadoop, Spark, Interactive Query |
| IoT/Transmissão em Fluxo | Kafka, Spark |
| Processamento transacional noSQL | HBase |
| Consultas interativas e mais rápidas com colocação em cache na memória | Interactive Query |
| Ciência dos Dados | Spark |
A tabela seguinte mostra os diferentes métodos que podem ser utilizados para criar um cluster do HDInsight.
| Ferramenta | Baseado no browser | Linha de Comandos | API REST | SDK |
|---|---|---|---|---|
| Portal do Azure | X | |||
| Azure Data Factory | X | X | X | X |
| CLI do Azure (ver 1.0) | X | |||
| Azure PowerShell | X | |||
| cURL | X | X | ||
| SDK do .NET | X | |||
| Python SDK | X | |||
| SDK Java | X | |||
| Modelos do Azure Resource Manager | X |
Para obter mais informações, veja o artigo Tipos de cluster no HDInsight.
Utilizar clusters transitórios a pedido
Os clusters do HDInsight podem não ser utilizados por longos períodos de tempo. Para ajudar a poupar nos custos dos recursos, o HDInsight suporta clusters transitórios a pedido, que podem ser eliminados depois de a carga de trabalho ter sido concluída com êxito.
Quando elimina um cluster, a conta de armazenamento associada e os metadados externos não são removidos. Posteriormente, o cluster pode ser recriado com as mesmas contas de armazenamento e meta-lojas.
Azure Data Factory pode ser utilizado para agendar a criação de clusters do HDInsight a pedido. Para obter mais informações, veja o artigo Criar clusters do Apache Hadoop a pedido no HDInsight com Azure Data Factory.
Desassociar o armazenamento da computação
As implementações típicas do Hadoop no local utilizam o mesmo conjunto de máquinas para o armazenamento de dados e o processamento de dados. Uma vez que estão em colocação, a computação e o armazenamento têm de ser dimensionados em conjunto.
Nos clusters do HDInsight, o armazenamento não precisa de ser colocado com computação e pode estar no armazenamento do Azure, Azure Data Lake Storage ou ambos. A desacoplação do armazenamento da computação tem os seguintes benefícios:
- Partilha de dados entre clusters.
- Utilização de clusters transitórios, uma vez que os dados não dependem do cluster.
- Custo de armazenamento reduzido.
- Dimensionar o armazenamento e a 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 numa região do Azure para mitigar o custo de desempenho da separação da computação e do armazenamento. As redes de alta velocidade tornam eficiente que os nós de computação acedam aos dados dentro do armazenamento do Azure.
Utilizar arquivos de metadados externos
Existem dois metastores principais que funcionam com clusters do HDInsight: Apache Hive e Apache Oozie. O metastore do Hive é o repositório de esquema central que pode ser utilizado por motores de processamento de dados, incluindo Hadoop, Spark, LLAP, Presto e Apache Pig. O metastore Oozie armazena detalhes sobre o agendamento e o estado das tarefas do Hadoop em curso e concluídas.
O HDInsight utiliza metastores SQL do Azure Database for Hive e Oozie. Existem duas formas de configurar um metastore em clusters do HDInsight:
Metastore predefinido
- Sem custos adicionais.
- O metastore é eliminado quando o cluster é eliminado.
- O Metastore não pode ser partilhado entre clusters diferentes.
- Utiliza base SQL do Azure BD, que tem um limite de cinco DTU.
Metastore externo personalizado
- Especifique uma Base de Dados de SQL do Azure externa como o metastore.
- Os clusters podem ser criados e eliminados sem perder metadados, incluindo detalhes da tarefa Oozie do esquema do Hive.
- A base de dados do metastore único pode ser partilhada com diferentes tipos de clusters.
- O metastore pode ser aumentado verticalmente conforme necessário.
- Para obter mais informações, veja Utilizar arquivos de metadados externos no Azure HDInsight.
Melhores práticas para o Metastore do Hive
Algumas das melhores práticas do metastore do HIVe do HDInsight são as seguintes:
- Utilize um metastore externo personalizado para separar recursos de computação e metadados.
- Comece com uma instância de SQL do Azure de escalão S2, que fornece 50 DTU e 250 GB de armazenamento. Se vir um estrangulamento, pode aumentar verticalmente a base de dados.
- Não partilhe o metastore criado para uma versão de cluster do HDInsight com clusters de uma versão diferente. Diferentes versões do Hive utilizam esquemas diferentes. Por exemplo, um metastore não pode ser partilhado com clusters do Hive 1.2 e hive 2.1.
- Faça uma cópia de segurança do metastore personalizado periodicamente.
- Mantenha o metastore e o cluster do HDInsight na mesma região.
- Monitorize o metastore para obter desempenho e disponibilidade com SQL do Azure ferramentas de Monitorização da Base de Dados, como portal do Azure ou registos do Azure Monitor.
- Execute o
ANALYZE TABLEcomando conforme necessário para gerar estatísticas para tabelas e colunas. Por exemplo,ANALYZE TABLE [table_name] COMPUTE STATISTICS.
Melhores práticas para diferentes cargas de trabalho
- Considere utilizar o cluster LLAP para consultas interativas do Hive com o tempo de resposta LLAP melhorado é uma nova funcionalidade no Hive 2.0 que permite a colocação em cache na memória de consultas.
- Considere utilizar tarefas do Spark em vez de tarefas do Hive.
- Considere substituir consultas baseadas em impala por consultas LLAP.
- Considere substituir tarefas do MapReduce por tarefas do Spark.
- Considere substituir tarefas de lote do Spark de baixa latência com tarefas de Transmissão em Fluxo Estruturada do Spark.
- Considere utilizar Azure Data Factory (ADF) 2.0 para orquestração de dados.
- Considere o Ambari para a Gestão de Clusters.
- Altere o armazenamento de dados do HDFS no local para WASB, ADLS ou ADFS para processamento de scripts.
- Considere utilizar o RBAC do Ranger em tabelas e auditorias do Hive.
- Considere utilizar o CosmosDB em vez do MongoDB ou cassandra.
Passos seguintes
Leia o artigo seguinte nesta série: