Um Guia Para a Modelagem e Desenvolvimento de … · Um Guia Para a Modelagem e Desenvolvimento de...

Capítulo

5Um Guia Para a Modelagem e Desenvolvimentode Aplicações Big Data Sobre o Modelo de Arqui-tetura Zeta

Kassiano J. Matteussi1 - [email protected] R. R. de Souza Jr2 - [email protected] C. S. dos Anjos3 - [email protected] F. R. Geyer4 - [email protected]

Abstract

A evidente e crescente instrumentação da sociedade e o uso da internet promove a ge-ração de dados em grandes proporções em uma era conhecida como Big Data. Essecenário tomou a atenção das mais variadas organizações que buscam maneiras eficazese de baixo custo para analisar, processar e minerar dados visando informações estratégi-cas e valiosas para seus negócios. Geralmente as organizações buscam desenvolver estassoluções em Big Data, entretanto muitos desafios são encontrados nesse percurso, onde

1Doutorando em Ciência da Computação pela Universidade Federal do Rio Grande Do Sul - UFRGS,Mestre em Ciências da Computação pela Pontifícia Universidade Católica do Rio Grande do Sul - PUCRS.Especialista em Engenharia e Qualidade de Software e Graduado em Ciência da Computação pela Univer-sidade Comunitária Regional de Chapecó - Unochapecó. Pesquisador nas áreas de Computação de AltoDesempenho (HPC), Virtualização, Nuvem Computacional e Big Data.

2Mestrando em Ciência da Computação pela Universidade Federal do Rio Grande do Sul - UFRGS.Possui graduação em Ciência da Computação pela Universidade de Passo Fundo. Pesquisador nas áreas deSistemas Distribuídos, Computação em Grade, HPC, Sistemas de Infraestrutura Híbrida e Big Data.

3Doutor em Ciências da Computação pela Universidade Federal do Rio Grande do Sul UFRGS/RS.Mestre em Ciência da Computação, pela Universidade Federal do Rio Grande do Sul. Graduado em Eng.Elétrica com ênfase em Eletrônica pela PUC/RS - Pontifícia Universidade Católica do Rio Grande do Sul.Pesquisador nas áreas de computação em grade, sistemas distribuídos, sistemas de infraestrutura híbrida,computação intensiva em dados, Big Data e sistemas virtuais.

4Pós-Doutorado em Informática pela Universite de Grenoble I (Scientifique Et Medicale - Joseph Fou-rier) - França. Doutorado em Informática pela Universite de Grenoble. Mestre em Ciência da Computaçãopela UFRGS/RS. Graduado em Engenharia Mecânica pela UFRGS/RS. Professor titular da UFRGS/RS,em Ciência da Computação. Áreas de interesse computação pervasiva (ubíqua), computação em grade, nasnuvens e voluntária, escalonamento e suporte a jogos multijogadores, computação intensiva em dados, comênfase na construção de middlewares.

Hands-on 83

a falta de conhecimento vai de encontro à complexidade na escolha de infraestrutura,linguagens de programação, plataforma e framework de processamento dessas soluções.Dessa forma, esse artigo apresenta a arquitetura Zeta como base a um guia de referên-cia para a modelagem e desenvolvimento de soluções Big Data. O guia é composto pelarelação entre a arquitetura Zeta e o ecossistema Big Data. Desse modo, busca favorecero desenvolvimento de soluções dinâmicas, flexíveis e adaptáveis para qualquer organiza-ção.

84 Um Guia Para a Modelagem e Desenvolvimento de Aplicações Big Data Sobre o Modelo de Arquitetura Zeta

5.1. IntroduçãoA evolução das redes sociais, redes de sensores, dispositivos móveis e todas as recentestecnologias de informação e comunicação utilizadas pela sociedade tem gerado dados deforma muito veloz. Como resultado, as organizações estão produzindo e armazenandograndes quantidades de dados. Por conseguinte, a capacidade de obter informações es-tratégicas, através da análise e processamento de dados, sobre preferências e produtosde consumidores com informações de tweets, blogs, avaliações de produtos e dados deredes sociais abre uma ampla gama de possibilidades para as organizações entenderemas necessidades de seus clientes, preverem seus desejos e demandas bem como a otimi-zação do uso de recursos [Marcos D et al. 2015]. Por esse motivo, muitas organizaçõesestão em busca de soluções eficientes, inteligentes, confiáveis e que ao mesmo tempo pos-suam baixo custo para lidar com processamento de dados em larga escala, exigidos poraplicações Big Data.

Apesar da popularidade, Big Data na prática exige esforço, é complexo e custoso,bem como incorre em um número considerável de desafios durante o desenvolvimentode soluções para esse fim [Marcos D et al. 2015, Fan and Bifet 2013]. Nesse contexto,soluções para o processamento de dados precisam ser tolerantes a falhas, escaláveis eextensíveis para suportar cargas de trabalho variadas.

Um marco importante nesse contexto foi o surgimento da arquitetura Lambda, cri-ada por Nathan Marz o criador do Apache Storm [Storm 2014]. Essa arquitetura provouser eficaz para muitos casos de uso que exigem processamento em lote e em tempo real,bem como é utilizada por diversas organizações. Desse modo, a escolha de uma arqui-tetura por si só é somente um dos componentes por trás do desenvolvimento de soluçõesBig Data.

Ao desenvolver soluções para a manipulação de dados é necessário que as orga-nizações façam uso ou adquiram conhecimento sobre o ecossistema Big Data como umtodo, ou seja, o que está por trás destas soluções, qual é a melhor forma para implementá-las, quais ferramentas e tecnologias deve-se utilizar e assim por diante. Em muitos casos,as organizações superam esses problemas efetuando investimento em infraestrutura, so-luções de software e em serviços de consultoria [Marcos D et al. 2015]. Entretanto, autilização e procura desses meios torna evidente a necessidade de um modelo de arquite-tura abrangente e de um guia que auxilie no desenvolvimento de soluções Big Data.

Desse modo, o modelo conceitual de arquitetura Zeta foi concebido para forneceruma modelo de alto nível para o desenvolvimento de soluções Big Data. O mesmo écomposto por 7 componentes bem definidos que podem ser facilmente relacionadas àstecnologias e soluções que compõem o ecossistema Big Data. Dessa forma, esse artigoapresenta a arquitetura Zeta como base a um guia de referência para a modelagem edesenvolvimento de soluções Big Data. Ao utilizar este guia será possível favorecer odesenvolvimento de soluções dinâmicas, flexíveis e adaptáveis para qualquer organização.

Este capitulo está organizado da seguinte forma: Na seção 5.2 é apresentada umavisão geral do tema Big Data, oportunidades e perspectivas; na seção 5.3 é introduzida aarquitetura Zeta; na seção 5.4 as tecnologias que compõem o “ecossistema"Big Data sãomostradas, relacionando diretamente com a arquitetura Zeta; na seção 5.5 um Hands-on

Hands-on 85

de uma aplicação Big Data é desenvolvido com base no guia proposto; por fim, na seção5.6 as considerações finais são apresentadas.

5.2. Big Data: Uma visão geralUm dos grandes desafios computacionais da atualidade se concentra em armazenar, ma-nipular e analisar de forma veloz e com baixo custo, um volume muito grande de dados(peta bytes diários) por sistemas corporativos, serviços e sistemas Web e mídias soci-ais [White 2009, Matteussi 2016]. Esses conjuntos de dados têm se tornado uma valiosafonte de informação que desperta o interesse de diversas organizações pela potencialidadeque pode trazer aos negócios. Como exemplos podem ser citados as corporações Googlee Facebook, responsáveis por gerar e manter grandes quantidades de dados oriundos deseus usuários [Polato et al. 2014]. Adicionalmente, o termo Big Data tem sido empregadopara descrever o crescimento, o uso e a disponibilidade das informações, sejam elas estru-turadas ou não [Chandarana 2014]. Ainda, Big Data pode ser categorizado por diferentesaspectos, características ou dimensões conhecidos como os 5Vs [Assuncao et al. 2015],conforme pode ser visto na Figura 5.1.

Figura 5.1. Big Data e suas Dimensões

Conforme pode ser visto na Figura 5.1 no contexto acadêmico algumas questõesinvestigadas são inerentes à melhor forma para se armazenar dados, aperfeiçoar o usode recursos, a transferência de dados, encontrar os limites de processamento e perfor-mance dentre outros. Por outro lado, para indústria é tipicamente interessante avaliara qualidade dos dados, as melhores estratégias para a mineração e monitoramento dosmesmos, a relevância dos resultados obtidos e o custo despendido para esse fim. Alémdisso, independente da organização, seja ela acadêmica ou da indústria, os 5Vs podem sercaracterizados da seguinte forma:

• Volume: infraestruturas de armazenamento estão se tornando cada vez mais aces-síveis, onde os dados gerados são gerados por diversas fontes e chegam a ordem depeta bytes ou zetta bytes;

• Velocidade: refere-se à velocidade com que os dados estão sendo produzidos, bemcomo o quão rápido os mesmos devem ser tratados para atender a análise e proces-samento;


• Variedade: os dados produzidos possuem naturezas diversas, por exemplo, sitesde comércio eletrônico utilizam dados estruturados, já logs de servidores web sãoconhecidos como dados semiestruturados, por outro lado redes sociais lidam comdados não estruturados como arquivos de áudio, vídeo, imagens, etc;

• Veracidade: diz respeito à confiabilidade sobre a fonte de dados, como por exem-plo, mensurar o sentimento dos clientes em redes sociais é incerto por natureza, jáque implica no uso do juízo humano. Mesmo assim, esses dados contêm valiosasinformações que mesmo imprecisas e incertas podem ser utilizadas como estáticasou dados históricos;

• Valor: o dado no seu formato original possui pouco valor, porém quando o mesmofor processado e analisado pode se tornar muito valioso, pois pode oferecer infor-mação estratégica ao negócio.

A riqueza contida nas informações obtidas pela análise e processamento de dadospotencializa a tomada de decisões estratégicas, de maneira a produzir informações muitovaliosas. Por esse motivo, muitas organizações buscam por soluções eficientes, inteligen-tes, confiáveis e de baixo custo para lidar com processamento e análise de dados em largaescala. No restante desse documento vão ser apresentados os desafios, perspectivas, bemcomo soluções existentes para esse fim.

5.2.1. Oportunidades e Perspectivas

Nos dias de hoje, muitas organizações buscam efetuar o desenvolvimento de soluçõesBig Data para auxiliar na tomada de decisão. Contudo, o processo de modelagem e de-senvolvimento dessa gama de aplicações é complexo e pode ser considerado um grandedesafio.

Nesse contexto, pode-se citar que os principais desafios inerentes ao desenvol-vimento de soluções Big Data estão ligados a: (i) a infraestrutura de armazenamento eprocessamento de dados necessária para suportar picos de processamento e de armazena-mento de dados em horários alternados. Em alguns casos o processamento pode demorarhoras ou dias, ou até mesmo ultrapassar a capacidade disponível das plataformas. Já oarmazenamento pode chegar a uma escala de grandeza na ordem de zetta bytes; (ii) o de-senvolvimento e a modelagem de soluções Big Data é uma tarefa complexa que demandaesforço e investimento, suprido geralmente por consultoria especializada; (iii) classificaras técnicas e algoritmos nas mais variadas áreas, tais como: matemática, estatística, in-teligência artificial, processamento natural de linguagem, análise preditiva e visualizaçãode dados exigem conhecimento abrangente e, em muitos casos a solução proposta podese tornar complexa devido às dificuldades em definir a infraestrutura ou em falhas naconcepção da arquitetura da aplicação.

Desse modo, reunir um conjunto de tecnologias de tal forma que qualquer orga-nização possa prover soluções na modelagem e desenvolvimento de aplicações Big Data,isto se tornou uma grande demanda. Principalmente porque existe a necessidade de ummodelo de arquitetura abrangente que se concentre em uma abordagem holística a fim defornecer eficácia, eficiência, agilidade e durabilidade para suportar mudanças e acomodarcargas de trabalho variadas.

Hands-on 87

Nesse contexto, a arquitetura ZETA [Scott 2015] foi escolhida para ser a basede um guia de referência para a modelagem e desenvolvimento de soluções Big Data.Ainda, essa arquitetura é considerada ideal para qualquer organização que deseje construiraplicações Big Data, principalmente porque apresenta componentes bem definidos emuma arquitetura conceitual de alto nível.

5.3. A Arquitetura ZETADevido aos inúmeros desafios encontrados nos mais variados segmentos da indústria eda academia relacionados ao gerenciamento de infraestrutura, modelagem e desenvolvi-mento de aplicações Big Data, notou-se a necessidade de um modelo padronizado quefosse referência para a resolução dos problemas anteriormente citados, mas também paraser ajustável a workloads, cenários e soluções variadas. A arquitetura ZETA [Scott 2015],criada por Jim Scott, é considerada uma arquitetura de alto nível que pode ser utilizadacomo referência para o desenvolvimento de soluções Big Data, isso porque a mesma édestinada a reduzir a complexidade em nível de sistema, enquanto aumenta a eficiênciada utilização dos recursos, esta arquitetura pode ser vista na Figura 5.2.

Figura 5.2. Arquitetura ZETA e seus componentes [Scott 2015]

Zeta é composta por sete componentes conectáveis que devem trabalhar em har-monia com o gerenciamento de recursos globais, todos explicados a seguir.

• Gestão Dinâmico e Global de Recursos: sem dúvida, essa é a principal camadadessa arquitetura. Localizado no centro da arquitetura o uso deste componente pos-sibilita a alocação dinâmica de recursos computacionais de forma compartilhada,permitindo a integração de inúmeras aplicações. Como exemplo, podemos citarMesos, YARN e outros;

• Sistema de Arquivos Distribuídos Compartilhado: simplifica a arquitetura de


sistema como um todo, pois permite que os programas armazenem e acessem ar-quivos de forma remota semelhante ao acesso local [Coulouris et al. 2013]. Alémdisso, esses sistemas possuem características como a transparência, escalabilidade,tolerância a falhas e segurança. Como exemplo, podemos citar o HDFS, GFS, oAmazon S3 e outros;

• Armazenamento em Tempo Real: esta camada é responsável pelo armazena-mento de cargas de trabalho cujo estado está em constante mudança. Como exem-plo, podemos citar o HBase entre outros;

• Frameworks para Processamento: são utilizados para efetuar o processamentoem lote ou em tempo real de cargas de trabalho variadas, compostas por dadosestruturados ou não. Como exemplos, podemos citar o Spark [Apache Spark 2014]e MapReduce dentre outros;

• Sistemas Virtualizados para tornar ágil o processo de implantação de software,muitas vezes é necessário oferecer maior liberdade de configuração aos desenvol-vedores. Nesse sentindo, a tecnologia de virtualização baseada em Contêinerespropicia ambientes padronizados, gerenciáveis, isolados e seguros. Como exem-plo, podemos citar o LXC, Docker e outros;

• Arquitetura da Solução: auxilia a satisfazer as necessidades das soluções em de-senvolvimento. São escolhidos o fluxo de trabalho, a arquitetura da infraestrutura,tecnologias, aplicações, técnicas, algoritmos, bibliotecas e componentes de soft-ware para o desenvolvimento da solução Big Data;

• Aplicação: apresenta o tipo da solução a ser construída e a lógica da implantação.Como exemplo, podemos citar aplicações web, de recomendação de conteúdo eanálise de sentimentos entre outros.

Ao utilizar uma abordagem padrão, qualquer organização poderá aproveitar o má-ximo dos recursos que possui, detectar e corrigir erros e manter a estabilidade dos dadosprocessados. Isso propicia a economia de recursos (tempo e investimento) sob testes, de-senvolvimento, transferência e processamento de dados e implantação de soluções. Essemodelo de arquitetura é projetado especialmente para a modelagem de aplicações BigData, mas também é possível modelar outras soluções de software. O uso dessa arqui-tetura como base para um guia de referência favorece o desenvolvimento de soluçõesdinâmicas, flexíveis e adaptáveis para qualquer organização.

5.4. O Ecossistema Big Data Sob a Perspectiva da Arquitetura ZETANesta seção, será apresentado um apanhado geral das principais tecnologias que compõemo "ecossistema"Big Data sob a perspectiva dos sete componentes da arquitetura ZETA.

5.4.1. Processamento em Lote (Batch Processing)

O processamento em lote representa uma maneira eficiente para a análise de dados emlarga escala, pois representa a execução de uma série de trabalhos (lote ou batch job)de uma aplicação sobre um ou mais computadores, sem a intervenção do usuário, ou

Hands-on 89

seja, não é interativo. Nesse sentido, o processamento em lote requer implementaçõesdistintas para cada fase: processamento inerente aos dados de entrada, transferência e pósprocessamento [Zaharia et al. 2016]. Alguns exemplos envolvem sistemas para o cálculode folhas de pagamento e faturamento, rentabilidade de fundos de investimento, backupsde banco de dados, atualização de estoques entre outros [IBM 2010].

Algumas características: enormes quantidades de dados de entrada são processa-dos, analisados e armazenados, produzindo informações valiosas e úteis às organizações;os dados são confiáveis; não possui tempo de resposta imediato, mas deve seguir o con-trato de nível de serviço (SLA) prescrito; os dados processados podem ser estruturados ounão; o processamento em lote pode ser composto por centenas ou milhares de trabalhos,processados em sequência.

5.4.2. Processamento em Tempo Real (Stream Processing)

O processamento em Tempo Real (TR) foi inicialmente utilizado nos setores de con-trole e automação, no ramo financeiro - bolsa de valores e comércio eletrônico, e hojejá é utilizado por inúmeras organizações e para as mais variadas finalidades. Dados emtempo real são gerados continuamente por milhares de fontes, que geralmente enviamos registros simultaneamente, em tamanhos pequenos (na ordem dos kilo bytes). Osdados em tempo real são variados, incluindo arquivos de logs gerados por clientes uti-lizando aplicativos móveis ou da web, compras em e-commerce, atividade do jogadordurante o jogo, informações de redes sociais, pregões financeiros ou serviços geo espa-ciais, como também telemetria de serviços conectados ou instrumentação em datacen-ters [Dos Anjos et al. 2015, Amazon 2016].

Esses dados devem ser processados contínua, sequencial e incrementalmente porregistro ou durante períodos móveis (janelas), e usados para uma ampla variedade de da-dos analíticos, como correlações, agregações, filtragem e amostragem [Amazon 2016]. Oprocessamento em TR deve ocorrer sobre uma arquitetura escalável, altamente disponívele tolerante a falhas [Bordin et al. 2016]. Além disso, TR trata os dados não como tabelasou arquivos estáticos, mas como um fluxo infinito e contínuo integrados a dispositivos,sensores (IOT) e informações históricas. As informações oriundas da análise de dados,propicia visibilidade sobre negócios e serviços para as organizações.

5.4.3. Arquiteturas para Processamento Big Data

Esta seção apresenta as arquiteturas mais populares utilizadas para o processamento BigData, bem como demonstra as principais diferenças e pontos de inflexão entre as mesmas.Criada por Nathan Marz, a arquitetura Lambda visa o processamento em lote e em temporeal. Essa abordagem de arquitetura busca equilibrar a latência, throughput e tolerânciaa falhas utilizando simultaneamente o processamento em lote para fornecer visualizaçõesabrangentes e precisas em tempo real sobre os dados. A arquitetura Lambda pode servista na Figura 5.3.

Lambda é basicamente formada por 3 camadas: (i) a camada de lote que ge-rencia grandes conjuntos de dados (imutáveis), geralmente dados históricos. Os mesmosão pré-processados em funções de consultas arbitrárias (views), tipicamente efetuadaspor frameworks como o Hadoop [White 2009], Hive [Hive 2015], Pig [Pig 2015] ou


Figura 5.3. Arquitetura Lambda [Scott 2015]

Spark [Zaharia et al. 2016]; (ii) a camada de velocidade ou tempo real processa pequenosconjuntos de dados de acordo com uma janela de tempo (por exemplo, 1 minuto). Essaestratégia permite o processamento em tempo real utilizando algoritmos incrementais. Éimportante ressaltar que a cada alteração é efetuado o reprocessamento dos dados. Aquipode-se usar, por exemplo, Flink, Spark ou Storm; (iii) a camada de serviço combina osresultados da camada de processamento em lote e em tempo real para permitir análisesinterativas rápidas (sem latência) por usuários. Esta camada pode utilizar bases de dadosrelacionais, mas também bases de dados não relacionais, como por exemplo o HBASE.

Já a arquitetura Kappa se concentra exclusivamente nas camadas de serviço e detempo real. Muito semelhante à arquitetura apresentada na Figura 5.3. Kappa é umasimplificação da arquitetura Lambda, evita a duplicidade de bases de dados e favorece oprocessamento de eventos. Geralmente, eventos são criados por dispositivos - Internet dasCoisas (IoT), redes sociais, arquivos de logs ou sistemas de processamento de transações.

5.4.4. Considerações e Tabela Comparativa

Ambas as arquiteturas podem ser implementadas combinando várias tecnologias open-source, como Apache Kafka, Apache HBase, Apache Hadoop (HDFS, MapReduce), Apa-che Spark, Apache Drill, Spark Streaming, Apache Storm e Apache Samza. Por exemplo,os dados podem ser inseridos utilizando um sistema de mensagens como o Kafka. O ar-mazenamento de dados pode ser implementado usando armazenamento persistente, comoHDFS. O processamento em lote pode ser feito pelo Hadoop MapReduce, enquanto o pro-cessamento em tempo real que exige baixa latência e suporte a atualizações incrementaispode utilizar o Storm ou Spark Streaming entre outros.

Finalmente, a escolha da arquitetura depende de alguns fatores, como por exem-plo, a expertise da equipe de desenvolvimento que pode ajudar a escolher as tecnologias ebasicamente sua estrutura. Em outro caso, os algoritmos aplicados para o processamentoem tempo real e em lote são idênticos, então é benéfico utilizar a arquitetura Kappa.Agora, se os algoritmos usados para o processamento em lote e em tempo real não foremidênticos, a escolha deve ser guiada pela simplicidade da codificação em comparação ao

Hands-on 91

desempenho. Ainda, em alguns casos, o processamento em lote pode superar o em temporeal e obviamente isso depende muito da maneira com que os dados são armazenados emuma base de dados. Por fim, sumarizamos ambas as arquiteturas na Tabela 5.1.

Tabela 5.1. Tabela Comparativa entre Arquiteturas

Plataforma eCaracterística Kappa Lambda

Modo deProcessamento

Tempo Real(micro-batch)

Lote e Tempo Real(batch e micro-batch)

ReprocessamentoSomente quando

o código for alteradoA cada ciclo

Acesso aos dados Algoritmos incrementaisAlgoritmos incrementais e

views (sobre todos os dados)

Confiabilidade Tempo real pode variarLote é confiavél e

Tempo real pode variar

5.4.5. Frameworks e Sistemas Big Data

Muitas organizações buscam por soluções eficientes, inteligentes, confiáveis e de baixocusto para lidar com processamento e análise de Big Data. Essas soluções geralmentesão realizadas utilizando o modelo de programação paralelo e distribuído MapReduce(MR) [Dean and Ghemawat 2004]. Por esse motivo, esta seção apresentará inicialmenteesse modelo, os principais framewors desenvolvidos sobre o mesmo e por fim os sistemasutilizados para gerenciá-los.

5.4.6. O modelo MapReduce e Suas Implementações

MR foi concebido pelo Google e efetua o processamento de dados através da execução devárias operações de map e reduce, ambas as funções implementadas pelo programador.A função de map recebe uma porção de dados do arquivo de entrada a ser processado,gerando um conjunto de tuplas intermediárias no formato chave-valor. As tuplas sãoautomaticamente agrupadas com base em suas chaves, transferidas pela fase de comuni-cação e sincronização, denominada shuffle, e em seguida cada função de reduce recebeuma chave como entrada, bem como uma lista com todos os valores gerados pelas fa-ses de map. Por fim, a lista de valores é processada e uma saída com os resultados égerada [Dean and Ghemawat 2004, Matteussi and De Rose 2015, Schemmer et al. 2015].O fluxo de funcionamento do MR pode ser observado na Figura 5.4.

Inicialmente, pode-se citar o Hadoop, um projeto da fundação Apache que im-plementa MR e é constituído por dois componentes principais: o Hadoop Distributed FileSystem (HDFS) para armazenamento de dados e o Hadoop MR (implementação MR).O ambiente de execução inclui um sistema de agendamento de tarefas que coordena aexecução de vários programas MR escritos em Java, que são enviados como trabalhosem lote. Um job MR consiste de várias tarefas de map e reduce que são escalonadasde forma simultânea para os nós em um cluster Hadoop [Matteussi 2016]. Também sãoencontradas APIs como o Hadoop Streaming que possibilita o processamento em temporeal e oferece suporte às linguagens de programação Python, PHP e Ruby entre outras.


Figura 5.4. Fluxo de Execução MapReduce

Já no Apache Storm, as aplicações são chamadas de topologias e são construídasna forma de DAGs, com spouts agindo como fontes de dados e bolts como operadores.A comunicação entre estes componentes acontece através de streams. Cada componentepode declarar as streams que serão produzidas e seus respectivos esquemas, mas apenasbolts podem consumir streams. O paralelismo de dados é provido no Storm pelo que échamado de stream grouping. O Storm garante que todas as mensagens emitidas pelosspouts serão processadas completamente ao mantê-las em uma fila até a confirmação deque elas foram processadas, e caso de uma mensagem falhar o spout irá enviá-la nova-mente para processamento [Gradvohl et al. 2014].

Por outro lado, o Apache Spark [Apache Spark 2014] é considerado um poderosoframework para o processamento e análise de dados de diversas naturezas (por exem-plo: texto, grafos, etc), bem como de diferentes origens (lote ou em tempo real com oSpark Streaming) [Zaharia et al. 2013]. Spark oferece computação em memória - Resili-ent Distributed Datasets (RDDs), onde eventos são processados em pequenos lotes comintervalos fixos de tempo para propiciar alto desempenho. Também é oferecido suporteao desenvolvimento com APIs para Java, Scala e Python. Spark pode ser executado sobYARN, Mesos, standalone ou na nuvem. Pode acessar diversas fontes de dados como oHDFS, NoSQL, HBase ou S3.

Apache Flink é considerado um framework para o processamento em lote e temporeal. Ele apresenta abstrações de programação em Java, Scala e, também, Python que for-nece uma API ainda em versão Beta. Possui um gerenciador de execução de alto desem-penho e otimização automática de código, bem como oferece suporte nativo para iteraçõesincrementais ou não incrementais [Alexandrov et al. 2014]. A Figura 5.5 apresenta as di-ferentes camadas da pilha do Flink que são construídas de forma a aumentar o nível deabstração das representações, como por exemplo, a definição e utilização de arquiteturaLambda em seu modelo. Diversos operadores são definidos com objetivo de ampliar agama do seu uso em aplicações, não apenas para isso, mas também para descomplicar asua implementação [Inoubli et al. 2016]. Além disso diversas bibliotecas são oferecidascom algoritmos de aprendizagem de máquina e deep learning. A seguir, são apresentadosos sistemas que permitem a orquestração e gerenciamento de recursos desses frameworkse suas aplicações.

YARN [Vavilapalli et al. 2013] ou MR versão 2.0 permite que vários frameworksde processamento de dados e suas aplicações compartilhem recursos sob uma única pla-taforma. A ideia fundamental do YARN é dividir as funcionalidades do gerenciamento

Hands-on 93

Figura 5.5. Arquitetura do Flink [Alexandrov et al. 2014]

de recursos, escalonamento e monitoramento de tarefas em daemons separados. Dessemodo, o YARN possui um ResourceManager global (RM) e um ApplicationMaster poraplicação (AM). Um aplicativo é um único trabalho ou um DAG de trabalhos. O Resour-ceManager e o NodeManager formam a estrutura de computação de dados. O Resour-ceManager é a autoridade final que arbitra recursos entre todas as aplicações no sistema.O NodeManager é o agente de estrutura por máquina que é responsável pelos contêine-res, monitorando o uso de recursos (CPU, memória, disco, rede) e relatando o mesmo aoResourceManager/Scheduler.

Do mesmo modo que o Yarn, o Apache Mesos [Hindman et al. 2011] permite oprocessamento, compartilhamento e gerenciamento de recursos de um cluster entre dife-rentes frameworks e aplicações, como Hadoop, MPI, Hypertable, Spark, Storm e outros.Assim, o Mesos cria uma grande coleção de recursos heterogêneos e introduz um me-canismo de programação distribuído de dois níveis chamado oferta de recursos. Destaforma, o Mesos decide quantos recursos oferecer a cada framework, enquanto os mesmosdecidem quais recursos aceitar e quais operações realizar. Trata-se de uma camada decompartilhamento de recursos fina que melhora o uso global de recursos.

Por fim, a utilização desses sistemas só é possível graças ao uso da sistemas vir-tualizados, em especial os baseados em contêineres. Seus principais representantes sãoo LXC e o Docker [Xavier et al. 2015, Xavier et al. 2016]. Além disso, contêineres re-presentam a forma mais leve de virtualização, pois atuam no mesmo nível do sistemaoperacional, favorecendo desempenho similar ao nativo por não utilizar subcamadas parase comunicar com os recursos computacionais. Nesse contexto, os sistemas Big Datacriam suas instâncias virtuais de forma isolada em meio a um ambiente compartilhadopor vários frameworks de processamento.

5.4.7. Considerações e Tabela Comparativa

A Tabela 5.2 sumariza as principais características dos frameworks e sistemas de proces-samento apresentados até aqui. Pode-se ressaltar que o MR é o modelo de programação


mais popular na atualidade. Atualmente, todas as aplicações utilizam este paradigma,bem como são executadas sobre frameworks compatíveis. Também é possível notar queas aplicações streaming estão em alta e por esse motivo o framework Spark esta sendomuito utilizado. Ainda, o mesmo oferece ampla variedade de APIs para auxiliar no de-senvolvimento de aplicações. Outra observação importante diz respeito ao frameworkFlink, que é muito eficaz para cenários IoT, pois suporta infraestrutura heterogênea e umagrande gama de aplicações com finalidades distintas.

Tabela 5.2. Tabela Comparativa - Frameworks de Processamento

Framework eCaracterísticas Hadoop Spark Storm Flink

ComputaçãoIterativa Não Sim Sim Sim

Modo deProcessamento Lote Tempo Real Tempo Real

Lote eTempo Real

Linguagem deProgramação Java

Java, Scalae Python

JavaJava, Scalae Python

Gerenciamentode Recursos

YARN eMesos

YARN eMesos

YARN/MesosZookpeer

Yarn eZookpeer

Informaçõesadicionais

GrandeCapacidade de

Armazenamento;APIs paraStreaming

e Monitoramento

InúmerasAPIs

para CriarAplicaçõesIterativas

Adequado paraAplicações em

Tempo Real

SuportaInfraestruturaHeterogênea;

Ideal paraAplicações

IoT

Por fim e não menos importante, é necessário apresentar os sistemas de arquivosdistribuídos e de armazenamento em tempo real (Figura 5.5). Esses sistemas fornecem oaporte para o processamento das aplicações e frameworks sob os sistemas Big Data, compor exemplo o Mesos e YARN.

5.4.8. Armazenamento de Arquivos Distribuído e em Tempo Real

Aplicações Big Data lidam com o processamentos de estruturados e não estruturados. Osdados estruturados geralmente são consolidados em banco de dados relacionais, apresen-tam fácil recuperação, manipulação e processamento. Já os dados não estruturados sãoconsiderados "crus"e referem-se, principalmente, a streaming de vídeo, áudio, dados pro-venientes de sensores, open-data não mapeados, comentários em redes sociais, tweets,e-mails dentre outros.

Dados não estruturados frequentemente possuem processamento, recuperação,identificação e interpretação complexos. Por conta desses motivos, pode-se dizer queos bancos de dados relacionais não são adequados para comportar esse tipo de dado. Issoporque esses dados dispõem de funcionalidades complexas para cenários onde são neces-sários esquemas e relações bem definidas, que não são ideais para dados não estruturados.Além disso, por possuírem essas características, o seu tempo de resposta se torna aindamaior, visto que aplicações em tempo real necessitam feedback imediato, ou quase paraseus usuários. Não obstante também são necessários dispositivos de armazenamento e

Hands-on 95

processamento que suportem esse formato de dado e garantam a melhor eficiência paraas análises.

As implementações MR são tipicamente acopladas a um sistema de arquivos dis-tribuídos (SAD), tais como GFS ou HDFS que possuem um sistema de arquivos altamentetolerante a falhas. O SAD é responsável pela distribuição de dados em um cluster MR,que consiste em dividir inicialmente os dados de entrada em blocos e armazenar réplicasde cada bloco nos discos locais dos nós do cluster. A localização dos dados é feita combase no escalonamento das tarefas MR. Por exemplo, as implementações MR tentam es-calonar as tarefas de map em nós que possuam réplicas dos dados de entrada. Isso ocorreporque é mais fácil trazer o processamento para o nó que possui o dado, do que utilizarintensivamente a rede [Neves 121].

Por outro lado, o uso de bancos não relacionais se adéqua muito bem ao Big Data.Os bancos de dados não relacionais (por exemplo, NoSQL, MongoDB [MongoDB 2017],Cassandra [Cassandra 2017]) possibilitam o processamento em tempo real, armazena-mento não estruturado (com gráficos / árvores, mapas de hash ou índices inversos) emelhor desempenho [Matteussi 2013]. Isso ocorre por que a maioria dessas soluções,são baseadas no projeto Big Table do Google [Chang et al. 2008], que trabalha com da-dos distribuídos usando hardware de baixo custo. Nesse mesmo contexto pode-se citar oHBase [George 2011], um SGBD não relacional orientado a colunas que permite leiturase gravações rápidas e aleatórias aos dados com baixa latência.

Por fim, não existe uma regra clara para uso de bancos relacionais ou não relacio-nais, mas é necessário observar qual é a melhor tecnologia para cada tipo de projeto. Emmuitos casos, o uso de soluções híbridas que usam tanto banco relacional como não rela-cional é comum. Um exemplo claro são os sites de e-commerces que necessitam controletransacional e, ao mesmo tempo, exigem baixo tempo de resposta para suportar picos deacesso e garantir qualidade de serviço.

5.4.9. Aplicações Big Data

O advento de IoT, da nuvem e do Big Data possibilita novas oportunidades para a análisee desenvolvimento de soluções. Aplicações Big Data podem ser utilizadas para os maisvariados fins e por qualquer organização. Essas soluções abrangem os dados obtidospor qualquer fonte, das redes sociais e sites web até os sensores espalhados por cidades,industrias, residências e lavouras [Mayer-Schonberger and Cukier 2014].

Nesse contexto, podem ser citadas como exemplo as seguintes aplicações: reco-mendação de conteúdo - nesse caso, os conteúdos são recomendados com base nas inte-rações anteriores do usuário em um web site; aplicações de classificação - consistem emdescobrir uma função que mapeie um conjunto de registros baseados em um conjunto dedados históricos; agrupamento (clusterização) - possui como objetivo segmentar regis-tros de um conjunto de dados em subconjuntos ou clusters, de tal forma que os elementosde um cluster compartilhem propriedades comuns que os distingam como, por exemplo,agrupar clientes pelo perfil de suas compras, para recomendar novos produtos para osmesmos.

Desse modo, a seguir apresenta-se um exemplo prático e intuitivo inerente ao de-


senvolvimento e à modelagem de uma aplicação Big Data para a classificação de dados.O desenvolvimento da mesma será efetuado utilizando o guia baseado no modelo de ar-quitetura conceitual Zeta, descrito nesse documento.

5.5. Hands-on: Um Exemplo PráticoNesta seção é apresentado um exemplo de aprendizagem simples para a classificação desentenças (PLN), orientado pela coleta de dados do Twitter. Esse modelo é dado comoexemplo de uma aplicação Big Data, onde podem ser aplicados os conceitos previamentediscutidos e, deste modo, analisados. Além disso, são mostrados e explicados os códigosfontes da aplicação desenvolvida.

5.5.1. A Aplicação

O fluxo de trabalho da aplicação proposta pode ser dividido em duas etapas, sendo aprimeira a coleta de informações sobre determinados assuntos de interesse do usuário.Esta etapa faz a coleta de tweets de dois assuntos específicos (Classes C1 e C2) - definidospelo usuário, a partir de uma hashtag. Na segunda etapa é feita a coleta de um terceirodado (C3), a ser classificado, para assim determinar sua tendência entre os assuntos dasclasses previamente coletadas.

Figura 5.6. Primeira Etapa da Aplicação

Durante a coleta dos dados, na primeira etapa, a aplicação inicialmente faz a con-tagem de bigramas5 dos dados de entrada. Na contagem dos bigramas, o tweet é nor-malizado (é removido qualquer tipo de acentuação e letras maiúsculas são colocadas emminúsculo). Em seguida os bigramas iguais são contados e armazenados, como pode servisto na Figura 5.6. Os tweets são coletados através da API disponibilizada pelo Twitter,onde é informada a palavra chave ou hashtag para filtrar os dados. Os dados são obtidosno formato JSON, contendo diversas informações.

Na segunda e última etapa, a aplicação relaciona o tweet com os dados passados.Para categorizar, o modelo faz uso de um classificador de texto probabilístico, chamadoNaive Bayes, onde esse modelo determina qual das classes, C1 e C2, possui a maiorequivalência em relação a C3. Uma vez que a classe predominante for encontrada, oresultado será disponibilizado ao usuário. O modelo completo da aplicação pode ser vistona Figura 5.7.

5Bigramas são combinações pares de unidades consecutivas, tais como letras, sílabas ou palavras

Hands-on 97

Figura 5.7. Aplicação Final

5.5.2. Arquitetura e Implementação

Por se tratar de uma aplicação de tempo real e apesar de ser uma aplicação simples, aindaé possível definir, pela arquitetura Zeta, os seguintes componentes para o ambiente: comoframework, foi determinado o uso do Flink, principalmente por ser apropriado à arquite-tura de solução lambda que se adéqua ao contexto da aplicação; é possível utilizar comobrokers tecnologias como o Apache Kafka6 e Mosquitto7; para a definição de armaze-namento, é recomendado no guia, bancos de dados não relacionais como por exemplo oMongoDB; essa aplicação é passível ao uso de sistemas de virtualização, como por exem-plo o Docker. Entretanto isso não é abordado, devido o crescimento de sua complexidade.

Essa aplicação será desenvolvida com a API Python do framework. A bibliotecaTweepy8 em Python foi utilizada como interface com a API do Twitter, para assim realizara coleta dos tweets. Após os dados serem processados, eles são armazenados em um bancode dados. Logo que os dados são coletados, a função de flat_map irá criar tuplas a partirdos bigramas possíveis (seguindo o padrão chave e valor). Um exemplo de entrada de umtweet e tuplas de saída pode ser visto a seguir.

»> map(["Exemplo de bigramas em tuplas"], 1)[(’Exemplo de’, 1), (’de bigramas’, 1), (’bigramas em’, 1),(’em tuplas’, 1)]

A função de flat_map é implementada da seguinte maneira. Uma função genéricaé criada para ser utilizada no Flink, onde para cada tweet de um dataflow, tem suas stringscriadas a partir das palavras separadas por espaço, agrupadas com seus "vizinhos", e emseguida as tuplas com os bigramas são criadas. É importante ressaltar que as funções mape flat_map do Flink não são bloqueantes. Uma vez que as tuplas são criadas e agrupadas,a partir de um ou mais tweets, a função de reduce já pode ser executada.

6http://kafka.apache.org/7https://mosquitto.org/8https://github.com/tweepy/tweepy


lambda tweet, c: [y for x in [[(word, 1) for word in [x.split(’ ’)[i] +’ ’ + x.split(’ ’)[1+i] for i in range(0, len(x.split(’ ’))-1)]]for x in tweet] for y in x]

Com as tuplas criadas, os dados serão agrupados por chave e a função de re-duce_group, que é a redução de dados agrupados, fará a contagem das tuplas que sãoiguais. A saída da função reduce_group será novas tuplas, com chave e valor respectivoao número de vezes que a tupla se repetiu.

class Adder(GroupReduceFunction):def reduce(self, iterator, collector):

count, word = iterator.next()count += sum([x[0] for x in iterator])collector.collect((count, word))

Para armazenar os dados obtidos, foi utilizada novamente uma função de map,como data sink da aplicação. Todavia, desta vez foi feito o uso de uma função genéricaque faz a comunicação com o banco de dados. Isso foi necessário por motivos de defi-ciência, da API em Python, em suportar a comunicação com o banco de dados em suafunção de Data Sink, que apenas suporta escrita em sistema de arquivos. Essa funçãode map ficou responsável pela comunicação com o MongoDB e assim salvar as tuplasobtidas pelo reduce.

.map(lambda y: cl.insert({"_id":y[1], "value":y[0]})if cl.find({"_id":y[1]}).count() == 0 else cl.update({"_id":y[1]},{"value": cl.find_one({"_id":y[1]})[’value’] + y[0]}))

Assim, a primeira etapa da aplicação está finalizada, os dados obtidos estão redu-zidos e armazenados para que a segunda etapa da aplicação possa utiliza-los. Agora serádescrita a segunda etapa, que irá classificar os tweets com base nas classes C1 e C2.

Na segunda etapa o tweet a ser classificado passa pela mesmas funções de map ereduce, utilizadas na primeira etapa, buscando contar os bigramas existentes nesse tweet.É necessário que o tweet passe novamente por esse processo a fim de obter as informaçõesnecessárias para que a classificação possa ser feita. Após as tuplas serem obtidas a aplica-ção realiza as contagens necessárias afim de classificar com o método Naive Bayes. Paraque isso seja possível um algoritmo que implementa o método NB é executado e assim,em seguida, os resultados são disponibilizados ao usuário. Logo que todos os resultadossão apresentados, a aplicação está finalizada.

5.6. ConclusãoO número de dados gerados pelos mais variados meios possibilita o desenvolvimento desoluções de análise e processamento Big Data altamente lucrativas e estratégicas. Dessemodo, a busca por esse tipo de solução aumentou consideravelmente. Para suprir talnecessidade, muitas tecnologias surgiram e outras mais irão surgir. De fato, essa procurasó tende a aumentar e junto a isso, a complexidade por trás do desenvolvimento dessassoluções.

Desse modo, a busca por um modelo padrão, que simplificasse a complexidadeencontrada durante o desenvolvimento de aplicações Big Data, se tornou essencial. Nesse

Hands-on 99

sentido, pode-se citar o modelo de arquitetura conceitual Zeta que apresenta em alto nívelsete componentes bem definidos, que representam os pilares fundamentais para o desen-volvimento de aplicações Big Data.

Finalmente, esse artigo apresentou um guia para a modelagem e desenvolvimentode aplicações Big Data sob a perspectiva do modelo conceitual de arquitetura Zeta. Esseguia é composto pela relação entre as tecnologias que compõem o ecossistema Big Datae a arquitetura Zeta. Como resultado, apresentou-se o desenvolvimento de uma aplicaçãoBig Data utilizando o mesmo.

Referências[Alexandrov et al. 2014] Alexandrov, A., Bergmann, R., Ewen, S., Freytag, J. C., Hu-

eske, F., Heise, A., Kao, O., Leich, M., Leser, U., Markl, V., Naumann, F., Peters, M.,Rheinländer, A., Sax, M. J., Schelter, S., Höger, M., Tzoumas, K., and Warneke, D.(2014). The stratosphere platform for big data analytics. VLBD Journal, 23(6):939–964.

[Amazon 2016] Amazon (2016). O que são dados em streaming? Acessado em:06/02/2017.

[Apache Spark 2014] Apache Spark (2014). Spark streaming programming guide. Aces-sado em: 04/02/2017.

[Assuncao et al. 2015] Assuncao, M. D., Calheiros, R. N., Bianchi, S., Netto, M. A.,and Buyya, R. (2015). Big Data computing and clouds: Trends and future directions.Journal of Parallel and Distributed Computing, 79–80:3–15. Special Issue on ScalableSystems for Big Data Management and Analytics.

[Bordin et al. 2016] Bordin, M. V., dos Anjos, J. C. S., Schemmer, R. B., and Geyer, C.F. R. (2016). Trabalhando com big data em tempo real. XVI ERAD 2016.

[Cassandra 2017] Cassandra, A. (2017). Apache cassandra. Acessado em: 04/02/2017.

[Chandarana 2014] Chandarana, P. (2014). Big Data Analytics Frameworks. Procee-dings of the International Conference on Circuits, Systems, Communication and Infor-mation Technology Applications, CSCITA’14, pages 430–434.

[Chang et al. 2008] Chang, F., Dean, J., Ghemawat, S., Hsieh, W. C., Wallach, D. A.,Burrows, M., Chandra, T., Fikes, A., and Gruber, R. E. (2008). Bigtable: A distri-buted storage system for structured data. ACM Transactions on Computer Systems,TOCS’2008, 26(2):4.

[Coulouris et al. 2013] Coulouris, G., Dollimore, J., Kindberg, T., and Blair, G. (2013).Sistemas Distribuídos: Conceitos e Projeto. Bookman Editora.

[Dean and Ghemawat 2004] Dean, J. and Ghemawat, S. (2004). MapReduce: SimplifiedData Processing on Large Clusters. Proceedings of the 6th Conference on Symposiumon Opearting Systems Design & Implementation, OSDI’04, pages 10–10.


[Dos Anjos et al. 2015] Dos Anjos, J. C., Assunção, M. D., Bez, J., Geyer, C., De Frei-tas, E. P., Carissimi, A., Costa, J. P. C., Fedak, G., Freitag, F., Markl, V., et al. (2015).Smart: An application framework for real time big data analysis on heterogeneouscloud environments. Proceedings of the IEEE International Conference on the Com-puter and Information Technology; Ubiquitous Computing and Communications; De-pendable, Autonomic and Secure Computing; Pervasive Intelligence and Computing(CIT/IUCC/DASC/PICOM)’2015, pages 199–206.

[Fan and Bifet 2013] Fan, W. and Bifet, A. (2013). Mining big data: Current status, andforecast to the future. ACM sIGKDD Explorations Newsletter, 14(2):1–5.

[George 2011] George, L. (2011). HBase: The Definitive Guide: Random Access to YourPlanet-Size Data. "O’Reilly Media, Inc.".

[Gradvohl et al. 2014] Gradvohl, A. L. S., Senger, H., Arantes, L., and Sens, P. (2014).Comparing distributed online stream processing systems considering fault toleranceissues. Journal of Emerging Technologies in Web Intelligence, 6(2):174–179.

[Hindman et al. 2011] Hindman, B., Konwinski, A., Zaharia, M., Ghodsi, A., Joseph,A. D., Katz, R. H., Shenker, S., and Stoica, I. (2011). Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center. Proceedings of the 8th USENIX Sympo-sium on Networked Systems Design and Implementation, NSDI’2011, 11(2011):22–22.

[Hive 2015] Hive, A. (2015). Apache Hive. Acessado em: 04/02/2017.

[IBM 2010] IBM, C. (2010). Mainframes working after hours: Batch processing. Aces-sado em: 04/02/2017.

[Inoubli et al. 2016] Inoubli, W., Aridhi, S., Mezni, H., and Jung, A. (2016). Big dataframeworks: A comparative study. arXiv preprint arXiv:1610.09962.

[Marcos D et al. 2015] Marcos D, A., Rodrigo N, C., Bianchi, S., Marco A, N., andBuyya, R. (2015). Big Data Computing and Clouds: Trends and Future Directions.Parallel and Distributed Computing. Science Direct, 79–80:3–15.

[Matteussi 2016] Matteussi, K. (2016). Um Estudo Sobre a Contenção de Disco em Am-bientes Virtualizados Utilizando Contêineres e Seu Impacto Sobre Aplicações MapRe-duce. Dissertação de Mestrado, Programa de Pós-Graduação em Ciência da Compu-tação, PUCRS., page 94.

[Matteussi and De Rose 2015] Matteussi, K. and De Rose, C. (2015). Uma estratégia dealocaç ao dinâmica e preditiva de recursos de I/O para reduzir o tempo de execuç aoem aplicaç oes mapreduce. XV ERAD 2015.

[Matteussi 2013] Matteussi, K. J. (2013). Protótipo de interface web com php para ge-renciamento de banco de dados couchdb.

[Mayer-Schonberger and Cukier 2014] Mayer-Schonberger, V. and Cukier, K. (2014).Big data: como extrair volume, variedade, velocidade e valor da avalanche de in-formação cotidiana, volume 1. Elsevier Brasil.

Hands-on 101

[MongoDB 2017] MongoDB (2017). MongoDB. Acessado em: 04/02/2017.

[Neves 121] Neves, M. V. (121). Application-aware Software-Defined networking toAccelerate Mapreduce Applications. Tese de Doutorado, Programa de Pós-Graduaçãoem Ciência da Computação, PUCRS. 2015. pp.

[Pig 2015] Pig, A. (2015). Apache Pig. Acessado em: 04/02/2017.

[Polato et al. 2014] Polato, I., Ré, R., Goldman, A., and Kon, F. (2014). A Comprehen-sive View of Hadoop Research—A Systematic Literature Review. Journal of Networkand Computer Applications, 46:1–25.

[Schemmer et al. 2015] Schemmer, R. B., Anjos, J. C., Tibola, A. L., Barros, J. F., andGeyer, C. F. (2015). Framework hadoop em plataformas de cloud e cluster computing.XV ERAD 2015, pages 1–18.

[Scott 2015] Scott, J. (2015). A Arquitetura Zeta. Acessado em: 04/02/2017.

[Storm 2014] Storm, A. (2014). Storm documentation. Acessado em: 04/02/2017.

[Vavilapalli et al. 2013] Vavilapalli, V. K., Murthy, A. C., Douglas, C., Agarwal, S., Ko-nar, M., Evans, R., Graves, T., Lowe, J., Shah, H., Seth, S., et al. (2013). Apachehadoop yarn: Yet another resource negotiator. Proceedings of the 4th annual Sympo-sium on Cloud Computing, page 5.

[White 2009] White, T. (2009). Hadoop: The Definitive Guide. O’Reilly Media, Inc.2009. 3rd. pp. 657, page 657.

[Xavier et al. 2015] Xavier, M. G., De Oliveira, I. C., Rossi, F. D., Dos Passos, R. D.,Matteussi, K. J., and De Rose, C. A. (2015). A performance isolation analysis ofdisk-intensive workloads on container-based clouds. Proceedings of the 23rd Euromi-cro International Conference on Parallel, Distributed and Network-Based Processing,PDP’2015, pages 253–260.

[Xavier et al. 2016] Xavier, M. G., Matteussi, K. J., Lorenzo, F., and De Rose, C. A.(2016). Understanding performance interference in multi-tenant cloud databases andweb applications. Proceedings of the IEEE International Conference on Big Data, BigData’2016, pages 2847–2852.

[Zaharia et al. 2013] Zaharia, M., Das, T., Li, H., Hunter, T., Shenker, S., and Stoica, I.(2013). Discretized streams: Fault-tolerant streaming computation at scale. Procee-dings of the Twenty-Fourth ACM Symposium on Operating Systems Principles, pages423–438.

[Zaharia et al. 2016] Zaharia, M., Xin, R. S., Wendell, P., Das, T., Armbrust, M., Dave,A., Meng, X., Rosen, J., Venkataraman, S., Franklin, M. J., Ghodsi, A., Gonzalez,J., Shenker, S., and Stoica, I. (2016). Apache spark: A unified engine for big dataprocessing. Commun. ACM, 59(11):56–65.


Um Guia Para a Modelagem e Desenvolvimento de … · Um Guia Para a Modelagem e Desenvolvimento de...

Documents

Transcript of Um Guia Para a Modelagem e Desenvolvimento de … · Um Guia Para a Modelagem e Desenvolvimento de...