GABRIEL BENJAMIM DA SILVA
COMPARATIVO ENTRE DIFERENTES SOLUÇÕES DE PROCESSAMENTO DE DADOS PARA BIG DATA
Florianópolis 2017
COMPARATIVO ENTRE DIFERENTES SOLUÇÕES DE PROCESSAMENTO DE DADOS PARA BIG DATA
Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharel em Sistemas de Informação.
Orientador: Prof. Aran Morales, Dr.
Florianópolis 2017
COMPARATIVO ENTRE DIFERENTES SOLUÇÕES DE PROCESSAMENTO DE DADOS PARA BIG DATA
Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Sistemas de Informação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharel em Sistemas de Informação.
Agradeço ao meu orientador e professores que fizeram parte integrante desta minha jornada acadêmica, e também agradeço aos meus familiares e amigos que me incentivaram a concluir este trabalho.
A quantidade de dados digitais gerados encontra-se em constante crescimento, por isso cada vez mais se ouve falar do conceito de Big Data. O resultado da ascensão deste tema é a diversidade de soluções que acompanha este crescimento, soluções para facilitar o processamento de dados, paralelismo, processamento em tempo real, tolerância a falha e etc. Diante desta diversidade de soluções para Big Data, este trabalho tem como objetivo estudar 3 dessas ferramentas, Apache Hadoop, Apache Spark e Apache Flink, apontando diferenças, semelhanças e comparando-as por meio de um experimento de contagem de palavras diante de grande volume de dados. Assim, foi possível avaliar o tempo de processamento de cada plataforma trabalhando em modo pseudo-distribuído e em um único cluster, e observar o desempenho de cada plataforma no processamento em lote. Por fim, pode-se avaliar que o objetivo de estudo e comparação de tempo de execução foi atendido. Constatou-se que a ferramenta Spark obteve os melhores resultados para o tipo de operação realizado no experimento, além de servir como base para estudos futuros das ferramentas, utilizando novas formas de processamento e de ambiente de execução.
Palavras-chave: Big Data. Processamento em Lote. Apache Hadoop. Apache Spark. Apache Flink.
LISTA DE FIGURAS
Figura 1 - Indicativo de popularidade do termo Big Data. ... 14
Figura 2 - Representação de dados estruturados ... 16
Figura 3 - Representação de dados semiestruturados. ... 17
Figura 4 - Comparativo de escalabilidade entre RDBMS e NoSQL ... 25
Figura 5 - Exemplo de um processo MapReduce para conta palavras ... 27
Figura 6 - Arquitetura HDFS ... 32
Figura 7 - Ecossistema Hadoop em camadas ... 33
Figura 8 - Trecho do código-fonte para o Word Count no Hadoop (Função Map) ... 51
Figura 9 - Trecho do código-fonte para o Word Count em Hadoop (Função Reduce) ... 51
Figura 10 - Trecho do código-fonte para o Word Count no Spark (Map e Reduce) ... 54
Figura 11 - Trecho do código-fonte para o Word Count no Flink (Map e Reduce) ... 56
Figura 12 - Comparativo de tempo de execução da aplicação Word Count com 1 GB ... 57
Figura 13 - Comparativo de tempo de execução da aplicação Word Count com 3 GB ... 58
Quadro 1 – Comparativo da plataforma Flink com as demais ... 37
Quadro 2 – Configuração do SSH ... 47
Quadro 3 – Configuração das variáveis de ambiente ... 47
Quadro 4 – Arquivos de configuração Hadoop ... 48
Quadro 5 – Processos rodando na JVM ... 50
Quadro 6 – Fonte de dados do experimento de contagem de palavras ... 50
Quadro 7 – Executando o Job Wordcount no hadoop ... 51
Quadro 8 – Resultado da contagem de palavras na Constituição Federal ... 52
Quadro 9 – Configuração Spark em modo pseudo-distribuído ... 53
Quadro 10 – Executando o Job Wordcount no Spark ... 54
Quadro 11 – Comando para visualização da contagem de palavras para o Spark ... 55
HDFS – Hadoop Distributed File System JSON – JavaScript Object Notation NoSQL – Not only SQL
RDBMS – Relational Database Management System SQL – Structured Query Language
XML – Extensible Markup Language YARN – Yet Another Resource Negotiator
1 INTRODUÇÃO ... 11 1.1 PROBLEMA ...12 1.2 OBJETIVOS ...12 1.2.1 Objetivo Geral ...13 1.2.2 Objetivos Específicos ...13 1.3 JUSTIFICATIVA ...13 1.4 ESTRUTURA DO TRABALHO ...14 2 REFERENCIAL BIBLIOGRÁFICO ... 15 2.1 TIPOS DE DADOS ...15 2.1.1 Dados Estruturados ...16 2.1.2 Dados Semiestruturados ...16
2.1.3 Dados Não Estruturados ...18
2.2 TIPOS DE PROCESSAMENTO ...18
2.2.1 Processamento em Lote ...19
2.2.2 Processamento em tempo real ou quase real ...19
2.3 BIG DATA ...20 2.3.1 Volume ...22 2.3.2 Velocidade ...23 2.3.3 Variedade ...23 2.4 NOSQL ...24 2.5 CLOUD COMPUTING ...26 2.6 MAPREDUCE ...27 2.7 HADOOP ...28
2.7.1 Hadoop Distributed Filesystem (HDFS) ...29
2.7.1.1 NameNode e DataNodes ... 30
2.7.2 Ecosistema Hadoop ...32
2.8 SPARK ...34
2.8.1 Resilient Distributed Datasets (RDD) ...35
2.9 FLINK ...36
2.9.1 Componentes ...37
3 MÉTODO... 39
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA ...39
3.2 ETAPAS METODOLÓGICAS ...40 3.3 PROPOSTA DE SOLUÇÃO ...41 3.4 DELIMITAÇÕES ...41 4 PROPOSTA DE DESENVOLVIMENTO ... 42 4.1 EXPERIMENTO ...42 4.1.1 Configuração Geral ...42 4.1.2 Contador de Palavras ...42 4.1.2.1 Fonte de dados ... 43 5 DESENVOLVIMENTO ... 44 5.1 HISTÓRICO DE DESENVOLVIMENTO ...44 5.1.1 Ferramentas e Tecnologias ...44 5.1.1.1 Eclipse ... 45 5.1.1.2 Maven ... 45 5.1.1.3 PDF to Text ... 46
5.1.2.2 Spark ... 53
5.1.2.3 Flink ... 55
5.1.3 Resultados ...56
5.1.4 Conclusões ...60
1 INTRODUÇÃO
A quantidade de dados criados e armazenados hoje em dia, em um nível global é quase inconcebível. Por essa razão, cada vez mais vem se falado no termo Big Data. Na verdade o conceito de Big Data não é algo novo, mas estão recebendo uma grande atenção por algumas razões, como o barateamento do armazenamento de dados, e mais possibilidades de serviços para publicar e difundir informações.
Para Gantz (2011, apud BERNARDES, 2014, p. 19), as tecnologias de Big Data descrevem uma nova geração de arquiteturas, projetadas para economicamente extrair valor de um grande volume, sobre uma grande variedade de dados, permitindo alta velocidade de captura, e/ou análise.
Segundo a SAS (2016), empresa atuante no mercado de business intelligence, o conceito ganhou força no início dos anos 2000, quando um analista famoso deste setor, Doug Laney, articulou a definição de big data como os três Vs: Volume, velocidade e variedade.
Quando se fala em Volume, refere-se à quantidade de dados, que dependendo de sua fonte, poderá vir a crescer exponencialmente. No passado, armazenar tamanha quantidade de informações seria um problema, porém novas tecnologias disponíveis hoje tem mitigado bastante esse tópico. Essas tecnologias serão tratadas com mais detalhes ao longo do trabalho.
Velocidade é a rapidez com que os dados são produzidos e precisam ser analisados. Muitas aplicações necessitam de resposta em tempo real, ou quase real, como detecção de fraudes ou recomendações baseadas em redes sociais.
E a variedade, que é um dos aspectos mais interessantes e mais desafiadores dos 3 Vs, pois o volume de dados que temos hoje são consequência também da diversidade de informações, esses dados são gerados em todos os tipos de formatos, desde dados estruturados, dados numéricos em bancos de dados tradicionais, até documentos de texto não estruturados, e-mail, áudio, vídeo, entre outros.
Com isso diferentes plataformas de Big Data vêm surgindo no mercado, alguns com diferentes propostas de solução para um mesmo propósito, outros com finalidades diferentes.
Este trabalho de conclusão de curso, em Sistemas da Informação tem como objetivo comparar essas diferenças e as funcionalidades das plataformas: Apache Hadoop, Apache Spark e Apache Flink. Além da comparação serão executados experimentos entre essas ferramentas, com o objetivo de avaliar o tempo de execução.
1.1 PROBLEMA
A tendência de expormos nossas opiniões em redes sociais, por exemplo, permite aos cientistas de dados tirarem proveito dessa gama de informações e mensurá-los de forma a se criar dados úteis a partir deles. Quando se trata de dados não estruturados essa tarefa se torna ainda mais difícil, a preocupação quanto a correção da informação e eliminação de ruídos deve ser feita logo na fonte da coleta, tendo que prever com antecedência, esse aspecto que os autores denominam de veracidade dos dados, que nada mais é que a tentativa de buscar qualidade e compreensão das informações antes mesmo de coleta-las.
Diante da necessidade de tornar processável toda esta gama de informações, que podem estar persistidas de forma estruturada, semiestruturada, ou sem nenhuma organização. Ferramentas como Apache Hadoop, Apache Spark e Apache Flink, são algumas das soluções disponíveis hoje no mercado, com o intuito de prover processamento desses dados não estruturados de forma escalável e otimizada. Ao se escolher uma dessas soluções é necessário entender qual o propósito de cada plataforma, identificar quais tipos de dados tal ferramenta é a mais adequada, qual possui melhor performance.
1.2.1 Objetivo Geral
O objetivo deste trabalho é o estudo da disciplina de Big Data e processamento de dados.
1.2.2 Objetivos Específicos
Pesquisar e reunir embasamento teórico sobre Big Data e processamento de dados.
Analisar a arquitetura e o funcionamento de algumas plataformas para processamento de
dados.
Produzir como resultado deste estudo, comparativos de velocidade e tempo de execução
por meio de experimentos realizado nas plataformas Apache Hadoop, Apache Spark e Apache Flink.
Construir um referencial teórico e prático sobre a área.
1.3 JUSTIFICATIVA
O assunto Big Data desde seu surgimento vem causado bastante curiosidade e interesse daqueles que já ouviram falar no termo ou tiveram a oportunidade de aplicá-lo algum dia.
Com uma consulta básica no Google Trends (2017) conforme mostra a Figura 1, já é possível perceber que esta é uma área que vem crescendo constantemente e indica um futuro bastante promissor.
Figura 1 – Indicativo de popularidade do termo Big Data.
Fonte: Elaborado pelo autor
Alguns fatores que colaboram para a ascensão do tema nos últimos anos é o crescimento constante de dados e a possibilidade de se extrair informações úteis a partir deles. A importância de se abordar esse assunto está no fato de se tratar de um tema que pode afetar diretamente a vida da sociedade, a qual muitas vezes gera dados valiosos e informações úteis diariamente.
É oportuno compreender as tecnologias que envolvem o projeto Hadoop, Spark e Flink, pois são ferramentas bastante recorrentes se tratando de processamento e análise de dados dentro do contexto de Big Data, e possibilitará o estudo mais aprofundado em relação a processamento de dados, área essencial aos estudos e aplicação dos conceitos de Big Data.
1.4 ESTRUTURA DO TRABALHO
A estrutura da monografia compreende os seguintes capítulos:
Capítulo 1: Refere-se a introdução ao assunto abordado, ao problema que o trabalho propõe a resolver e os objetivos do trabalho, bem como a justificativa para o seu desenvolvimento.
Capítulo 2: Irá expor os principais conceitos e ferramentas abordadas no trabalho, juntamente com uma comparação entre elas, a fim de construir a fundamentação teórica.
Capítulo 3: Apresentará o tipo de pesquisa realizada, bem como as atividades que compõem a proposta de solução e as delimitações.
Capítulo 4: Descreve os detalhes da proposta com o experimento e da fonte de dados a ser processada com a utilização do Hadoop, Spark e Flink como ferramentas computacionais disponíveis.
Capítulo 5: Apresenta o histórico de desenvolvimento, bem como os resultados obtidos com o experimento, e oportunidades para trabalhos futuros.
2 REFERENCIAL BIBLIOGRÁFICO
Este capítulo tem como objetivo dar fundamentação teórica ao trabalho, descrevendo os principais elementos abordados nele. Para auxiliar no entendimento são abordados brevemente os Tipos de Dados, logo em seguida aprofundando no assunto Big Data e em conceitos e soluções correlatos.
2.1 TIPOS DE DADOS
O montante de dados de todos os tipos, disponíveis eletronicamente tem aumentado dramaticamente ano após ano. O dado reside em diferentes formas, variando de não estruturados até dados altamente estruturados em sistemas de banco de dados relacionais. Alguns desses dados são brutos, como imagens e som por exemplo, outros possuem estruturas, mesmo que essas estruturas se encontram implícitas, e não rígidas ou regulares como as encontradas em um sistema de banco de dados padrão. Muitas vezes a estrutura existe, mas temos que extraí-las dos dados, outras vezes a estrutura existe, mas preferimos ignorá-la por certos motivos, como em uma consulta por exemplo. (ABITEBOUL et al., 1997, tradução nossa).
2.1.1 Dados Estruturados
Para Inmon et al. (2008, tradução nossa), dados estruturados são dados representados por números, tabelas, linhas, colunas, atributos e assim por diante. Como o próprio nome implica, dados estruturados são geralmente disciplinados, bem comportados, previsíveis, e repetíveis. Dados estruturados são feitos de tipos de dados que são repetidos continuamente. O mesmo tipo de dado é encontrado na maioria das transações. A única coisa que difere de uma transação para a próxima são os valores que o tipo do dado leva.
Segundo o mesmo autor, em complemento a repetitividade e a previsibilidade, a essência de ambientes estruturados são os dados numéricos. Embora haja textos nos ambientes estruturados, a maioria desses textos tem como propósitos a identificação ou a descrição de alguns dados numéricos.
A figura a seguir exibe um exemplo de dados estruturados, extraído de uma tabela de um banco de dados relacional
Figura 2 – Representação de dados estruturados.
Fonte: Elaborado pelo autor
2.1.2 Dados Semiestruturados
Para Nestorov et al. (1998, tradução nossa) o termo dados semiestruturados surgiu para descrever o dado que tem alguma estrutura, mas que não é regular, nem conhecido a priori para o sistema. Por esta razão que a maioria dos modelos de dados semiestruturados são auto descritivos.
Kanimozhi et al. (2015, tradução nossa) descreve que dados semiestruturados é um tipo de dado estruturado, mas é ausente em estrutura de modelo de dado ou não está em conformidade formal ou não apresenta uma estrutura rígida. Nestorov et al. (1998, tradução nossa) complementa dizendo que, dados semiestruturados não necessitam de um schema definido por ser opcional, possuem marcadores para separar semanticamente os elementos, impondo hierarquias de campos de registro dentro dos dados.
Segundo Kanimozhi et al. (2015, tradução nossa) dados semiestruturados vem crescendo cada vez mais desde que diferentes aplicações precisam de um meio para trocar informações. Linguagem de marcação como XML ou JSON são usados para lidar com dados semiestruturados. São usadas linguagens de processamento natural ou técnicas de data mining para converter dados semiestruturados em dados estruturados.
A figura a seguir demonstra um exemplo de dados semiestruturados no formato XML.
Figura 3 – Representação de dados semiestruturados.
2.1.3 Dados Não Estruturados
Gartner (apud STEWART, 2013) define dados não estruturados como um conteúdo que não está em conformidade com um modelo de dados pré-definido e em específico e não se encaixa em tabelas de banco de dados.
Segundo Kanimozhi et al. (2015, tradução nossa), dados não estruturados vem de várias fontes como imagens de satélite, sensores de leitura, mensagens de email, mídias sociais, logs, áudio, vídeos e etc. Assim, o grande desafio está em analisar e extrair valores significativos desse grande volume de dados não estruturados.
Segundo pesquisas realizadas por Gartner e a International Data Group (IDG) (apud REEDY, 2015, tradução nossa) acerca do crescimento de dados não estruturados, estima-se que:
●IDG: Dados não estruturados estão crescendo a uma taxa de 62% ao ano.
●IDG: Em 2022, 93% de todos os dados no universo digital serão dados não estruturados.
●Gartner: O volume de dados deverá crescer 800% nos próximos 5 anos e 80% disso será de dados não estruturados.
2.2 TIPOS DE PROCESSAMENTO
Para cada tipo de dado que se deseja consumir ou do contexto da aplicação, irá exigir um tipo de processamento de dados.
2.2.1 Processamento em Lote
Acerca do processamento em lote ou batch processing, SOUBRA (2012, tradução nossa) diz que inicialmente as empresas analisavam os dados usando processamento em lote. Primeiro separava-se um pedaço desses dados, enviava-se um job para o servidor e esperava pela entrega do resultado. Esse esquema funciona quando a taxa de dados de entrada é mais lenta do que a taxa de processamento em lote e quando o resultado é útil, apesar do atraso. Com novas fontes de dados oriundas de rede sociais, e aplicações mobile por exemplo, o processamento em lote não conseguiu atender plenamente.
Segundo WILSON (2015, tradução nossa) o processamento em lote envolve 3 processos separados. Primeiro o dado é coletado, geralmente por um período de tempo. Segundo, o dado é processado por um programa separado. Terceiro, é gerado então output desses dados.
O mesmo autor complementa, quando você está processando dados arquivados ou históricos para determinar as tendências de consumo ao longo dos últimos anos, este exemplo é um tipo de cenário que não exige processamento com urgência, portanto se mostra ideal para o processamento em lote.
2.2.2 Processamento em tempo real ou quase real
O significado de "tempo real" pode variar dependendo do contexto em que é usado. "No mesmo sentido em que não há realmente algo totalmente não estruturado, não há algo totalmente em tempo real. Há apenas quase em tempo real" diz John Akred, gerente sênior dentro do domínio de dados da Accenture's Emerging Technology Innovations Group. "Geralmente quando falamos em sistemas em tempo real ou quase real, queremos dizer arquiteturas que permitem você responder a dados que são recebidos sem necessariamente de ter que persisti-los em um banco de dados primeiro" (BARLOW, 2013, tradução nossa).
Segundo WILSON (2015, tradução nossa) o processamento em tempo real requer uma entrada de dados contínua, processamento constante e saída constante de dados. Um grande exemplo de processamento em tempo real são os sistemas de radar, sistemas de atendimento
ao cliente e caixas eletrônicos de bancos, onde o processamento imediato é crucial para que o sistema funcione adequadamente.
Já o processamento em tempo quase real, segundo o mesmo autor é quando a velocidade é importante, mas o processamento do tempo em minutos é aceitável em vez de segundos.
Para CHEDE (2012) a ideia de stream processing ou stream computing é um novo paradigma. No modelo de data mining tradicional uma empresa filtra dados dos seus vários sistemas e após criar um Data Warehouse, dispara as “queries”. Na prática faz-se garimpagem em cima de dados estáticos, que não refletem o momento, mas sim o contexto de horas, dias ou mesmo semanas atrás. Com stream computing esta garimpagem é efetuada em tempo real. Em vez de disparar queries em cima de uma base de dados estática, coloca-se uma corrente contínua de dados (streaming data) atravessando um conjunto de queries.
2.3 BIG DATA
Big Data descreve um conjunto de problemas e suas soluções tecnológicas em computação aplicada com características que tornam seus dados difíceis de tratar. Apesar de Big Data ser uma expressão criada para ter impacto mercadológico, acabou definindo uma nova área de pesquisa. (XEXÉO, CIÊNCIAHOJE, 2013).
Segundo a Gartner Group, Big Data são ativos de informação de alto volume, alta velocidade e alta variedade, que demandam formas inovadoras e efetivas em custo de processamento que permitam melhorar a visibilidade e tomada de decisão.
Segundo a empresa SAS (2016), as fontes de Big Data geralmente caem em uma das três categorias:
Transmissão de dados (streaming data) Dados de redes sociais
Fontes publicamente disponíveis
O mesmo autor complementa que a primeira categoria inclui dados que chegam aos seus sistemas de TI a partir de uma rede de dispositivos conectados. Os dados podem ser analisados ao ponto de tomar decisões sobre quais dados devem ser mantidos, quais não manter e quais requerem uma análise posterior mais aprofundada.
Segundo o mesmo autor dados de redes sociais são um conjunto cada vez mais atraente de informação, particularmente para marketing, vendas e funções de apoio. São muitas vezes capturados de formas não estruturada ou semiestruturada, por isso representam um desafio único quando se trata de consumo e análise.
Em um encontro realizado pela empresa TDW BI Consulting (2014), com profissionais da área de Business Intelligence, constatou-se que ainda existe muita confusão sobre o significado do termo Big Data e suas diferenças em relação a outros conceitos como Data Warehouse e Business Intelligence. Apesar da maneira agressiva com que o mercado de tecnologia procurou explorar o tema nos últimos anos, Big Data continua sendo um projeto futuro para a grande maioria das organizações e não são muitos os casos de sucesso documentados fora do segmento de internet.
Inicialmente o grupo explorou a possibilidade da diferença estar no volume de dados envolvido, mas vários participantes lembraram de projetos de Data Warehouse envolvendo dezenas ou centenas de terabytes que foram implantados há vários anos com sucesso. Alguns participantes levantaram a possibilidade da diferenciação estar relacionada com o armazenamento de dados mais consolidados, orientados ao atendimento de relatórios corporativos ou formação de indicadores, versus a utilização de dados que precisam ser analisados de forma adhoc1, mas o grupo entendeu que existem vários casos de sucesso de projetos de Data Warehouse que armazenam dados de forma mais detalhada e onde consultas adhoc são permitidas e até mesmo incentivadas. Depois de algumas discussões interessantes, a conclusão foi de que as grandes diferenças entre Big Data e Data Warehouse estariam associadas com necessidade de lidar com dados não estruturados ou de estrutura flexível como vídeos, imagens textos ou logs de internet. Outro ponto considerado relevante foi a capacidade de receber e processar de forma continua dados que chegam em grandes volumes e variedade. As tecnologias de banco de dados atuais até conseguem lidar com o processamento contínuo de grandes volumes de dados mas elas possuem limitações para lidar coma variedade dos dados.
Em 2012, Gartner (apud SYED et al., 2013, tradução nossa), formalizou a definição de Big Data em "3Vs", resumindo em alto Volume, Velocidade e alta Variedade de ativos de informação, exigindo novas formas de processamento permitindo a melhora nas tomadas de decisões, no descobrimento de Insights e na optimização de processos. A IBM adicionou o
1 Qualquer consulta que não pode ser determinada antes de ser feita. Permitem ao usuário consultas em tempo
quarto "V" de Veracidade para agregar o desafio referente a informação confiável e da filtragem de ruídos aos analistas de Big Data.
A partir desses três ‘Vs’, diversos autores propõem ainda outros conceitos, como variabilidade ou valor. São outras preocupações importantes, como garantir que o dado seja verdadeiro e ainda válido no tempo. (XEXÉO, CIÊNCIAHOJE, 2013).
2.3.1 Volume
No passado com o volume excessivo de dados criavam-se problemas de armazenamento. Hoje com a queda no custo de armazenamento, outros problemas surgiram, incluindo como determinar a relevância entre os grandes volumes de dados e como criar valor a partir dos dados que são relevantes. Esse volume é o principal desafio para as estruturas de TI convencionais. Com isso, criou-se a necessidade por armazenamento escalável e uma abordagem distribuída na consulta desses dados. Muitas empresas já possuem um grande volume de dados armazenados, talvez em forma de logs, mas não possuem a capacidade de processa-los (SYED et al., 2013, tradução nossa).
Segundo Xexéo (CIÊNCIAHOJE, 2013), para se ter uma ideia, um disco rígido comum tem atualmente em torno de 1 terabyte. O LHC, o maior acelerador de partículas do mundo, no Centro Europeu de Pesquisas Nucleares (CERN), na Suíça, armazena 15 petabytes por ano de dados na forma original. É o equivalente a 15 mil discos rígidos cheios. Ao longo do tempo, os dados já somam 100 petabytes.
Vieira (et al., 2012) explana que a análise de dados (data analytics) no contexto de Big Data normalmente envolve processamento da ordem de Terabytes em dados de baixo valor (informação original “bruta”) que são transformados para dados de maior valor (valores agregados/sumarizados).
O mesmo autor afirma que mesmo com a grande quantidade de dados Big Data não garante a qualidade da informação, pois a análise continua, em grande parte, sendo muito subjetiva. Isso se deve ao fato que os dados em si não são autoexplicativos, o processo de limpeza, amostragem, e relacionamento dos dados continua sendo crítico e passível a erros, aproximações e incertezas.
2.3.2 Velocidade
Velocidade significa que esses dados são enviados aos nossos sistemas com uma taxa de bytes por intervalo de tempo muito alta, tão grande que não é possível armazená-los totalmente. Assim, muitas vezes, a escolha dos dados para guardar e outros para descartar vira uma etapa fundamental do processo. Para armazenar 15 petabytes por ano, o CERN escolhe dados relevantes entre 15 petabytes gerados por segundo de operação do LHC (XEXÉO, CIÊNCIAHOJE, 2013).
Para SYED et al. (2013, tradução nossa), velocidade significa quão rápido os dados estão sendo produzido e o quão rápido os dados devem ser tratados para atender à demanda.
O tipo da demanda define se o processamento deve ocorrer em tempo real, quase em tempo real ou em lote. (MYSORE et al., 2014).
2.3.3 Variedade
Segundo Dijcks (2013, tradução nossa) formatos de dados tradicionais tendem a ser relativamente bem definidos por um esquema de dados e lentas mudanças. Em contrapartida, os formatos de dados não tradicionais apresentam uma taxa vertiginosa de alteração. À medida que novos serviços são adicionados, novos sensores implantados ou novas campanhas de marketing executadas, novos tipos de dados são necessários para capturar as informações resultantes.
O mesmo autor complementa, dizendo que a infraestrutura necessária para a organização do Big Data precisa ser capaz de processar e manipular os dados no local de armazenamento original, suportar altas taxas de transferência (geralmente em lote) para lidar com o grande volume de dados durantes os passos de processamento, e lidar com a grande variedade de formato de dados de não estruturados até dados estruturados.
2.4 NOSQL
Uma das tendências para solucionar os diversos problemas e desafios gerados pelo contexto Big Data é o movimento denominado Not only SQL (NoSQL). NoSQL promove diversas soluções inovadoras de armazenamento e processamento de grande volume de dados. Para Kopp (2011), a dificuldade dos Sistemas Gerenciadores de Banco de Dados Relacional (RDBMS), é a distribuição horizontal de carga e dados. NoSQL difere de RDBMS na forma como as entidades são distribuídas e que nenhuma consistência é imposta através dessas entidades.
Estas soluções foram inicialmente criadas para solucionar problemas gerados por aplicações, por exemplo, Web 2.0 que na sua maioria necessitam operar com grande volume de dados, e que tenham uma arquitetura que escale horizontalmente com facilidade, e que permitam fornecer mecanismos de inserção de novos dados de forma incremental e eficiente, além da necessidade de persistência dos dados em aplicações nas nuvens (cloud computing). Essas diversas soluções vêm sendo utilizadas com muita frequência em inúmeras empresas para o processamento analítico de dados de logs Web, transações convencionais, entre inúmeras outras tarefas (VIEIRA et al., 2012).
A Figura 4 ilustra esta facilidade do NoSQL em relação a sua escalabilidade, quando comparada a um RDBMS.
Figura 4 – Comparativo de escalabilidade entre RDBMS e NoSQL.
Fonte: Kopp (2011)
O NoSQL permite distribuir automaticamente os dados através de um grande número de nós de banco de dados e também escrevê-los de forma independente. Se fossemos escrever 20 entidades a um cluster de banco de dados com 3 nós, há a possibilidade de espalhar uniformemente as gravações em todos esses nós. O banco de dados NoSql não precisa sincronizar entre os nós para que isso aconteça e não há a necessidade de uma confirmação de duas fases (two phase commit), com o efeito visível que o Cliente 1 poderá ver as alterações no nó 1 antes que o cliente 2 tenha escritos todas as 20 entidades. Uma solução RDBMS distribuída por outro lado, precisa reforçar a consistência por todos os três nós. Isso significa que o Cliente 1 não irá ver quaisquer mudanças até os 3 nós alcançarem a two phase commit e será bloqueado até que o mesmo aconteça. Além de que a sincronização do RDBMS também precisa ler dados de outros nós, a fim de garantir a integridade referencial em tudo o que acontece durante a transação do Cliente 2 (KOPP, 2011, tradução nossa).
De acordo com Dijcks (2013, tradução nossa), bancos de dados NoSQL são muitas vezes utilizados para recolher e armazenar dados de mídias sociais. Enquanto usuários enfrentam frequentemente mudanças nas aplicações, do outro lado, as estruturas de armazenamento têm se mantido simples.
O mesmo autor complementa dizendo que, em vez de se modelar um schema com relacionamentos entre entidades, em NoSQL a estrutura é geralmente simples, possuindo
apenas uma chave principal para a identificação, o dado, e um container que mantem os conteúdos de dados relevantes (como um ID do cliente e um perfil de cliente). Esta estrutura simples é dinâmica e permite que as alterações possam ser feitas sem a necessidade de reorganizar a camada de armazenamento e sua estrutura (como adicionar novos campos para o perfil do cliente).
2.5 CLOUD COMPUTING
Recentemente, ambientes de computação em nuvem (cloud computing) têm sido utilizados para o gerenciamento de dados em forma de Big Data, com foco principalmente em duas tecnologias: Bases de Dados Como Serviço (Database as a Service ou DaaS) e Infraestrutura Como Serviço (Infrastructure as a service ou IaaS). DaaS utiliza um conjunto de ferramentas que permite o gerenciamento remoto dos servidores de dados mantidos por uma infraestrutura externa sob demanda. Essa infraestrutura IaaS fornece elasticidade, pagamento sob demanda, backups automáticos, e rapidez de implantação e entrega (VIEIRA et al., 2012).
Segundo a Intel (2015, tradução nossa), faz sentido, que as organizações de TI estão procurando a computação na nuvem como a estrutura para apoiar os seus projetos de Big Data. Ambientes para o Big Data exigem clusters de servidores para suportar ferramentas que processam grandes volumes de dados, em alta velocidade e em formatos variados para o Big Data. O Cloud é implementado em pools de servidores, em recursos de armazenagem e de rede e pode escalar para cima ou para baixo, conforme a necessidade. Computação na nuvem oferece uma forma de custo-benefício para apoiar as tecnologias de Big Data e as aplicações analíticas avançadas que podem agregar valor ao negócio.
2.6 MAPREDUCE
Confrontado com um conjunto único de desafios, em 2004 Google decidiu trazer o poder da computação paralela e distribuída, para ajudar a digerir enormes montantes de dados produzidos durante operações diárias. O resultado foi um grupo de tecnologias e filosofias de design arquitetônicos que veio a ser conhecido como MapReduce (SCHNEIDER, 2012, tradução nossa).
O mesmo autor complementa, dizendo em poucas palavras que, MapReduce foi construído para provar o conceito de "dividir e conquistar", pois é muito mais rápido quebrar uma tarefa grande em pedaços menores e processá-los paralelamente. Como mostra a figura a seguir.
Figura 5 – Exemplo de um processo MapReduce para conta palavras
Fonte: Vieira et al., 2012.
O MapReduce utiliza pares de chave/valor. Primeiro a chave identifica que tipo de informação estamos buscando. Se compararmos com um banco de dados relacional, a chave equipara-se a uma coluna de uma tabela. Na fase Map do MapReduce, registros da fonte de dados são alimentados com a função map() por meio de pares de chave/valor. A função map() então produz um ou mais valores intermediários, juntamente com uma chave a partir da entrada de saída. Depois que a fase Map acaba, todos os valores intermediários dados a partir da chave de saída são combinados juntos em uma lista. A função reduce() então combina esses valores intermediários em um ou mais valores finais para uma mesma chave (SCHNEIDER, 2012, tradução nossa).
2.7 HADOOP
MapReduce é um bom começo, mas é necessário gastar um montante significativo de recursos tecnológicos e de desenvolvedores. Isso não seria viável para a maioria das empresas. Esta complexidade relativa levou ao advento do Hadoop. (SCHNEIDER, 2012, tradução nossa).
Hadoop é um framework open source para o processamento, armazenamento e análise de grandes quantidades de dados distribuídos não estruturados. Foi inspirado pelo MapReduce. O framework foi projetado para lidar com petabytes e exabytes de dados distribuídos em vários nós em paralelo. O Hadoop agora é um projeto da Apache Software Foundation, no qual centenas de contribuidores melhoram continuamente o core da tecnologia (SYED, 2013, tradução nossa).
Segundo White (2015, tradução nossa) em um feito publicado, a New York Times usou computação em nuvem, para processar 4 terabytes de arquivos digitalizados do papel, convertendo-os em PDFs para a Web. O tratamento durou menos de 24 horas para executar usando 100 máquinas, e o projeto provavelmente não teria sido empreendido sem a combinação do modelo de pay-by-the-hour da Amazon (que permitiu que o New York Times tivesse acesso a um grande número de máquinas por um curto período), e o modelo de programação paralela do Hadoop.
O mesmo autor conta que em Abril de 2008, o Hadoop quebrou o recorde mundial e se tornou o sistema mais rápido para classificar terabyte de dados. Executado em um cluster de 910 nós, o Hadoop classificou 1 terabyte em 209 segundos (pouco menos de 3,5 minutos), batendo o vencedor de 297 segundos do ano anterior. Em novembro do mesmo ano, o Google informou que a sua implementação própria de MapReduce ordenou 1 terabyte em 68 segundos. Em seguida, em abril de 2009, foi anunciado que uma equipe da Yahoo! tinha usado Hadoop para classificar 1 terabyte em 62 segundos.
Podemos dizer que um ambiente Hadoop possui 3 camadas básicas, no qual apresentam uma hierarquia lógica com uma completa separação de responsabilidades. Juntos essas três camadas resultam em uma implementação MapReduce completa.
A primeira camada é a “Application layer/end user access layer”, traduzindo, Camada de acesso do usuário final/Camada de aplicação, essa camada fornece um framework de aplicação distribuída para grandes conjuntos de dados. Ela serve como o ponto de contato para as aplicações interagirem com o Hadoop. Essas aplicações podem ser soluções internas ou ferramentas de terceiros. Para construir um desses aplicativos, geralmente se utiliza algumas interfaces populares de programação como Java, PIG (uma linguagem especializada de MapReduce em alto nível), ou Hive (uma linguagem especializada de MapReduce baseada em SQL) (SCHNEIDER, 2012, tradução nossa).
A segunda camada é a “MapReduce workload management layer”, traduzindo, Camada de gerenciamento de carga de trabalho de MapReduce, essa camada é conhecida como JobTracker. Este componente Hadoop fornece um mecanismo de execução de tarefas em tempo de execução. Este mecanismo coordena todos os aspectos do ambiente Hadoop, tais como programação e agendamento de tarefas, balanceamento de carga entre diferentes recursos e também lida com falhas e outros problemas. Esta camada é importante, pois é ela que deve garantir a confiabilidade e a performance de uma implantação Hadoop (SCHNEIDER, 2012, tradução nossa).
O mesmo autor complementa com a última camada, a “Distributed parallel file systems/data layer”, traduzindo, Camada de Sistemas de arquivos distribuídos em paralelo/Camada de dados, essa camada é responsável pelo armazenamento de informações. Por uma questão de eficiência, geralmente usa-se um sistema de arquivos distribuídos especializados. Na maioria dos casos, esse sistema de arquivos distribuídos é o do Hadoop, que será explanado a seguir.
2.7.1 Hadoop Distributed Filesystem (HDFS)
Sistemas que gerenciam o armazenamento de arquivos de máquinas interligadas em rede são chamados de sistemas de arquivos distribuídos (distributed filesystems).
White (2015, tradução nossa) ainda explica que seu funcionamento depende dos protocolos de rede, logo, todo as complicações relacionados a própria rede estão presentes,
por isso os sistemas de arquivos distribuídos são mais complexos que os sistemas de arquivos convencionais. Como por exemplo, o grande desafio de fazer com que o sistema de arquivo tolere falhas em seus nós sem que haja perda de dados. O Hadoop vem com um sistema de arquivo distribuído chamado HDFS. Esse sistema de arquivo distribuídos, que segundo Vieira (et al., 2012) é voltado para o processamento de volume de dados na ordem de Terabytes (ou Petabytes). Este sistema também suporta controle de falhas e acesso paralelo, sendo que os arquivos são automaticamente armazenados de forma redundante e transparente em vários nós. Os controladores do HDFS fazem com que em cada nó os dados sejam armazenados em blocos contínuos, o que facilita muito o acesso aos dados de forma sequencial. Outra importante característica é o “não cacheamento” dos arquivos, dado que estes podem chegar a tamanhos extremamente grandes, completa o autor.
O HDFS de acordo com White (2015, tradução nossa) foi projetado para armazenar arquivos muito grandes a uma taxa de transmissão de dados constantes, sendo executado em clusters com hardware de baixo custo.
2.7.1.1 NameNode e DataNodes
Segundo Chevreuil et al. (2012) o NameNode é o processo master do HDFS. Todas as operações de manipulação de arquivos ou pastas do HDFS são tratadas pelo NameNode. Isso porque é ele quem contém as informações de em quais nós ao longo do cluster estão cada segmento de arquivo salvo no HDFS, bem como os diretórios existentes e suas permissões de acesso.
Segundo Schneider (2012, tradução nossa) a maioria das implantações Hadoop possuem várias instâncias de nós masters. Pois, ter mais de um nó master ajuda a eliminar o risco de falhas.
Como todo dado salvo no HDFS é persistido em um arquivo (binário ou texto), arquivos representando grandes DataSets (como, por exemplo, total de mensagens trocadas entre usuários de uma rede social) logo excederiam a capacidade física do HD. Para resolver tal desafio o NameNode divide o arquivo em blocos de tamanho predefinido e define para quais DataNodes cada um desses segmentos será enviado. Além disso, a configuração do NameNode também define a quantidade de réplicas de cada bloco para mitigar possíveis
falhas de nós. O NameNode definirá quais nós irão receber cada uma das réplicas, balanceando a carga de uso de cada nó e levando em conta também o segmento de rede em que cada nó se encontra (Chevreuil et al., 2012).
Chevreuil et al. (2012) ressalta que o NameNode em momento algum manipula os dados persistidos no HDFS. Ele apenas coordena as operações a serem realizadas, provendo informações e instruções para que os programas clientes possam realizar essas operações diretamente com os nós onde os dados estão sendo gravados (ou de onde estão sendo lidos).
De acordo com White (2015, tradução nossa), sem o NameNode, o sistema de arquivo não poderia ser usado, na verdade a máquina que deveria rodar o NameNode seria obliterada, todo os arquivos no sistema de arquivo seriam perdidos, pois não haveria maneira de saber como reconstruir os arquivos dos blocos vindo dos DataNodes.
Acerca dos DataNodes, Chevreuil et al. (2012) explica que é o processo responsável por armazenar grandes blocos de arquivos que serão utilizados pela aplicação do usuário. Apesar de o NameNode desempenhar a maioria das funções administrativas do HDFS, os DataNodes detêm certa autonomia na manutenção dos dados e interação com clientes em processos de escrita e leitura. Por exemplo, cada DataNode se comunica com outros DataNodes para fazer a replicação dos seus blocos (por default um bloco é copiado entre 3 DataNodes).
Com a figura a seguir é possível visualizar como operam e se comunicam os DataNodes e o NameNodes.
Figura 6 – Arquitetura HDFS.
Fonte: Apache (2016)
2.7.2 Ecosistema Hadoop
O termo “Hadoop” muitas vezes é usado para se referir ao largo ecossistema de projetos, não apenas HDFS e MapReduce. Muito dessas soluções estão hospedadas na Apache Software Foundation, a qual disponibiliza suporte para a comunidade de projetos de software open sources. (WHITE, 2015, tradução nossa).
Segundo Placios (2011, citado por MENDES, 2015) a arquitetura das versões do Hadoop 0 e 1 se dividem em três pilares fundamentais, Hadoop MapReduce, o sistema de arquivo (HDFS) e por último o Hadoop Common. Esse último refere-se aos utilitários que possibilitam a integração dos subprojetos do ecossistema Hadoop.
A Figura 7 representa, em camadas, alguns dos projetos englobados no ecossistema do Hadoop.
Figura 7 – Ecossistema Hadoop em camadas.
Fonte: Gupta (2015)
Segundo Gupta (2015, tradução nossa):
Camada de armazenamento (Data Storage): É aonde o dado é armazenado em um sistema de arquivo distribuído, como HDFS e/ou no HBase. HBase é um banco de dados distribuído escalável, orientado a coluna, que suporta o armazenamento de dados estruturados para grandes tabelas.
Camada de Processamento de Dados (Data Processing): Aqui é onde o agendamento, e a gestão dos recursos e gerenciamento de cluster são calculados. O agendamento de Jobs pelo YARN e o gerenciamento de recursos do cluster com MapReduce são pertinentes a essa camada.
Camada de acesso de dados (Data Access): Essa camada é onde as requisições vindas da Management Layer passam, para serem processadas posteriormente na Processing Layer. A respeito das ferramentas, o Hadoop disponibiliza o Hive, o qual prove uma infraestrutura de data warehouse que permite a sumarização de dados e consultas adhoc. Pig, linguagem de alto nível de fluxo de dados e um framework para execução de computação paralela. Mahout, biblioteca para mineração de dados e aprendizado de máquina. E por último o projeto Avro, sistema de serialização de dados.
Camada de gestão de dados (Data Management): Essa é a camada mais próxima do usuário que acessa o sistema. Essa camada possui componentes como: Chukwa, sistema de coleção de dados para a gestão de grandes sistemas distribuídos. ZooKeeper, serviço de alta performance responsável por coordenar aplicações distribuídas.
De acordo com Apache (2012, apud MENDES, 2015) durante o processo de amadurecimento do Apache Hadoop um quarto pilar, denominado Yarn, foi inserido a partir da versão 2.
Segundo White (2015), o verdadeiro facilitador para novos modelos de processamento no Hadoop foi a introdução do YARN (Yet Another Resource Negotiator) na versão 2 do Hadoop. O YARN é um sistema de gerenciamento de recursos para clusters, o qual permite que qualquer distribuição de programa (não só MapReduce) rode em um cluster Hadoop.
Nos últimos anos, tem surgido diferentes padrões para processamento e que funcionam em conjunto com o Hadoop.
2.8 SPARK
Apache Spark é um framework para computação em cluster para processamento de dados em larga escala. Spark não usa MapReduce como mecanismo de execução, em vez disso, utiliza seu próprio mecanismo para trabalhar com clusters. Entretanto, é permitido utilização em paralelo com MapReduce, ele pode ser executado em YARN e trabalhar com formatos de arquivos e armazenamento Hadoop, como HDFS (WHITE, 2015, p. 549, tradução nossa).
Spark é conhecido por sua capacidade de manter grandes conjuntos de dados em processamento na memória em tempo de execução entre cada Job. Esta capacidade permite ao
Spark superar o fluxo de trabalho do MapReduce (Por uma ordem de magnitude ou mais em alguns casos), onde os conjuntos de dados são sempre carregados a partir do disco. Dois tipos de aplicação que são bastante beneficiadas com o modelo de processamento do Spark são os algoritmos iterativos (onde uma função é aplicada a um conjunto de dados repetidamente até que uma condição de saída seja atendida) e análises iterativas. (WHITE, 2015, p. 549, tradução nossa).
Mesmo quando o uso de caching2 em memória não se faça necessário, o Spark é atrativo por diversas outras razões, como seu mecanismo DAG (Directed Acyclic Graph), que diferente do MapReduce, que possui apenas 2 funções (map e reduce), DAG pode ter múltiplos níveis formando uma estrutura em árvore, sendo mais flexível e permitindo funcionalidades como map, filter, union etc. (WHITE, 2015, p. 549, tradução nossa).
A experiência do usuário com o uso de Spark também é um grande atrativo, com o seu conjunto de APIs para executar múltiplas tarefas de processamento de dados (como Joins por exemplo). O Spark fornece APIs em três linguagens: Scala, Java e Python. (WHITE, 2015, p. 550, tradução nossa).
Segundo Apache (2016), o projeto Apache Spark inclui módulos para aprendizado de máquina (MLlib), processamento em grafos (GraphX), processamento em stream (Spark Streaming), e SQL (Spark SQL), sendo possível combinar essas bibliotecas em uma mesma aplicação.
O Spark também conta com um componente que abstrai o conjunto de objetos distribuídos no cluster, este componente será abordado a seguir.
2.8.1 Resilient Distributed Datasets (RDD)
O conjunto de dados resilientes e distribuídos ou RDD (Resilient Distributed Datasets) é o conceito central do framework Spark. Segundo Penchikala (2015), o RDD pode ser comparado com uma tabela do banco de dados que pode guardar qualquer tipo de dado. O Spark armazena os dados do RDD em diferentes partições. Isso ajuda a reorganização computacional e a otimização no processamento dos dados.
2 Componente ou técnica de hardware ou software que armazena o dado previamente, para que consultas futuras
Os RDDs são imutáveis. Ainda que aparentemente seja possível modificar um RDD com uma transformação, na verdade o resultado dessa transformação é um novo RDD, sendo que o original permanece intocável. O RDD suporta dois tipos de operações:
Transformação: Não retornam um único valor, mas um novo RDD. Nada é avaliado quando a função de transformação é chamada, ela apenas recebe um RDD e retorna um novo RDD. Algumas das funções de transformação são map, filter, flatMap, groupByKey, reduceByKey, aggregateByKey, pipe e coalesce. (PENCHIKALA, 2015)
Ação: Esta operação avalia e retorna um novo valor. Quando uma função de ação é chamado em um objeto RDD, todas as consultas de processamento de dados são computadas e o valor é retornado. Algumas das operações de ação são reduce, collect, count, first, take, countByKey e foreach (PENCHIKALA, 2015).
A seguir é apresentado outro framework, que não pertence ao ecossistema do Hadoop, porém apresenta algumas semelhanças com o Spark.
2.9 FLINK
Apache Flink oferece suporte nativo ao streaming de dados, e é uma plataforma que efetua o processamento distribuído no cluster, através de processos workers que realizam o processamento de dados em memória.
Segundo Data Science Brazil (2016), Flink é muito similar ao projeto chamado Spark, porém oferece características como suporte a ordenação de eventos, semântica de consistência “exactly-once” que garante a unicidade dos eventos, suporte à manutenção dos estados dos eventos, divisão flexível do fluxo em "janelas", entre outras. Já o Spark tem uma abordagem diferente do Flink na manipulação do stream de dados, 'quebrando' internamente os streams de dados em pequenos processos batch (microbatches). Enquanto o Spark simula o processamento de streams com microbatch, o que pode gerar um atraso para aplicações real time - neste caso Spark é um processador quase em tempo real (near real time). Flink foi desenhado especificamente para manipular stream de dados e trata processos batch, como um caso especial de streaming de dados. Semelhante ao Spark, Flink também fornece uma API e um conjunto de bibliotecas para o desenvolvimento de aplicações de aprendizado de máquina (machine learning), processamento de grafos e suporte para SQL.
A seguir é apresentado um quadro para comparação das 3 plataformas que foram abordadas.
Quadro 1 – Comparativo da plataforma Flink com as demais.
Apache Hadoop Apache Spark Apache Flink Versão atual 2.8.1 (08/06/2017) 2.2.0 (11/07/2017) 1.3.2 (05/08/2017) Contribuidores (GitHub) 109 1.152 339 Suporte a Linguagens Suporte nativo em Java,porém outras linguagens como C, C++, Ruby, Groovy, Perl, Python também
são suportadas.
Suporte nativo em Scala, porém outras linguagens como Java, Python e R também são suportadas.
Suporte nativo em Java e Scala, porém outras linguagens como Python e
R são suportadas.
Engine de processamento de dados (core)
Batch Batch Streaming
Processamento Iterativo
Não provê suporte a processamento iterativo
nativamente.
Provê iteratividade de dados em Batch. Cada
iteração é agendada e executada separadamente.
Provê suporte nativo a processamento iterativo.Capaz de processar apenas partes
dos dados que foram alterados, assim aumentando sua performance.
Processamento
em Stream Não suportado
Utiliza micro-batches para todo o processamento em streaming. Considerado streaming em tempo quase real.
Utiliza sistema de stream real, inclusive para batch e micro-batch. Sendo o batch
um conjunto FINITO de dados em stream.
Modelo Computacional
Modelo Mapreduce que é puramente batch. Processa todo o junto de
dados do input e produz o resultado (output).
Utiliza micro-batch. Possui o mesmo tipo de
modelo computacional que o Hadoop, ou seja, coleta e então processa.
Adota o modelo continuo de fluxo baseado em operadores, processando os dados assim que recebidos,
sem delay em coletar e processar os dados. Fonte: Elaborado pelo autor
2.9.1 Componentes
O Flink também segue o modelo mestre-escravo, por meio de dois componentes: o JobManager e os TaskManagers. O JobManager é responsável por coordenar, enquanto que
os TaskManagers são os que executam o programa em paralelo (FRIEDMAN, 2016, tradução nossa).
3 MÉTODO
O método, segundo Garcia (1998, p. 44 apud HEERDT, 2007), "representa um procedimento racional e ordenado (forma de pensar), constituído por instrumentos básicos, que implica utilizar a reflexão e a experimentação, para proceder ao longo do caminho (significado etimológico de método) e alcançar os objetivos preestabelecidos no planejamento da pesquisa."
Este capítulo apresenta os procedimentos metodológicos utilizados pelo autor para atingir o objetivo deste trabalho. É contemplado no decorrer de suas seções o tipo de pesquisa seguida, a apresentação do esquema de solução, bem como as delimitações do trabalho.
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA
A pesquisa será feita seguindo uma abordagem de pesquisa qualitativa e com natureza aplicada, com análises comparativas e uso alguns cálculos estatísticos para medir resultados provenientes do uso prático de ferramentas e soluções para Big Data. Segundo Goldenberg (1997, p. 34 apud GERGARDT, 2009, p. 33) os pesquisadores que adotam a abordagem qualitativa opõem-se ao pressuposto que defende um modelo único de pesquisa para todas as ciências, já que as ciências sociais têm sua especificidade, o que pressupõe uma metodologia própria. Deslauriers (1991, p. 58 apud GERGARDT, 2009 p. 34) complementa afirmando que na pesquisa qualitativa “O desenvolvimento da pesquisa é imprevisível. O conhecimento do pesquisador é parcial e limitado. O objetivo da amostra é de produzir informações aprofundadas e ilustrativas: seja ela pequena ou grande, o que importa é que ela seja capaz de produzir novas informações”.
Quanto ao objetivo, a pesquisa irá seguir o caminho de uma pesquisa exploratória, pois segundo Gil (2007, apud GERGARDT, 2009, p. 35), este tipo de pesquisa tem como objetivo proporcionar maior familiaridade com o problema, com vistas a torná-lo mais explícito ou a construir hipóteses. A grande maioria dessas pesquisas envolve levantamento bibliográfico e análise de exemplos que estimulem a compreensão. Assim, essa pesquisa pode ser classificada como uma pesquisa bibliográfica e estudo de caso.
Por fim, o procedimento usado nessa pesquisa será bibliográfico. Segundo Fonseca (2002, apud GERGARDT, 2009, p. 37), a pesquisa bibliográfica é feita a partir do levantamento de referências teóricas já analisadas, e publicadas por meios escritos e eletrônicos, como livros, artigos científicos, páginas de web sites. Qualquer trabalho científico inicia-se com uma pesquisa bibliográfica, que permite ao pesquisador conhecer o que já se estudou sobre o assunto.
3.2 ETAPAS METODOLÓGICAS
As etapas deste trabalho serão as seguintes:
1) Problema: Nessa etapa é apresentado o problema que o presente trabalho de conclusão de curso se propõe a resolver em relação a processamento de dados para Big Data.
2) Fundamentação Teórica: Nesta etapa são apresentados os fundamentos do problema em questão, a fim de servir de embasamento para consultas e reforçar o conhecimento teórico de Big Data, processamento de dados e soluções correlatas.
3) Proposta de solução: Nessa etapa é elaborada a proposta de solução do problema, a fim de esclarecer os passos que serão realizados no experimento de contagem de palavras, e também descrevendo as ferramentas que serão utilizadas para o avanço da pesquisa.
4) Implementação da solução: Nessa etapa é realizada a implementação para a solução do problema, apresentando um passo a passo detalhado que o autor seguiu para se chegar na conclusão do experimento.
5) Apresentação da conclusão e trabalhos futuros: Serão apresentados os resultados gerados por esta monografia, em relação ao uso de algumas soluções em Big Data, e oportunidade de trabalhos futuros com base nos objetos estudados nesta monografia.
3.3 PROPOSTA DE SOLUÇÃO
O trabalho tem como objetivos explorar o uso das ferramentas para solução em Big Data, para isso foi escolhido pelo autor trabalhar com as ferramentas Apache Hadoop, Spark e Flink.
Para isso foi desenvolvido um programa de contador de palavras para consumir uma fonte de dados não estruturados e de tamanhos variáveis, processando-as em lote, para que se pudesse executa-las em todas as plataformas, a fim de obter seus respectivos tempos de execução.
Foi utilizado as APIs na linguagem Java para o desenvolvimento, por ser disponível em todas as 3 soluções e se tratar de uma linguagem em que o autor possui maior familiaridade.
No cenário proposto, o grande volume de dados, provenientes de fontes não estruturadas, justifica a utilização de técnicas de Big Data em função da necessidade de processamento desses dados, e na criação de um ambiente escalável.
3.4 DELIMITAÇÕES
A objetivo do trabalho é mostrar o processamento de dados não estruturados utilizando-se soluções de Big Data para o processamento do mesmo.
Por se tratar de um tema que exige a utilização de um ambiente distribuído para se extrair um melhor resultado, um orçamento para a criação desse tipo de cenário se faz necessário, nesse caso o trabalho se limitará com ferramentas e soluções gratuitas, já que trata-se de uma solução para fins educacionais.
Por isso foi decidido trabalhar de forma mínima possível em um ambiente local, em modo cluster único ou pseudo-distribuído, assim foi possível avaliar como as 3 plataformas estão mais otimizadas para se trabalhar nesta forma.
Os resultados obtidos por meio das soluções técnicas aplicadas serão meramente para a comparação de tempo de processamento e de digestão de dados complexos, portanto, não será feita análises estatísticas complexas a fim de se estudar um fenômeno específico.
4 PROPOSTA DE DESENVOLVIMENTO
Nesta seção estão descritos detalhes do experimento envolvendo as plataformas Hadoop, Spark e Flink.
4.1 EXPERIMENTO
O experimento será um contador de palavras, executado em todos as plataformas, e que irá processar em lote dados não estruturados e de tamanhos variáveis, a fim de obter seus respectivos tempos de execução.
4.1.1 Configuração Geral
Os experimentos e as ferramentas serão configuradas e emuladas em um ambiente Linux por meio da distribuição Ubuntu versão 16.04, com 8 GB de memória RAM e um processador com 4 cores. As 3 plataformas irão funcionar, em modo pseudo-distribuído, neste modo usa-se um único Nó (node). Onde será feito o uso do HDFS como sistema de arquivo compartilhado em conjunto com o YARN, assim será possível simular uma aplicação rodando em um cluster.
4.1.2 Contador de Palavras
O principal motivo para a escolha desta aplicação para avaliação das plataformas foi a similaridade de implementação utilizando Hadoop, Spark e Flink, além de que trabalhar
com um algoritmo de contagem de palavras demanda um processamento em lote com grandes volumes de dados, assim, dando a oportunidade de se medir o resultado por meio do ganho em tempo de execução (speedup) de cada plataforma em condições semelhantes.
Mais detalhes a respeito da implementação de um contador de palavras (word count), bem como seu funcionamento, pode ser observado na Figura 5 do capítulo 2, onde o modelo MapReduce é abordado.
4.1.2.1 Fonte de dados
Como fonte de dados o programa Word Count irá utilizar a constituição federal, disponibilizada no formato PDF pelo Supremo Tribunal Federal (BRASIL, 1988), possuindo 514 páginas, e com tamanho total de 2.8MB. Por se tratar de um arquivo relativamente pequeno, que não permite se extrair todo o potencial das ferramentas de objeto de estudo, foi decidido que o arquivo será convertido para formato texto (.txt), pois nesse formato o arquivo poderá ser facilmente replicado múltiplas vezes, com o objetivo de se chegar em um tamanho ideal para o objetivo da pesquisa e simular um processamento em larga escala. Para replicar o arquivo foi utilizado o seguinte comando no terminal linux:
for i in {1..N};do cat CONSTITUICAO.txt >> FONTE1.txt; done
Sendo N o número de vezes em que o arquivo texto terá seu conteúdo concatenado3. Para se obter uma fonte de dados de 1GB o arquivo foi concatenado 1000 vezes, para se obter a segunda fonte de 3GB, foram necessárias 3000 iterações, e por fim o arquivo de 5GB com 4850 iterações.
3 Concatenação é um termo usado em computação para designar a operação de unir o conteúdo de duas strings
5 DESENVOLVIMENTO
Este capítulo irá descrever o processo de desenvolvimento do experimento realizado por meio de uma aplicação de contagem de palavras. Além de demonstrar algumas das principais configurações das ferramentas Apache Hadoop, Apache Spark e Apache Flink, para se obter uma aplicação funcional onde será possível desenvolver o resultado proposto.
5.1 HISTÓRICO DE DESENVOLVIMENTO
Por se tratar de 3 ferramentas abordadas, sendo que cada uma delas demanda um certo tipo de configuração e de requisitos para ser executada, alguns passos não serão detalhados, pois apresentaria um conteúdo muito extenso e que não influenciará no resultado final do experimento.
5.1.1 Ferramentas e Tecnologias
Além das ferramentas que fazem parte do ecossistema de cada plataforma, foram utilizadas outras que contribuíram com o experimento e que serão apresentadas a seguir.
5.1.1.1 Eclipse
Eclipse é um ambiente de desenvolvimento integrado (IDE) usada para programação computacional, considerada uma das mais populares IDEs para desenvolvimento em Java. O software disponibiliza também um sistema extensível de plug-ins, que permite a customização do ambiente. Tem sua maior parte escrito em Java, porém é possível utilizá-lo para desenvolver em outras linguagens por meio de plug-ins. Eclipse é grátis e um software open-source, lançado sobre os termos de licença próprio. (ECLIPSE, 2017, tradução nossa).
Foi utilizada a versão Eclipse Neon (4.6.3), que já possui suporte a versão 8 do Java. Este software foi utilizado por ser uma ferramenta que facilita muito o desenvolvimento em Java, foi também utilizada porque possui plug-in para integração com o Maven, tal ferramenta é utilizada para automação de compilação, e será abordada com mais detalhes a seguir.
5.1.1.2 Maven
Apache Maven é uma ferramenta grátis de automação de compilação, utilizada primariamente em projetos Java. O Maven utiliza um arquivo XML, chamado de POM, no qual descreve o projeto sendo construído, suas dependências, seus componentes externos, sua ordem de compilação, diretórios e plug-ins necessários. Além de compilação de código e seu empacotamento, Maven baixa bibliotecas Java e seus plug-ins dinamicamente de seus repositórios próprios, e os armazena em uma área de cache local. (MAVEN, 2017, tradução nossa).
Foi escolhido trabalhar com o Maven pois facilita muito na compilação e na forma de servir a aplicação com as dependências necessárias para a utilização das APIs das plataformas estudadas neste experimento.
5.1.1.3 PDF to Text
Ferramenta online e grátis que permite converter PDF em arquivos de texto, sem a necessidade de instalação de um software. Foi necessária sua utilização para converter a fonte de dados do experimento e assim poder manipulá-la com mais facilidade. Tal ferramenta se encontra disponível em <http://pdftotext.com> (Acesso em 15 de outubro de 2017).
5.1.2 Histórico de Desenvolvimento
Nesta primeira parte, será descrito os seguintes requisitos iniciais de instalação do ambiente de execução do experimento:
Usuário do sistema inserido no grupo “Hadoop” Java Development Kit (JDK)
Cliente SSH sem password
Variáveis de ambiente mapeadas para Java, Hadoop e Yarn.
Para executar o Hadoop e consequentemente o HDFS é necessário que o usuário da aplicação esteja em um grupo chamado “Hadoop”, portanto, em vez de se criar o grupo e adicionar o usuário existente nesse grupo, foi escolhido por se criar um novo usuário chamado “hduser” e adicioná-lo ao novo grupo “Hadoop”.
Em seguida, para executar o experimento e consequentemente fazer funcionar todas as plataformas, é necessário a instalação do Java no ambiente de execução. Foi escolhida a última versão do Java, a versão 8, que possui compatibilidade com as 3 plataformas
O Hadoop se comunica através de autenticação SSH (Secure Shell), para isso o mesmo deve estar instalado e configurado corretamente. No caso da configuração se optou por utilizar uma chave pública DSA para o usuário hduser utilizar o serviço de SSH. Esta política permite a comunicação entre os nós, sem precisar inserir usuário e senha, como esse tipo de comunicação entre nós é bastante frequente, foi necessário adotar essa solução para evitar uma sobrecarga desnecessária devido a autenticação. Para isso foi utilizado os comandos como mostra o Quadro 2.
Quadro 2 – Configuração do SSH. ssh-keygen -t dsa -P '' -f ~/.ssh/id_dsa
cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys chmod 0600 ~/.ssh/authorized_keys
Fonte: Elaborado pelo autor
Em seguida é necessário configurar as variáveis de ambiente para o novo usuário, para isso, deve-se acessar o arquivo ~/.bashrc e adicionar as variáveis conforme o Quadro 3.
Quadro 3 – Configuração das variáveis de ambiente export JAVA_HOME=/usr/lib/jvm/java-8-oracle export HADOOP_HOME=/usr/local/hadoop export PATH=$PATH:$HADOOP_HOME/bin export PATH=$PATH:$HADOOP_HOME/sbin export HADOOP_MAPRED_HOME=$HADOOP_HOME export HADOOP_COMMON_HOME=$HADOOP_HOME export HADOOP_HDFS_HOME=$HADOOP_HOME export YARN_HOME=$HADOOP_HOME export HADOOP_COMMON_LIB_NATIVE_DIR=$HADOOP_HOME/lib/native export HADOOP_OPTS="-Djava.library.path=$HADOOP_HOME/lib" export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop Fonte: Elaborado pelo autor
5.1.2.1 Hadoop
Cumprida a primeira parte da instalação, agora serão descritos os passos seguidos para a criação da aplicação de contador de palavras e a sua execução no ambiente Hadoop.
O Hadoop possui vários arquivos de configuração em que se configura os diversos parâmetros para os vários componentes que rodam sobre o Hadoop, como HDFS, MapReduce, e o YARN.
Para não tornar esta sessão muito extensa, foi criado o Quadro 4, que demonstra apenas as linhas adicionadas ou alteradas, separando os arquivos por comentário.
