A apresentação propõe três arquiteturas Hadoop para processar dados de monitoramento de rede de uma empresa de telecomunicações. A proposta 3, que usa Hadoop, HBase, YARN e CrateData, é a escolhida por oferecer maior capacidade de processamento e não impactar sistemas legados.

1. Slide 1 de 20.
Proposta para arquitetura Hadoop
FIAP / 2BDT
Adriano Laranjeira (RM 46.316)
Alexandro Romeira (RM 46.452)
Amarildo Clemente (RM 46.515)
Caio Deustch (RM 46.418)
Wellington Silva (RM 46.477)

2. Slide 2 de 1209.
Agenda
 1 INTRODUÇÃO
 1.1 Business Trigger
 1.2 O problema
 1.3 Objetivo da pesquisa
 1.4 Metodologia
 2 ESTUDO DE CASO
 2.1 Arquitetura & Indicadores atuais
 2.2 Volumetrias
 2.3 Fluxo atual de dados
 2.4 Ensaios:
 2.4.1 Proposta 01: Hadoop como repositório
 2.4.2 Proposta 02: Hadoop 2 + HBase + Yarn
 2.4.3 Proposta 03: Hadoop 2 + HBase + Yarn + CrateData
 3 FINALIZAÇÃO
 3.1 Conclusões
 3.2 Sugestão para trabalhos futuros
 3.3 Referências

3. Slide 3 de 19.
Proposta para arquitetura Hadoop
1 Introdução

4. Slide 4 de 1209.
1.1 Business Trigger
 Um dos objetivos de uma certa empresa de Telecomunicações é a
expansão de sua rede em ~40%;
 Esta rede é monitorada por um NOC com capacidade atual de processamento em
~2.000 rq/s (requisições por segundo);
 Estas requisições são dados de leitura de status dos
equipamentos de rede espalhados em todo Brasil.

5. Slide 5 de 1209.
1.2 O problema
 A infraestrutura atual deste NOC atende de forma satisfatória
mas sem folga;
 Considerando os objetivos de negócio conclui-se que muito em breve
ele será incapaz de atender às necessidades de
monitoração da companhia.

6. Slide 6 de 1209.
1.3 Objetivo da pesquisa
Encontrar uma arquitetura MPP ideal, baseada em
Hadoop;
Prover crescimento na capacidade de
computação, atendendo à necessidade de monitoração da área.

7. Slide 7 de 1209.
1.4 Metodologia
Pesquisa de softwares satélites ao Hadoop 2;
 Ensaio e experimentação teórica de arquiteturas lógicas para
atender ao objetivo da pesquisa.

8. Slide 8 de 19.
Proposta para arquitetura Hadoop
2 ESTUDO DE CASO

9. Slide 9 de 19.
2.1 Arquitetura & Indicadores atuais
Cidade 1
Coletor
Cidade N
Coletor
Consolidador
Matriz
 A meta neste processo é que
85% ou mais das requisições
sejam processadas com sucesso;
 A volumetria atual é de ~2.100
rq/s(1), com sinais claros de que este
volume está em crescimento;
 Hoje, a área aponta que 85% a
90% destas requisições são
processadas - sinal que qualquer
aumento significativo no volume de
equipamentos a ser monitorado vai
degradar o indicador.
1 - rq/s = requisições por segundo

10. Qtde - /5 minutos
Slide 10 de 1209.
2.2 Volumetrias
REQUISIÇÕES DE MONITORAÇÃO
Monitoração
Qtde Alvos
Alvo Item Mínima Máxima
Ambiente
Headend CMTS Porta giga 267 267 801
Headend CMTS CPU 267 267 801
Headend CMTS Temperatura 267 267 801
Headend CMTS – Porta UP Tráfego 42720 42720 128160
Headend CMTS – Porta DOWN Tráfego 10680 10680 32040
Datacenter Switch CPU 154 154 462
Datacenter Switch Tráfego na porta 3696 3696 11088
Datacenter Router CPU 57 57 171
Datacenter Servidor CPU 228 228 684
Datacenter Servidor Disco 228 228 684
Datacenter Servidor Rede 228 228 684
Totais 58792 58792 176376
Considerações relevantes:
 A tabela acima serve apenas para melhorar o entendimento da necessidade. Os dados são confidenciais para a
companhia por isso os alvos e as respectivas volumetrias foram alterados.

11. Slide 11 de 19.
2.3 Fluxo atual de dados
 Cada cidade gera arquivos do tipo RRD e grava-os localmente em seu coletor;
 Esses arquivos são transferidos para um servidor consolidador, que lê os
arquivos com os dados de monitoração permitindo a geração de dados
consolidados, drill-down e gráficos para acompanhar a disponibilidade dos
serviços;
 Lembrando, a frequência deve ser de ~2.000 rq/s. Os dados no consolidador são
mantidos tanto em RRD como em SQL.

12. Slide 12 de 1209.
2.4 Ensaios
Propostas:
 2.4.1 - Hadoop como repositório dos arquivos RRD;
 2.4.2 - Hadoop 2 + HBase + Yarn;
 2.4.3 - Hadoop 2 + HBase + Yarn + CrateData.

13. Slide 13 de 1209.
2.4.1 Proposta 01: Hadoop como repositório
Cidade 1 Cidade 2 Cidade 3 Cidade N
Coletor Coletor Coletor Coletor
HDFS (5 máquinas: 2 namenode + 3 datanode)
Vantagens
 Coletor passa a ser só uma unidade de processamento, não armazena mais dados.
Desvantagens
 Só melhora disponibilidade dos dados. A melhora no processamento é questionável.
Consumidores

14. Consumidores
Slide 14 de 1209.
2.4.2 Proposta 02: Hadoop + YARN + HBase
Cidade 1
Cidade N
Vantagens
Coletor
Coletor
RRDs @ HDFS
 Coletor agora é só uma unidade de processamento, não armazena mais nada;
 Melhora na capacidade de computação é altamente provável;
 Aumentar capacidade de computação implicaria apenas em adicionar nós no cluster.
Desvantagens
 As aplicações integradas na camada de dados do consolidador teriam que ser reescritas. Hoje elas
fazem acesso direto ao dado SQL e esta proposta implicaria em alterar sistemas externos;
 Retrabalho e curva de aprendizado do time para reescrever todos os scripts (shell, Perl e PHP) na
plataforma YARN com HBase.
(5 máquinas: 2 namenode + 3
datanode)
YARN
HBase
Consolidador
passa a ser
YARN + HBase.

15. Consumidores
Consolidador
passa a ser YARN
+ HBase.
Dados podem ser
acessados via
CrateData.
Slide 15 de 1209.
2.4.3 Proposta 03: Hadoop + YARN + Hbase + CrateData
Cidade 1
Cidade N
Vantagens
Coletor
Coletor
RRDs @ HDFS
(5 máquinas: 2 namenode + 3
datanode)
YARN
HBase
CrateData
 Coletor agora é só uma unidade de processamento, não armazena mais nada;
 Melhora na capacidade de computação altamente provável;
 Aumentar capacidade de computação implicaria apenas em adicionar nós no cluster;
 Aplicações legadas podem se integrar via SQL pela camada CrateData.
Desvantagens
 Retrabalho e curva de aprendizado do time para reescrever todos os scripts (shell, Perl e PHP) na
plataforma YARN com Hbase, além de projetar/construir as visões materializadas (atualizáveis ou
não) nos bancos de dados da camada CrateData.

16. Slide 16 de 19.
Proposta para arquitetura Hadoop
3 Finalização

17. Slide 17 de 1209.
3.1 Conclusões
 A arquitetura que traz o menor impacto para a operação é
a proposta 01;
 No entanto utiliza-la não traz ganhos em processamento, por isso a
escolha do grupo é a proposta 03, que além de
liberar os coletores da tarefa de manter dados, promete ganhos
significativos através da utilização do YARN, além de não impactar
os sistemas integrados legados com a solução CrateData.

18. Slide 18 de 1209.
3.2 Sugestão para trabalhos futuros
 Melhorar a arquitetura para prover o conceito de Data Lake (ou Data Service);
 Aplicar na prática as arquiteturas propostas para extração de métricas e
apresentar comparações mais precisas;
 Criar uma camada REST para que as aplicações externas não tenham de
conhecer a tecnologia aplicada dentro da camada de dados.

19. Slide 19 de 1209.
3.3 Referências (1/2)
 APACHE HADOOP 2.5.1 - YARN. Disponível em: <http://hadoop.apache.org/docs/current/hadoop-yarn/
hadoop-yarn-site/YARN.html>. Acesso em 15 de Outubro de 2014.
 APACHE HADOOP. Disponível em: <http://en.wikipedia.org/wiki/Apache_Hadoop>. Acesso em 13 de
Outubro de 2014.
 APACHE HBASE. Disponível em: <http://en.wikipedia.org/wiki/Apache_HBase>. Acesso em 16 de
Outubro de 2014.
 CRATE DATA DOCUMENTATION. Disponível em: <https://crate.io/docs/stable/>. Acesso em 10 de
Outubro de 2014.
 HADOOP - APACHE HADOOP 2.5.1. Disponível em: <http://hadoop.apache.org/docs/current/>. Acesso
em 17 de Outubro de 2014.
 HADOOP DISTRIBUTED FILE SYSTEM (HDFS). Disponível em:
<http://br.hortonworks.com/hadoop/hdfs/>. Acesso em 11 de Outubro de 2014.
 HADOOP YARN. Disponível em: <http://br.hortonworks.com/hadoop/yarn/>. Acesso em 15 de Outubro de
2014.

20. Slide 20 de 1209.
3.3 Referências (2/2)
 HBASE - APACHE HBASE HOME. Disponível em: <http://hbase.apache.org/>. Acesso em 19 de Outubro
de 2014.
 HDFS ARCHITECTURE GUIDE. Disponível em:
<http://hadoop.apache.org/docs/r1.2.1/hdfs_design.html>. Acesso em 21 de Outubro de 2014.
 MASSIVELY PARALLEL (COMPUTING). Disponível em:
<http://en.wikipedia.org/wiki/Massively_parallel_%28computing%29>. Acesso em 22 de Outubro de 2014.
 NETWORK OPERATIONS CENTER. Disponível em:
<http://en.wikipedia.org/wiki/Network_operations_center>. Acesso em 12 de Outubro de 2014.
 REPRESENTATIONAL STATE TRANSFER. Disponível em:
<http://en.wikipedia.org/wiki/Representational_state_transfer>. Acesso em 14 de Outubro de 2014.
 RRDTOOL - ABOUT RRDTOOL. Disponível em: <http://oss.oetiker.ch/rrdtool/>. Acesso em 15 de Outubro
de 2014.
 RRDTOOL. Disponível em: <http://en.wikipedia.org/wiki/RRDtool>. Acesso em 16 de Outubro de 2014.