9/19/23, 8:29 PM pspd/lab1/relatorio.

md at main · linktocaio/pspd

linktocaio /
pspd

Code Issues Pull requests Actions Projects Wiki Security Ins

pspd / lab1 / relatorio.md

mibasFerraz Rename README.md to relatorio.md now

223 lines (160 loc) · 12.5 KB

Preview Code Blame Raw

Turma: 1

Integrantes:

Caio Martins Ferreira - 180074741

Jonathan Jorge Barbosa Oliveira - 180103580
Júlia Farias Sousa - 180103792
Lucas Lima Ferraz - 180105345

Introdução
Atualmente, o termo BigData ganhou destaque no cenário acadêmico devido à sua capacidade
de processar vastas e diversificadas quantidades de dados, criando um cenário favorável para
desenvolver aplicações que auxiliam na tomada de decisões.

Nessa perspectiva, o Apache Hadoop, inspirado em tecnologias do Google, emerge como uma
plataforma em sintonia com as demandas do BigData, sendo também de código aberto e de
fácil utilização. O propósito deste projeto é proporcionar ao aluno uma vivência prática com
esta plataforma, permitindo-lhe reconhecer seus pontos positivos e entender como o
desenvolvimento de aplicações neste contexto se contrasta com abordagens mais
convencionais.

Metodologia
Inicialmente, criamos três contêineres Docker, um para o mestre e dois para os escravos,
todos com o Hadoop 3.3.6 instalado. Os containers podem ser iniciados rodando o scrip
start-container.sh. O numero de slaves criados pode ser alterada no mesmo arquivo na
variavel N.

Verificamos a interface web do cluster Hadoop, que deve listar três nós ativos, acessível
aqui

https://github.com/linktocaio/pspd/blob/main/lab1/relatorio.md 1/7
9/19/23, 8:29 PM pspd/lab1/relatorio.md at main · linktocaio/pspd

Atividade 1 - Projeto de pesquisa Hadoop

Tarefa: O objetivo desse projeto é criar um contexto para experimentar a plataforma hadoop a
fim de identificar os benefícios inerentes e, ao mesmo tempo, perceber as diferenças na
construção de aplicações nesse ambiente, em relação aos esquemas tradicionais.

O projeto do Hadoop básico foi realizado no link do Github

Atividade 2 - Teste do framework Hadoop

Tarefa: Realizar cinco alterações no cluster Hadoop afetando o escalonador de processos

YARN, o sistema de arquivos HDFS e o funcionamento geral das aplicações.

Primeira Alteração: Aumento da Replicação, dfs.replication:

Modificamos o valor de dfs.replication de 1 para 2 no arquivo hdfs-site.xml. Levantamos o

cluster após a alteração e verificamos que o dobro de memória foi utilizados para que
fosse possivel as replicacoes de blocos acontecerem.

Modificamos o valor de dfs.replication de 1 para 3 no arquivo hdfs-site.xml. Levantamos o

cluster após a alteração e verificamos que o triplo de memória foi utilizados para que fosse
possivel as replicacoes de blocos acontecerem.

Foi observado que os arquivos podem abranger vários blocos e cada bloco será replicado
o número de vezes especificado em dfs.replication. O tamanho de tais blocos é
especificado no parâmetro dfs.block.size.Com apenas uma replicação suas gravações
serão mais rápidas, às custas do risco de perda de dados e desempenho de leitura. Suas
leituras podem ser lentas porque seus dados podem estar em um nó com problemas sem
nenhum outro bloco disponível, bem como falha no trabalho no caso de falha de apenas
um nó.

Segunda Alteração: Ajuste do Tamanho dos Blocos, dfs.block.size:

Blocos Maiores: Se você aumentar o tamanho dos blocos, o armazenamento necessário

para armazenar os dados será mais eficiente, pois haverá menos metadados associados a
cada bloco. No entanto, isso pode resultar em fragmentação se seus dados forem
menores que o tamanho do bloco, o que pode levar a uma distribuição de dados mais
desigual entre os nós do cluster. Além disso, pode ser necessário mais tempo para replicar
blocos grandes.

Blocos Menores: Reduzir o tamanho dos blocos pode levar a uma maior utilização do
armazenamento, pois haverá mais metadados associados a cada bloco. No entanto, isso
pode ser benéfico se você tiver muitos pequenos arquivos, pois reduzirá a fragmentação
havendo mais blocos para a distribuição. Isso pode melhorar a paralelização das tarefas.

Terceira Alteração: Configuração de Limites de Recursos

Para evitar sobrecarga do cluster e garantir que os recursos sejam compartilhados da melhor
forma confirguramos recursos de CPU e memória no arquivo mapred-site.xml .

https://github.com/linktocaio/pspd/blob/main/lab1/relatorio.md 2/7
9/19/23, 8:29 PM pspd/lab1/relatorio.md at main · linktocaio/pspd

Limitamos a quantidade máxima de memória que as tarefas map e reduce poderiam usar
utilizando a seguinte configuração:

<property>
<name>mapreduce.map.memory.mb</name>
<value>512</value>
</property>
<property>
<name>mapreduce.reduce.memory.mb</name>
<value>512</value>
</property>

E para limitár o número máximo de núcleos de CPU que cada tarefa poderia usar adicionamos
o seguinte trecho de código usando as propriedades mapreduce.map.cpu.vcores e
mapreduce.reduce.cpu.vcores :

<property>
<name>mapreduce.map.cpu.vcores</name>
<value>2</value>
</property>
<property>
<name>mapreduce.reduce.cpu.vcores</name>
<value>4</value>
</property>

Quarta Alteração: Alteração do Modo de Compressão

Alteramos o tipo de compressão padrão para o Hadoop, especificamente para os jobs

MapReduce. Decidimos mudar para o SnappyCodec , conhecido por sua rápida compressão e
descompressão.

No arquivo mapred-site.xml , realizamos a seguinte modificação:

<property>
<name>mapreduce.map.output.compress</name>
<value>true</value>
</property>

<property>
<name>mapreduce.map.output.compress.codec</name>
<value>org.apache.hadoop.io.compress.SnappyCodec</value>
</property>

<property>
<name>mapreduce.output.fileoutputformat.compress</name>
<value>true</value>
</property>

<property>
<name>mapreduce.output.fileoutputformat.compress.codec</name>

https://github.com/linktocaio/pspd/blob/main/lab1/relatorio.md 3/7
9/19/23, 8:29 PM pspd/lab1/relatorio.md at main · linktocaio/pspd
<value>org.apache.hadoop.io.compress.SnappyCodec</value>
</property>

Ao realizar essa mudança, os jobs MapReduce mostraram uma melhoria significativa na

velocidade de execução, visto que o SnappyCodec é mais eficiente em termos de velocidade
quando comparado a codecs como Gzip . Porém, o SnappyCodec gasta mais memória ao
realizar a compressão, então é necessário ponderar qual modo de compressão utilizar. Outro
ponto a levar em consideração é a necessidade de utilizar um decoder já que a saída acaba
ocorrendo com extensão .snappy e gera conflito ao ser traduzida.

Quinta Alteração: Ajuste de Parâmetros de Redução no MapReduce,

mapreduce.job.reduces

Alteramos o número de tarefas de redução especificando um valor maior ou menor para o

parâmetro mapreduce.job.reduces no arquivo mapred-site.xml. Aumentar o número de
tarefas de redução pode acelerar o processo de redução, pois mais tarefas estarão
processando simultaneamente. No entanto, isso pode aumentar a carga no cluster. Foi
utilizado os parametros de 1, 3 e 6. Houve diferencas na execucao de algumas operacoes.
Foi observado um aumento no tempo de execucao, estimamos que o ocorrido se dê pela
arquitetura pseudo distribuida proveniente na utilização do Docker.

Para 1 HDFS: Number of read operations=38 HDFS: Number of write operations=2 Total
time spent by all reduce tasks (ms)=51971 Shuffled Maps =11 CPU time spent
(ms)=206600

Para 2 HDFS: Number of read operations=48 HDFS: Number of write operations=6 Total
time spent by all reduce tasks (ms)=97396 Shuffled Maps =33 CPU time spent
(ms)=236970

Para 3 HDFS: Number of read operations=63 HDFS: Number of write operations=12 Total
time spent by all reduce tasks (ms)=178163 Shuffled Maps =66 CPU time spent
(ms)=251480

Atividade 3 - Teste do MapReduce no Hadoop

Tarefa: Realizar uma tarefa de Word Count usando o framework MapReduce no cluster
Hadoop e monitorar o uso de recursos.

Foram desenvolvidos duas funções python, um mapper e um reducer, estão disponiveis na

pasta lab1/config. Os inputs tambem podem ser encontrados no mesmo caminho, juntamente
com um script python para aumentar o numero de arquivos de entrada se desejado.

Para testes podemos seguir o tutorial abaixo:

cd pspd/lab1
sudo docker network create --driver=bridge hadoop

https://github.com/linktocaio/pspd/blob/main/lab1/relatorio.md 4/7
9/19/23, 8:29 PM pspd/lab1/relatorio.md at main · linktocaio/pspd
sudo docker build -t hadoop .
./start-container.sh

Assim subimos os containers docker, é esperado que voce esteja interagindo com o hadoop-
master a partir desta etapa.

./start-hadoop.sh
./run-wordcount.sh

Verificamos a interface web do cluster Hadoop, que deve listar três nós ativos, acessível (aqui)
[localhost:8088/]. Apos o termino da execução é esperado que a contagem de palavras seja
mostrada no terminal.

Atividade 4 - Teste de tolerância a faltas e escalabilidade da

aplicação

Antes da execucao dos wordCounter:

hadoop-master: SecondaryNameNode ResourceManager NameNode

hadoop-slave 1 2 e 3: DataNode NodeManager

Durante execução do wordCounter:

hadoop-master: SecondaryNameNode ResourceManager NameNode RunJar

hadoop-slave 1: NodeManager DataNode YarnChild YarnChild

hadoop-slave 2: NodeManager DataNode YarnChild YarnChild YarnChild YarnChild

YarnChild YarnChild YarnChild YarnChild

hadoop-slave 3: MRAppMaster NodeManager DataNode YarnChild YarnChild

Removendo um slave com processo MRAppMaster

WARN ipc.Client: Address change detected. Old: hadoop-

slave3/172.21.0.5:33361 New: hadoop-slave3:33361
2023-09-19 22:45:52,382 INFO ipc.Client: Retrying connect to server:
hadoop-slave3:33361. Already tried 0 time(s); maxRetries=3

https://github.com/linktocaio/pspd/blob/main/lab1/relatorio.md 5/7
9/19/23, 8:29 PM pspd/lab1/relatorio.md at main · linktocaio/pspd

Quando um nó slave com o processo MRAppMaster em execução é removido do cluster por

meio de uma parada forçada do contêiner Docker, isso pode causar interrupções graves no
processo de MapReduce. O registro de mensagens de aviso e erro indica que o sistema está
tentando se reconectar ao nó removido. No entanto, essa reconexão não é possível porque o
nó não está mais disponível. Isso pode levar a perda de tarefas em andamento, o que pode
resultar em uma interrupção no processamento. Tentativas repetidas de reconexão que
consomem recursos do cluster sem sucesso. Falha na recuperação das tarefas em execução
no nó removido.

Foi verificado que para solucionar esse problema, é aconselhável utilizar uma solução de
orquestração, como o Apache ZooKeeper. O ZooKeeper pode ajudar a gerenciar de forma mais
eficaz a disponibilidade dos nós e a recuperação de tarefas em caso de falha.

Removendo um slave sem o processo MRAppMaster

INFO ipc.Client: Retrying connect to server: 0.0.0.0/0.0.0.0:10020.

Already tried 9 time(s); retry policy is
RetryUpToMaximumCountWithFixedSleep(maxRetries=10, sleepTime=1000
MILLISECONDS)
ERROR streaming.StreamJob: Error Launching job :
java.net.ConnectException: Your endpoint configuration is wrong; For more
details see: http://wiki.apache.org/hadoop/UnsetHostnameOrPort
Streaming Command Failed!

Quando um nó slave comum é removido do cluster por meio de uma parada forçada do
contêiner Docker, o impacto no processo de MapReduce é menos severo em comparação com
o cenário anterior. No entanto, ainda há consequências, como indicado pelo registro de
mensagens de informação e erro. O sistema tenta se reconectar ao nó removido para concluir
tarefas de MapReduce em andamento. As tentativas de reconexão podem resultar em atrasos
no processamento de tarefas devido à busca do nó ausente. É importante observar que, neste
cenário, a conclusão das tarefas de MapReduce ainda é possível.

Conclusão Geral
Ao longo deste projeto, pudemos mergulhar profundamente no mundo do BigData, com ênfase
no funcionamento e configuração do Apache Hadoop. O termo BigData, amplamente debatido
no mundo acadêmico, revelou-se uma espinha dorsal fundamental para o desenvolvimento de
aplicações que buscam processar volumes significativos e variados de dados.

Com a configuração e ajustes em nossa instância Hadoop, identificamos os prós e contras de

certas modificações, desde a replicação de blocos até as alterações no sistema de
compressão. Estas experiências práticas proporcionaram uma compreensão tangível dos
princípios teóricos estudados.

Ficou evidente a robustez e a flexibilidade do Hadoop em lidar com BigData, assim como os
desafios inerentes ao ajuste de seu desempenho. Além disso, experimentamos a importância
da tolerância a falhas e escalabilidade em um ambiente real, percebendo as implicações de
remover nós ativos do cluster.

https://github.com/linktocaio/pspd/blob/main/lab1/relatorio.md 6/7
9/19/23, 8:29 PM pspd/lab1/relatorio.md at main · linktocaio/pspd

Em suma, este projeto não apenas reforçou a relevância do Hadoop como uma ferramenta de
BigData, mas também destacou a necessidade de um entendimento profundo e prático para
otimizar seu desempenho em cenários variados. Aprendemos que a prática, combinada com o
conhecimento teórico, é crucial para dominar as nuances do mundo do BigData. Estamos
gratos por essa experiência valiosa e ansiosos para aplicar essas lições em futuros desafios
relacionados ao processamento de dados.

https://github.com/linktocaio/pspd/blob/main/lab1/relatorio.md 7/7