View - IFBa

Análise Arquitetural do Hadoop File System
João Carlos Nascimento Pacheco
Vinícius Azevedo de Melo
Instituto Federal da Bahia (IFBA)
Salvador, Bahia, Brasil.
[email protected]
Instituto Federal da Bahia (IFBA)
Salvador, Bahia, Brasil.
[email protected]
Resumo—A cada dia, novas barreiras vêm sendo
ultrapassadas na área da tecnologia da informação e paralela a
esta questão, o aumento na quantidade e complexidade dos
serviços oferecidos na Web, consequentemente levando a uma
grande quantidade de informação a ser gerenciada.
Para o processamento destas informações, escalabilidade,
tolerância a falhas, alta disponibilidade de armazenamento
dentre outros, são fatores importantíssimos que precisam ser
avaliados, já que mecanismos convencionais que fazem
gerenciamento de dados não oferecem tal suporte almejado.
Eis que uma das soluções existentes atualmente é o Apache
Hadoop, um arcabouço para o armazenamento e processamento
de dados em larga escala. Ele oferece como ferramentas
principais o MapReduce, responsável pelo processamento
distribuído, e o Hadoop Distributed File System (HDFS), para
armazenamento de grandes conjuntos de dados, também de
forma distribuída.
Keyword – Hadoop, HDFS, MapReduce.
I.
INTRODUÇÃO
Uma das grandes barreiras encontradas atualmente no
mundo da tecnologia da informação está em armazenar e
gerenciar de forma inteligente a grande quantidade de
informações que vêm sendo disponibilizada.
Sistemas de mídias sociais, serviços corporativos,
sistemas Web, dentre outros, vêm produzindo uma quantidade
gigantesca de dados. A maioria destes dados se encontra
armazenada em uma forma não estruturada e em sistemas,
linguagens e formatos heterogêneos, em muitos casos,
incompatíveis entre si. [3].
É neste cenário que surge o Apache Hadoop, um
framework para o processamento de grande quantidade de
informações em aglomerados computacionais, com objetivo
de prover soluções para os sistemas distribuídos.
Ele oferece como ferramentas principais o MapReduce,
responsável pelo processamento distribuído, e o HDFS, para
armazenamento de grandes conjuntos de dados, também de
forma distribuída. [2]
Com base nestas breves informações, o intuito deste
artigo consiste em analisar como são desempenhadas as
tarefas de processamento, armazenamento, gerência e
transferência dos dados do HDFS, através da extração de
duas view-points distintas, sendo a primeira estrutural e a
segunda, uma visão de implantação, para que ambas nos
permitam avaliar como o HDFS cumpre os requisitos
funcionais e não funcionais definidos em seu projeto.
Este trabalho está estruturado da seguinte forma: Na
próxima seção está descrito o que consiste de fato o HDFS, e
quais são seus objetivos, requisitos funcionais e não
funcionais.
Na seção conseguinte duas visões arquiteturais foram
extraídas do HDFS e demonstradas com o intuito de destacar
possíveis estilos, padrões arquiteturais, componentes,
conectores e configuração final obtida.
Posteriormente, uma demonstração de como foi realizado
o mapeamento do modelo arquitetural nos artefatos de
implementação do HDFS e por fim, discussões e soluções
alternativas serão pontuadas com base em uma visão
comparativa crítica.
II.
HDFS
Um sistema gerenciador de arquivos convencional tem
em suas premissas um conjunto de funcionalidades, como por
exemplo,
armazenamento,
organização,
nomeação,
compartilhamento, recuperação, permissão e proteção aos
arquivos geridos de forma que todo este processo ocorra de
maneira mais “transparente” possível ao usuário. [3]
Já um sistema gerenciador de arquivos distribuído deve
além de possuir as premissas descritas acima, permitir o
armazenamento e o compartilhamento desses arquivos em
diversos hardwares diferentes, interconectados por meio de
uma rede.
O HDFS foi inspirado no Google File System e projetado
para ser implantado em hardware de baixo custo,
organizados dentro de um cluster. Cada cluster contém um
único Namenode, que é o componente de software
responsável por armazenar em memória os metadados
referentes à localização dos arquivos gerenciados, manter a
integridade do sistema e responder requisições dos clientes
que desejam fazer operações com os arquivos. [2]
Os dados físicos estão propriamente armazenados nos nós
do cluster denominados Datanodes. Estes nós, dentro do
conceito trazido pelo Hadoop são máquinas comuns, numa
combinação aceitável de aproximadamente dez mil
trabalhando em paralelo, que podem ser substituídas ou
adicionadas ao cluster de acordo com a demanda de
armazenamento e à medida que apresentarem eventuais
problemas. [2]
O Namespace de um HDFS consiste em registros que
armazenam metadados de arquivos, tais como: localização,
permissões de acesso, data de acesso e modificação, e cotas
de espaço em disco.
Estes registros são chamados de Inodes, e são mantidos
em memória RAM pelo Namespace. A decisão arquitetural
de manter o Namespace separado dos dados foi tomada para
permitir a escalabilidade do sistema, visto que, o acesso aos
metadados é mais rápido em relação à transferência de
arquivos inteiros. [1] [2]
O processo de leitura dos dados dá-se através do HDFS
Client que solicita ao Namenode um arquivo, este retorna
uma lista de Datanodes, contendo os blocos daquele arquivo.
De posse desta lista, o HDFS Client conecta-se diretamente
aos respectivos Datanodes detentores dos blocos e efetua a
leitura dos dados.
Quando um cliente solicita uma operação de leitura,
o Namenode envia as informações necessárias para que a
leitura seja efetuada juntamente com um checksum do bloco
que está sendo lido, para que o cliente leitor verifique a sua
integridade. Caso o bloco não esteja íntegro, o cliente notifica
o Namenode, que por sua vez envia um novo checksum de
outro Datanode que possua uma réplica do mesmo bloco. [2]
O processo de escrita de dados em arquivos ocorre de
forma similar: o HDFS Client solicita ao Namenode a escrita
do primeiro bloco do arquivo no sistema e tem como resposta
uma lista de Datanodes para armazenar as réplicas daquele
bloco. [2]
Outro detalhe relevante é que cada bloco de informação
enviado pelo cliente é seguido de um checksum como forma
de verificar a integridade do bloco de dados no momento que
ele chega a cada Datanode. Este checksum é guardado
separadamente dos metadados das informações de fato, que o
cliente escreveu no arquivo. [2]
Espera-se que o Namenode organize as réplicas em
Datanodes espalhados em máquinas e em racks diferentes, de
modo a aumentar a disponibilidade destes arquivos quando
solicitados, visto que, no procedimento de leitura de um
arquivo, são escolhidos os Datanodes mais próximos do
cliente que fez a solicitação. O uso de réplicas também
garante que dados não serão perdidos em caso de falha de um
nó. [1] [2]
Adiante, os Datanodes ainda enviam Blockreports e
Heartbeats para o Namenode. O primeiro consiste em
informações sobre as réplicas dos blocos dos arquivos que
cada Datanode possui, por padrão, um Blockreport é enviado
assim que o Datanode se registra, depois disso, é agendado
um envio de hora em hora. Desta forma o Namenode
consegue manter-se atualizado com relação aos arquivos
disponíveis no sistema. [1].
Já um Heartbeat tem por finalidade informar ao
Namenode que o respectivo Datanode que o enviou está
ativo, permitindo manter a integridade do sistema, visto que,
Datanodes que não enviam Heartbeats por cerca dez minutos
são desativados e, se necessário, o Namenode cria novas
replicas em outros nós para substituir aquele Datanode. [2]
Um Heartbeat contém informações importantes sobre o
respectivo Datanode
que viabilizam as ações de
balanceamento tomadas pelo Namenode, tais como:
capacidade total de armazenamento, quantidade de espaço em
uso e volume de dados em tráfego decorrente de operações de
leitura e/ou escrita em andamento. [2]
III.
PROJETO ARQUITETURAL
A escolha dos Datanodes leva em consideração questões
como balanceamento de uso de espaço em disco e distância
física até o cliente solicitante. Ao receber os possíveis
destinos de escrita dos dados, o HDFS Client organiza um
pipeline de instruções e os envia para os respectivos
Datanodes. Este processo se repete para cada bloco de
arquivo a ser escrito e os Datanodes escolhidos para o
armazenamento podem variar. [2]
Um detalhe relevante é que quando um cliente está
escrevendo informações no arquivo a ser enviado, somente
ele poderá fazer este procedimento e nenhum outro cliente
em paralelo poderá fazer o mesmo procedimento, garantindo
um dos requisitos funcionais, denominado Write-Once-ReadMany. [2]
Os arquivos armazenados pelo HDFS geralmente são
divididos em blocos e cada bloco é replicado em três
Datanodes distintos, por padrão. [1] [2]
Figura 1 – Visão Estrutural
Os protocolos disponibilizados pela camada core exibida
na Figura 1 servem para padronizar a comunicação interna e
viabiliza a adição ou substituição de novos componentes,
desde que eles utilizem o mesmo conjunto de protocolos.
O HDFS atende a um estilo de arquitetura em camadas
observando que a aplicação acessa a interface provida pelo
HDFS Core, que por sua vez compõe o núcleo do sistema,
que integra o Namenode, Datanodes e os demais
componentes por meio dos protocolos NamenodeProtocol e
DatanodeProtocol. [8]
A escrita em arquivo por parte do HDFS Client utiliza-se
do estilo arquitetural Pipe-and-Filter. À medida que é
formado um pipe entre os nós para os quais os dados vão ser
persistidos, e estes fluem dos nós mais próximos para os mais
remotos, considerando-se distância calculada através da
topologia de rede, o primeiro nó recebe os dados, guarda para
si os que são destinados a ele e repassa adiante os que devem
chegar aos nós adjacentes. [2] Este fluxo de dados entre os
nós do pipe configura a utilização de um conector do tipo
stream.
O Hadoop Pipe é uma solução fornecida pelo projeto
Hadoop, que cria um pipe composto de jobs, e pode ser
utilizado pelo HDFS Client para realizar a tarefa de escrita de
arquivos.
A seguir estão listados os pares que se comunicam
utilizando os estilos arquiteturais acima descritos:




HDFS Client e Namenode - uso de conector
NamenodeProtocol, que utiliza os conectores remote
procedure call - ipc (utilizando a Lib IPC), HTTP,
arbitrator, distributor e stream.
HDFS Client e Datanodes - uso de conector do tipo
DatanodeProtocol para envio de recebimento de dados,
utilizando os conectores remote procedure call - ipc e
stream.
Datanodes e Namenode - uso de conector
DatanodeProtocol para envio de Heartbeats e
Blockreports dos Datanodes para o Namenode. No
sentido contrário, em resposta aos Datanodes, o
Namenode utiliza o conector NamenodeProtocol para
passar instruções aos nós sobre o que fazer (armazenar
arquivo, ligar, desligar, enviar relatório com urgência).
Backupnodes e Namenode - há uma sincronização em
tempo de execução em que o Backupnode conecta-se ao
Namenode através de um conector NamenodeProtocol e
obtém as informações contidas no Namenode.

Balancer e Datanodes - uso do conector
DatanodeProtocol e InterDatanodeProtocol para
estabelecer conexão, coordenar, distribuir atividades de
balanceamento entre Datanodes e permitir o fluxo de
dados entre os mesmos.
Os componentes HDFS Client, Namenode, Balancer e
Datanodes, possuem um interpretador de comandos para
efetuar suas atividades quando invocados, atendendo,
portanto ao estilo arquitetural Basic Interpreter. [8]
Isto permite, por exemplo, que o administrador mude em
tempo de execução algum parâmetro de funcionamento do
sistema e ordene ao Balancer que verifique novamente como
está balanceamento dos dados. Esse estilo permite que novos
comandos sejam adicionados em cada artefato sem impacto
sobre a arquitetura.
O funcionamento do HDFS Client é voltado para uma
execução em lote das requisições, uma vez que a interação
com o usuário não é prioridade, desta forma o estilo
arquitetural Batch Sequential é utilizado, priorizando-se a
vazão dos dados em detrimento do tempo de resposta ao
cliente. [4]
A possibilidade de uso do protocolo HTTP provida pelo
NamenodeProtocol para acesso à suas informações consiste
em uma aplicação do estilo arquitetural Cliente Servidor. Este
protocolo pode ser utilizado pelo Backupnode e pelo HDFS
Client, como faz o WebHDFS
Ainda de acordo com a figura 1, considerando os conectores
existentes, temos os seguintes valores de dimensão:


O conector do tipo remote procedure call - ipc
utilizado pelos protocolos NamenodeProtocol,
DatanodeProtocol e InterDatanodeProtocol utiliza
passagem de parâmetro por referência, invocação
explícita, acesso público e chamadas síncronas com
único ponto de entrada. [7]
O conector do tipo stream utilizado pelos protocolos
DatanodeProtocol e InterDatanodeProtocol utiliza
buffer de 64kb, entregando unidades atômicas aqui
denominadas blocos em formato raw, não
guardando estado das conexões efetuadas, e atuando
de forma remota realizando transferência síncrona
com tempo limite. Este ainda é capaz de enviar e
receber dados simultaneamente em mais de uma
conexão, e cada bloco é enviado no máximo uma
vez. [2]


O conector do tipo arbitrator utilizado pelos
protocolos NamenodeProtocol e DatanodeProtocol
age de forma autoritária, por meio de comandos
diretos retornados para os Datanodes por meio do
DatanodeProtocol para o primeiro, e por meio de
comandos diretos enviados do BlockScanner e do
Balancer, para o segundo. [2]
O conector do tipo distritbutor implementado pelos
protocolos NamenodeProtocol e DatanodeProtocol
utiliza o mecanismo de entrega do tipo unicast. O
roteamento é feito de forma dinâmica, pois um
Datanode possui um identificador único e este pode
ser reconhecido pelo Namenode mesmo se o seu
endereço IP mudar. Os nós que o distributor pode
afetar são do tipo adhoc, visto que novos Datanodes
podem ser adicionados ao sistema em tempo de
execução e estes estarão sujeitos ao que for
determinado por meio dos protocolos citados, tanto
pelas operações de balanceamento efetuadas pelo
balancer quanto para a escolha dos nós que
receberão réplicas dos blocos no processo de escrita
efetuada pelo Namenode. [2]
IV.
IMPLEMENTAÇÃO E IMPLANTAÇÃO
A Figura 2 exibe uma proposta de implantação, onde uma
aplicação cliente acessa algum dos HDFS Clients
disponibilizados para efetuar operações, estes HDFS Clients
são: WebHDFS e C API Lib.
O WebHDFS é um HDFS Client que traz consigo o
protocolo Representational State Transfer (REST), e por isto
apresenta todas as características decorrentes das decisões
arquiteturais utilizadas neste Commercial-Off-The-Shelf, do
inglês, Produto Comercial de Prateleira (COTS). [10]
A utilização do WebHDFS consiste em requisições do
tipo GET do protocolo HTTP para efetuar cada operação
disponibilizada pelo HDFS Client, como: ler arquivo,
adicionar à arquivo, criar/apagar diretório, listar diretório,
obter checksum de arquivo, definir permissão, dentre outras.
[8] [9] [10]
A C API Lib é uma segunda alternativa de HDFS Client
que disponibiliza um conector do tipo RPC através da
biblioteca Java Native Interface (JNI), para execução de
código Java nativo a partir da linguagem C. [10]
A aplicação, utilizando de um dos artefatos citados acima,
pode acessar o HDFS Client para efetuar as mesmas ações
que o WebHDFS acessa, só que, neste caso, o faz por meio
de chamadas do tipo RPC. [9] [10]
Cabe aqui ressaltar que ao efetuar uma leitura/escrita, seja
qual for o HDFS Client utilizado, o algoritmo do Namenode
que retorna a lista de Datanodes a serem lidos considera a
distância até o Client e ordena pela menor distância, assim
sendo, caso o WebHDFS Client seja utilizado, os Datanodes
contidos no mesmo rack no qual ele se encontra serão
posicionados primeiro na lista, e o mesmo acontece com
relação ao C API Lib, de forma análoga. [9]
V.
DISCUSSÃO E CONCLUSÕES
Os ganhos com o desenvolvimento do HDFS foram de
grande valia para que mais um passo fosse dado no mundo da
tecnologia da informação.
Figura 2 – Visão de Implantação
Características como redundância de dados, recursos
contra eventuais falhas, seja de consistência de informação ou
de máquinas físicas, grande capacidade de armazenamento de
informações, processamento em máquinas convencionais,
simplicidade oferecida ao desenvolvedor com relação a
gerenciamento de questões relativas à computação paralela,
escalabilidade e balanceamento de carga proporcionada pelo
próprio arcabouço, são algumas das principais vantagens de
adota-lo como ferramenta de gerenciamento distribuído de
informações. Além do alto desempenho alcançado por meio
do estilo Batch Sequential, implementação que prioriza a
vazão dos dados trafegados. [1] [3]
A capacidade de receber e interpretar comandos em
tempo de execução provida pela aplicação do estilo
arquitetural Basic Interpreter permite que o administrador
consulte informações e configure o Namenode e o Balancer
de modo a otimizar o funcionamento do sistema de acordo
com a sua necessidade.
O alto desempenho entregue pelo HDFS também reside
no uso do IPC, uma lib que provê um mecanismo remote
procedure call de forma rápida, por não utilizar a serialização
nativa do Java, fazendo com que o cliente implemente sua
própria serialização de forma otimizada
A arquitetura em camadas utilizada, permitiu que novas
funcionalidades fossem adicionadas ao sistema, como é o
caso dos Backupnodes e CheckpointNodes que só foram
adicionados ao projeto em um segundo momento, e
utilizaram o NamenodeProtocol provido pelo HDFS Core,
integrando-se à solução sem impacto significativo sobre os
artefatos já existentes, e trazendo consigo features
importantes para atender ao requisito de tolerância à falhas.
[2]
Outro fator positivo a ser citado é o custo para a utilização
deste sistema, que por ser open source, garante uma redução
de custo considerável em relação a um sistema concorrente
proprietário. [3]
Por outro lado, o uso de um único Namenode tende limitar
a escalabilidade provida pela arquitetura implementada pelo
HDFS, quando o número de arquivos providos cresce. [4]
Uma vez que para aperfeiçoar o tempo de resposta às
requisições dos clientes, os metadados dos arquivos do
Datanode ficam armazenados em memória RAM no
Namenode, portanto, a quantidade de informações
armazenadas é limitada pelo tamanho desta memória. [4]
Somado a isto, existe o fato de que durante o ciclo de vida
do sistema de arquivos o espaço necessário para armazenar os
dados cresce numa proporção maior do que o armazenamento
físico disponível, fazendo com que a memória RAM do
Namenode se torne um “gargalo” para escalabilidade do
sistema. [4]
Além disso, o envio de Heartbeats dos nós para o
Namenode cria uma carga interna ao sistema, que pode se
tornar disfuncional caso o número de nós seja tal que
comprometa a capacidade do Namenode de responder a
requisições clientes externas. [4]
Como uma alternativa ao HDFS, existe o Ceph. Este
apresenta uma solução para sistema de arquivos distribuídos
onde o Namenode é replicado em um cluster de acordo com a
demanda, de modo a balancear a carga de armazenamento do
namespace e dividir a carga interna do sistema em vários nós.
[6]
O intuito com o Ceph é de prover maior escalabilidade e
maior tolerância a falhas em relação ao Hadoop, visto que o
uso de um único Namenode consiste em um único ponto de
falha, e mesmo com as estratégias de backup e recovery
oferecidas pelo HDFS do Hadoop, o processo de recuperação
no caso de uma falha no nó da rede onde o Namenode se
encontra pode demandar um tempo considerado inaceitável
para aplicações que exigem alta disponibilidade. [6]
REFERÊNCIAS
[1] Borthakur D. "HDFS Architecture Guide", abril 2009,
http://archive.cloudera.com/cdh4/cdh/4/mr1/hdfs_design.pdf,
[2] Chansler R., Kuang H., Radia S., Shvachko K. and Srinivas S.,
"The
Hadoop
Distributed
File
System"
http://www.aosabook.org/en/hdfs.html
[3] Goldman, A., Kon, F., Junior, F. P., et al. “Apache Hadoop:
Conceitos teóricos e práticos, evolução e novas possibilidades”,
XXXI Jornadas de atualizações em informática, 2012,
http://www.imago.ufpr.br/csbc2012/anais_csbc/eventos/jai/artigos/JAI%20%20Cap%203%20Apache%20Hadoop%20conceitos%20teoricos
%20e%20praticos,%20evolucao%20e%20novas%20possibilidades.pdf
[4] Konstantin Shvachko, et al., “The Hadoop Distributed File
System,” Mass Storage Systems and Technologies (MSST), IEEE
26th
Symposium
on
IEEE,
2010,
http://storageconference.org/2010/Papers/MSST/Shvachko.pdf.
[5] P. Bone, “Integrating NLTK with the Hadoop Map Reduce
Framework”,
Junho
2008,
http://ww2.cs.mu.oz.au/~pbone/papers/nltk-hadoop.pdf
[6] Scott, B., E. M. Estolano, C. Maltzahn, A. Khurana, A. Nelson,
e S. Weil, “Ceph as a Scalable Alternative to the Hadoop Distributed
File
System,”
vol.
35,
Agosto
2010,
http://static.usenix.org/publications/login/201008/openpdfs/maltzahn.pdf
[7] Hadoop Wiki - http://wiki.apache.org/hadoop/ipc
[8] Hadoop Version Control System http://hadoop.apache.org/version_control.html
[9] LibHDFS C API http://hadoop.apache.org/docs/stable/libhdfs.html
[10] WebHDFS REST API http://hadoop.apache.org/docs/stable/webhdfs.html