1

Um Guia Para a Modelagem e Desenvolvimento

de Aplicações Big Data Sobre o Modelo de
Arquitetura Zeta
Kassiano J. Matteussi - kjmatteussi@inf.ufrgs.br 1
Paulo R. R. de Souza Jr - prrsjunior@inf.ufrgs.br 2
Julio C. S. dos Anjos - jcsanjos@inf.ufrgs.br 3
Claudio F. R. Geyer - geyer@inf.ufrgs.br4

Resumo:

A evidente e crescente instrumentação da sociedade e o uso da internet pro-

move a geração de dados em grandes proporções em uma era conhecida como Big
1
Doutorando 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 Universidade Comunitária Regional de Chapecó -
Unochapecó. Pesquisador nas áreas de Computação de Alto Desempenho (HPC), Virtualização, Nuvem Computacional e
Big Data.
2
Mestrando 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 de Sistemas Distribuídos, Computação
em Grade, HPC, Sistemas de Infraestrutura Híbrida e Big Data.
3
Doutor 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.
4
Pós-Doutorado em Informática pela Universite de Grenoble I (Scientifique Et Medicale - Joseph Fourier) - França.
Doutorado em Informática pela Universite de Grenoble. Mestre em Ciência da Computação pela UFRGS/RS. Graduado em
Engenharia Mecânica pela UFRGS/RS. Professor adjunto da UFRGS/RS, em Ciência da Computação. Áreas de interesse
computação pervasiva (ubíqua), computação em grade, nas nuvens e voluntária, escalonamento e suporte a jogos multijoga-
dores, computação intensiva em dados, com ênfase na construção de middlewares.
Data. Esse cenário tomou a atenção das mais variadas organizações que buscam
maneiras eficazes e de baixo custo para analisar, processar e minerar dados visando
informações estratégicas e valiosas para seus negócios. Geralmente, as organiza-
ções buscam desenvolver soluções Big Data, entretanto muitos desafios são encon-
trados nesse percurso, onde 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 arquite-
tura Zeta como base a um guia de referência para a modelagem e desenvolvimento
de soluções Big Data. O guia é composto pela relação entre a arquitetura Zeta e o
ecossistema Big Data. Desse modo, busca favorecer o desenvolvimento de soluções
dinâmicas, flexíveis e adaptáveis para qualquer organização.
1.1. Introdução

A evolução das redes sociais, redes de sensores, dispositivos móveis e todas

as recentes tecnologias de informação e comunicação utilizadas pela sociedade tem
gerado dados de forma muito veloz. Como resultado, as organizações estão produ-
zindo e armazenando grandes quantidades de dados. Por conseguinte, a capacidade
de obter informações estratégicas, através da análise e processamento de dados,
sobre preferências e produtos de consumidores com informações de tweets, blogs,
avaliações de produtos e dados de redes sociais abre uma ampla gama de possibili-
dades para as organizações entenderem as necessidades de seus clientes, preverem
seus desejos, demandas bem como a otimização do uso de recursos [MAR 2015].
Por esse motivo, muitas organizações estão em busca de soluções eficientes, inte-
ligentes, confiáveis e que ao mesmo tempo possuam baixo custo para lidar com
processamento de dados em larga escala, exigido por aplicaçõ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 de-
senvolvimento de soluções para esse fim [MAR 2015, FAN 2013]. Nesse contexto,
soluções para o processamento de dados precisam ser tolerantes a falhas, escaláveis
e extensíveis para suportar cargas de trabalho variadas.
Um marco importante nesse contexto foi Nathan Marz, criador do Apache
Storm [STO 2014] que apresentou a arquitetura Lambda. Essa arquitetura provou
ser eficaz para muitos casos de uso que exigiram processamento em lote e em tempo
real, bem como é utilizada por diversas organizações. Desse modo, a escolha de
uma arquitetura por si só é somente um dos componen5tes por trás do desenvolvi-
mento de soluções Big Data.
Ao desenvolver soluções para a manipulação de dados é necessário que as
organizações façam uso ou adquiram conhecimento sobre o ecossistema Big Data
como um todo, 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, soluções de software e em serviços de consulto-
ria [MAR 2015]. Entretanto, a utilização e procura desses meios torna evidente a
necessidade de um modelo de arquitetura 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
fornecer uma modelo de alto nível para o desenvolvimento de soluções Big Data.
O mesmo é composto por 7 camadas bem definidas que podem ser facilmente re-
lacionadas às tecnologias e soluções que compõem o ecossistema Big Data. 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. Ao utilizar este
guia será possível favorecer o desenvolvimento de soluções dinâmicas, flexíveis e
adaptáveis para qualquer organização.
Este capitulo está organizado da seguinte forma: Na seção 1.2 é apresentada
uma visão geral do tema Big Data, oportunidades e perspectivas; na seção 1.3 é
introduzida a arquitetura Zeta; na seção 1.4 as tecnologias que compõem o “ecos-
sistema"Big Data são mostradas, relacionando diretamente com a arquitetura Zeta;
na seção 1.5 um Hands-on de uma aplicação Big Data é desenvolvido com base no
guia proposto; por fim, na seção 1.6 as considerações finais são apresentadas.

1.2. Big Data: Uma visão geral

Um dos grandes desafios computacionais da atualidade se concentra em ar-
mazenar, manipular 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, mídias sociais [WHI 2009, MAT 2016]. Esses conjuntos de dados têm se tor-
nado uma valiosa fonte de informação que desperta o interesse de diversas organi-
zações pela potencialidade que pode trazer aos negócios, como exemplos podem ser
citadas as corporações Google e Facebook, responsáveis por gerar e manter grandes
quantidades de dados oriundos de seus usuários [POL 2014]. Adicionalmente, Big
Data trata-se de um termo empregado para descrever o crescimento, o uso e a dis-
ponibilidade das informações, sejam elas estruturadas ou não [CHA 2014]. Ainda,
Big Data pode ser categorizado por diferentes aspectos, características ou dimen-
sões conhecidas como os 5Vs [ASS 2015], como pode ser visto na Figura 1.1.

Figura 1.1: Big Data e suas Dimensões .

Conforme pode ser visto na Figura 1.1 no contexto acadêmico algumas ques-
tões investigadas são inerentes a melhor forma para se armazenar dados, aperfeiçoar
o uso de recursos, a transferência de dados, encontrar os limites de processamento e
performance dentre outros. Por outro lado, para indústria é tipicamente interessante
avaliar a qualidade dos dados, as melhores estratégias para a mineração e monitora-
mento dos mesmos, a relevância dos resultados obtidos e o custo despendido para
esse fim. Além disso, independente da organização, seja ela acadêmica ou da in-
dústria, Big Data pode ser caracterizado por diferentes aspectos, características ou
dimensões, como pode ser visto a seguir.

• Volume: infraestruturas de armazenamento estão se tornando cada vez mais

acessíveis, onde os dados gerados são gerados por diversas fontes e chegam a
ordem de peta bytes ou zetta bytes;

• Velocidade: refere-se a velocidade com que os dados estão sendo produzidos,

bem como o quão rápido os mesmos devem ser tratados para atender a análise
e processamento;

• Variedade: os dados produzidos possuem naturezas diversas, por exemplo,

sites de comércio eletrônico utilizam dados estruturados, já logs de servido-
res web são conhecidos como dados semiestruturados, por outro lado redes
sociais lidam com dados não estruturados como arquivos de áudio, vídeo,
imagens e etc;

• Veracidade: diz respeito à confiabilidade sobre a fonte de dados, como por

exemplo, mensurar o sentimento dos clientes em redes sociais é incerto por
natureza, já que implicam uso do juízo humano. Mesmo assim, esses da-
dos contêm valiosas informações que mesmo imprecisas e incertas podem ser
utilizas como estáticas ou dados históricos;

• Valor: o dado no seu formato original possui pouco valor, porem quando o
mesmo for processado e analisado pode se tornar muito valioso, pois pode
oferecer informação estratégica ao negócio.

A riqueza contida nas informações obtidas pela análise e processamento de

dados potencializam a tomada de decisões estratégicas, de maneira a produzir infor-
mações muito valiosas. Por esse motivo, muitas organizações buscam por soluções
eficientes, inteligentes, confiáveis e de baixo custo para lidar com processamento e
análise de dados em larga escala. No restante desse documento vão ser apresentados
os desafios, perspectivas, bem como soluções existentes para esse fim.
1.2.1. Oportunidades e Perspectivas
Nos dias de hoje, muitas organizações buscam efetuar o desenvolvimento
de soluções Big Data para auxiliar na tomada de decisão. Contudo, o processo de
modelagem e desenvolvimento dessa gama de aplicações é complexo e pode ser
considerado um grande desafio.
Nesse contexto, pode-se citar que os principais desafios inerentes ao desen-
volvimento de soluções Big Data estão ligados: (i) a infraestrutura de armazena-
mento e processamento de dados necessária para suportar picos de processamento
e de armazenamento de dados em horários alternados. Em alguns casos o processa-
mento pode demorar horas ou dias, ou até mesmo ultrapassar a capacidade disponí-
vel das plataformas. Já o armazenamento pode chegar a uma escala de grandeza na
ordem de zetta bytes; (ii) o desenvolvimento e a modelagem de soluções Big Data é
uma tarefa complexa que demanda esforço e investimento, suprido geralmente por
consultoria especializada; (iii) a classificação de técnicas e algoritmos nas mais vari-
adas áreas, tais como: matemática, estatística, inteligência artificial, processamento
natural de linguagem, análise preditiva e visualização de dados exige conhecimento
abrangente e, em muitos casos a solução proposta pode se tornar complexa devido
ao mau uso da infraestrutura ou falhas na concepção da arquitetura da aplicação.
Desse modo, reunir um conjunto de tecnologias de tal forma que qualquer
organização possa prover soluções na modelagem e desenvolvimento de aplicações
Big Data, isto se tornou uma grande demanda. Principalmente porque existe a ne-
cessidade de um modelo de arquitetura abrangente que se concentre em uma abor-
dagem holística a fim de fornecer eficácia, eficiência, agilidade e durabilidade para
suportar mudanças e acomodar cargas de trabalho variadas.
Nesse contexto, a arquitetura ZETA [SCO 2015] foi escolhia para ser a base
de 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 de-
seje construir aplicações Big Data, principalmente porque apresenta camadas bem
definidas em uma arquitetura conceitual de alto nível.

1.3. A Arquitetura ZETA

Devido aos inúmeros desafios encontrados nos mais variados segmentos da
indústria e da academia relacionados ao gerenciamento de infraestrutura, modela-
gem e desenvolvimento de aplicações Big Data, notou-se a necessidade de um mo-
delo padronizado que fosse referência para a resolução dos problemas anteriormente
citados, mas também para ser ajustável a workloads, cenários e soluções variadas.
A arquitetura ZETA [SCO 2015], criada por Jim Scott é considerada uma arquite-
tura de alto nível que pode ser utilizada como referência para o desenvolvimento
de soluções Big Data, isso porquê a mesma é destinada a reduzir a complexidade
em nível do sistema enquanto aumenta a eficiência da utilização dos recursos, essa
arquitetura, que pode ser vista na Figura 1.2.

Figura 1.2: Arquitetura ZETA e Suas Camadas [SCO 2015].

Zeta é composta por sete componentes conectáveis que devem trabalhar em

harmonia com o gerenciamento de recursos globais, todos explicados a seguir.

• Gestão Dinâmico e Global de Recursos: sem dúvidas, essa é a principal

camada dessa arquitetura. Localizado no centro da arquitetura o uso deste
componente possibilita a alocação dinâmica de recursos computacionais de
forma compartilhada, permitindo a integração de inúmeras aplicações. Como
exemplo, podemos citar Mesos, YARN e outros;

• Sistema de Arquivos Distribuídos Compartilhado: simplifica a arquite-

tura de sistema como um todo, pois permite que os programas armazenem e
acessem arquivos de forma remota semelhante ao acesso local [COU 2013].
Além disso, esses sistemas possuem características como a transparência, es-
calabilidade, tolerância a falhas e segurança. Como exemplo, podemos citar
o HDFS, GFS, o Amazon S3 e outros;
 • Armazenamento em Tempo Real: esta camada é responsável pelo arma-
zenamento de cargas de trabalho cujo o estado está em constante mudança.
Como exemplo, podemos citar o HBase entre outros;
• Frameworks para Processamento: são utilizados para efetuar o proces-
samento em lote ou em tempo real de cargas de trabalho variadas, com-
postas por dados estruturados ou não. Como exemplos, podemos citar o
Spark [Apa 2014], MapReduce dentre outros;
• Sistemas Virtualizados para tornar ágil o processo de implantação de soft-
ware, muitas vezes é necessário oferecer maior liberdade de configuração aos
desenvolvedores. Nesse sentindo, a tecnologia de virtualização baseada em
Contêineres propicia ambientes padronizados, gerenciáveis, isolados e segu-
ros. Como exemplo, podemos citar o LXC, Docker e outros;
• Arquitetura da Solução: auxilia a satisfazer as necessidades das soluções
em desenvolvimento. São escolhidos o fluxo de trabalho, a arquitetura da in-
fraestrutura, tecnologias, aplicações, técnicas, algoritmos, bibliotecas e com-
ponentes de software 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 implan-
tação. Como exemplo, podemos citar aplicações web, de recomendação de
conteúdo, análise de sentimentos entre outros.

Ao utilizar uma abordagem padrão, qualquer organização poderá extrair a

quantidade máxima dos recursos que possui, detectar e corrigir erros e manter a
estabilidade dos dados processados. Isso propicia a economia de recursos (tempo e
investimento) sob testes, desenvolvimento, transferência e processamento de dados
e implantação de soluções. Esse modelo de arquitetura é projetado especialmente
para a modelagem de aplicações Big Data, mas também é possível modelar outras
soluções de software. O uso dessa arquitetura como base para um guia de referên-
cia favorece o desenvolvimento de soluções dinâmicas, flexíveis e adaptáveis para
qualquer organização.

1.4. O Ecossistema Big Data Sob a Perspectiva da Ar-

quitetura ZETA
Nesta seção, será apresentado um apanhado geral das principais tecnologias
que compõem o "ecossistema"Big Data sob a perspectiva das sete camadas da ar-
quitetura ZETA.
1.4.1. Processamento em Lote (Batch Processing)
O processamento em lote representa uma maneira eficiente para a análise de
dados em larga 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 seja, não é interativo. Nesse sentido, o processamento em lote re-
quer implementações distintas para cada fase: processamento inerente aos dados de
entrada, transferência e pós processamento [ZAH 2016]. Alguns exemplos envol-
vem sistemas para o cálculo de folhas de pagamento e faturamento, rentabilidade de
fundos de investimento, backups de banco de dados, atualização de estoques entre
outros [IBM 2010].
Algumas características: enormes quantidades de dados de entrada são pro-
cessados, analisados e armazenados, reproduzindo 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 contrato de nível de serviço (SLA) prescrito; os dados processados
podem ser estruturados ou não; o processamento em lote pode ser composto por
centenas ou milhares de trabalhos, processados em sequência.

1.4.2. Processamento em Tempo Real (Stream Processing)

O processamento em Tempo Real (TR) foi inicialmente utilizado nos se-
tores de controle e automação, no ramo financeiro - bolsa de valores e comércio
eletrônico, e hoje já é utilizado por inúmeras organizações e para as mais variadas
finalidades. Dados em tempo real são gerados continuamente por milhares de fon-
tes, que geralmente enviam os registros simultaneamente, em tamanhos pequenos
(na ordem dos kilo bytes). Os dados em tempo real são variados, incluindo arqui-
vos de logs gerados por clientes utilizando aplicativos móveis ou da web, compras
em e-commerce, atividade do jogador durante o jogo, informações de redes sociais,
pregões financeiros ou serviços geo espaciais, como também telemetria de serviços
conectados ou instrumentação em datacenters [DOS 2015, AMA 2016].
Esses dados devem ser processados contínua, sequencial e incrementalmente
por registro ou durante períodos móveis (janelas), e usados para uma ampla va-
riedade de dados analíticos, como correlações, agregações, filtragem e amostra-
gem [AMA 2016]. O processamento em TR deve ocorrer sobre uma arquitetura
escalável, altamente disponível e tolerante a falhas [BOR 2016]. Além disso, TR
trata os dados não como tabelas ou arquivos estáticos, mas como um fluxo infinito
e contínuo, integrados a dispositivos e 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.
1.4.3. Arquiteturas para Processamento Big Data
Esta seção apresenta as arquiteturas mais populares utilizadas para o pro-
cessamento Big Data, 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 tempo real. Essa abordagem de arquitetura busca
equilibrar a latência, throughput e tolerância a falhas utilizando simultaneamente o
processamento em lote para fornecer visualizações abrangentes e precisas em tempo
real sobre os dados, essa arquitetura pode ser observada na Figura 1.3.

Figura 1.3: Arquitetura Lambda [SCO 2015].

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
mesmo são pré-processados em funções de consultas arbitrárias (views), tipica-
mente efetuadas por frameworks como o Hadoop [WHI 2009], Hive [HIV 2015],
Pig [PIG 2015] ou Spark [ZAH 2016]; (ii) a camada de velocidade ou tempo real
processa pequenos conjuntos de dados de acordo com uma janela de tempo (por
exemplo, 1 minuto). Essa estratégia permite o processamento em tempo real utili-
zando algoritmos incrementais, é importante ressaltar que a cada alteração é efetu-
ado o reprocessamento dos dados. Aqui pode-se usar, por exemplo, Flink, Spark ou
Storm; (iii) a camada de serviço combina os resultados da camada de processamento
em lote e em tempo real para permitir análises interativas rápidas (sem latência) por
usuários. Esta camada pode utilizar bases de dados relacionais, 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 de tempo real. Muito semelhante à arquitetura apresentada na Figura 1.3. Kappa
é uma simplificação da arquitetura Lambda, evita a duplicidade de bases de dados
e favorece o processamento de eventos. Geralmente, eventos são criados por dis-
positivos - Internet das Coisas (IoT), redes sociais, arquivos de logs ou sistemas de
processamento de transações.

1.4.4. Considerações e Tabela Comparativa

Ambas as arquiteturas podem ser implementadas combinando várias tecno-
logias open-source, como Apache Kafka, Apache HBase, Apache Hadoop (HDFS,
MapReduce), Apache Spark, Apache Drill, Spark Streaming, Apache Storm e Apa-
che Samza. Por exemplo, os dados podem ser inseridos utilizando um sistema de
mensagens como o Kafka. O armazenamento de dados pode ser implementado
usando armazenamento persistente, como HDFS. O processamento em lote pode
ser feito pelo Hadoop MapReduce, enquanto o processamento em tempo real que
exige baixa latência e suporte a atualizações incrementais pode utilizar o Storm,
Spark Streaming entre outros.
Finalmente, a escolha da arquitetura depende de alguns fatores, como por
exemplo, a expertise da equipe de desenvolvimento que, pode ajudar a escolher as
tecnologias e basicamente sua estrutura. Em outro caso, os algoritmos aplicados
para o processamento em tempo real e em lote são idênticos, então é benéfico utili-
zar a arquitetura Kappa. Agora, se os algoritmos usados para o processamento em
lote e em tempo real não forem idênticos, a escolha deve ser guiada pela simplici-
dade da codificação em comparação ao desempenho. Isso porque, em alguns casos,
o processamento em lote pode superar o em tempo real, obviamente isso depende
muito da maneira com que os dados são armazenados em uma base de dados. Por
fim, sumarizamos ambas as arquiteturas na Tabela 1.1.

Tabela 1.1: Tabela Comparativa entre Arquiteturas.

Plataforma e
Kappa Lambda
Característica
Modo de Tempo Real Lote e Tempo Real
Processamento (micro-batch) (batch e micro-batch)
Somente quando
Reprocessamento A cada ciclo
o código for alterado
Algoritmos incrementais e
Acesso aos dados Algoritmos incrementais
views (sobre todos os dados)
Lote é confiavél e
Confiabilidade Tempo real pode variar
Tempo real pode variar
1.4.5. Frameworks e Sistemas Big Data
Muitas organizações buscam por soluções eficientes, inteligentes, confiá-
veis e de baixo custo para lidar com processamento e análise de Big Data. Essa
soluções geralmente são realizadas utilizando o modelo de programação paralelo e
distribuído MapReduce (MR) [DEA 2004]. Por esse motivo, esta seção apresentará
inicialmente esse modelo, os principais framewors desenvolvidos sobre o mesmo e
por fim os sistemas utilizados para gerencia-lós.

1.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 de várias operações de map e reduce, ambas as funções implementa-
das 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ão automaticamente agrupadas com base em suas chaves,
transferidas pela fase de comunicação e sincronização, denominada shuffle, e em se-
guida cada função de reduce recebe uma chave como entrada, bem como uma lista
com todos os valores gerados pelas fases de map. Por fim, a lista de valores é proces-
sada e uma saída com os resultados é gerada [DEA 2004, MAT 2015, SCH 2015],
o fluxo de funcionamento pode ser observado na Figura 1.4.

Figura 1.4: Fluxo de Execução MapReduce.

Inicialmente, pode-se citar o Hadoop, um projeto da fundação Apache que

implementa MR e é constituído por dois componentes principais: o Hadoop Dis-
tributed File System (HDFS) para armazenamento de dados e o Hadoop MR (im-
plementação MR). O ambiente de execução inclui um sistema de agendamento de
tarefas que coordena a execução de vários programas MR escritos em Java, que
são enviados como trabalhos em lote. Um job MR consiste de várias tarefas de
map e reduce que são escalonadas de forma simultânea para os nós em um cluster
Hadoop [MAT 2016]. Também são encontradas APIs como o Hadoop Streaming
que possibilita o processamento em tempo real e oferece suporte a linguagem de
programação Python, PHP, Ruby entre outras.
Já no Apache Storm, as aplicações são chamadas de topologias e são cons-
truídas na 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 componente pode declarar as streams que serão produzidas e seus respecti-
vos esquemas, mas apenas bolts podem consumir streams. O paralelismo de da-
dos é provido no Storm pelo que é chamado de stream grouping. O Storm ga-
rante que todas as mensagens emitidas pelos spouts serão processadas completa-
mente ao mantê-las em uma fila até a confirmação de que elas foram processadas, e
caso de uma mensagem falhar o spout irá enviá-la novamente para processamento
[GRA 2014].
Por outro lado, o Apache Spark [Apa 2014] é considerado um poderoso fra-
mework 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
o Spark Streaming) [ZAH 2013]. Spark oferece computação em memória - Resili-
ent Distributed Datasets (RDDs), onde eventos são processados em pequenos lotes
com intervalos fixos de tempo para propiciar alto desempenho. Também é ofere-
cido suporte ao desenvolvimento com APIs para Java, Scala e Python. Spark pode
ser executado sob YARN, Mesos, standalone ou na nuvem. Pode acessar diversas
fontes de dados como o HDFS, NoSQL, HBase ou S3.
Apache Flink é considerado um framework para o processamento em lote
e tempo real. Ele apresenta abstrações de programação em Java, Scala e, também,
Python que fornece uma API ainda em Beta. Possui um gerenciador de execução
de alto desempenho e otimização automática de código, bem como oferece suporte
nativo para iterações incrementais ou não incrementais [ALE 2014]. A Figura 1.5
apresenta as diferentes camadas da pilha do Flink que são construídas de forma a
aumentar o nível de abstração das representações, como por exemplo, a definição
e utilização de arquitetura lambda em seu modelo. Diversos operadores são defi-
nidos com objetivo de ampliar a gama do seu uso em aplicações, não apenas para
isso, mas também para descomplicar a sua implementação [?]. Além disso diver-
sas bibliotecas são oferecidas com algoritmos de aprendizagem de máquina e deep
learning. A seguir, são apresentados os sistemas que permitem a orquestração e
gerenciamento de recursos desses frameworks e suas aplicações.
YARN [VAV 2013] ou MR versão 2.0 permite que vários frameworks de
processamento de dados e suas aplicações compartilhem recursos sob uma única
plataforma. A ideia fundamental do YARN é dividir as funcionalidades do geren-
ciamento de recursos e o escalonamento, do gerenciamento e monitoramento de
tarefas em daemons separados. Desse modo, o YARN possui um ResourceMana-
ger global (RM) e um ApplicationMaster por aplicação (AM). Um aplicativo é um
 Figura 1.5: Arquitetura do Flink [ALE 2014].

único trabalho ou um DAG de trabalhos. O ResourceManager e o NodeManager

formam a estrutura de computação de dados. O ResourceManager é 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êineres, monitorando
o uso de recursos (CPU, memória, disco, rede) e relatando o mesmo ao Resource-
Manager/Scheduler.
Do mesmo modo que o Yarn, o Apache Mesos [HIN 2011] permite o pro-
cessamento, compartilhamento e gerenciamento de recursos de um cluster entre
diferentes 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 in-
troduz um mecanismo de programação distribuído de dois níveis chamado oferta
de recursos. Desta forma, o Mesos decide quantos recursos oferecer a cada fra-
mework, enquanto os mesmos decidem quais recursos aceitar e quais operações re-
alizar. Trata-se de uma camada de compartilhamento de recursos fina que melhora
o uso global de recursos.
Por fim, o utilização desses sistemas só é possível graças ao uso da sistemas
virtualizados, em especial a baseada em contêineres. Seus principais representan-
tes são o LXC, e o Docker [XAV 2015, XAV 2016]. Além disso, contêineres repre-
sentam a forma mais leve de virtualização, pois atuam no mesmo nível do sistema
operacional, favorecendo desempenho similar ao nativo por não utilizar subcama-
das para se comunicar com os recursos computacionais. Nesse contexto, os sistemas
Big Data criam suas instâncias virtuais de forma isolada em meio a um ambiente
compartilhado por vários frameworks de processamento.
1.4.7. Considerações e Tabela Comparativa
A Tabela 1.2 sumariza as principais características dos frameworks e siste-
mas de processamento apresentados até aqui. Pode-se ressaltar que o MR é o mo-
delo de programação mais popular na atualidade, basicamente todas as aplicações
utilizam este paradigma, bem como são executadas sobre Frameworks compatíveis.
Também é possível notar que as aplicações streaming estão em alta e por esse mo-
tivo o framework Spark esta sendo muito utilizado. Ainda, o mesmo oferece ampla
variedade de APIs para auxiliar no desenvolvimento de aplicações. Outra obser-
vação importante diz respeito ao framework Flink, o mesmo é muito eficaz para
cenários IoT, pois suporta infraestrutura heterogênea e uma grande gama de aplica-
ções com finalidades distintas.

Tabela 1.2: Tabela Comparativa - Frameworks de Processamento.

Framework e
Hadoop Spark Storm Flink
Características
Computação
Não Sim Sim Sim
Iterativa
Modo de Lote e
Lote Tempo Real Tempo Real
Processamento Tempo Real
Linguagem de Java, Scala Java, Scala
Java Java
Programação e Python e Python
Gerenciamento YARN e YARN e YARN/Mesos Yarn e
de Recursos Mesos Mesos Zookpeer Zookpeer
Grande Suporta
Inúmeras
Capacidade de Infraestrutura
APIs Adequado para
Informações Armazenamento; Heterogênea;
para Criar Aplicações em
adicionais APIs para Idela para
Aplicações Tempo Real
Streaming Aplicações
Iterrativas
e Monitoramento IoT

Por fim e não menos importante, pode-se citar os sistemas de arquivos distri-
buídos e de armazenamento em tempo real (Figura 1.5). Esses sistemas fornecem o
aporte para o processamento das aplicações e frameworks sob os sistemas Big Data,
com por exemplo o Mesos e YARN.

1.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. Os dados estruturados geralmente são consolidados em banco de da-
dos relacionais, apresentam fácil recuperação, manipulação e processamento. Já os
dados não estruturados são considerados "crus"e referem-se, principalmente, a stre-
aming de vídeo, áudio, dados provenientes 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 complexas. Por conta desses motivos, pode-se
dizer que os bancos de dados relacionais não são adequados para comportar esse
tipo de dado. Isso porque esses dados dispõem de funcionalidades complexas para
cenários onde são necessários esquemas e relações bem definidas, que não são ide-
ais para dados não estruturados. Além disso, por possuírem essas características,
o seu tempo de resposta se torna ainda maior, visto que aplicações em tempo real
necessitam feedback imediato, ou quase para seus usuários. Não obstante também
são necessários dispositivos de armazenamento e processamento que suportem esse
formato de dado e garantam a melhor eficiência para as análises.
As implementações MR são tipicamente acopladas a um sistema de arquivos
distribuídos (SAD), tais como GFS ou HDFS que possuem um sistema de arquivos
altamente tolerante 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éplicas de cada bloco nos discos locais dos nós do cluster. A locali-
zação dos dados é feita com base no escalonamento das tarefas MR. Por exemplo,
as implementações MR tentam escalonar as tarefas de map em nós que possuam ré-
plicas dos dados de entrada. Isso ocorre porque é mais fácil trazer o processamento
para o nó que possui o dado, do que utilizar intensivamente a rede [NEV 21].
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 [MON 2017],
Cassandra [CAS 2017]) possibilitam o processamento em tempo real, armazena-
mento não estruturado (com gráficos / árvores, mapas de hash ou índices inversos)
e melhor desempenho [MAT 2013]. Isso ocorre por que a maioria dessas soluções,
são baseadas no projeto Big Table do Google [CHA 2008], que trabalha com dados
distribuídos usando hardware de baixo custo. Nesse mesmo contexto pode-se citar
o HBase [GEO 2011], um SGBD não relacional orientado a colunas que permite
leituras e 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
relacionais, mas é necessário observar qual é a melhor tecnologia para cada tipo
de projeto. Em muitos casos, o uso de soluções híbridas que usam tanto banco
relacional como não relacional é comum. Um exemplo claro são os sites de e-
commerces que necessitam controle transacional e, ao mesmo tempo exigem baixo
tempo de resposta para suportar picos de acesso e garantir qualidade de serviço.
1.4.9. Aplicações Big Data
O advento de IoT, da nuvem e do Big Data possibilita novas oportunidades
para a análise e desenvolvimento de soluções. Aplicações Big Data podem ser
utilizadas para os mais variados fins e por qualquer organização. Essas soluções
abrangem os dados obtidos por qualquer fonte, das redes sociais e sites web até os
sensores espalhados por cidades, industrias, residências e lavouras [MAY 2014].
Nesse contexto, podem ser citadas como exemplo as seguintes aplicações:
recomendação de conteúdo - nesse caso, os conteúdos são recomendados com
base nas interações anteriores do usuário em um web site; Aplicações de classifi-
cação - consistem em descobrir uma função que mapeie um conjunto de registros
baseados em um conjunto de dados históricos; agrupamento (clusterização) - pos-
sui como objetivo segmentar registros de um conjunto de dados em subconjuntos ou
clusters, de tal forma que os elementos de um cluster compartilhem propriedades
comuns que os distingam como, por exemplo, agrupar clientes pelo perfil de suas
compras, para recomendar novos produtos para os mesmos.
Desse modo, a seguir apresenta-se um exemplo prático e intuitivo inerente
ao desenvolvimento 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 arquitetura conceitual Zeta, descrito nesse documento.

1.5. Hands-on: Um Exemplo Prático

Nesta seção é apresentado um exemplo de aprendizagem simples para a clas-

sificação de sentenças (PLN), orientado pela coleta de dados do Twitter. Esse mo-
delo é dado como exemplo de uma aplicação Big Data, onde podem ser aplicados
os conceitos previamente discutidos e, deste modo, analisados. Além disso, são
mostrados e explicados os códigos fontes da aplicação desenvolvida.

1.5.1. A Aplicação
O fluxo de trabalho da aplicação proposta pode ser dividida em duas etapas,
sendo a primeira 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 ) - definidos pelo usuário, a partir de uma hashtag. Na segunda etapa é
feita a coleta de um terceiro dado (C3 ), a ser classificado, para assim determinar sua
tendência entre os assuntos das classes previamente coletadas.
Durante a coleta dos dados, na primeira etapa, a aplicação inicialmente faz a
 Figura 1.6: Primeira Etapa da Aplicação.

contagem de bigramas5 dos dados de entrada. Na contagem dos bigramas, o tweet é

normalizado (é removido qualquer tipo de acentuação e letras maiúsculas são colo-
cadas em minúsculo). Em seguida os bigramas iguais são contados e armazenados,
como pode ser visto na Figura 1.6. Os tweets são coletados através da API dispo-
nibilizada pelo Twitter, onde é informada a palavra chave ou hashtag para filtrar os
dados. Os dados são obtidos no formato JSON, contendo diversas informações.

Figura 1.7: Aplicação Final.

Na segunda e última etapa, a aplicação relaciona o tweet com os dados passa-

dos. Para categorizar, o modelo faz uso de um classificador de texto probabilístico,
chamado Naive Bayes. Onde esse modelo determina qual das classes, C1 e C2 , pos-
sui a maior equivalência em relação a C3 . Uma vez que a classe predominante for
5
Bigramas são combinações pares de unidades consecutivas, tais como letras, sílabas ou palavras
encontrada, será disponibilizado ao usuário. O modelo completo da aplicação pode
ser visto na Figura 1.7.

1.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: como framework, foi determinado o uso do Flink, principalmente
por ser apropriado à arquitetura de solução lambda que se adéqua ao contexto da
aplicação; é possível utilizar como brokers tecnologias como o Apache Kafka6 e
Mosquitto7 ; para a definição de armazenamento, é recomendado no guia, bancos de
dados não relacionais como por exemplo o MongoDB; essa aplicação é passível ao
uso de sistemas de virtualização, como por exemplo 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 bibli-
oteca Tweepy8 em Python foi utilizada como interface com a API do Twitter, para
assim realizar a coleta dos tweets. Após os dados serem processados, eles são ar-
mazenados em um banco de dados. Logo que os dados são coletados, a função de
flat_map irá criar tuplas a partir dos bigramas possíveis (seguindo o padrão chave
e valor). Um exemplo de entrada de um tweet e tuplas de saída podem 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 strings criadas a partir das palavras separadas por espaço, agrupadas com
seus "vizinhos" e em seguida as tuplas com os bigramas são criadas. É importante
ressaltar que as funções map e 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.
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

reduce_group, que é a redução de dados agrupados, fará a contagem das tuplas que
6
http://kafka.apache.org/
7
https://mosquitto.org/
8
https://github.com/tweepy/tweepy
são iguais. A saída da função reduce_group será novas tuplas, com chave e valor
respectivo ao 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érica que faz a comunicação com o banco de dados. Isso foi necessário por mo-
tivos de deficiência, da API em Python, em suportar a comunicação com o banco
de dados em sua função de Data Sink, que apenas suporta escrita em sistema de ar-
quivos. Essa função de map ficou responsável pela comunicação com o MongoDB
e assim salvar as tuplas obtidas 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

reduzidos 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 e reduce, 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ções necessá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 clas-
sificar com o método Naive Bayes. Para que isso seja possível um algoritmo que
implementa o método NB é executado e assim, em seguida, os resultados são dispo-
nibilizados ao usuário. Logo que todos os resultados são apresentados, a aplicação
está finalizada.

1.6. Conclusão

O número de dados gerados pelos mais variados meios possibilita o desen-

volvimento de soluções de análise e processamento Big Data altamente lucrativas e
estratégicas. Desse modo, a busca por esse tipo de solução aumentou consideravel-
mente. Para suprir tal necessidade, muitas tecnologias surgiram e outras mais iram
surgir. De fato, essa procura só tende a aumentar e junto a isso, a complexidade por
trás do desenvolvimento dessas soluções.
Desse modo, a busca por um modelo padrão, que simplificasse a comple-
xidade encontrada durante o desenvolvimento de aplicações Big Data, se tornou
essencial. Nesse sentido, pode-se citar o modelo de arquitetura conceitual Zeta que
apresenta em alto nível sete camadas bem definidas que representam os pilares fun-
damentais para o desenvolvimento de aplicações Big Data.
Finalmente, esse artigo apresentou um guia para a modelagem e desenvol-
vimento de aplicações Big Data sob a perspectiva do modelo conceitual de arquite-
tura Zeta. Esse guia é composto pela relação entre as tecnologias que compõem o
ecossistema Big Data e a arquitetura Zeta. Como resultado, apresenta-se o desen-
volvimento de uma aplicação Big Data utilizando o mesmo.

1.7. Bibliografia
[ALE 2014] ALEXANDROV, A. et al. The Stratosphere platform for big data analytics.
VLBD Journal, v.23, n.6, p.939–964, 2014.

[AMA 2016] AMAZON. O que são dados em streaming? Acessado em: 06/02/2017.

[Apa 2014] Apache Spark. Spark streaming programming guide. Acessado em:
04/02/2017.

[ASS 2015] ASSUNCAO, M. D. et al. Big Data computing and clouds: trends and fu-
ture directions. Journal of Parallel and Distributed Computing, v.79–80,
p.3–15, 2015. Special Issue on Scalable Systems for Big Data Management
and Analytics.

[BOR 2016] BORDIN, M. V. et al. Trabalhando com big data em tempo real. XVI
ERAD 2016, 2016.

[CAS 2017] CASSANDRA, A. Apache cassandra. Acessado em: 04/02/2017.

[CHA 2014] CHANDARANA, P. Big Data Analytics Frameworks. Proceedings of

the International Conference on Circuits, Systems, Communication
and Information Technology Applications, CSCITA’14, p.430–434,
April 2014.

[CHA 2008] CHANG, F. et al. Bigtable: a distributed storage system for structured data.
ACM Transactions on Computer Systems, TOCS’2008, v.26, n.2, p.4,
2008.

[COU 2013] COULOURIS, G. et al. Sistemas Distribuídos: Conceitos e Projeto. [S.l.]:

Bookman Editora, 2013.
[DEA 2004] DEAN, J.; GHEMAWAT, S. MapReduce: Simplified Data Processing on
Large Clusters. Proceedings of the 6th Conference on Symposium on
Opearting Systems Design & Implementation, OSDI’04, Berkeley, CA,
USA, p.10–10, 2004.

[DOS 2015] DOS ANJOS, J. C. et al. Smart: an application framework for real time big
data analysis on heterogeneous cloud environments. Proceedings of the
IEEE International Conference on the Computer and Information Te-
chnology; Ubiquitous Computing and Communications; Dependable,
Autonomic and Secure Computing; Pervasive Intelligence and Compu-
ting (CIT/IUCC/DASC/PICOM)’2015, p.199–206, 2015.

[FAN 2013] FAN, W.; BIFET, A. Mining big data: current status, and forecast to the
future. ACM sIGKDD Explorations Newsletter, New York, NY, USA,
v.14, n.2, p.1–5, Apr. 2013.

[GEO 2011] GEORGE, L. Hbase: the definitive guide: random access to your planet-
size data. [S.l.]: "O’Reilly Media, Inc.", 2011.

[GRA 2014] GRADVOHL, A. L. S. et al. Comparing distributed online stream proces-

sing systems considering fault tolerance issues. Journal of Emerging Te-
chnologies in Web Intelligence, v.6, n.2, p.174–179, 2014.

[HIN 2011] HINDMAN, B. et al. Mesos: A Platform for Fine-Grained Resource Sha-
ring in the Data Center. Proceedings of the 8th USENIX Symposium
on Networked Systems Design and Implementation, NSDI’2011, v.11,
n.2011, p.22–22, 2011.

[HIV 2015] HIVE, A. Apache Hive. Acessado em: 04/02/2017.

[IBM 2010] IBM, C. Mainframes working after hours: Batch processing. Acessado
em: 04/02/2017.

[MAR 2015] MARCOS D, A. et al. Big Data Computing and Clouds: Trends and Fu-
ture Directions. Parallel and Distributed Computing. Science Direct,
v.79–80, p.3–15, May 2015.

[MAT 2015] MATTEUSSI, K.; DE ROSE, C. Uma estratégia de alocaç ao dinâmica e

preditiva de recursos de I/O para reduzir o tempo de execuç ao em aplicaç
oes mapreduce. XV ERAD 2015, 2015.

[MAT 2013] MATTEUSSI, K. J. Protótipo de interface web com php para gerenciamento
de banco de dados couchdb. Trabalho de Conclusão de Curso de Mes-
trado em Ciência da Computação, Unochapecó, 2013.
[MAT 2016] MATTEUSSI, K. Um Estudo Sobre a Contenção de Disco em Ambientes
Virtualizados Utilizando Contêineres e Seu Impacto Sobre Aplicações Ma-
pReduce. Dissertação de Mestrado, Programa de Pós-Graduação em
Ciência da Computação, PUCRS, p.94, 2016.

[MAY 2014] MAYER-SCHONBERGER, V.; CUKIER, K. Big data: como extrair vo-
lume, variedade, velocidade e valor da avalanche de informação cotidiana.
[S.l.]: Elsevier Brasil, 2014. v.1.

[MON 2017] MONGODB. MongoDB. Acessado em: 04/02/2017.

[NEV 21] NEVES, M. V. Application-aware Software-Defined networking to Ac-

celerate Mapreduce Applications. Tese de Doutorado, Programa de Pós-
Graduação em Ciência da Computação, PUCRS. 2015.

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

[POL 2014] POLATO, I. et al. A Comprehensive View of Hadoop Research—A Syste-

matic Literature Review. Journal of Network and Computer Applicati-
ons, v.46, p.1–25, 2014.

[SCH 2015] SCHEMMER, R. B. et al. Framework hadoop em plataformas de cloud e

cluster computing. XV ERAD 2015, p.1–18, 2015.

[SCO 2015] SCOTT, J. A Arquitetura Zeta. Acessado em: 04/02/2017.

[STO 2014] STORM, A. Storm documentation. Acessado em: 04/02/2017.

[VAV 2013] VAVILAPALLI, V. K. et al. Apache hadoop yarn: yet another resource
negotiator. Proceedings of the 4th annual Symposium on Cloud Com-
puting, p.5, 2013.

[WHI 2009] WHITE, T. Hadoop: The Definitive Guide. O’Reilly Media, Inc. 2009.
3rd. pp. 657, p.657, 2009.

[XAV 2015] XAVIER, M. G. et al. A performance isolation analysis of disk-intensive

workloads on container-based clouds. Proceedings of the 23rd Euromicro
International Conference on Parallel, Distributed and Network-Based
Processing, PDP’2015, p.253–260, 2015.

[XAV 2016] XAVIER, M. G. et al. Understanding performance interference in multi-

tenant cloud databases and web applications. Proceedings of the IEEE In-
ternational Conference on Big Data, Big Data’2016, p.2847–2852, 2016.
[ZAH 2013] ZAHARIA, M. et al. Discretized streams: fault-tolerant streaming compu-
tation at scale. Proceedings of the Twenty-Fourth ACM Symposium on
Operating Systems Principles, p.423–438, 2013.

[ZAH 2016] ZAHARIA, M. et al. Apache spark: a unified engine for big data pro-
cessing. Commun. ACM, New York, NY, USA, v.59, n.11, p.56–65,
Oct. 2016.