Fundamentos de Big Data

José Luiz dos Anjos Rosa

INTRODUÇÃO AO HADOOP®

A quantidade de dados armazenados no mundo está estimada em 16

Zettabytes (16 bilhões de Gigabytes - GB). Mas a projeção para 2020 é de 44
ZB. Somente o Facebook armazena 7 Petabytes (PB) por mês , sendo que 1 PB
equivale a 1000 TB. São textos, sons, imagens, vídeos, enfim, tem-se o que se
chama Big Data, que é definida em função de 3 V’s:

Para que se possa processar grandes massas de dados, opta-se pelo pa-
ralelismo de dados e controle (PACHECO, 1997), o que evita redimensionamento
da capacidade de processamento (aumento de memória, CPU’s mais rápidas, e
assim por diante) a cada incremento na quantidade de dados a processar. Um
crescimento exponencial da quantidade a ser processada, levaria a uma cons-
tante readequação do sistema de computação. Visando processar dados de for-
ma paralela, pode-se contar com um agrupamento de computadores, ou clus-
ter, que deve oferecer comunicação de dados entre processos paralelos, balan-
ceamento da carga e tolerância a falhas, e com Hadoop®, um framework para
processamento em ambiente de Big Data. Desenvolvido pelo Yahoo!, atual-
mente é um projeto de código aberto (open source) de alto nível mantido pela
The Apache™ Software Foundation.

Um cluster Hadoop é uma plataforma de software que processa - de for-

ma eficiente – um grande volume de informação, utilizando um grupo (cluster)
- Grande Volume de dados (GB; TB; PB; ZB);
- Variados formatos (texto, imagem, vídeo etc.);
- Velocidade exponencide cral escimento.

Os computadores ("nós" do cluster) trabalham em paralelo com os dados

sendo distribuídos pelos nós de forma replicada. Assim, caso ocorra uma falha
em um nó, o dado replicado que está em outro nó é copiado para o nó onde a
falha ocorreu.
Ao passo que bancos de dados lidam bem com dados estruturados (orga-
nizados em entidades que possuem um formato definido, tais como tabelas de
dados ou documentos XML), Hadoop lida bem com dados semiestruturados
(como planilhas eletrônicas, que são organizadas em células, as quais podem
conter qualquer tipo de dado) e dados não estruturados (que não possuem es-
trutura interna alguma, tais como textos e imagens).

Processamento paralelo e distribuído de dados não é novidade. Em PA-

CHECO (1997) são apresentados os principais conceitos que permitem ao leitor
aprender as técnicas de programação paralela utilizando MPI (Message Passing
Interface), uma biblioteca de extensões para C, C++ e Fortran, desenvolvida
1992 por universidades e empresas dos Estados Unidos e da Europa, e publica-
do em 1994.

No MPI, os dados são acessados a partir de uma área de armazenamen-

to na rede. O acesso a grandes quantidades de dados é um gargalo, pois re-
quer grande largura de banda (de rede), o que faz com que vários nós fiquem
ociosos (balanceamento de carga ruim). É bem mais rápido do que Hadoop,
mas o esforço de programação é bem maior, além do que, não possui mecanis-
mo de tolerância a falhas, a não ser que o programador cuide desse detalhe.
Apenas um programa é criado, sendo executado por todos os nós do cluster de
forma paralela. Cabe ao programador elaborar o código para cada nó do clus-
ter, ou, um código para o nó mestre (pelo qual o processamento é iniciado) e
outro código para os demais nós (escravos), bem como a lógica de distribuição
dos dados pelos nós do cluster. O nó mestre fica responsável por decompor o
problema em tarefas, distribuir o código a processar para todos os nós escra-
vos, e enviar, para cada nó escravo, os dados a serem processados. Ao térmi-
no dos trabalhos, os escravos enviam os resultados de seus processamentos
ao mestre para que este possa gerar um resultado consolidado.
 Já Haddop trabalha com o conceito de Localização de dados (data loca-
lity). Os dados são organizados em um conjunto de pares <chave,valor>, e
são distribuídos pelos nós por meio do mecanismo denominado MapReduce.
Desta forma, o acesso a grandes quantidades de dados torna-se mais rápido.
Por ser um framework, diminui, e muito, o esforço de programação, cujas tare-
fas repetitivas de controle e distribuição dos dados pelos nós e de tolerância a
falhas, ficam a cargo das classes componentes do framework, restando, ao
programador, cuidar da lógica do negócio.

O projeto Hadoop inclui, dentre outros, os seguintes módulos:

- Hadoop Common
Utilitários comuns que suportam outros módulos do Hadoop. É um con-
junto de componentes e interfaces para sistemas de arquivos distribuídos
e E/S geral (serialização, Java RPC, estruturas de dados persistentes).
- Hadoop Distributed File System (HDFS™)
Sistema de arquivos distribuído que provê acesso de alto desempenho
aos dados da aplicação.
- Hadoop YARN
Framework para agendamento dos trabalhos (job scheduling) e gerencia-
mento dos recursos do cluster.
- Hadoop MapReduce
Sistema baseado no YARN, para processamento paralelo de grandes
massas de dados (large data sets).

Existem outros projetos relacionados ao Hadoop. Abaixo, listam-se al-

guns desses projetos:

- Ambari™
Uma ferramenta gráfica para provisionamento, monitoramento e gerenci-
amento de clusters Hadoop.
- HBase™
Banco de dados distribuído, orientado a colunas (não relacional), que
comporta tabelas enormes de dados, contendo bilhões de linhas e mi-
lhões de colunas. Roda sobre HDFS.
- Hive™
datawarehouse distribuído. Gerencia dados armazenados em HDFS e pro-
vê uma linguagem de consulta de dados baseada em SQL, a qual é tra-
duzida em tempo de execução para as tarefas (jobs) MapReduce.

- ZooKeeper™
Coordenador de serviços centralizado de alta disponibilidade.

Versões de Hadoop

A série "1.x", continuação da série "0.20", processa os dados via "MapRe-

duce". Já a versão "0.23", renomeada como "2.x", utiliza o "MapReduce 2", um
novo mecanismo de processamento distribuído de dados, construído sobre o
sistema YARN, que realiza o gerenciamento geral dos recursos utilizados na
execução de aplicações distribuídas.
As propriedades de configuração tiveram seus nomes alterados da versão
1.x para a versão 2.x, conferindo maior regularidade na nomeação. Por exem-
plo: ao nome da propriedade de configuração do namenode: dfs.name.dir foi
alterado para dfs.namenode.name.dir, e o nome da propriedade do MapRe-
duce mapred.job.name teve seu nome alterado para mapreduce.job.name.
Sistemas construídos na versão 1.0.1 são compatíveis com servidores
das versões 1.0.2 ou 1.1.0, mas não funcionam com um servidor da versão
2.0.0.
Sistema de Arquivos Distribuído

O esquema de alocação de arquivos em disco de um Sistema Operacional

é denominado Sistema de Arquivos.
Existem vários sistemas de arquivo, como, por exemplo, o NTFS (Win-
dows) e o EXT4 (Linux), para citar alguns.
O sistema de arquivos utilizado pelo Hadoop é o HDFS, um acrônimo pa-
ra Hadoop Distributed FileSystem (Sistema de Arquivos Distribuído do Ha-
doop), projetado para armazenar arquivos muito grandes, com capacidade de
recuperação muito veloz e grande escalabilidade (capacidade que um sistema
distribuído tem de ser expandido em função de novas demandas de armazena-
mento).
Em virtude de o HDFS ser distribuído, os arquivos nele armazenados po-
dem ser acessados a partir de qualquer um dos nós do cluster.

MAPREDUCE

MapReduce é um framework que permite escrever aplicações que proces-

sam grandes quantidades de dados (vários Terabytes) em paralelo, de forma
confiável e tolerantes a falhas, em grandes clusters formados por máquinas
simples (commodity machines). O termo "commodity machines" pode ser en-
tendido como "computadores que não foram especificamente projetados para
serem parte de um cluster, mas que são adaptados para tal". Não se deve, po-
rém, confundi-los com computadores de baixa qualidade, mas sim, hardware
comum, de preço acessível. (WHITE, 2015). São computadores simples, mas
com arquitetura de servidor, não de desktop ou de notebook.

Um job MapReduce geralmente divide um conjunto de dados de

entrada em partes independentes que são processados ​por tarefas de mapea-
mento (map tasks) de uma forma completamente paralela. O framework clas-
sifica as saídas dos mapas (maps), que são, em seguida, fornecidos como en-
trada para as tarefas de redução (reduce tasks). Tipicamente, tanto a entrada
como a saída do job são armazenados num sistema de arquivos. O framework
se encarrega de agendar tarefas, monitorando e reexecutando as tarefas que
falharam.

MapReduce 1

Nesta versão, o MapReduce consiste de um nó mestre (master) denomi-

nado NameNode, de outro nó mestre denominado JobTracker (rastreador de
job), e os demais nós, os escravos (slaves) do cluster, agindo como DataNodes
(nós de dados) e TaskTrackers (rastreadores de tarefa).

O NameNode gerencia o namespace (espaço de nome) do sistema de ar-

quivos e os metadados de todos os arquivos e diretórios. Esta informação é ar-
mazenada de forma persistente no disco local na forma de dois arquivos: o pri-
meiro, a imagem do namespace (fsimage), e o segundo, um edit log (edits).

O NameNode também conhece os DataNodes nos quais todos os

blocos para um dado arquivo estão localizados. Porém, o NameNode não arma-
zena esta informação de forma persistente, porque esta informação é recons-
truída a partir dos DataNodes quando o sistema é iniciado.

Os Datanodes são os "trabalhadores braçais" do cluster. Eles armazenam

e recuperam blocos quando solicitados pelo NameNode, e, periodicamente, re-
portam ao NameNode os blocos que armazenam naquele momento.
Sem o NameNode, o sistema de arquivos não pode ser usado, pois
todos os arquivos no sistema de arquivos serão perdidos, uma vez que não se
conseguirá reconstruí-los a partir dos blocos dos DataNodes.
Para tornar o NameNode resiliente a falhas, pode-se salvar as infor-
mações do NameNode em múltiplos sistemas de arquivos (por exemplo, via
NFS).
Também é possível executar um SecondaryNameNode (NameNode
Secundário), que, apesar do nome, não age como um segundo NameNode. O
SecondaryNameNode tão somente realiza, de forma periódica, verificações
(checkpoints).
 O processo de verificação (checkpoint) executa as seguintes tarefas:

a. O SecondaryNameNode (SNN) solicita ao NameNode (NN) primário que en-

vie os arquivos "edits" (edição de logs) e "fsimage". Novas operações serão
inseridas em um novo arquivo "edits";
b. O SNN recupera os arquivos "fsimage" e "edits" do NN;
c. O SNN carrega o "fsimage" na memória, aplica cada operação contida no
"edits", e, em seguida, cria um novo arquivo "fsimage", consolidado;
d. O SNN envia o novo "fsimage" de volta ao NN;
e. O NN substitui o antigo "fsimage" pelo novo arquivo, e o antigo "edits" pelo
novo arquivo "edits", ambos enviados pelo SNN (item d). O NN também
atualiza o arquivo "fstime" para conter em que momento o checkpoint foi
realizado.

Observa-se que os requisitos de memória do SNN são idênticos aos do

NN, uma vez que o SNN tem de carregar o "fsimage" na memória. Em grandes
clusters, o SNN exige uma máquina dedicada.

MapReduce 2 (YARN)

MapReduce 2 (MRv2) é também chamado YARN, cujo significado é:

Yet Another Resource Negotiator, valendo, também, o acrônimo: YARN Appli-
cation Resource Negotiator.
Em MapReduce 1, a gerência do agendamento das tarefas (job
scheduling) nos TaskTracker e o monitoramento do progresso das tarefas (por
exemplo, mantendo atualizado um contador de maps de saída) é realizada pelo
JobTracker.
YARN (MRv2) remedia as deficiências de escalabilidade do MapRe-
duce clássico, pela divisão das responsabilidades do JobTracker em dois dae-
mons (programas independentes, que rodam em background):
- ResourceManager: gerencia o uso dos recursos pelo cluster;
 - ApplicationMaster: gerencia o ciclo de vida das aplicações sendo execu-
tadas no cluster.

A ideia é que uma ApplicationMaster negocie com o ResourceManager a

quantidade de recursos do cluster (descrito em termos contêineres, cada qual
com sua limitação de memória) e, depois, execute processos específicos da
aplicação nesses contêineres. Os contêineres são supervisionados por NodeMa-
nagers (gerenciadores de nós) em execução nos nós do cluster, o que garante
que a aplicação não utilizará mais recursos do que os que foram alocados.

Em YARN, cada instância de uma aplicação (MapReduce job) possui - du-

rante o ciclo de vida da aplicação - uma ApplicationMaster dedicada, que rece-
be notícias sobre o progresso e o status das tarefas, e informa sobre o anda-
mento dos trabalhos ao cliente que submeteu o job.

Falhas

- Falha em tarefas (tasks): Exceções em tempo de execução (runtime ex-

ceptions) e saídas repentinas da JVM são reportadas à ApplicationMaster, que
"marca" a tarefa (task) como falha. Da mesma forma, a ausência de ping após
um intervalo de tempo definido na propriedade mapreduce.task.timeout,
também faz com que a tarefa seja marcada como falha. A figura 1 exibe trecho
do arquivo mapred-default.xml e a propriedade mapreduce.task.time-
out. Entre as tags <value> e </value> observa-se o valor 300000, referen-
te ao total de milissegundos (ms) antes que uma tarefa (task) seja terminada,
caso a tarefa não haja leitura de dados, escrita de um processamento ou atua-
lização do status da tarefa. Um valor igual a 300.000 ms equivale ao tempo de
5 min, pois:

1000 ms = 1 s e 60 s = 1 min

300.000 ms = 300.000 ms x x = 5 min

 Figura 1: Configuração do tempo de timeout

A tarefa é marcada como falha após algumas tentativas (attempt) de

execução, valor que pode ser configurado em mapreduce.map.maxat-
tempts, para tarefas "map", e em mapreduce.reduce.maxattempts, para
tarefas "reduce".

Algumas aplicações podem ter seus resultados utilizados, mesmo que

uma determinada porcentagem de tarefas esteja marcada como falha. Configu-
ra-se as porcentagens pelas propriedades:

mapreduce.map.failures.maxpercent

mapreduce.reduce.failures.maxpercent
- Falha na Application Master: YARN tenta executar uma aplicação várias
vezes no caso de falha. Por padrão, uma aplicação é marcada como "falha" se
ela falha uma vez, número que pode ser configurado no arquivo yarn-de-
fault.xml na propriedade:

yarn.resourcemanager.am.max-retries

Uma ApplicationMaster envia pulsos (heartbeats) periódicos ao Resour-

ceManager, que detecta se houve falha. Em havendo, inicia uma nova instância
da aplicação em um novo contêiner (gerenciado por um NodeManager). Os es-
tados das tarefas no momento da falha podem ser recuperados, de forma que
as mesmas não precisem ser executadas novamente. Para tal, deve-se alterar
a propriedade yarn.app.mapreduce.am.job.recovery.enable para true.

Um novo endereço da ApplicationMaster em caso de falha terá de ser in-

formado pelo ResourceManager aos clientes que possuem tarefas gerenciadas
pela aplicação, o que causa um aumento no tempo de processamento.

- Falha no NodeManager: Se um NodeManager falha, ele para de enviar pul-

sos (heartbeats) ao ResourceManager, o que acarreta na remoção do nó do
pool de nós disponíveis do ResourceManager. O tempo que o ResourceManager
espera antes de considerar que o NodeManager falhou, por não estar enviando
mais pulsos, é configurado pela propriedade:
yarn.resourcemanager.nm.liveness-monitor.expiry-interval-ms
e seu valor padrão é igual a 600000 ms (10 minutos). Qualquer tarefa ou
aplicação em execução em um NodeManager falho será recuperado.
NodeManagers podem ser colocados em uma "lista negra" se o número
de falhas para uma aplicação for alto. A lista negra é construída pela Applicati-
onMaster, que tentará reagendar as tarefas em diferentes nós se mais do que
três tarefas falharem em um NodeManager. Esse valor pode ser configurado
na propriedade:
mapreduce.job.maxtaskfailures.per.tracker
- Falha no Resource manager: É uma falha séria, pois sem o ResourceMana-
ger não se consegue acessar, nem os jobs, nem os contêineres das tarefas.
Após a falha, o administrador do cluster deve "levantar" uma nova instância do
ResourceManager, com a recuperação do estado salvo. O estado consiste dos
NodeManagers bem como das aplicações em execução. Configura-se o armaze-
namento utilizado pelo ResourceManager pela propriedade:
yarn.resourcemanager.store.class
O padrão é:
org.apache.hadoop.yarn.server.resourcemanager.recovery.MemStore
que mantém o armazenamento em memória.

Map, Reduce e Shuffle

Para exemplificar como analisar uma base de dados com MapReduce, se-
rão utilizados os dados de levantamento do clima do National Climatic Data
Center (NCDC), disponível em http://www.ncdc.noaa.gov/, como propos-
to em WHITE (2015).

Os dados (figura 2) são armazenados em linhas no formato ASCII, com

cada linha sendo um registro, contendo informações, dentre outras: identifica-
ção da estação meteorológica, data e hora da observação, temperatura do ar
(em ºC x 10), pressão atmosférica, etc.

Figura 2: Registros de observações do NCDC

A base é composta de vários arquivos pequenos, contendo os dados de

cada uma das dezenas de milhares de estações meteorológicas para cada dia
do ano. Por exemplo, o diretório relativo a 1901 contém 6 arquivos comprimi-
dos (.gz), cada um deles com 1095 linhas; já em 2015, são 14.418 arquivos
(.gz), alguns dos quais com mais de 18.000 linhas de dados. Como Hadoop
trabalha bem com grandes arquivos, os conteúdos de vários arquivos peque-
nos de um dado ano, devem ser consolidados em um só arquivo por ano de co-
leta.

Para obter os arquivos, pode-se utilizar um aplicativo FTP cliente, tal co-
mo FileZilla (figura 3):

Figura 3: Cliente de FTP, FileZilla

Na metade esquerda da ferramenta, aparecem detalhes do endereço local. A

metade direita (endereço remoto) ainda não possui informação alguma, pois
falta realizar a conexão.
Para acessar o endereço de FTP onde estão disponíveis os arquivos do
exemplo, deve-se configurar esse endereço na ferramenta. Para tal, clique em
Arquivo -> Gerenciador de Sites... (figura 4):
 Figura 4: Iniciando a configuração do endereço FTP desejado

Na janela que abre, relativa ao Gerenciador de Sites, dê um clique no botão

Novo Site, e o renomeie como NCDC. Em seguida, preencha os campos como
mostrado na figura 5 e clique em Ok:

Figura 5: Cadastrando o endereço ftp.ncdc.noaa.gov no FileZilla

Agora, na janela inicial do FileZilla, clique na tecla de atalho do Gerenciador de
Sites (no alto, à esquerda).
 Figura 6: Realizando a conexão com o endereço remoto

Uma vez conectado, os dados disponibilizados no endereço remoto aparecem

na metade direita do aplicativo:

Figura 7: Exibição dos dados do computador remoto

Finalmente, navegue até o endereço remoto onde estão situados os arquivos
de dados (/pub/data/noaa), selecione os arquivos desejados, dê um clique com
o botão direito do mouse e clique em Baixar, para fazer o download dos arqui-
vos desejados para o computador local.
 Figura 8: Fazendo o download dos arquivos

MapReduce atua dividindo o processo em duas fases: a fase map e a fa-

se reduce. Cada fase possui pares chave-valor (key-value) como entrada e sa-
ída, como tipo de dado tanto da chave como do valor ficando a cargo do pro-
gramador. Deve-se especificar, também, duas funções: função map e função
reduce. A entrada para a fase map será a linha dos dados da NCDC (base do
clima):

- A chave (key) será a posição (offset) da linha do dado.

- O valor (value) será a própria linha, no formato texto.
 A função map é simples, tendo, por objetivo, extrair os dados referentes
a ano e temperatura de cada linha de dados. A função map é uma fase de pre-
paração de dados, de tal forma que a função reduce possa fazer o seu traba-
lho. No exemplo dado: encontrar a máxima temperatura para cada ano forneci-
do. A função map é também um bom lugar para se eliminar registros ruins,
por exemplo, filtrando os registros cujos dados de temperatura sejam faltan-
tes, suspeitos ou errôneos.

Para visualizar a forma como a fase map trabalha, considere as seguin-

tes linhas de dados de entrada (algumas colunas não utilizadas foram represen-
tadas por pontos):

0067011990999991950051507004...9999999N9+00001+99999999999...
0043011990999991950051512004...9999999N9+00221+99999999999...
0043011990999991950051518004...9999999N9-00111+99999999999...
0043012650999991949032412004...0500001N9+01111+99999999999...
0043012650999991949032418004...0500001N9+00781+99999999999...

Estas linhas são, então, fornecidas à função map como pares chave-va-
lor:
(0 , 0067011990999991950051507004...9999999N9+00001+99999999999...)
(106 , 0043011990999991950051512004...9999999N9+00221+99999999999...)
(212 , 0043011990999991950051518004...9999999N9-00111+99999999999...)
(318 , 0043012650999991949032412004...0500001N9+01111+99999999999...)
(424 , 0043012650999991949032418004...0500001N9+00781+99999999999...)

As chaves representam as posições das linhas dentro do arquivo (off-

sets). Essas chaves serão ignoradas na função map, que tão somente extrairá
o ano e a temperatura do ar (mostradas em destaque):

(0, 0067011990999991950051507004...9999999N9+00001+99999999999...)
(106, 0043011990999991950051512004...9999999N9+00221+99999999999...)
(212, 0043011990999991950051518004...9999999N9-00111+99999999999...)
(318, 0043012650999991949032412004...0500001N9+01111+99999999999...)
(424, 0043012650999991949032418004...0500001N9+00781+99999999999...)

A saída gerada pela função map é mostrada abaixo (os valores de tem-
peratura são convertidos para o tipo inteiro):
(1950 , 0)
(1950 , 22)
(1950 , −11)
(1949 , 111)
(1949 , 78)
 A saída da função map é processada pelo framework MapReduce antes
de ser enviada à função reduce. Este processamento utiliza a chave para orde-
nar e agrupar os pares chave-valor. No exemplo dado, a entrada da função re-
duce seria:
(1949 , [111 , 78] )
(1950, [0 , 22 , −11] )

Cada par contém um ano e uma lista de todas as temperaturas registra-

das para aquele ano. Tudo que a função reduce tem que fazer, então, é iterar
sobre cada uma das listas e encontrar a maior temperatura lida para cada ano.
Uma vez terminada a iteração, tem-se a saída final: a máxima temperatura
global (registrada por todas as estações) para cada ano, como mostrado abai-
xo:
(1949 , 111)
(1950 , 22)

MapReduce garante que a entrada para cada reduce seja ordenada pela
chave. O processo pelo qual o sistema realiza a ordenação e transfere as saí-
das do map para o reduce é conhecido por shuffle. É o "coração" do MapRe-
duce.
Hadoop Distributed Filesystem (HDFS)

HDFS é um sistema de arquivos distribuído, ou seja, gerencia o armaze-

namento de arquivos em máquinas fisicamente separadas (em rede). Por ser
baseado em rede, possui muito mais complicações do que sistemas de arqui-
vos de discos regulares, como, por exemplo, a tolerância às falhas dos nós
com nenhuma perda de dados.

HDFS foi projetado para:

- Armazenar arquivos muito grandes (gigabytes, terabytes, ou mesmo, pe-

tabytes);

- Escrever uma vez e ler muitas vezes: uma análise envolve uma grande par-
te de uma base de dados, se não toda ela. Assim, otimiza-se o processo
lendo toda a base de dados ao invés da leitura registro a registro;

- Funcionar em máquinas simples (commodity hardware).

Entretanto, HDFS não foi projetado para:

- Acesso a dados com baixa latência(*): aplicativos que requerem acesso de

baixa latência para os dados não vão funcionar bem com HDFS, que é oti-
mizado para elevadas taxas de transferência (throughput), conseguido à
custa de latência. HBase é, atualmente, a melhor escolha para o acesso de
baixa latência;

Obs.: Tempo de latência é a soma dos tempos de: posicionamento no setor que
contém os dados (latência rotacional) + posicionamento na trilha que con-
tém os dados (busca).
O tempo total de acesso aos dados de um disco, é igual à soma dos tempos
de: latência + transferência (do disco para a memória)

- Muitos arquivos pequenos: o número de arquivos é limitado pela quantida-

de de memória do NameNode, pois o mesmo contém metadados do siste-
ma de arquivos na memória. Como regra geral, cada arquivo, diretório e
 bloco, ocupa cerca de 150 bytes. Para um milhão de arquivos, cada um
ocupando um bloco, serão necessários, pelo menos, 300 MB de memória;

- Modificação de arquivos: após salvos em HDFS, os arquivos não podem ser

modificados, o que favorece uma alta taxa de transferência (throughput).

Blocos
Um sistema de arquivos para um disco simples lida com dados em bloco,
cujo tamanho define a quantidade mínima de dados que pode ser lida ou escri-
ta. Assim sendo, se um sistema de arquivos define que o tamanho do bloco é
1KB (1024 bytes), mesmo que um arquivo contenha 10 bytes de tamanho, ele
ocupará 1024 bytes em disco ao ser salvo. Naturalmente, um arquivo maior
ocupará vários blocos para seu armazenamento (por exemplo, um arquivo de
9,5 KB ocupará 10 blocos).
O HDFS também divide os dados em blocos que, por padrão, ocupam
128MB. Porém, ao contrário dos sistemas de arquivos para discos simples, em
HDFS, arquivos menores do que o tamanho do bloco não ocupam todo o espa-
ço.
Blocos HDFS são largos se comparados com blocos em discos simples
para minimizar o custo com a procura dos dados (latência).

NameNodes e DataNodes

O NameNode gerencia o espaço de nome (namespace) do sistema de ar-

quivos, por meio de metadata para todos os blocos, arquivos e diretórios na
árvore.
Os DataNodes são usados como armazenamento comum de blocos por
todos os Namenodes do cluster. Reportam-se periodicamente ao NameNode,
enviando heartbeats (batimentos cardíacos) periódicos, que servem como "si-
nais de vida", e listas com os blocos armazenados no momento do envio des-
tes relatórios.
HDFS Federado

O NameNode mantém uma referência ao namespace (arquivo, diretório e

bloco) do sistema de arquivos em memória. Clusters muito grandes possuem
um fator de limitação de escala. HDFS Federado, introduzido a partir da versão
2.x (release series), permite a inclusão de NameNodes, cada qual gerenciando
uma porção do namespace, ou seja, é um cluster que possui múltiplos names-
paces, cada qual sendo gerenciado por um NameNode. Por exemplo, um
NameNode pode gerenciar os arquivos sob o diretório "/user", e, um segundo
NameNode os arquivos sob "/share".
Os NameNodes federados são independentes, e não necessitam de coor-
denação uns com os outros. A configuração é compatível com versões antigas,
e permite a configuração de um NameNode único, existente, sem qualquer al-
teração. A nova configuração foi concebida de tal forma que todos os nós no
cluster tenham a mesma configuração, sem a necessidade da implantação de
configuração diferente com base no tipo do nó no cluster.

Alta Disponibilidade (HDFS High-Availability)

Replicar o metadado do NameNodes em vários sistemas de arquivos, e

usar o NameNode Secundário para criar pontos de checagem (checkpoints)
protege contra a perda de dados, mas não fornece alta disponibilidade do sis-
tema de arquivos. O NameNode continua sendo um único ponto de falha (SPOF
– Single Point Of Failure). Se ele falhar, todos os clientes, incluindo os jobs Ma-
pReduce seriam incapazes de ler, escrever ou listar os arquivos, porque o Na-
meNode é o único repositório de metadados e do mapeamento "arquivo-blo-
co". Em um evento como esse, todo o sistema Hadoop estará - efetivamente -
fora de serviço, até que um novo NameNode possa ser colocado online.
A versão 2.x do Hadoop remediou esta situação, adicionando suporte pa-
ra HDFS de alta disponibilidade (HA). Nesta implementação há um par de Na-
meNodes numa configuração "ativo - em espera" (active-standby). Em caso de
falha do NameNode ativo, o NameNode em espera (standby) assume suas fun-
ções, para continuar atendendo a solicitações do cliente sem interrupção signi-
ficativa.
 Se o NameNode ativo falhar, o NameNode em espera pode assumir
muito rapidamente (em algumas dezenas de segundos), pois tem o estado
mais recente disponível em memória, tanto do log da última edição, como do
mapeamento de bloco atualizado.
Na prática, o tempo real de substituição (failover) observado é lon-
go (em torno de um minuto ou mais), em função de o sistema ter de decidir
que o NameNode ativo falhou.

Observação: Failover é quando uma máquina substitui outra, no caso de falha

desta última.

Entendendo o Sistema de Arquivos Distribuído

Seja o cluster composto por um switch (na parte superior da imagem) e

quatro máquinas, como mostrado na figura 42.

Figura 42: Cluster com um switch e quatro máquinas (nós do cluster)

 Quando o usuário acessa o cluster e executa o comando para listar arqui-
vos (ls) ele está interagindo com o Linux. Porém, para processar arquivos no
ambiente de execução do Hadoop, o usuário necessita acessar arquivos arma-
zenados no HDFS. Para tal, utiliza-se hdfs dfs” (ou "hadoop fs") antes dos co-
mandos a serem executados no HDFS, de tal forma que a execução se dê no
Hadoop, e não no Linux.
Em virtude de o HDFS ser distribuído, os arquivos nele armazenados po-
dem ser acessados a partir de qualquer um dos nós do cluster.
Supondo que cada máquina do cluster da figura 42 possua um disco rígi-
do (HD) de 1,5 TB, particionado de tal forma que 0,5 TB seja formatado para
uso do Linux e 1,0 TB seja formatado para uso do Hadoop (HDFS), tem-se um
esquema de compartilhamento igual ao mostrado na figura 43.

Figura 43: Compartilhamento de disco entre nós do cluster

Pela figura 43 vê-se que o total de armazenamento compartilhado por todos os

nós do cluster é de 4TB.
Dessa forma, listar o diretório de qualquer nó, faz com que sejam exibidos os
diretórios e arquivos daquele nó somente. Porém, a listagem dos arquivos e di-
retórios do HDFS exibe o mesmo conteúdo, independentemente do nó em que
se execute o comando de listagem, comprovando que se trata de um recurso
compartilhado por todos os nós do cluster.
Por exemplo, a listagem do diretório “/home” do no02 (segunda máquina do
cluster da figura 42, de cima para baixo) produz o seguinte

Figura 44: Listagem do diretório /home do nó 02 do cluster

Observe que, nesta listagem, não há um diretório chamado “users” entre os di-
retórios “tez” e “yarn”.
Já a listagem do no03 (terceira máquina) produz o seguinte:
 Figura 45: Listagem do diretório /home do nó 03 do cluster

Observe que, na listagem da figura 45, há o diretório “users” entre os diretó-

rios “tez” e “yarn”, cujo detalhe está ampliado na figura 46.

Figura 46: Exibição do diretório “users” em no03

Já a execução dos comandos “hdfs dfs –ls /” (ou “hadoop fs –ls /”) e “hdfs dfs
–ls /user” (ou “hadoop fs –ls /user”), tanto do nó 02, como do nó 03, produz o
mesmo resultado:

Figura 47: Listagem de diretórios do HDFS nos nós 02 e 03

Isto comprova, independentemente do nó em que ocorre o acesso, que

se trata do mesmo sistema de arquivos, ou seja, o sistema enxerga todos os
HDs de todos os nós do cluster que estejam formatados com HDFS, como sen-
do "um mesmo HD".
Comandos do Shell HDFS

Entendida a distribuição de arquivos pelo HDFS e o porquê de os dados

estarem neste ambiente (os dados têm de ser compartilhados por todos os nós
do cluster), o passo seguinte é mostrar comandos do Shell HDFS.
A sintaxe é a seguinte:
hdfs dfs -comando argumentos

Comando: appendToFile

 Adiciona arquivos do sistema de arquivos local para o sistema de arquivos

destino (HDFS).

Uso:

hdfs dfs -appendToFile <localsrc> <dest>

Exemplo:

hdfs dfs -appendToFile localfile /hdfsDir/file

Comando: cat

 Exibe o conteúdo do arquivo.

Uso:

hdfs dfs -cat URI [URI ...]

Exemplo:

hdfs dfs -cat /hdfsDir/file

Comando: copyFromLocal
  Copia arquivos do sistema de arquivos local para HDFS. Similar ao coman-
do put.

Uso:

hdfs dfs -copyFromLocal [-f] <localsrc> URI

Exemplo:

hdfs dfs -copyFromLocal localfile /hdfsDir/file

Comando: copyToLocal

 Copia arquivos do sistema de arquivos HDFS para o sistema de arquivos

local. Similar ao comando get.

Uso:

hdfs dfs -copyToLocal [-f] URI <localsrc>

Exemplo:

hdfs dfs -copyToLocal /hdfsDir/file localfile

Comando: cp

 Copia arquivo(s) da origem (HDFS) para o destino (HDFS).

Uso:

hdfs dfs -cp [-f] URI [URI ...] <dest>

Exemplo:

hdfs dfs -cp /hdfsDir/file1 /hdfsDir/file2 /hdfsDir/dir

Comando: du

 Exibe o tamanho dos arquivos e diretórios.

 Uso:

hdfs dfs -du [-s] [-h] URI [URI ...]

Exemplo:

hdfs dfs -du -h hdfsDir/file /hdfsDir

Comando: expunge

 Esvazia a lixeira.

Uso:

hdfs dfs -expunge

Comando: get

 Copia arquivo(s) do sistema de arquivos (HDFS ) para o sistema de arqui-

vos local.

Uso:

hdfs dfs -get <src> <localdst>

Exemplo:

hdfs dfs -get /hdfsDir/file localfile

Comando: ls

 Lista os arquivos do diretório.

Uso:
 hdfs dfs -ls [-R] <args>

Exemplo:

hdfs dfs -ls /hdfsDir/file

Comando: mkdir

 Cria um diretório no sistema de arquivos (HDFS).

Uso:

hdfs dfs -mkdir <paths>

Exemplo:

hdfs dfs -mkdir /hdfsDir/dir1 /hdfsDir/dir2

Comando: mv

 Move arquivos da origem (HDFS) para o destino (HDFS). Não é permitido

mover arquivos entre sistemas de arquivos (de HDFS para local, e vice-
versa).

Uso:

hdfs dfs -mv URI [URI ...] <dest>

Exemplo:

hdfs dfs -mv /hdfsDir/file1 /hdfsDir/file2

Comando: put

 Copia arquivos do sistema de arquivos local para o sistema de arquivos

(HDFS).

Uso:

hdfs dfs -put <localsrc> <dest>

 Exemplo:

hdfs dfs -put localfile /hdfsDir/file

Comando: rm

 Apaga arquivos no sistema de arquivos (HDFS).

Uso:

hdfs dfs -rm [-f] [-r|-R] [-skipTrash] URI [URI ...]

Exemplo:

hdfs dfs -rm /hdfsDir/file

ADMINISTRAÇÃO DO CLUSTER

O Apache Ambari é um projeto que visa tornar simples o gerenciamento

de clusters Hadoop.
Ambari é carregado em navegador Web, e sua interface gráfica é intuiti-
va e fácil de usar. Por meio dessa interface, o administrador do cluster tem à
sua disposição diversos recursos de supervisão e controle, tais como:

- Instalar, por meio de um assistente passo-a-passo (step-by-step wizard)

serviços Hadoop em qualquer host do sistema;
- Configurar de serviços Hadoop;
- Parar, iniciar e reconfigurar serviços Hadoop entre os nós do cluster.

Por meio do painel (dashboard) de Ambari, o administrador do cluster con-

segue:

- Monitorar a saúde e o status do cluster;

- Obter métricas de funcionamento do sistema de cada host, enviando-as
para o Coletor de Métricas;
- Ser alertado pelo framework de alerta de Ambari, quando a situação ins-
pira atenção, como, por exemplo, quando um nó “cai”, há pouco espaço
remanescente em disco etc.
 O Ambari possui um dashboard (painel) que exibe os serviços instalados
e suas condições, além de várias métricas do sistema.

Figura 137: Dashboard do Ambari

Verifica-se que o HBase está parado. As sinalizações desse status são o

triângulo vermelho antes do nome do serviço e o sumário.

Figura 138: Indicação de serviço parado do HBase

Para iniciar o serviço, basta clicar em Service Actions -> Start:

 Figura 139: Iniciando o serviço HBase
Confirme a operação:

Figura 140: Confirmação da operação “Iniciar (Start) HBase”

Algumas vezes, há mais de um serviço parado, como mostrado na figura

137. Neste caso, pode-se iniciar todos os serviços (Start All) ao mesmo tempo:

Figura 141: Iniciando todos os serviços

 Após confirmar, o Ambari mostra o progresso da operação de iniciação
de todos os serviços.

Figura 142: Progresso da operação de iniciação de todos os serviços

Ao terminar a operação solicitada, a barra de progresso fica toda verde.

A figura 143 exibe várias operações executadas no sistema.

Figura 143: Operações de manutenção executadas no sistema

 Algumas vezes, é necessário executar mais de uma vez a operação de
reinício do serviço para “colocá-lo no ar”, como mostrado abaixo para o Hive:

Figura 144: Executando operação de início do Hive mais de uma vez

Finalmente, Ambari mostra todos os serviços funcionando:

Figura 145: Todos os serviços iniciados

 São muitas as possibilidades que o Ambari oferece, como, por exemplo,
exibir métricas sobre dado serviço ou recurso (como o HDFS):

Figura 149: Métricas do HDFS

Ambari é uma ferramenta poderosa, mas intuitiva e de fácil manipulação,

oferecendo leituras diversas sobre os vários recursos e serviços instalados no
sistema.

Figura 150: Duas leituras sobre as métricas do HDFS

BIBLIOGRAFIA

APACHE HBASE
Obtido da Internet: http://hbase.apache.org/book.html

GETTING STARTED WITH BITVISE SSH SERVER AND CLIENT

Obtido da Internet: https://www.bitvise.com/getting-started

HADOOP
Obtido da Internet: http://hadoop.apache.org

PACHECO, P. S. Parallel programming with MPI. Morgan Kaufmann Publish-

ers, Inc., 1997.

WHITE, T. Hadoop - The Definitive Guide. 4rd. ed. Sebastopol: O´Reilly,

2015.