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

Processamento distribuído de grandes blocos de dados

Critical Manufacturing

2014 / 2015

1111439 Rui Magalhães


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

iii

«Great solutions are the ones who solve great problems»

Amr Awadallah


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.


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


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


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


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


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


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


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


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


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.



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.



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



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.



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.



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.



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).



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.



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.



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



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



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



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).



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



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.



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.



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).



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.



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).



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.



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



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



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



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



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



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,



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



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



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



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.



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/



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.10 MongoDB

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



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.11 MSSQL 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.12 Cassandra

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



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.13 Hbase

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.14 Apache 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



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).



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



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



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.



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



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



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.



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



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



4.2.2 Cassandra

Fruto da pesquisa e levantamento das principais características das tecnologias existentes foi

possível constatar que o Cassandra é um dos sistemas NoSQL com maior poder de

processamento de dados (Rabl et al., 2012). Apesar de ser uma ferramente com excelentes

resultados em testes sintéticos não satisfazia o requisito de importação automática de dados.

Deste modo apenas será apresentado o guia de instalação.

4.2.2.1 Instalação do Cassandra 2.0

O processo de instação do Cassandra, seguido pelo manual de referência3, revelou ser o mais

fácil de todas as tecnologias testadas, basta adicionar ao repositório a versão oficial, instalar a

aplicação, configurar os parâmetros do cluster e iniciar. O protocolo de gossip trata da

descoberta e categorização de instâncias Cassandra existentes na rede. Para a instalação do

Cassandra foram utilizados as duas máquinas virtuais CentOS 6.6.

Criar ficheiro de repositório:

Sudo vi /etc/yum.repos.d/datastax.repo

Editar o ficheiro e colocar a seguinte informação:

[datastax]

name = DataStax Repo for Apache Cassandra

baseurl = http://rpm.datastax.com/community

enabled = 1

gpgcheck = 0

Instalar o pacote fornecido pelo repositório:

sudo yum install dsc20-2.0.14-1 cassandra20-2.0.14-1

A configuração é o passo mais importante no processo de instalação. O Cassandra procura

outras instâncias na rede através de um protocolo próprio chamado “Gossip”, que consiste na

partilha periódica entre nós de informação sobre eles próprios e informação sobre nós com os

quais já contactaram. No ficheiro de configuração deve ser explicitado um nó que arranca o

processo de gossip, este parâmetro aceita um endereço IP e deve ser igual em todas as

máquinas por motivos de eficiência.

Configurar cassandra.yaml

cluster_name: 'MyCassandraCluster'

num_tokens: 256

3 http://docs.datastax.com/en/cassandra/2.0/cassandra/initialize/initializeSingleDS.html



seed_provider:

- class_name: org.apache.cassandra.locator.SimpleSeedProvider

parameters:

- seeds: "192.168.126.242"

listen_address:

rpc_address: 0.0.0.0

endpoint_snitch: GossipingPropertyFileSnitch

Por fim, o serviço pode ser iniciado.

sudo service cassandra start

O comando seguinte permite verificar o estado do serviço. É através deste que é possível obter

uma lista de outras instâncias do Cassandra a correr no cluster, bem como recolher informação

sobre o seu estado.

nodetool status

Figura 14 – Estado do cluster cassandra

Fonte: https://twgame.files.wordpress.com/2015/02/only-nodetool-status.png

4.2.3 MongoDB

MongoDB é uma tecnologia NoSQL que a par do Cassandra demonstra resultados muito bons

em testes sintéticos, quer a nível da capacidade de ingestão, quer na eficiência de

escalabilidade. O seu estilo de armazenamento em documentos com esquema livre suporta

perfeitamente o tipo de dados do problema em causa, os dados de sensores não têm uma

relação de muitos para muitos inerene o que torna a utilização do MongoDB ainda mais rápida,

tal como referido no capítulo três.



4.2.3.1 Requisitos

O MongoDB tem alguns requisitos de sistema que devem ser preferencialmente garantidos

antes da instalação. O primeiro passo é assegurar que o sistema de segurança SELinux é

alterado do modo ‘enforcing’ para o modo “permissive”.

Esta configuração está acessível através do ficheiro selinux.conf

Vi /etc/selinux.conf

A linha onde de pode ler ‘SELINUX=enforcing’ deve ser alterada para:

SELINUX=permissive

Este passo, bem como todos os passos da instalação, devem ser replicados por todas as

máquinas que se pretende que façam parte do cluster.

4.2.3.2 Teste de instalação

Para poder testar o potencial do MongoDB é necessário, após a instalação (em anexo B),

englobar os nós num Replica Set e activar o Sharding. Primeiramente será demonstrado o

método para a criação de um Replica Set.

4.2.3.2.1 Replica Set

Inicialmente devem ser criadas pastas por cada máquina integrante do Replica Set. Sendo o

comando repetido igualmente por cada máquina membro.

mkdir -p /srv/mongodb/rs0-0 /srv/mongodb/rs0-1 /srv/mongodb/rs0-2

Após a criação das pastas deve ser iniciado em cada nó o processo mongod com um comando

personalizado, de acordo com o nome da pasta respetiva do Replica Set.

Máquina 1

mongod --port 27017 --dbpath /srv/mongodb/rs0-0 --replSet rs0 --

smallfiles --oplogSize 128

Máquina 2



Máquina 3





Estes passos iniciam cada instância do MongoDB como um membro do replica set rs0, cada

um a correr em portas distintas e especificando o diretório das réplicas com o argumento –

dbpath. A opção –smallfiles e –oplogSize reduz o espaço em disco ocupado por cada instância.

A partir de um novo terminal pode aceder-se à consola do MongoDB usando o comando:

mongo --port 27017

A porta identifica a instância à qual é feita a conexão.

O passo final para a criação do replica set é definir os seus membros e iniciá-lo a partir da Shell

do mongo.

rsconf = {

_id: "rs0",

members: [

{

_id: 0,

host: "hmaster:27017"

}

]

}

rs.initiate( rsconf )

Na configuração inicial basta explicitar o primeiro membro, os restantes podem ser

adicionados com o comando

rs.add("hslave1:27018")

rs.add("hslave2:27019")

Ao correr o comando rs.status() verifica-se que todos os nós fazem parte do replica set:



Figura 15 – Informação detalhada do Replica Set criado no MongoDB

4.2.3.2.2 Sharding

O passo de ativar o Sharding é bastante simples quando executado a seguir à criação do replica

set, uma vez que as pastas criadas anteriormente serão usadas também para efeitos de

Sharding.

Caso ainda não esteja aberta, deve iniciar-se uma ligação a uma shel do mongo:

mongo --host hslave1 --port 27017

Sem necessidade de configurações adicionais, podem adicionar-se shards com o comando:

sh.addShard("rs0/hslave1:27017,hslave2:27018,hmaster:27019")

Finalizadas as configurações para tornar o armazenamento do MongoDB, foi importada a

tabela factmaterialmovement usando a ferramenta SQL2mongo. Foi testada uma query similar

às executadas no sistema Hadoop, pretendia-se calcular a soma da coluna

‘ProcessedPrimaryQuantity’ e averiguar o tempo de resposta.

db.FactMaterialMovement.aggregate( [ { $group: { _id: null, total: {

$sum: "$ProcessedPrimaryQuantity" } } } ] )



Os resultados obtidos mostraram que em relação ao Hive, o mongoDB para além de não

suportar qualquer tipo de query SQL também é bastante mais lento, executando a query num

tempo nunca inferior a 3 minutos. O tamanho da tabela em disco, apesar das flags de

compressão, assumia um valor de 6 GB, valor muito superior aos 14 megas ocupados no Hive.

O valor dos 6 GB pode ser alcançado tendo em conta que a tabela incial tem cerca de 1GB,

cada máquina replica 1 vez a sua informação, portanto teremos 2GB por máquina, como

existiam 3 máquinas membro da réplica set chegamos ao valor dos 6GB apresentado pelo

mongoDB.

4.3 Importação automática de dados de um sistema de base

de dados relacional para um cluster NoSQL

Ficou definido que a forma como o sistema de base de dados NoSQL ia ser alimentado era

através de uma base de dados relacional. Seriam periodicamente corridos scripts para

descarregar dados de produção no cluster, o que gerou a necessidade de uma ferramenta que

permitisse importar dados externos para a base de dados NoSQL. Foram testadas algumas

ferramentas e os resultados são apresentados em seguida.

4.3.1 Sqoop

O Sqoop foi uma ferramenta testada após ter sido apurado o requisito de importação de dados

do SQL Server para o sistema Hadoop. A escolha de um programa de importação de dados

para Hadoop recaiu no Sqoop porque este dispõe de um modo de importação direta para o

Hive, fazendo automaticamente a conversão de tabelas de um RDBMS para tabelas Hive. O

Sqoop permite também fazer exportações, e existem outras soluções de aquisição de dados

como o Apache Chukwa, Apache Storm e Apache Flume, mas estas são mais centradas para o

processamento de dados de tempo real, em modo streaming. O Sqoop é a ferramenta ideal

para trabalhos de importação incremental, agendados com periodicidade diária ou semanal,

dependendo do tamanho de dados a importar, cumprindo perfeitamente os requisitos do

problema. É um serviço integrante das duas distribuições analisadas. No HDP o Sqoop é usado

somente através da linha de comandos, já no Cloudera Manager pode ser utilizado tanto a

partir da linha de comandos, como a partir do separador de importação na interface HUE.

4.3.1.1 Instalar driver JBDC

Para o Sqoop conseguir comunicar com outra base de dados tem de possuir uma interface

específica para o fazer. Neste caso são usadas drivers JDBC, em concreto para o SQL Server. Na



sua generalidade, os SGBD possuem um conector JDBC disponibilizado pela empresa

proprietária. Para o SQL Server a Microsoft disponibiliza o sqljdbc 4.0.

A sua instalação é bastante simples, basta efetuar o download e copiar um ficheiro “.jar” para

a biblioteca do Sqoop.

cd /opt

curl -L 'http://download.microsoft.com/download/0/2/A/02AAE597-3865-

456C-AE7F-613F99F850A8/sqljdbc_4.0.2206.100_enu.tar.gz' | tar xz

cp /opt/sqljdbc_4.0/enu/sqljdbc4.jar /usr/hdp/2.2.6.0-2800/sqoop/lib/

Há alguns passos que devem ser executados na configuração do SQL Server para permitir a

interação com o Sqoop. Deve ser criado um login destinado apenas para o Sqoop, o mixed

mode authentication e o protocolo de rede TCP/IP devem estar ativados. Para mais detalhe

pode ser consultado o seguinte manual: http://hortonworks.com/hadoop-tutorial/import-

microsoft-sql-server-hortonworks-sandbox-using-sqoop/

Para testar a instalação do conector pode ser executado um simples comando para listar as

bases de dados existentes num determinado servidor SQL.

sqoop list-databases \

--connect jdbc:sqlserver://CMF-VM-ATS2:49725 \

--username hadoop \

--password hadoop

Em caso de sucesso deve ser retornada uma lista com as bases de dados existentes no SGBD

Para todas as operações são necessários alguns parâmetros essenciais, o –connect para indicar

o driver a usar, o endereço do servidor do SGDB, e a porta para se conectar. O nome de

utilizador corresponde ao parâmetro –username, o parâmetro password pode ser omitido e

introduzido na consola aquando da execução do comando. Desta forma evita-se ter a

password guardada em plain-text.

4.3.1.2 Importação para Hive

O Sqoop disponibiliza vários modos de importação para o Hive, estes podem ser consultados

na página de documentação4. Neste documento serão abordados os métodos de importação

por query, por tabela, e modo append.

4 https://sqoop.apache.org/docs/1.4.6/SqoopUserGuide.html



Para além dos parâmetros base referidos anteriormente, a importação para o Hive exige

também a designação da flag –Hive-import bem como o nome da base de dados e da tabela

da qual vão ser importados dados.

4.3.1.2.1 Modo tabela

O seguinte comando exemplifica o modo de importação de uma tabela inteira diretamente

para o Hive, o parâmetro –m designa o número de tarefas de map iniciadas para executar a

operação, a paralelização do import tem por objetivo reduzir o tempo da importação.

Idealmente deve ser escolhido um valor igual ou superior ao número de nós do cluster, no

entanto, a capacidade de débito do servidor do SGBD pode ser um fator limitante, e a partir

de determinado valor de –m o processo deixa de ganhar desempenho.

sqoop import \

--connect "jdbc:sqlserver://CMF-VM-ATS2:49725;database=ATSCHQUnver-

sionedDWH" \

--username hadoop \

--password hadoop \

--table "FactMaterialMovement" \

--m 1 \

--Hive-import

4.3.1.2.2 Modo query

O modo query permite importar um subconjunto de valores definido por uma query SQL que

será interpretada do lado do SGBD e não do Hive. Nas importações em paralelo, a query deve

terminar com a flag “$CONDITIONS”, que tomará uma expressão única para cada processo do

Sqoop. Adicionalmente é também necessário fornecer o nome de uma coluna para o Sqoop

processar a divisão, --split-by. Este modo requer, para além da query, a especificação de uma

pasta de destino no HDFS através do parâmetro –target-dir, e um parâmetro para nomear a

tabela criada no Hive, –hive-table.

sqoop import \


--username hadoop \

--password hadoop \

--query 'SELECT top (1000) * FROM [ATSCHQUnver-

sionedDWH].[dbo].[FactMaterialMovement] WHERE $CONDITIONS '\

--m 1 \

--target-dir /opt/test2 \

--Hive-import \

--hive-table test1000 \



--Hive-drop-import-delims \

--split-by AreaKey

Durante os testes realizados observou-se que o Sqoop não interpretava corretamente as

condições de divisão. Por cada mapper, era feita a importação total da query, e não de uma

parte. As tabelas apareciam com registos quadruplicados, quando se usavam 4 tarefas de

mapeamento. A única solução para resolver o problema foi forçar o valor de –m a 1.

4.3.1.2.3 Modo Append Incremental

O Sqoop permite acrescentar informação a uma tabela existente de dois modos, incremental

e temporal. O modo temporal verifica a data em que os registos foram alterados e compara-a

com a data do último update. Se as alterações forem mais recentes então os valores serão

atualizados. O modo append incremental permite importar uma porção de dados de um modo

muito similar ao de query, mas com a diferença de acrescentar registos a uma tabela de forma

incremental, em vez de criar uma nova com os dados anteriores mais os dados novos. O modo

de append incremental é muito útil, uma vez que a solução pretendida visa a importação

periódica, de informação estática recolhida diariamente por uma RDBMS, para

armazenamento permanente no Hadoop. Apenas foi testado o modo de append incremental,

uma vez que no âmbito da solução, os dados são guardados uma vez e não sofrem

actualizações posteriores. Por questão de simplificação, nesta secção sempre que for

mencionado o modo append este refere-se a append incremental.

Para testar o append, foi necessário criar uma primeira tabela sobre a qual seria efetuado o

import no modo append, neste caso, optou-se por criar uma tabela com os primeiros 500

registos.

sqoop import \


--username hadoop \

--password hadoop \



--m 1 \


--Hive-import \

--hive-table test500append1000 \

--Hive-drop-import-delims

A sintaxe de um comando append é muito similar à do import, varia somente na adição dos

parâmetros --incremental append, –check-column, e –last-value. O –last-value é o valor do



ultimo registo conhecido da coluna especificada em –check-column. O sqoop usa este valor

para determinar a partir de que ponto deve incrementar informação mais recente. Nos testes

realizados este valor foi calculado manualmente através da consulta do último registo.

O seguinte comando exemplifica o append de 500 registos aos inicialmente importados. São

selecionados os primeiros 1000 registos como se pode verificar na query, mas apenas são

adicionados os registos cujo valor da coluna “createservicehistoryid” é superior a

1410130000000007141. Há portanto a limitação de uma coluna ter obrigatoriamente de

conter registos de forma sequencial, típica de uma coluna identity com chave simples. Contudo,

o mesmo não pode ser garantido para IDs com chaves compostas.

sqoop import \


--username hadoop \

--password hadoop \



--m 1 \


--Hive-import \


--incremental append \

--check-column createservicehistoryid \


--last-value 1410130000000007141

O teste anterior foi executado mais uma vez, sobre a mesma tabela, agora com 1000 registos.

Propositadamente, não foi alterado o parâmetro --last-value, ficando com o valor do registo

numero 500. Constatou-se que o Hive não foi capaz de detetar registos duplicados, a tabela

resultante acabou por ficar com 1500 linhas, sendo que as últimas 500 são uma cópia dos

registos entre o 500 e 1000.

sqoop import \


--username hadoop \

--password hadoop \



--m 1 \


--Hive-import \




--incremental append \

--check-column createservicehistoryid \


--last-value 1410130000000007141

No fim de cada import no modo append, o Sqoop imprime o valor do último registo inserido.

Este valor pode ser apanhado por um script de modo a tornar toda a operação automática

(White, 2012).

4.3.1.3 Importação para HBase

A importação para o HBase usando Sqoop é similar à importação para o Hive e partilha muitas

das operações. Na prática, o processo de importação para HBase lê cada registo da tabela de

origem e transforma-o numa operação “put” do HBase. Como o armazenamento no HBase é

feito por coluna e não por linha, são necessárias algumas flags adicionais, como por exemplo

o –hbase-family, que permite descriminar as famílias de colunas.

O seguinte comando exemplifica a importação de uma tabela em SQL Server para o HBase:

sqoop import \

--connect "jdbc:sqlserver://CMF-VM-ATS2:49725;database=ATSCHQUnver-

sionedDWH" \

--username hadoop \

--password hadoop \

--table "FactMaterialMovement" \

--hbase-create-table \

--hbase-table test \

--column-family cf \

--m 1

A operação foi testada várias vezes na distribuição HDP e Cloudera, e em todos os casos

demorou sempre acima de 30 minutos a concluir. Dos imports resultaram tabelas com um

número variável de linhas, entre as 40 e as 120, mas caricatamente o output apresentou

sempre a informação de que foram transferidos 0 bytes, como pode ser constatado na Figura

16 – Output para a consola do resumo da importação Sqoop para HBase.



Figura 16 – Output para a consola do resumo da importação Sqoop para HBase

Era evidente que a operação foi mal sucedida pois a tabela original tinha 662048 registos. Foi

também testado o modo de importação gráfico do HUE na distribuição da Cloudera para

desviar qualquer problema com o Sqoop. O modo gráfico do HUE importa os dados a partir de

um CSV. Foi usada a ferramenta de ligação externa do Excel para obter o CSV com os dados da

tabela e, em seguida, executou-se o processo de importação.

Figura 17 – Função de carregamento automático em volume para o HBase a partir de um

ficheiro csv



Mais uma vez o HBase foi capaz de criar a tabela, definir o column family passado por

parâmetro “cf” mas a página acaba por bloquear. Quando consultada a interface web do

serviço HBase (ip-do-no-master:60010) verifica-se que foi iniciado o pedido para criação da

tabela “factmaterialmovement” mas este fica pendurado, com tempo de resposta muito acima

do que seria expectável, como pode ser observado no quadrado amarelo da Figura 18.

Figura 18 – Log do HBase com a informação sobre tabela criada e operações pendentes

4.3.2 SQL2mongo

A ferramenta SQL2mongo está para o MongoDB assim como o Sqoop está para o Hadoop. Foi

escolhida para teste durante o projecto a fim de satisfazer o requisito de importação

automática de dados do SQLServer para uma base de dados NoSQL.

O programa tem já incorporado os drivers necessários para a comunicação com o MongoDB.

Fornece uma interface bastante simples com dois parâmetros de preenchimento obrigatório,

a string de conexão para o SQL Server e o endereço da máquina na qual se encontra a colecção

a receber os dados.

SQL SERVER CS- Data Source=CMF-VM-ATS2,49725;Initial Catalog=ATSCH-

QUnversionedDWH;User id=hadoop;Password=hadoop

MONGODB CS- mongodb://hslave1,hslave2:27018,hmaster:27019/?replica-

Set=rs0



Figura 19 – Interface da ferramenta de Importação do SQL2mongo

Como se pode observar na figura, são listadas as tabelas existentes na base de dados de origem

e o seu nome de destino no MongoDB. Neste caso foi selecionada a tabela

FactMaterialMovement e o mantido o nome para a colecção de destino. O Page Size deve ser

tanto maior quanto o número de registos a importar, tornando a operação ligeiramente mais

rápida. Ao contrário do Sqoop não é possível realizar importações incrementais nem filtrar os

dados de importação com uma query. Não existe também, como referido no terceiro capítulo,

a possibilidade de realizar um mapeamento personalizado dos tipos de dados. A tabela é

convertida automaticamente para um ficheiro BSON.



4.4 Linguagem familiar para consulta, em tempo útil, de

grandes volumes de dados

A solução pretendida visa a possibilidade de compressão dos dados guardados em bases de

dados NoSQL. Esta compressão deve ser feita recorrendo a um algoritmo eficiente, tanto do

ponto de vista da taxa de compressão como da utilização do processador. Outro requisito

apreciado é a existência de uma linguagem declarativa similar ao SQL que permita obter

informação, em tempo útil, dos dados armazenados. Estes dados devem poder ser

armazenados em formato bruto (schema free). Para satisfazer estes requisitos foram testadas

as ferramentas Hive e Impala.

4.4.1 Hive

Como foi visto na secção de apresentação das tecnologias, o Hive é uma ferramenta que

facilita o acesso e manuseamento dos dados armazenados no HDFS, simulando um ambiente

SQL. Para ser executado, o Hive necessita de uma instância Hadoop a correr na máquina, os

seus requisitos a nível de hardware limitam-se aos do Hadoop e pode também correr em

Windows.

4.4.2 Teste da instalação

Para testar a instalação (documentado no anexo B) do Hive foi feito o download de uma tabela

em formato CSV com vinte milhões de registos e quatro campos. O Hive permite a importação

de ficheiros em vários formatos, é contudo necessário criar uma tabela no hive com todos os

campos definidos antes de se proceder à importação. A tabela criada servirá de molde para

os dados do ficheiro a importar.

Download e extração da tabela para teste:

cd /opt/hadoop

wget http://files.grouplens.org/datasets/movielens/ml-20m.zip

unzip ml-20m.zip

Criar tabela para importar ficheiros csv:

hive

CREATE TABLE u_data (

userid INT,

movieid INT,

rating FLOAT,

unixtime STRING)

ROW FORMAT DELIMITED FIELDS TERMINATED BY ','



LINES TERMINATED BY '\n';

Importar dados do sistema de ficheiros local para o HDFS dentro da consola do Hive

hive

LOAD DATA LOCAL INPATH '/opt/hadoop/ml-20m/ratings.csv'

OVERWRITE INTO TABLE u_data;

O Hive inicia um processo de importação, após terminado, a tabela passa a fazer parte do

hive e toda a informação que estava no CSV passa, agora, a estar disponível para consultar

usando comandos SQL:

select min(rating) from u_data;

O Hive, por definição, utiliza como motor de execução o MapReduce. Durante a execução dos

testes foi possível detetar que existe um período de tempo inicial de ativação comum a todas

as tarefas MapReduce submetidas, sejam elas de grande ou de pequena dimensão.

Tabela 7 – Relação entre tempos de execução de queries com o volume de registos envolvido

Comando Registos da tabela Tempo

SELECT MIN(rating) FROM u_data; 20 Milhões 49s

INSERT INTO tabela_teste (id, valor1, valor2) VALUES

(1, 2, 3);

0 38s

SELECT MIN(rating) FROM tabela_teste; 1 35s

Como se pode verificar na Tabela 7, o tempo necessário para operação de selecionar o mínimo

de uma tabela de 20 milhões de registos ou 1 registo, apenas difere em 19%. Tal efeito pode

ser explicado pela natureza de trabalho em batch do MapReduce, é despendido tempo em

inúmeras operações como determinar a carga de trabalho a realizar, a distribuição pelos nós,

criação de contentores, a escrever resultados intermédios para o HDFS entre outros (Jiang, Ooi,

Shi, & Wu, 2010)

A introdução do YARN como sistema de gestão de recursos do Hadoop permitiu a integração

de várias tecnologias de processamento e pesquisa de dados tal como o Spark e Tez abordados

num capítulo anterior. Esta modularidade confere ao Hadoop uma maior versatilidade. O

utilizador pode escolher executar um trabalho pequeno em memória para respostas rápidas

(Spark) ou tratar um grande volume de informação em disco (Tez). Na secção seguinte serão



analisadas as tecnologias supracitadas e exploradas propriedades avançadas do Hive (Zhang,

2013), tendo por objetivo avaliar o impacto que têm no desempenho deste. Os dados

utilizados para os seguintes testes são provenientes da importação efetuada com o Sqoop.

Trata-se de uma tabela de factos de mais de 600 mil registos, com aproximadamente 1.03GB.

4.4.3 Hive on Spark

A par do Tez e MapReduce, o Hive tem também suporte para Spark, apesar de ser dirigido

para casos de uso de rápida resposta e análise de dados em stream, foi tomado em conta a

fim de averiguar se o seu rápido motor de processamento superava as capacidades do Tez.

Esta tecnologia foi testada usando a distribuição Hadoop da Cloudera.

Para ativar o Spark é necessário alterar uma variável na configuração da distribuição.

1- Abrir o separador do serviço Hive

2- Abrir a coluna de configuração

3- Pesquisar por “hive on spark”

4- Selecionar a opção que diz (“Enable Hive on Spark”)

5- Guardar alterações

O Hive passará então a usar o motor do Spark para executar as suas queries. Foi corrida a

query utilizada no processo de otimização com Tez e a fonte de dados foi a tabela

factmaterialmovement. O tempo de execução pode ser consultado na página de histórico de

trabalhos submetidos, Figura 20.

Figura 20 – Interface Job History do Hadoop com log de uma aplicação Spark



Os resultados obtidos ficaram muito aquém das expectativas, pois o Spark mostrou ser

bastante mais lento que o MapReduce. Estes resultados podem ser melhorados com o

afinamento de parâmetros do motor Spark, contudo, dado os fracos resultados iniciais e um

artigo5 publicado pela HortonWorks que compara a performance do Tez com o Spark, não foi

empenhado mais tempo no estudo desta solução.

4.4.4 Tez

O Tez é primariamente desenvolvido pela HortonWorks, que o disponibiliza pré-instalado na

sua distribuição Hadoop integrado com o Hive. Visto estar a trabalhar com uma instalação

Hadoop standalone e não uma distribuição, foi necessário fazer o download do Tez

separadamente. A instalação do Tez diferiu das outras ferramentas na medida em que

requeria compilação manual, daí ter sido necessário instalar compiladores e o gestor de

projetos maven. Durante a compilação dos diferentes módulos sucederam inúmeros erros por

falta de dependências. A resolução passou pela análise dos logs de erro em busca de nomes

de programas ou bibliotecas em falta. Por sua vez, as próprias dependências requeriam

pesquisa e download da ferramenta, seguida de compilação. Não foi possível resolver todos

os problemas, por isso foi feito o download de uma versão não oficial do Tez. A sua compilação

foi facilitada porque todas as dependências estavam expressas no ficheiro POM e o maven

efetuou automaticamente o download do que era necessário. A integração com o hive

mostrou-se, contudo, infrutífera. O Hive gerava sempre um erro na fase de mapping devido à

falta de uma classe no Tez. Dada a importância desta tecnologia e aos resultados obtidos,

optou-se por formatar as máquinas e instalar a distribuição Hadoop da HortonWorks. A

instalação de distribuições será detalhada mais à frente neste documento.

Para tirar partido do Tez é preciso defini-lo como motor de execução predefinido no Hive,

através do comando:

set hive.execution.engine=tez;

Para utilizar novamente o MapReduce basta substituir ‘Tez’ por ‘mr’:

set hive.execution.engine=mr;

De modo a constatar as melhorias do Tez em relação ao MapReduce, foi testada uma query

simples que percorre toda a tabela ‘factmaterialmovement’ e retorna o número de registos

da coluna ‘materialkey’

5 http://pt.slideshare.net/hortonworks/hive-on-spark-is-blazing-fast-or-is-it-final



SELECT COUNT(materialkey) FROM factmaterialmovement;

Figura 21 – Output para a consola de uma operação de MapReduce realizada no Hive

Como pode ser observado na Figura 21, recorrendo ao MapReduce, a query foi executada

em 95.439s.

A ativação do Tez permite representar as queries por grafos acíclicos dirigidos (DAG) em vez

de múltiplos estágios de MapReduce observáveis na Figura 21. Esta alteração evita problemas

de sincronização e overheads de IO, uma vez que o Tez escreve os seus dados intermédios

para memória e não para disco.

Figura 22 - Output para a consola de uma query realizada no Hive usando o motor de

execução Tez

Com a utilização do Tez o tempo de execução foi de 58.911 segundos. O valor apresentado



em ELAPSED TIME, apresentado a vermelho na Figura 22 corresponde ao tempo de execução

do trabalho no Tez e é sempre menor que o tempo total apresentado no Hive, uma vez que

não contabiliza o tempo de alocação de recursos e submissão do ‘job’ no YARN.

Tabela 8 – Comparação dos tempos de execução do Tez e MapReduce

Comando: SELECT COUNT(materialkey) FROM factmaterialmovement; Tempo

Tez 58.911s

MapReduce 95.439s

4.4.4.1 Vectorização (Ficheiros ORC)

A vectorização permite melhorar ainda mais a eficiência do Hive, em conjunto com o Tez. Esta

técnica pode executar queries até 125 vezes mais rápido (Gates & Bains, 2014). Quando a

técnica de vectorização é utilizada, o Hive seleciona blocos de 1000 registos por ciclo de

processamento em vez de um, poupando nas chamadas ao CPU e otimizando a utilização

global do cluster. Quando ativa, a vectorização permite também a diminuição da latência de

ativação e reativação de contentores, fazendo uso de dados quentes nestes contidos,

reduzindo enormemente o tempo de reexecução consecutiva de uma query.



4.4.4.2 Conversão para Ficheiros ORC

Para tirar partido da vectorização é necessário converter a tabela alvo pra o formato ORC. O

seguinte comando demonstra a conversão:

create table factmaterialmovement_orc stored as orc as select * from

factmaterialmovement;

É lançado um trabalho de MapReduce para fazer a conversão da tabela:

Figura 23 – Operação de conversão de uma tabela Hive para ficheiro ORC usando

MapReduce

Como se pode constatar na Figura 23, o trabalho MapReduce dividiu a conversão em 5 etapas,

demorando um total de 237.868 segundos. Este tempo de conversão pode ser melhorado

através da utilização do Tez, bastando para isso defini-lo como motor de execução.



Figura 24 - Operação de conversão de uma tabela Hive para ficheiro ORC usando Tez

A conversão com o Tez utilizou 8 contentores e demorou 147.375 segundos.

Tabela 9 – Comparação do tempo de conversão da tabela Factmaterialmovement usando o

Tez e usando MapReduce

Comando: create table factmaterialmovement_orc stored as orc as

select * from factmaterialmovement;

Tempo

Tez 237.868s

MapReduce 147.375s

Ao formato de ficheiro ORC está também associado um algoritmo de compressão. A seguinte

tabela compara o tamanho da tabela importada pelo Sqoop em ficheiro de texto e a tabela

convertida no formato ORC:

Tabela 10 – Comparação do tamanho final das tabelas nos formatos TextFile e ORC File

Tipo de Ficheiro Tamanho

TextFile 1052.21 MB

ORC File 14.32 MB

O tamanho das tabelas foi verificado através do explorador de ficheiros da interface WEB

Hadoop, acessível a partir do endereço da máquina a executar o serviço namenode, na porta

50070. Por exemplo,

slave2:50070/explorer.html#/apps/hive/warehouse/factmaterialmovement

Foram comparados uma vez mais os tempos de resposta antes de se ativar a vectorização.

Desta forma pode ser medido o impacto do tamanho dos ficheiros.



Tabela 11 – Comparação entre o tempo de execução de uma query numa tabela em formato

TextFile com outra em formato ORC File

Comando: SELECT COUNT(materialkey) FROM

factmaterialmovement_orc;

Tempo

TextFile + Tez 58.911s

ORC File + Tez 40.085s

A principal causa para o melhor desempenho está associada com a redução do tamanho do

ficheiro. Uma vez que se trata de uma query que exige uma leitura completa da tabela, todo

o conteúdo da mesma será carregado. É naturalmente muito mais rápido ler do disco 14 MB

do que 1 GB. Pode também constatar-se, pela Figura 25, que a utilização do CPU com o ficheiro

ORC é muito similar à do ficheiro de texto, o que indica que o algoritmo de compressão é

bastante leve, ZLIB por omissão (Shanklin, 2013).

Figura 25 – Gráfico de utilização das CPUs no cluster

4.4.4.3 Ativação da Vectorização

Depois de ter uma tabela no formato ORC pode-se então ativar a vectorização utilizando para

isso o seguinte comando:

set hive.vectorized.execution.enabled;

A query foi testada novamente usando Tez como motor e foi possível constatar uma grande



melhoria quando a Vectorização está ativada.

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

Comando: SELECT COUNT(materialkey) FROM factmaterialmovement_orc; Tempo

Sem Vectorização + ORC File + Tez 40.085s

Com Vectorização + ORC File + Tez 20.372s

Reexecução (Hot containers) 5.337s

Como se pode ver na Tabela 12 a reexecução de queries tem ganhos muito interessantes

recorrendo a dados recentes nos contentores. Na Figura 26 é demonstrada a reutilização de

contentores com dados quentes (Hot Containers):

Figura 26 – Demonstração do efeito Hot Container



Se uma query for executada de forma consecutiva, duas ou mais vezes, tira partido do efeito

de Hot container, explorado pela vectorização (Zhang, 2013).

4.4.4.4 CBO

O motor de otimização baseada em custos usa estatísticas referentes às tabelas do Hive para

produzir um query plan otimizado. Os principais benefícios são a otimização sem necessidade

de recorrer a especialistas e aumento da eficiência de utilização do cluster.

As estatísticas podem ser ativadas para colunas, linhas ou partições. O seguinte comando ativa

o uso de estatísticas para colunas e partições através do CBO:

set hive.compute.query.using.stats = [true, **false**];

set hive.stats.fetch.column.stats = [true, **false**];

set hive.stats.fetch.partition.stats = [true, **false**];

set hive.cbo.enable = [true, **false**];

Embora o Hive já passe a fazer uso das estatísticas para otimizar as queries com os comandos

anteriores, ainda é necessário processar as estatísticas pretendidas para uma tabela em

particular. Neste caso foi usado um tipo de estatística por coluna, a tabela foi

‘factmaterialmovement_orc’ e a coluna foi ‘materialkey’.

ANALYZE TABLE factmaterialmovement_orc COMPUTE STATISTICS FOR COLUMNS

materialKey;

Figura 27 – Demonstração da análise de estatísticas a uma tabela ORC

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


(engine=Tez)



CBO Disbled + Vectorização + ORC File + Tez 20.372s

CBO Enabled + Vectorização + ORC File + Tez 13.573s


4.4.4.5 Conclusões

As otimizações aproximam cada vez mais o Hive de um sistema interativo, capaz de executar

operações em bloco sobre uma grande quantidade de dados e em tempo útil. A tabela testada

tem uma dimensão muito inferior às cargas de trabalho para o qual o Hive foi projetado,

contudo, foi possível observar melhorias muito interessantes. Estas otimizações serão tanto

mais notórias quanto maior for o conjunto de dados analisados.

Tabela 14 – Comparação entre tempos de execução de uma query usando apenas

MapReduce em relação à utilização de otimizações


MapReduce 95.439s

CBO + Vectorização + ORC File + Tez 13.573s


Como se pode observar na Tabela 14 as otimizações totalizaram uma melhoria de

aproximadamente 27 vezes face ao MapReduce.



4.5 Visualização de dados armazenados num sistema NoSQL

a partir de ferramentas externas

Um dos aspectos valorizados pela empresa nos sistemas de base de dados é a possibilidade

de aceder e manipular os dados através de uma ferramenta com interface gráfica. A maioria

das tecnologias testadas funciona à base de linha de comandos pelo que foi imperativo

efectuar uma pesquisa de utensilios por forma a satisfazer o presente requisito. Os resultados

obtidos são debatidos em seguida.

4.5.1 SQuirreL

O objectivo inicial era conseguir criar uma ligação entre o Hive e o Excel, a fim de efectuar

cálculos sobre os dados de uma determinada tabela e, no final, exportar os resultados para

outra tabela Hive. A criação da ligação não se conseguiu concretizar apesar de terem sido

seguidos com rigor todos os passos indicados pela HortonWorks na sua documentação6. O

insucesso da operação pode dever-se ao estado imaturo dos drivers que a HortonWorks

disponibiliza. Após alguma pesquisa sobre métodos de acesso ao Hive a partir de máquinas

externas, foi encontrada a ferramenta SQuirreL. Embora não permita a manipulação directa

para cálculos como no Excel, o Squirrel fornece uma interface de querying que permite

consultar dados das tabelas Hive, independetemente da máquina e do sistema operativo em

que corre.

4.5.1.1 Instalar drivers

O SQuirreL é um programa bastante modular na medida em que permite a conexão a qualquer

base de dados desde que seja fornecido o driver apropriado. Os drivers necessários para

conectar ao Hive podem ser encontrados nas pastas de instalação da distribuição Hadoop.

HIVE_HOME/build/dist/lib/*.jar

HADOOP_HOME/hadoop-*-core.jar

O conteúdo destas pastas foi copiado por FTP para o Windows e colocado na pasta de drivers

do SQuirreL. Pode então ser iniciado o processo de configuração do driver Hive, para além de

um nome deve também ser fornecido um URL para a máquina na qual corre o servidor do Hive,

neste caso hslave1, na porta 10000. O Class Name indica o nome da classe responsável pelo

comportamento do driver, que é neste caso org.apache.hadoop.hive.jdbc.HiveDriver. Depois

de validados todos os campos basta terminar o processo e iniciar a ligação.

6 http://hortonworks.com/hadoop-tutorial/how-to-use-excel-2013-to-access-hadoop-data/



Figura 28 – Menu de configuração de drivers SQuirreL

4.5.1.2 Teste da instalção

Figura 29 – Interface de input de comando SQL do SQuirreL

Na Figura 26 pode ver-se a interface gráfica disponibilizada por esta ferramenta. Os comandos

inseridos são enviados e processados de modo distribuído no Hive, tal como se fosse feito um

uso directo da linha de comandos numa máquina do cluster Hadoop. Através desta ligação

podem também ser enviados parâmetros “set” para, enventualmente, alterar configurações

de execução do Hive.



Figura 30 – Informação detalhada, apresentada pelo SQuirrel, do resultado de uma query

No final é, ainda, possível aceder a várias informações sobre a query executada, a data em que

foi lançada, o tempo decorrido, entre outros.

4.6 Sistema de instalação automática e de fácil configuração

com componente de monitorização

A instalação do conjunto de ferramentas equacionadas para a solução é morosa e o seu

monitoramento é arcaico. Estableceu-se então o objectivo de testar soluções chave-na-mão

existentes, que dipõem de instalação automática, monitorização dos recursos do cluster e do

estado individual de cada nó. Os testes às soluções encontradas são discutidos em seguida.

As distribuições proporcionam uma solução chave-na-mão, contemplam a maioria das

aplicações do ecossistema Hadoop e a sua instalação é facilitada por guias gráficos. Baixam a

barreira de entrada para o mundo Hadoop, uma vez que todas as configurações de sistema

são feitas automaticamente. Fornecem também uma interface gráfica para reiniciar serviços,

adicionar nós, monitorizar os recursos do cluster e trabalhos submetidos, entre outros. Este

tipo de solução só foi tomada em consideração após terem surgido problemas de instalação e

integração do Tez com o Hive. Até então, era feita uma instalação manual dos programas à

medida que estes eram necessários. Este método parecia muito mais indicado do que



proceder à instalação de várias ferramentas que ficariam a correr no sistema a consumir

recursos mas que não seriam utilizadas. Após a instalação e teste das distribuições, constatou-

se que era possível adicionar e remover serviços não utilizados de forma expedita. Mesmo

simulando um ambiente básico com Hadoop e Hive+Tez, a utilização de memória RAM do

sistema era totalmente utilizada mesmo quando nenhum trabalho estava a ser processado, o

que não ocorria na instalação manual. Em seguida serão demonstrados os passos de instalação

para duas das distribuições Hadoop mais utilizadas.

4.6.1 HortonWorks Data Platform (HDP)

A distribuição da HortonWorks apresenta uma solução totalmente gratuíta e preparada para

um ambiente de produção. A sua instalação é guiada por um assistente gráfico que fornece

informações detalhadas a cada passo, facilitando todo o processo.

4.6.1.1 Instalação do HDP 2.3

A instalação do HDP, tal como seguido pelo manual de referência7 , é acompanhada pela

interface gráfica do Ambari, o que, como se poderá observar, facilita bastante o processo.

4.6.1.1.1 Pré requisitos

Desativar firewall. Este passo facilita a configuração do ficheiro IPtables com inúmeras regras

por cada porto utilizado pelos vários serviços. Como se trata apenas de um ambiente de

teste, optou-se por desativar a firewall:

service iptables save

service iptables stop

chkconfig iptables off

Ativar ntpd. Este passo garante que as máquinas tem os relógios atualizados e sincronizados

entre elas:

chkconfig ntpd on

service ntpd start

ntpdate -u se.pool.ntp.org

Desativar THP. Transparent Huge Pages, é um módulo de gestão de memória do kernel Linux

responsável pela redução de overheads do serviço Translation Lookaside Buffer (TLB) nas

ações de pesquisa de páginas de memória. Contudo, o THP não é adequado para suportar

cargas de trabalho típicas de uma base de dados que tendem a ter padrões de acesso aleatório

7 http://docs.hortonworks.com/HDPDocuments/Ambari-

2.0.0.0/Ambari_Doc_Suite/ADS_v200.html#Installing_HDP_Using_Ambari



em vez de contíguos. Para assegurar a melhor performance possível, a HortonWorks aconse-

lha a desativação deste serviço.

echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag

echo never > /sys/kernel/mm/transparent_hugepage/enabled

Para testar que o serviço foi desativado devem ser corridos os seguintes comandos:

cat /sys/kernel/mm/redhat_transparent_hugepage/defrag

cat /sys/kernel/mm/redhat_transparent_hugepage/enabled

resultado esperado: always madvise [never]

Configurar uma chave ssh para fazer login nas restantes máquinas sem ser exigida palavra

passe. Este passo pode ser replicado consultando o capítulo Hadoop, secção da configuração

de nós.

Fazer download do repositório do Ambari:

cd /etc/yum.repos.d/

wget -nv http://public-repo-1.hortonworks.com/ambari/centos6/2.x/up-

dates/2.0.1/ambari.repo

Depois de definido o repositório, a instalação do Ambari pode agora ser feita através do co-

mando yum:

yum install Ambari-server

Correr o wizard de instalação com as opções default e iniciar o serviço:

Ambari-server setup

Ambari-server start



4.6.1.1.2 Interface de instalação

Uma vez iniciado o serviço, podemos aceder à sua interface gráfica através do endereço da

máquina no porto 8080, fazendo login com o nome de utilizador ‘admin’ e senha ‘admin’.

Figura 31 – Página de Login do Apache Ambari

Em seguida, é apresentado um menu de operações no qual consta a opção de criar um novo

cluster. O processo de criação de um novo cluster consiste em informar o Ambari dos IPs ou

Nomes dos Hosts nos quais se pretende instalar a distribuição previamente selecionada,

fornecendo também uma chave RSA para o processo de instalação executar comandos em

todas as máquinas com login automático.

Figura 32 – Menu de configuração das máquinas e respectiva chave RSA durante a instalação

do HDP



Na fase seguinte o Ambari verifica se as máquinas cumprem os requisitos necessários à

instalação da distribuição selecionada. Estes requisitos prendem-se essencialmente com

versões de software incompatível ou problemas de permissões. Depois de resolvidos todos os

warnings é apresentada uma lista para escolher os programas pretendidos. Optou-se apenas

pelo conjunto de programas essencial, Tabela 15, para os testes a executar, uma vez que para

o pacote completo a RAM recomendada é de 8GB por nó.

Tabela 15 – Lista de componentes do HDP selecionados para instalação

COMPONENTES INSTALADOS

HDFS

YARN+MAPREDUCE2

TEZ

HIVE

HBASE

PIG

SQOOP

ZOOKEEPER

AMBARI METRICS

O aspeto mais importante é a distribuição dos serviços pelos diferentes nós. Esta deve ser feita

tendo em conta as características de cada nó e a natureza de trabalho que determinado

componente possui. Na prática fará sentido mover os componentes mais exigentes para as

máquinas com os melhores recursos e manter os serviços básicos nas máquinas de menor

poder. A Figura 33 apresenta a distribuição escolhida:



Figura 33 – Distribuição dos diferentes componentes do HDP pelas máquinas do cluster

No próximo passo são definidos quais os nós que exercem o papel de servidor e de cliente. A

escolha dos clientes terá influência no sítio onde serão executados os comandos para aceder

aos serviços. Neste passo, as máquinas com o papel de DataNode farão parte do HDFS e terão

a função de armazenamento dos dados Hadoop. Os nós com o serviço NodeManager serão

vistos como trabalhadores para desempenhar os trabalhos submetidos no YARN. As máquinas

que fazem parte do RegionServer são utilizadas pelo HBase para armazenamento e

processamento de dados.



Figura 34 – Menu de atribuição de componentes HDP cliente, e servidor, a cada nó

O Ambari passa então por um processo de cópia de ficheiros de instalação entre máquinas e

execução de scripts para definição de variáveis de ambiente etc. Após um período de 1 hora,

dependendo dos serviços a instalar, o processo termina e o cluster fica imediatamente

utilizável.

4.6.1.2 Desinstalação do HDP 2.3

O HDP deixa uma grande pegada no sistema, isto devido ao seu assistente de desinstalação

muito pouco eficaz. Não são totalmente limpos os pacotes de programas, pastas de instalação,

pastas de logs, pastas de configuração, pastas de utilizadores criados automaticamente, entre

outros. Nesta secção serão demonstrados alguns passos para remover completamente o HDP

(Taurus, 2015) . Embora não tenha sido utilizada, a utilização da ferramenta PDSH permite

replicar os comandos para todos os nós do cluster, no qual tenha sido instalado o HDP e se

pretenda efetuar a remoção.

Parar todos os serviços através da interface web.

Parar o processo agent e server em todos os nós:

Ambari-server stop

ambari-agent stop

Ambari-server reset

Executar o script de remoção fornecido pela Hortonworks.

python /usr/lib/python2.6/site-packages/ambari_agent/HostCleanup.py



Remover todos os pacotes instalados associados ao HDP. Basicamente, se corrermos o

comando “yum list installed | grep HDP”, e "yum list installed | grep HDP-UTILS" depois da

desinstalação, o resultado deve ser vazio.

yum -y remove `yum list installed | grep -i hadoop | cut -d. -f1 |

sed -e :a -e '$!N; s/\n/ /; ta'`

yum -y remove Ambari*

yum -y remove `yum list installed | grep -w 'HDP' | egrep -v -w | cut

-d. -f1 | grep -v "^[ ]" | sed -e :a -e '$!N; s/\n/ /; ta'`

yum -y remove `yum list installed | egrep -w 'hcata-

log|hive|hbase|zookeeper|oozie|pig|snappy|hadoop-lzo|knox|hadoop|hue'

| cut -d. -f1 | grep -v "^[ ]" | sed -e :a -e '$!N; s/\n/ /; ta'`

yum -y remove mysql mysql-server

rm -rf /var/lib/mysql

yum -y remove postgre*

Limpar pastas criadas para os programas do HDP:

rm -r `find /usr/bin -maxdepth 1 | egrep -wi 'mysql|hcata-

log|hive|hbase|zookeeper|oozie|pig|snappy|hadoop|knox|hadoop|hue|am-

bari|Tez|flume|storm|accumulo|spark|kafka|falcon|slider|gan-

glia|nagios|phoenix' | sed -e :a -e '$!N; s/\n/ /; ta'`

rm -r `find /etc -maxdepth 1 | egrep -wi 'mysql|hcata-




rm -r `find /var/log -maxdepth 1 | egrep -wi 'mysql|hcata-




rm -r `find /tmp -maxdepth 1 | egrep -wi 'hadoop' | sed -e :a -e

'$!N; s/\n/ /; ta'`

rm -r /hadoop

rm -rf /var/run/hdfs-sockets

sudo rm -r /tmp/amba*

sudo rm -r /tmp/sqoop*

sudo rm -r /tmp/*_resources

sudo rm -r /tmp/?etty*

sudo rm -r /usr/hdp

find /usr/bin -lname '/usr/hdp*' -delete



sudo rm -r /usr/lib/Ambari*

sudo rm -r /usr/lib/*hbase

Apagar utilizadores

sudo userdel -rf spark

sudo userdel -rf ams

sudo userdel -rf httpfs

sudo userdel -rf mysql

sudo userdel -rf hive

sudo userdel -rf hbase

sudo userdel -rf Tez

sudo userdel -rf sqoop

sudo userdel -rf hcat

sudo userdel -rf mapred

sudo userdel -rf ambari-qa

sudo userdel -rf zookeeper

sudo userdel -rf hdfs

sudo userdel -rf yarn

sudo groupdel hadoop

sudo groupdel HTTPFS

4.6.2 Cloudera Data Hub (CDH)

A par da distribuição da HortonWorks, o Cloudera Data Hub fornece uma solução chave na

mão com uma grande variedade de ferramentas do ecossistema Hadoop. Apesar de ser

gratuíta para download, alguns dos seus componentes são disponibilizados em modo de teste

por um período de 60 dias, como é o caso do Cloudera Impala e a componente de métricas

em tempo real do Cloudera Manager. Os requisitos do sistema são similares ao HDP da

Hortonworks. As máquinas devem ter uma versão Linux compatível e o Java instalado e 4GB

de RAM. Assegurados estes requisitos, pode então proceder-se à instalação da distribuição. As

máquinas usadas para esta instalação foram a hmaster, hslave1 e hslave2, numa arquitetura

idêntica à instalação do HDP.

4.6.2.1 Instalação do CDH 5.4

A instalação do Cloudera Data Hub pode ser feita, tal como consultado num manual 8

disponível na Internet, de forma automatizada recorrendo ao Cloudera Manager, algo

parecido ao processo de instalação do HDP usando Apache Ambari. Todos os pré-requisitos

8 http://www.bogotobogo.com/Hadoop/BigData_hadoop_CDH5_Install.php



efectuados no HDP devem também ser aplicados à instalação do CDH. O download do

Cloudera Manager requer um registo prévio no site da Cloudera a partir do endereço:

http://www.cloudera.com/content/cloudera/en/user/registration.html

Após o registo, é enviado um email com uma password que deve ser usada para o download.

Uma vez que o centOS não dispunha de uma interface gráfica, foi usado um comando wget

com os parâmetros de login para proceder à autenticação.

wget http://archive.cloudera.com/cm5/installer/latest/cloudera-man-

ager-installer.bin --user=1111439_isep.ipp.pt --pass-

word=9Gj02u0J7ELOXNZ

Em Seguida pode ser iniciado o binário de instalação:

sudo ./cloudera-manager-installer.bin

É iniciada uma aplicação com uma interface gráfica de terminal que nos guia por todo o

processo. Foram escolhidas todas as opções por omissão.

Figura 35 – Interface de instalação do CDH

No final, de forma semelhante ao que acontece com o Ambari no HDP, deve-se aceder a uma

página Web a partir da qual são definidos os nós do cluster e os serviços a instalar.

http://archive.cloudera.com/cm5/installer/latest/cloudera-manager-installer.bin

http://archive.cloudera.com/cm5/installer/latest/cloudera-manager-installer.bin



Figura 36 – Passo final da instalação do Cloudera Manager

A conta por definição a usar na aplicação Web é admin, com password admin. No seguinte

passo deve ser escolhida uma de três versões do serviço, Cloudera Express, Cloudera Data Hub

Enterprise Trial e Cloudera Enterprise. Para os testes a realizar foi escolhida a versão CDH Trial

Enterprise de 60 dias que dispõe de todos os serviços, à excepção de apoio técnico

personalizado. Todo o restante processo de instalação é idêntico ao descrito anteriormente no

Ambari. Deve ser fornecida uma lista de endereços das máquinas nas quais se pretende

instalar o CDH. Deve ser previamente configurado o acesso entre máquinas através de SSH, e

selecionar os serviços que se pretendem instalar.

Tabela 16 - Lista de componentes do CDH selecionados para instalação

COMPONENTES INSTALADOS

HDFS

YARN+MAPREDUCE2

HIVE

HBASE

HUE

IMPALA

OOZIE

SQOOP

SPARK

ZOOKEEPER



A distribuição dos serviços foi replicada do HDP, sendo que os serviços adicionais, Impala e

Hue e Spark foram instalados na máquina Hslave2. Após um processo de instalação de

aproximadamente 20 minutos é-se redirecionado para a página inicial do Cloudera Manager

no qual se tem informação sobre o estado do cluster.

Figura 37 – Interface de monitorização de administração do Cloudera Manager

Apesar dos requisitos mínimos serem de 4GB de RAM por nó, foram gerados avisos devido a

falta de memória e ao excessivo consumo de memória swap por parte de alguns serviços.

4.6.2.2 Desinstalação do CDH 5.4

O processo de desinstalação do CDH mostrou-se mais eficaz que o do HDP. Primeiro param-se

todos os serviços através da interface Cloudera Manager.

Corre-se o script fornecido pela Cloudera para a desinstalação e apagam-se as pastas do

Cloudera Manager:

sudo ./uninstall-cloudera-manager.sh

sudo rm -Rf /usr/share/cmf /var/lib/cloudera* /var/ca-

che/yum/cloudera* /var/log/cloudera* /var/run/cloudera*

Em todos os outros nós devem limpar-se as pastas dos programas instalados:

for u in hdfs mapred cloudera-scm hbase hue zookeeper oozie hive im-

pala flume; do sudo kill $(ps -u $u -o pid=); done

sudo rm -Rf /var/lib/flume-ng /var/lib/hadoop* /var/lib/hue

/var/lib/oozie /var/lib/solr /var/lib/sqoop*

sudo rm -Rf /dfs /mapred /yarn

sudo rm /tmp/.scm_prepare_node.lock



5 Conclusões

Com o desenvolvimento deste projeto foi possível verificar o estado atual de várias tecnologias

NoSQL, as suas capacidades e casos de uso, vantagens e desvantagens em relação a uma

RDBMS (Relational Database Management System). Este estudo permitiu formar um conceito

para uma solução prática, que engloba várias ferramentas, cada uma delas essencial para

resolver uma parte do problema, estruturando uma solução funcional no seu todo.

No estado atual, a solução permite a importação de um conjunto de dados personalizado, a

partir do SQL Server para uma tabela Hive, recorrendo ao Sqoop. Esta tabela pode ser criada

automaticamente na importação, ou optar por um modo incremental, adicionando apenas

informação nova a uma tabela já existente. Recorrendo ao Hive, diretamente ou através do

SQuirreL, o sistema fornece uma interface de interrogação muito familiar com o dialeto SQL.

Ao tirar partido da arquitetura distribuída e altamente escalável do Hadoop, o Hive é capaz de

executar queries sobre tabelas com milhões de linhas, num tempo inversamente proporcional

ao número de máquinas do cluster. A solução contempla também a utilização do motor de

execução Tez de forma a melhorar os tempos de resposta do Hive, sendo que esta

implementação só é possível graças ao novo gestor de recursos YARN. Outras otimizações,

como vectorização, CBO e o formato de ficheiro ORC, mostraram melhorias na ordem dos 2700%

no tempo de resposta, bem como uma redução em 74 vezes no espaço ocupado pelas tabelas.

O sistema de ficheiros distribuído (HDFS) contemplado na solução através da utilização do

Hadoop confere ao sistema uma capacidade de ingestão de dados cumulativa, a par de

tolerância a falhas fruto da replicação dos dados.

O HBase foi considerado para estudo devido à sua capacidade de varrer os dados de forma

muito eficiente e de fornecer tempos de reposta interativos. Contudo a importação com o

Sqoop não teve sucesso, e sendo um requisito básico para a solução, não foi incluído na mesma.

O Cassandra apresenta resultados muito acima da concorrência nos testes sintéticos de escrita

e leitura. Foi tomado em consideração para estudo, por forma a averiguar se o seu

desempenho nas operações I/O, tinha impacto significativo na procura de dados das suas

tabelas internamente armazenadas. Não foi possível contudo encontrar uma ferramenta

gratuita que importasse os dados do SQL Server e, como não era do intuito do projeto

desenvolver uma ferramenta de ETL, o estudo do Cassandra foi abandonado. O MongoDB

revelou ser uma solução razoável, com ferramenta de importação, replicação de dados,

processamento distribuído e escalável, características muito próximas do Hadoop. Os testes



efetuados revelaram, contudo, que o seu desempenho foi muito limitado e o espaço ocupado

em disco rapidamente se tornaria impraticável em larga escala.

A solução encontrada não será aplicada imediatamente a um ambiente de produção na Critical

Manufacturing por não existir ainda um volume de dados que o justifique. Acima de tudo, o

trabalho realizado permite abrir caminho para novas abordagens de armazenamento de dados.

Provou-se efetivamente que é possível tirar partido da escalabilidade e capacidade de trabalho

do Hadoop, sem recorrer a equipas especializadas ou desenvolver novos programas, assim

como armazenar de forma altamente eficiente grandes quantidades de informação.



5.1 Requisitos realizados

Seguidamente serão revistos os requisitos apresentados no capítulo de introdução e para cada

um deles será descrito o seu grau de realização. De notar que os requisitos foram sendo

definidos ao longo do projeto, dependendo em maior parte das tecnologias disponíveis e não

tanto das exigências de um Product Owner, isto porque o objetivo era explorar o que as

tecnologias NoSQL tinham para oferecer e até que ponto se distinguiam das bases de dados

convencionais.

Tabela 17 – Requisitos do projeto

REQUISITO GRAU DE TANGIBILIDADE

RESPOSTA ÀS QUERIES EM TEMPO ÚTIL Atingido

APROVEITAR O CONHECIMENTO DOS PRO-FISSIONAIS COM CONHECIMENTOS DE SQL PARA INTERAGIR COM O SITEMA NOSQL

Atingido

TOLERANCIA A FALHAS E ECONÓMICO Atingido

ALTAMENTE ESCALÁVEL, VERTICAL E HORI-ZONTALMENTE

Atingido

DESCARREGAR PERIODICAMENTE INFOR-MAÇÃO PARA O SISTEMA A DESENVOLVER

Atingido

CAPACIDADE DE VISUALIZAR UMA TABELA A PARTIR DE UMA MÁQUINA DE UM CO-LABORADOR

Atingido

SISTEMA DE INSTALAÇÃO AUTOMÁTICA E DE FÁCIL CONFIGURAÇÃO

Atingido

MONITORIZAÇÃO DO ESTADO DE TODAS AS MÁQUINAS DO CLUSTER

Atingido

RESPOSTA ÀS QUERIES EM TEMPO ÚTIL Atingido

APROVEITAR O CONHECIMENTO DOS PRO-FISSIONAIS COM CONHECIMENTOS DE SQL PARA INTERAGIR COM O SITEMA NOSQL

Atingido

TOLERANCIA A FALHAS E ECONÓMICO Atingido

ALTAMENTE ESCALÁVEL, VERTICAL E HORI-ZONTALMENTE

Atingido

5.2 Limitações e trabalho futuro

A solução apresentada neste documento consegue cumprir os requisitos mínimos apurados.

Contudo, existe uma série de passos intermédios que são necessários devido a limitações das

próprias tecnologias. Foi concluído que o formato de ficheiros mais rápido para Hive é o ORC,



mas para manter a funcionalidade de importação de dados do SQL Server através do Sqoop,

apenas se poderiam usar simples tabelas de texto, uma vez que o Sqoop ainda não suporta

importação direta para ficheiros do tipo ORC, havendo a necessidade de fazer a conversão

após importação, implicando apagar tabelas com vários gigas para inserir apenas umas linhas

de registos. Há que ter em conta as limitações do Hive quanto ao seu modelo de consistência,

não é possível garantir transações ACID, e embora seja uma ferramenta bastante completa,

ainda não suporta bastantes operações nativas do SQL como o UNION ou INTERSECT, o que

impossibilita uma utilização direta de algumas queries que atualmente correm no SQL Server,

sendo o mesmo válido para alguns tipos de dados. Durante o desenvolvimento do projeto foi

possível constatar uma limitação tecnológica que obrigou à instalação de um novo sistema

operativo nas máquinas, isto porque as distribuições Hadoop não eram compatíveis com o

CentOS 7.

O trabalho futuro passa pela automatização de todo o processo de importação e querying,

agendando a execução de um script feito manualmente ou com o auxílio de ferramentas

denominadas de “Workflow Engines” (Crobak, 2013), em especial o Apache Oozie 9 . Há

também que testar o impacto que a criação de índices e particionamento de tabelas tem no

desempenho do Hive, assim como testar a estabilidade do sistema com mais máquinas e com

mais recursos. O descobrimento tardio de tecnologias concorrentes muito similares ao Hive e

Tez não permitiu o seu estudo aprofundado. Contudo, o Apache Drill10 assim como o formato

de ficheiros Parquet11 deve ser avaliado em confronto com Hive e ORC Files. Quanto ao Tez,

deve ser analisado o seu desempenho em comparação com o Apache Phoenix12.

9 http://oozie.apache.org/ 10 https://drill.apache.org/ 11 https://parquet.apache.org/ 12 https://phoenix.apache.org/



5.3 Apreciação final

Este projeto exigiu uma extensa pesquisa inicial dado o desconhecimento quase total do tema.

Sem uma detalhada lista de requisitos definida à partida, filtrar temas de pesquisa e jargões

que surgiam constantemente demonstrou-se laborioso. Houve uma grande dificuldade em

entender de que maneira as diferentes ferramentas se interligavam entre si e qual a finalidade

a que se destinavam. Com o desenrolar do projeto, os requisitos foram sendo moldados com

base nas melhores características das ferramentas testadas. A tenra idade das tecnologias

evidenciou alguma falta de documentação e apoio técnico, principalmente sobre problemas

frequentemente encontrados. Na sua maioria, as tecnologias eram de natureza comunitária,

o que pode explicar a falta de instruções mais profissionais. Embora não tenha sido possível

testar com a profundidade desejada todas as tecnologias propostas inicialmente, a verdade é

que muitas outras foram descobertas e vieram a mostrar-se importantes para a solução.

Apesar de todos os entraves os principais requisitos foram cumpridos.


Rui Fernando Alves Rebelo MagalhãesRui Fernado Alves Rebelo Magalhães

90

Bibliografia

Apache Ambari. (2015). Ambari - Apache Ambari - Apache Software Foundation. Retrieved June 25, 2015, from https://cwiki.apache.org/confluence/display/AMBARI/Ambari

Borthakur, D. (2013). HDFS Architecture Guide. Retrieved June 29, 2015, from https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html

Bradberry, R., & Lubow, E. (2013). Practical Cassandra: A Developer’s Approach. Retrieved from http://dl.acm.org/citation.cfm?id=2591783

Brewer, E. (2012). CAP twelve years later: How the “rules” have changed. Computer, 45(2), 23–29. http://doi.org/10.1109/MC.2012.37

Brewer, E. A. (2000). Towards robust distributed systems (abstract). In Proceedings of the nineteenth annual ACM symposium on Principles of distributed computing - PODC ’00 (p. 7). New York, New York, USA: ACM Press. http://doi.org/10.1145/343477.343502

Burrows, M. (2006). The Chubby lock service for loosely-coupled distributed systems, 335–350. Retrieved from http://dl.acm.org/citation.cfm?id=1298455.1298487

Capriolo, E., Wampler, D., & Rutherglen, J. (2012). Programming Hive. Retrieved from http://dl.acm.org/citation.cfm?id=2464898

Celko, J. (2014). JOE CELKO’S COMPLETE GUIDE TO NoSQL: What every SQL professional needs to know about nonrelational databases.

Chang, F., Dean, J., Ghemawat, S., Hsieh, W. C., Wallach, D. A., Burrows, M., … Gruber, R. E. (2006). Bigtable: A distributed storage system for structured data. In 7th Symposium on Operating Systems Design and Implementation (OSDI ’06), November 6-8, Seattle, WA, USA (pp. 205–218). USENIX Association. Retrieved from http://research.google.com/archive/bigtable-osdi06.pdf

Chodorow, K., & Dirolf, M. (2010). MongoDB: The Definitive Guide. O’Reilly Media.

Cloudera. (2015). Cloudera Manager. Retrieved June 25, 2015, from http://www.cloudera.com/content/cloudera/en/products-and-services/cloudera-enterprise/cloudera-manager.html

Codd, E. F. (1970). A relational model of data for large shared data banks. Communications of the ACM, 13(6), 377–387. http://doi.org/10.1145/362384.362685

Crobak, J. (2013). Workflow Engines for Hadoop. Retrieved July 17, 2015, from http://pt.slideshare.net/jcrobak/data-engineermeetup-201309



Cutting, D. (1999). Apache Lucene - Apache Lucene Core. Retrieved June 30, 2015, from https://lucene.apache.org/core/

Cutting, D., & Cafarella, M. (2003). Apache Nutch. Retrieved June 30, 2015, from http://nutch.apache.org/

Dean, J., & Ghemawat, S. (2004). MapReduce. Communications of the ACM, 51(1), 107. http://doi.org/10.1145/1327452.1327492

Gates, A. (2014). Apache Calcite. Retrieved June 29, 2015, from http://calcite.incubator.apache.org/docs/

Gates, A., & Bains, R. (2014). Stinger.next: Enterprise SQL at Hadoop Scale with Apache Hive. Retrieved July 10, 2015, from http://hortonworks.com/blog/stinger-next-enterprise-sql-hadoop-scale-apache-hive/

George, L. (2011). HBase: The Definitive Guide. http://doi.org/10.1038/ngeo1026

Ghemawat, S., Gobioff, H., & Leung, S.-T. (2003). The Google file system. ACM SIGOPS Operating Systems Review, 37(5), 29. http://doi.org/10.1145/1165389.945450

Gifford, D. K. (1979). Weighted voting for replicated data. In Proceedings of the seventh symposium on Operating systems principles - SOSP ’79 (pp. 150–162). New York, New York, USA: ACM Press. http://doi.org/10.1145/800215.806583

Gilbert, S., & Lynch, N. (2002). Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. ACM SIGACT News, 33(2), 51. http://doi.org/10.1145/564585.564601

Gropp, W., Lusk, E., & Thakur, R. (1999). Using MPI-2: Advanced Features of the Message-Passing Interface. Retrieved from http://dl.acm.org/citation.cfm?id=555151

Gunarathne, T. (2015). Hadoop MapReduce v2 Cookbook - Second Edition. Packt Publishing Ltd. Retrieved from https://books.google.com/books?id=T1fTBgAAQBAJ&pgis=1

Harizopoulos, S., Abadi, D. J., Madden, S., & Stonebraker, M. (2008). OLTP through the looking glass, and what we found there. In Proceedings of the 2008 ACM SIGMOD international conference on Management of data - SIGMOD ’08 (p. 981). New York, New York, USA: ACM Press. http://doi.org/10.1145/1376616.1376713

Holmes, A. (2012). Hadoop in Practice. Retrieved from http://dl.acm.org/citation.cfm?id=2543981

HortonWorks. (2015a). Apache Tez. Retrieved June 23, 2015, from http://hortonworks.com/hadoop/tez/

HortonWorks. (2015b). Hortonworks Data Platform delivers Open Enterprise Hadoop. Retrieved June 25, 2015, from http://hortonworks.com/hdp/



Hue. (2015). Hue v3.7.0, released Thursday 9th, October 2014. Retrieved June 25, 2015, from http://cloudera.github.io/hue/docs-3.7.0/release-notes/release-notes-3.7.0.html

Jiang, D., Ooi, B. C., Shi, L., & Wu, S. (2010). The performance of MapReduce. Proceedings of the VLDB Endowment, 3(1-2), 472–483. http://doi.org/10.14778/1920841.1920903

Lam, C. (2011). Hadoop in Action. Retrieved from http://books.google.com/books?id=iGq3PwAACAAJ&pgis=1\nhttp://dl.acm.org/citation.cfm?id=1965594

Leverenz, L. (2015). Apache Hive - Apache Software Foundation. Retrieved June 16, 2015, from https://cwiki.apache.org/confluence/display/Hive/Home#Home-ApacheHive

Loshin, D. (2013). Big Data Analytics: From Strategic Planning to Enterprise Integration with Tools, Techniques, NoSQL, and Graph. Elsevier Science. Retrieved from https://books.google.com/books?id=0osSaJy5ahwC&pgis=1

MapR. (2015a). In-Hadoop NoSQL Databases - MapR-DB | MapR. Retrieved June 25, 2015, from https://www.mapr.com/products/mapr-db-in-hadoop-nosql

MapR. (2015b). The MapR Distribution including Apache Hadoop | MapR. Retrieved June 25, 2015, from https://www.mapr.com/products/mapr-distribution-including-apache-hadoop

Mohan, C., & Lindsay, B. (1983). Efficient commit protocols for the tree of processes model of distributed transactions. In Proceedings of the second annual ACM symposium on Principles of distributed computing - PODC ’83 (pp. 76–88). New York, New York, USA: ACM Press. http://doi.org/10.1145/800221.806711

Mokhtar, M. (2015). HIVE 0.14 Cost Based Optimizer (CBO) Technical Overview. Retrieved June 29, 2015, from http://hortonworks.com/blog/hive-0-14-cost-based-optimizer-cbo-technical-overview/

Pooley, R., Coady, J., Schneider, C., Linger, H., Barry, C., & Lang, M. (Eds.). (2013). Information Systems Development. New York, NY: Springer New York. http://doi.org/10.1007/978-1-4614-4951-5

Popularity ranking of database management systems. (2015). Db-Engines.com. Retrieved from http://db-engines.com/en/ranking

Pritchett, D. (2008). BASE: AN ACID ALTERNATIVE. Queue, 6(3), 48–55. http://doi.org/10.1145/1394127.1394128

Process Mining: The Objectification of Gut Instinct. (2013). Retrieved July 2, 2015, from http://bpm.com/bpm-today/blogs/477-process-mining-the-objectification-of-gut-instinct



Rabl, T., Gómez-Villamor, S., Sadoghi, M., Muntés-Mulero, V., Jacobsen, H.-A., & Mankovskii, S. (2012). Solving big data challenges for enterprise application performance management. Proceedings of the VLDB Endowment, 5(12), 1724–1735. http://doi.org/10.14778/2367502.2367512

Russell, J. (2013). Cloudera Impala. Retrieved from https://books.google.com/books?hl=pt-PT&lr=&id=iIWMBAAAQBAJ&pgis=1

Rynnwang. (2013). MSSQL To MongoDB Tool - Home. Retrieved June 25, 2015, from https://mssql2mongo.codeplex.com/

Sadalage, P. J., & Fowler, M. (2012). NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence. Retrieved from http://dl.acm.org/citation.cfm?id=2381014

Saha, B. (2013). Apache Tez: A New Chapter in Hadoop Data Processing - Hortonworks. Retrieved June 23, 2015, from http://hortonworks.com/blog/apache-tez-a-new-chapter-in-hadoop-data-processing/

Saha, B., Shah, H., Seth, S., Vijayaraghavan, G., Murthy, A., & Curino, C. (2015). Apache Tez. In Proceedings of the 2015 ACM SIGMOD International Conference on Management of Data - SIGMOD ’15 (pp. 1357–1369). New York, New York, USA: ACM Press. http://doi.org/10.1145/2723372.2742790

Shanklin, C. (2013). ORCFile in HDP 2: Better Compression, Better Performance. Retrieved July 22, 2015, from http://hortonworks.com/blog/orcfile-in-hdp-2-better-compression-better-performance/

Skeen, D. (1982, February 1). A Quorum-Based Commit Protocol. Cornell University. Retrieved from http://ecommons.library.cornell.edu/handle/1813/6323

Slootwe, S. (2015). Why you should never, ever, ever use MongoDB. Retrieved August 3, 2015, from http://cryto.net/~joepie91/blog/2015/07/19/why-you-should-never-ever-ever-use-mongodb/

Sqoop User Guide (v1.4.6). (2015). Retrieved June 16, 2015, from http://sqoop.apache.org/docs/1.4.6/SqoopUserGuide.html#_introduction

SQuirreL. (2015). SQuirreL, a Universal SQL Client. Retrieved June 25, 2015, from http://squirrel-sql.sourceforge.net/paper/SQuirreL_us.pdf

Stephen, F. (2014). A Brief History of Databases. Retrieved June 15, 2015, from http://avant.org/media/history-of-databases

Taurus, P. (2015). Clean UNinstall Hortonworks HDP 2.2. Retrieved July 15, 2015, from https://pulsatingtaurus.wordpress.com/2015/02/15/clean-uninstall-hortonworks-hdp-2-2/



Vaish, G. (2013). Getting started with NoSQL. Retrieved from http://books.google.com/books?hl=en&lr=&id=oPiT-V2eYTsC&oi=fnd&pg=PT9&dq=Getting+Started+with+NoSQL&ots=sGmGnTiHnp&sig=74wa7iVM84-uzz4zwJ521ucEm-g

Vavilapalli, V. K., Seth, S., Saha, B., Curino, C., O’Malley, O., Radia, S., … Shah, H. (2013). Apache Hadoop YARN. In Proceedings of the 4th annual Symposium on Cloud Computing - SOCC ’13 (pp. 1–16). New York, New York, USA: ACM Press. http://doi.org/10.1145/2523616.2523633

Vogels, W. (2009). Eventually consistent. Communications of the ACM, 52(1), 40. http://doi.org/10.1145/1435417.1435432

White, T. (2012). Hadoop: The Definitive Guide. Retrieved from https://books.google.pt/books/about/Hadoop_The_Definitive_Guide.html?id=drbI_aro20oC&pgis=1

Zaharia, M., Chowdhury, M., Franklin, M. J., Shenker, S., & Stoica, I. (2010). Spark: cluster computing with working sets, 10. Retrieved from http://dl.acm.org/citation.cfm?id=1863103.1863113

Zhang, M. (2013). Hive & Performance. Retrieved July 22, 2015, from http://pt.slideshare.net/ye.mikez/hive-tuning

Zimmermann, T. (2004). The Race: Extreme Sailing and Its Ultimate Event: Nonstop, Round-the-World, No Holds Barred. Retrieved from https://books.google.com/books?hl=pt-PT&lr=&id=WI7U45COn1EC&pgis=1



Anexo A Reuniões de acompanhamento

Tabela 18: Reuniões de Acompanhamento

Data 09/03/2015 Local: Critical Manu-facturing

Participantes: Ricardo Magalhães Rui Magalhães

Pontos de-batidos:

Introdução ao projeto.

Discussão de possíveis abordagens e planeamento de etapas.



Pontos de-batidos:

Discussão sobre as tecnologias a estudar.

Data 12/03/2015 Local: ISEP Participantes: Paulo Jorge Oliveira Rui Magalhães

Pontos de-batidos:

Apresentação do projeto, discussão da abordagem a tomar com base no planeamento preliminar.

Alusão a vários aspetos técnicos do relatório.



Pontos de-batidos:

Revisão do plano preliminar à luz das sugestões do Dr. Paulo Oliveira





Pontos de-batidos:

Analise das necessidades do sistema contrapondo com as capacida-des do mongoDB e Cassandra.

Alusão a conceitos chave de negócio como recolha de informação de sensores, filtragem dos dados, armazenamento da informação



Pontos de-batidos:

Discussão sobre tecnologias NewSQL vs. NoSQL.

Analise das vantagens de implementação no sistema.

As transações não são necessárias por isso a velocidade das tecnolo-gias NoSQL prevalece um fator eliminatório



Pontos de-batidos:

Discussão do método de importação de dados para a base de dados NoSQL.

Acerto de varos pormenores do sistema como: o Definição da fonte de dados. o Estado de filtragem dados importados. o Requisitos de armazenamento da base de dados não relaci-

onal. o Discussão sobre o débito de dados



Pontos de-batidos:

Esclarecimento de dúvidas sobre requisitos.

Elaboração de um esquema do sistema.

Alusão ao conceito de uma base de dados ODS e cubo OLAP.

Visualização do papel que a base de dados NoSQL deve ter no sis-tema e como o deve integrar.

Discussão dos requisitos da máquina para testes.





Pontos de-batidos:

Entrega de dados de acesso a duas máquinas virtuais com CentOS 7.

Breve revisão do planeamento.



Pontos de-batidos:

Revisão do ponto de situação.

Apresentação de algumas funcionalidades do protótipo.



Pontos de-batidos:

Comunicação das dificuldades sentidas para a instalação de um soft-ware devido a incompatibilidade com o SO.

Revisão dos requisitos das máquinas e acordo de instalação do Cen-tOS 6.



Pontos de-batidos:

Pedido de configuração de acesso à base de dados SQL Server para posterior importação de dados de teste recorrendo ao Apache Sqoop.

Auxilio nas configurações do Sqoop para realizar a conexão ao SQL Server. Definida a driver JDBC a usar e inspeção da respetiva fonte.

Definida amostra de dados a testar.



Pontos de-batidos:


Sugestão de presença na palestra "Hive on Tez" realizada na UPTec e discussão dos possíveis pontos abordados e interesse dos mesmos para a solução.

Comunicação de ausência temporária do Supervisor e acordo de um substituto





Pontos de-batidos:


Partilha da informação recolhida por mim nas palestras "Hive on Tez", "MongoDB Wired Tiger" e "Hands On Big-Data by Xarevision".

Análise de um caso prático de utilização de Hadoop na Amazon.

Reflexão sobre o trabalho realizado durante o estágio.

Discussão acerca da necessidade de revisitar e aprofundar alguns tópicos.

Definição de uma meta preferencial para a entrega do relatório (9 de julho).

Data 22/06/2015 Local: ISEP Participantes: Paulo Jorge Oliveira Rui Magalhães

Pontos de-batidos:


Análise de desvios ao planeamento inicial

Análise do documento de relatório elaborado até à data, discussão quanto á sua estrutura, profundidade dos temas e enquadramento teórico de cada capitulo entre outros aspetos técnicos.

Discussão sobre a fase de entrega do relatório tendo em conta o trabalho ainda requerido pelo documento.



Anexo B Instalações

Instalação do JDK

O Hadoop foi desenvolvido em Java, para se proceder à sua instalação é necessário ter uma

versão do JDK instalada em todas as máquinas do cluster, neste caso foi selecionada a versão

7. Em seguida são demonstrados os passos de instalação e configuração do Java.

O utilizador deve ter direitos de administrador na máquina para poder instalar programas, o

download é feito a partir do comando wget e a pasta de destino será opt.

su root

cd /opt/

wget --no-cookies --no-check-certificate --header "Cookie:

gpw_e24=http%3A%2F%2Fwww.oracle.com%2F; oraclelicense=accept-

securebackup-cookie" "http://download.oracle.com/otn-

pub/java/jdk/7u75-b13/jdk-7u75-linux-x64.tar.gz"

Caso o comando wget não seja reconhecido deve ser instalado

sudo yum install wget

Depois de feito o download do tarbal este deve ser descompactado

tar xzf jdk-7u75-linux-x64.tar.gz

Procede-se à instalação do binário recorrendo ao alternatives.

cd /opt/jdk1.7.0_75/

alternatives --install /usr/bin/java java

/opt/jdk1.7.0_75/bin/java 2

Deve ser selecionada a versão do Java por definição do sistema, isto porque, podem existir versões diferentes do java instaladas anteriormente por outros programas.

alternatives --config java

Exemplo de output do comando acima (A opção a escolher será a 4):

There are 4 programs which provide 'java'.

Selection Command

-----------------------------------------------

* 1 /usr/lib/jvm/jre-1.6.0-openjdk/bin/java

+ 2 /opt/jdk1.7.0_60/bin/java

3 /opt/jdk1.7.0_72/bin/java



4 /opt/jdk1.7.0_75/bin/java

Enter to keep the current selection[+], or type selection number:

4 [Press Enter]

Definir caminhos para o Javac e para o Jar

alternatives --install /usr/bin/jar jar /opt/jdk1.7.0_75/bin/jar

2

alternatives --install /usr/bin/javac javac

/opt/jdk1.7.0_75/bin/javac 2

alternatives --set jar /opt/jdk1.7.0_75/bin/jar

alternatives --set javac /opt/jdk1.7.0_75/bin/javac

Verificar o estado da instalação

java –version

(output)java version "1.7.0_75" Java(TM) SE Runtime Environment

(build 1.7.0_75-b13) Java HotSpot(TM) 64-Bit Server VM (build

24.75-b04, mixed mode)

Configurar as variáveis de ambiente13. As seguintes linhas devem ser adicionadas ao ficheiro

/etc/bashrc

Definir JAVA_HOME

export JAVA_HOME=/opt/jdk1.7.0_75

Definir JRE_HOME

export JRE_HOME=/opt/jdk1.7.0_75/jre

Definir PATH

export PATH=$PATH:/opt/jdk1.7.0_75/bin:/opt/jdk1.7.0_75/jre/bin

Instalação do Hadoop 2.6.0

Aquando da execução do projeto, a versão estável mais recente do Hadoop era a 2.6.0, os

passos seguidos para a sua instalação são demonstrados abaixo, estes são similares para

versões mais antigas desde a 2.0 até às mais recentes.

13 https://en.wikipedia.org/wiki/Environment_variable#Unix



Na máquina master:

cd /opt

wget http://www.eu.apache.org/dist/hadoop/common/hadoop-2.6.0/hadoop-

2.6.0.tar.gz

tar -zxf hadoop-2.6.0.tar.gz

rm hadoop-2.6.0.tar.gz

mv hadoop-2.6.0 hadoop

Propagar /opt/hadoop para os nós escravos:

scp -r hadoop hslave1:/opt

scp -r hadoop hslave2:/opt

Definir variáveis de ambiente adicionando as seguintes linhas ao

ficheiro /home/hadoop/.bashrc em todas as máquinas (pode ser usado o comando scp para

propagar o ficheiro para as restantes máquinas):

export HADOOP_PREFIX=/opt/hadoop

export HADOOP_HOME=$HADOOP_PREFIX

export HADOOP_COMMON_HOME=$HADOOP_PREFIX

export HADOOP_CONF_DIR=$HADOOP_PREFIX/etc/hadoop

export HADOOP_HDFS_HOME=$HADOOP_PREFIX

export HADOOP_MAPRED_HOME=$HADOOP_PREFIX

export HADOOP_YARN_HOME=$HADOOP_PREFIX

export PATH=$PATH:$HADOOP_PREFIX/sbin:$HADOOP_PREFIX/bin

Editar o ficheiro /opt/hadoop/etc/hadoop/core-site.xml – configurar o NameNode URI em

todos os nós:

<configuration>

<property>

<name>fs.defaultFS</name>

<value>hdfs://hmaster:9000/</value>

</property>

</configuration>

Criar os diretórios HDFS DataNode em todos os nós e alterar o owner da pasta /opt/hadoop:

chown hadoop /opt/hadoop/ -R

chgrp hadoop /opt/hadoop/ -R

mkdir /home/hadoop/datanode

chown hadoop /home/hadoop/datanode/

chgrp hadoop /home/hadoop/datanode/

Editar /opt/hadoop/etc/hadoop/hdfs-site.xml – configurar DataNodes, para garantir

replicação e tolerância a falhas o valor do dfs.replication deve ser superior a 1:

<configuration>

<property>

<name>dfs.replication</name>

<value>2</value>

</property>

<property>

<name>dfs.permissions</name>

<value>false</value>

</property>

<property>

<name>dfs.datanode.data.dir</name>

<value>/home/hadoop/datanode</value>

</property>

</configuration>

Criar diretórios HDFS NameNode data na máquina master:

# mkdir /home/hadoop/namenode

# chown hadoop /home/hadoop/namenode/

# chgrp hadoop /home/hadoop/namenode/

Editar /opt/hadoop/etc/hadoop/hdfs-site.xml no master e adicionar a seguinte propriedade

às existentes:

<property>

<name>dfs.namenode.data.dir</name>

<value>/home/hadoop/namenode</value>

</property>

Editar /opt/hadoop/etc/hadoop/mapred-site.xml na máquina master.

<configuration>

<property>

<name>mapreduce.framework.name</name>

<value>yarn</value>



</property>

</configuration>

Editar /opt/hadoop/etc/hadoop/yarn-site.xml – Configurar o ResourceManager e

NodeManagers:

<configuration>

<property>

<name>yarn.resourcemanager.hostname</name>

<value>hadoop-namenode</value>

</property>

<property>

<name>yarn.resourcemanager.scheduler.address</name>

<value>hadoop-namenode:8030</value>

</property>

<property>

<name>yarn.resourcemanager.resource-

tracker.address</name>


</property>

<property>

<name>yarn.resourcemanager.address</name>


</property>

<property>

<name>yarn.resourcemanager.admin.address</name>


</property>

<property>

<name>yarn.resourcemanager.webapp.address</name>

<value>0.0.0.0:8088</value>

</property>

<property>

<name>yarn.nodemanager.aux-services</name>

<value>mapreduce_shuffle</value>

</property>

<property>

<name>yarn.nodemanager.aux-

services.mapreduce.shuffle.class</name>

<value>org.apache.hadoop.mapred.ShuffleHandler</value>

</property>



</configuration>

Editar /opt/hadoop/etc/hadoop/slaves no master (para que o master possa arrancar todos os

serviços de que necessite nos nós):

hslave1

hslave2

Descativar firewall e IPv6 (Hadoop não suporta IPv6 – existe um problema de escuta em todas

as interfaces via 0.0.0.0):

systemctl stop firewalld

Adicionar as seguintes linhas ao ficheiro /etc/sysctl.conf:

net.ipv6.conf.all.disable_ipv6 = 1

net.ipv6.conf.default.disable_ipv6 = 1

Formatar NameNode:

su hadoop

hdfs namenode -format

O output será semelhante a este, caso a operação tenha sucesso:

13/07/13 10:58:07 INFO namenode.NameNode: STARTUP_MSG:

/************************************************************

STARTUP_MSG: Starting NameNode

STARTUP_MSG: host = hadoop-master/192.168.1.15

STARTUP_MSG: args = [-format]

STARTUP_MSG: version = 1.2.0

STARTUP_MSG: build =

https://svn.apache.org/repos/asf/hadoop/common/branches/branch-

1.2 -r 1479473; compiled by 'hortonfo' on Mon May 6 06:59:37 UTC

2013

STARTUP_MSG: java = 1.7.0_25

************************************************************/

13/07/13 10:58:08 INFO util.GSet: Computing capacity for map

BlocksMap

13/07/13 10:58:08 INFO util.GSet: VM type = 32-bit

13/07/13 10:58:08 INFO util.GSet: 2.0% max memory = 1013645312

13/07/13 10:58:08 INFO util.GSet: capacity = 2^22 = 4194304

entries



13/07/13 10:58:08 INFO util.GSet: recommended=4194304,

actual=4194304

13/07/13 10:58:08 INFO namenode.FSNamesystem: fsOwner=hadoop

13/07/13 10:58:08 INFO namenode.FSNamesystem:

supergroup=supergroup


isPermissionEnabled=true


dfs.block.invalidate.limit=100


isAccessTokenEnabled=false accessKeyUpdateInterval=0 min(s),

accessTokenLifetime=0 min(s)

13/07/13 10:58:08 INFO namenode.FSEditLog:

dfs.namenode.edits.toleration.length = 0

13/07/13 10:58:08 INFO namenode.NameNode: Caching file names

occuring more than 10 times

13/07/13 10:58:08 INFO common.Storage: Image file of size 112

saved in 0 seconds.

13/07/13 10:58:08 INFO namenode.FSEditLog: closing edit log:

position=4, editlog=/opt/hadoop/hadoop/dfs/name/current/edits

13/07/13 10:58:08 INFO namenode.FSEditLog: close success:

truncate to 4, editlog=/opt/hadoop/hadoop/dfs/name/current/edits

13/07/13 10:58:08 INFO common.Storage: Storage directory

/opt/hadoop/hadoop/dfs/name has been successfully formatted.

13/07/13 10:58:08 INFO namenode.NameNode: SHUTDOWN_MSG:

/************************************************************

SHUTDOWN_MSG: Shutting down NameNode at hadoop-

master/192.168.1.15

************************************************************/

Iniciar HDFS (com o utilizador hadoop):

start-dfs.sh

Verificar com o comando jps se o DataNode está a correr nos nós escravo e se

o DataNode, NameNode, e SecondaryNameNode estão a correr no master.

Iniciar o serviço YARN no master:

start-yarn.sh



Agora o NodeManagers deverá estar a correr em todos os nós e o ResourceManager iniciado

no master. Podemos ver que, no Hadoop, um nó mestre é constituído por os seguintes serviços

ResourceManager, NodeManager (YARN), NameNode e DataNode (HDFS). Um nó escravo

trabalha ao mesmo tempo como um NodeManager e um DataNode.

Teste da instalação Hadoop 2.6.0

Verificar se os nós estão online e a correr através do comando:

/opt/hadoop/bin/hadoop dfsadmin –report

ou através da interface web

http://192.168.126.242:50070/dfshealth

Fazer o download de um ficheiro de teste e. g. “Os Lusíadas”.

wget http://www.gutenberg.org/cache/epub/3333/pg3333.txt -O test.txt

Alterar o modo de segurança do HDFS para aceitar escritas

hdfs dfsadmin -safemode leave

hdfs dfs -mkdir /input

Copiar um ficheiro de teste do sistema de ficheiros do Linux para o sistema de ficheiros do

Hadoop (HDFS)

hdfs dfs -copyFromLocal test.txt /input

hdfs dfs -cat /input/test.txt | head

Correr um trabalho de MapReduce:

hadoop jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-exam-

ples-2.6.0.jar wordcount /input/test.txt /output1

Em caso de erro o ficheiro de log pode ser consultado em: /opt/hadoop/log/*.log

Obter os resultados:

hadoop fs -getmerge /output1 /output1/results.txt

cat /opt/hadoop/results.txt

Instalação do MongoDB 3.0



A instalação do MongoDB é bastante simples, com pouca necessidade de configurações,

contudo, ao contrário do Cassandra, o ambiente que se obtém após a instalação não é

distribuído, requer a criação de um replicaSet e a activação do Sharding para que os recursos

de armazenamento sejam partilhados. Os seguintes passos demonstram a instalação do

MongoDB na sua versão 3.0 tal como seguido no manual de referencia14.

O modo de instalação escolhido foi pelo gestor de pacotes yum. Foi apenas necessário

acrescentar o repositório correspondente à versão escolhida na pasta de repositórios do

sistema.

sudo vi /etc/yum.repos.d/mongodb-org-3.0.repo

O conteúdo do ficheiro deve ser preenchido como descrito a baixo:

[mongodb-org-3.0]

name=MongoDB Repository

baseurl=http://repo.mongodb.org/yum/redhat/$releasever/mongodb-

org/3.0/x86_64/

gpgcheck=0

enabled=1

Aquando da instalação pode optar-se por uma versão anterior à especificada no repositório,

neste caso foi instalada a versão descrita no repositório correndo para isso o seguinte

comando.

sudo yum install -y mongodb-org

Para iniciar o MongoDB basta correr o seguinte comando em todos os nós do cluster.

sudo service mongod start

A fim de verificar se o arranque do programa decorreu sem falhas pode ser consultado o

ficheiro de log na pasta:

/var/log/mongodb/mongod.log

E tomar especial atenção às seguintes linhas:

[initandlisten] waiting for connections on port <port>

14 http://docs.mongodb.org/manual/



Na qual <port> deve mostrar o porto tal como configurado no ficheiro /etc/mongod.conf, que

por omissão será 27017.

Para assegurar que o MongoDB é iniciado sempre que o sistema é desligado e reiniciado deve

correr-se o seguinte comando.

sudo chkconfig mongod on

Caso necessário, o serviço pode ser parado ou reiniciado de forma rápida com o comando:

sudo service mongod stop

sudo service mongod restart

Instalação do Hive 0.14.0 Download do pacote de instalação

cd /opt/hadoop

wget http://www.us.apache.org/dist/hive/hive-0.14.0/hive-

0.14.0.tar.gz

tar xzf hive-0.14.0.tar.gz

mv hive-0.14.0 Hive

chown -R hadoop Hive

Definir variáveis

export HIVE_HOME=/opt/hadoop/hive

export PATH=$HIVE_HOME/bin:$PATH

Antes de iniciar o Hive é necessário criar as pastas /tmp e /user/hive/warehouse. Em

seguida, alterar as suas permissões no HDFS antes de criar uma tabela.

hdfs dfs -mkdir /user

hdfs dfs -mkdir /user/hdfs dfs -chmod g+w /user/Hive/warehouse



Pode ocorrer um erro ao executar o Hive se os nós não estiverem com a data sincronizada.

Para corrigir a situação pode ser instalado um programa que acerta o relógio do sistema, por

exemplo o ntp:

yum install ntp

ntpdate pool.ntp.org (em caso do socket estar ocupado usar:

ntpdate -u pool.ntp.org)



Anexo C Ponto de situação

Projetos/Estágios

Ano letivo de 2014-2015

PONTO DE SITUAÇÃO

PROJETO Nº: 20152065 ALUNO Nº: 1111439

ORIENTADOR (docente): Paulo Oliveira

ORGANIZAÇÃO: Critical Manufacturing S.A.

SUPERVISOR (Organiz.): Ricardo Magalhães

Problema

– É diariamente armazenada uma enorme quantidade de dados re-

colhidos por sensores, em alguns casos estes registos devem per-

manecer disponíveis para consulta durante 15 anos.

– Os RDBMS (sistema de bases de dados relacional) não permitem

digerir a informação de uma quantidade tão grande de informação

em tempo útil.

– Os RDBMS possuem uma escalabilidade muito reduzida, para di-

minuir o tempo de resposta de acesso à informação é necessário

adquirir computadores mais potentes.



Solução pretendida

– Pretende-se implementar uma base de

dados NoSQL que:

• Suporte tecnologias para análise de grandes volumes de dados

em paralelo (Map Reduce)

• Tenha um desempenho satisfatório para a quase totalidade das

queries.

• Suporte um nível de consistência mínimo e armazenamento per-

manente assegurado

• Escale de forma quase linear em máquinas banais (comodity

hardware)

Análise e implementação da solução

– Foi feito um levantamento do estado de arte das tecnologias NoSQL por forma a

melhor compreender este novo conceito bem como ter noção da variedade de

soluções existentes dentro do tema.

– Descrição da solução a implementar

• Cluster com base de dados NoSQL em máquinas virtuais Linux (CentOS

6.6)

• Serão testadas as tecnologias Apache Hadoop, Hbase, Hive, sqoop,

Cassandra, Riak e MongoDB.

• A informação necessária (dados de sensores) para a população das ba-

ses de dados será fornecida pela Critical Manufacturing e o seu modelo

de dados será elaborado com base nas caracteristicas de cada tecnolo-

gia NoSQL.



Execução da implementação

• Até ao momento foi levantado o estado de arte, passo este

que foi de extrema importância dado o pouco conhecimento

que tinha sobre o tema antes do estágio.

• Instalei um cluster hadoop primeiramente em modo pseudo-

distribuído (2 nós), e mais tarde fiz testes com 3 nós. Neste

momento estou a tentar instalar uma distribuição hadoop da

HortonWorks mas estão a ocorrer muitos erros de configura-

ção e comunicação entre nós.

• Dada a volatilidade do tema e alguma imprevisibilidade dos

resultados existe a possibilidade de testar uma tecnologia

não considerada no planeamento.

Problemas surgidos no projeto

– A montagem do cluster Hadoop demorou mais tempo que o previsto e ainda terá

de ser testado um processo de ETL nesta tecnologia pelo que a evidenciar-se

este atraso numa fase final poderá significar o abandono do estudo da tecnolo-

gia Riak

– Descrição de problemas tecnológicos surgidos

• Primeiramente foi instalado o Hadoop 2.6 nas máquinas com centOS 7,

mais tarde não foi possível instalar a distribuição do Hortonworks porque

esta não era compatível com centOS superior ao 6 tendo sido necessário

formatar as máquinas com um novo centOS compatível

• A documentação existente é escassa ou muito vaga fazendo com que

um simples problema se torne em algo moroso para um iniciante. Este

problema pode estar relacionado com o facto de se tratar de software li-

vre cuja comunidade produz conteúdos de forma voluntária.



Observações

– Existe uma variedade enorme de tecnologias NoSQL o que representa

um problema complexo de seleção. Por sua vez os fatores tempo e pro-

fundidade de estudo pretendida limitam o numero de sistemas a testar.

– É um projeto de vanguarda e ambicioso dada a fraca maturação das ba-

ses de dados NoSQL face às soluções de mercado como a Oracle e

MySQL que assentam num modelo com décadas de maturação e confi-

ança comprovada. Na minha opinião certos modelos de negócio podem

lucrar astronomicamente com as tecnologias NoSQL mas haverá sempre

a necessidade de complementar a restante arquitetura com a solidez das

bases de dados relacionais. Dados os requisitos do problema e o poten-

cial da solução, o NoSQL para corresponder na perfeição com o preten-

dido.

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

Documents

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