Introdução
O lote da empresa varejista foi concluído com sucesso ontem, mas o comando de hoje informa um erro. Repeti-lo sem ler a mensagem pode ocultar a causa real ou incentivar um atalho destrutivo. Uma entrada ausente, um endereço errado de serviço e uma tarefa de processamento com falha exigem respostas diferentes.
Você seguirá uma pequena sequência de diagnóstico: identificar o sistema de arquivos e a conexão, conferir a existência e a legibilidade da entrada, conferir o caminho de saída e inspecionar o estado e os logs de uma aplicação aceita. Um erro do lado do cliente pode ocorrer antes de uma aplicação ser submetida. Uma aplicação submetida tem uma identidade no YARN cujos diagnósticos fornecem mais evidências.
Este laboratório fornece várias falhas de propósito, incluindo uma aplicação de treinamento pré-compilada que rejeita um registro de entrada marcado. São exemplos controlados de aprendizagem, não falhas aleatórias de infraestrutura. Você os preservará como evidência e concluirá uma execução correta de WordCount usando outros caminhos de entrada e saída. Não é necessário programar em Java, reinstalar serviços, formatar nem fazer exclusões amplas. Todos os dados de exemplo são independentes; use o Terminal.
Diagnostique erros de conexão e entrada
Nesta etapa, você distinguirá um endereço errado de serviço de um arquivo ausente lendo erros reais do cliente.
Comece no espaço de trabalho local:
cd /home/labex/project
Primeiro, relembre o sistema de arquivos configurado:
hdfs getconf -confKey fs.defaultFS
Ele deverá ser hdfs://localhost:9000. Agora peça de propósito ao cliente que se conecte à porta 1, onde nenhum NameNode está escutando. As propriedades -D abaixo limitam as novas tentativas de conexão e definem um tempo limite de conexão de 2.000 milissegundos para esta chamada, mantendo o erro intencional limitado. Elas não editam a configuração compartilhada.
O redirecionamento > file 2>&1 salva a saída comum em um arquivo local e envia a saída de erro ao mesmo destino. Espera-se que o próximo comando falhe.
hdfs dfs -Dipc.client.connect.max.retries=0 -Dipc.client.connect.timeout=2000 -ls hdfs://localhost:1/user/labex > /home/labex/project/output/connection-error.log 2>&1
Leia o erro coletado:
cat /home/labex/project/output/connection-error.log
Procure uma falha ou recusa de conexão e o endereço errado. Isso acontece antes de uma listagem do sistema de arquivos poder ter sucesso. Não formate o HDFS nem reinstale serviços; o comando usou o ponto de conexão errado. Volte ao ponto de conexão configurado usando o caminho padrão:
hdfs dfs -ls /user/labex/job-diagnostics/data
Você deverá ver clean.txt e rejected.txt. A conexão funciona. Um problema diferente é solicitar a esse sistema de arquivos saudável um arquivo inexistente. Espera-se que o próximo comando falhe.
hdfs dfs -ls /user/labex/job-diagnostics/data/missing.txt > /home/labex/project/output/missing-input.log 2>&1
Inspecione a mensagem:
cat /home/labex/project/output/missing-input.log
Ela deverá informar que o caminho nomeado não existe. Confira a entrada pretendida com a operação de leitura conhecida:
hdfs dfs -cat /user/labex/job-diagnostics/data/clean.txt
As duas linhas são notebook pen e notebook folder. Um caminho de entrada corrigido resolve um problema de arquivo ausente; mudar a configuração do servidor não resolveria. Mantenha os logs de erro como evidência.
Reconheça um caminho de saída existente
Nesta etapa, você observará por que um trabalho recusa um diretório de saída que já existe e escolherá preservar em vez de fazer uma exclusão ampla.
A preparação criou um diretório de resultado vazio existing para representar um local de saída já reservado. Inspecione a entrada desse diretório:
hdfs dfs -ls -d /user/labex/job-diagnostics/results/existing
O formato de saída do exemplo MapReduce espera criar um novo diretório de saída. Um diretório existente pode provocar uma rejeição do lado do cliente antes de uma aplicação de processamento ser aceita. Espera-se que o próximo comando falhe.
hadoop jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.5.0.jar wordcount /user/labex/job-diagnostics/data/clean.txt /user/labex/job-diagnostics/results/existing > /home/labex/project/output/existing-output.log 2>&1
Leia a mensagem coletada:
cat /home/labex/project/output/existing-output.log
Procure uma mensagem de diretório de saída já existente ou FileAlreadyExistsException. Isso é um conflito de caminho, não uma evidência de que o algoritmo de contagem de produtos esteja errado.
Liste as aplicações aceitas pelo YARN:
yarn application -list -appStates ALL
Esses erros do cliente não devem produzir uma aplicação de processamento concluída. Um cliente pode contatar serviços do cluster ou obter um identificador durante a preparação da submissão; uma aplicação aceita e seu estado são evidências separadas.
Você preservará o diretório reservado e usará um novo caminho de saída na execução bem-sucedida. Remover todo o diretório results ou excluir a entrada bruta seria uma mudança muito mais ampla do que o problema exige.
Inspecione uma aplicação real com falha
Nesta etapa, você submeterá uma aplicação de treinamento controlada e usará sua identidade e seus logs reais do YARN para explicar a falha.
O controlled-failure.jar preparado aceita um caminho de entrada e um novo caminho de saída. Seu mapper rejeita deliberadamente o marcador BAD_RECORD. Você não precisa inspecionar nem editar código Java; o objetivo é distinguir uma falha de tarefa de uma aplicação aceita dos erros anteriores do cliente.
Primeiro, leia a entrada marcada:
hdfs dfs -cat /user/labex/job-diagnostics/data/rejected.txt
Ela contém uma linha normal de produtos seguida por BAD_RECORD. O trabalho de treinamento usa uma tentativa de map para que a mesma falha intencional não seja repetida várias vezes. Espera-se que o próximo comando falhe.
hadoop jar /home/labex/project/tools/controlled-failure.jar /user/labex/job-diagnostics/data/rejected.txt /user/labex/job-diagnostics/results/failed-example > /home/labex/project/output/failed-job.log 2>&1
Espere o prompt e leia o final do log:
tail -n 25 /home/labex/project/output/failed-job.log
Diferentemente dos casos anteriores, esta execução deverá ter uma aplicação YARN submetida e evidências de falha de tarefa. Colete seu ID real usando o mesmo padrão de listagem de aplicações do laboratório anterior:
yarn application -list -appStates ALL | grep -o 'application_[0-9]*_[0-9]*' > /home/labex/project/output/failed-application-id.txt
Consulte e salve seu relatório:
yarn application -status "$(cat /home/labex/project/output/failed-application-id.txt)" > /home/labex/project/output/failed-application-status.txt
Leia o relatório:
cat /home/labex/project/output/failed-application-status.txt
Encontre a identidade da aplicação, o status final e os diagnósticos. O status final deverá ser FAILED; o relatório é uma evidência do YARN, não um rótulo de falha escrito manualmente. Leia também os logs agregados reais:
yarn logs -applicationId "$(cat /home/labex/project/output/failed-application-id.txt)" > /home/labex/project/output/failed-application.log
Use grep para encontrar o diagnóstico de treinamento conhecido dentro deles:
grep 'Training input rejected' /home/labex/project/output/failed-application.log
A mensagem aponta para o registro marcado. Você passou de um resultado genérico de comando diferente de zero para uma explicação específica sustentada pelos logs da aplicação e da tarefa. Preserve essa evidência em vez de tratar toda falha como motivo para reiniciar o cluster.
Corrija a seleção do lote e conclua uma execução
Nesta etapa, você usará a entrada limpa e um novo diretório de saída e guardará um diagnóstico curto baseado em evidências.
A entrada pretendida para o relatório é clean.txt; o arquivo rejeitado era um dado de treinamento. Mantenha ambos os originais. Submeta o conhecido exemplo WordCount usando apenas o arquivo limpo e um novo diretório de resultado:
hadoop jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.5.0.jar wordcount /user/labex/job-diagnostics/data/clean.txt /user/labex/job-diagnostics/results/successful-run > /home/labex/project/output/successful-job.log 2>&1
Este comando deverá terminar com sucesso. A entrada tem duas ocorrências de notebook, uma de pen e uma de folder. Leia o resultado:
hdfs dfs -cat '/user/labex/job-diagnostics/results/successful-run/part-*' | sort
Contagens esperadas:
folder 1
notebook 2
pen 1
O log do driver bem-sucedido inclui seu ID de aplicação. sort -u ordena e remove linhas repetidas com IDs idênticos, deixando o único ID desta chamada:
grep -o 'application_[0-9]*_[0-9]*' /home/labex/project/output/successful-job.log | sort -u > /home/labex/project/output/successful-application-id.txt
Confirme o estado real da aplicação bem-sucedida:
yarn application -status "$(cat /home/labex/project/output/successful-application-id.txt)"
O status final deverá ser SUCCEEDED. Reúna as evidências anteriores em um registro local de diagnóstico:
cat /home/labex/project/output/connection-error.log /home/labex/project/output/missing-input.log /home/labex/project/output/existing-output.log /home/labex/project/output/failed-application-status.txt > /home/labex/project/output/diagnosis.md
Acrescente a escolha do reparo. printf imprime o texto e \n cria quebras de linha; >> acrescenta em vez de substituir as evidências coletadas:
printf '\nRepair: select /user/labex/job-diagnostics/data/clean.txt and use the new /user/labex/job-diagnostics/results/successful-run output. Preserve original inputs and the existing result directory.\n' >> /home/labex/project/output/diagnosis.md
Este registro relaciona erro, observação e ação. Para um serviço indisponível ou uma falha da plataforma fora do seu acesso, registre o ponto de conexão e a mensagem e informe o problema, em vez de reformatar o armazenamento. Para os problemas ensinados aqui, uma escolha específica de caminho ou entrada foi suficiente.
Resumo
Você distinguiu erros de conexão, entradas ausentes e caminhos de saída existentes de uma falha de tarefa em uma aplicação YARN aceita. Usou o estado real da aplicação e os logs de tarefa para explicar uma rejeição controlada e concluiu um lote correto com uma entrada limpa e um novo caminho de saída.
O desafio final do curso combina esses hábitos com organização de entradas e permissões. Ele pede que você conclua um novo lote de forma independente usando métodos que já praticou.
