Introdução
Os arquivos da empresa varejista têm nomes e diretórios, mas as máquinas também precisam armazenar seu conteúdo em algum lugar. Como um arquivo grande pode ser distribuído entre nós de armazenamento? O que o HDFS copia quando mantém uma réplica? Um bloco quase vazio reserva no disco o espaço de um bloco inteiro?
Você já sabe organizar e preservar arquivos. Neste laboratório, olhará além de seus caminhos. Um bloco do HDFS é uma parte de um arquivo que o HDFS acompanha e armazena. O NameNode mantém metadados sobre arquivos e locais dos blocos; os DataNodes guardam os dados dos blocos. Uma réplica é outra cópia armazenada de um bloco, em vez de um novo registro de varejo ou outro arquivo visível ao usuário.
Você enviará dois arquivos preparados com um tamanho de bloco propositalmente pequeno e válido, preverá suas quantidades de blocos e inspecionará os locais reais. Este ambiente com um único DataNode usa fator de replicação 1. Ele fornece observações reais sem pretender demonstrar recuperação entre várias máquinas. Todos os dados e serviços são preparados de forma independente. Use o Terminal; não é necessário programar.
Relacione o tamanho do arquivo aos blocos
Nesta etapa, você enviará um arquivo com um tamanho de bloco conhecido e inspecionará seus metadados.
Um caminho de sistema de arquivos nomeia um arquivo lógico. O HDFS divide seu conteúdo em blocos para que partes diferentes possam ser armazenadas em DataNodes diferentes em um cluster maior. O tamanho configurado de um bloco é um tamanho máximo de dados para esse bloco, não uma garantia de que todos os blocos estejam cheios.
Comece no diretório do projeto:
cd /home/labex/project
O comando local wc -c conta bytes. Use-o no primeiro arquivo preparado:
wc -c /home/labex/project/data/products-a.txt
O resultado começa com 1572864: exatamente 1,5 MiB. Um MiB equivale a 1.048.576 bytes. Este arquivo repete um rótulo simples de produto para que o experimento de armazenamento não tenha regras de negócio complicadas.
Crie um diretório pessoal no HDFS:
hdfs dfs -mkdir -p /user/labex/block-study
Para esta demonstração, -Ddfs.blocksize=1048576 substitui a configuração de tamanho de bloco do cliente no envio seguinte. -D fornece uma propriedade de configuração para este comando; ele não edita os arquivos de configuração compartilhados. Um MiB atende ao limite mínimo de tamanho de bloco desta imagem e mantém a demonstração pequena:
hdfs dfs -Ddfs.blocksize=1048576 -put /home/labex/project/data/products-a.txt /user/labex/block-study/products-a.txt
Preveja a distribuição: 1,5 MiB com tamanho de bloco de 1 MiB exige um bloco cheio e um bloco pela metade, totalizando dois blocos.
A operação -stat do HDFS imprime metadados selecionados. Em seu formato entre aspas, %b significa comprimento do arquivo em bytes, %o significa tamanho de bloco e %r significa fator de replicação:
hdfs dfs -stat 'bytes=%b blocksize=%o replication=%r' /user/labex/block-study/products-a.txt
Valores esperados:
bytes=1572864 blocksize=1048576 replication=1
O comprimento do arquivo continua sendo 1,5 MiB. Fator de replicação 1 significa uma cópia armazenada por bloco, não um bloco para o arquivo inteiro. Salve os metadados reais:
hdfs dfs -stat 'bytes=%b blocksize=%o replication=%r' /user/labex/block-study/products-a.txt > /home/labex/project/output/file-a-metadata.txt
Se o arquivo já existir devido a um envio concluído, inspecione-o antes de repetir o envio; não exclua um arquivo apenas porque -put informa um destino existente.
Inspecione os locais e preveja uma mudança
Nesta etapa, você encontrará os blocos reais do primeiro arquivo e testará sua previsão com um arquivo maior.
O comando hdfs fsck pode inspecionar o estado de armazenamento de um arquivo. Na inspeção somente de leitura a seguir, -files inclui detalhes de arquivos, -blocks inclui informações de blocos e -locations inclui os DataNodes que guardam cada bloco. Nenhuma dessas opções repara ou exclui arquivos:
hdfs fsck /user/labex/block-study/products-a.txt -files -blocks -locations
Localize a linha de comprimento do arquivo, as entradas dos blocos e o campo Total blocks (validated) do resumo. Deverá haver dois blocos. Um contém 1.048.576 bytes e o outro 524.288 bytes. Identificadores dos blocos, endereços e horários variam. O resumo final de integridade do sistema de arquivos deverá ser HEALTHY.
Salve a inspeção:
hdfs fsck /user/labex/block-study/products-a.txt -files -blocks -locations > /home/labex/project/output/file-a-blocks.txt
Um resultado saudável significa que esta verificação encontrou os blocos e as réplicas necessários. Com uma réplica por bloco em uma máquina, isso não significa que o arquivo possa sobreviver à perda dessa máquina.
Agora inspecione o tamanho do segundo arquivo local:
wc -c /home/labex/project/data/products-b.txt
Seu comprimento é 2621440 bytes, ou 2,5 MiB. Antes de enviar, preveja a quantidade e os tamanhos de seus blocos usando o mesmo tamanho de bloco de 1 MiB. Apenas o comprimento do arquivo muda:
hdfs dfs -Ddfs.blocksize=1048576 -put /home/labex/project/data/products-b.txt /user/labex/block-study/products-b.txt
Inspecione o resultado:
hdfs fsck /user/labex/block-study/products-b.txt -files -blocks -locations
Você deverá encontrar três blocos: dois blocos cheios e um bloco de 524.288 bytes. Todos os locais se referem ao mesmo DataNode neste laboratório. Salve a observação:
hdfs fsck /user/labex/block-study/products-b.txt -files -blocks -locations > /home/labex/project/output/file-b-blocks.txt
Em um cluster maior, os locais dos blocos podem variar entre máquinas. O NameNode fornece metadados de localização aos clientes; ele não é um canal central pelo qual cada byte do conteúdo dos arquivos precisa passar.
Interprete espaço, réplicas e o caminho dos dados
Nesta etapa, você relacionará as observações dos blocos ao tamanho do arquivo e ao relatório real do nó de armazenamento.
Um bloco final pela metade não reserva um MiB inteiro de espaço para dados apenas porque o tamanho de bloco configurado é 1 MiB. Use -du sem -h para manter visíveis as contagens exatas em bytes:
hdfs dfs -du /user/labex/block-study
As duas primeiras colunas de cada arquivo deverão ser:
1572864 1572864 .../products-a.txt
2621440 2621440 .../products-b.txt
A primeira coluna é o comprimento lógico do arquivo; a segunda leva em conta a replicação. Aqui, elas são iguais porque a replicação é 1. Esses valores descrevem os dados de arquivos do HDFS, não cada byte de metadados do sistema de arquivos nem o uso total do disco da VM. Salve as linhas:
hdfs dfs -du /user/labex/block-study > /home/labex/project/output/block-report.txt
Confira o relatório real do nó de armazenamento com o comando administrativo somente de leitura apresentado no laboratório sobre o ambiente:
sudo -u hdfs /usr/local/bin/hdfs dfsadmin -report
Procure Live datanodes (1). Definir a replicação como 3 não criaria três máquinas; este laboratório mantém a replicação em 1, em vez de deixar blocos esperando por réplicas indisponíveis.
Relacione as observações ao caminho dos dados:
Gravação: o cliente pede ao NameNode para criar um arquivo e envia os dados dos blocos aos DataNodes.
Leitura: o cliente pede os locais ao NameNode e lê os dados dos blocos dos DataNodes.
Com várias réplicas em um cluster maior, um cliente pode usar uma cópia disponível, e um framework de processamento pode tentar executar o trabalho perto dos dados. Essa ideia é chamada de localidade dos dados. Uma cópia nomeada criada com -cp é um segundo arquivo lógico; réplicas são cópias de armazenamento dos blocos dentro de um arquivo lógico. Elas resolvem problemas diferentes.
Seu exercício de previsão mudou o tamanho do arquivo, não o fator de replicação. O arquivo A continua com dois blocos, o arquivo B tem três, e ambos têm uma réplica por bloco. A seguir, você aprenderá por que um arquivo pode estar presente e saudável, mas ainda assim não ser legível para um usuário específico: permissões de acesso.
Resumo
Você previu e observou como arquivos de 1,5 MiB e 2,5 MiB se dividem em dois e três blocos de 1 MiB. Inspecionou os locais reais dos blocos e distinguiu comprimento lógico do arquivo, armazenamento de réplicas e arquivos nomeados adicionais.
Também relacionou esses resultados aos metadados do NameNode e às transferências dos DataNodes. O ambiente de nó único ilustra essas responsabilidades, deixando a capacidade e a tolerância a falhas entre várias máquinas para uma exploração posterior.
