Big Data para leigos - parte 1

Ecossistema Hadoop - Ferramentas para Big Data
Há algum tempo atrás pedi a meu irmão pra me ajudar a traduzir um tutorial do Yahoo sobre Hadoop e outras ferramentas para Big Data, e este trabalho finalmente foi concluído.

Hoje começo uma série que vai te fornecer informação relevante sobre os softwares comumente usados em projetos de análise de grandes volume de dados, com destaque para o Hadoop.

Hadoop


O Hadoop é uma infraestrutura de processamento em lote distribuído em larga escala. Mesmo podendo ser usado em uma única máquina, o seu verdadeiro poder reside na sua capacidade de se adaptar a centenas ou milhares de computadores, cada um com vários núcleos de processador. 

O Hadoop também é projetado para distribuir eficientemente grandes quantidades de tarefas através de um conjunto de máquinas.

Mas o que é uma grande quantidade de tarefas?

Estou falando de ordens de magnitude maior do que os sistemas existentes. Centenas de gigabytes de dados pra começar.

Na verdade, o Hadoop foi construído para processar dados "em escala web", da ordem de centenas de gigabytes a terabytes ou petabytes.

Nessa escala, é provável que o conjunto de dados de entrada não vá mesmo caber no disco rígido de um único computador, muito menos na memória.

Por isso o Hadoop inclui um sistema de arquivos distribuído que quebra os dados de entrada e envia frações dos dados originais para várias máquinas em seu cluster em  segurança.

Isso resulta processamento paralelo com todas as máquinas do cluster e cálculo dos resultados de saída da maneira mais eficiente possível.

Desafios em larga escala


Fazer computação em larga escala é difícil. Para trabalhar com esse volume de dados, é necessária a distribuição de partes do problema em várias máquinas para processamento paralelo. 

Sempre que são usadas ​​várias máquinas em cooperação, a probabilidade de falhas aumenta. Em um ambiente em uma a máquina, a falha não é algo que os projetistas de aplicações explicitamente se preocupam com muita frequência: se a máquina caiu, então não há nenhuma maneira para que o programa seja recuperado.

Em um ambiente distribuído, no entanto, falhas parciais são uma ocorrência esperada e comum. As redes podem experimentar falhas parciais ou totais, se switches e roteadores quebrarem.

Os dados podem não chegar a um determinado ponto no tempo devido ao congestionamento de rede inesperado.

Nós individuais de computação podem superaquecer, 

Podem ocorrer falhas no disco rígido, ou de falta de memória ou espaço em disco.

Os dados podem ser corrompidos, maliciosamente ou por erro de transmissão.

Várias implementações e versões de software cliente podem falar protocolos ligeiramente diferentes um do outro.

Clocks podem ficar dessincronizados, arquivos de bloqueio podem não ser liberados, as partes envolvidas em transações atômicas distribuídas podem perder sua conexão de rede, 

Em cada um desses casos, o resto do sistema distribuído deve ser capaz de se recuperar da falha ou condição transitória de erro e continuar a fazer progressos.

É claro que, na verdade, fornecer tais resiliências é um grande desafio de engenharia de software.

Diferentes sistemas distribuídos abordam especificamente certos modos de falha, enquanto se preocupam menos com os outros.

O Hadoop não fornece nenhum modelo de segurança, nem salvaguarda contra dados maliciosamente inseridos.

Ele não consegue detectar um ataque MITM, por exemplo.

Por outro lado, ele é projetado para lidar com questões de falha de hardware e situações de congestionamento de forma muito robusta.

Outros sistemas distribuídos podem ser usados para problemas com outros requisitos (alta segurança, por exemplo).

Além de se preocupar com esses tipos de erros e desafios, há também o fato de que o hardware tem recursos finitos. Os principais recursos incluem:

  • Tempo do processador
  • Memória
  • Espaço em disco
  • Largura de banda de rede

Máquinas individuais normalmente têm apenas alguns gigabytes de memória. Se o conjunto de dados de entrada é de vários terabytes, isso exigiria mil ou mais máquinas para manter os dados na memória RAM e, mesmo assim, nenhuma máquina seria capaz de processar ou tratar todos os dados.

Os discos rígidos são muito maiores; uma única máquina pode armazenar vários terabytes de informação em seus discos rígidos.

Mas o conjunto de dados intermediários gerados durante a execução de uma computação em larga escala pode facilmente multiplicar a ocupação de espaço em relação ao conjunto de dados de entrada original tinha ocupado.

Durante esse processo, alguns dos discos rígidos utilizados pelo sistema poderão ficar cheios, e o sistema distribuído pode precisar redirecionar esses dados para outros nós que possam armazenar o excesso.

Finalmente, a largura de banda é um recurso escasso, mesmo em uma rede interna.

Enquanto um conjunto de nós diretamente conectados por uma ethernet gigabit geralmente tem alta taxa de transferência entre eles, se todas as máquinas transmitirem conjuntos de dados multi-gigabyte, podem facilmente saturar a capacidade de largura de banda do switch.

Além disso, se as máquinas estão espalhadas por vários racks, a largura de banda disponível para a transferência de dados seria muito menor.

E mais, solicitações RPC e outros pedidos de transferência de dados usando este canal podem ser adiados ou descartados.

Para ser bem sucedido, um sistema distribuído em larga escala deve ser capaz de gerir os recursos acima mencionados de forma eficiente.

E deve atribuir alguns desses recursos para a manutenção do sistema como um todo, dedicando o máximo tempo possível para o cálculo real de processamento dos dados.

A sincronização entre várias máquinas continua a ser o maior desafio no projeto de sistemas distribuídos.

Se os nós de um sistema distribuído podem se comunicar de forma explícita, os projetistas de aplicatições devem estar cientes dos riscos associados a tais padrões de comunicação.

Torna-se muito maior o risco de gerar mais chamadas de procedimento remoto (RPC) do que o sistema pode suportar!

E a capacidade de continuar o cálculo em caso de falhas torna-se mais difícil.

Por exemplo, se há 100 nós presentes em um sistema e um deles falha, os outros 99 nós devem ser capazes de continuar a computação, de preferência, com apenas uma pequena penalização proporcional à perda de 1% do poder de computação.

Naturalmente, isto irá exigir que a computação de qualquer trabalho perdido seja possível.

Além disso, se há uma complexa rede de comunicação sobre a infraestrutura  distribuída, determinar a melhor forma de reiniciar o cálculo do nó que falhou e propagar esta informação sobre a mudança na topologia da rede pode ser não trivial de implementar.

A lei de Moore


Então, por que usar um sistema distribuído? Eles parecem trazer mais problemas do que soluções. E com o ritmo acelerado do projeto de hardware, parece inevitável que o hardware de um único chip seja capaz de "crescer" para lidar com os volumes maiores de dados.

Afinal de contas, a Lei de Moore (em homenagem a Gordon Moore, fundador da Intel) afirma que o número de transistores que podem ser colocados em um processador irá duplicar aproximadamente a cada dois anos, pela metade do custo.

Mas as tendências em projeto de chips estão mudando para enfrentar novas realidades. Enquanto ainda é possível dobrar o número de transistores por unidade de área nesse ritmo, isso não necessariamente resulta em um desempenho  mais rápido.

Novos processadores e arquiteturas agora se concentrar em incorporar muitas CPUs menores ou "núcleos" para o mesmo dispositivo físico.

Isso permite processar duas vezes mais dados em paralelo, com a mesma velocidade em que operava anteriormente.

Mesmo se centenas ou milhares de núcleos são colocados numa máquina única, não seria possível entregar os dados de entrada para esses núcleos suficientemente rápido para processamento.

Discos rígidos individuais só podem sustentar velocidades de leitura entre 60-100 MB/segundo.

Estas velocidades têm vindo a aumentar ao longo do tempo, mas não no mesmo ritmo alucinante como processadores.

Sendo otimista e assumindo o limite máximo de 100 MB/segundo, e assumindo quatro canais independentes disponíveis para a máquina, temos 400 MB de dados a cada segundo.

Um conjunto de dados 4 terabyte levaria, portanto, mais de 10.000 segundos para ser lido - cerca de três horas apenas para carregar os dados.

Com 100 máquinas separadas, cada uma com dois canais, isso cai para três minutos.

A Abordagem Hadoop


Hadoop foi concebido para processar eficientemente grandes volumes de informação, ligando muitos computadores convencionais em conjunto para funcionar em paralelo.

A máquina de 1000 CPU teóricos descritos anteriormente custaria uma quantidade muito grande de dinheiro, muito mais do que 1.000 máquinas com uma única CPU ou 250 máquinas com 4 CPUs.

O Hadoop vai amarrar essas máquinas menores em um único cluster de computação de baixo custo.

Conclusão


Entendo que o Hadoop é uma demonstração clara da aplicabilidade de sistemas distribuídos na solução de problemas que envolvam alto volume de dados, o que se torna cada vez mais comum atualmente.

Assim, entender os desafios e as soluções representadas pelo Hadoop e seu ecossistema é fundamental para quem deseja estar preparado para resolver os problemas enfrentados pelas organizações hoje.

Quer saber mais ? Confira o ebook que preparei, e confira esta palestra gratuita!

Em breve a parte 2... aguarde e confira :)

Christian Guerreiro

Professor por vocação, blogueiro e servidor público por opção, amante da tecnologia e viciado em informação.


Ensino a distância em Tecnologia da Informação: Virtualização com VMware, Big Data com Hadoop, Certificação ITIL 2011 Foundations e muito mais.


Suporte o Tecnologia que Interessa!

Você acha que as informações compartilhadas aqui são úteis?
Então me ajude a produzir ainda mais e melhores conteúdos!


É muito fácil. Basta divulgar nossos treinamentos pra alguém que conheça!


E se for de Salvador, podemos estruturar um curso presencial para sua empresa!

Eu vou ficar muito grato (e quem fizer os curso também :)!