APOSTILA ARQUITETURA DE COLETA E ARMAZENAMENTO DE DADOS -HADOOP E SPARK

Prévia do material em texto

1 
 
 
ARQUITETURA DE COLETA E ARMAZENAMENTO DE DADOS: 
HADOOP E SPARK 
 
 
 
 
2 
 
 
NOSSA HISTÓRIA 
 
 
A nossa história inicia com a realização do sonho de um grupo de 
empresários, em atender à crescente demanda de alunos para cursos de 
Graduação e Pós-Graduação. Com isso foi criado a nossa instituição, como 
entidade oferecendo serviços educacionais em nível superior. 
A instituição tem por objetivo formar diplomados nas diferentes áreas 
de conhecimento, aptos para a inserção em setores profissionais e para a 
participação no desenvolvimento da sociedade brasileira, e colaborar na 
sua formação contínua. Além de promover a divulgação de conhecimentos 
culturais, científicos e técnicos que constituem patrimônio da humanidade 
e comunicar o saber através do ensino, de publicação ou outras normas de 
comunicação. 
A nossa missão é oferecer qualidade em conhecimento e cultura de 
forma confiável e eficiente para que o aluno tenha oportunidade de cons-
truir uma base profissional e ética. Dessa forma, conquistando o espaço de 
uma das instituições modelo no país na oferta de cursos, primando sempre 
pela inovação tecnológica, excelência no atendimento e valor do serviço 
oferecido. 
 
 
 
 
 
 
 
 
3 
 
 
Sumário 
NOSSA HISTÓRIA ......................................................................................................... 2 
ARQUITETURA DE COLETA E ARMAZENAMENTO DE DADOS: HADOOP E 
SPARK ............................................................................................................................. 5 
INTRODUÇÃO ................................................................................................................ 5 
Definição ........................................................................................................................ 12 
Atributos ......................................................................................................................... 14 
Velocidade ...................................................................................................................... 14 
Variedade ........................................................................................................................ 15 
Volume ........................................................................................................................... 16 
Veracidade ...................................................................................................................... 16 
Técnicas e Tecnologias ................................................................................................... 17 
NoSQL ............................................................................................................................ 17 
MapReduce ..................................................................................................................... 19 
Apache Hadoop .............................................................................................................. 22 
Limitações do Hadoop .................................................................................................... 24 
Apache Spark .................................................................................................................. 24 
Spark RDD ..................................................................................................................... 25 
Modelo de dados ............................................................................................................. 26 
Escalonamento de Jobs ................................................................................................... 28 
Módulos extras ............................................................................................................... 28 
Spark Streaming ............................................................................................................. 30 
Apache Flink .................................................................................................................. 31 
Arquitetura do Flink ....................................................................................................... 32 
Processamento ................................................................................................................ 34 
 
 
 
4 
Processamento Em Lotes ................................................................................................ 36 
Módulos extras ............................................................................................................... 37 
Softwares Auxiliares ...................................................................................................... 37 
Kafka .............................................................................................................................. 38 
Arquitetura ...................................................................................................................... 38 
Características ................................................................................................................. 38 
ZooKeeper ...................................................................................................................... 40 
Arquitetura ...................................................................................................................... 40 
Características ................................................................................................................. 41 
REFERÊNCIAS ............................................................................................................. 42 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
5 
 
ARQUITETURA DE COLETA E ARMAZENAMENTO 
DE DADOS: HADOOP E SPARK 
 
INTRODUÇÃO 
O crescente uso de dispositivos eletrônicos, tais como smartphones, 
tablets, sensores, dentre outros e o uso da internet promovem a geração 
de dados em grande volume, levando ao surgimento do termo conhecido 
como Big Data. 
 Esse cenário atraiu a atenção de várias organizações que buscam 
maneiras eficientes e de baixo custo para analisar, processar e minerar es-
ses dados visando extrair informações estratégicas e valiosas (ASSUN-
ÇÃO et al., 2015). 
Dessa forma, inúmeras aplicações para Big Data surgiram. Essas 
aplicações cobrem os mais variados domínios, tais como: Internet das Coi-
sas, empresarial, governamental, astronômico, meteorológico, da bioinfor-
mática, das ciências, dentre outras. 
Em um cenário com produção de dados em larga escala é muito co-
mum observar a imensa movimentação e o processamento intensivo de 
dados. Quanto à movimentação de dados, o tráfego total na Internet cres-
ceu exponencialmente nas últimas duas décadas. 
Em meados de 1992, as redes globais de Internet costumavam movi-
mentar aproximadamente 100 GB de tráfego por dia. 
Dez anos depois, o tráfego global da Internet era de 100 Gigabytes 
por segundo (GBps). 
 
 
 
6 
Em 2016, a movimentação de dados já era superior a 20.000 Gbps. 
Além disso, esse número deve crescer ainda mais, superando 278 Exa-
bytes por mês até 2021, ante 96 Exabytes por mês em 2016, indicando 
crescimento anual acumulativa (Cumulative Annual-Growth Rate – CAGR) 
de 24%. 
Esse cenário representa um ligeiro aumento das expectativas em re-
lação à previsão do ano de 2015, que projetou um CAGR de 22% de 2015 
a 2020 (CISCO, 2018). 
Por outro lado, o processamento intensivo de dados requerido por 
aplicações Big Data utiliza datacenters compostos por centenas ou milha-
res nós de computação de alta performance. 
Tal tipo de infraestrutura necessita ser aperfeiçoada continuamente 
para alcançar o maior poder de processamento. Mesmo com novas tecno-
logia de design e fabricação, os desafios ligados à eficiência energética 
persistem, tornando-se uma preocupação atual. 
Adicionalmente, pode-se citar a análise proposta por (GÖDDEKE et 
al., 2013;EBRAHIMI; JONES; FLEISCHER, 2014), onde os autores indi-
cam que os atuais sistemas de computação de alto desempenho (High-
Performance Computing – HPC) utilizam cerca de 40% a 60% do total de 
energia gasta para a computação, 10% para os sistemas de rede e de ar-
mazenamento, e o restante é consumido pela própria infraestrutura, tal 
como iluminação e refrigeração. 
Pode-se observar, com base nesse estudo, que o consumo energé-
tico, sem sombra de dúvidas, está se tornando um critério essencial para a 
construção de novos datacenters. 
Pode-se observar que o Green500 (TOP500.ORG, 2018a), ao contrá-
rio do Top500 (TOP500.ORG, 2018b) cria seu ranking levando em conta a 
eficiência energética do supercomputador e não o seu poder computacio-
nal. Então um datacenter bem colocado no Green500 apresenta uma efici-
ência energética alta. 
 
 
 
7 
Ainda, a maioria dos líderes do Green500 usam uma combinação de 
processadores x86 com unidades de processamento gráfico (Graphic Pro-
cessing Unit – GPU) e outras tecnologias de aceleração. 
Os processadores ARM são amplamente utilizados em diversos sis-
temas embarcados, tais como: smartphones, tablets, sensores, dispositivos 
IoT, dentre outros (LOGHIN et al., 2015). 
Além disso, a organização destes modelos de processadores foi de-
senvolvida para possuir eficiência energética. Assim, os processadores 
ARM se candidatam a serem utilizados na construção de novos datacen-
ters focados no baixo consumo energético. 
Ainda, os processadores ARM possuem melhor eficiência energética 
em relação os processadores x86 (PADOIN et al., 2014; PADOIN et al., 
2012; XU; CHANG, 2017). 
Um dos domínios de Big Data que mais cresce é a área de Internet 
Das coisas. 
Estimativas mostram que em 2020 haverá aproximadamente 30 bi-
lhões de dispositivos de Internet das Coisas no mundo (IDC, 2018). As apli-
cações envolvendo tais dispositivos são muito sensíveis à latência (YI; LI; 
LI, 2015). 
A arquitetura de computação em nuvem, muito usada atualmente, 
apresenta justamente o problema da latência (YI; LI; LI, 2015). 
Assim, para resolver o problema de latência foi proposto o usa da ar-
quitetura de computação em névoa (FOG Computing) e de borda (EDGE 
Computing). 
Tais arquiteturas adicionam camadas de processamento entre a apli-
cação (usuário final) e a nuvem para diminuir principalmente a latência (YI; 
LI; LI, 2015). 
 
 
 
8 
Ao utilizar processadores com um menor consumo de energia nessa 
camada, as aplicações alcançam um aumento da eficiência energética. 
 Assim a computação em névoa e de borda, bem como a área de Big 
Data, também podem se beneficiar da principal vantagem dos processado-
res ARM, ou seja, sua eficiência energética. De fato, o uso de processado-
res ARM para o processamento Big Data foi objeto de estudo de vários 
autores. 
Pode-se citar o trabalho de Kalyanasundaram e Simmhan (KALYA-
NASUNDARAM; SIMMHAN, 2017), os autores avaliaram o impacto do uso 
de processador ARM de 64 bits para processamento Big Data em compa-
ração ao uso de processadores X86. 
Os resultados indicam que os processadores ARM 14 de 64 bits são 
mais eficientes energeticamente que os processadores X86. 
O trabalho de Malik (MALIK et al., 2018) apresenta um estudo de 
como os parâmetros de configuração do Hadoop (a nível de sistema e ar-
quitetura) podem refletir em ganhos de desempenho. 
Os resultados obtidos mostraram que o aumento do número de nú-
cleos ativos para tarefas de map ajuda a maximizar a eficiência energética 
e reduzir a utilização da CPU. 
As aplicações Big Data podem ser construídas utilizando dois mode-
los de processamento. 
O primeiro modelo é chamado de processamento em lotes e tem 
como finalidade o processamento de dados com limites definidos e o se-
gundo é chamado de processamento em tempo real que tem por finalidade 
o processamento de dados sem limite definidos. 
As aplicações do modelo de processamento em lotes podem ser exe-
cutados sobre frameworks Apache Hadoop, Spark, Flink e outros, e as apli-
cações de processamento em tempo real podem ser executadas sobre os 
frameworks Apache Spark, Flink, Storm e outros. 
 
 
 
9 
No estado da arte, muitos autores abordam o processamento Big Data 
sobre processadores ARM. 
Entretanto, a grande maioria leva em conta o processamento em lotes 
utilizando o framework Hadoop. 
Além disso, poucos trabalhos comparam o desempenho entre os pro-
cessadores ARM e X86 ou entre diferentes processadores ARM (LOGHIN 
et al., 2015; MALIK; HOMAYOUN, 2015; MALIK et al., 2015; 
NESHATPOUR et al., 2015). 
Não há uma comparação entre diferentes processadores ARM de di-
ferentes arquiteturas, logo, não há uma avaliação de como diferentes ar-
quiteturas influenciam na execução de aplicações Big Data. 
Desse modo, percebe-se a necessidade de avaliar o desempenho dos 
frameworks (e aplicações Big Data) sob ambos os modelos de processa-
mento. Além disso, torna-se importante avaliar o impacto de diferentes ar-
quiteturas ARM sobre os frameworks e aplicações Big Data. 
Esta mudança provocou uma ampla transformação na maneira com 
que indivíduos de uma sociedade se relacionam, passando a ser mais atu-
antes no que tange a questões de interesse comum, tais como segurança, 
educação, saúde, economia, entre outros. 
Devido a este fenômeno social, foi possível que cada indivíduo exerça 
o seu papel de cidadão de modo mais participativo nos acontecimentos 
políticos e sociais de sua região. Para que o exercício de cidadania seja 
aplicado, é necessário que o indivíduo tenha ao seu alcance direitos indivi-
duais, políticos e sociais. 
Dentre os direitos políticos de cada cidadão, estão o direito ao voto, à 
justiça, à liberdade de expressão pública de pensamento e, principalmente, 
à liberdade de informação e ao acesso às informações (SOLIS, 1994 apud 
HEERDT, 2000). 
 
 
 
10 
Segundo Araújo (1999), a construção da cidadania passa necessari-
amente pelo acesso, uso, disseminação e discussão de informações sobre 
direitos e deveres referentes à construção de uma sociedade mais igualitá-
ria. Portanto, a falta de acesso à tais informações inibe a realização de ati-
vidades cívicas. 
A Lei no 12.527 de 18 de novembro de 20111 garante à cada cidadão 
brasileiro o acesso às informações públicas dos poderes Executivo, Legis-
lativo e Judiciário, criando regras de como estas informações são publica-
das e consumidas. 
Esta regulamentação estimula o exercício da cidadania e fortalece a 
relação entre Estado e cidadão, significando um importante passo para a 
consolidação da Democracia brasileira. 
Uma maior participação pública nas questões governamentais per-
mite uma maior fiscalização contra irregularidades, além de possibilitar 
avanços na gestão pública do país. 
O crescimento no uso de novas tecnologias como Cloud Computing, 
Internet e dispositivos móveis fez criar a necessidade de gerenciar a anali-
sar uma vasta quantidade de informações que ultrapassa a nossa capaci-
dade convencional de processamento (DUMBILL, 2013). 
Segundo Villars, Olofson e Eastwood (2011), em 2010, o mundo criou 
1 zetabyte (1021 bytes) de dados, enquanto a previsão para 2014 será de 
7 zetabytes de dados. 
De acordo com pesquisas de Manyika et al. (2011), em 2010, mais de 
4 bilhões de pessoas, ou 60% da população mundial, estão utilizando tele-
fones celulares, sendo destes 12% smartphones e com um crescimento 
anual de 20%. 
Existem também mais de 30 milhões de sensores nos setores de 
transporte, automotivo, indústria, utilidades e de vendas. 
 
 
 
11 
A taxa de crescimento destes sensores é de 30%. Toda esta informa-
ção produzida cria novas oportunidades para a extração de valor sobre a 
informação, como aponta Taurion (2013): 
Geramos um imenso volume de dados a cada dia e análises de pa-
drões e correlações nesta massa de dados podem produzir informações 
valiosíssimas emtodos os setores da sociedade humana, de governos bus-
cando entender demandas da população a empresas buscando se posici-
onar mais competitivamente no mercado. 
McAfee e Brynjolfsson (2012) citam um exemplo de como a captura e 
processamento de uma grande massa de dados pode dar vantagem com-
petitiva para uma empresa. 
O tempo estimado de chegada (ETA - Estimated Time to Arrive), rea-
lizada pelos pilotos minutos antes do pouso, é uma informação importante 
para os passageiros e para os funcionários de uma companhia aérea. 
No caso de um avião pousar antes do que o tempo esperado, a tripu-
lação e passageiros devem aguardar os funcionários do aeroporto se pre-
param para realizar o desembarque. 
Caso o pouso ocorra depois do tempo esperado, os funcionários fica-
rão ociosos aguardando a chegada da aeronave. 
Situações extremas como essas causam grandes custos para a com-
panhia. Para a solução deste problema, uma empresa americana chamada 
PASSUR1 criou, então, uma tecnologia para a indústria aviária chamada 
RightETA2, capaz de determinar com alta precisão o tempo estimado para 
chegada de cada voo baseando-se em diversas fontes de dados, tais como 
clima, programação dos voos, localização de outros aviões detectados pelo 
radar do aeroporto, entre outros. 
São coletadas diversas informações sobre todos os aviões próximos 
a cada 4,6 segundos. Como resultado, milhares de dólares ao ano foram 
poupados em cada aeroporto em que a tecnologia foi implantada. 
 
 
 
12 
Organizações que conseguem se beneficiar de decisões em tempo 
real e de informações atuais e precisas terão vantagem competitiva sobre 
aquelas organizações incapazes de adotar e fazer uso desta tendência 
(VILLARS; OLOFSON; EASTWOOD, 2011). 
Através na análise de imensos volumes de dados que estão disponí-
veis, existe um grande potencial em realizar importantes avanços nos ne-
gócios de empresas e na obtenção de conhecimento em diversas áreas 
científicas (AGRAWAL et al., 2011). 
 
Definição 
Não existe um consenso sobre o conceito de Big Data totalmente 
aceito e aplicado no mercado. 
Diversos autores o definem sobre perspectivas distintas, porém, apre-
sentam convergências em certos aspectos que permitem um melhor enten-
dimento de sua definição. 
O encontro de uma definição para o termo é importante para o anda-
mento desta pesquisa. 
Segundo Manyika et al. (2011, tradução nossa), Big Data "refere-se a 
conjuntos de dados cujo tamanho é além da capacidade de ferramentas de 
software de banco de dados típicos para capturar, armazenar, gerenciar e 
analisar". 
Gartner (2012, tradução nossa), define Big Data como "ativos de alto 
volume, velocidade e variedade de informação que demandam custo-be-
nefício, formas inovadoras de processamento de informação para maior vi-
sibilidade e suporte à tomada de decisão". 
 
 
 
13 
Já a IDC define Big Data como sendo "uma nova geração de tecnolo-
gias e arquiteturas, projetadas para extrair economicamente o valor de vo-
lumes muito grandes e de uma grande variedade de dados, permitindo uma 
alta velocidade de captura, descoberta, e ou análise". 
Percebe-se, com as definições citadas anteriormente, semelhanças 
entre os termos utilizados, como, por exemplo, o grande volume de dados, 
a alta velocidade de processamento e a diversa variedade de fontes de 
dados. 
Taurion (2013) resume atributos semelhantes entre diversos concei-
tos existentes sobre Big Data em uma fórmula que permite compreendê-la 
de maneira mais ampla: 
BigData = V olume + V ariedade + V elocidade + V eracidade + V alor 
1 http://www.passur.com 
2 http://www.passur.com/righteta-product-detail.htm 
O mesmo autor ainda abrange o termo para além da área técnica: Big 
Data não é apenas um produto de software ou hardware, mas um conjunto 
de tecnologias, processos e práticas que permitem às empresas analisa-
rem dados a que antes não tinham acesso e tomar decisões ou mesmo 
gerenciar atividades de forma muita mais eficiente (TAURION, 2013). 
Com base nas definições apresentadas, pode-se concluir, portanto, 
que o conceito Big Data pode ser direcionado para um conjunto de práticas 
e tecnologias que visam processar, armazenar, analisar e informar uma 
grande variedade e volume de dados a uma grande velocidade, permitindo 
que empresas possam utilizá-las de forma eficiente no seu processo de 
tomada de decisão. 
 
http://www.passur.com/
 
 
 
14 
Atributos 
O termo Big Data é constituído por diversos atributos que o diferencia 
de outros conceitos já existentes no mercado, como Business Intelligence 
(BI). 
Segue a contextualização de cada atributo identificado pelo autor Tau-
rion (2013). 
 
 
Velocidade 
O atributo Velocidade está relacionado à rapidez em que as informa-
ções são consumidas e analisadas (RIFFAT, 2014). 
O mesmo é um fator determinante para a tomada de decisão de em-
presas, pois "dados não tratados e analisados em tempo hábil são dados 
inúteis, pois não geram informação" (TAURION, 2013). 
Velocidade é um critério que vai se tornar cada vez mais importante, 
devido à crescente rapidez com que as empresas precisam reagir às mu-
danças no cenário de negócios, bem como é necessária para tratar os da-
dos em tempo real, interferindo na execução do próprio processo de negó-
cios (TAURION, 2013). 
Em situações em que as respostas rápidas às mudanças ou tendên-
cias for um fator importante para o negócio, a velocidade torna-se um atri-
buto mais importante do que os demais (MCAFEE; BRYNJOLFSSON, 
2012). 
 
 
 
 
15 
Variedade 
O crescimento no uso das redes sociais e de smartphones, aliados à 
evolução das tecnologias de armazenamento de dados e diminuição no 
custo de hardware, causaram uma grande expansão na criação e prolife-
ração de dados. Tal situação viabiliza economicamente a elaboração de 
tecnologias capazes de armazenar e processas diversas fontes diferentes 
de dados (MCAFEE; BRYNJOLFSSON, 2012). 
Taurion (2013) cita a importância de ligar diversas fontes de dados 
com o objetivo de obter informações: 
A variedade é um parâmetro importante, pois, com diversas fontes de 
dados aparentemente sem relações, podemos derivar informações extre-
mamente importantes e fazer análises preditivas mais eficientes. 
Por exemplo, conectando dados meteorológicos com padrões de 
compra dos clientes podemos planejar quais tipos de produtos deverão es-
tar em destaque nas lojas quando for detectado que haverá um período de 
alguns dias de temperatura elevada, aqui a três dias. 
Ou conectar dados geográficos com detecção de fraudes. Entretanto, 
existem desafios para serem enfrentados quando ocorre a busca por infor-
mações em diferentes tipos de dados. 
Os tipos de dados podem ser classificados em estruturados, não-es-
truturados e semiestruturados, esclarecidos a seguir: 
Os dados estruturados estão presentes em sistemas tradicionais cor-
porativos (bancos de dados, arquivos sequenciais e hierárquicos etc). 
Os semiestruturados estão disponíveis por meio de logs de sistemas 
(web servers, CDRs etc.) e os não estruturados são os conteúdos digitali-
zados que, anteriormente, eram acessados em forma não digital, como ar-
quivos de imagens, áudios, textos, entre outros (CIO, 2012). 
 
 
 
16 
Segundo o IDC (2011), 90% dos dados do universo digital são com-
postos por dados não-estruturados. Dessa forma, é importante atentar para 
este tipo de dado que é representado em sua ampla maioria armazenadas 
atualmente. 
 
Volume 
Trata-se da quantidade de dados que é consumida e processada (RI-
FFAT, 2014). Este atributo é o comumente mais conhecido, visto que o "Big 
Data vem chamando atenção pela acelerada escala em que volumes cada 
vez maiores de dados são criados pela sociedade" (TAURION, 2013). 
Valor "Big Data só faz sentido se o valor da análise dos dados com-
pensar o custo de sua coleta, armazenamento e processamento" (TAU-RION, 2013). 
Assim sendo, espera-se que a implantação de uma solução Big Data 
gere retorno sobre o investimento (ROI) para quem o investiu. 
 
Veracidade 
Não basta ter posse de uma informação: é necessário que a mesma 
seja autêntica e tenha algum sentido para que o utiliza (TAURION, 2013). 
A veracidade torna-se, portanto, um atributo importante para ser utili-
zada em um mercado de alta competitividade e dinamismo. 
 
 
 
 
 
 
17 
Técnicas e Tecnologias 
O crescimento de dados gerados todos os dias não é o único fator 
que possibilitou a existência do Big Data. 
Os avanços nas tecnologias de armazenamento e mineração de da-
dos também são responsáveis pelo crescimento da quantidade de informa-
ções consumidas e analisadas (MICHAEL.; MILLER, 2013). 
 
NoSQL 
O Sistema Gerenciador de Banco de Dados Relacional (SGBDR) é, 
atualmente, a tecnologia predominante para o armazenamento de dados 
estruturados para aplicações corporativos ou web. 
Diversas outras alternativas apareceram em alguns anos, como os 
bancos de dados orientados a objeto ou armazenamento em arquivos XML, 
porém nenhum deles conseguiu obter a mesma adoção do que os SGB-
DRs. 
O movimento NoSQL (Not only SQL) começou em 1998 como uma 
alternativa mais barata e eficiente para o gerenciamento de grandes mas-
sas de dados. Sua proposta vem ao encontro com a necessidade de alta 
escalabilidade, processamento eficiente de grande volume de dados e, 
principalmente, na fácil distribuição de processamento entre outros servi-
dores (STRAUCH, 2011). 
Estas características fazem dos bancos de dados NoSQLs soluções 
ideais para a construção de tecnologias Big Data. 
Segundo Hecht e Jablonski (2011), os SGBDRs tornam-se complexos 
e pouco performáticos quando o modelo de dados não corresponde com o 
modelo relacional. Isto acarreta no uso de frameworks pouco performáticos 
e algoritmos complexos que tornam o modelo relacional difícil de manter e 
evoluir. 
 
 
 
18 
Caso seja realizada uma operação de alteração, todo o SGBDR pode 
ficar inoperante. 
Já para aplicações que utilizam uma grande massa de dados, opera-
ções de join e lock influenciam diretamente na sua performance e disponi-
bilidade, podendo ficar ainda mais crítico quando presente dentro de um 
sistema de armazenamento distribuído. 
Pode-se classificar, segundo Hecht e Jablonski (2011), os bancos de 
dados NoSQL em 5 diferentes categorias de acordo com o método utilizado 
para o gerenciamento de dados. 
São elas: 
a) Chave/Valor: Os dados são armazenados em estruturas onde um 
determinado valor pode ser somente recuperado através de sua chave. 
Sua simplicidade permite registrar novos valores sem conflitar com os da-
dos já armazenados e sem afetar a disponibilidade do sistema. 
São exemplos de bancos de dados para esta categoria: Redis, Volde-
mort, Membase. 
b) Documento: Semelhante à categoria anterior, porém possibilitam 
gerenciar estrutura de dados mais complexos. Para cada chave, utiliza-se 
a estrutura JSON como valor, permitindo armazenar mais de um atributo 
para cada chave, para esta estrutura, dá-se o nome de Documento. 
Documentos podem ser agrupados entre si e formar uma Coleção. 
Esta estruturação dos dados permite armazenar informações mais comple-
xas e uma fácil migração e replicação de dados. 
São exemplos de banco de dados para esta categoria: CouchDB, 
MongoDB, Riak. 
c) Tabular: Neste modelo de gerenciamento, são armazenados pares 
de campos chave/valor dentro de linhas (registros). 
 
 
 
19 
Apesar de semelhança com o modelo relacional, os bancos de dados 
tabulares somente armazenam os valores solicitados, ao invés de armaze-
nar valores nulos em cada coluna onde não houver um valor para ela. 
Esta flexibilidade permite que banco de dados tabulares sejam efici-
entes em armazenamento de grande quantidade de dados. 
São exemplos de banco de dados para esta categoria: Apache Cas-
sandra, HBase, Hypertable. 
 
d) Grafos: Especialistas em associação de um ou mais dados entre 
si, os bancos de dados baseados em grafos são indicados para sistemas 
que necessitam de relacionamento seus dados para prover informações 
para o usuário final, como redes sociais, sistemas de recomendação e ser-
viços orientados a localização. 
São exemplos de banco de dados para esta categoria: Sesame, Big-
Data, Neo4j, GraphDB, FlockDB. 
Com a grande quantidade de banco de dados NoSQL existentes no 
mercado, onde cada uma possui uma especialidade específica, cabem aos 
profissionais de análise de dados a escolher a melhor ferramenta para aten-
der às suas necessidades. 
 
MapReduce 
Grandes volumes de dados exigem técnicas de processamento de 
alto desempenho e facilidade de uso em ambientes distribuídos. 
O MapReduce surgiu como uma solução popular para aproveitar o 
aumento do poder de processamento de sistemas interligados (CONDIE et 
al., 2010). 
 
 
 
20 
Segundo (DEAN; GHEMAWAT, 2004, tradução nossa), MapReduce 
é "um modelo de programação e uma implementação associada para o 
processamento e a geração de grandes conjuntos de dados". 
O MapReduce permite que programadores sem experiência em im-
plementação de sistemas distribuídos criem sistemas capazes de proces-
sar grandes quantidades de dados, e deixando que detalhes como partici-
onamento, escalonamento, tolerâncias a falhas e comunicação entre diver-
sos servidores à cargo do serviço MapReduce. 
Esta condição possibilita que o foco da implementação esteja apenas 
no tratamento dos dados (DEAN; GHEMAWAT, 2010). 
Segundo Condie et al. (2010), para utilizar o MapReduce, o progra-
mador deve implementar algumas funções pré-determinadas. 
A entrada e saída de cada função será um conjunto de pares 
chave/valor. A primeira função a ser executa é a map, que é executada a 
cada entrada de par chave/valor, produzindo uma lista de pares intermedi-
ários. 
Em seguida, a função reduce é invocada uma única vez para cada 
chave distinta da lista criada anteriormente e retornar o resultado do pro-
cessamento para o usuário. 
 
A figura 1 ilustra o fluxo de processamento de uma operação MapRe-
duce. 
 
 
 
21 
 
 
A solução MapReduce mais conhecido no mercado atualmente é o 
Apache Hadoop. 
Trata-se de uma implementação de código fonte aberto do MapRa-
duce originalmente criada pela Google e atualmente mantida pela Funda-
ção Apache. 
Ele é constituído por uma implementação MapReduce e por um sis-
tema de arquivos chamado Hadoop Distributed File System (HDFS). 
Este sistema de arquivos é otimizado para receber grandes cargas de 
dados e possibilitar a execução das operações MapReduce em sistemas 
distribuídos. 
O mesmo armazena apenas os dados de entrada da função map e a 
saída da função reduce, deixando os dados intermediários em cada nodo 
do sistema (CONDIE et al., 2010). 
 
 
 
 
22 
Apache Hadoop 
O Hadoop foi inicialmente introduzido em 2007 como uma implemen-
tação de código aberto para o processamento MapReduce ligado a um sis-
tema de arquivos distribuídos (WHITE, 2012), mas desde então evoluiu 
para uma vasta rede de projetos relacionados a cada etapa de um grande 
fluxo de dados, incluindo a coleta de dados, armazenamento, processa-
mento e etc. 
Atualmente, o Hadoop consiste em quatro módulos principais 
(FOUNDATION, 2018c): 
• MapReduce Data processing engine. Um trabalho MapReduce con-
siste em duas partes, uma fase de map, que processa os dados de entrada 
e organiza-os em pares de chave/valor e uma fase de reduce que processa 
os dados em paralelo (LANDSET et al., 2015); 
• Hadoop distributed file system (HDFS): um sistema de arquivos pro-
jetado para armazenar grandes quantidades de dados através de vários 
nós. 
O HDFS possui uma arquitetura mestre-escravo composta de nós de 
dados escravos (data nodes) em que cada nó armazena blocos de dados, 
recuperando os dados sob demanda e reportando aonó mestre (name 
node). 
O nó mestre mantém os registros dos dados (referências a locais de 
arquivos e metadados) e direciona o tráfego para os nós de dados após 
solicitações de clientes. 
Este sistema possui tolerância a falhas, normalmente mantendo três 
ou mais cópias de cada bloco de dados em caso de falha no disco. Além 
disso, também há controles no caso de falha de nó mestre, no qual um 
sistema terá um nó mestre secundário ou que mantém os backups dos me-
tadados (LANDSET et al., 2015); 
 
 
 
23 
• YARN (“Yet Another Resource Negotiator”) (VAVILAPALLI et al., 
2013) 
Com o YARN, se um aplicativo deseja executar, seu cliente deve so-
licitar o lançamento de um processo de gerenciamento de aplicativo a partir 
do gerenciador de recursos, que então encontra um gerenciador de nó em 
um dos nós do cluster. 
O gerenciador de nó lança um contêiner que executa a aplicação. As 
responsabilidades de gerenciamento do YARN são divididas entre o geren-
ciador de recursos, o processo de gerenciamento de aplicativo (Applica-
tionMaster) e o servidor de logs (que armazena o histórico dos aplicativos), 
enquanto as responsabilidades de gerenciar os recursos do nó são tratados 
pelo gerenciador de nó. 
O YARN é capaz de funcionar em clusters maiores, mais do que du-
plicar a quantidade de trabalhos e tarefas que ele pode manipular antes de 
chegar a um gargalo (WHITE, 2012). 
No YARN, os slots podem ser reutilizados, pois há uma utilização de 
recursos muito melhor (KULKARNI; KHANDEWAL, 2014); 
 
• Hadoop Common (FOUNDATION, 2018a) 
Um conjunto de utilitários comuns necessários aos outros módulos 
Hadoop. 
Além disso, possui bibliotecas compartilhadas nativas que incluem im-
plementações Java para codecs de compressão, utilitários de E/S e detec-
ção de erros. 
Também estão incluídas interfaces e ferramentas para configuração 
de reconhecimento de rack, autorização de usuários proxy, autenticação, 
autorização de nível de serviço, confidencialidade de dados e o servidor de 
gerenciamento de chaves Hadoop (KMS) (LANDSET et al., 2015). 
 
 
 
24 
Por fim, o ecossistema Hadoop é composto por uma vasta gama de 
projetos construídos utilizando os módulos principais descritos acima. 
Esses projetos foram projetados para auxiliar pesquisadores e profis-
sionais em todos os aspectos de um fluxo de trabalho típico de análise de 
dados ou aprendizagem de máquinas (LANDSET et al., 2015). 
 
Limitações do Hadoop 
Uma das principais desvantagens do MapReduce é a sua ineficiência 
na execução de algoritmos iterativos. 
O MapReduce não foi projetado para processos iterativos. Os mape-
adores leem os mesmos dados repetidamente do disco. 
Assim, após cada iteração, os resultados devem ser gravados no 
disco para passá-los para a próxima iteração. 
Para cada iteração, um novo mapeador e redutor devem ser iniciali-
zados. Às vezes, os trabalhos MapReduce são de curta duração, caso em 
que a sobrecarga da inicialização dessa tarefa se torna uma sobrecarga 
significativa para a própria tarefa. 
Algumas soluções alternativas, como o agendamento direto (configu-
ração do próximo trabalho MapReduce antes do final anterior) foram pro-
postas. 
No entanto, essas abordagens introduzem níveis adicionais de com-
plexidade no código-fonte (SINGH; REDDY, 2015). 
 
Apache Spark 
Spark é um paradigma para o processamento de Big Data desenvol-
vido por pesquisadores da Universidade da Califórnia em Berkeley (SINGH; 
REDDY, 2015). 
 
 
 
25 
A principal característica do Spark que o torna diferente do Hadoop é 
a capacidade de executar computações em memória (JUNIOR et al., 2018). 
O que permite os dados serem armazenados em cache na memória, 
eliminando assim a limitação de sobrecarga de disco para tarefas iterativas. 
O Spark é um mecanismo geral para o processamento de dados em 
larga escala que suporta as linguagens Java, Scala e Python. Uma das 
principais abstrações para se obter um processamento no Spark é o uso 
do RDD. 
 
Spark RDD 
O Spark (ZAHARIA et al., 2012; ZAHARIA et al., 2010) apresenta uma 
abstração de dados para análise de Big Data, denominada conjunto de da-
dos distribuídos resilientes (Resilient Distributed Dataset – RDD), que é 
uma estrutura de dados imutável determinística com tolerância a falhas 
(CHENEY et al., 2009; BOSE; FREW, 2005). 
Suas duas principais características são: 
• Usar um modelo de persistência elástica para fornecer a flexibilidade 
para persistir o conjunto de dados na memória, nos discos ou em ambos. 
Ao persistir o conjunto de dados na memória, favorece aplicações que 
precisam ler o conjunto de dados várias vezes (por exemplo, algoritmos 
iterativos) e permite consultas interativas (ZHANG et al., 2015); 
• Incorporar um mecanismo leve de tolerância a falhas (ou seja, uma 
linhagem), sem a necessidade de checkpoints. 
A linhagem de um RDD contém informações suficientes para que ele 
possa ser reavaliado com base em sua linhagem e RDDs dependentes, 
que são os arquivos de dados de entrada no HDFS no pior dos casos 
(ZHANG et al., 2015). 
 
 
 
26 
A capacidade de persistência de dados na memória torna o RDD ade-
quado para muitas aplicações de análise de dados, especialmente algorit-
mos iterativos, uma vez que remove o alto custo de acesso aos dados em 
discos em todas as etapas, como ocorre com Hadoop (ZHANG et al., 2015). 
 
Modelo de dados 
Os RDDs podem ser entendidos como uma memória compartilhada 
distribuída somente de leitura (NI, 2013). 
A API RDD foi ampliada em 2015 para incluir DataFrames, que per-
mitem aos usuários agrupar uma coleção distribuída de dados por coluna, 
semelhante a uma tabela em uma base de dados relacional. 
Por exemplo, um RDD de pares de chave/valor pode ser convertido 
em um DataFrame que é representado como uma tabela com uma coluna 
para cada par chave/valor. 
Os DataFrame podem ser criados a partir de um RDD existente, ta-
bela Hive, HDFS ou uma série de outras fontes de dados (LANDSET et al., 
2015). 
A modificação de dados é conseguida através de transformações 
RDD de grão grosso que aplicam a mesma operação a todos os itens de 
dados no RDD, gerando assim um novo RDD. 
Esta abstração oferece oportunidades de alta consistência e um es-
quema leve de tolerância a falhas. 
Especificamente, um RDD registra as transformações que foram fei-
tas nele (ou seja, sua linhagem), sem replicação de dados ou verificação 
de falhas para tolerância a falhas. 
Quando uma partição do RDD é perdida, ela é recomputada de outros 
RDDs com base em sua linhagem. 
 
 
 
27 
Como RDD é atualizado por transformações de grão grosso, geral-
mente requer muito menos espaço e esforço para fazer backup das infor-
mações da linhagem do que os esquemas tradicionais de replicação ou 
verificação de dados, ao preço de um custo de recomputação mais alto 
para trabalhos intensivos em computação, quando há uma falha. 
Assim, para RDDs com grafos de linhagem longa envolvendo um 
grande custo de recomputação, um checkpointing é usado, o que é mais 
benéfico (ZHANG et al., 2015). 
O modelo RDD fornece uma boa estratégia de cache para “conjuntos 
de trabalho” durante a computação, mas não é suficientemente geral para 
suportar a funcionalidade tradicional de armazenamento de dados por dois 
motivos: 
• O esquema de tolerância a falhas RDD baseia-se na suposição de 
manipulação de dados de grão grosso sem modificação no local, porque 
deve garantir que o tamanho do programa seja muito inferior ao tamanho 
dos dados. 
Assim, operações de dados de grão fino, como a atualização de um 
único objeto de chave/valor, não podem ser suportadas neste modelo 
(ZHANG et al., 2015); 
• Assume que existe um conjunto de dados original persistente em um 
armazenamento estável, o que garante a correção do modelo de tolerância 
a falhas e a adequação do modelo de organização baseado em blocos. 
Noentanto, no armazenamento tradicional de dados, os dados estão 
chegando dinamicamente e a alocação de dados não pode ser determi-
nada a priori. 
Como consequência, os objetos de dados são dispersos na memória, 
o que resulta em uma velocidade de transferência de memória degradada 
(ZHANG et al., 2015). 
 
 
 
 
28 
Escalonamento de Jobs 
Os jobs em Spark são organizados em um DAG, que captura depen-
dências de trabalho. 
O RDD usa materialização preguiçosa, ou seja, um RDD não é com-
putado a menos que seja usado em uma ação (por exemplo, count()). 
Quando uma ação é executada em um RDD, o escalonador examina 
a linhagem do RDD para criar um DAG de tarefas para execução. 
Spark usa uma programação de trabalho em duas fases (ZAHARIA et 
al., 2012): 
• Primeiro organiza os trabalhos em um DAG de estágios, cada um 
dos quais pode conter uma sequência de trabalhos com apenas uma de-
pendência de um-para-um no nível de partição. Os limites das etapas são 
as operações com shuffle, que têm dependências de muitos para muitos 
(ZAHARIA et al., 2012); 
• Em cada etapa, um trabalho é formado por uma sequência de traba-
lhos em uma partição, como o map e os trabalhos de filtragem. 
Tarefa é a unidade de agendamento no sistema, que elimina a mate-
rialização dos estados intermediários e permite uma estratégia de agenda-
mento fino (ZAHARIA et al., 2012). 
 
Módulos extras 
Além do núcleo do Spark, alguns projetos adicionais foram desenvol-
vidos para complementar a funcionalidade fornecida pelo núcleo. 
Todos esses subprojetos (construídos no topo do núcleo) são descri-
tos a seguir: 
• Spark SQL: apresenta DataFrames, que é uma nova estrutura de 
dados para dados estruturados e semi-estruturados. 
 
 
 
29 
O DataFrame oferece a possibilidade de introduzir consultas SQL nos 
programas Spark e fornece suporte à linguagem SQL, com interfaces de 
linha de comando e controladores ODBC/JDBC (GARCÍA-GIL et al., 29 
2017); 
• Spark Streaming: nos permite usar a API do Spark em ambientes 
em tempo real usando micro-lotes de dados que são processados rapida-
mente. Este design permite que o mesmo conjunto de código para proces-
samento em lotes (formado por transformações RDD) seja usado em aná-
lises em tempo real com pouca mudança. 
Spark Streaming pode funcionar com várias fontes de dados, como 
HDFS, Flume ou Kafka (GARCÍA-GIL et al., 2017); 
• Machine Learning library (MLlib) (MENG et al., 2016): é formado por 
algoritmos de aprendizagem de máquina e utilitários estatísticos comuns. 
Entre as suas principais funcionalidades, incluem: classificação, re-
gressão, agrupamento, filtragem colaborativa, otimização e redução de di-
mensionalidade. Esta biblioteca foi especialmente projetada para simplifi-
car pipelines ML em ambientes de grande escala. 
Nas versões mais recentes do Spark, a biblioteca MLlib foi dividida 
em dois pacotes, MLlib, compilação sobre os RDDs e ML, compilação so-
bre os DataFrames para a construção de pipelines; 
 
• Spark GraphX: é o sistema de processamento de grafos em Spark. 
Graças a este motor, os usuários podem visualizar, transformar e jun-
tar de forma intercambiável tanto em grafos como coleções. Ele também 
permite expressar a computação de grafos usando a abstração de Pregel 
(MALEWICZ et al., 2010). 
 
 
 
 
30 
Spark Streaming 
O Spark Streaming usa micro-lotes que é uma técnica semelhante a 
uma simulação de processamento em tempo real. Nesta abordagem, um 
fluxo de entrada é empacotado em sequências de pequenos pedaços de 
dados, que podem então ser processados por um sistema em lotes 
(SHAHRIVARI, 2014). 
Embora isso possa ser adequado para muitos projetos, não é um ver-
dadeiro sistema em tempo real. 
É observado em (ZAHARIA et al., 2012) que esta abordagem facilita 
o balanceamento de carga e é mais robusta para tolerar falhas nos nós. 
Além disso, os autores mencionam que, embora este modelo seja mais 
lento do que o processamento em tempo real verdadeiro, a latência pode 
ser minimizada o suficiente para a maioria dos projetos do mundo real 
(LANDSET et al., 2015). 
O Spark Streaming utiliza totalmente a imutabilidade do mecanismo 
de tolerância a falhas do RDD baseadas em linhagens do Spark, com algu-
mas extensões e otimizações. 
Especificamente, o fluxo de entrada é dividido em uma sequência de 
RDDs imutáveis com base em intervalos de tempo, chamados D-streams, 
que são as unidades básicas que podem ser atuadas por transformações 
determinísticas, incluindo não apenas transformações disponíveis em 
Spark RDDs normais (por exemplo, map, reduce e groupBy), mas também 
cálculos com janelas exclusivas para Spark Streaming (por exemplo, re-
ductionByWindow e countByWindow). 
Os RDDs de intervalos históricos podem ser mesclados automatica-
mente com o RDD recém-gerado à medida que novos fluxos chegam. 
Os dados em tempo real são replicados em dois nós de trabalho para 
garantir a durabilidade dos dados originais em que a recuperação baseada 
em linhagem depende e o checkpointing é feito periodicamente para reduzir 
o tempo de recuperação devido a grafos de linhagem longa. 
 
 
 
31 
O determinismo e a linhagem de níveis de partição de D-streams pos-
sibilitam a recuperação paralela após um nó falhar e mitigar o problema dos 
retardatários por meio de execução especulativa (ZHANG et al., 2015). 
O Spark tem semântica de entrega em tempo real exatamente uma 
vez. A ideia é processar uma tarefa em vários nós de trabalho. Durante 
uma falha, o processamento dos micro-lotes pode simplesmente ser recal-
culado e redistribuído. 
O estado dos RDDs é periodicamente replicado para outros nós de 
trabalho, para mitigar uma possível falha do nó. 
As tarefas são então discretizadas em tarefas menores executadas 
em qualquer nó, sem afetar a execução. Assim, as tarefas com falha podem 
ser lançadas em paralelo distribuindo uniformemente a tarefa sem afetar o 
desempenho. Este procedimento é chamado de recuperação paralela. No 
entanto, o processamento de micro-lotes tem desvantagens. 
O processamento de micro-lotes leva mais tempo nas operações pos-
teriores. A configuração de cada micro-lote pode demorar mais do que a 
análise em tempo real (LOPEZ; LOBATO; DUARTE, 2016). 
 
Apache Flink 
Flink (FOUNDATION, 2018b) foi desenvolvido na Universidade Téc-
nica de Berlim sob o nome Stratosphere (ALEXANDROV et al., 2014). Ofe-
rece capacidade para o processamento em tempo real e em lotes, permi-
tindo a implementação de uma arquitetura Lambda. 
É um framework escalável que possui APIs para Java e Scala. Tem 
seu próprio runtime, em vez de ser construído no topo do MapReduce. 
Como tal, ele pode ser integrado com HDFS e YARN, ou executar comple-
tamente independente do ecossistema Hadoop. 
 
 
 
32 
O modelo de processamento do Flink aplica transformações a cole-
ções de dados paralelas (EWEN et al., 2013; LEICH et al., 2013). 
Essas transformações generalizam as funções de map e reduce, bem 
como funções como join, group e iterate. 
Também inclui um otimizador baseado em custos que seleciona au-
tomaticamente a melhor estratégia de execução para cada trabalho. 
O Flink também é totalmente compatível com o MapReduce, o que 
significa que ele pode executar o código legado sem modificações 
(FOUNDATION, 2018b). 
Como Spark, o Flink também oferece processamento em lotes itera-
tivo, bem como opções de processamento em tempo real, embora sua API 
de tempo real seja baseada em eventos individuais, ao invés da abordagem 
de micro-lotes que o Spark usa (LANDSET et al., 2015). 
 
Arquitetura do Flink 
Um cluster Flink compreende três tipos de processos: o cliente, o Ge-
renciador de Trabalhos (JobManager) e, pelo menos, um Gerenciador de 
Tarefas (TaskManager). O processo cliente que é um interpretador do có-
digo do programa, que transforma este código em um grafo com o fluxo de 
execução e o enviao Job Manager. 
Esta fase de transformação também examina os tipos de dados (es-
quema dos dados trocados entre operadores) e cria serializadores ou ou-
tros tipos/esquemas de código específico. 
Os programas DataSet também passam por uma fase de otimização 
de consulta baseada em custos, semelhante às otimizações físicas realiza-
das por otimizadores de consultas relacionais (CARBONE et al., 2015). 
O JobManager coordena a execução distribuída do fluxo de dados. 
Ele rastreia o estado e o progresso de cada operador; transmite e agenda 
 
 
 
33 
novos operadores e coordena os pontos de verificação e a recuperação. O 
processamento real de dados ocorre em TaskManagers. 
Um TaskManager executa um ou mais operadores que produzem flu-
xos de dados e relatórios sobre o status deles no JobManager. 
O TaskManager mantém pools de buffer para buffer ou para materia-
lizar os fluxos e as conexões de rede para trocar os fluxos de dados entre 
operadores (CARBONE et al., 2015). 
O grafo de fluxo de dados é um DAG que consiste em: operadores 
com estado e fluxos de dados que representam dados produzidos por um 
operador e estão disponíveis para consumo pelos operadores. 
Como os grafos de fluxo de dados são executados de forma paralela, 
os operadores são paralelizados em uma ou mais instâncias chamadas 
subtarefas e os fluxos são divididos em uma ou mais partições de fluxo 
(uma partição por subtarefa produzida). 
Os fluxos de dados entre os produtores e os consumidores são distri-
buídos em vários padrões, como ponto a ponto, transmissão, re-partição, 
fan-out e mesclagem (CARBONE et al., 2015). 
Os fluxos de dados intermediários do Flink são a abstração do núcleo 
para troca de dados entre operadores. 
Um fluxo de dados intermediário representa um identificador lógico 
para os dados que são produzidos por um operador e que podem ser con-
sumidos por um ou mais operadores (CARBONE et al., 2015). 
O Flink oferece uma execução confiável com rigorosas garantias de 
consistência via processamento exatamente uma vez (JUNIOR et al., 2018) 
e lida com falhas via verificação e reexecução parcial. 
O pressuposto geral que o sistema faz para fornecer efetivamente es-
sas garantias são que as fontes de dados são persistentes. 
 
 
 
34 
O mecanismo de verificação do Apache Flink baseia-se na noção de 
snapshots distribuídos e consistentes para obter garantias de processa-
mento exatamente uma vez. 
O mecanismo usado no Flink é chamado de Asynchronous Barrier 
Snapshotting (ABS [7]). As barreiras são registros de controle injetados nos 
fluxos de dados de entrada que correspondem a um tempo lógico e sepa-
ram logicamente o fluxo na parte que será incluída no snapshot atual e a 
parte que será posteriormente captada (CARBONE et al., 2015). 
Existem duas APIs principais no Flink: a API DataSet para processar 
conjuntos de dados finitos (geralmente denominado processamento em lo-
tes) e a API DataStream para processamento de fluxos de dados potenci-
almente ilimitados (geralmente referidos como processamento em tempo 
real) (CARBONE et al., 2015). 
 
Processamento 
Em Tempo Real no Flink A API DataStream do Flink implementa uma 
estrutura completa de análise em tempo real em cima do Flink, incluindo os 
mecanismos para gerenciar o tempo, como o processamento de eventos 
fora de ordem, a definição de janelas e a manutenção e atualização do 
estado definido pelo usuário. 
A API de tempo real é baseada na noção de um DataStream, uma 
coleção (possivelmente ilimitada) imutável de elementos de um determi-
nado tipo (CARBONE et al., 2015). 
O Flink distingue entre duas noções de tempo: tempo de evento 
(event-time), que denota o tempo em que um evento se origina (por exem-
plo, o timestamp associado a um sinal proveniente de um sensor, como um 
dispositivo móvel) e tempo de processamento (processing-time), o qual é a 
hora do relógio da máquina que está processando os dados (CARBONE et 
al., 2015). 
 
 
 
35 
O Flink inclui uma terceira noção de tempo como um caso especial de 
tempo de evento chamado ingestion-time, que é o momento em que os 
eventos entram no Flink (CARBONE et al., 2015). 
Os cálculos incrementais sobre fluxos ilimitados são frequentemente 
avaliados em visualizações lógicas em constante evolução, chamadas ja-
nelas. 
O Flink incorpora janelas dentro de um operador com estado que é 
configurado através de uma declaração flexível compostas por três funções 
principais: um atributo de janela e, opcionalmente, um gatilho e um evictor 
(CARBONE et al., 2015). 
Enquanto a maioria dos operadores da API DataStream do Flink se 
parecem com operadores funcionais e sem efeitos colaterais, eles forne-
cem suporte para cálculos eficientes e com estado. 
As janelas de fluxo (Stream windows) são operadores com estado que 
atribuem registros a buckets atualizados continuamente na memória como 
parte do estado do operador (CARBONE et al., 2015). 
O mecanismo de controle do Flink garante que qualquer estado regis-
trado seja durável com uma semântica de atualização exatamente uma vez 
(CARBONE et al., 2015). 
As iterações assíncronas cobrem as necessidades de comunicação 
para aplicativos em tempo real e diferem dos problemas de otimização pa-
ralela baseados em iterações estruturadas em dados finitos. 
O modelo de execução do Flink já abrange iterações assíncronas, 
quando nenhum mecanismo de controle de iteração está habilitado (CAR-
BONE et al., 2015). 
 
 
 
36 
 
Processamento Em Lotes 
No Flink Um conjunto de dados delimitados é um caso especial de um 
fluxo de dados ilimitado. 
Assim, um programa em tempo real que insere todos os seus dados 
de entrada em uma janela pode formar um programa em lote e o proces-
samento em lotes deve ser totalmente coberto pelos recursos do Flink. 
No entanto, a sintaxe (ou seja, a API para computação em lotes) pode 
ser simplificada (por exemplo, não há necessidade de definições de janela 
global artificial) e os programas que processam conjuntos de dados limita-
dos são passíveis de otimizações adicionais, mantendo a tolerância a fa-
lhas e agendamento por etapas. 
O Flink aborda o processamento em lotes da seguinte maneira: 
• A computação em lotes é executada pelo mesmo runtime que a com-
putação em tempo real (CARBONE et al., 2015); 
• O snapshotting periódico é desativado quando a sobrecarga é alta 
(CARBONE et al., 2015); 
• Os operadores de bloqueio (por exemplo, sorts) são simplesmente 
implementações do operador que passam a bloquear até que tenham con-
sumido toda a sua entrada (CARBONE et al., 2015); 
• Uma API de DataSet dedicada fornece abstrações familiares para 
computação em lotes, nomeadamente uma estrutura de dados de DataSet 
tolerante a falhas limitadas e transformações em DataSets (por exemplo, 
junções, agregações, iterações); 
• Uma camada de otimização de consulta transforma um programa 
DataSet em um executável eficiente (CARBONE et al., 2015). 
 
 
 
37 
 
Módulos extras 
O Flink possui quatro grandes bibliotecas criadas nas principais APIs 
dele. São elas: 
• Gelly: é o sistema de processamento de grafos no Flink. Contém 
métodos e utilitários para o desenvolvimento de aplicações de análise de 
grafos (GARCÍA-GIL et al., 2017); 
• FlinkML: esta biblioteca pretende fornecer um conjunto de algoritmos 
ML escaláveis e uma API intuitiva. Ele contém algoritmos para aprendiza-
gem supervisionada, aprendizado sem supervisão, pré-processamento de 
dados, recomendação e outros utilitários (GARCÍA-GIL et al., 2017); 
• API Table e SQL: é uma linguagem de expressão semelhante ao 
SQL para processamento em tempo real e em lotes que pode ser incorpo-
rado nas API de dados do Flink (GARCÍA-GIL et al., 2017); 
• FlinkCEP: é a biblioteca de processamento de eventos complexos. 
Permite detectar padrões de eventos complexos em em tempo real (GAR-
CÍA-GIL et al., 2017). 
 
SoftwaresAuxiliares 
Para Computação Distribuída Nesta Seção serão apresentados os 
softwares Kafka e Zookeeper. 
Sendo citados detalhes da arquitetura utilizada por cada um deles, 
bem como as suas principais características. 
 
 
 
 
38 
Kafka 
Kafka combina os benefícios dos agregadores tradicionais de regis-
tros e sistemas de mensagens. Por um lado, o Kafka é distribuído e esca-
lável e oferece alto throughput (JUNIOR et al., 2018). 
Por outro lado, o Kafka fornece uma API semelhante a um sistema de 
mensagens e permite que os aplicativos consumam eventos em tempo real 
(KREPS et al., 2011). 
 
Arquitetura 
Um fluxo de mensagens de um tipo específico é definido por um tópico 
(topic). Um produtor publica as mensagens em um tópico. 
As mensagens publicadas são armazenadas em um conjunto de ser-
vidores chamados brokers. Um consumidor pode assinar um ou mais tópi-
cos dos brokers e consumir as mensagens dos tópicos assinadas, obtendo 
dados dos brokers (KREPS et al., 2011). 
Como o Kafka é distribuído por natureza, um cluster Kafka geralmente 
consiste em vários brokers. Para equilibrar a carga, um tópico é dividido em 
várias partições e cada broker armazena uma ou mais dessas partições. 
Vários produtores e consumidores podem publicar e recuperar mensagens 
ao mesmo tempo (KREPS et al., 2011). 
 
Características 
As principais características do Kafka são: 
1. Armazenamento simples: o Kafka tem um layout de armazena-
mento muito simples. Cada partição de um tópico corresponde a um log 
lógico. Fisicamente, um log é implementado como um conjunto de seg-
mento de arquivos com aproximadamente o mesmo tamanho. Toda vez 
 
 
 
39 
que um produtor publica uma mensagem em uma partição, o broker sim-
plesmente anexa a mensagem ao último segmento de 36 arquivo (KREPS 
et al., 2011); 
2. Transferência eficiente: o produtor pode enviar um conjunto de 
mensagens em uma única solicitação de envio (KREPS et al., 2011); 
3. Broker sem estado: no Kafka, as informações sobre quanto cada 
consumidor consumiu não são mantidas pelo broker, mas pelo próprio con-
sumidor (KREPS et al., 2011); 
4. Coordenação Distribuída: Kafka tem o conceito de grupos de con-
sumidores (consumer groups). Cada grupo de consumidores consiste em 
um ou mais consumidores que consomem conjuntamente um conjunto de 
tópicos inscritos, ou seja, cada mensagem é entregue a apenas um dos 
consumidores dentro do grupo. O objetivo é dividir as mensagens armaze-
nadas nos brokers entre os consumidores, sem introduzir muita sobrecarga 
de coordenação. 
Para facilitar a coordenação, o Kafka utiliza o Zookeeper. O Kafka usa 
o Zookeeper para as seguintes tarefas: 
(1) detectar a adição e remoção de brokers e consumidores, 
(2) desencadear um processo de reequilíbrio em cada consumidor 
quando os eventos acima ocorrerem e 
(3) manter a relação de consumo e acompanhar o deslocamento con-
sumido de cada partição (KREPS et al., 2011); 
4. Garantias de Entrega: Em geral, o Kafka garante apenas a semân-
tica pelo menos uma vez. Na maioria das vezes, uma mensagem é entre-
gue exatamente uma vez para cada grupo de consumidores. 
O Kafka garante que as mensagens de uma única partição sejam en-
tregues a um consumidor na ordem correta. 
 
 
 
40 
Para evitar a corrupção de logs, o Kafka armazena um CRC para cada 
mensagem no log. Se houver algum erro de E/S no broker, o Kafka execu-
tará um processo de recuperação para remover as mensagens com CRCs 
inconsistentes. 
Se um broker ficar inativo, qualquer mensagem armazenada nele 
ainda não consumida ficará indisponível (KREPS et al., 2011). 
 
 
ZooKeeper 
O ZooKeeper tem uma abordagem livre de espera para o problema 
de coordenar processos em sistemas distribuídos, expondo objetos sem 
esperas a clientes. 
O ZooKeeper alcança throughput de centenas de milhares de opera-
ções por segundo para cargas de trabalho de leitura usando leituras rápi-
das com relógios, ambos servidos por réplicas locais (HUNT et al., 2010). 
 
Arquitetura 
O cliente (client) denota o usuário do serviço ZooKeeper, o servidor 
(server) denota um processo que fornece o serviço ZooKeeper e o znode 
denota um nó com dados em memória que contém os dados do ZooKeeper, 
e que é organizado em um namespace hierárquico chamado de árvore de 
dados (data tree). Os termos update e write se referem a qualquer operação 
que modifique o estado da árvore de dados. 
Os clientes estabelecem uma sessão quando se conectam ao Zoo-
Keeper e obtêm um identificador de sessão pelo qual eles emitem solicita-
ções (HUNT et al., 2010). 
 
 
 
 
41 
Características 
As principais características do ZooKeeper são: 
1. Modelo de dados: O modelo de dados do ZooKeeper é essencial-
mente um sistema de arquivos com uma API simplificada e apenas leituras 
e gravações completas de dados. 
O namespace hierárquico é útil para alocar subárvores para o names-
pace de aplicativos diferentes e para definir direitos de acesso a essas su-
bárvores. 
Os znodes mapeiam para abstrações os aplicativos do cliente, nor-
malmente correspondendo a metadados usados para propósitos de coor-
denação. 
Os znodes também possuem metadados associados a carimbos de 
data e hora e contadores de versão, que permitem aos clientes rastrear 
alterações nos znodes e executar atualizações condicionais com base na 
versão do znodes (HUNT et al., 2010); 
2. Sessões: As sessões têm um tempo limite associado. O Zoo-
Keeper considera um cliente defeituoso se ele não receber nada de sua 
sessão por mais que o tempo limite. 
Uma sessão termina quando os clientes fecham explicitamente um 
identificador de sessão ou o ZooKeeper detecta que um cliente está com 
defeito (HUNT et al., 2010); 
3. Garantias: O ZooKeeper tem duas garantias básicas de pedidos: 
gravações linearizáveis; fila FIFO onde todos os pedidos de um deter-
minado cliente são executados na ordem em que foram enviados (HUNT 
et al., 2010). 
 
 
 
 
 
42 
 
 
 
REFERÊNCIAS 
ADMINISTRATION, T. U. E. I. Prices and Factors Affecting Prices. 
2018. . Acessado Novembro 25, 2018. 
ALEXANDROV, A. et al. The stratosphere platform for big data ana-
lytics. The VLDB Journal, Springer, v. 23, n. 6, p. 939–964, 2014. 
AMAZON.COM. NVIDIA Jetson TX2 Development Kit. 2018. . Aces-
sado Novembro 25, 2018. 
Anjos, J. C. S. et al. Enabling strategies for big data analytics in hybrid 
infrastructures. In: 2018 International Conference on High Performance 
Computing Simulation (HPCS). [S.l.: s.n.], 2018. p. 869–876. 
BARROSO, L. A.; CLIDARAS, J.; HÖLZLE, U. The datacenter as a 
computer: An introduction to the design of warehouse-scale machines. Syn-
thesis lectures on computer architecture, Morgan & Claypool Publishers, v. 
8, n. 3, p. 1–154, 2013. 
BOSE, R.; FREW, J. Lineage retrieval for scientific data processing: a 
survey. ACM Computing Surveys (CSUR), ACM, v. 37, n. 1, p. 1–28, 2005. 
CARBONE, P. et al. Apache flink: Stream and batch processing in a 
single engine. Bulletin of the IEEE Computer Society Technical Committee 
on Data Engineering, IEEE Computer Society, v. 36, n. 4, 2015. 
CHEN, C. P.; ZHANG, C.-Y. Data-intensive applications, challenges, 
techniques and technologies: A survey on big data. Information Sciences, 
Elsevier, v. 275, p. 314–347, 2014. 
CHEN, M.; MAO, S.; LIU, Y. Big data: A survey. Mobile networks and 
applications, Springer, v. 19, n. 2, p. 171–209, 2014. 
 
 
 
43 
CHENEY, J. et al. Provenance in databases: Why, how, and where. 
Foundations and Trends R in Databases, Now Publishers, Inc., v. 1, n. 4, p. 
379–474, 2009. 
DEAN, J.; GHEMAWAT, S. Mapreduce: simplified data processing on 
large clusters. Communications of the ACM, ACM, v. 51, n. 1, p. 107–113, 
2008. 
DONG, X. L.; SRIVASTAVA, D. Big data integration. In: IEEE. Data 
Engineering (ICDE), 2013 IEEE 29th International Conference on. [S.l.], 
2013. p. 1245–1248.DUSTY-NV. Tegra Parker Block Diagram.png. 2018. Acessado No-
vembro 24, 2018. 
EBRAHIMI, K.; JONES, G. F.; FLEISCHER, A. S. A review of data 
center cooling technology, operating conditions and the corresponding low-
grade waste heat recovery opportunities. Renewable and Sustainable En-
ergy Reviews, Elsevier, v. 31, p. 622–638, 2014. 
FOUNDATION, A. S. Apache Hadoop 3.1.0. 2018. . Acessado Abril 
25, 2018. 
GEORGAKOUDIS, G. et al. Nanostreams: Codesigned microservers 
for edge analytics in real time. In: IEEE. Embedded Computer Systems: Ar-
chitectures, Modeling and Simulation (SAMOS), 2016 International Confer-
ence on. [S.l.], 2016. p. 180–187. 
GHEMAWAT, S.; GOBIOFF, H.; LEUNG, S.-T. The Google file sys-
tem. [S.l.]: ACM, 2003. v. 37. 
HASHEM, I. A. T. et al. The rise of “big data” on cloud computing: 
Review and open research issues. Information Systems, Elsevier, v. 47, p. 
98–115, 2015. 
HITZLER, P.; JANOWICZ, K. Linked data, big data, and the 4th para-
digm. Semantic Web, v. 4, n. 3, p. 233–235, 2013. 
 
 
 
44 
KALYANASUNDARAM, J.; SIMMHAN, Y. Arm wrestling with big data: 
A study of commodity arm64 server for big data workloads. In: Proc. IEEE 
24th International Conference on High Performance Computing (HiPC). 
[S.l.: s.n.], 2017. p. 203–212. 
KAMBATLA, K. et al. Trends in big data analytics. Journal of Parallel 
and Distributed Computing, Elsevier, v. 74, n. 7, p. 2561–2573, 2014. 
KOROMILAS, E. et al. Spark acceleration on fpgas: A use case on machine 
learning in pynq. In: IEEE. Modern Circuits and Systems Technologies (MO-
CAST), 2017 6th International Conference on. [S.l.], 2017. p. 1–4. 
LANDSET, S. et al. A survey of open source tools for machine learning 
with big data in the hadoop ecosystem. Journal of Big Data, Springer, v. 2, 
n. 1, p. 24, 2015. 
LANEY, D. 3d data management: Controlling data volume, velocity 
and variety. META Group Research Note, v. 6, n. 70, 2001. LEICH, M. et 
al. Applying stratosphere for big data analytics. In: BTW. [S.l.: s.n.], 2013. 
p. 507–510. 
MANYIKA, J. et al. Big data: The next frontier for innovation, competi-
tion, and productivity. 2011. MEDIA, I. O. Big Data Now: 2014 Edition. [S.l.]: 
O’Reilly Media, 2015. 
MENG, X. et al. Mllib: Machine learning in apache spark. The Journal 
of Machine Learning Research, JMLR. org, v. 17, n. 1, p. 1235–1241, 2016. 
MISRA, P.; SIMMHAN, Y.; WARRIOR, J. Towards a practical archi-
tecture for the next generation internet of things. arXiv preprint 
arXiv:1502.00797, 2015. 
NESHATPOUR, K. et al. Energy-efficient acceleration of big data an-
alytics applications using fpgas. In: IEEE. Big Data (Big Data), 2015 IEEE 
International Conference on. [S.l.], 2015. p. 115–123. 
 
 
 
45 
PADOIN, E. L. et al. Time-to-solution and energy-to-solution: a com-
parison between arm and xeon. In: IEEE. Applications for Multi-Core Archi-
tectures (WAMCA), 2012 Third Workshop on. [S.l.], 2012. p. 48–53. 
SAMOSIR, J.; INDRAWAN-SANTIAGO, M.; HAGHIGHI, P. D. An 
evaluation of data stream processing systems for data driven applications. 
Procedia Computer Science, Elsevier, v. 80, p. 439–449, 2016. 
SHAHRIVARI, S. Beyond batch processing: towards real-time and 
streaming big data. Computers, Multidisciplinary Digital Publishing Institute, 
v. 3, n. 4, p. 117–129, 2014. SHI, W. et al. Edge computing: Vision and 
challenges. IEEE Internet of Things Journal, IEEE, v. 3, n. 5, p. 637–646, 
2016. 
VARGHESE, B. et al. Challenges and opportunities in edge compu-
ting. arXiv preprint arXiv:1609.01967, 2016. 
VAVILAPALLI, V. K. et al. Apache hadoop yarn: Yet another resource 
negotiator. In: ACM. Proceedings of the 4th annual Symposium on Cloud 
Computing. [S.l.], 2013. p. 5. 
WHITE, T. Hadoop: The definitive guide. [S.l.]: "O’Reilly Media, Inc.", 
2012. 
XILINX. PYNQ: PYTHON PRODUCTIVITY FOR ZYNQ. 2018. . Aces-
sado Abril 27, 2018. 
XU, S. S.-D.; CHANG, T.-C. A feasible architecture for arm-based mi-
croserver systems considering energy efficiency. IEEE Access, IEEE, v. 5, 
p. 4611–4620, 2017. 
YI, S.; LI, C.; LI, Q. A survey of fog computing: concepts, applications 
and issues. In: ACM. Proceedings of the 2015 workshop on mobile big data. 
[S.l.], 2015. p. 37–42. 
 
 
 
46 
ZAHARIA, M. et al. Resilient distributed datasets: A fault-tolerant ab-
straction for in-memory cluster computing. In: USENIX ASSOCIATION. Pro-
ceedings of the 9th USENIX conference on Networked Systems Design and 
Implementation. [S.l.], 2012. p. 2–2. 
ZAHARIA, M. et al. Spark: Cluster computing with working sets. Hot-
Cloud, v. 10, n. 10-10, p. 95, 2010. 
ZIKOPOULOS, P.; EATON, C. et al. Understanding big data: Analytics 
for enterprise class hadoop and streaming data. [S.l.]: McGraw-Hill Osborne 
Media, 2011. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
47