Concrete Logo
Hamburger button

Hadoop, parte III

  • Blog
  • 20 de Dezembro de 2012
Share

 
Este post faz parte da série sobre BigData, MapReduce e Hadoop cujos primeiros posts foram os seguintes:

 

Um pouco da arquitetura do Hadoop

Um cluster totalmente configurado para rodar Hadoop inclui um conjunto de daemons ou programas residentes em diferentes servidores da sua rede. Eles tem papéis específicos. Alguns rodam somente em um servidor e outros em múltiplos servidores.

Os daemons incluem:

 

NameNode

    A arquitetura do Hadoop é similar a do framework de MapReduce do Google. Mostrei em uma figura do artigo MapReduce – parte III, que o Google mantém um nó master controlando todo o processo.

    O Hadoop também emprega o conceito master/slave tanto para o armazenamento como para o processamento distribuído. O sistema de armazenamento distribuído é chamado de Hadoop Distributed File System ou HDFS.

    O NameNode é o mais vital dos daemons. É o master do HDFS que comanda os daemons slaves DataNode para executar as tarefas de I/O de baixo nível.

    Assim como no GFS, o master do Hadoop não armazena nenhum dado e nem executa nenhum processamento relativo ao MapReduce. Sua função é a de um gerentão burocrata que trata de segmentar os arquivos em blocos, manter registro de quais nós armazenam os blocos e cuidar da saúde geral do sistema de arquivos.

    No caso do GFS, este ponto único de falha é compensado pela existência de um shadow master, que entra em ação tão pronto quanto possível em caso de falha do nó master. No Hadoop o guarda vidas é o Secondary NameNode ou o mais atual Backup node. A diferença é a necessidade de intervenção humana para reconfigurar o cluster para usar o SSN ou o Backup node como NameNode primário.

 

DataNode

    Cada máquina slave na sua rede hospeda um daemon DataNode para fazer o trabalho do sistema de arquivos distribuído e para replicar blocos de dados em outros DataNodes. Cada bloco é armazenado em no mínimo 3 réplicas.

 

Secondary NameNode

    O SSN agora está “deprecated”. Inclui aqui porque acho interessante entendê-lo dentro da arquitetura para saber as vantagens das novas opções e porque ainda é encontrado nos livros.

    É um daemon assistente para monitorar o estado do cluster HDFS. O NameNode armazena modificações no file system em um log. Quando o NameNode inicia, lê o estado do HDFS de um arquivo de imagem e aplica o que estava no log existente. Então grava o atual estado em um nova imagem e inicia um novo log. O Secondary NameNode junta (merge) a imagem com o log periodicamente e mantém o tamanho do log dentro de um certo limite.

    Cada cluster tem um único SSN. Ele tem as mesmas exigências de memória que o NameNode e por isso deve residir em uma outra máquina dedicada. Ele não armazena nenhum dado de MapReduce e nem faz nenhum processamento relativo a ele.

    Diferente do NameNode, não recebe e nem registra nenhuma mudança em tempo real. Ao invés disto se comunica com o NameNode e como disse acima, tira snapshots dos metadados HDFS em intervalos de tempos definidos na configuração do cluster.

    Para assumir o lugar do NameNode em caso de falha deste último, há um processo de recuperação que como dissemos antes, exige intervenção humana.

     

    Checkpoint Node

      O NameNode persiste seu namespace usando 2 arquivos:

        – fsimage – imagem do file system (último checkpoint do namespace) e
        – edits – journal (log) de mudanças no namespace desde o checkpoint.

      O Checkpoint node periodicamente cria checkpoints do namespace. Faz download dos arquivos fsimage e edits do NameNode ativo, junta os dois localmente e então sobe a nova imagem de volta ao NameNode ativo. O Checkpoint node normalmente roda em uma máquina diferente do NameNode porque precisa de memória de mesma grandeza.

      Um cluster pode ter múltiplos Checkpoint nodes.

     

    Backup Node

    O Backup node provê a mesma funcionalidade do Checkpoint node e mantem na memória cópias atualizadas do namespace do file system que é sempre sincronizado com estado do ativo NameNode. Estas facilidades substituem o trabalho do SSN.

    O Backup node não precisa fazer o download da imagem fsimage e do log edits para criar um checkpoint como é exigido do Checkpoint node ou do Secondary NameNode. Ele já tem na memória dados atualizados do estado.

    O processo de checkpoint do Backup node é mais eficiente porque apenas precisa salvar o namespace em um arquivo fsimage local e fazer reset no log edits. E ainda opcionalmente pode dispensar o NameNode de persistir o estado deixando toda esta responsabilidade a cargo do Backup node

    Como o Backup node mantem uma copia do namespace na memória, precisa do mesmo tanto de RAM que NameNode.

    O NameNode suporta apenas um Backup node mas no future está prevista a possibilidade de usar múltiplos Backup node concorrentemente. Se usar o Backup node, não pode usar Checkpoint nodes.

 

JobTracker

    É a ligação entre as aplicações e o Hadoop. Existe um único JobTracker por cluster. É ele que dita o plano de execução e determina quais arquivos vai processar, quais nós assumirão quais tarefas e monitora todas as tarefas em andamento.. Se uma tarefa falha, o JobTracker cuida de reiniciá-la possivelmente em um nó diferente (depois de um limitado número de tentativas).

 

TaskTracker

    Cada TaskTracker é responsável pela execução da tarefa designada pelo JobTracker. Existe um só TaskTracker por nó slave mas ele pode se espalhar por múltiplas JVMs para lidar em paralelo com várias tarefas de map ou de reduce. Uma das suas responsabilidades é se comunicar constantemente com o JobTracker. Caso o JobTracker não receba o heartbeat do TaskTracker dentro do tempo estipulado, assumirá que o TaskTracker falhou e resubmete a tarefa para outro nó do cluster.

 

Topologia de um cluster Hadoop

(antes do SSN ser deprecated)

    Cluster Hadoop - fig. 2.3 do ótimo livro Hadoop in Action da Editora Manning

    Nesta topologia, o nó master roda os daemons NameNode e JobTracker e há um nó dedicado ao SSN. Em clusters menores, o SSN pode residir em um dos nós slaves. Porém em clusters maiores, não só o SSN tem um nó só para ele, como também há nós separados para o NameNode e JobTracker. As máquinas slaves rodam as tarefas no mesmo nó onde seus dados são armazenados.

 

Configuração SSH em um cluster do Hadoop

Agora que já mostrei a arquitetura, ficou mais fácil explicar porque é preciso fazer isto.

Um cluster Hadoop tem um nó master que tipicamente hospeda o daemons NameNode e JobTracker. Ele serve também de base para contactar os nós slaves e ativar os daemons DataNode e TaskTracker. O Hadoop usa SSH com este objetivo.

A chave pública é armazenada localmente em cada nó do cluster e o nó master envia a chave privada quando tenta acessar uma máquina remota.

     

    Definir uma conta comum

      O Hadoop exige que todos nós usem a mesma conta de usuário, isto é, o mesmo username. Por questões de segurança é recomendável que esta conta, que serve apenas para gerenciar o cluster, tenha poderes limitados aos de um usuário comum.

     

    Verificar a instalação do SSH

      Caso receba alguma mensagem de erro, precisa instalar SSH (no Linux pode ser OpenSSH)

     

    Gerar par de chaves SSH

      Usar
      [sourcecode language=”bash” autolinks=”false”]ssh-keygen -t dsa -P ” -f ~/.ssh/id_dsa[/sourcecode]

      Captura de Tela

      Obs.: Na verdade teria que fazer tudo com o usuário hadoop mas só fiz assim na geração para mostrar aqui. Rodei os exemplos com meu usuário (e minhas chaves)

     

    Distribuir as chaves públicas e validar os logins

      Copiar a chave pública para o nó master e também para cada nó slave. Deveria fazer assim:
      [sourcecode language=”bash” autolinks=”false”]scp ~/.ssh/id_rsa.pub hadoop@target:~/master_key[/sourcecode]

      E manualmente entrar em cada nó target para configurar a master_key como uma chave autorizada:

      [sourcecode language=”bash” autolinks=”false”][hadoop@target]$ mkdir ~/.ssh
      [hadoop@target]$ chmod 700 ~/.ssh
      [hadoop@target]$ mv ~/master_key ~/.ssh/authorized_keys
      [hadoop@target]$ chmod 600 ~/.ssh/authorized_keys
      [/sourcecode]

      Depois validaria os logins tentando logar no nó target a partir do master:
      [sourcecode language=”bash” autolinks=”false”][hadoop@master]$ ssh target[/sourcecode]

      Na primeira vez aparecerá pedido de autenticação, que depois de confirmada, não pedirá mais.

      Porém…

      Vou rodar o exemplo em um só nó aqui na minha máquina. Então farei apenas o seguinte (com meu usuário mesmo):

      [sourcecode language=”bash” autolinks=”false”]cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
      ssh localhost[/sourcecode]

    Pronto, agora sim temos o hadoop configurado para rodar nosso teste.

 

Preparando para rodar o Hadoop na minha máquina

Lembram quando configurei conf/hdfs-site.xml com replication = 1, isto é, com um único nó em Hadoop, parte II?

Pois é, pedras em 3, 2, 1… um cluster de um único nó…

 

    Formatar o NameNode

      Os comandos do HDFS tem a seguinte forma geral:
      [sourcecode language=”bash” autolinks=”false”]hadoop fs -cmd <args>[/sourcecode]

      Como todo file system, permite operações do tipo adicionar arquivos e diretórios, copiar arquivos, apagar arquivos, listar arquivos e diretórios, etc. Mas o Hadoop permite operar sobre o file system também de forma programática (não vou mostrar isto aqui e nem entrarei nos detalhes do programa wordcount escrito para o Hadoop)

      Usando o Hadoop do arquivo tgz e supondo estar no diretório raiz do hadoop, formatar é apenas assim:
      [sourcecode language=”bash” autolinks=”false”]bin/hadoop namenode -format[/sourcecode]

      Se estivesse rodando o hadoop instalado via homebrew:
      [sourcecode language=”bash” autolinks=”false”]/usr/local/Cellar/hadoop/1.0.4/libexec/bin/hadoop namenode -format[/sourcecode]

     

    Iniciar o hadoop

      [sourcecode language=”bash” autolinks=”false”]bin/start-all.sh[/sourcecode]

     

    Verificar o que foi formatado:

      [sourcecode language=”bash” autolinks=”false”]bin/hadoop dfs -ls /[/sourcecode]

      Não consegui tirar a mensagem de erro “Unable to load realm info from SCDynamicStore”. Procurei bastante, achei várias dicas mas nenhuma deu certo. A mensagem não impede o funcionamento correto.

     

    Interface web

      Para monitorar o que está rodando, o NameNode provê uma página web configurada para a porta 50070. No meu caso seria acessada com https://localhost:50070

      É uma visão geral do seu cluster HDFS que permite navegar pelo file system, checar o status de cada nó DataNode e ver os logs dos daemons para verificar se tudo funciona nos conformes.

      O Hadoop provê também uma visão geral do status dos jobs MapReduce na porta 50030.

     

    Copiar o arquivo de dados para o file system do Hadoop

      Vou usar “hadoop fs -put
      [sourcecode language=”bash” autolinks=”false”]bin/hadoop fs -put input/pg4300-UlyssesJoyce.txt /input[/sourcecode]

      Para listar o conteúdo do diretório input “hadoop dfs -ls /input”[sourcecode language=”bash” autolinks=”false”]bin/hadoop dfs -ls /[/sourcecode]

     

    Copiar o diretório conf para dentro do diretório input no file system do Hadoop

      Confesso que não me lembro exatamente o motivo porque precisei fazer isto. Só sei que se não fizer, meu exemplo não funciona. Na verdade já faz tempo que estudei estas coisas, faz tempo que executei estes exemplos e aqui tenho registrado este passo. Mais tarde com calma, voltarei a isto e descobrirei exatamente o por quê disto. Por enquanto vai mesmo na base da receita de bolo do tipo “minha vó mandou colocar assim”.

      [sourcecode language=”bash” autolinks=”false”]bin/hadoop fs -put conf /input[/sourcecode]

Já temos o arquivo de dados no HDFS, falta agora rodar o exemplo.

 

Rodando o Hadoop na minha máquina

     
    Infelizmente ficarei devendo esta parte. Ocorre que está dando um erro no comando de execução do exemplo e não tenho tempo de depurar. Ocorre que tenho 3 hadoops aqui instalado e este exemplo já deu certo de outras vezes. Se nunca tivesse dado certo talvez fosse mais fácil encontrar o erro.

    Fiquei na dúvida se postava este artigo assim incompleto ou não. Mas como o principal objetivo é compartilhar aprendizado, pode ser que o texto tal como foi escrito sirva para alguém.

    [sourcecode language=”bash” autolinks=”false”]bin/hadoop jar hadoop-examples-1.0.4.jar wordcount input output
    [/sourcecode]

É isso. Não foi um modo muito bom de terminar esta série. Sorry…