Processamento distribuído de grandes blocos de
dados
Critical Manufacturing
2014 / 2015
1111439 Rui Magalhães
Processamento distribuído de grandes blocos de
dados
Critical Manufacturing
2014 / 2015
1111439 Rui Magalhães
Licenciatura...
iii
«Great solutions are the ones who solve great problems»
Amr Awadallah
Processamento distribuído de grandes blocos de dados
iv
Agradecimentos
Gostaria de agradecer ao Instituto Superior de Enge...
Processamento distribuído de grandes blocos de dados
v
Resumo
A recolha de informação sobre as diferentes etapas de produç...
Processamento distribuído de grandes blocos de dados
vi
Índice
1 Introdução .................................................
Processamento distribuído de grandes blocos de dados
vii
ferramentas externas ...............................................
Processamento distribuído de grandes blocos de dados
viii
Índice de Figuras
Figura 1 – Gráfico demonstrativo da relação do...
Processamento distribuído de grandes blocos de dados
ix
Figura 25 – Gráfico de utilização das CPUs no cluster ...............
Processamento distribuído de grandes blocos de dados
x
Índice de Tabelas
Tabela 1 – Planeamento do projecto .................
Processamento distribuído de grandes blocos de dados
xi
Notação e Glossário
ACID Atomicidade, Consistência, Integridade e ...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães xii
JSON JavaScript Object Notati...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 1
1 Introdução
O modelo relaciona...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 2
1.1 Apresentação do projeto/est...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 3
1.1.1 Planeamento de projeto
O ...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 4
1.1.2 Reuniões de acompanhament...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 5
1.4 Organização do relatório
O ...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 6
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 7
2 Contexto
Dado o problema em c...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 8
2.2 Modelo Relacional
Desde que...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 9
2.3 BigData e Business intelige...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 10
2.4 ACID vs. BASE
Um sistema d...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 11
Durabilidade
A durabilidade é ...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 12
sistemas de bases de dados dis...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 13
 Consistência e tolerância ao...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 14
estado eventual de consistênci...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 15
Este modelo tem algumas varian...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 16
uma versão mais antiga do cari...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 17
3 Tecnologias e Ferramentas
3....
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 18
Figura 3 – Esquema representat...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 19
Os principais objetivos e cara...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 20
3.3 MapReduce
O MapReduce é um...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 21
Preparação de dados
Na primeir...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 22
Figura 5 – Fase de redução do ...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 23
demonstrar-se uma má implement...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 24
O ResourceManager é um process...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 25
Fonte: https://www.packtpub.co...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 26
Fonte: http://image.slideshare...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 27
atualizações, inserções e elim...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 28
menor o tempo de carregamento ...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 29
de um CBO, mais concretamente ...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 30
esquema dos dados a importar. ...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 31
requeridos (White, 2012). Mais...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 32
3.9 Distribuições Hadoop
Dada ...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 33
3.9.2 Cloudera Data Hub
 Cust...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 34
uma das propriedades CAP tem d...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 35
todos os nós desempenham o mes...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 36
superior a um trabalho de MapR...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 37
4 Descrição técnica
Após o lev...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 38
4.2 Sistema de base de dados d...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 39
4.2.1 Hadoop (Standalone)
A in...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 40
4.2.1.3 Configuração dos nós p...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 41
4.2.1.4 Ficheiros de configura...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 42
Block size (propriedade dfs.bl...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 43
A ferramenta está disponível p...
Processamento distribuído de grandes blocos de dados
Rui Fernando Alves Rebelo Magalhães 44
O retorno indica-nos os valore...
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Processamento distribuído de grandes blocos de dados - Rui Magalhaes
Próximos SlideShares
Carregando em…5
×

Processamento distribuído de grandes blocos de dados - Rui Magalhaes

1.344 visualizações

Publicada em

1 comentário
0 gostaram
Estatísticas
Notas
  • Somos una estructura privada que siendo ofreciendo préstamos entre privados resumidamente y a largo plazo que van de 4000€ a 3.000.000€ a cada persona seria en la necesidad. El tipo de interés es del 2.5% sobre toda duración de reembolso. Préstamo inmobiliario, préstamo a la inversión, préstamo automóvil, préstamo personal. Estamos disponibles a satisfacer a nuestros clientes en la duración mayor del 72 ver 3 días. Contactamos sobre el puesto: aurelioazietta@gmail.com
       Responder 
    Tem certeza que deseja  Sim  Não
    Insira sua mensagem aqui
  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
1.344
No SlideShare
0
A partir de incorporações
0
Número de incorporações
18
Ações
Compartilhamentos
0
Downloads
4
Comentários
1
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Processamento distribuído de grandes blocos de dados - Rui Magalhaes

  1. 1. Processamento distribuído de grandes blocos de dados Critical Manufacturing 2014 / 2015 1111439 Rui Magalhães
  2. 2. Processamento distribuído de grandes blocos de dados Critical Manufacturing 2014 / 2015 1111439 Rui Magalhães Licenciatura em Engenharia Informática Outubro de 2015 Orientador ISEP: Paulo Oliveira Supervisor Externo: Ricardo Magalhães
  3. 3. iii «Great solutions are the ones who solve great problems» Amr Awadallah
  4. 4. Processamento distribuído de grandes blocos de dados iv Agradecimentos Gostaria de agradecer ao Instituto Superior de Engenharia do Porto pela formação disponibilizada durante todo o percurso da minha licenciatura em Engenharia Informática. Agradeço ao Professor Doutor Paulo Oliveira pela orientação fornecida durante todo o projeto, bem como a sua disponibilidade e sempre rápida e valiosa reposta. Agradeço também à Critical Manufacturing pela remuneração generosa oferecida mensalmente, pela formação oferecida, e pela oportunidade de trabalhar num projeto de vanguarda, tomando contacto com profissionais como o Engenheiro Ricardo Magalhães que sempre se mostrou disponível e empenhado na supervisão do projeto. A revisão ortográfica e semântica do presente documento por parte da Diana Silva enriqueceu e clarificou inúmeras secções pelo que agradeço a sua ajuda e apoio moral.
  5. 5. Processamento distribuído de grandes blocos de dados v Resumo A recolha de informação sobre as diferentes etapas de produção num chão de fábrica é crucial para a eficiência de negócio. A análise destes dados pode ser feita em tempo real, permitindo prever a ocorrência de eventos críticos como rotura de matérias-primas, avaria de uma máquina, entre outros. Existem, o entanto, processos de análise posteriores, que evolvem uma quantidade enorme de dados históricos na tentativa de encontrar relações causais entre conjuntos de dados. São processos que exigem imenso poder de computação, e visam apurar, por exemplo, fatores que levam a um equipamento defeituoso. Este projeto baseia-se no estudo de tecnologias que suportem o armazenamento e consulta de grandes volumes de dados. O presente documento incide em tecnologias NoSQL como Cassandra, Hadoop e o seu ecossistema, HBase, MongoDB e Spark. O NoSQL foi escolhido pela sua escalabilidade e arquitetura natural para processamento distribuído. A solução final propõe a utilização de uma distribuição Hadoop, tirando partido de ferramentas embutidas para, importação automática de dados de uma RDBMS para um sistema NoSQL, análise de dados usando uma interface próxima do SQL e armazenamento eficiente de dados recorrendo a compressão. Os resultados obtidos evidenciam a crescente facilidade de adoção do Hadoop, este oferece ferramentas para inúmeras tarefas e suporta todos os comandos SQL essenciais. Apesar de ter sido projetada apenas para um cluster de três máquinas, com o recurso a otimizações, o sistema tem desempenhos próximos de uma RDBMS. Por apurar fica a eficiência da escalabilidade. Palavras-chave (Tema): Processamento distribuído e escalável Importação de dados para bases de dados NoSQL Interface de pesquisa SQL em sistemas NoSQL Palavras-chave (Tecnologias): NoSQL; Hadoop; MapReduce; Hive; Sqoop; Big Data
  6. 6. Processamento distribuído de grandes blocos de dados vi Índice 1 Introdução ..............................................................................................................1 1.1 Apresentação do projeto/estágio .....................................................................2 1.2 Apresentação da organização ..........................................................................4 1.3 Contributos deste trabalho...............................................................................4 1.4 Organização do relatório .................................................................................5 2 Contexto.................................................................................................................7 2.1 Introdução........................................................................................................7 2.2 Modelo Relacional ..........................................................................................8 2.3 BigData e Business inteligence, o valor do armazenamento de dados ...........9 2.4 ACID vs. BASE ............................................................................................10 2.5 NoSQL ..........................................................................................................16 3 Tecnologias e Ferramentas...................................................................................17 3.1 Apache Hadoop.............................................................................................17 3.2 HDFS.............................................................................................................18 3.3 MapReduce....................................................................................................20 3.4 Apache YARN...............................................................................................23 3.5 Apache Tez....................................................................................................25 3.6 Apache Hive..................................................................................................26 3.7 Apache Sqoop ...............................................................................................29 3.8 SQuirreL SQL Client.....................................................................................31 3.9 Distribuições Hadoop....................................................................................32 3.10 MongoDB ..................................................................................................33 3.11 MSSQL To MongoDB Tool (SQL2Mongo)..................................................34 3.12 Cassandra...................................................................................................34 3.13 Hbase .........................................................................................................35 3.14 Apache Spark.............................................................................................35 4 Descrição técnica .................................................................................................37 4.1 Requisitos......................................................................................................37 4.2 Sistema de base de dados distribuído, escalável horizontalmente de forma económica, e tolerante a falhas ................................................................................38 4.3 Importação automática de dados de um sistema de base de dados relacional para um cluster NoSQL ...........................................................................................50 4.4 Linguagem familiar para consulta, em tempo útil, de grandes volumes de dados 59 4.5 Visualização de dados armazenados num sistema NoSQL a partir de
  7. 7. Processamento distribuído de grandes blocos de dados vii ferramentas externas ................................................................................................71 4.6 Sistema de instalação automática e de fácil configuração com componente de monitorização...........................................................................................................73 5 Conclusões ...........................................................................................................85 5.1 Requisitos realizados.....................................................................................87 5.2 Limitações e trabalho futuro .........................................................................87 5.3 Apreciação final ............................................................................................89
  8. 8. Processamento distribuído de grandes blocos de dados viii Índice de Figuras Figura 1 – Gráfico demonstrativo da relação do volume de pesquisas dos termos Cap theorem, NoSQL e Cloud Computing .................................................................................................................................11 Figura 2 – Modelos de consistência de sistemas distribuídos.................................................................12 Figura 3 – Esquema representativo de parte do ecossistema Hadoop...................................................18 Figura 4 – Fase de mapeamento do algoritmo mapreduce....................................................................21 Figura 5 – Fase de redução do algoritmo mapreduce ............................................................................22 Figura 6 – Fluxo de informação entre as etapas de map, shuffle e reduce.............................................22 Figura 7 – Arquitetura do Hadoop 2.0 descrevendo os componentes do sistema YARN ........................23 Figura 8 – Esquema representativo da interacção dos diferentes componentes do YARN .....................24 Figura 9 – Esquema comparativo entre os passos realizados pelo MapReduce e pelo Tez para uma mesma query ..........................................................................................................................................25 Figura 10 – Diferentes fases de desenvolvimento do projecto Stinger e respectivas metas a alcançar .29 Figura 11 – Arquitetura de uma solução Sqoop entre RDBMS e tecnologias Hadoop............................31 Figura 12 – Arquitetura da distribuição Hadoop da HortonWorks (HDP 2.3).........................................32 Figura 13 - Arquitetura da distribuição Hadoop da Cloudera (CDH 5.4) ................................................33 Figura 14 – Estado do cluster cassandra ................................................................................................46 Figura 15 – Informação detalhada do Replica Set criado no MongoDB .................................................49 Figura 16 – Output para a consola do resumo da importação Sqoop para HBase.................................56 Figura 17 – Função de carregamento automático em volume para o HBase a partir de um ficheiro csv ................................................................................................................................................................56 Figura 18 – Log do HBase com a informação sobre tabela criada e operações pendentes....................57 Figura 19 – Interface da ferramenta de Importação do SQL2mongo .....................................................58 Figura 20 – Interface Job History do Hadoop com log de uma aplicação Spark.....................................61 Figura 21 – Output para a consola de uma operação de MapReduce realizada no Hive.......................63 Figura 22 - Output para a consola de uma query realizada no Hive usando o motor de execução Tez..63 Figura 23 – Operação de conversão de uma tabela Hive para ficheiro ORC usando MapReduce..........65 Figura 24 - Operação de conversão de uma tabela Hive para ficheiro ORC usando Tez.........................66
  9. 9. Processamento distribuído de grandes blocos de dados ix Figura 25 – Gráfico de utilização das CPUs no cluster ............................................................................67 Figura 26 – Demonstração do efeito Hot Container ...............................................................................68 Figura 27 – Demonstração da análise de estatísticas a uma tabela ORC...............................................69 Figura 28 – Menu de configuração de drivers SQuirreL..........................................................................72 Figura 29 – Interface de input de comando SQL do SQuirreL .................................................................72 Figura 30 – Informação detalhada, apresentada pelo SQuirrel, do resultado de uma query.................73 Figura 31 – Página de Login do Apache Ambari.....................................................................................76 Figura 32 – Menu de configuração das máquinas e respectiva chave RSA durante a instalação do HDP ................................................................................................................................................................76 Figura 33 – Distribuição dos diferentes componentes do HDP pelas máquinas do cluster.....................78 Figura 34 – Menu de atribuição de componentes HDP cliente, e servidor, a cada nó ............................79 Figura 35 – Interface de instalação do CDH............................................................................................82 Figura 36 – Passo final da instalação do Cloudera Manager..................................................................83 Figura 37 – Interface de monitorização de administração do Cloudera Manager .................................84
  10. 10. Processamento distribuído de grandes blocos de dados x Índice de Tabelas Tabela 1 – Planeamento do projecto ........................................................................................................3 Tabela 2 – Requisitos não funcionais e funcionais..................................................................................37 Tabela 3 – Especificações dos nós do cluster ..........................................................................................38 Tabela 4 – Descrição dos principais parâmetros de configuração do Hadoop .......................................41 Tabela 5 – Parametros de entrada para o script de cálculo dos recursos optimos alocados por cada nó do cluster Hadoop...................................................................................................................................43 Tabela 6 – Correspondência entre o ficheiro de configuração, o nome da propriedade e a fórmula de cálculo do valor da mesma.....................................................................................................................44 Tabela 7 – Relação entre tempos de execução de queries com o volume de registos envolvido ............60 Tabela 8 – Comparação dos tempos de execução do Tez e MapReduce.................................................64 Tabela 9 – Comparação do tempo de conversão da tabela Factmaterialmovement usando o Tez e usando MapReduce ................................................................................................................................66 Tabela 10 – Comparação do tamanho final das tabelas nos formatos TextFile e ORC File.....................66 Tabela 11 – Comparação entre o tempo de execução de uma query numa tabela em formato TextFile com outra em formato ORC File .............................................................................................................67 Tabela 12 – Comparação entre o tempo de execução de uma query com e sem vectorização, bem como o tempo de execução recorrendo a Hot Conteiners................................................................................68 Tabela 13 - Comparação entre o tempo de execução de uma query com e sem CBO, bem como o tempo de execução recorrendo a Hot Conteiners ..............................................................................................69 Tabela 14 – Comparação entre tempos de execução de uma query usando apenas MapReduce em relação à utilização de otimizações ........................................................................................................70 Tabela 15 – Lista de componentes do HDP selecionados para instalação..............................................77 Tabela 16 - Lista de componentes do CDH selecionados para instalação...............................................83 Tabela 17 – Requisitos do projeto...........................................................................................................87 Tabela 18: Reuniões de Acompanhamento.............................................................................................95
  11. 11. Processamento distribuído de grandes blocos de dados xi Notação e Glossário ACID Atomicidade, Consistência, Integridade e Durabilidade API Application Programming Interface BASE Basically Available, Soft state, Eventual consistency Batch Processing Técnica de processamento caracterizada por o tratamento de um grande volume de dados Blobs Binary Large Objects CAP Consistency, Availability, Partition tolerance CBO Cost-based optimization CLI Command Line Interface Commodity Hardware Equipamento informatico considerado banal e de desempenho muito infe- rior quando comparado com servidores recentes CPU Central Processing Unit DAG Directed acyclic graph Data Warehouse Repositório de dados que possibilita a análise um grande volume de dados DML Data Manipulation Language ETL Extract Transform Load Framework Ambiente de produção de código reutilizavél como parte integrante de uma solução maior Hardware Equipamento informatico HDFS Hadoop Distributed File System HiveQL Hive Query Language HQL Hive Query Language JDBC Java Database Connectivity
  12. 12. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães xii JSON JavaScript Object Notation Logs Ficheiro com registos de eventos ou medições MOLAP Multidimensional On Line Analytical Processing NoSQL Not only SQL OLAP On Line Analytical Processing OLTP On Line Transaction Processing
  13. 13. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 1 1 Introdução O modelo relacional apresentado em 1970 por E.F. Codd foi uma revolução. Passou-se de um sistema de ficheiros arcaico, complexo de gerir, para um sistema de tabelas, que garantia consistência de forma transparente ao utilizador, com uma linguagem de manipulação de dados semelhante à natural (Codd, 1970). Com o aparecimento da Internet e a relativamente recente massificação de serviços que esta fornece, tem-se assistido a um explosivo crescimento dos seus conteúdos, bem como a uma utilização sem precedentes de uma quantidade gigantesca de informação. Do ponto de vista técnico, acompanhar este crescimento é um desafio, devido a fatores como volume, velocidade, exigência de disponibilidade e flexibilidade. O modelo de Codd foi desenhado para colmatar um problema muito diferente daquele que foi descrito anteriormente, pois, apesar de fornecer uma excelente ideologia para armazenamento de dados, não está preparado para abarcar os maiores desafios da era atual. Temos por isso assistido a um crescente aparecimento de novas tecnologias, que para além de outras características, permitem a persistência de dados de forma cooperativa e paralela, distribuindo o trabalho computacional por diversas máquinas. Este movimento representa o aparecimento de uma nova categoria de bases de dados não relacionais, que se caracterizam pela sua alta escalabilidade horizontal e esquema de representação de dados livre. Existem no entanto limitações: o modelo de consistência é relaxado, e, na sua maioria, estas tecnologias não contemplam suporte total das propriedades ACID. Este compromisso na consistência garante ao sistema uma melhoria franca de performance e ao mesmo tempo facilita a sua distribuição (Sadalage & Fowler, 2012). Tendo como base estas tecnologias, o objetivo deste trabalho é fazer um estudo de implementação num ambiente de produção com necessidade de armazenamento e análise de grandes volumes de dados.
  14. 14. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 2 1.1 Apresentação do projeto/estágio Atualmente, são usadas bases de dados multidimensionais para o armazenamento e análise de dados provenientes de uma grande variedade de fontes, contudo, a sua manutenção é muito dispendiosa e requer computadores potentes para operar. Existem muitas tecnologias que apresentam características interessantes para a solução deste problema, enquadram-se na área das bases de dados NoSQL e serão o alvo de estudo durante todo o projeto. A solução pretendida visa oferecer uma plataforma de armazenamento distribuída de alta performance e escalabilidade, capaz de correr num conjunto de máquinas banais, interligadas entre si. A solução deverá também dispor de uma interface semelhante ao modelo atual, permitindo extrair informação dos dados recolhidos usando linguagens declarativas como o SQL, aproveitando assim, do melhor modo, o vasto conhecimento dos colaboradores nesta tecnologia.
  15. 15. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 3 1.1.1 Planeamento de projeto O planeamento do projeto foi definido numa fase prematura do levantamento do estado de arte, por isso, foram definidas tecnologias para estudo que mais tarde se revelaram complementares a outras ou não indicadas para a solução. No entanto, foram abordadas ferramentas que não faziam parte do planeamento inicial mas que passaram a fazer parte do plano de estudos devido às suas caraterísticas. Em seguida é apresentado o documento inicialmente idealizado. Tabela 1 – Planeamento do projecto TAREFA DURAÇÃO INICIO FIM 1 PROJECTO 110 dias 09/03/2015 07/08/2015 1.1 LEVANTAMENTO DO ESTADO DE ARTE 23 dias 09/03/2015 08/04/2015 1.1.1 CONCEITOS GERAIS 9 dias 09/03/2015 19/03/2015 1.1.2 TECNOLOGIAS NOSQL 14 dias 20/03/2015 08/04/2015 1.2 ENQUADRAMENTO DAS TECNOLO- GIAS NOSQL AO PROBLEMA 25 dias 09/04/2015 13/05/2015 1.2.1 CASSANDRA 5 dias 09/04/2015 15/04/2015 1.2.2 MONGODB 5 dias 16/04/2015 22/04/2015 1.2.3 HADOOP 10 dias 23/04/2015 06/05/2015 1.2.4 HIVE 5 dias 23/04/2015 29/04/2015 1.2.5 HBASE 5 dias 30/04/2015 06/05/2015 1.2.6 RIAK 5 dias 07/05/2015 13/05/2015 1.2.7 PRODUÇÃO DE DOCUMENTAÇÃO 25 dias 09/04/2015 13/05/2015 1.3 INSTALAÇÃO, CONFIGURAÇÃO E TESTE DAS TECNOLOGIAS NOSQL NUM CLUSTER 59 dias 14/05/2015 04/08/2015 1.3.1 CASSANDRA 11 dias 14/05/2015 28/05/2015 1.3.2 MONGODB 11 dias 29/05/2015 12/06/2015 1.3.3 HADOOP 26 dias 15/06/2015 20/07/2015 1.3.4 HIVE 13 dias 15/06/2015 01/07/2015 1.3.5 HBASE 13 dias 02/07/2015 20/07/2015 1.3.6 RIAK 11 dias 21/07/2015 04/08/2015 1.3.7 PRODUÇÃO DE DOCUMENTAÇÃO 59 dias 14/05/2015 04/08/2015 1.4 ELABORAÇÃO DO RELATÓRIO 28 dias 01/07/2015 07/08/2015
  16. 16. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 4 1.1.2 Reuniões de acompanhamento No decorrer do projeto foram ocorrendo várias reuniões, no entanto, nenhuma delas foi agendada no planeamento, visto que ocorriam sempre que necessário e sem necessidade de agendamento, (à exceção das reuniões com o orientador do ISEP), uma vez que todos os dias tomava contacto com o supervisor, que apesar de ter as suas próprias tarefas dentro da empresa, sempre negociou com relativa facilidade uma reunião. Estes momentos de debate foram cruciais para o desenvolvimento deste projeto pois, uma vez que era de cariz exploratório, não havia uma lista de objetivos específicos a cumprir definidos à partida, tendo estes sido moldados de reunião para reunião. A listagem completa das reuniões pode ser consultada na Tabela 18 do Anexo A. 1.2 Apresentação da organização A CRITICAL Manufacturing proporciona às indústrias de produção discreta uma solução de gestão e controlo de produção que capacita as unidades fabris para alcançarem os seus objetivos. Detalha as operações, facilita a visibilidade sobre os processos e custos refletidos na cadeia de abastecimento e é de fácil implementação nas infraestruturas já existentes. Como resultado, os seus produtos e serviços facilitam uma redução contínua de custos, a flexibilidade necessária para satisfazer a procura e sobretudo capacitam a organização de uma maior agilidade, visibilidade e fiabilidade. 1.3 Contributos deste trabalho O estudo efetuado durante o período de estágio permite à organização ter uma ideia clara das tecnologias NoSQL que melhor se encaixam nas suas necessidades. Visa dar a conhecer características como desempenho, query model, facilidade de uso e escalabilidade. A construção e teste de protótipos das tecnologias candidatas permitirá avaliar o impacto da implementação das mesmas num ambiente de produção. A tecnologia escolhida permitirá recolher diariamente, e de forma automática, uma quantidade considerável de dados. O sistema deverá suportar queries SQL básicas sobre quantidades gigantescas de dados, trabalho que não é possível realizar tão rapidamente, ou de todo, numa base de dados relacional.
  17. 17. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 5 1.4 Organização do relatório O presente documento está organizado em cinco capítulos: Introdução, Contexto, Tecnologias e Ferramentas, Descrição Técnica e Conclusões. No primeiro capítulo (Introdução) é apresentada a instituição onde foi realizado o estágio e é feita uma contextualização do problema a resolver através do estudo. No capítulo “Contexto” são apresentados os conceitos chave que fundamentam as ferramentas testadas ao longo do projeto, sendo também efetuado um levantamento do estado da arte. Já no capítulo intitulado “Tecnologias e Ferramentas”, são apresentadas as principais ferramentas identificadas para a solução do problema bem como descritas as tecnologias que as suportam. No capítulo seguinte são apresentados os detalhes de instalação e configuração das ferramentas consideradas para teste que, de alguma forma, satisfazem o requisito no qual estão enquadradas. Em “Conclusões” é avaliada a mais-valia da solução, descritos principais contratempos e problemas encontrados ao longo do projeto e são, ainda, sugeridas algumas abordagens para possível trabalho futuro.
  18. 18. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 6
  19. 19. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 7 2 Contexto Dado o problema em causa, foi necessário realizar um levantamento das tecnologias disponíveis, tendo em conta as suas limitações e vantagens face aos requisitos da solução final. Todos os conceitos de relevância que surgiram durante o estudo serão abordados em pormenor nesta secção. 2.1 Introdução Na produção industrial é cada vez mais importante recorrer-se a novas tecnologias para aumentar a competitividade. A Internet das coisas aplicada ao chão de fábrica permite às empresas um aumento da qualidade, eficiência sem que seja necessária uma remodelação do negócio. Milhares de sensores recolhem dados que são analisados em tempo real, permitindo traçar métricas de qualidade, ter controlo sobre a produção e inclusive cumprir e monitorizar requisitos legais, como é o caso da área de produção de dispositivos médicos, que exige a salvaguarda dos dados recolhidos durante a produção por um período de tempo até quinze anos. Para satisfazer a necessidade de armazenamento de grandes volumes de dados estruturados, semiestruturados e não estruturados é necessário um sistema que seja capaz de os ingerir, persistir e inquirir em tempo útil.
  20. 20. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 8 2.2 Modelo Relacional Desde que existem sistemas informáticos sempre houve necessidade de armazenar informação. Primeiramente em simples fitas de papel perfurado que eram dadas como output de um programa, e mais tarde em grandes discos magnéticos, onde a informação era persistida em formato digital. Os computadores evoluíram até ao ponto em que eram potentes o suficiente para servir vários utilizadores em simultâneo, surgia contudo um problema, não era possível dois utilizadores alterarem o mesmo ficheiro ao mesmo tempo. Estes ficheiros podiam conter milhares de linhas, com informação não estruturada difícil de manipular. Em 1970 E.F. Codd sugeriu um modelo relacional que visava melhorar três aspetos dos sistemas daquela altura, primeiro, a maneira como os dados eram representados (estrutura de dados), segundo, que dados são permitidos (integridade dos dados), e por último, que alterações podem ser feitas sobre os dados (manipulação de dados). Com este modelo os utilizadores podiam alcançar a informação que procuravam através de uma linguagem declarativa, composta por operações lógicas, sem necessidade de conhecer a estrutura de ficheiros do sistema (Codd, 1970). A IBM desenvolveu o primeiro protótipo deste modelo em 1974, apelidado de “System R”, este viria mais tarde a tornar-se no tão conhecido SQL. Em 1979 a Oracle foi a primeira a apresentar uma solução comercial baseada no trabalho de Codd e o seu sistema (Relational Software, Inc.) dominou o mundo das bases de dados durante os anos vindouros (Stephen, 2014). O paradigma atual da informação é muito diferente daquele encontrado aquando da criação do modelo relacional. A quantidade de dados armazenada e tratada diariamente supera a capacidade funcional das bases de dados relacionais. O maior problema deste modelo é a fraca escalabilidade horizontal e os overheads associados às transações (Harizopoulos, Abadi, Madden, & Stonebraker, 2008). Embora se possam criar caches para escritas mais rápidas, replicar os dados por máquinas escravas para efetuar leituras em paralelo, aumentar o poder da máquina principal adquirindo uma nova com mais núcleos de processamento, mais RAM, discos mais rápidos, normalizar os dados, criar índices, pré-computar queries etc. (George, 2011). Na prática o que se observa é que o aumento do poderio dos recursos físicos não é proporcional ao desempenho operacional ganho, tendo tendência a estagnar, tornando-se inviável (Pooley et al., 2013).
  21. 21. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 9 2.3 BigData e Business inteligence, o valor do armazenamento de dados A recolha de dados sempre foi um aspeto importante para a evolução de uma determinada atividade. Já no seculo IX se recolhiam dados sobre a navegação marítima, eram registados a bordo a direção e intensidade do vento, as horas de sol, a data, eventos anormais avistados, entre outros. Milhões de notas manuscritas sem critério rigoroso, de forma não estruturada e muitas vezes em texto corrido ou em prosa, foram registadas pelos capitães. Mas só mais tarde no seculo XX viriam a ser analisadas. O oficial da marinha americana Matthew Fontaine Maury efetuou a mineração dos logs narrativos, transformando-os em informação estruturada e categorizada, um processo de extração moroso e colossal (“Process Mining: The Objectification of Gut Instinct,” 2013). A análise da informação recolhida veio mostra-se muito valiosa, foi possível calcular as melhores rotas para os barcos tendo em conta as marés, a localização dos melhores ventos em dada altura do ano, etc. Uma viagem de São Francisco para Nova Iorque que antes demorava em média 150 dias podia agora ser navegada num tempo recorde de 89 dias. Estima-se que o trabalho de Matthew tenha poupado na altura cerca de 10 milhões de dólares por ano à indústria náutica, sendo que o seu trabalho se repercute para os dias de hoje (Zimmermann, 2004). Atualmente, como foi anteriormente referido, existe uma proliferação de equipamentos ligados à grande rede, que emitem dados continuamente. Já não se trata da análise de milhares de registos por ano mas sim de milhões de sinais por segundo, toda esta quantidade de informação é armazenada com a esperança de detetar anomalias, descobrir melhorias num determinado procedimento, economizar recursos, prever tendências antes de estas ocorrerem, entre outros, tudo isto no menor intervalo de tempo possível.
  22. 22. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 10 2.4 ACID vs. BASE Um sistema de base de dados fornece um conjunto de ações que permite manipular e alterar os dados nele contido de tal forma que este transite de um estado consistente para um novo estado que respeite o modelo de consistência (gray, 1981). Contudo nos sistemas distribuídos este requisito é complexo de alcançar de uma forma eficiente devido à concorrência das operações e ao modo como o modelo ACID materializa estas operações em transações. A tecnologia NoSQL foi projetada para alto débito de dados recorrendo a várias máquinas distribuídas e, para tal, foi necessário abandonar o rígido modelo de transações ACID e adaptar algo mais flexível, surgindo assim o modelo BASE. Nesta secção serão abordados os principais conceitos dos dois modelos, analisando as suas vantagens e os seus propósitos. 2.4.1 ACID ACID é acrónimo de Atomicidade, Consistência, Integridade e Durabilidade, sendo que este modelo de consistência garante que as transações ocorrem de uma forma fiável, desde que respeitem as propriedades que seguidamente serão descritas. Atomicidade Uma transação é constituída por um conjunto de instruções, se alguma destas falhar toda a transação deve ser cancelada seguindo a filosofia de tudo ou nada. Esta regra permite garantir a atomicidade, exigindo assim que todas as operações de uma transação tenham sucesso para que esta se torne efetiva, caso contrário a base de dados manter-se-á inalterada. Consistência A Consistência é uma propriedade que garante que uma transação faz transitar a base de dados de um estado para outro conservando a validade. Toda a informação escrita na base de dados tem de ser validada de acordo com as regras definidas, caso ocorra uma falha qualquer alteração será automaticamente revertida para manter assim o estado de consistência. Isolamento A propriedade de isolamento assegura que a execução de várias transações de modo concorrente resulta num estado de sistema que seria obtido se as mesmas fossem executadas sequencialmente (serialização). As transações só garantem a consistência do sistema quando terminam. Se estas não fossem isoladas, seria possível aceder a informação inválida de uma outra transação que acabou por falhar.
  23. 23. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 11 Durabilidade A durabilidade é a propriedade que garante que, após uma transação ser concluída, o seu resultado deve permanecer no sistema, o que deve acontecer mesmo que ocorra uma falha de software ou hardware. 2.4.2 Teorema de CAP Em meados dos anos noventa, com o crescimento da Internet, os problemas previamente estudados sobre a dificuldade dos sistemas distribuídos mostraram-se extremamente pertinentes (Mohan & Lindsay, 1983). Nessa altura, as pessoas começaram a valorizar a ideia de um sistema sempre disponível, tornando-se esta a caraterística potencialmente mais importante. No entanto, a disponibilidade teria sempre um custo associado, havendo a necessidade de negligenciar outros pontos do sistema. Conjeturado por Eric Brewer (E. A. Brewer, 2000), e formalmente confirmado por Seth Gilbert e Nancy Lynch, o teorema de CAP veio mostrar que em sistemas distribuídos existem três propriedades altamente desejáveis: Consistência, disponibilidade (Availability) e tolerância ao Particionamento, mas que as três propriedades nunca podem coexistir em simultâneo, apenas duas podem ser satisfeitas (Gilbert & Lynch, 2002). Figura 1 – Gráfico demonstrativo da relação do volume de pesquisas dos termos Cap theorem, NoSQL e Cloud Computing Fonte: http://goo.gl/acw0XT Sendo as bases de dados NoSQL maioritariamente sistemas distribuídos, o teorema de CAP tem uma implicação intrínseca no modo como estas são projetadas. Esta relação entre
  24. 24. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 12 sistemas de bases de dados distribuídos e o teorema de CAP pode ser observada na Figura 1. Serão seguidamente definidas as caraterísticas deste teorema. Consistência Num sistema distribuído todos os nós devem ver os mesmos dados ao mesmo tempo, desta forma, o sistema deve garantir que a informação é consistente em todos os nós de forma síncrona. Disponibilidade Esta característica dita que todos os pedidos ao sistema devem ter sucesso e originar uma resposta. Como se trata de um sistema distribuído e existem dados replicados, a falha de um nó não deve afetar o funcionamento dos restantes, tornando assim o sistema altamente disponível e tolerante a falhas. Tolerância ao Particionamento A tolerância ao particionamento implica que uma falha no canal de comunicação entre nós não afete o normal funcionamento do sistema, se este não suportar particionamento, os nós ficam isolados e não conseguem anunciar as modificações de escrita aos restantes, resultando em inconsistência de dados. Pares CAP Do teorema de CAP surgem três pares de propriedades possíveis: Figura 2 – Modelos de consistência de sistemas distribuídos Fonte: http://blog.imaginea.com/wp-content/uploads/2013/09/cap.jpg
  25. 25. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 13  Consistência e tolerância ao particionamento comprometendo a disponibilidade (CP). No caso de uma ligação entre nós falhar, o sistema ficará indisponível por um período de tempo até que seja restaurada a comunicação entre estes. Apresenta-se em seguida o exemplo de Martin Fowler para melhor ilustrar este conceito. No mesmo instante, dois amigos em pontos diferentes do globo tentam reservar um quarto no mesmo hotel, estes acedem a servidores distintos que perderam temporariamente a comunicação entre eles. Como os nós não conseguem comunicar, o sistema descarta automaticamente todas as reservas feitas nesse intervalo de tempo uma vez que não sabe que quartos foram reservados nos outros servidores. Desta forma evitam-se reservas duplicadas e registos ambíguos (Sadalage & Fowler, 2012).  Tolerância ao particionamento e disponibilidade, comprometendo a consistência (AP). Este sistema caracteriza-se por ser altamente disponível, responde a todos os pedidos, potencialmente retornando dados desatualizados e aceita escritas conflituosas. Dependo do contexto de negócio esta solução pode ser muito rentável. Imaginando novamente o exemplo acima referido, é muito mais vantajoso o hotel aceitar as duas reservas e lidar com as inconsistências mais tarde (Sadalage & Fowler, 2012).  Disponibilidade e consistência comprometendo tolerância a partição (CA).Originalmente considerada por Brewer no seu teorema, esta propriedade, veio a revelar-se incoerente, uma vez que se o sistema é distribuído e não tolerante ao particionamento, então, por omissão, será forçado a relaxar a consistência ou a disponibilidade. Surgiu assim uma renovada visão do teorema, que diz que durante uma partição de rede, um sistema distribuído só pode escolher consistência ou disponibilidade (E. Brewer, 2012). 2.4.3 BASE Tal como o nome sugere, este paradigma é a antítese do modelo ACID que segue uma filosofia pessimista de consistência absoluta. Basically Available, Soft state, Eventual consistency dá prioridade à disponibilidade da informação delegando a consistência para um estado transitivo de maturação (Pritchett, 2008). Basicamente disponível (Basically Available). Um sistema garante a disponibilidade dos dados seguindo o teorema de CAP. Não obstante, como foi visto anteriormente, a resposta poderá ser de falha ou inconsistência, pois os dados estão inconsistentes ou em estado de mudança (Celko, 2014). Estado flexível (Soft state). O estado do sistema pode alterar ao longo do tempo, por isso, mesmo durante períodos sem atualizações implícitas, os dados podem mudar, devido ao
  26. 26. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 14 estado eventual de consistência. Assim, o sistema é visto como flexível em oposição a um sistema rígido, onde o valor dos dados é garantido (Celko, 2014). Existem duas formas de encarar a consistência. Uma é do ponto de vista do developer/cliente, a maneira como estes observam os updates. Outra é do lado do servidor, que incide no modo como os updates fluem pelo sistema as garantias que este dá em relação às atualizações dos dados (Vogels, 2009). Os componentes do lado do cliente genericamente são:  Um sistema de armazenamento, de larga escala e altamente distribuído, garantindo encapsulamento, durabilidade e disponibilidade.  Processo A. Este processo escreve e lê do sistema de armazenamento.  Processo B e C. Estes dois processos são independentes de A e efetuam leituras e escritas no sistema de armazenamento. É irrelevante se são lançados no sistema como threads dentro do mesmo programa, o importante é que são independentes e precisam de comunicar entre si para trocar informação. A consistência do lado do cliente é descrita pelo momento e pela maneira como os processos supra citados veem os updates feitos aos objetos no sistema de ficheiros. De seguida são apresentados exemplos que ilustram os diferentes tipos de consistência. Partindo do principio que A efetuou uma alteração num campo de dados de um objeto: Consistência Forte (Strong consistency). Após concluir um update, qualquer acesso subsequente por A, B ou C retornará o valor atualizado. Consistência fraca (Weak consistency). O sistema não garante que os acessos subsequentes retornem o valor atualizado. Um certo número de condições tem de ser alcançado para que esse valor seja devolvido. O período de tempo entre a alteração e o momento em que é garantido que qualquer observador acede ao valor mais atual é chamado de janela de inconsistência (inconsistency window). Eventualmente Consistente (Eventual consistency) - A consistência eventual é um modelo específico de consistência fraca, parte do princípio de que se nenhuma alteração for feita a um determinado valor, então, eventualmente todos os acessos ao mesmo retornarão a sua ultima atualização. Se nenhum erro ocorrer, a duração máxima da janela de inconsistência pode ser determinada com base em fatores como a carga do sistema, a latência da rede, o número de réplicas, entre outros (Vogels, 2009).
  27. 27. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 15 Este modelo tem algumas variantes apresentadas em seguida: Causal consistency - Se um processo A fizer alterações a um determinado valor e informar B, então, sempre que B aceder a este valor receberá sempre os dados mais atualizados, por sua vez é garantido que as escritas por parte de B substituem o antigo valor mantendo a consistência. Se um processo não for informado sobre alterações e tentar aceder ao valor este acesso será regido por uma consistência eventual. Read Your Writes consistency - Sempre que um valor é atualizado todas as subsequentes operações de leitura retornarão o valor atualizado. Session consistency - É uma variante de Read your writes, nesta versão as atualizações são sempre vistas apenas pelos processos que as fizeram Monotonic reads - Quando um processo acede a um valor pela primeira vez, este é considerado como o mais atual, qualquer leitura subsequente do mesmo nunca retornará um valor mais antigo. Monotonic writes - Quando um processo efetua uma operação de escrita pela primeira vez, num determinado campo, este é considerado o mais atual, qualquer operação de escrita seguinte apenas será efetuada se o valor guardado for mais antigo. Consistência do ponto de vista do servidor Num sistema de base de dados distribuído, a replicação aumenta a disponibilidade dos dados e a velocidade de processamento das queries. Contudo, a replicação torna muito mais complexa a maneira como as atualizações dos dados são processadas, especialmente quando na presença de uma falha nos nós ou de um particionamento na rede (Skeen, 1982). Um protocolo de gestão de replicação garante a serialização das operações, isto é, nunca duas atualizações concorrentes podem alterar os mesmos dados, no mesmo instante (Gifford, 1979). Do lado do servidor os dados podem estar replicados por todos ou apenas por alguns nós. Se todos os n nós acordarem no valor de um campo, então teremos a certeza da sua veracidade. Quando os nós comunicam entre si para chegar a um consenso sobre um valor atualizado é necessário saber que nós já têm a versão mais recente dos dados e quais aqueles que ainda não deram qualquer resposta. Este é uma regra básica de quórum que nos permite detetar nós em falha e replicações incompletas. Estas regras podem variar consoante o modelo de negócio, uma aplicação a correr num banco poderá exigir uma replicação pela totalidade dos nós para que esta seja efetiva. Um carrinho de compras abandonado pode ser revisitado em qualquer nó do servidor, mesmo que seja
  28. 28. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 16 uma versão mais antiga do carinho, o cliente pode facilmente voltar a inserir os produtos em falta. O sistema só tem de assegurar, no momento de checkout, que todas as versões replicadas pelos nós são atualizadas para o último estado (Lam, 2011). 2.5 NoSQL Devido à sua dimensão, a Google foi uma das primeiras empresas a deparar-se com as sérias limitações das bases de dados relacionais. Obviamente não existiam ainda opções comerciais para resolver este conjunto de problemas tecnológicos, por isso, eles próprios inventaram e desenvolveram novas estratégias para gestão dos seus dados. Google File System (Ghemawat, Gobioff, & Leung, 2003), MapReduce (Dean & Ghemawat, 2004), Chubby (Burrows, 2006), BigTable (Chang et al., 2006) foram projetos pioneiros de grande sucesso, e a sua divulgação despertou um enorme interesse devido ao crescente número de companhias que mais tarde ou mais cedo acabavam por se defrontar com as mesmas barreiras. Com base nestes projetos, uma panóplia de software open-source emergiu rapidamente, assim nascia o fenómeno NoSQL. A capacidade de distribuir trabalho por milhares de máquinas de baixo custo confere a este tipo de sistemas um poder enorme de ingestão e processamento de dados. Existem contudo outras vantagens. Na sua generalidade, as tecnologias NoSQL possibilitam um armazenamento de informação estruturada e não estruturada sem restrições quanto ao tipo de dados (schema free), ao contrário das RDBMS a estrutura é definida em tempo de leitura e não de escrita, uma vantagem soberba para ambientes em que o modelo de dados se encontra em constante mutação. Dada a sua implementação em código aberto, na sua maioria não comercial, e o facto de ser funcional em máquinas banais (commodity hardware), o NoSQL representa uma alternativa muito económica face aos produtos de bases de dados relacionais (Vaish, 2013). A fim de avaliar os conceitos tecnológicos adjacentes ao software disruptivo NoSQL foi feito um levantamento do estado de arte que será apresentado em seguida.
  29. 29. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 17 3 Tecnologias e Ferramentas 3.1 Apache Hadoop O Hadoop foi criado por Doug Cutting, as suas origens estão relacionadas com Apache Nutch (Cutting & Cafarella, 2003), um motor de pesquisa open source que integrava o projeto Lucene (Cutting, 1999). Do ponto de vista técnico, Hadoop é uma framework de código aberto, com dois componentes chave, HDFS (Hadoop Distributed File System) e MapReduce na sua versão 1.0 e HDFS mais YARN na versão 2.0. Este par de tecnologias base permite o desenvolvimento e execução de aplicações para processamento distribuído de dados em massa de forma simples (Lam, 2011). O Hadoop assenta na categoria de computação distribuída, focando-se nos seguintes aspetos: Acessibilidade- Trata-se de uma tecnologia que pode operar sobre um grande conjunto de máquinas banais (commodity hardware) ou na cloud. Robustez- Pensado para trabalhar em ambientes compostos por várias máquinas de baixo custo, este consegue controlar de forma eficaz inevitáveis problemas de hardware. Escalabilidade- O aumento de número de nós afeta de forma linear o desempenho efetivo das aplicações. Simplicidade- Permite aos utilizadores escrever código paralelo de forma eficiente, sem preocupações de concorrência ou bloqueios típicos da computação paralela. Dada a sua procura, e características desejáveis, como escalabilidade e robustez, o Hadoop evoluiu rapidamente, tornando-se uma referência no processamento distribuído. Por forma a tirar partido destas características, o Hadoop foi acolhendo novos projectos, que para além de solucionarem um leque cada vez maior de problemas, baixavam a barreira de entrada nas tecnologias NoSQL. Tendo por base a mascote Hadoop, as ferramentas escolheram o seu nome inspirando-se num animal, tendo como critério algo que descrevesse a sua finalidade. Projetos complementares ou de menor importância têm normalmente nomes banais. Dada a vasta quantidade de ferramentas das quais uma amostra pode ser observada na Figura 3, este princípio tem como intuito facilitar, numa primeira abordagem, a utilidade da ferramenta ou o seu grau de importância no ecossistema Hadoop.
  30. 30. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 18 Figura 3 – Esquema representativo de parte do ecossistema Hadoop Fonte: http://www.neevtech.com/blog/wp-content/uploads/2013/03/hadoop.png 3.2 HDFS O HDFS é o Sistema de Ficheiros usado no Hadoop, inspirado no GFS (Google File System) (Ghemawat et al., 2003), tornou-se um dos aspetos chave do sucesso do Hadoop. Desenhado para armazenar grandes blocos de dados de forma distribuída em discos de baixo custo, o HDFS proporciona um excelente desempenho na capacidade acumulada de escrita e leitura tornando-o a escolha indicada para projetos Big-Data. Apesar de se ter assistido a uma evolução acentuada da capacidade dos discos rígidos as suas velocidades de escrita e de leitura tenderam a estagnar, não acompanhando o tamanho gigantesco, na prática existe capacidade para armazenar informação mas não para a consultar em tempo útil, tirando por isso o propósito do seu armazenamento. Este sistema de armazenamento de dados diferencia-se dos convencionais por possuir características que o tornam operável de forma distribuída num grande conjunto de máquinas interligadas por uma rede (DataNodes). O facto de ser distribuído tem implicações que foram referidas anteriormente no capítulo sobre a consistência, obrigando o HDFS a relaxar alguns dos requisitos POSIX (Borthakur, 2013).
  31. 31. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 19 Os principais objetivos e características diferenciadoras do HDFS são: Tolerância a falhas As falhas de Hardware são uma exceção, mas quando lidamos com um grande número de máquinas, a exceção facilmente passa a regra. Sendo o HDFS um sistema criado para funcionar em milhares de máquinas, este implementa, de raiz, uma serie de mecanismos para deteção de falhas, recuperação rápida e automática. Acesso a dados O HDFS foi desenhado para um acesso em bloco aos seus dados, dando enfase à leitura de grandes volumes de informação, ao invés de um uso interativo de baixas latência. A norma POSIX impõe requisitos rígidos maioritariamente desnecessários para os casos de uso do HDFS, por isso, como forma de obter o máximo desempenho, o HDFS não cumpre esta norma na totalidade. Armazenamento de ficheiros de grande dimensão Os ficheiros armazenados no HDFS terão por norma um tamanho compreendido entre o giga e o terabyte, paradigma bastante diferente dos sistemas de ficheiro convencionais. O HDFS foi desenhado para suportar milhões destes ficheiros, mantendo a largura de banda agregada e escalar por inúmeros nós. Modelo de coerência simples O HDFS segue o modelo write-once-read-many para acesso à informação, uma vez criado, um ficheiro não precisará de ser alterado. Este modelo simplifica os problemas abordados anteriormente, no capítulo de consistência, e permite ganhos de performance consideráveis. Movimentar poder de computação é mais barato do que movimentar dados Uma operação computacional é tanto mais eficaz quanto mais próxima estiver da sua fonte de dados, isto porque a velocidade da rede é muito inferior à velocidade de leitura em disco. Quanto maior for o tamanho dos ficheiros a movimentar e o numero de pedidos, maior será o congestionamento da rede, é por isso preferível mobilizar o poder de computação para próximo dos dados em vez do contrário. O HDFS disponibiliza às aplicações que sobre ele correm uma interface que lhes dá a possibilidade de deslocação para a máquina onde a informação está armazenada, recorrendo também a replicação de informação de forma a facilitar a paralelização e a tolerância a falhas.
  32. 32. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 20 3.3 MapReduce O MapReduce é um modelo de programação cujo conceito já existia desde a década de 90 (Gropp, Lusk, & Thakur, 1999), contudo, apenas em 2004 pelas mãos da Google se viria a materializar (Dean & Ghemawat, 2004). Foi desenvolvido com vista ao processamento de um enorme volume de dados, em concreto para um sistema de indexação de páginas web. Este modelo permite o desenvolvimento de aplicações automaticamente distribuídas por um múltiplo número de máquinas, sem que o programador tenha de se preocupar com problemas de paralelização, sincronização e distribuição. Em termos gerais, o conceito MapReduce resume-se a duas tarefas principais, Map e Reduce. A primeira é processada em paralelo por todos os nós do cluster e consiste na divisão de dados em pares chave-valor, a fase de reduce agrega todos os pares com a mesma chave e efetua operações sobre o valor. Em seguida pode ver-se um exemplo trivial destas duas funções basilares, o programa apresentado faz a contagem do número de palavras de um documento. map(String key, String value): // key: nome do documento // value: conteúdo do documento for each word w in value: EmitIntermediate(w, "1"); reduce(String key, Iterator values): // key: uma palavra // values: número de vezes que a palavra foi contada int result = 0; for each v in values: result += ParseInt(v); Emit(AsString(result)); Após a disponibilização ao público do artigo do Google que dava a conhecer as potencialidades do seu sistema, várias foram as implementações open-source que lhe seguiram, a mais conhecida será indiscutivelmente a do Hadoop. Tomando como caso de estudo a tecnologia MapReduce do Hadoop, veremos de seguida cinco etapas distintas características desta implementação (Loshin, 2013).
  33. 33. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 21 Preparação de dados Na primeira fase o bloco de dados é dividido em peças mais pequenas, normalmente de 128Mb (tamanho default do Block Size do sistema de ficheiros distribuído do Hadoop). A cada porção de dados é atribuída uma operação de Mapeamento. Mapeamento Nesta operação os nós começam então a agrupar a informação em pares chave-valor. Tal como pode ser observado na primeira coluna da Figura 4. Organização Todas as operações de mapeamento ocorrem em simultâneo e de forma distribuída, por isso, ao longo do tempo, vão-se formando grupos de chaves iguais, particionadas pelos diversos nós. É necessário agrupar todas as ocorrências de chaves idênticas na mesma lista, para garantir que a função seguinte opera sobre todos os valores de uma certa chave, e não apenas uma fração. Figura 4 – Fase de mapeamento do algoritmo mapreduce Fonte: http://www.secureboot.org/wp-content/uploads/2015/02/mapreduce.png Redução É feita uma redução por cada chave distinta resultante da operação anterior. A redução consiste na execução de uma operação ao conjunto de valores da chave, a mais comum é a soma, como se pode ver no exemplo da Figura 5, todos os valores apurados para a chave “price” são somados.
  34. 34. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 22 Figura 5 – Fase de redução do algoritmo mapreduce Fonte: http://www.secureboot.org/wp-content/uploads/2015/02/mapreduce.png Escrita Por fim, os resultados são combinados em ficheiros “partN”, um por cada redutor, e são guardados no HDFS. De um modo geral, o fluxo de informação entre estas etapas pode ser observado na Figura 6. Figura 6 – Fluxo de informação entre as etapas de map, shuffle e reduce Fonte: http://sci2s.ugr.es/sites/default/files/files/TematicWebSites/BigData/mr.png Para além de plataforma de programação, o Hadoop atribuiu ao MapReduce a responsabilidade de gestão de recursos e escalonamento de tarefas. Este acoplamento viria
  35. 35. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 23 demonstrar-se uma má implementação, forçando os programadores a más práticas. A centralização da gestão das tarefas mostrou-se uma limitação à escalabilidade do sistema (Vavilapalli et al., 2013). Processamento em tempo real, computação de grafos, computação interativas, queries em tempo real, entre outros, todos eles exemplo de um crescente número de casos de uso para os quais o Hadoop não conseguia dar resposta. Era necessário um novo sistema que permitisse ao utilizador correr várias frameworks de processamento distribuído no mesmo cluster e fazer uso do potente sistema de armazenamento HDFS (Gunarathne, 2015). Esse sistema foi alcançado e tomou o nome de YARN, será detalhado no capítulo seguinte. 3.4 Apache YARN YARN (Yet Another Resource Negotiator), trata-se de um sistema de gestão de recursos que permite eficazmente partilhar o poder de computação e armazenamento de um cluster Hadoop entre várias frameworks de processamento distribuído. O YARN é um componente central no ecossistema Hadoop, ao fornecer uma interface comum a vários tipos de aplicações distribuídas dá ao utilizador a capacidade de correr quer trabalhos batch, interativos, de streaming, entre outros, sobre um único cluster (Gunarathne, 2015). A Figura 7 descreve uma arquitetura alto nível do YARN. Figura 7 – Arquitetura do Hadoop 2.0 descrevendo os componentes do sistema YARN Fonte: http://3.bp.blogspot.com/-PzcFAXPdl1Q/U8LJt2rJjDI/AAAAAAAABX0/fXD54m758zs/s1600/yarn-arc.png
  36. 36. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 24 O ResourceManager é um processo central do YARN, responsável pelo escalonamento de tarefas, este gere e aloca recursos para as aplicações submetidas no cluster. O ResourceManager aloca recursos em resposta aos pedidos das aplicações. Toma em consideração as capacidades do cluster bem como todas as regras que podem ser explicitamente especificadas através do YARN policy plugin framework (Gunarathne, 2015). O YARN NodeManager é um processo que corre individualmente em cada nó e tem como função vigiar os recursos e monitorar a evolução do trabalho na máquina em que está a correr. De modo a simplificar a alocação de recursos para um número flexível de máquinas, o YARN tem o conceito de container (contentor), é uma unidade mínima de alocação de recursos. Para cada container alocado, é reservada uma percentagem de CPU e memória num nó em particular. As aplicações podem pedir recursos ao YARN especificando o número de contentores, memória, e CPU necessários para cada um desses contentores (Vavilapalli et al., 2013). O ApplicationMaster é um processo iniciado sempre que uma aplicação é submetida, este é responsável pela gestão dos recursos que a aplicação necessita a cada instante, com base nisso, efetua pedidos de containers ao ResourceManager. Uma vez alocados, o ApplicationMaster coordena com o NodeManager a execução e monitoramento dos containers (Gunarathne, 2015). A Figura 8 representa a interação entre os diferentes componentes do YARN quando uma aplicação de MapReduce é submetida. Figura 8 – Esquema representativo da interacção dos diferentes componentes do YARN
  37. 37. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 25 Fonte: https://www.packtpub.com/sites/default/files/Article-Images/8294OS_03.png 3.5 Apache Tez O apache Tez é uma framework do ecossistema Hadoop (HortonWorks, 2015a). Originalmente desenvolvida pela Hortonworks em 2013 como projeto incubador na comunidade Apache, em 2014 viria a graduar-se para um projeto de alto nível. O Tez permite o desenvolvimento de aplicações que aproximam o processamento de dados em lote a uma vertente iterativa. Coordenado pelo Apache YARN, este projeto mostra uma melhoria drástica em relação ao desempenho do MapReduce, mantendo ao mesmo tempo a escalabilidade no tratamento de Peta bytes de informação (Saha, 2013). Tez tira partido da computação de trabalho recorrendo a complexos grafos acíclicos dirigidos (directed acyclic graph-DAG). De uma maneira simples, uma aplicação pode ser modelada como um fluxo de dados, no qual as arestas refletem o movimento da informação e os vértices representam o processamento de tarefas (Saha et al., 2015). Esta API de fluxo de informação fornecida pelo Tez permite aos utilizadores expressarem lógicas complexas de query de forma intuitiva e natural, tornando-se assim um excelente motor de execução para frameworks declarativas de alto nível como é o caso do Apache Hive(HortonWorks, 2015a). Figura 9 – Esquema comparativo entre os passos realizados pelo MapReduce e pelo Tez para uma mesma query
  38. 38. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 26 Fonte: http://image.slidesharecdn.com/w-235p-hall1-pandey-140617161536-phpapp01/95/hive-tez-a- performance-deep-dive-9-638.jpg Na Figura 9 pode observar-se uma abstração de dois planos de execução de uma mesma query Hive, a diferença está no motor de execução, à esquerda MapReduce, e à direita Tez, de notar a diferença no número de operações de redução ‘R’ e mapeamento ‘M’ necessárias, bem como os acessos ao HDFS. O Tez evita muitos passos com um overhead associado considerável e que no MapReduce são norma, como é o caso das escritas no HDFS dos resultados intermédios, iniciação de um número desnecessário de Jobs, entre outros. A tecnologia de grafos permite ainda a execução de tarefas em paralelo e não necessariamente por ordem, não necessitando de refazer parte do trabalho caso uma tarefa num nó falhe (HortonWorks, 2015a). 3.6 Apache Hive Hive é um programa de data-warehousing contruído em cima do Apache Hadoop. O Hive tira todo o partido das capacidades de escalonamento do Hadoop para processar enormes quantidades de dados. Entre outras funcionalidades, o Hive dispõe de:  Ferramentas que facilitam operações ETL  Um mecanismo de estruturação de um variado leque de formatos  Acesso direto a ficheiros guardados no HDFS ou noutros sistemas de armazenamento distribuído como o HBase  Execução de queries através de MapReduce ou outros motores de execução como, por exemplo, Tez A grande marca desta ferramenta é sem dúvida a sua linguagem simples, similar ao SQL, chamada HQL, que permite aos utilizadores familiarizados com SQL executarem de modo transparente as suas queries. Esta linguagem dá também a liberdade aos programadores com experiência na framework MapReduce de executarem os seus próprios mappers e reducers, permitindo análises mais sofisticadas que podem não ser suportadas pelo HiveQL (Leverenz, 2015). Não se trata de uma base de dados por si só, os constrangimentos no design do Hadoop e no HDFS impõem limites às funcionalidades do Hive. A maior limitação é a falta de suporte para
  39. 39. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 27 atualizações, inserções e eliminação ao nível do registo (linha). Podem, no entanto, ser geradas novas tabelas ou ficheiros a partir de resultados de queries. Como o Hadoop é um sistema orientado para processamento de lotes, as queries executadas em Hive têm sempre uma latência considerável associada, devido ao overhead de arranque de jobs de MapReduce. Queries que normalmente terminam em poucos segundos numa base de dados tradicional levam mais tempo a concluir no Hive, até em trabalhos muito pequenos. O Hive não suporta transações ACID (até ao momento de escrita deste documento). Portanto, não preenche o requisito fundamental para OLTP, encontra-se mais próximo de uma ferramenta OLAP, se bem que, devido à sua alta latência de resposta, o componente Online de OLAP não é satisfeito. O seu uso mais adequado é em aplicações de armazenamento de dados, nas quais os dados analisados são relativamente estáticos, sem mudanças rápidas de estado, sendo que o tempo de resposta nunca é considerado como fator prioritário. Como a maioria dos armazéns de dados são implementados usando bases de dados SQL, o HQL diminui a resistência e complexidade de mover estes armazéns para o Hadoop. Um programador com conhecimentos mínimos de SQL poderia transitar para Hadoop sem qualquer dificuldade, não havendo a necessidade de aprender novas linguagens de programação ou dominar novas ferramentas para se manter produtivo (White, 2012). 3.6.1 Tipos de dados O Hive suporta tipos de dados primitivos e complexos de dados. No conjunto dos primitivos podemos contar com tipos numéricos, booleanos, strings e timestamp. Como dados complexos temos o tipo array, maps e estruturas (Capriolo, Wampler, & Rutherglen, 2012). 3.6.2 Formatos de ficheiros e compressão Existem duas dimensões de formatos a ter em conta quando se pretende gravar uma tabela no Hive, o formato de linha e o formato de ficheiro. O formato de linha dita de que forma os campos de uma tabela são interpretados, este mecanismo tem o nome de SerDe (Serialização- Deserialização). O formato de ficheiro dita a estrutura da tabela em disco. Estes dois conceitos estão interligados, uma vez que cada formato de ficheiro exige uma forma de SerDe. Os diferentes formatos de ficheiros têm diferenças de desempenho mediante a tipologia de dados que armazenam. Os formatos de ficheiro incluem suporte para algoritmos de compressão, normalmente Zlib ou Snappy. A compressão permite reduzir drasticamente o tamanho dos dados armazenados, aliviando a carga das operações de input e output no disco. Quando uma query é executada, o Hive carrega os dados em disco da tabela para memória, quanto maior o fator de compressão,
  40. 40. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 28 menor o tempo de carregamento dos mesmos. Há contundo uma consequência, a compressão e descompressão de dados exige muitos ciclos de relógio, podendo o CPU tornar-se um fator mais limitante que o próprio disco. Há que medir as vantagens da compressão de dados mediante o equipamento disponível e o caso de uso em mãos. Os principais tipos de ficheiro suportados pelo Hive são:  Parquet  Text  ORC  Avro  RCFile  SequenceFile 3.6.3 HiveQL A característica mais diferenciadora do Hive é a sua capacidade de inquirir os dados contidos no hadoop recorrendo a queries SQL. O HiveQL é um dialeto SQL com um suporte próximo da totalidade da norma ANSI SQL-92 mas conta também com extensões inspiradas na notação MySQL para uso nas suas queries. Este módulo do Hive nunca teve o foco de replicar na íntegra todas as funcionalidades da norma ANSI, contudo, ao longo do tempo os utilizadores foram desenvolvendo código que replicasse operações similares aquelas existentes nos SGBD relacionais. 3.6.4 CBO Um CBO (Cost Based Optimizer) é um conceito genérico de um programa que analisa queries com a finalidade de reduzir o tempo de execução e utilização de recursos. O algoritmo baseia- se nas tabelas usadas e nas condições especificadas na query para assim poder gerar planos de execução mais eficientes. A otimização dos planos de execução é um aspeto importante para soluções de armazenamento de dados. Estando à partida envolvidos um grande volume de dados, uma má organização do trabalho a realizar pode fazer uma diferença de minutos ou até mesmo horas (Mokhtar, 2015). O Hive por definição delega a otimização da query para o utilizador, mas este nem sempre é o mais eficiente possível e todo o processo exige tempo, sendo por isso aconselhável a utilização
  41. 41. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 29 de um CBO, mais concretamente o Apache Calcite (Gates, 2014). Numa fase posterior deste documento será analisada a performance deste CBO. 3.6.5 Stinger Stinger é um projeto desenvolvido pela comunidade Apache e alavancado pela HortonWorks (Gates & Bains, 2014), que tem como objetivo melhorar o desempenho e a funcionalidade do Hive tornando-o num software mais rico, com capacidade para responder a um maior leque de problemas Big Data. Deste projeto nasceram algumas inovações cruciais para a competitividade do Hive, nomeadamente o Tez, a integração do CBO Calcite, entre outros. Os objetivos do projeto são renovados a cada nova versão do Hive, as novas metas para 2015 contam com suporte para transações ACID nos updates e queries Sub-Second. Na Figura 10 pode ser vista uma figura descritiva da evolução deste projeto. Figura 10 – Diferentes fases de desenvolvimento do projecto Stinger e respectivas metas a alcançar Fonte: http://hortonworks.com/wp-content/uploads/2014/09/r4.png 3.7 Apache Sqoop O Sqoop é uma ferramenta desenvolvida sobre uma licença apache, desenhada para transferir dados entre o sistema Hadoop e as bases de dados relacionais. Este pode importar dados de MySQL, Oracle, SQL Server ou outra RDBMS para o HDFS, usando para isso as respetivas APIs. No Hadoop estes dados podem então ser tratados, analisados e transformados, podendo mais tarde ser exportados de volta para uma RDBMS. A grande vantagem do Sqoop em relação a abordagens mais tradicionais, que implicam escrita de código para transferência de dados é que, dependendo da fonte e do recetor, este automatiza a totalidade do processo, apoiando-se nas propriedades das tabelas para inferir o
  42. 42. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 30 esquema dos dados a importar. O Sqoop usa MapReduce tanto na importação como na exportação de dados, conferindo assim paralelismo bem como tolerância a falhas (“Sqoop User Guide (v1.4.6),” 2015). 3.7.1 Conectores e drivers O Sqoop tem uma framework para possibilitar a importação e exportação de dados de forma automática, desde que o sistema de armazenamento externo suporte transferências em massa (Bulk Load). Um Sqoop conector é um componente modular que usa esta framework para realizar operações de import e export (White, 2012). Tal como o Hadoop, também o Sqoop é escrito em Java, este oferece uma API chamada Java Database Connectivity, ou JDBC, que permite às aplicações aceder a dados guardados numa base de dados, assim como inspecionar o tipo destes dados. Existem três cenários possíveis quando se pretende executar uma operação de transferência.  O meu sistema de gestão de base de dados é suportado por um dos conetores que vem pré instalado no com o Sqoop. Neste caso, será apenas necessário adquirir um driver JDBC compatível com o SGBD (“Sqoop User Guide (v1.4.6),” 2015).  O Sqoop não inclui um conetor compatível com o meu SGBD. Para este caso será necessário efetuar o download de um conetor de terceiros, assim como o respetivo driver JDBC (“Sqoop User Guide (v1.4.6),” 2015).  O meu SGBD não dispõe de um conector Sqoop mas existe um driver JDBC disponível. Nesta situação tomar-se-á partido do conetor JDBC genérico do Sqoop, apenas sendo necessário efetuar a transferência e instalação do driver JDBC proprietário do vendedor do SGBD (“Sqoop User Guide (v1.4.6),” 2015). 3.7.2 Importação Como foi mencionado anteriormente, o Sqoop importa dados correndo trabalhos de MapReduce que escrevem os registos no HDFS. Baseando-se no URL contido na connection string que é usada para aceder à base de dados, o Sqoop tenta prever qual o conetor ou driver adequado para a operação. Antes de iniciar a importação, o Sqoop efetua uma query, através de JDBC, à tabela que se pretende importar, este processo é necessário para obter a lista de todas as colunas e os seus respetivos tipos de dados. Com a informação recolhida no passo anterior é feita uma conversão do tipo de dados SQL para Java. Para além do HDFS, o Sqoop permite também a importação de dados para tabelas Hive e HBase, com a criação automática de tabelas nestes programas de destino mediante a introdução de alguns parâmetros
  43. 43. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 31 requeridos (White, 2012). Mais à frente neste documento serão dados exemplos práticos de importação para estes programas. A Figura 11 representa o papel desempenhado pelo Sqoop numa solução Hadoop. Figura 11 – Arquitetura de uma solução Sqoop entre RDBMS e tecnologias Hadoop Fonte: http://www.dummies.com/how-to/content/sqoop-20-preview.html Existem outras ferramentas que permitem a ingestão de dados para o HDFS mas que não foram alvo de teste durante o estágio, nomeadamente Apache Chukwa, Apache Flume (Holmes, 2012). A principal diferença destas ferramentas em relação ao Sqoop é a sua orientação para coleção de logs em modo de streaming (ingestão continua) ao invés de Bulk Loading. 3.8 SQuirreL SQL Client SQuirreL SQL Cliente (SQuirreL, 2015) é um programa Java com uma interface gráfica modesta que permite a ligação a uma base de dados que disponha de um JDBC. Permite a visualização de tabelas, estrutura, dados e execução de comandos. O Hive fornece drivers JDBC que podem ser usados nesta ferramenta, dando assim a possibilidade de uma iteração muito completa com os dados armazenadas no Hadoop a partir de qualquer sistema. Os comandos executados a partir deste cliente são processados normalmente no cluster hadoop, tal como se fossem inseridos diretamente na consola do Hive.
  44. 44. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 32 3.9 Distribuições Hadoop Dada a grande diversidade de ferramentas disponíveis no universo Hadoop o utilizador depara-se com um grande obstáculo para escolher, instalar, e configurar um sistema minimamente funcional. Com o intuito de diminuir o grau de investimento inicial, algumas empresas começaram a disponibilizar soluções completas Hadoop, com software de todo o espectro Apache. HortonWorks (HortonWorks, 2015b), Cloudera (Cloudera, 2015), MapR (MapR, 2015b), são as empresas líderes em distribuições Hadoop, não se limitando apenas à compilação de ferramentas, todas elas melhoram, adaptam e desenvolvem frameworks Hadoop em busca de melhor performance. Apache Tez, Apache Impala (Russell, 2013) e MapR- DB (MapR, 2015a) são fruto desse trabalho, sendo que as duas últimas são software proprietário da Cloudera e MapR respetivamente. Por forma a agilizar o processo de testes e análise de ferramentas, optou-se por testar duas destas distribuições, HortonWorks Data Platform e Cloudera Manager. Ambos fornecem um guia de instalação com interface gráfica (Web) bastante amigável com o utilizador e todo o software selecionado é instalado automaticamente pelos nós do cluster. 3.9.1 HortonWorks Data Platform  Custos de Software: Totalmente gratuito  Monitorização do cluster: Apache Ambari (Apache Ambari, 2015)  Interface gráfica para execução de queries: Não tem  Arquitetura: Figura 12 Figura 12 – Arquitetura da distribuição Hadoop da HortonWorks (HDP 2.3) Fonte: http://hortonworks.com/hdp/
  45. 45. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 33 3.9.2 Cloudera Data Hub  Custos de Software: Apache Impala (30 dias Trial)  Monitorização do cluster: Cloudera Manager  Interface gráfica para execução de queries : Apache Hue (Hue, 2015)  Arquitetura: Figura 13 Figura 13 - Arquitetura da distribuição Hadoop da Cloudera (CDH 5.4) Fonte: http://www.cloudera.com/content/cloudera/en/products-and-services/cloudera-enterprise.html 3.10MongoDB MongoDB é uma tecnologia NoSQL multi-plantaforma, inicialmente desenvolvido pela companhia 10gen em Outubro de 2007 como um serviço comercial, passou a open-source em 2009 e até 2014 ganhou mercado, tornando-se a tecnologia NoSQL mais utilizada atualmente (“Popularity ranking of database management systems,” 2015) apesar de inúmeros problemas de consistência e escrita de dados (Slootwe, 2015). Enquadra-se na categoria das bases de dados orientadas a documentos, corta com o tradicional método de armazenamento de dados em tabelas em favor de documentos do estilo JSON (JavaScript Object Notation), mais especificamente BSON (Binary JSON). O MongoDB é uma boa opção para consistência e disponibilidade, no entanto, como se trata de um sistema distribuído com propriedade BASE
  46. 46. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 34 uma das propriedades CAP tem de ser sacrificada, neste caso, as escritas são comprometidas em caso de falha (par CP do teorema). É ideal para aplicações que efectuem operações de leitura de dados imediamente após a escrita dos mesmos, conseguindo manter a consistência. O seu estilo de documento BSON incentiva o armazenamento de coleções de dados num único documento, retirando em muitos casos a necessidade de realizar JOINS. Se o modelo de dados tiver relações de muitos para muitos surge um problema, ou se criam enormes documentos com a totalidade da informação dos objectos referenciados, ou são criadas chaves estrangeiras que forçam a utilização de JOINS e reduzem drasticamente o desempenho do sistema. O facto de permitir um esquema livre torna-o uma boa opção para modelos de dados em mutação e rápido crescimento (Chodorow & Dirolf, 2010). 3.11MSSQL To MongoDB Tool (SQL2Mongo) SQL2Mongo (Rynnwang, 2013) é uma ferramenta open-source baseada em .NET framework 4.0 que permite importar tabelas de Microsoft SQL Server 2005 ou superior para MongoDB. Com apenas duas connection string, o programa abre as ligações, cria o documento JSON no MongoDB e efetua todas as conversões de tipos de dados automaticamente, sem possibilidade de alteração manual. 3.12Cassandra Originalmente desenvolvido pelo Facebook em 2008 para suportar a funcionalidade de pesquisa na caixa de entrada, o Cassandra rapidamente foi lançado para código aberto e em 2009 foi aceite como um projecto Apache de alto nível. O Cassandra é um DBMS distribuído desenhado para suportar grandes quantidades de dados espalhados por vários servidores com hawdware convencional e ao mesmo tempo manter a disponibilidade. Pode ser definido como uma variante de uma base de dados key/value, na qual uma chave pode ser atribuída não apenas a um mas sim a um conjunto de valores, aproximando-se muito do tipo de base de dados Row Store. Um ponto forte deste sistema é a sua capacidade para ingerir e armazenar grandes volumes de dados de forma celere. A consistência é assegurada através de um sistema de versões de ficheiros MVCC1 (Multiversion concurrency control) que determina a validade dos dados através de um timestamp. O Cassandra recai sobre o par AP do teorema de CAP, a consistência é relaxada em favor da disponibilidade e tolerância ao particionamento. A sua arquitetura descentralizada garante ao Cassandra a ausência de um ponto de falha isolado, 1 https://en.wikipedia.org/wiki/Multiversion_concurrency_control
  47. 47. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 35 todos os nós desempenham o mesmo papel, por isso em caso de falha de um destes, os outros podem substituir de forma expedita a sua carga. A sua imunidade a falha reflete-se também nos dados, pois estes são replicados pelos diversos nós do cluster, permitindo ainda a distribuição e replicação de dados em clusters geograficamente separados, mas membros da mesma instancia Cassandra (Bradberry & Lubow, 2013). 3.13Hbase Nascido de um projecto começado em finais de 2006 por Chad Walters e Jim Kellerman, o HBase teve uma forte influência num artigo proveniente da investigação que a Google realizou no seu projeto BigTable, que tinha sido publicado meses antes nesse mesmo ano. Em 2010 graduou-se para um projecto Apache de alto nível e é atualmente considerada uma tecnologia madura, usada em ambiente de produção de diversas industrias. O HBase é uma base de dados distribuída column-oriented, construída no topo do sistema de ficheiros do Hadoop. O seu ponto forte é a capacidade de resposta em tempo real quando se acede a um grande volume de dados de forma aleatória, quer para leituras como em escritas. Foi construído de raiz para escalar linear e facilmente à medida que novos nós vão sendo adicionados ao cluster. Apesar de não se tratar de uma base de dados relacional, não suportar SQL nem transações ACID, dado o problema certo, o HBase é capaz de de fazer aquilo que as RDBMS determinaram como impraticável: armazenar grandes quantidades de dados, dispersos por tabelas num cluster constituído por máquinas banais (White, 2012). Do ponto de vista da consistência, o HBase é considerado um sistema CP no teorema de CAP, permite uma forte tolerância a falhas mantendo a consistência. 3.14Apache Spark Inicialmente idealizado por Matei Zaharia da universidade de Berkeley (Zaharia, Chowdhury, Franklin, Shenker, & Stoica, 2010), o Spark tornou-se um projecto de alto nível Apache em 2004. É uma framework de clustering para processamento de dados em larga escala. Ao contrário da maioria das tecnologias baseadas em Hadoop, o Spark dispensa o uso de MapReduce como motor de execução e usa, em vez disso, a sua própria tecnologia para executar trabalho distribuído num cluster. Não obstante, o Spark tem características muito similares ao MapReduce. Fortemente integrado com o Hadoop, o Spark pode utilizar o gestor de recursos YARN, bem como tirar partido do poderoso sistema de armazenamento distribuído HDFS. O ponto forte desta tecnologia é a sua capacidade de, entre operações, manter em memória grandes blocos de dados, permitindo assim um desempenho ordens de magnitude
  48. 48. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 36 superior a um trabalho de MapReduce. Esta característica é essencial para dois grandes tipos de aplicações: algoritmos iterativos e análises iterativas. Num algoritmo iterativo é aplicada de forma repetida uma função a um conjunto de dados até que uma condição de paragem seja atingida. Num tipo de trabalho de análise iterativa são corridas uma série de queries exploratórias inseridas num pipeline. Estes trabalhos têm um padrão de acesso a dados encadeado ou repetitivo, beneficiando de chaches em memória. Mesmo para algoritmos de batch, a tecnologia de DAG do Spark pode ser vantajosa e, por isso, esta tecnologia foi alvo de testes, documentados no presente documento. Tem provado ser uma tecnologia com uma boa plataforma para desenvolver aplicações de análise, conta com módulos de machine learning (MLlib), processamento de gráficos (GraphX), processamento em streaming (Spark Streaming), e SQL (Spark SQL) (White, 2012).
  49. 49. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 37 4 Descrição técnica Após o levantamento do estado das tecnologias NoSQL, e identificação das suas ferramentas, foram feitos vários testes a fim de averiguar de que forma estas tecnologias permitiam solucionar os requisitos apresentados. O presente capítulo é guiado por requisitos, em cada um deles é analisada uma ferramenta, que de forma direta ou indireta, permite alcançar o objectivo em que se enquadra. 4.1 Requisitos O presente trabalho tem uma vertente exploratória predominante, significa isto, que os requisitos da solução foram sendo identificados de forma progressiva e iterativa. Não se partiu de uma lista fixa de itens, a pesquisa constante moldou as várias etapas e ditou o as ferramentas a testar. Os requisitos apurados podem ser visualizados em seguida: Tabela 2 – Requisitos não funcionais e funcionais REQUISITO NÃO FUNCIONAL REQUISITO FUNCIONAL SUBJACENTE RESPOSTA ÀS QUERIES EM TEMPO ÚTIL Compressão de informação armazenada re- correndo a algoritmos eficientes APROVEITAR O CONHECIMENTO DOS PROFISSIONAIS COM CONHECIMENTOS DE SQL PARA INTERAGIR COM O SITEMA NOSQL Interface de querying declarativa similar ao SQL TOLERANCIA A FALHAS E ECONÓMICO Sistema distribuído composto por commodity hardware sem SPOF(Single Point Of Failure) ALTAMENTE ESCALÁVEL, VERTICAL E HO- RIZONTALMENTE Sistema de base de dados NoSQL DESCARREGAR PERIODICAMENTE INFOR- MAÇÃO PARA O SISTEMA A DESENVOL- VER Importação automática de dados de um sis- tema de base de dados relacional para um cluster NoSQL CAPACIDADE DE VISUALIZAR UMA TA- BELA A PARTIR DE UMA MÁQUINA DE UM COLABORADOR Visualização de dados armazenados num sis- tema NoSQL a partir de ferramentas externas SISTEMA DE INSTALAÇÃO AUTOMÁTICA E DE FÁCIL CONFIGURAÇÃO Distribuição Hadoop ou similar com comuni- ção por ssh para instalação automaticas MONITORIZAÇÃO DO ESTADO DE TODAS AS MÁQUINAS DO CLUSTER Distribuição Hadoop ou similar com software de monitorização
  50. 50. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 38 4.2 Sistema de base de dados distribuído, escalável horizontalmente de forma económica, e tolerante a falhas Um dos requisitos chave da solução é, sem dúvida, montar um sistema distribuido, tolerante a folhas, com a capacidade de escalar horizontalmente de forma linear, sem ser necessário um grande investimento, sempre que se pretenda aumentar o numero de máquinas. Várias soluções foram testadas e, em seguida, serão apresentados os resultados. Nesta secção serão descritos pormenorizadamente os passos de instalação das ferramentas descritas anteriormente. Passos mais relevantes e detalhes técnicos importantes são alvo de uma explicação mais detalhada. Em geral, foram utilizadas duas máquinas virtuais com o sistema operativo CentOS 7 e mais tarde foram migradas para o CentOS 6.6 por motivos de compatibilidade com as distribuições Hadoop. Para certas tecnologias foi ainda utilizada uma instalação de uma máquina virtual num Laptop HP. Tabela 3 – Especificações dos nós do cluster Máquina CPU Nucleos Disponíveis Frequência (Ghz) RAM (MB) Disco (GB) S.O. Localização Física Hslave1 AMD Optro n 2439 SE 4 2.8 3952 35 CentO S Servidores da CMF Hslave2 AMD Optro n 2439 SE 4 2.8 3823 35 CentO S Servidores da CMF Hmaster Intel Core 2 Duo P8700 2 2.53 1820 15 CentO S Laptop da CMF
  51. 51. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 39 4.2.1 Hadoop (Standalone) A instalação do Hadoop pode ser feita em modo local, pseudo-distribuído, ou distribuído, sendo que a diferença reside no número de máquinas em que é instalado e no modo como as demons são iniciadas (DataNodes, NameNode, ResourceManager, JobHistoryServer). Nesta secção serão detalhados os passos para a instalação do Hadoop sem usar uma distribuição. 4.2.1.1 Modos de funcionamento do Hadoop Uma instalação Hadoop começa por omissão em modo local (standalone), o instalador não sabe à partida o número nem os endereços das máquinas em que poderá ser executado, por isso, assume uma postura conservadora e efetua uma instalação local. Deste modo os ficheiros de configuração estão vazios e o HDFS desligado, não há a necessidade de comunicar com outros dispositivos, não lançando assim nenhum daemon. Este modo serve essencialmente para desenvolver e testar aplicações MapReduce. O modo pseudo-distribuído complementa o modo local na medida em que também corre numa só máquina, mas inicializa todos os daemons como se de um ambiente distribuído se tratasse. Este modo é indicado para debugging de código, permitindo analisar o uso da memória, operações de leitura e escrita no HDFS bem como observar interações entre os diferentes componentes lógicos do Hadoop (daemons). Para dois ou mais nós, deve usar-se o modo distribuído, este modo segue uma arquitetura mestre/escravo típica do Hadoop, e permite uma escalabilidade linear. Nesta configuração as máquinas que correm o DataNode integram no HDFS e partilham o seu armazenamento. Para um cluster com muitas máquinas, é recomendável reservar uma ou mais máquinas apenas para o ResourceManager e o NameNode, uma vez que estes processos têm tendência a acumular uma grande quantidade de carga computacional à medida que o número de nós aumenta. Este modo permite explorar todo o potencial do Hadoop e é ideal para ambientes de produção, foi por isso sobre ele que incidiu o estudo. 4.2.1.2 Requisitos Os sistemas operativos GNU/Linux são suportados quer para ambientes de desenvolvimento como de produção, embora seja possível instalar o Hadoop em Windows. Neste guia será mostrado o processo de instalação num CentOS 7. É preciso assegurar que a máquina onde se vai efetuar a instalação possui Java 7 ou superior. Em termos de Hardware não existem requisitos rígidos, contudo é aconselhável uma quantidade de RAM generosa, 4GB por nó será um mínimo aceitável.
  52. 52. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 40 4.2.1.3 Configuração dos nós para o modo cluster Nesta secção é demonstrada, após instalação que pode ser consultadano anexo B do presente documento, a configuração de um método que permite usar um nome em vez de um IP quando nos queremos referir a um nó. É também exemplificada a geração e distribuição de uma chave RSA pública pelas máquinas do cluster para que estas possam cooperar entre si, por exemplo, iniciar processos através de um comando Shell enviado por rede. O ficheiro hosts permite armazenar uma tabela similar a um DNS na qual podemos adicionar os nomes das máquinas e os respetivos IPs. A solução ótima seria registar o nome das máquinas no servidor de DNS da rede, mas por questões de simplificação optou-se por preterir a norma FQDN2 . Usar o comando a baixo para aceder ao ficheiro hosts sudo vi /etc/hosts Adicionar as seguintes linhas ao ficheiro 192.168.126.242 hmaster 192.168.127.108 hslave1 192.168.127.212 hslave2 Adicionar o utilizador hadoop sudo useradd hadoop sudo passwd hadoop Definir chaves ssh para login entre máquinas sem solicitação de password su hadoop ssh-keygen -t rsa ssh-copy-id -i ~/.ssh/id_rsa.pub hadoop@hmaster ssh-copy-id -i ~/.ssh/id_rsa.pub hadoop@hslave1 ssh-copy-id -i ~/.ssh/id_rsa.pub hadoop@hslave2 chmod 0600 ~/.ssh/authorized_keys 2 https://en.wikipedia.org/wiki/Fully_qualified_domain_name
  53. 53. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 41 4.2.1.4 Ficheiros de configuração O Hadoop é uma ferramenta bastante versátil, esta característica provém de uma forte componente de customização suportada pelos seus ficheiros de configuração. A instalação do programa em si é bastante simples, todo o trabalho árduo exigido pela implementação do Hadoop está voltada para a moldagem dos ficheiros de configuração a um caso de uso específico e pelo domínio da lógica do sistema implícita nos parâmetros. Esta é uma vantagem, mas também um entrave a utilizadores menos experientes, pois não é fácil conjugar as implicações do valor de um parâmetro em conjunto com outros que dele dependem, direta ou indiretamente. Não existem receitas para uma solução ótima, a maneira mais prática de refinar o funcionamento do Hadoop é através de um demorado processo de tentativa e erro. Em seguida serão mostrados os ficheiros de configuração mais importantes na Tabela 4 – Descrição dos principais parâmetros de configuração do Hadoop, e explicados alguns dos parâmetros configuração. Todos os ficheiros de configuração são locais ao nó, não existe uma pasta central à qual estes acedem, cabe ao utilizador garantir que todas as máquinas do cluster têm as suas pastas de configuração sincronizadas. Caso se trate de um cluster constituído por máquinas de diferentes características cada nó deve ter as configurações apropriadas e este, por sua vez, deve pertencer a uma classe de máquinas com aquelas características. Tabela 4 – Descrição dos principais parâmetros de configuração do Hadoop Ficheiro Descrição core-site.xml Configuração de parâmetros base do Hadoop como regras de I/O transversais ao HDFS, MapReduce, e YARN hdfs-site.xml Configuração dos daemons HDFS: namenode, secondary namenode, e datanode mapred-site.xml Configuração do daemon MapReduce: job history server yarn-site.xml Configuração do daemon YARN: resource manager, web app proxy server, e node manager slaves Um ficheiro de texto com uma máquina por linha, cada uma corre um daemon datanode e node manager
  54. 54. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 42 Block size (propriedade dfs.block.size do ficheiro hdfs-site.xml) Por definição, o espaço no disco é dividido em blocos de 64 Mb, podendo ser superior. Nos discos tradicionais este valor é, por norma, 4 Kb. Cada vez que é necessário fazer uma leitura ou escrita no disco, o sistema tem de efetuar um conjunto de operações por cada bloco consultado. Se o padrão de acesso for uma consulta de muitos ficheiros de pequeno tamanho, os 4Kb permitem um acesso de baixa latência. Se, por sua vez, estivermos perante um padrão de consulta com poucos ficheiros mas de grande dimensão, o sistema beneficia de um tamanho de bloco superior, uma vez que terá de efetuar menos operações de consulta, diminuindo o overhead. Replication Factor (propriedade dfs.replication do ficheiro hdfs-site.xml) Define o número de cópias criadas por ficheiro, trata-se de uma propriedade crítica para a fiabilidade e performance do HDFS. Quando definido para um valor igual a 3, o HDFS guarda uma cópia na rack local, outra numa rack diferente ou remota, e uma terceira num nó distinto da rack remota. Esta política reduz significativamente o tráfego entre racks e aumenta o desempenho das operações de escrita. No caso implementado é usado um valor de 2 para garantir o mínimo de uma cópia por cada ficheiro. Reduce slow start (propriedade mapreduce.job.reduce.slowstart.completedmaps do ficheiro mapred-site.xml) Por definição, os escalonadores esperam até que 5% das tarefas de map estejam concluídas antes de iniciarem os reducers. Num Job de larga escala este intervalo pode causar problemas na utilização do cluster, uma vez que são alocados containers para as tarefas de redução mas não são executados durante esse intervalo. Um valor de 0.80 pode ajudar a aumentar o desempenho nestes casos. Parametrização da RAM e CPUs A parametrização da quantidade de recursos disponibilizada para cada componente do sistema Hadoop deve ser baseada primeiro nas características da máquina e depois no tipo de trabalho que o cluster vai realizar. A solução apresentada neste relatório visa casos de utilização generalizados que são por omissão adequados para trabalhos em lote, por isso, foi usado uma ferramenta que calcula a quantidade de recursos atribuídos consoante as capacidades da máquina.
  55. 55. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 43 A ferramenta está disponível para download e pode ser obtida através do comando: wget http://public-repo- 1.hortonworks.com/HDP/tools/2.0.6.0/hdp_manual_install_rpm_helper_fil es-2.0.6.101.tar.gz tar -xvf hdp_manual_install_rpm_helper_files-2.0.6.101.tar.gz Depois de extraído, é possível ver que se trata de um simples script com os seguintes parâmetros de entrada. Tabela 5 – Parametros de entrada para o script de cálculo dos recursos optimos alocados por cada nó do cluster Hadoop Opção Descrição -c CORES Número de CPU cores por cada nó -m MEMORY Quantidade de RAM em cada nó expressa em GB -d DISKS Número de discos em cada nó -k HBASE "True" se HBase estiver instalado, "False" se não existir. A execução do mesmo para as máquinas em causa foi a seguinte: 4 cores, 4 GB RAM e 1 disco python yarn-utils.py -c 4 -m 4 -d 1 -k False
  56. 56. Processamento distribuído de grandes blocos de dados Rui Fernando Alves Rebelo Magalhães 44 O retorno indica-nos os valores que devem ser aplicados para as seguintes propriedades: Tabela 6 – Correspondência entre o ficheiro de configuração, o nome da propriedade e a fórmula de cálculo do valor da mesma Ficheiro de Configuração Propriedade Cálculo do valor yarn-site.xml yarn.nodemanager.resource.memory-mb = Containers * RAM-per-Container yarn-site.xml yarn.scheduler.minimum-allocation-mb = RAM-per-Container yarn-site.xml yarn.scheduler.maximum-allocation-mb = containers * RAM-per-Container mapred-site.xml mapreduce.map.memory.mb = RAM-per-Container mapred-site.xml mapreduce.reduce.memory.mb = 2 * RAM-per-Container mapred-site.xml mapreduce.map.java.opts = 0.8 * RAM-per-Container mapred-site.xml mapreduce.reduce.java.opts = 0.8 * 2 * RAM-per-Container yarn-site.xml yarn.app.mapreduce.am.resource.mb = 2 * RAM-per-Container yarn-site.xml yarn.app.mapreduce.am.command-opts = 0.8 * 2 * RAM-per-Container O output obtido para as máquinas do cluster foi o seguinte: Using cores=4 memory=4GB disks=1 hbase=True Profile: cores=4 memory=2048MB reserved=2GB usableMem=2GB disks=1 Num Container=3 Container Ram=682MB Used Ram=1GB Unused Ram=2GB yarn.scheduler.minimum-allocation-mb=682 yarn.scheduler.maximum-allocation-mb=2046 yarn.nodemanager.resource.memory-mb=2046 mapreduce.map.memory.mb=682 mapreduce.map.java.opts=-Xmx545m mapreduce.reduce.memory.mb=1364 mapreduce.reduce.java.opts=-Xmx1091m yarn.app.mapreduce.am.resource.mb=1364 yarn.app.mapreduce.am.command-opts=-Xmx1091m mapreduce.task.io.sort.mb=272

×