Um estudo sobre a performance de aplicações big data em ambientes de névoa e de borda

(1)

PROGRAMA DE PÓS-GRADUAÇÃO EM COMPUTAÇÃO

JORGE XIMENDES SILVA JUNIOR

Um Estudo sobre a Performance de

Aplicações Big Data em Ambientes de

Névoa e de Borda

Dissertação apresentada como requisito parcial para a obtenção do grau de Mestre em Ciência da Computação

Orientador: Prof. Dr. Cláudio Resin Geyer

Porto Alegre 2019

(2)

Silva Junior, Jorge Ximendes

Um Estudo sobre a Performance de Aplicações Big Data em Ambientes de Névoa e de Borda / Jorge Ximendes Silva Junior. – Porto Alegre: PPGC da UFRGS, 2019.

134 f.: il.

Dissertação (mestrado) – Universidade Federal do Rio Grande do Sul. Programa de Pós-Graduação em Computação, Porto Ale-gre, BR–RS, 2019. Orientador: Cláudio Resin Geyer.

1. Processadores ARM. 2. Computação em névoa e de borda. 3. Eficiência Energética. 4. Big Data. I. Geyer, Cláudio Resin. II. Título.

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL Reitor: Prof. Rui Vicente Oppermann

Vice-Reitora: Profa. Jane Fraga Tutikian

Pró-Reitor de Pós-Graduação: Prof. Celso Giannetti Loureiro Chaves Diretora do Instituto de Informática: Profa. Carla Maria Dal Sasso Freitas Coordenadora do PPGC: Profa_{. Luciana Salete Buriol}

(3)

(4)

Agradeço aos meus pais pelo apoio e incentivo durante o mestrado, mesmo não entendendo nada do que eu estava fazendo.

Agradeço ao Kassiano por toda a ajuda durante o mestrado, mesmo que às vezes não tenhamos nos entendido em certos pontos.

Agradeço ao Presidente Lula e a Presidenta Dilma por terem fornecido as oportu-nidades para chegar até aqui.

(5)

O uso de processadores ARM para o processamento Big Data já é objeto de estudo de vários autores. Entretanto, a grande maioria desses autores leva em conta o processa-mento em lotes (batch) utilizando o framework Hadoop. Além disso, poucos trabalhos comparam o desempenho entre diferentes processadores ARM. Não há uma comparação de como diferentes arquiteturas influenciam na execução de aplicações Big Data. Desse modo, percebe-se a necessidade de um estudo que avalie o desempenho dos frameworks (e aplicações Big Data) sob ambos os modelos de processamento (em lotes e em tempo real). Além disso, torna-se importante avaliar o impacto de diferentes arquiteturas ARM sobre os frameworks e aplicações Big Data. Assim, esse trabalho apresenta uma avaliação experimental de processadores ARM para processamento Big Data. Os dois principais modelos de processamento Big Data foram avaliados neste trabalho (processamento em lotes e processamento em tempo real). Assim, como os frameworks Hadoop, Spark e Flink. Como representantes ARM foram avaliados a arquitetura ARMv7 com processa-dor Cortex-A7 e a arquitetura ARMv8 com os processaprocessa-dores Cortex-A57 e Denver2. O benchmarkutilizado neste trabalho foi o Hibench que apresenta aplicações que utilizam ambos os modelos de processamento e que suportam os frameworks citados. Os resulta-dos mostraram que é possível utilizar processadores ARM no processamento Big Data e que a escolha da arquitetura e do processador a serem utilizados passa pelas necessidades da aplicação a ser processada, assim, como pelas características do ambiente de execução a ser construído.

Palavras-chave: Processadores ARM. Computação em névoa e de borda. Eficiência Energética. Big Data.

(6)

ABSTRACT

The use of ARM processors for Big Data processing already is study object of several authors. However, the vast majority of these authors take only the batch processing under consideration using the Hadoop framework. Besides, few works compare the performance among different ARM processors. There is no comparison regarding how different archi-tectures inffluence the execution of Big Data applications. Therefore, a need is perceived regarding a study that evaluates the framework’s performance (and Big Data applications) under both batch and real-time processing models. Furthermore, it is important to evalu-ate the impact of different ARM architectures over the Big Data application’s frameworks. Thus, this work presents an experimental evaluation of ARM processors for Big Data pro-cessing. The two main Big Data processing models were evaluated in this work (batch processing and real time processing), just as the Hadoop, Spark and Flink frameworks. Representing ARM, we evaluated the ARMv7 architecture with Cortex-A7 processor and the ARMv8 architecture with Cortex-A57 and Denver2 processors. The benchmark that was used in this work was HiBench, that contains applications that use both processing models, and that support the previously mentioned frameworks. The results showed that it is possible to use ARM processors in the Big Data processing, and also that both the choice of architecture and the processor that will be used are dependent on the applica-tion that will be processed, as well as it is dependent on the features of the execuapplica-tion environment to be built.

(7)

CAGR Cumulative Annual-Growth Rate HPC High-Performance Computing GPU Graphic Processing Unit TCO Total Cost of Ownership IoT Internet of Things

(8)

Figura 2.1 Arquiteturas De Computação ...21

Figura 5.1 Limites - processamento em lotes ...77

Figura 5.2 Diagrama em bloco do processador da Tegra TX2...88

Figura 5.3 Uso de recursos no ambiente 1 para a aplicação Pagerank ...89

Figura 5.4 Uso de recursos no ambiente 1 para a aplicação Kmeans ...90

Figura 5.5 Uso de recursos no ambiente 2 para a aplicação Pagerank ...91

Figura 5.6 Uso de recursos no ambiente 2 para a aplicação Kmeans ...92

Figura 5.7 Limites - processamento em tempo real (Flink) ...95

Figura 5.8 Uso de recursos - ambiente 1 - 10000 msgs/s - Flink - Fixwindow ...101

Figura 5.11 Uso de recursos - ambiente 4 - 25000 msgs/s - Flink - Identity ...103

Figura 5.12 Uso de recursos - ambiente 1 - 100 msgs/s - Flink - Wordcount...104

Figura 5.13 Uso de recursos - ambiente 4 - 25000 msgs/s - Flink - Wordcount...105

Figura A.1 Uso de recursos no ambiente 3 para a aplicação Pagerank ...122

Figura A.2 Uso de recursos no ambiente 3 para a aplicação Kmeans...122

Figura A.3 Uso de recursos no ambiente 4 para a aplicação Pagerank ...123

Figura A.4 Uso de recursos no ambiente 4 para a aplicação Kmeans...123

Figura B.1 Uso de recursos no ambiente 1 com a carga de trabalho de 100 msgs/s...124

Figura B.4 Uso de recursos no ambiente 1 com a carga de trabalho de 100 msgs/s...126 Figura C.1 Uso de recursos no ambiente 3 com a carga de trabalho de 10000 msgs/s.127 Figura C.2 Uso de recursos no ambiente 4 com a carga de trabalho de 10000 msgs/s.128 Figura C.3 Uso de recursos no ambiente 2 com a carga de trabalho de 25000 msgs/s.128 Figura C.4 Uso de recursos no ambiente 3 com a carga de trabalho de 20000 msgs/s.129 Figura C.5 Uso de recursos no ambiente 2 com a carga de trabalho de 10000 msgs/s.129 Figura C.6 Uso de recursos no ambiente 3 com a carga de trabalho de 10000 msgs/s.130 Figura C.7 Uso de recursos no ambiente 4 com a carga de trabalho de 10000 msgs/s.130 Figura C.8 Uso de recursos no ambiente 2 com a carga de trabalho de 25000 msgs/s.131 Figura C.9 Uso de recursos no ambiente 3 com a carga de trabalho de 20000 msgs/s.131 Figura C.10 Uso de recursos no ambiente 2 com a carga de trabalho de 10000 msgs/s132 Figura C.11 Uso de recursos no ambiente 3 com a carga de trabalho de 10000 msgs/s132 Figura C.12 Uso de recursos no ambiente 4 com a carga de trabalho de 10000 msgs/s133 Figura C.13 Uso de recursos no ambiente 2 com a carga de trabalho de 20000 msgs/s133 Figura C.14 Uso de recursos no ambiente 3 com a carga de trabalho de 20000 msgs/s134

(9)

Tabela 4.1 Análise comparativa dos trabalhos relacionados ...55

Tabela 5.1 Cargas de trabalho para o domínio Micro Benchmarks ...59

Tabela 5.2 Cargas de trabalho para o domínio SQL ...60

Tabela 5.3 Cargas de trabalho para o domínio Websearch Benchmarks ...60

Tabela 5.4 Cargas de trabalho para o domínio Machine Learning (Bayesian Clas-sification)...61

Tabela 5.5 Cargas de trabalho para o domínio Machine Learning (K-means clustering)62 Tabela 5.6 Domínios, aplicações e frameworks ...63

Tabela 5.7 Apresentação das placas Cubietruck, Nvidia Tegra TX1 e Nvidia Tegra TX2 ...65

Tabela 5.8 Apresentação dos ambientes utilizados ...66

Tabela 5.9 Distribuição das tarefas de Map E Reduce para os ambientes 1 E 2 ...67

Tabela 5.10 Distribuição das tarefas de Map E Reduce para o ambiente 3...67

Tabela 5.11 Distribuição das tarefas de Map E Reduce para o ambiente 4...67

Tabela 5.12 Nível de paralelismo (Flink)...70

Tabela 5.13 Configurações das aplicações do domínio Streaming ...72

Tabela 5.14 Métricas ...75

Tabela 5.15 Ambiente 1 - framework Hadoop ...78

Tabela 5.16 Ambiente 1 - framework Spark ...78

Tabela 5.23 Resumo das configurações ...85

Tabela 5.24 Diferença entre os processadores/arquiteturas ...86

Tabela 5.25 Consumo energético dos processadores/arquiteturas ...93

Tabela 5.26 Consumo energético dos processadores/arquiteturas - em porcentagem ....93

Tabela 5.27 Resultados - framework Spark...95

Tabela 5.28 Ambiente 1 - framework Flink ...96

Tabela 5.32 Consumo de energia - framework Flink - em Joule (J) ...106

Tabela 5.33 Consumo de energia - framework Flink - em porcentagem ...107

Tabela 5.34 Componentes da fórmula 5.9...108

(10)

1 INTRODUÇÃO ...12

1.1 Hipótese e Questões de Pesquisa...14

1.2 Organização do Trabalho...15

2 BIG DATA...16

2.1 Definições e Conceitos...16

2.2 Modelos de Processamento...18

2.2.1 Processamento em Lotes...19

2.2.2 Processamento em Tempo Real ...19

2.3 Infraestrutura de Computação em Névoa e de Borda para Aplicações Big Data ...20

2.3.1 Considerações do consumo energético ...22

2.4 Considerações finais...22

3 FRAMEWORKS BIG DATA...23

3.1 O Modelo MapReduce...23 3.2 Apache Hadoop ...24 3.2.1 Limitações do Hadoop ...25 3.3 Apache Spark ...26 3.3.1 Spark RDD...26 3.3.2 Modelo de dados ...27 3.3.3 Escalonamento de Jobs ...28 3.3.4 Módulos extras...28 3.3.5 Spark Streaming ...29 3.4 Apache Flink...30 3.4.1 Arquitetura do Flink...31

3.4.2 Processamento Em Tempo Real no Flink ...32

3.4.3 Processamento Em Lotes No Flink...33

3.4.4 Módulos extras...34

3.5 Softwares Auxiliares Para Computação Distribuída ...35

3.5.1 Kafka...35 3.5.1.1 Arquitetura ...35 3.5.1.2 Características ...35 3.5.2 ZooKeeper...36 3.5.2.1 Arquitetura ...37 3.5.2.2 Características ...37 3.6 Considerações finais...38 4 TRABALHOS RELACIONADOS ...39

4.1 Infraestrutura em Computação em Névoa (e de Borda) ...39

4.2 Processamento Big Data em Processadores ARM ...41

4.3 Processamento Big Data em Sistemas Heterogêneos ...50

4.4 Considerações...55

5 UMA ANÁLISE COMPARATIVA DA PERFORMANCE DE APLICAÇÕES BIG DATA EM AMBIENTES DE NÉVOA E DE BORDA ...57

5.1 Proposta ...57

5.2 Metodologia ...58

5.2.1 Especificações de Software...58

5.2.1.1 Frameworks Big Data ...58

(11)

5.2.2.2 ARMv8 ...64

5.2.2.3 Resumo das configurações...65

5.2.3 Cenários de Teste para Processamento em Lotes ...66

5.2.3.1 Limite de processamento ...67

5.2.3.2 Configuração de slots em clusters MapReduce ...68

5.2.3.3 Diferença de desempenho entre arquiteturas/organizações ...68

5.2.3.4 Utilização de recursos ...69

5.2.3.5 Eficiência energética ...69

5.2.4 Cenários de Teste para Processamento em Tempo Real ...70

5.2.4.2 Configuração de slots para o framework Spark ...71

5.2.4.3 Avaliação dos ambientes no framework Flink ...71

5.2.5 Análise de custo total da posse (Total Cost of Ownership - TCO) ...73

5.2.5.1 Análise de custo total da posse ...73

5.2.6 Quantidade de experimentos...74

5.2.7 Resumo das Métricas Utilizadas...74

5.3 Avaliação ...76

5.3.1 Processamento em Lote ...76

5.3.1.2 Configuração de slots em clusters MapReduce ...77

5.3.1.3 Diferença de desempenho entre arquiteturas/organizações ...86

5.3.2 Processamento em Tempo Real ...94

5.3.2.2 Configuração de slots para o framework Spark ...96

5.3.2.3 Avaliação dos ambientes no framework Flink ...96

5.3.3 Análise de custo total da posse (Total Cost of Ownership - TCO) de proces-sadores ARM para processamento Big Data ...107

5.4 Considerações...110

6 CONCLUSÃO ...112

REFERÊNCIAS...115

APÊNDICE A — USO DE RECURSOS NAS APLICAÇÕES DE PROCES-SAMENTO EM LOTES...122

APÊNDICE B — USO DE RECURSOS NAS APLICAÇÕES DE PROCES-SAMENTO EM TEMPO REAL NO FRAMEWORK SPARK...124

APÊNDICE C — USO DE RECURSOS NAS APLICAÇÕES DE PROCES-SAMENTO EM TEMPO REAL NO FRAMEWORK FLINK ...127

(12)

1 INTRODUÇÃO

O crescente uso de dispositivos eletrônicos, tais como smartphones, tablets, sen-sores, 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 esses dados visando extrair informações estratégicas e valiosas (AS-SUNÇÃO et al., 2015).

Dessa forma, inúmeras aplicações para Big Data surgiram. Essas aplicações co-brem os mais variados domínios, tais como: Internet das Coisas, empresarial, governa-mental, astronômico, meteorológico, da bioinformática, das ciências, dentre outras. Em um cenário com produção de dados em larga escala é muito comum observar a imensa movimentação e o processamento intensivo de dados.

Quanto à movimentação de dados, o tráfego total na Internet cresceu exponen-cialmente nas últimas duas décadas. Em meados de 1992, as redes globais de Internet costumavam movimentar aproximadamente 100 GB de tráfego por dia. Dez anos de-pois, o tráfego global da Internet era de 100 Gigabytes por segundo (GBps). 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 Exabytes 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 relaçã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 milhares 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 tecnologia de design e fabricação, os desafios ligados à eficiência energética persistem, tornando-se uma preo-cupação atual.

Adicionalmente, pode-se citar a análise proposta por (GÖDDEKE et al., 2013; EBRAHIMI; JONES; FLEISCHER, 2014), onde os autores indicam que os atuais siste-mas de computação de alto desempenho (High-Performance Computing – HPC) utilizam cerca de 40% à 60% do total de energia gasta para a computação, 10% para os sistemas de rede e de armazenamento, e o restante é consumido pela própria infraestrutura, tal como

(13)

iluminação e refrigeração. Pode-se observar, com base nesse estudo, que o consumo ener-gé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 con-trá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 computacional. Então um datacenter bem colocado no Green500 apresenta uma eficiência energética alta. Ainda, a maioria dos lideres do Green500 usam uma combinação de processadores x86 com unidades de processamento gráfico (Graphic Processing Unit – GPU) e outras tecnologias de acelera-ção.

Os processadores ARM são amplamente utilizados em diversos sistemas embarca-dos, tais como: smartphones, tablets, sensores, dispositivos IoT, dentre outros (LOGHIN et al., 2015). Além disso, a organização destes modelos de processadores foi desenvol-vida para possuir eficiência energética. Assim, os processadores ARM se candidatam a serem utilizados na construção de novos datacenters 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 bilhões de dispositivos de Internet das Coisas no mundo (IDC, 2018). As aplicaçõ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 jus-tamente o problema da latência (YI; LI; LI, 2015). Assim, para resolver o problema de latência foi proposto o usa da arquitetura de computação em névoa (FOG Computing) e de borda (EDGE Computing). Tais arquiteturas adicionam camadas de processamento entre a aplicação (usuário final) e a nuvem para diminuir principalmente a latência (YI; LI; LI, 2015). 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, tam-bém podem se beneficiar da principal vantagem dos processadores ARM, ou seja, sua eficiência energética. De fato, o uso de processadores ARM para o processamento Big Data foi objeto de estudo de vários autores. Pode-se citar o trabalho de Kalyanasunda-ram e Simmhan (KALYANASUNDARAM; SIMMHAN, 2017), os autores avaliaKalyanasunda-ram o impacto do uso de processador ARM de 64 bits para processamento Big Data em com-paraçã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 arquitetura) 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 modelos de proces-samento. O primeiro modelo é chamado de processamento em lotes e tem como finalidade o processamento de dados com limites definidos e o segundo é 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 executados sobre frameworks Apache Hadoop, Spark, Flink e outros, e as aplicações de processamento em tempo real podem ser executadas sobre os frameworks Apache Spark, Flink, Storm e outros.

No estado da arte, muitos autores abordam o processamento Big Data sobre pro-cessadores 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 processadores 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 diferentes ar-quiteturas, logo, não há uma avaliação de como diferentes arquiteturas 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 arquiteturas ARM sobre os frameworks e aplicações Big Data.

1.1 Hipótese e Questões de Pesquisa

Este trabalho tem como objetivo investigar a seguinte hipótese de pesquisa: "É possível utilizar processadores ARM para processamento Big Data". Para conduzir essa investigação, as seguintes questões de pesquisa foram definidas:

• Q1. Como diferentes arquiteturas ARM podem influenciar nas aplicações Big Data? O objetivo é mensurar a diferença de desempenho entre as arquiteturas ARMv7 (32 bits) e ARMv8 (64 bits) no processamento de aplicações Big Data; • Q2. Como os recursos de entrada/saída dos processadores ARM influenciam

(15)

nas aplicações Big Data? O objetivo é identificar as possíveis contenções nos re-cursos de entrada/saída (memória, disco, rede) e como elas afetam o processamento Big Data;

• Q3. Qual das diferentes arquiteturas ARM tem melhor eficiência energética no processamento Big Data. O objetivo é identificar qual dos processadores ARM e qual das arquiteturas ARM têm a melhor eficiência energética no processamento Big Data;

• Q4. Descobrir os limites para processamento Big Data dos processadores ARM. O objetivo é compreender e identificar as características dos processadores ARM no processamento Big Data e, assim, identificar os seus limites de processamento; • Q5. Realizar uma análise de custo total da posse (Total Cost of Ownership

-TCO) do uso de processadores ARM para processamento Big Data. O objetivo é analisar se o uso dos processadores ARM para processamento Big Data é viável do ponto de vista econômico.

Desse modo, o objetivo e as questões apresentadas serão explorados nos capítulos a seguir desta dissertação.

1.2 Organização do Trabalho

O presente capítulo apresentou a introdução desse trabalho e sua motivação. Os próximos capítulos estão organizados da seguinte forma: O capítulo 2 apresenta os con-ceitos e modelos de processamento Big Data, o capítulo 3 apresenta os principais fra-meworksBig Data explicando as características de cada um deles. O capítulo 4 apresenta os trabalhos relacionados a pesquisa realizada neste trabalho. O capítulo 5 apresenta a proposta desse trabalho, bem como a avaliação experimental que busca responder as questões pesquisa relacionadas ao mesmo. O Capítulo 6 apresenta as conclusões a cerca do trabalho realizado.

(16)

2 BIG DATA

Neste capítulo, serão apresentados os conceitos de Big Data, os modelos de pro-cessamento em lote e em tempo real destacando como ocorre o propro-cessamento e o funci-onamento dos mecanismos de tolerância à falhas utilizados em cada um deles.

2.1 Definições e Conceitos

Big Data é um termo utilizado para se referir ao grande volume de dados que são difíceis de armazenar, processar e analisar através de tecnologias tradicionais. A definição de Big Data é imprecisa e seu processamento envolve esforço considerável para identificar e traduzir os dados em novos conhecimentos (informação) (HASHEM et al., 2015).

Vários pesquisadores e profissionais utilizaram o termo na literatura. Por exemplo, os autores (COX; ELLSWORTH, 1997) referiram-se a Big Data como um grande volume de dados científicos para visualização. Já o autor (MANYIKA et al., 2011) define Big Data como “um conjunto de dados cujo tamanho está além da capacidade de ferramentas de software de banco de dados típicas para capturar, armazenar, gerenciar e analisar”. Do mesmo modo, o autor (DAVIS, 2012) diz que “Big Data são dados muito grandes para serem tratados e analisados por protocolos tradicionais de banco de dados, como SQL”; e a mesma definição é compartilhada por outros autores (ZIKOPOULOS; EATON et al., 2011; KRISHNAN, 2013; REEVE, 2013). Adicionalmente, o autor (MEDIA, 2015) relata que “os dados são muito grandes, se movem muito rápido ou não se encaixam nas restrições de suas arquiteturas de banco de dados”.

Historicamente, pode-se dizer que Big Data começou em 1997, quando os autores (COX; ELLSWORTH, 1997) discutiram Big Data no contexto da computação moderna. Este trabalho teve como finalidade a visualização de dados, mas suas observações sobre o problema de Big Data são facilmente extrapoladas para a análise geral de dados e a aprendizagem de máquina. Ainda, os autores citam os principais problemas em torno do tema "Big Data".

• Grandes coleções de dados que são conjuntos de dados variados e que possuem diferentes fontes e formatos, bem como são armazenados de forma distribuída em diferentes repositórios;

(17)

muito grandes para serem processados nos algoritmos e hardwares tradicionais para a época. Ao contrário das coleções, os objetos são oriundos de uma única fonte.

Já em 2001, o autor (LANEY, 2001) descreveu três dimensões dos desafios de gerenciamento de dados, em termos de volume, velocidade e variedade, é frequentemente documentada na literatura e é a base do que hoje é entendido como Big Data. Estas três dimensões (comumente referidas como as 3V’s) podem ser entendidas da seguinte forma:

• O volume refere-se ao tamanho propriamente dito dos dados;

• A velocidade aborda a velocidade com que os dados podem ser recebidos e anali-sados;

• Variedade refere-se à questão de diferentes formatos de dados.

Já que o tamanho não é a única característica do Big Data; Muitos autores (DA-VIS, 2012; MEDIA, 2015; ZIKOPOULOS; EATON et al., 2011; DONG; SRIVASTAVA, 2013; HITZLER; JANOWICZ, 2013; REEVE, 2013) também utilizam os 3V’s. Se os três Vs são encontrados em grande parte da literatura, muitos autores (HITZLER; JA-NOWICZ, 2013) e institutos como IEEE se concentram em Valor, Veracidade e Visua-lização. Este último “V” para notar o quão importante é fornecer boas ferramentas para descobrir resultados de dados e análises. A seguir, serão definidas as principais caracte-rísticas que o Big Data possui atualmente. São elas:

• Volume (dados aramazenados). O benefício obtido com a capacidade de processar grandes quantidades de informações é o principal atrativo do processamento Big Data (MEDIA, 2015). A consequência é que armazenar grande quantidade de dados de vários tipos se tornou uma tendência para muitas empresas;

• Variedade (dados em muitas formas). Os dados não possuem uma estrutura fixa e raramente se apresentam em uma forma perfeitamente ordenada e prontos para processamento (MEDIA, 2015). Na verdade, esses dados podem ser altamente estruturados (dados de bancos de dados relacionais), semiestruturados (logs da web, feedsde mídia social, feed bruto diretamente de uma fonte de sensor, e-mail, etc.) ou não estruturados (vídeo, imagens estáticas, áudio, cliques) (MEDIA, 2015); • Velocidade (dados em movimento). A velocidade envolve fluxos de dados, criação

de registros estruturados e disponibilidade para acesso e entrega. Na verdade, a velocidade dos dados recebidos não é o único problema: é possível transmitir os

(18)

dados rapidamente para o sistema de armazenamento para posterior processamento em lotes, por exemplo. A importância reside na velocidade do feedback, levando dados da entrada até a decisão (MEDIA, 2015);

• Valor (dados em destaque). Esse recurso é o objetivo da tecnologia Big Data. Esta visão é bem expressa pela International Data Corporation ao dizer que:"as arquite-turas de Big Data são projetadas para extrair economicamente o valor de volumes muito grandes de uma grande variedade de dados, permitindo a captura, descoberta e/ou análise em alta velocidade”. Esse valor cai em duas categorias: uso analítico (substituindo/apoiando decisões humanas, descobrindo necessidades, segmentando populações para personalizar ações) e permitindo novos modelos de negócios, pro-dutos e serviços (MEDIA, 2015; MANYIKA et al., 2011);

• Veracidade (dados em dúvida). A veracidade é o que está em conformidade com a verdade ou fato, ou em suma, fidelidade, certeza, precisão. A incerteza pode ser causada por inconsistências, aproximações de modelos, ambiguidades, decepções, fraude, duplicação, incompletude, spam e latência. Devido à veracidade, os resulta-dos obtiresulta-dos com Big Data não podem ser comprovaresulta-dos, mas podem ser atribuíresulta-dos um probabilidade aos resultados obtidos (EMANI; CULLOT; NICOLLE, 2015).

Trabalhar de forma eficiente com Big Data exige que se crie valor em relação ao volume, variedade e veracidade dos dados enquanto eles ainda estão em movimento (velo-cidade), e não apenas depois que está armazenado (ZIKOPOULOS; EATON et al., 2011). A seguir serão apresentados os modelos de processamento utilizados pelas aplicações e frameworksBig Data.

2.2 Modelos de Processamento

Em Big Data, o processamento de dados é dividido em duas abordagens princi-pais: processamento em lotes (batch), que também inclui o processamento de micro-lotes (micro-batch), e o processamento em tempo real (streaming).

(19)

2.2.1 Processamento em Lotes

O modelo de processamento em lote pode ser dividido em lotes e micro-lotes. O primeiro deles, em lotes, é normalmente usado para aplicações sem requisitos elevados em termos de tempo de resposta (CHEN; MAO; LIU, 2014). A análise de grandes conjuntos de dados estáticos, que são coletados em períodos anteriores, é feita com o processamento em lotes. No entanto, esta técnica tem grande latência, enquanto várias aplicações reque-rem processamento em tempo real, com respostas em microsegundos (RYCHLY et al., 2014). Entretanto, este modelo de processamento também pode ser utilizada para realizar o processamento próximo ao tempo real ao utilizar o que pode ser chamado de micro-lotes (LOPEZ; LOBATO; DUARTE, 2016).

O micro-lotes trata o fluxo como uma sequência de blocos de dados menores. A entrada é agrupada em blocos de dados e é entregue ao sistema de processamento em lote para ser processado em pequenos intervalos de tempo. Entretanto, no processamento em lotes e micro-lotes, algumas funções, como agregações e divisões de dados são difíceis de implementar, porque o sistema lida com um lote inteiro ao mesmo tempo.

De modo complementar, pode-se citar o modelo de programação paralelo e dis-tribuído MapReduce. Este tornou-se o modelo dominante no processamento em lotes e sua finalidade busca dividir o conjunto de dados a ser analisado em pequenos pedaços. Em seguida, esses pedaços são processados em paralelo e de forma distribuída para gerar resultados intermediários, onde é aplicado uma função de mapeamento que gera um con-juntos de dados intermediários, em formato de chave/valor. Estes dados intermediários são submetidos então a uma função de redução, que emite uma nova chave/valor. Este modelo agenda recursos próximos ao local dos dados, o que evita a sobrecarga de comu-nicação da transmissão de dados. O modelo MapReduce é simples e amplamente aplicado em bioinformática, mineração de dados e aprendizagem de máquina (HU et al., 2014).

2.2.2 Processamento em Tempo Real

Os sistemas de processamento em tempo real (streaming) operam em fluxos de dados contínuos: por exemplo, fluxos em páginas da web, solicitação de usuário/fluxos de consulta, eventos de monitoramento, notificações, etc. A importância dos sistemas de processamento em tempo real aumenta à medida que as aplicações impõem restrições de tempo mais rígidas em uma determinada propagação do evento ao longo do pipeline

(20)

(KAMBATLA et al., 2014).

O processamento em tempo real Big Data possui alto volume, alta velocidade e tipos de dados complexos. Portanto, as plataformas em tempo real, como o SQLstream, Storm e StreamCloud (GULISANO et al., 2012), foram projetadas especialmente para análise de dados de fluxo em tempo real.

O processamento em tempo real exige uma latência de resposta muito baixa. Por-tanto, não há muita acumulação de dados na dimensão temporal para o processamento (STONEBRAKER; ÇETINTEMEL; ZDONIK, 2005). Em geral, Big Data pode ser co-letado e armazenado em um ambiente distribuído, e não em um centro de dados (CHEN; ZHANG, 2014).

Os métodos “tradicionais” de processamento de dados, envolvendo trabalhos Ma-pReduce, não são completamente adequados para casos de uso em tempo real envolvendo dados com disponibilidade não determinística. O processamento em tempo real permite que os dados sejam processados logo que estejam disponíveis, sem a necessidade de um sistema de armazenamento, como o HDFS (SAMOSIR; INDRAWAN-SANTIAGO; HAGHIGHI, 2016).

2.3 Infraestrutura de Computação em Névoa e de Borda para Aplicações Big Data

A computação em névoa, também conhecida como FOG Computing, representa um paradigma de computação distribuída que atua como uma camada intermediária entre os datacenters da nuvem e os dispositivos/sensores de Internet das Coisas (Internet of Things – IoT). Ela oferece recursos de computação, rede e armazenamento para que os serviços baseados em nuvem possam ser oferecidos mais perto dos dispositivos/sensores de IoT (DASTJERDI et al., 2016).

Um ambiente de computação em névoa é composto por componentes de rede tradi-cionais, isto é, roteadores, switches, set top boxes, servidores proxy, estações base, dentre outros e podem ser colocados na proximidade de dispositivos/sensores IoT. Esses com-ponentes são fornecidos com diversos recursos de computação, armazenamento, rede. A computação em névoa pode melhorar a latência de resposta e consumo de energia (MAH-MUD; KOTAGIRI; BUYYA, 2018).

A computação de borda, também conhecida como EDGE Computing, permite o processamento de dados na borda da rede. A rede de borda consiste basicamente de dispositivos finais (por exemplo, telefone celular, objetos inteligentes, dentre outros),

(21)

dis-positivos de borda (por exemplo, roteadores de borda, settop boxes, bridges, estações bases, pontos de acesso sem fio, dentre outros) ou servidores de borda. Estes compo-nentes devem ser equipados com os recursos necessários para suportar a computação de borda. Como um paradigma de computação localizada, a computação de borda fornece respostas mais rápidas às solicitações de serviços computacionais e, na maioria das vezes, envia menos dados para as camadas de aplicações em nuvem (MAHMUD; KOTAGIRI; BUYYA, 2018).

A computação de borda não se conecta a serviços baseados em nuvem (como IaaS, PaaS, SaaS, dentre outros), mas se concentra próximo aos dispositivos finais (SHI et al., 2016). Ao contrário da computação de borda, a computação em névoa pode estender os serviços baseados em nuvem (MAHMUD; KOTAGIRI; BUYYA, 2018).

Figura 2.1: Arquiteturas De Computação

Fonte: (MAHMUD; KOTAGIRI; BUYYA, 2018) com adaptações

A Figura 2.1 demonstra a arquitetura de soluções de computação de borda e com-putação em névoa em relação à arquitetura tradicional de soluções baseados em nuvem.

(22)

2.3.1 Considerações do consumo energético

Os nós de computação em névoa precisam lidar com um grande número de solici-tações de serviço provenientes de dispositivos/sensores finais simultaneamente. Uma das soluções triviais é implantar os nós no ambiente de acordo com a demanda. No entanto, esta abordagem aumentará o número de nodos ativos computacionalmente, afetando o consumo total de energia do sistema. Portanto, ao responder a solicitações de grande número de serviços, será necessário um gerenciamento de energia adequado na rede de computação em névoa. Porém, a otimização do uso de energia dentro da rede de compu-tação em névoa ainda está em aberto.

Além disso, para gerenciar a energia no ambiente de névoa, a consolidação de nós pela migração de tarefas de um nó para outro pode ser eficaz em alguns cenários. Alguns trabalhos estudam formas de diminuir o consumo de energia dentro da rede de compu-tação em névoa, dentre eles, pode-se citar o trabalho dos autores (MISRA; SIMMHAN; WARRIOR, 2015) que estudaram o trade-off entre o consumo de energia e o atraso em um sistema de computação em névoa. Os autores modelaram as funções de consumo e atraso de energia para o sistema de névoa e formalizaram o problema de alocar cargas de trabalho entre a névoa e a nuvem. Os resultados mostram que a computação em névoa pode reduzir significativamente a latência de comunicação mas implica em um consumo de energia ligeiramente maior.

2.4 Considerações finais

Esse capítulo apresentou os conceitos de Big Data necessários para a compreensão desse trabalho. Além disso, foram apresentados os modelos de processamento Big Data em lotes (batch) e em tempo real (streaming) que serão explorados no decorrer deste trabalho. A computação em névoa e de borda se apresentam como uma tendência para diminuir a latência e o consumo de energia de aplicações Big Data, pois propõem o uso de dispositivos que têm como característica principal o uso de hardware com baixo consumo de energia. O próximo capítulo busca compreender a construção e o funcionamento dos frameworksBig Data Hadoop, Spark e Flink.

(23)

3 FRAMEWORKS BIG DATA

Neste capítulo, serão apresentados o modelo de processamento paralelo e distri-buído MapReduce e suas implementações sobre os frameworks Apache Hadoop, Spark, bem como o framework Flink.

3.1 O Modelo MapReduce

O MapReduce (DEAN; GHEMAWAT, 2008) é um modelo de programação sim-plificado para o processamento de um grande conjunto de dados. Inicialmente proposto pelo Google para aplicações intensivas em dados. O modelo MapReduce foi desenvolvido com base no GFS (GHEMAWAT; GOBIOFF; LEUNG, 2003).

O programador deve especificar apenas duas funções: a função de map (mapeador) e a função de reduce (redutor) comumente utilizada na programação funcional. O mape-ador transforma os dados da entrada em pares chave/valor e gera pares intermediários chave/valor. O redutor combina todos os pares associados à mesma chave (intermediária) e, em seguida, gera uma nova chave/valor para a saída de dados. (HASHEM et al., 2015). A função map envolve 3 subtarefas (SUBRAMANIYASWAMY et al., 2015), sendo elas:

• Mapper que envolve o mapeamento de dados; • Combiner que combina os dados em memória;

• Partitioner que divide os dados em pequenas partições.

A função Reduce envolve 2 subtarefas (SUBRAMANIYASWAMY et al., 2015), sendo elas:

• Joiner que mantém a união dos resultados intermédios dos trabalhos do map; • Reducer que é usada para realizar a agregação.

A função de map é aplicada a cada entrada (key1, value1), onde o domínio de entrada é diferente da lista de pares de saída gerada (key2, value2). Os elementos da lista (key2, value2)são agrupados por uma chave. Depois de agrupar, a lista (key2, value2) é dividida em várias listas [key2, list (value2)] e a função de reduce é aplicada a cada [key2, list (value2)]para gerar uma lista de resultados final (key3, value3) (HASHEM et al., 2015).

(24)

3.2 Apache Hadoop

O Hadoop foi inicialmente introduzido em 2007 como uma implementação de código aberto para o processamento MapReduce ligado a um sistema de arquivos dis-tribuídos (WHITE, 2012), mas desde então evoluiu para uma vasta rede de projetos re-lacionados a cada etapa de um grande fluxo de dados, incluindo a coleta de dados, ar-mazenamento, processamento e etc. Atualmente, o Hadoop consiste em quatro módulos principais (FOUNDATION, 2018c):

• MapReduce Data processing engine. Um trabalho MapReduce consiste 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 projetado para ar-mazenar 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 ao nó 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 man-tendo 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 metadados (LANDSET et al., 2015);

• YARN (“Yet Another Resource Negotiator”) (VAVILAPALLI et al., 2013) Com o YARN, se um aplicativo deseja executar, seu cliente deve solicitar 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 gerenci-ador de nó lança um contêiner que executa a aplicação. As responsabilidades de gerenciamento do YARN são divididas entre o gerenciador de recursos, o processo de gerenciamento de aplicativo (ApplicationMaster) e o servidor de logs (que ar-mazena o histórico dos aplicativos), enquanto as responsabilidades d e gerenciar o os recursos do nó são tratadas pelo gerenciador de nó. O YARN é capaz de funci-onar em clusters maiores, mais do que duplicar a quantidade de trabalhos e tarefas

(25)

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 ne-cessários aos outros módulos Hadoop. Além disso, possui bibliotecas compartilha-das nativas que incluem implementaçõ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, au-tenticaçã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).

Por fim, o ecossistema Hadoop é composto por uma vasta gama de projetos cons-truídos utilizando os módulos principais descritos acima. Esses projetos foram projetados para auxiliar pesquisadores e profissionais 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). Em seguida, serão apresentados as limitações do Apache Hadoop.

3.2.1 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 mapeadores 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 inicializados. Às vezes, os trabalhos MapReducesã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 (configuração do próximo trabalho MapReduce antes do final anterior) foram propostas. No entanto, essas abordagens introduzem níveis adicionais de complexidade no código-fonte (SINGH; REDDY, 2015).

(26)

3.3 Apache Spark

Spark é um paradigma para o processamento de Big Data desenvolvido por pesqui-sadores da Universidade da Califórnia em Berkeley (SINGH; REDDY, 2015). A principal característica do Spark que o torna diferente do Hadoop é a capacidade de executar com-putaçõ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.

3.3.1 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 dados distribuídos resilientes (Resilient Distributed Dataset – RDD), que é uma estrutura de dados imutável determi-ní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 sufi-cientes para que ele possa ser reavaliado com base em sua linhagem e RDDs de-pendentes, que são os arquivos de dados de entrada no HDFS no pior dos casos (ZHANG et al., 2015).

A capacidade de persistência de dados na memória torna o RDD adequado para muitas aplicações de análise de dados, especialmente algoritmos 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).

(27)

3.3.2 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 DataFra-mes, que permitem 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, tabela 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 esquema leve de tolerância a falhas. Especificamente, um RDD registra as transformações que foram feitas 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. Como RDD é atualizado por transformações de grão grosso, geralmente requer muito menos espaço e esforço para fazer backup das informaçõ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 armazena-mento estável, o que garante a correção do modelo de tolerância a falhas e a

(28)

ade-quação do modelo de organização baseado em blocos. No entanto, no armazena-mento tradicional de dados, os dados estão chegando dinamicamente e a alocação de dados não pode ser determinada 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).

3.3.3 Escalonamento de Jobs

Os jobs em Spark são organizados em um DAG, que captura dependências de trabalho. O RDD usa materialização preguiçosa, ou seja, um RDD não é computado 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 dependê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 é formada por uma sequência de trabalhos em uma par-tição, como o map e os trabalhos de filtragem. Tarefa é a unidade de agendamento no sistema, que elimina a materialização dos estados intermediários e permite uma estratégia de agendamento fino (ZAHARIA et al., 2012).

3.3.4 Módulos extras

Além do núcleo do Spark, alguns projetos adicionais foram desenvolvidos para complementar a funcionalidade fornecida pelo núcleo. Todos esses subprojetos (construí-dos no topo do núcleo) são descritos a seguir:

• Spark SQL: apresenta DataFrames, que é uma nova estrutura de dados para dados estruturados e semi-estruturados. O DataFrame oferece a possibilidade de introdu-zir 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 rapidamente. Este design per-mite que o mesmo conjunto de código para processamento 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 prin-cipais funcionalidades, incluem: classificação, regressão, agrupamento, filtragem colaborativa, otimização e redução de dimensionalidade. Esta biblioteca foi espe-cialmente projetada para simplificar pipelines ML em ambientes de grande escala. Nas versões mais recentes do Spark, a biblioteca MLlib foi dividida em dois pa-cotes, MLlib, compilação sobre os RDDs e ML, compilação sobre 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 juntar 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).

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

(30)

a falhas do RDD baseadas em linhagens do Spark, com algumas 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, reducti-onByWindowe countByWindow). Os RDDs de intervalos históricos podem ser mesclados automaticamente com o RDD recém-gerado à medida que novos fluxos chegam. Os da-dos em tempo real são replicada-dos em dois nós de trabalho para garantir a durabilidade da-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. O determinismo e a linhagem de níveis de partição de D-streams possibilitam 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 recalculado 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 distri-buindo 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 posteriores. A configu-ração de cada micro-lote pode demorar mais do que a análise em tempo real (LOPEZ; LOBATO; DUARTE, 2016).

3.4 Apache Flink

Flink (FOUNDATION, 2018b) foi desenvolvido na Universidade Técnica de Ber-lim sob o nome Stratosphere (ALEXANDROV et al., 2014). Oferece capacidade para o processamento em tempo real e em lotes, permitindo 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 completamente independente do ecossistema

(31)

Hadoop. 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 automaticamente a melhor estra-té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 iterativo, 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).

3.4.1 Arquitetura do Flink

Um cluster Flink compreende três tipos de processos: o cliente, o Gerenciador 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 envia o Job Manager. Esta fase de transformação também examina os tipos de dados (esquema dos dados trocados entre operadores) e cria serializadores ou outros tipos/esquemas de código específico. Os pro-gramas DataSet também passam por uma fase de otimização de consulta baseada em custos, semelhante às otimizações físicas realizadas por otimizadores de consultas relaci-onais (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 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 fluxos de dados e relatórios sobre o status deles no JobManager. O TaskManager mantém pools de buffer para buffer ou para materializar 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

(32)

por subtarefa produzida). Os fluxos de dados entre os produtores e os consumidores são distribuí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 produzido por um operador e que podem ser consumidos por um ou mais operadores (CARBONE et al., 2015).

O Flink oferece uma execução confiável com rigorosas garantias de consistên-cia 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 efe-tivamente essas garantias são que as fontes de dados são persistentes. O mecanismo de verificação do Apache Flink baseia-se na noção de snapshots distribuídos e consistentes para obter garantias de processamento 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 separam 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 denominada processamento em lotes) e a API DataStream para processamento de fluxos de dados potencialmente ilimitados (geralmente referidos como processamento em tempo real) (CARBONE et al., 2015).

3.4.2 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 atua-lizaçã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 deter-minado 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 exemplo, 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

(33)

(CARBONE et al., 2015). 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 janelas. O Flink incorpora ja-nelas 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 fornecem 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 conti-nuamente na memória como parte do estado do operador (CARBONE et al., 2015). O mecanismo de controle do Flink garante que qualquer estado registrado 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 paralela baseados em iterações estruturadas em dados finitos. O modelo de execução do Flink já abrange iterações assín-cronas, quando nenhum mecanismo de controle de iteração está habilitado (CARBONE et al., 2015).

3.4.3 Processamento Em Lotes No Flink

Um conjunto de dados delimitados é um caso especial de um fluxo de dados ilimi-tado. 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 processamento em lotes deve ser total-mente coberto pelos recursos do Flink. No entanto, a sintaxe (ou seja, a API para compu-taçã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 limitados são passíveis de otimizações adicionais, mantendo a tolerância a falhas 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 computação em tempo real (CARBONE et al., 2015);

(34)

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

3.4.4 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 utili-tá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 aprendizagem 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 proces-samento em tempo real e em lotes que pode ser incorporado 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 (GARCÍA-GIL et al., 2017).

(35)

3.5 Softwares Auxiliares 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 caracte-rísticas.

3.5.1 Kafka

Kafka combina os benefícios dos agregadores tradicionais de registros e sistemas de mensagens. Por um lado, o Kafka é distribuído e escalá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).

3.5.1.1 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 arma-zenadas em um conjunto de servidores chamados brokers. Um consumidor pode assinar um ou mais tópicos 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 clusterKafka 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).

3.5.1.2 Características

As principais características do Kafka são:

1. Armazenamento simples: o Kafka tem um layout de armazenamento muito sim-ples. Cada partição de um tópico corresponde a um log lógico. Fisicamente, um logé implementado como um conjunto de segmento de arquivos com aproximada-mente o mesmo tamanho. Toda vez que um produtor publica uma mensagem em uma partição, o broker simplesmente 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 con-sumiu não são mantidas pelo broker, mas pelo próprio consumidor (KREPS et al., 2011);

4. Coordenação Distribuída: Kafka tem o conceito de grupos de consumidores (con-sumer groups). Cada grupo de consumidores consiste em um ou mais consumido-res 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 armazenadas nos brokers entre os consumidores, sem in-troduzir 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) detec-tar 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 consumido de cada partição (KREPS et al., 2011);

5. Garantias de Entrega: Em geral, o Kafka garante apenas a semântica pelo menos uma vez. Na maioria das vezes, uma mensagem é entregue exatamente uma vez para cada grupo de consumidores. O Kafka garante que as mensagens de uma única partição sejam entregues a um consumidor na ordem correta. 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 executará um processo de recuperação para remover as mensagens com CRCs inconsistentes. Se um broker ficar inativo, qual-quer mensagem armazenada nele ainda não consumida ficará indisponível (KREPS et al., 2011).

3.5.2 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 ZooKe-eper alcança throughput de centenas de milhares de operações por segundo para cargas

(37)

de trabalho de leitura usando leituras rápidas com relógios, ambos servidos por réplicas locais (HUNT et al., 2010).

3.5.2.1 Arquitetura

O cliente (client) denota o usuário do serviço ZooKeeper, o servidor (server) de-nota um processo que fornece o serviço ZooKeeper e o znode dede-nota 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 ZooKeeper e obtêm um identificador de sessão pelo qual eles emitem solicitações (HUNT et al., 2010).

3.5.2.2 Características

As principais características do ZooKeeper são:

1. Modelo de dados: O modelo de dados do ZooKeeper é essencialmente 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 namespace de aplicativos diferentes e para definir direitos de acesso a essas subárvores. Os znodes mapeiam para abstrações os aplicativos do cliente, normalmente correspondendo a metadados usados para propósitos de coordenação. Os znodes também possuem metadados associados a carimbos de data e hora e contadores de versão, que permi-tem 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 ZooKeeper 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 lineari-záveis; fila FIFO onde todos os pedidos de um determinado cliente são executados na ordem em que foram enviados (HUNT et al., 2010).

(38)

3.6 Considerações finais

Esse capítulo apresentou os principais frameworks para Big Data e para cada um deles foram apresentados as características (organização dos seus componentes, modelo de dados, modelo de processamento) que os definem. Também foram apresentados os softwares Kafka e Zookeeper, utilizados para suporte à computação distribuída. Os fra-meworks apresentados neste capítulo serão utilizados e avaliados no decorrer deste traba-lho. No próximo capítulo, serão apresentados os trabalhos relacionados.

(39)

4 TRABALHOS RELACIONADOS

Esse capítulo apresenta o estado da arte, os problemas e as analises relativas ao uso de soluções eficientes em termos de consumo de energia para o processamento de aplicações Big Data.

A primeira seção trata de infraestruturas de computação em névoa e de borda. A segunda seção trata de trabalhos que fazem uso de processadores ARM, em vez de pro-cessadores x86, para o processamento de aplicações Big Data. A terceira seção trata de trabalhos que fazem o uso de sistemas heterogêneos, ou seja, usam FGPAs em combi-nação com processadores ARM/x86 para melhorar o desempenho e eficiência energética das aplicações Big Data.

4.1 Infraestrutura em Computação em Névoa (e de Borda)

Nesta seção, serão analisados três artigos sobre infraestrutura em computação em Névoa (e de borda).

1. A Survey of Fog Computing: Concepts, Applications and Issues (YI; LI; LI, 2015): A computação em névoa pode fornecer recursos elásticos para o sistema de processamento de Big Data sem sofrer com a desvantagem da nuvem (alta latên-cia). Na computação em nuvem, o evento ou os dados serão transmitidos para o datacenter dentro da rede principal e o resultado será enviado de volta ao usuário final após uma série de processamentos. Uma federação de névoa e nuvem pode manipular a aquisição, agregação e pré-processamento de Big Data, reduzindo o transporte e o armazenamento de dados, equilibrando o poder de computação no processamento de dados. Por exemplo, em um sistema de monitoramento ambien-tal em larga escala, os dados locais e regionais podem ser agregados e extraídos em nós de névoa, fornecendo feedback especialmente para casos de emergência, como por exemplo alertas de poluição tóxica. Enquanto a análise detalhada e minuciosa pode ser agendada para processamento no lado da nuvem;

2. System Architecture and Deployment Scenarios for SESAME: Small cEllS coo-dinAtion for Multi-tenancy and Edge services (GIANNOULAKIS et al., 2016): O projeto SESAME propõe uma infraestrutura de execução virtualizada em micro-escala na forma de um Light Data Center(Light DC) para melhorar os recursos de