Introdução
Você consegue enviar um arquivo ao HDFS, mas para onde o terminal realmente o enviou? O arquivo diário de uma empresa varejista pode existir em um notebook, no servidor atual ou em um armazenamento compartilhado. Ler a cópia errada pode produzir um cálculo perfeitamente válido sobre os dados errados. Antes de gerenciar mais arquivos, você precisa reconhecer o armazenamento usado pelos seus comandos.
O Hadoop separa responsabilidades. O Hadoop Common fornece bibliotecas e utilitários compartilhados. O HDFS armazena arquivos. O MapReduce descreve e executa tarefas de processamento em lote. O YARN aloca recursos para aplicações, incluindo trabalhos MapReduce. Você usará esses nomes gradualmente; hoje inspecionará armazenamento e configuração, sem executar um cálculo nem instalar serviços.
Este laboratório tem três resultados: descobrir o sistema de arquivos padrão, demonstrar que um mesmo caminho escrito pode se referir a arquivos diferentes e identificar os serviços HDFS em execução. Você terminará com observações coletadas do seu próprio ambiente. Todos os dados de exemplo são preparados independentemente do laboratório anterior. Use o Terminal; não é necessário programar.
Descubra o destino configurado
Nesta etapa, você encontrará o sistema de arquivos padrão e lerá a opção configurada para a execução do MapReduce.
O terminal executa um comando cliente. Um cliente solicita que um serviço realize um trabalho; o serviço pode estar nesta máquina ou em outra. A configuração conecta o comando curto do cliente ao destino correto. Comece no seu espaço de trabalho local:
cd /home/labex/project
O comando hdfs getconf lê a configuração do Hadoop. Sua opção -confKey solicita uma configuração pelo nome. fs.defaultFS indica o sistema de arquivos padrão usado quando um caminho de sistema de arquivos do Hadoop não possui um esquema explícito:
hdfs getconf -confKey fs.defaultFS
Valor esperado:
hdfs://localhost:9000
Isso é uma URI, um endereço que inclui como acessar um recurso. Aqui, hdfs seleciona o HDFS, localhost é esta máquina e 9000 é a porta de conexão do serviço. Uma porta identifica um ponto de conexão de rede usado por um serviço. Você não precisa abrir essa porta por conta própria.
Salve o valor observado. Como no primeiro laboratório, > grava a saída do comando em um arquivo local, substituindo seu conteúdo anterior:
hdfs getconf -confKey fs.defaultFS > /home/labex/project/output/default-filesystem.txt
Os arquivos de configuração do Hadoop usam XML: uma propriedade possui um name e um value. Agora você só precisa ler uma propriedade. grep seleciona linhas de texto correspondentes, e -A 1 inclui a linha imediatamente após cada correspondência:
grep -A 1 '<name>mapreduce.framework.name</name>' /etc/labex-bigdata/hadoop/mapred-site.xml
As duas linhas relevantes são:
<name>mapreduce.framework.name</name>
<value>yarn</value>
yarn significa que as aplicações MapReduce estão configuradas para usar o YARN no gerenciamento de recursos. Essa configuração, sozinha, não prova que uma aplicação está em execução. O HDFS foi iniciado para este laboratório; os serviços de computação serão usados quando você aprender a submeter trabalhos.
Salve essas linhas de configuração como evidência, em vez de digitar o valor esperado por conta própria:
grep -A 1 '<name>mapreduce.framework.name</name>' /etc/labex-bigdata/hadoop/mapred-site.xml > /home/labex/project/output/execution-setting.txt
Para uma tabela temporária minúscula, seu sistema de arquivos local pode ser suficiente. Para arquivos históricos compartilhados por trabalhos Hadoop, o destino no HDFS importa. A escolha de uma ferramenta começa com uma necessidade, em vez de enviar automaticamente todos os arquivos ao Hadoop.
Resolva o mesmo caminho em dois sistemas de arquivos
Nesta etapa, você lerá dois arquivos preparados com o mesmo caminho escrito e demonstrará qual sistema de arquivos cada comando seleciona.
Apenas para esta comparação, a preparação colocou um arquivo diferente em /home/labex/project/data/location.txt em cada sistema de arquivos. Isso é possível porque o sistema de arquivos local e o HDFS têm árvores de diretórios separadas. O espaço de trabalho usual do curso no HDFS é /user/labex; o caminho igual de hoje facilita perceber a distinção.
Uma URI file:/// seleciona explicitamente o sistema de arquivos local. As três barras combinam o separador de esquema com um caminho absoluto. Antes de executar o próximo comando, preveja se ele lerá a versão local ou a compartilhada:
hdfs dfs -cat file:///home/labex/project/data/location.txt
Saída esperada:
Local store: draft product file
Embora você tenha usado o cliente Hadoop, a URI selecionou um arquivo local. Agora selecione explicitamente o HDFS com o endereço de serviço observado na etapa 1:
hdfs dfs -cat hdfs://localhost:9000/home/labex/project/data/location.txt
Saída esperada:
HDFS store: shared product file
Por fim, omita o esquema e o endereço do serviço. Preveja qual versão o padrão da etapa 1 escolherá:
hdfs dfs -cat /home/labex/project/data/location.txt
A versão compartilhada do HDFS aparece. Um caminho absoluto fixa a localização dentro de um sistema de arquivos; sozinho, ele não escolhe esse sistema. O comando comum do Linux cat /home/labex/project/data/location.txt ainda leria a versão local.
Colete os três resultados separadamente para comparar suas previsões com evidências:
hdfs dfs -cat file:///home/labex/project/data/location.txt > /home/labex/project/output/local-result.txt
hdfs dfs -cat hdfs://localhost:9000/home/labex/project/data/location.txt > /home/labex/project/output/hdfs-result.txt
hdfs dfs -cat /home/labex/project/data/location.txt > /home/labex/project/output/default-result.txt
Os resultados do HDFS e do caminho padrão devem ser iguais. Use diff, que não imprime nada quando os arquivos são iguais:
diff /home/labex/project/output/hdfs-result.txt /home/labex/project/output/default-result.txt
Este experimento explica por que um caminho isolado pode confundir durante o diagnóstico de problemas: confira tanto o caminho quanto o sistema de arquivos ao qual ele pertence.
Identifique os serviços de armazenamento
Nesta etapa, você relacionará as operações de arquivo às funções do NameNode e do DataNode e reunirá suas observações do ambiente.
O HDFS separa as informações de nome e localização de um arquivo dos dados desse arquivo. O NameNode gerencia a árvore de diretórios e sabe quais DataNodes guardam os blocos do arquivo. Os DataNodes armazenam esses blocos e fornecem o conteúdo dos arquivos. Pense no catálogo e nas estantes de uma biblioteca: o catálogo ajuda a localizar um livro; as estantes guardam suas páginas.
Cliente HDFS → NameNode: perguntar onde estão os dados do arquivo
Cliente HDFS ↔ DataNode: transferir os dados do arquivo
Um bloco é uma parte de um arquivo gerenciada pelo HDFS. Mais adiante, você inspecionará blocos e réplicas diretamente. Por enquanto, confira se os serviços dessas duas funções estão ativos. systemctl is-active solicita ao sistema operacional o estado de cada serviço nomeado; este comando apenas observa o estado:
systemctl is-active labex-hdfs-namenode labex-hdfs-datanode
Você deverá ver duas linhas active, uma para cada serviço. Salve essa observação:
systemctl is-active labex-hdfs-namenode labex-hdfs-datanode > /home/labex/project/output/storage-services.txt
O HDFS também informa sua visão dos nós de armazenamento. dfsadmin -report é um relatório administrativo somente de leitura. O comando a seguir usa a identidade de serviço hdfs preparada, por meio de sudo -u hdfs, exclusivamente para ler esse relatório; continue fazendo o trabalho normal com arquivos usando sua própria identidade labex:
sudo -u hdfs /usr/local/bin/hdfs dfsadmin -report
Procure Live datanodes (1) e um nó cujo Decommission Status seja Normal. Capacidade, espaço usado, identificadores de host e horários variam; esses valores não precisam coincidir com os da VM de outra pessoa. Um nó ativo está se comunicando com o NameNode, enquanto Normal significa que ele não está sendo retirado de serviço.
Salve o relatório:
sudo -u hdfs /usr/local/bin/hdfs dfsadmin -report > /home/labex/project/output/storage-report.txt
Este é o modo pseudodistribuído de nó único: processos de serviço separados do Hadoop são executados em uma máquina. No modo local, um programa pode trabalhar com arquivos locais sem serviços HDFS; em um cluster com várias máquinas, os serviços e o armazenamento são distribuídos entre hosts. Ver um DataNode aqui não demonstra a capacidade de sobreviver à falha de uma máquina inteira.
Quando você submeter um trabalho mais adiante, o ResourceManager do YARN alocará recursos e um NodeManager gerenciará o trabalho em cada máquina de execução. As observações de armazenamento de hoje não exigem um trabalho em execução.
Monte um pequeno relatório concatenando suas observações salvas. cat aceita vários caminhos locais de entrada em ordem; > salva seu conteúdo combinado:
cat /home/labex/project/output/default-filesystem.txt /home/labex/project/output/execution-setting.txt /home/labex/project/output/storage-services.txt /home/labex/project/output/storage-report.txt > /home/labex/project/output/environment-report.txt
Leia-o de volta:
cat /home/labex/project/output/environment-report.txt
Localize a URI do sistema de arquivos, a configuração yarn, os dois estados de serviço e a quantidade de nós ativos. Agora você tem evidências que relacionam seus comandos ao ambiente real. A seguir, você gerenciará o ciclo de vida de um arquivo no sistema de arquivos correto.
Resumo
Você inspecionou o sistema de arquivos e a opção de execução configurados e usou caminhos locais, explícitos do HDFS e padrão para demonstrar de onde vieram os dados. Relacionou esses resultados à função de metadados do NameNode e à função de armazenamento do DataNode e reconheceu os limites de um ambiente de aprendizagem em uma única máquina.
Sua próxima tarefa é gerenciar entradas de forma consciente: copiar, arquivar, exportar, medir e remover apenas os arquivos temporários pretendidos.
