Este conteúdo foi traduzido por máquina para sua conveniência e a Huawei Cloud não pode garantir que o conteúdo foi traduzido com precisão. Para exibir o conteúdo original, use o link no canto superior direito para mudar para a página em inglês.
Central de ajuda/ MapReduce Service/ Visão geral de serviço/ Componentes/ MapReduce/ Recursos de código aberto aprimorados do MapReduce
Atualizado em 2023-05-19 GMT+08:00

Recursos de código aberto aprimorados do MapReduce

Recurso aprimorado de código aberto de MapReduce: JobHistoryServer HA

JobHistoryServer (JHS) é o servidor usado para exibir informações históricas de tarefas do MapReduce. Atualmente, o JHS de código aberto suporta apenas serviços de instância única. O JHS HA pode resolver o problema de um aplicativo não acessar a API do MapReduce quando os SPOFs ocorrem no JHS, o que faz com que o aplicativo não seja executado. Isso melhora muito a alta disponibilidade do serviço MapReduce.

Figura 1 Transição de status da alternância ativa/em espera de JobHistoryServer HA

JobHistoryServer de alta disponibilidade

  • O ZooKeeper é usado para implementar a eleição ativa/em espera e a alternância.
  • O JHS usa o endereço IP flutuante para fornecer serviços externamente.
  • Os modos JHS da única instância e da implantação da HA são apoiados.
  • Apenas um nó inicia o processo de JHS em um ponto de tempo para impedir que várias operações de JHS processem o mesmo arquivo.
  • Você pode executar expansão, redução, migração de instâncias, atualização e verificação de integridade.

Recurso de código aberto aprimorado: melhorando o desempenho do MapReduce por otimizar o processo de mesclagem/classificação em cenários específicos

A figura abaixo mostra o fluxo de trabalho de uma tarefa do MapReduce.

Figura 2 Job de MapReduce
Figura 3 Fluxo de execução de jobs de MapReduce

O processo de Reduce é dividido em três etapas diferentes: copiar, classificar (na verdade, deveria ser chamado de mesclar) e reduzir. Na fase de copiar, o Reducer tenta buscar a saída do Maps do NodeManagers e armazená-la no Reducer na memória ou no disco. Fase de embaralhamento (classificar e mesclar), em seguida, começa. Todas as saídas de mapa obtidas estão sendo classificadas, e os segmentos de diferentes saídas de mapas são mesclados antes de serem enviados para o Reducer. Quando um job tem um grande número de mapas a serem processados, o processo de embaralhamento é demorado. Para tarefas específicas (por exemplo, tarefas de SQL como junção de hash e agregação de hash), a classificação não é obrigatória durante o processo de embaralhamento. No entanto, a classificação é necessária por padrão no processo de embaralhamento.

Esse recurso é aprimorado usando a API de MapReduce, que pode fechar automaticamente o processo de classificação para essas tarefas. Quando a classificação é desativada, a API mescla diretamente os dados de saída do Maps buscados e envia os dados para o Reducer. Isso economiza muito tempo e melhora significativamente a eficiência das tarefas de SQL.

Recurso de código aberto aprimorado: problema do arquivo pequeno de log resolvido após a otimização do MR History Server

Após a execução do job no Yarn, o NodeManager usa o LogAggregationService para coletar e enviar logs gerados ao HDFS e excluí-los do sistema de arquivos local. Depois que os logs são armazenados no HDFS, eles são gerenciados pelo MR HistoryServer. O LogAggregationService mesclará logs locais gerados por contêineres em um arquivo de log e o enviará para o HDFS, reduzindo o número de arquivos de log até certo ponto. No entanto, em um cluster de grande escala e ocupado, haverá arquivos de log excessivos no HDFS após a execução de longo prazo.

Por exemplo, se houver 20 nós, cerca de 18 milhões de arquivos de log são gerados no período de limpeza padrão (15 dias), que ocupam cerca de 18 GB da memória de um NameNode e diminuem a resposta do sistema HDFS.

Somente a leitura e a exclusão são necessárias para arquivos armazenados no HDFS. Portanto, o Hadoop Archives pode ser usado para arquivar periodicamente o diretório de arquivos de log coletados.

Arquivar logs

O módulo AggregatedLogArchiveService é adicionado ao MR HistoryServer para verificar periodicamente o número de arquivos no diretório de log. Quando o número de arquivos atinge o limite, o AggregatedLogArchiveService inicia uma tarefa de arquivamento para arquivar arquivos de log. Após o arquivamento, ele exclui os arquivos de log originais para reduzir os arquivos de log no HDFS.

Limpar logs arquivados

Hadoop Archives não suporta exclusão em arquivos arquivados. Portanto, todo o pacote de log de arquivamento deve ser excluído durante a limpeza de log. O tempo de geração de log mais recente é obtido modificando o módulo AggregatedLogDeletionService. Se todos os arquivos de log atenderem aos requisitos de limpeza, o pacote de log de arquivamento poderá ser excluído.

Navegar pelos logs arquivados

Hadoop Archives permite acesso baseado em URI ao conteúdo do arquivo no pacote de log do arquivo. Portanto, se o MR History Server detectar que os arquivos de log originais não existem durante a navegação de arquivos, ele redirecionará diretamente o URI para o pacote de log de arquivamento para acessar o arquivo de log arquivado.

  • Esta função invoca Hadoop Archives do HDFS para arquivamento de logs. Porque a execução de uma tarefa de arquivamento pelo Hadoop Archives é executar uma aplicação de MR. Portanto, depois que uma tarefa de arquivamento é executada, um registro de execução de MR é adicionado.
  • Esta função de arquivamento de logs é baseada na função de coleta de logs. Por conseguinte, esta função só é válida quando a função de recolha de registos está ativada.