• Nenhum resultado encontrado

MapReduce em Ambientes Voláteis e Heterogêneos

N/A
N/A
Protected

Academic year: 2021

Share "MapReduce em Ambientes Voláteis e Heterogêneos"

Copied!
35
0
0

Texto

(1)

WAGNER KOLBERG

MapReduce em Ambientes Voláteis e

Heterogêneos

Trabalho Individual I TI-I

Prof. Dr. Cláudio Fernando Resin Geyer Orientador

(2)

SUMÁRIO

LISTA DE ABREVIATURAS E SIGLAS . . . . 4

LISTA DE FIGURAS . . . . 5 LISTA DE TABELAS . . . . 6 RESUMO . . . . 7 ABSTRACT . . . . 8 1 INTRODUÇÃO . . . . 9 1.1 Motivação . . . 9 1.2 Objetivo . . . 10 1.3 Organização do Texto . . . 10

2 AMBIENTES DE COMPUTAÇÃO DISTRIBUíDA . . . . 11

2.1 Clusters . . . 11

2.2 Computação em Grade . . . 11

2.3 Desktop Grid . . . 12

2.3.1 Enterprise Desktop Grid . . . 12

2.4 Computação Voluntária . . . 12

3 MAPREDUCE . . . . 13

3.1 Arquitetura do Framework . . . 14

3.2 Etapas e Otimizações Internas . . . 15

3.3 GFS . . . 17 3.4 Backup Tasks . . . 18 3.5 Aplicações típicas . . . 18 3.6 Frameworks MapReduce . . . 20 3.6.1 Hadoop . . . 20 3.6.2 Phoenix . . . 22 3.6.3 MARS . . . 23 3.6.4 Cloud . . . 23 4 TRABALHOS RELACIONADOS . . . . 26

4.1 MOON: MapReduce On Opportunistic eNvironments . . . 26

4.2 Towards MapReduce for Desktop Grid Computing . . . 27

4.3 Volunteer Cloud Computing: MapReduce over the Internet . . . 27 4.4 Decoupling Storage and Computation in Hadoop with SuperDataNodes 29

(3)
(4)

LISTA DE ABREVIATURAS E SIGLAS

API Application Programming Interface DFS Distributed File System

GFS Google File System GPU Graphics Processing Unit HDFS Hadoop Distributed File System LHC Large Hadron Collider

MOON MapReduce On Opportunistic eNvironments P2P Peer to peer

(5)

3.6 Arquitetura do HDFS . . . 22

3.7 Fluxo de execução no Phoenix . . . 22

3.8 MARS GPU . . . 23

3.9 MARS GPU+CPU . . . 23

3.10 MARS Hadoop . . . 24

3.11 Arquitetura do Cloud MapReduce . . . 25

3.12 Arquitetura do Azure MapReduce . . . 25

4.1 Processo de decisão para armazenar dados no MOON . . . 27

4.2 Visão geral do sistema usando o BitDew . . . 27

4.3 Processo de mapeamento no BOINC-MR . . . 28

4.4 Processo de redução no BOINC-MR . . . 29

4.5 Esquema de um SuperDataNode . . . 30

(6)

LISTA DE TABELAS

(7)

desenvolver software para ambientes distribuídos é uma tarefa complexa, pois envolve uma série de conceitos e problemas que devem ser considerados pelos programadores; como concorrência, tolerância a falhas, distribuição de dados e balanceamento de carga. A fim de facilitar este processo, a multinacional Google desenvolveu o MapReduce, um modelo de programação paralela para processamento distribuído de grandes volumes de dados.

Devido ao sucesso do MapReduce em clusters homogêneos, diferentes plataformas passaram a ser estudadas como ambiente de execução para o modelo. Uma recente linha de pesquisa busca tornar viável a execução do MapReduce em ambientes voláteis, onde os recursos computacionais podem ficar indisponíveis a qualquer momento. Este trabalho tem como objetivo estudar, através de pesquisas existentes, o comportamento do Map-Reduce em ambientes voláteis e heterogêneos, a fim de descobrir e analisar possíveis melhorias na execução do modelo nestas condições.

(8)

ABSTRACT

MapReduce on Volatile and Heterogeneous Environments

With the evolution of information systems and the increasing amount of services avail-able to its users, also grows the volume of data that needs to be processed by computer systems. To compute this large amount of information is in a reasonable time frame, it is necessary to explore paradigms of parallel programming and distributed processing. However, developing software for distributed environments is a complex task because it involves a series of concepts and problems that must be considered by the developers, such as: concurrency, fault tolerance, data distribution and load balancing. To facilitate this process, the multinational Google developed MapReduce, a parallel programming model for distributed processing of large data sets.

Due to the success of MapReduce in homogeneous clusters, different platforms have been studied as execution environment for the model. A recent research line seeks to improve the implementation of MapReduce in volatile environments, where computing resources may be unavailable at any time. This work aims to study, through existing research, the behavior of MapReduce in volatile and heterogeneous environments in order to discover and examine possible improvements in the implementation of the model under these conditions.

(9)

1

INTRODUÇÃO

Com a evolução dos sistemas de informação e o aumento da quantidade de serviços disponibilizados a seus usuários, cresce também o volume de dados que precisa ser pro-cessado pelos sistemas computacionais. Como exemplos de computação intensiva de dados, (WHITE, 2009) aponta: a bolsa de valores de Nova Iorque, que gera um terabyte de dados por dia; o Facebook, que hospeda 10 bilhões de fotos (totalizando um petabyte de armazenamento); e o Large Hadron Collider (LHC), que deve produzir cerca de 15 petabytes de dados por ano. Empresas na área de busca, e.g. Google e Yahoo, também são ótimos exemplos, pois indexam trilhões de páginas da internet, e atendem bilhões de requisições diariamente.

De acordo com a IDC (International Data Corporation), a quantidade de informação criada, capturada ou replicada em meio digital no ano de 2009 apresentou um cresci-mento de 62%, alcançando aproximadamente 800.000 petabytes. Em 2020 o crescicresci-mento esperado deve alcançar os 35 zetabytes, equivalente a 35 milhões de petabytes (GANTZ; REINSEL, 2010).

Para que a computação desta grande quantidade de informações seja realizada em tempo viável, cada vez mais faz-se necessária a exploração de paradigmas de progra-mação paralela e processamento distribuído. Porém, desenvolver software para ambientes distribuídos é uma tarefa complexa, pois envolve uma série de conceitos e problemas que devem ser considerados pelos programadores; como concorrência, tolerância a falhas, distribuição de dados e balanceamento de carga.

A fim de facilitar este processo, a multinacional Google desenvolveu o MapReduce, um modelo de programação paralela para processamento distribuído de grandes volumes de dados (DEAN; GHEMAWAT, 2008).

Além do framework da Google, diversas implementações para o MapReduce foram desenvolvidas, dentre as quais, a mais conhecida e divulgada está inserida no projeto Hadoop(HADOOP, 2010a), mantido pela Apache Software Foundation. Um aspecto im-portante desta implementação é seu escalonador de tarefas, o qual supõe que o ambiente distribuído é homogêneo. Assim, quando submetido à execução em ambientes heterogê-neos, o Hadoop MapReduce apresenta um comportamento inadequado, prejudicando seu desempenho (KONWINSKI, 2009; ZAHARIA et al., 2008).

1.1

Motivação

Há muito constatou-se que as estações de trabalho apresentam longos períodos de ociosidade, principalmente durante a noite e finais de semana, quando ficam aproximada-mente 95% do tempo disponíveis (FOSTER; KESSELMAN, 2003), utilizando, ao longo do tempo, apenas 30% de sua capacidade de processamento (MUTKA; LIVNY, 1988).

(10)

10

Pesquisadores passaram, então, a estudar o uso de estações de trabalho como recursos de processamento distribuído, em alternativa aos clusters de dedicação exclusiva, que ap-resentam um custo muito mais elevado. Este tipo de ambiente é conhecido por Desktop Grid(FOSTER; KESSELMAN, 2003), e tem como importante características a volatili-dade e heterogeneivolatili-dade de seus recursos.

1.2

Objetivo

Este trabalho tem como objetivo estudar o comportamento do MapReduce em ambi-entes voláteis e heterogêneos, a fim de descobrir e analisar possíveis melhorias na exe-cução do modelo nestas condições. Dentre as vantagens que estas futuras modificações podem apresentar é possível citar: melhor aproveitamento de recursos computacionais; redução no consumo de energia do ambiente MapReduce distribuído; e ganho de desem-penho.

1.3

Organização do Texto

O restante deste trabalho está estruturado conforme a descrição a seguir. O capítulo 2 descreve brevemente os ambientes de processamento distribuído sobre os quais o estudo é realizado. No capítulo 3 é introduzido o funcionamento do modelo MapReduce e suas implementações. Os trabalhos relacionados diretamente com o foco deste estudo são apresentados no capítulo 4. Por fim, as considerações finais do trabalho são expostas no capítulo 5.

(11)

2

AMBIENTES DE COMPUTAÇÃO DISTRIBUÍDA

Com o avanço tecnológico das últimas décadas, os computadores passaram a ficar cada vez mais populares, e consequentemente seu custo foi reduzido drasticamente, per-mitindo a multiplicação desses dispositivos tanto em ambientes empresariais, quanto domésticos. Este crescimento, aliado a avanços em áreas como armazenamento e comu-nicação de informações, possibilitou a colaboração entre recursos computacionais para a solução de problemas. Desta distribuição do trabalho que antes era realizado por uma única máquina, surgiu o paradigma de processamento distribuído (TOTH, 2008). Esta linha de pesquisa envolve vários outros conceitos — relacionados com infraestrutura, téc-nicas de distribuição e balanceamento de carga, etc. — que serão comentados a seguir.

2.1

Clusters

Um cluster pode ser definido como um conjunto de máquinas, administrado e uti-lizado por um único indivíduo, com o objetivo de solucionar problemas que levariam muito tempo em uma única estação de trabalho (TOTH, 2008).

Dentre algumas características frequentemente observadas em um cluster, é possível destacar:

• O cluster é constituído por máquinas de prateleira, apresentando baixo custo se comparado a supercomputadores.

• Todos os nós estão geograficamente próximos, geralmente em um mesmo prédio. • As conexões entre as máquinas possuem altas taxas de transferência.

• As máquinas são homogêneas, i.e. possuem capacidades de processamento simi-lares.

2.2

Computação em Grade

Uma Grade Computacional (do inglês, Grid) consiste de um sistema que coordena recursos de maneira não centralizada, utilizando protocolos e interfaces padronizadas, abertas, e de propósitos gerais, a fim de prover uma variedade de serviços complexos de acordo com a demanda de seus usuários (FOSTER; KESSELMAN, 2003).

Ainda de acordo com Foster, o termo “Grid” é utilizado em analogia às redes de energia elétrica (chamadas de power grids em inglês), as quais proveem acesso difuso à eletricidade (FOSTER; KESSELMAN, 2003). Assim deveria ser nas grades, com o

(12)

12

compartilhamento flexível de recursos computacionais, em forma de ferramentas colabo-rativas que poderiam ser acessadas de qualquer ponto.

2.3

Desktop Grid

Desktop Gridssão grades computacionais que, em contraste aos clusters, apresentam as seguintes propriedades:

• Os nós da grade são tipicamente heterogêneos.

• As taxas de transferência das conexões também podem variar, podendo apresentar ligações extremamente lentas.

• Os nós não estão necessariamente centralizados em um mesmo local, e podem estar dispersos por todo o mundo, conectando-se através da Internet.

• Os nós são voláteis, i.e. as máquinas podem parar de responder (ou voltar a fazê-lo) a qualquer momento.

2.3.1 Enterprise Desktop Grid

As Enterprise Desktop Grids (KONDO et al., 2007), ou Desktop Grids Empresariais, são restritas à rede local de uma única corporação. Esta restrição normalmente implica em uma rede mais rápida, uma vez que é comum observar este tipo de grade com conexões de 100Mb/s e 1Gb/s.

2.4

Computação Voluntária

Os ambientes de Computação Voluntária agregam centenas de milhares de recur-sos disponibilizados por seus usuários, que encontram-se espalhados geograficamente e conectados através da Internet. Este poder computacional é aproveitado para a execução de aplicativos e para a resolução de problemas que levariam muito tempo para serem re-solvidos em ambientes de menor escala. Como exemplos de plataformas de computação voluntária é possível citar: BOINC (ANDERSON, 2004), Condor (THAIN; TANNEN-BAUM; LIVNY, 2003), XtremWeb (FEDAK et al., 2001), dentre outros.

Dentre as plataformas em uso atualmente, o BOINC (Berkley Open Infrastructure for Networking Computing) pode ser considerada a infra-estrutura mais conhecida e utilizada. Nela são encontrados diversos projetos como: SETI@Home (KORPELA et al., 2001), que analisa ondas de rádio à procura de inteligência extra-terrestre; modelos de previsão do tempo, como o ClimatePrediction; e projetos humanitários que buscam curas para doenças.

Estes ambientes possuem altos índices de volatilidade, e usuários com perfis muito variados. Outro fator importante é a conexão, que dá-se através da Internet. Neste caso a banda e latência das conexões diferem de forma importante, e podem ser limitadas por valores muito baixos em alguns casos.

(13)

3

MAPREDUCE

O MapReduce, criado pela Google, é um modelo de programação paralela para pro-cessamento largamente distribuído de grandes volumes de dados. Seu objetivo é facilitar a programação de aplicativos distribuídos com este perfil. Para tal, o modelo inspira-se nas primitivas Map e Reduce presentes em diversas linguagens funcionais, como Lisp e Haskell, por exemplo. Esta abordagem foi adotada pois verificou-se que, em muitos ca-sos, era necessário mapear fragmentos dos dados de entrada a uma chave identificadora, e então processar todos os fragmentos que compartilhassem a mesma chave (DEAN; GHE-MAWAT, 2008).

Assim, a tarefa principal do programador é implementar estas duas funções, indi-cando como o mapeamento e redução dos dados serão computados. Todo o trabalho de distribuição do sistema — incluindo problemas de comunicação, tolerância a falhas, con-corrência, etc. — é abstraído, e fica a cargo do próprio framework. Durante a execução, as funções recebem e emitem dados no formato de pares chave/valor. Como o tipo destes elementos dependem da aplicação que será executada, cabe ao desenvolvedor, também, definir estas propriedades.

Um exemplo de uso do MapReduce é demonstrado na Figura 3.1, a qual contém uma aplicação cujo objetivo é contar a quantidade de ocorrências de cada palavra em um documento. No pseudocódigo, cada chamada da função map recebe como valor uma linha de texto do documento, e como chave o número desta linha. Para cada palavra encontrada na linha recebida, a função emite um par chave/valor, onde a chave é a palavra em si, e o valor é a constante 1 (um). A função reduce, por sua vez, recebe como entrada uma palavra (chave), e um iterador para todos os valores emitidos pela função map, associados com a palavra em questão. Todos os valores são então somados e um par chave/valor, contendo a palavra e seu total de ocorrências, é emitido.

Para auxiliar no entendimento, a Figura 3.2 ilustra o fluxo de execução e dados para esta aplicação. Como entrada é utilizado um arquivo texto com apenas duas linhas, cujos conteúdos são “primeira linha” e “segunda linha”.

Para cada linha de texto do arquivo de entrada é feita uma chamada à função map. Logo, como o arquivo possui duas linhas, duas chamadas são realizadas. Em seguida, cada função map gera n pares chave/valor intermediários, onde, nesta aplicação, n é igual à quantidade de palavras contidas na linha de texto recebida pela função. Como cada linha possui duas palavras, um total de quatro pares intermediários são criados. Na fase de re-dução, todos os pares intermediários que estão associados a uma mesma chave (neste caso, uma palavra do documento) são passados para uma chamada da função reduce. Portanto, como existem três palavras distintas (“primeira”, “linha” e “segunda”), três re-duções são executadas. Por fim, a execução da função reduce retorna a soma de todos os valores presentes na lista de pares recebidos. Os resultados finais são armazenados no

(14)

14 1 f u n c t i o n map ( I n t e g e r c h a v e , S t r i n g v a l o r ) : 2 / ∗ c h a v e : numero da l i n h a no a r q u i v o . ∗ / 3 / ∗ v a l o r : t e x t o da l i n h a c o r r e s p o n d e n t e . ∗ / 4 l i s t a D e P a l a v r a s = s p l i t ( v a l o r ) 5 f o r e a c h p a l a v r a i n l i s t a D e P a l a v r a s : 6 e m i t ( p a l a v r a , 1 ) 7 end f o r 8 end f u n c t i o n 9 10 f u n c t i o n r e d u c e ( S t r i n g c h a v e , I n t e g e r I t e r a t o r v a l o r e s ) : 11 / ∗ c h a v e : p a l a v r a e m i t i d a p e l a f u n c a o map . ∗ / 12 / ∗ v a l o r e s : c o n j u n t o de v a l o r e s e m i t i d o s p a r a a c h a v e . ∗ / 13 t o t a l = 0 14 f o r e a c h v i n v a l o r e s : 15 t o t a l = t o t a l + v 16 end f o r 17 e m i t ( p a l a v r a , t o t a l ) 18 end f u n c t i o n

Figura 3.1: Pseudocódigo de programação no MapReduce

Figura 3.2: Fluxo simplificado de execução e dados do MapReduce

arquivo de saída.

Outros exemplos de programas facilmente expressos no modelo MapReduce são: grep distribuído, frequência de acesso a URLs, grafo reverso de links web, índice invertido, ordenamento distribuído, dentre outros (DEAN; GHEMAWAT, 2008).

3.1

Arquitetura do Framework

O modelo MapReduce pode ser executado sobre uma variedade de plataformas e am-bientes distintos. Logo, a melhor implementação do framework depende do ambiente alvo. Uma implementação feita para utilizar a GPU (Graphics Processing Unit) de uma máquina, por exemplo, provavelmente será beneficiada por um comportamento distinto a uma implementação destinada a um grande cluster.

O Google MapReduce foi desenvolvido para grandes clusters de máquinas de prateleira1,

(15)

pelo usuário. Como é possível perceber, trata-se de uma típica arquitetura mestre-escravo (do inglês master-slave) (DUBREUIL; GAGNÉ; PARIZEAU, 2006).

A arquitetura compreende, ainda, um sistema de arquivos distribuído, onde ficam ar-mazenados os dados utilizados como entrada para os jobs. Para evitar a transferência excessiva de dados, os workers do MapReduce são também nós do sistema de arquivos. Mais detalhes sobre este recurso são apresentados nas seções 3.3 e 3.6.1.3.

3.2

Etapas e Otimizações Internas

Além das fases de mapeamento e redução, que consistem na execução de fato das funções map e reduce criadas pelo programador, quatro outras etapas são características durante a execução do framework MapReduce. Elas são conhecidas como Input splitting, Shuffle, Sort e Combine. As três primeiras são referenciadas, porém não detalhadas, na Figura 3.2.

A etapa Input splitting (VENNER, 2009) consiste na leitura e divisão dos dados de entrada. Cada intervalo gerado, chamado de input split, normalmente varia de 16 a 64 megabytes (diretamente relacionado com o tamanho dos blocos do sistema de arquivos distribuído) e é utilizado como entrada para uma tarefa de mapeamento. Após a divisão, cada tarefa lê o conteúdo de seu input split e gera pares chave/valor que serão passa-dos a várias chamadas da função map definida pelo usuário. O componente responsável pela leitura dos input splits é conhecido como Reader (ou leitor em português) (DEAN; GHEMAWAT, 2008).

Cada implementação do modelo MapReduce possui uma variedade de leitores e, nor-malmente, permite que os programadores desenvolvam seus próprios componentes. As-sim o programador pode criar readers para casos específicos, como ler tuplas de um banco de dados ou registros de um arquivo binário, por exemplo. Vale ressaltar, ainda, que cada input split recebido por uma tarefa de mapeamento, pode gerar várias chamadas da função map criada pelo usuário. No exemplo WordCount, uma tarefa de mapeamento chamaria a função para cada linha de texto contida no input split, por exemplo. Esta possibilidade de extensão permite que o framework não apenas suporte uma variedade de sistemas de armazenamento, mas possibilita, também, a utilização de índices pré-gerados sobre os dados de entrada. Índices de bancos de dados e log rollover são exemplos citados em (DEAN; GHEMAWAT, 2010).

A fase Shuffle (VENNER, 2009; WHITE, 2009), realizada a partir do momento em que cada tarefa de mapeamento passa a produzir pares intermediários, é dividida em dois passos distintos: particionamento e ordenamento. No primeiro, os pares chave/valor são divididos em R partições de acordo com a tarefa de redução de destino de cada chave. tipo de equipamento é denominado Commodity Machine.

2Em mais detalhes, um job refere-se a cada solicitação de execução realizada por um usuário, e.g.

executar o programa que computa a frequência de palavras. Cada job, por sua vez, é constituído por diversas tarefas (tasks) de mapeamento e redução, criadas pelo próprio framework.

(16)

16

Figura 3.3: Fases de Shuffle e Sort no MapReduce (WHITE, 2009)

Logo, o valor de R corresponde à quantidade de tarefas de redução do job. Já no passo de ordenamento, as chaves pertencentes a uma mesma partição são ordenadas para facilitar posterior processamento. É importante destacar que cada tarefa de redução pode proces-sar várias chaves, porém uma única chamada à função reduce do usuário será feita para cada chave, i.e. uma função de redução deve processar todos os valores associados a uma determinada chave.

Como previamente comentado, uma tarefa de redução deve processar todas as par-tições a ela destinadas. Estes dados, contudo, estão espalhados pelos nós da rede, pois o mapeamento normalmente é realizado em mais de um worker. Portanto, o redutor deve copiar e fundir as partições a ele destinadas, e que foram geradas durante o Shuffle. Este processo de aglutinação de partições comuns é realizado na fase Sort (VENNER, 2009; WHITE, 2009). A etapa recebe este nome pois a fusão dos dados dá-se através de um merge-sort, otimizado pelo passo de ordenamento realizado no Shuffle, e que resulta em uma garantia de saída ordenada (por partição). A Figura 3.3 ilustra o fluxo de dados nas fases de Shuffle e Sort.

A etapa Combine, por sua vez, é definida por uma função do usuário, assim como as fases de mapeamento e redução, porém não é obrigatória. Ela consiste em um pré-processamento da redução, e provê um significativo ganho de desempenho para certas classes de aplicações (DEAN; GHEMAWAT, 2008). Esta etapa ocorre em cada worker que executa uma tarefa map, após o passo de ordenamento realizado durante o Shuffle. Em muitos casos, a função reduce do usuário é associativa e comutativa, tornando possível o processamento disjunto dos valores associados a uma mesma chave. A aplicação que computa a frequência de palavras é um bom exemplo de tais propriedades. Considere que a função combine é igual à função reduce e que o arquivo de entrada contém a seguinte linha de texto duas vezes: “palavra palavra”.

O fluxo de dados para o exemplo em questão é demonstrado na Figura 3.4, onde os dados iniciais, mais à esquerda de cada bloco, representam os pares intermediários emitidos pelas instâncias da função map (que são duas, devido à quantidade de linhas da entrada). Neste exemplo dois workers distintos realizam os mapeamentos. É possível perceber que sem a função combine o redutor teria que buscar e processar quatro pares intermediários, enquanto que, ao utilizar o combine, somente dois pares são manipulados na redução. Logo, verifica-se que esta etapa reduz o tráfego de informações na rede e a quantidade de trabalho centralizado no redutor.

(17)

Figura 3.4: Fluxo de dados da função Combine

3.3

GFS

À primeira vista, o processo de execução do MapReduce parece transferir um grande volume de dados pela rede para que os workers possam processar as informações. Este problema, no entanto, não apresenta o impacto esperado devido a alguns fatores impor-tantes. Como visto, a função combine é um deles, realizando “reduções parciais” sobre os pares intermediários. É possível, ainda, observar que um worker responsável por um mapeamento, pode vir a realizar a redução dos dados computados durante o map, evi-tando a cópia desses dados. Um outro importante recurso utilizado pelo framework, é a utilização de um sistema de arquivos distribuído (ou apenas DFS, abreviado do inglês Distributed File System), o qual influencia fortemente a implementação do MapReduce. No framework da Google, este recurso é representado pelo GFS.

O Google File System (GFS) é um sistema de arquivos distribuído para aplicações com processamento intensivo de dados (GHEMAWAT; GOBIOFF; LEUNG, 2003). Sua arquitetura consiste em um nó master, e diversos chunkservers. Ambos os tipos de nós são constituídos por máquinas de prateleira, rodando servidores a nível de usuário. A arquite-tura, ilustrada na Figura 3.5, considera, ainda, máquinas clientes (clients) que acessam o sistema de arquivos concorrentemente.

Figura 3.5: Arquitetura do GFS (GHEMAWAT; GOBIOFF; LEUNG, 2003) O nó mestre é encarregado de manter e controlar todos os metadados do sistema de arquivos, incluindo espaço de nomes (namespace), mapeamento de arquivos a chunks (“pedaços” de arquivos, que podem ser traduzidos como blocos do sistema de arquivos), localização dos chunks, dentre outros. O nó mestre centraliza, também, diversas

(18)

ativi-18

dades como balanceamento de carga dos chunkservers, garbage collection, e atendimento a requisições dos clientes, por exemplo.

Os chunkservers, por sua vez, possuem a tarefa de armazenar os dados em si, e enviá-los diretamente aos clientes que os requisitaram. Esta característica é fundamental para o bom desempenho do sistema.

Como comentado, existe uma forte ligação entre o DFS e a implementação do MapRe-duce. Isto ocorre pois os workers são também chunkservers, portanto, quando o escalon-ador do MapReduce atribui uma tarefa de mapeamento a um worker, ele tenta fazê-lo para um nó que já possua, em sua unidade de armazenamento local, uma réplica dos chunks que devem ser processados, a fim de evitar a transferência de informações pela rede. Quando esta atribuição não pode ser realizada, o escalonador tenta passar a tarefa à máquina que estiver mais próxima3ao chunkserver que possui os dados (DEAN; GHEMAWAT, 2008).

Assim, quando executa-se grandes operações MapReduce, envolvendo uma signifi-cante fração de nós do cluster, a maioria dos dados são lidos localmente e o consumo de banda é praticamente nulo (DEAN; GHEMAWAT, 2008).

3.4

Backup Tasks

Considerando a arquitetura e funcionamento do MapReduce, seus criadores identi-ficaram um possível problema de desempenho causado por máquinas cuja performance está aquém dos demais nós da grade. Essas máquinas são denominadas stragglers (DEAN; GHEMAWAT, 2008).

Uma máquina pode tornar-se lenta por diversos problemas de hardware e software. Neste caso, as tarefas executadas em um straggler atrasam o processamento como um todo, especialmente quando a lentidão das tarefas ocorre no final de um job (DEAN; GHEMAWAT, 2008).

Para contornar este problema no MapReduce, foram introduzidas as Backup Tasks. Estas tarefas de apoio são cópias de tarefas em andamento no final de operações de ma-peamento e redução. Quando qualquer uma das cópias de uma tarefa é finalizada com sucesso, as demais são encerradas (DEAN; GHEMAWAT, 2008).

A execução das backup tasks resulta em um alto ganho de desempenho nos jobs do MapReduce. Como exemplo deste ganho, (DEAN; GHEMAWAT, 2008) aponta um al-goritmo de ordenamento que, sem a utilização das backup tasks, apresenta um aumento de 44% no tempo de execução do job em relação ao comportamento normal (com backup tasks).

3.5

Aplicações típicas

Devido a sua facilidade de programação e uso, o modelo MapReduce é utilizado nas mais diferentes áreas de pesquisa, como por exemplo, data mining, processamento de imagens (WILEY et al., 2011) e bioinformática (MATSUNAGA; TSUGAWA; FORTES, 2008). Além disso, grandes empresas, como Google, Yahoo!, Facebook, Amazon e Ebay, tem utilizado o MapReduce em seus clusters para realizar o processamento de grandes conjuntos da dados (APACHE SOFTWARE FOUNDATION, 2011).

3O conceito de proximidade em redes é bastante subjetivo, e pode referir-se, por exemplo, à quantidade

de nós em um caminho, ao tempo de transferência de dados entre dois nós, e até mesmo à proximidade geográfica. No contexto do framework MapReduce, considera-se que dois nós são próximos quando eles compartilham uma storage de dados no cluster, ou estão ligados a um mesmo switch, por exemplo.

(19)

O Facebook, outro contribuidor do projeto Hadoop, utiliza o sistema para processa-mento de logs, geração de relatórios e estatísticas, e aprendizagem de máquina. Um de seus maiores clusters possui 1.100 máquinas, totalizando 8.800 núcleos de processamento e 12 peta bytes de armazenamento bruto.

A Google, criadora do modelo, utiliza seu próprio framework, desenvolvido em C++. Dentre aplicações típicas executadas é possível citar: geração de índices para o sistema de buscas; aprendizagem de máquina em larga escala; problemas de agrupamento de notícias e produtos; geração de relatórios para as buscas mais frequentes; extração de informações de páginas web, como localização por exemplo; e computação de grafos em larga-escala (DEAN; GHEMAWAT, 2010).

Contudo, nem todos os aplicativos são adequados e/ou facilmente modelados com o MapReduce. Cabe ao desenvolvedor identificar a viabilidade da representação de seus aplicativos através do modelo. Porém alguns tipos de aplicação são, normalmente, mais adequadas ao MapReduce. Dentre estes, é possível citar:

• Algoritmos de manipulação de dados em geral (dataflow programming); • Encadeamento de transformações sobre dados;

• Embarrassingly parallel problems. Algumas aplicações mais específicas são: • Data mining;

• Processamento de imagem e vídeo; • Cálculos estatísticos;

• Algoritmos de ordenamento • Algoritmos de pesquisa; • e geração de índices.

Dentre algumas limitações do modelo MapReduce estão, o não tratamento de de-pendência entre tarefas de um mesma fase (map ou reduce); e o alto overhead para tare-fas curtas, gerado pelos mecanismos internos do framework e sistema de arquivos. O MapReduce também não é adequado para ser utilizado como um sistema de resposta em tempo real. Um web service, por exemplo, normalmente não invoca a execução de um job MapReduce perante a solicitação de um usuário. Ao invés disso, o web service utiliza-se de informações geradas por jobs executados periodicamente em segundo plano.

(20)

20

3.6

Frameworks MapReduce

Devido ao sucesso do MapReduce em clusters homogêneos, diferentes plataformas passaram a ser estudadas como ambiente de execução para o modelo. Ranger propôs uma versão do MapReduce para execução em processadores multicore de memória compar-tilhada (RANGER et al., 2007a). Uma versão para GPUs (Graphics Processing Unit) também foi desenvolvida e chamada de MARS (FANG et al., 2011). Foram propostas, também, melhorias no Hadoop para que ele seja utilizado em ambientes heterogêneos como desktop grids (ZAHARIA et al., 2008). Além disso, com a popularização da com-putação em nuvem, foram implementadas versões que utilizam os serviços oferecidos pelos sistemas operacionais de cloud computing (LIU; ORBAN, 2011) (GUNARATHNE et al., 2010).

3.6.1 Hadoop

Uma das implementações mais conhecidas do MapReduce faz parte do projeto Hadoop, mantido pela Apache Software Foundation (APACHE, 2010), e que tem como finalidade desenvolver software livre para computação distribuída, escalável e confiável (HADOOP, 2010a). O Hadoop MapReduce é uma implementação em Java do modelo e framework criado pela Google, o qual foi originalmente desenvolvido em C++.

Os conceitos que servem como base para o framework do Hadoop seguem o mod-elo definido no trabalho de (DEAN; GHEMAWAT, 2008), o qual foi apresentado nas seções anteriores. Logo, seu funcionamento é extremamente semelhante ao framework da Google.

Google Hadoop

Master JobTracker

Worker TaskTracker

Backup task Speculative task GFS Master HDFS NameNode GFS Chunkserver HDFS DataNode

Tabela 3.1: Comparação da terminologia utilizada no Hadoop

Em alguns pontos da implementação, a terminologia utilizada difere do que foi previ-amente apresentado, porém é possível relacionar os termos equivalentes. Os conceitos de nó Master e Worker, por exemplo, são respectivamente denominados JobTracker e Task-Trackerno Hadoop. A Tabela 3.1 relaciona mais algumas equivalências de nomenclatura e tecnologias.

3.6.1.1 Escalonamento de Tarefas

Assim como o framework da Google, o Hadoop MapReduce apresenta uma arquite-tura cliente-servidor. O código dos workers, portanto, é constituído de um simples heart-beat4que envia o estado do nó ao mestre, e aguarda tarefas para então processá-las.

Quando um worker indica que está disponível para receber mais trabalho, o nó mestre lhe atribui uma tarefa seguindo o processo descrito a seguir.

1. Se ainda existe alguma tarefa de mapeamento a ser finalizada, o nó mestre procura, em ordem, uma tarefa

(21)

2. Para as tarefas de redução, o sistema opera da seguinte maneira: primeiramente são distribuídas tarefas pendentes e, por fim, tarefas especulativas. Na redução não existe o conceito de blocos locais, uma vez que a entrada para estas tarefas consiste dos resultados das tarefas de mapeamento, que estão distribuídos entre os nós da grade.

Existe ainda um escalonamento entre tarefas de jobs distintos. Atualmente o algoritmo utilizado é denominado Fair Scheduler, e busca uma distribuição justa da capacidade do clusterentre os usuários (WHITE, 2009). O escalonamento entre jobs, contudo, não será abordado neste trabalho.

3.6.1.2 Execução Especulativa

No Hadoop, a execução especulativa (do inglês speculative execution) (WHITE, 2009) representa o mecanismo de backup tasks do framework da Google.

As tarefas especulativas são executadas nos nós do cluster somente quando todas as outras tarefas (map ou reduce)5 regulares já foram concluídas, e somente para tarefas que já estão executando há pelo menos um minuto e não conseguiram atingir o mesmo progresso, em média, que as demais tarefas do job (WHITE, 2009).

Para identificar as máquinas lentas, cada nó do cluster envia seu progresso, e outras informações, através do sinal de heartbeat (WHITE, 2009). Para tarefas de mapeamento, o progresso é calculado através da fração de dados já processados, enquanto que nas tare-fas de redução, cada tare-fase (cópia, ordenamento e redução) representa 1/3 do andamento (cada fase, contudo, tem seu progresso determinado em função dos dados processados, como no mapeamento) (ZAHARIA et al., 2008).

3.6.1.3 HDFS

Assim como sua implementação do MapReduce, o projeto Hadoop provê uma al-ternativa Java para o GFS. O Hadoop Distributed File System (HDFS) é um sistema de arquivos distribuído altamente tolerante a falhas projetado para rodar sobre hardware de prateleira (HADOOP, 2010b).

A plataforma Hadoop suporta diversos sistemas de arquivos distintos, como Ama-zon S3 (Native e Block-based), CloudStore, HAR, sistemas mantidos por servidores FTP e HTTP/HTTPS (este último apenas como leitura), Local (destinado a unidades de ar-mazenamento conectadas localmente), dentre outros (WHITE, 2009). O HDFS, contudo, é seu sistema de arquivos padrão.

A arquitetura do HDFS, ilustrada na Figura 3.6, segue os moldes do GFS, apresenta-dos em (GHEMAWAT; GOBIOFF; LEUNG, 2003) (HADOOP, 2010c). Assim como o sistema de arquivos da Google, o HDFS possui um nó mestre (denominado NameNode) responsável por atender requisições dos usuários e gerenciar a localização dos dados, e

5O mecanismo de execução especulativa atua no fim das fases de mapeamento e redução de maneira

(22)

22

Figura 3.6: Arquitetura do HDFS (HADOOP, 2010b)

vários nós de dados (DataNodes) que armazenam e transmitem os dados aos usuários que os requisitarem.

Outra propriedade importante do HDFS é a distribuição de dados. O sistema de ar-quivos busca manter um balanceamento na porcentagem de ocupação das storages que o constituem através da redistribuição e re-replicação de blocos (WHITE, 2009).

Uma importante funcionalidade do HDFS, e que impacta fortemente no desempenho do MapReduce, é conhecida como rack awareness. Através desse recurso, o HDFS é capaz de identificar quais DataNodes pertencem a um mesmo rack, e a partir dessa in-formação, distribuir as réplicas de maneira mais inteligente aumentando a performance e resiliência do sistema (WHITE, 2009).

3.6.2 Phoenix

O Phoenix (RANGER et al., 2007b) é uma implementação do MapReduce para ar-quiteturas multicore com memória compartilhada. Seu fluxo de execução é ilustrado pela figura 3.7.

Figura 3.7: Fluxo de execução no Phoenix (RANGER et al., 2007b)

Como esta solução é executada em uma única máquina, e consequentemente não pos-sui um sistema de arquivos distribuído, a quantidade de chunks da entrada é igual à quanti-dade de núcleos de processamento da máquina. O mesmo ocorre na fase de redução, onde

(23)

3.6.3 MARS

MARS (FANG et al., 2011) é uma implementação do MapReduce que permite o uso de processadores gráficos para a execução de tarefas (figura 3.8). Para alocar a memória nos dispositivos gráficos, o MARS realiza uma etapa extra de pré-processamento das tarefas a fim de descobrir a quantidade de dados emitidos.

Figura 3.8: MARS GPU (FANG et al., 2011)

Além do uso de GPUs, o MARS possibilita o uso de CPUs em uma única máquina (figura 3.9), e também uma forma distribuída, que utiliza o Hadoop Streaming para chamar o aplicativo nas CPUs e/ou GPUs dos workers (figura 3.10).

Figura 3.9: MARS GPU+CPU (FANG et al., 2011)

3.6.4 Cloud

Novos frameworks MapReduce estão surgindo também para os ambientes de cloud computing, que estão tornando-se cada vez mais populares. Dentre soluções recentes, é

(24)

24

Figura 3.10: MARS Hadoop (FANG et al., 2011)

possível citar o Cloud MapReduce (LIU; ORBAN, 2011) e o Azure MapReduce (GU-NARATHNE et al., 2010). Suas arquiteturas estão respectivamente ilustradas nas figuras 3.11 e 3.12.

Uma característica importante das implementações do MapReduce para ambientes cloud é que, ao utilizar os serviços de armazenamento de dados destes ambientes, os frameworks acabam perdendo a propriedade de localidade de dados na fase de mapea-mento. Isto ocorre pois os workers precisam buscar os dados através da rede, no ambiente de armazenamento de dados da cloud.

(25)

Figura 3.11: Arquitetura do Cloud MapReduce (LIU; ORBAN, 2011)

(26)

26

4

TRABALHOS RELACIONADOS

Este capítulo apresenta os trabalhos científicos mais relevantes na adaptação do Map-Reduce a ambientes voláteis e heterogêneos até o presente momento. A partir deste estado-da-arte, será possível avaliar quais dificuldades ainda existem para que esta adap-tação tenha sucesso, e quais melhorias podem ser desenvolvidas sobre os estudos atuais.

4.1

MOON: MapReduce On Opportunistic eNvironments

MOON (LIN et al., 2010) é uma extensão do Hadoop MapReduce que busca suportar ambientes de computação voluntária, e que introduz um ambiente híbrido de máquinas voláteis e servidores dedicados. Mais especificamente, seu ambiente alvo são Intranets institucionais, constituídas de computadores pessoais (PCs) conectados em redes locais (LANs), com alta banda e baixa latência. Esta solução utiliza reexecução para tolerância a falhas nos casos de falhas em tarefas e perda de dados intermediários.

O ambiente híbrido introduzido neste trabalho busca melhorar o desempenho do Hadoop em ambientes voláteis, como computação voluntária e desktop grids. Para tal, a solução considera dois tipos de workers: voláteis e dedicados. Os primeiros são constituídos de recursos ociosos, como máquinas cedidas por usuários, ou estações de trabalhos ociosas em um ambiente empresarial. Os usuários desses recursos podem utilizá-los a qualquer momento, tornando-os indisponíveis para a computação de tarefas MapReduce. Para con-tornar este problema, os workers dedicados são máquinas sempre ativas, e que trabalham exclusivamente para a computação distribuída. Estes últimos garantem disponibilidade de dados e processamento mesmo na ausência de nós voluntários.

A figura 4.1 ilustra o processo de decisão utilizado para o armazenamento de dados no MOON. Dois tipos de armazenamento são propostos: confiável e oportunista. No primeiro caso os dados são armazenados nos nós dedicados. Os dados de entrada, que não podem ser gerados pelo MapReduce, utilizam o armazenamento confiável. No segundo caso os dados ficam nos workers voláteis, como no caso dos pares intermediários. Caso os dados armazenados de forma oportunista sejam perdidos, o MOON reexecuta as tarefas que geraram estes dados. Este processo de reexecução para tolerar falhas pode apresentar um custo importante em ambientes com altos níveis de volatilidade.

Outra contribuição deste trabalho é a introdução de um estado de hibernação para os nós voláteis (hibernate). Isto ocorre no momento em que um worker fica indisponível. Então o nó mestre aguarda por um determinado tempo para verificar se o worker voltou a processar a tarefa ou não. Isto evita o relançamento de tarefas em situações onde os recursos ficam indisponíveis por um curto período de tempo.

(27)

Figura 4.1: Processo de decisão para armazenar dados no MOON (LIN et al., 2010)

4.2

Towards MapReduce for Desktop Grid Computing

No trabalho de (TANG et al., 2010) é proposta uma implementação do MapReduce que executa sobre o BitDew, um middleware para gerenciamento de dados em desktop grids. Esta solução utiliza propriedades de redes P2P (peer-to-peer) para tolerância a fal-has, replicação de dados, verificação de resultados, dentre outros. A figura 4.2 apresenta uma visão geral do sistema.

Figura 4.2: Visão geral do sistema usando o BitDew (TANG et al., 2010)

Na arquitetura proposta, os nós voláteis assumem o papel de workers (MR Worker), e os nós estáveis assumem os papéis de master e service node (MR Master e MR Service respectivamente). O service node é responsável pelo monitoramento das tarefas do Map-Reduce, e é controlado pelo nó mestre. O componente MapReduce fornece uma API (Ap-plication Programming Interface) para o desenvolvimento das funções de mapeamento e redução.

Para lidar com a volatilidade dos recursos, a solução utiliza os mecanismos de tolerân-cia a falhas do BitDew. Os nós master e service, contudo, continuam sendo pontos únicos de falha pois considera-se que estarão sempre disponíveis.

4.3

Volunteer Cloud Computing: MapReduce over the Internet

No trabalho recente de (COSTA; SILVA; DAHLIN, 2011) é apresentado o BOINC-MR, uma outra implementação do MapReduce para computação voluntária sobre a plataforma BOINC (um importante sistema de computação voluntária que compreende projetos como

(28)

28

o SETI@Home (KORPELA et al., 2001)), e que utiliza fontes de dados fixas. Neste tra-balho foram realizadas modificações no servidor e cliente do BOINC, a fim de permitir troca de dados entre os clientes do sistema, que originalmente comunicam-se apenas com o servidor.

A figura 4.3 ilustra a fase de mapeamento no BOINC-MR: primeiramente, cada usuário solicita tarefas ao servidor BOINC. Em seguida o escalonador procura por tarefas de ma-peamento disponíveis para enviar ao cliente. Por fim, os usuários fazem o download dos dados de entrada diretamente dos servidores de dados do projeto responsável pelo job.

Figura 4.3: Processo de mapeamento no BOINC-MR (COSTA; SILVA; DAHLIN, 2011)

A fase de redução, por sua vez, procede da seguinte maneira: como mapeamento, ini-cialmente os usuários solicitam trabalho ao servidor, e em seguida o escalonador procura por tarefas de redução disponíveis. Então o escalonador utiliza o JobTracker para identi-ficar quais clientes finalizaram tarefas map e possuem dados disponíveis para transferên-cia. Por fim o usuário coleta a saída das tarefas map diretamente dos usuários especifica-dos pelo escalonador e realiza a computação do reduce.

Como é possível perceber, as saídas das tarefas de mapeamento são mantidas nos workers que as processaram, a fim de evitar que todos os dados passem pelo servidor. Para tal, o BOINC-MR envia uma hash dos dados para o servidor, que por sua vez utiliza um método usual de quorum para validar os resultados. Toda a saída da fase de redução, por outro lado, é retornada ao servidor.

(29)

Figura 4.4: Processo de redução no BOINC-MR (COSTA; SILVA; DAHLIN, 2011)

4.4

Decoupling Storage and Computation in Hadoop with

Super-DataNodes

Na implementação original do Hadoop existe um forte acoplamento entre a localiza-ção dos dados e onde estes dados serão processados. Isto ocorre pois os workers que processam os dados são, também, nós do sistema de arquivos distribuído.

Neste artigo, PORTER (2010) propõe o conceito de SuperDataNodes para o Hadoop. Estes nós possuem uma ordem de magnitude a mais de armazenamento que os nós con-vencionais do Hadoop. Esta abordagem foi adotada a fim de obter um desacoplamento entre armazenamento e processamento dos dados, porém mantendo um certo de nível de localidade dos dados no momento da execução (PORTER, 2010).

A figura 4.5 ilustra o esquema de funcionamento dos SuperDataNodes. Eles possuem várias dúzias de unidades de armazenamento formando um único pool de discos. Além disso, cada SuperDataNode hospeda várias máquinas virtuais que executam versões não modificadas dos DataNodes do Hadoop.

Os SuperDataNodes, além de mais discos de armazenamento, devem possuir links de rede com altas taxas de transferência. Estes requisitos podem ser considerados como limitações do modelo proposto. Além destes, a existência de poucos nós que armazenam muitos dados reduz a tolerância a falhas da solução.

Devido ao desacoplamento alcançado neste trabalho, os autores alegam que é pos-sível evitar transferências desnecessárias de dados ao desativar máquinas que possuem baixa carga de trabalho. Este comportamento pode ser de grande utilidade em ambientes voláteis, e apresenta certa semelhança com os workers dedicados apresentados na arquite-tura MOON (seção 4.1).

(30)

30

Figura 4.5: Esquema de um SuperDataNode (PORTER, 2010)

4.5

Variable-sized map and locality-aware reduce on public-resource

grids

No trabalho apresentado por (SU et al., 2011), os autores propõem um framework MapReduce para grades com recursos públicos, denominado “Ussop”. A figura 4.6 mostra uma visão geral do sistema. Esta implementação introduz, também, dois novos algoritmos de escalonamento de tarefas: o Variable-Sized Map Scheduling (VSMS) e o Locality-Aware Reduce Scheduling(LARS).

Figura 4.6: Visão geral do Ussop (SU et al., 2011)

O VSMS utiliza informações sobre a capacidade computacional dos workers (repre-sentada pela quantidade de dados processados por segundo) para ajustar o tamanho das

(31)

quentemente, o Ussop não realiza o prefetching de dados na fase de redução. Os autores alegam que independentemente da utilização do algoritmo LARS, não seria possível re-alizar o prefetching devido à volatilidade dos nós.

(32)

32

5

CONSIDERAÇÕES FINAIS

Devido ao sucesso do MapReduce em clusters homogêneos, diferentes plataformas passaram a ser estudadas como ambiente de execução para o modelo. Uma recente linha de pesquisa busca tornar viável a execução do MapReduce em ambientes voláteis, onde os recursos computacionais podem ficar indisponíveis a qualquer momento.

Este trabalho apresentou um estudo das pesquisas mais relevantes no que toca a adap-tação do MapReduce para ambientes voláteis e heterogêneos. A partir de uma análise feita sobre os trabalhos estudados, é possível perceber que um dos grandes desafios para imple-mentar o modelo MapReduce em tais ambientes é o grande volume de dados a ser proces-sado pelas aplicações. Falhas e períodos de indisponibilidade implicam em reexecução ou migração de informações pela rede. Estes processos podem ser muito custosos, e as características da infraestrutura influenciam nas decisões de implementação, e.g. frame-worksdesenvolvidos para execução na Internet devem evitar ao máximo a transferência de dados, e ao mesmo tempo garantir a disponibilidade das informações.

Assim, verifica-se que a pesquisa de soluções mais eficientes na implementação do MapReduce em ambientes com recursos voláteis é importante para a evolução desta tec-nologia — e de outros sistemas que necessitam processar grandes volumes de dados — em ambientes como desktop grids e de computação voluntária, que por sua vez propor-cionam alto poder computacional utilizando recursos ociosos.

(33)

REFERÊNCIAS

ANDERSON, D. BOINC: a system for public-resource computing and storage. In: GRID COMPUTING, 2004. PROCEEDINGS. FIFTH IEEE/ACM INTERNATIONAL WORK-SHOP ON. Anais. . . [S.l.: s.n.], 2004. p.4–10.

APACHE. Welcome! - The Apache Software Foundation. Disponível em: <http://www.apache.org/>. Acesso em: abril 2010.

APACHE SOFTWARE FOUNDATION, A. Powered by - Hadoop Wiki. Disponível em http://wiki.apache.org/hadoop/PoweredBy - Acessado em 3 de outubro de 2011.

COSTA, F.; SILVA, L.; DAHLIN, M. Volunteer Cloud Computing: mapreduce over the internet. In: PARALLEL AND DISTRIBUTED PROCESSING WORKSHOPS AND PHD FORUM (IPDPSW), 2011 IEEE INTERNATIONAL SYMPOSIUM ON. Anais. . . [S.l.: s.n.], 2011. p.1855–1862.

DEAN, J.; GHEMAWAT, S. MapReduce: simplified data processing on large clusters. Commun. ACM, New York, NY, USA, v.51, n.1, p.107–113, 2008.

DEAN, J.; GHEMAWAT, S. MapReduce: a flexible data processing tool. Commun. ACM, New York, NY, USA, v.53, n.1, p.72–77, Jan. 2010.

DUBREUIL, M.; GAGNÉ, C.; PARIZEAU, M. Analysis of a master-slave architecture for distributed evolutionary computations. Systems, Man, and Cybernetics, Part B: Cybernetics, IEEE Transactions on, [S.l.], v.36, n.1, p.229–235, 2006.

FANG, W. et al. Mars: accelerating mapreduce with graphics processors. IEEE Trans-actions on Parallel and Distributed Systems, [S.l.], v.22, n.4, p.608–620, Apr. 2011. FEDAK, G. et al. Xtremweb: a generic global computing system. In: CLUSTER COM-PUTING AND THE GRID, 2001. PROCEEDINGS. FIRST IEEE/ACM INTERNA-TIONAL SYMPOSIUM ON. Anais. . . [S.l.: s.n.], 2001. p.582–587.

FOSTER, I.; KESSELMAN, C. The Grid 2: blueprint for a new computing infrastruc-ture. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 2003.

GANTZ, J.; REINSEL, D. The Digital Universe Decade – Are You Ready? [S.l.]: IDC, 2010. White Paper.

GHEMAWAT, S.; GOBIOFF, H.; LEUNG, S.-T. The Google file system. In: SOSP ’03: PROCEEDINGS OF THE NINETEENTH ACM SYMPOSIUM ON OPERATING SYS-TEMS PRINCIPLES, New York, NY, USA. Anais. . . ACM, 2003. p.29–43.

(34)

34

GUNARATHNE, T. et al. MapReduce in the Clouds for Science. In: IEEE SECOND INTERNATIONAL CONFERENCE ON CLOUD COMPUTING TECHNOLOGY AND SCIENCE (CLOUDCOM), 2010. Proceedings. . . [S.l.: s.n.], 2010. p.565–572.

HADOOP. Welcome to Apache Hadoop! Disponível em: <http://hadoop.apache.org/>. Acesso em: abril 2010.

HADOOP. HDFS Architecture. Disponível em:

<http://hadoop.apache.org/common/docs/current/hdfs_design.html>. Acesso em: abril 2010.

HADOOP. HDFS - Hadoop Wiki. Disponível em:

<http://wiki.apache.org/hadoop/HDFS>. Acesso em: maio 2010.

KONDO, D. et al. Characterizing resource availability in enterprise desktop grids. Future Generation Computer Systems, [S.l.], v.23, n.7, p.888–903, 2007.

KONWINSKI, A. Improving MapReduce Performance in Heterogeneous Environ-ments. 2009. Dissertação (Mestrado em Ciência da Computação) — EECS Department, University of California, Berkeley. (UCB/EECS-2009-183).

KORPELA, E. et al. SETI@home-massively distributed computing for SETI. Computing in Science Engineering, [S.l.], v.3, n.1, p.78 –83, jan/feb 2001.

LIN, H. et al. MOON MapReduce On Opportunistic eNvironments. In: ACM INTERNA-TIONAL SYMPOSIUM ON HIGH PERFORMANCE DISTRIBUTED COMPUTING, 19., New York, NY, USA. Proceedings. . . ACM, 2010. p.95–106. (HPDC ’10).

LIU, H.; ORBAN, D. Cloud MapReduce: a mapreduce implementation on top of a cloud operating system. In: IEEE INTERNATIONAL SYMPOSIUM ON CLUSTER COM-PUTING AND THE GRID 2011. Proceedings. . . [S.l.: s.n.], 2011.

MATSUNAGA, A.; TSUGAWA, M.; FORTES, J. CloudBLAST: combining mapreduce and virtualization on distributed resources for bioinformatics applications. In: IEEE FOURTH INTERNATIONAL CONFERENCE ON ESCIENCE, 2008. ESCIENCE ’08., Los Alamitos, CA, USA. Proceedings. . . IEEE, 2008. v.0, p.222–229.

MUTKA, M. W.; LIVNY, M. Profiling Workstations’ Available Capacity for Remote Execution. In: PERFORMANCE ’87: PROCEEDINGS OF THE 12TH IFIP WG 7.3 INTERNATIONAL SYMPOSIUM ON COMPUTER PERFORMANCE MODELLING, MEASUREMENT AND EVALUATION, Amsterdam, The Netherlands, The Nether-lands. Anais. . . North-Holland Publishing Co., 1988. p.529–544.

PORTER, G. Decoupling storage and computation in Hadoop with SuperDataNodes. ACM SIGOPS Operating Systems Review, [S.l.], v.44, n.2, p.41–46, 2010.

RANGER, C. et al. Evaluating MapReduce for Multi-core and Multiprocessor Systems. In: HPCA ’07: PROCEEDINGS OF THE 2007 IEEE 13TH INTERNATIONAL SYM-POSIUM ON HIGH PERFORMANCE COMPUTER ARCHITECTURE, Washington, DC, USA. Anais. . . IEEE Computer Society, 2007. p.13–24.

(35)

TANG, B. et al. Towards MapReduce for Desktop Grid Computing. In: INTERNA-TIONAL CONFERENCE ON P2P, PARALLEL, GRID, CLOUD AND INTERNET COMPUTING, 2010., Washington, DC, USA. Proceedings. . . IEEE Computer Society, 2010. p.193–200. (3PGCIC ’10).

THAIN, D.; TANNENBAUM, T.; LIVNY, M. Condor and the Grid. In: GRID COM-PUTING. Anais. . . [S.l.: s.n.], 2003. p.299–335.

TOTH, D. M. Improving the productivity of volunteer computing. 2008. Tese (Doutorado em Ciência da Computação) — Bucknell University.

VENNER, J. Pro Hadoop. Berkely, CA, USA: Apress, 2009.

WHITE, T. Hadoop: the definitive guide. [S.l.]: O’Reilly Media, Inc., 2009.

WILEY, K. et al. Astronomy in the Cloud: using mapreduce for image co-addition. Pub-lications of the Astronomical Society of the Pacific, [S.l.], v.123, n.901, p.366–380, Mar. 2011.

ZAHARIA, M. et al. Improving MapReduce Performance in Heterogeneous Environ-ments. [S.l.: s.n.], 2008. (UCB/EECS-2008-99).

Referências

Documentos relacionados

O objetivo do curso foi oportunizar aos participantes, um contato direto com as plantas nativas do Cerrado para identificação de espécies com potencial

O valor da reputação dos pseudônimos é igual a 0,8 devido aos fal- sos positivos do mecanismo auxiliar, que acabam por fazer com que a reputação mesmo dos usuários que enviam

• The definition of the concept of the project’s area of indirect influence should consider the area affected by changes in economic, social and environmental dynamics induced

Outra parceria de sucesso firmada pelos Cartórios de Registro Civil foi um convênio firmado no final de 2019 entre a Correge- doria Geral da Justiça (CGJ-MA), o Estado do Maranhão

(2008) comparando as alterações na qualidade do café natural e despolpado submetidos a diferentes tipos de secagem e armazenamento em condições de umidades

Quando os dados são analisados categorizando as respostas por tempo de trabalho no SERPRO, é possível observar que os respondentes com menor tempo de trabalho concordam menos que

Por outro lado, é necessário ressaltar que o comportamento dos custos (quer sejam Custos Fixos ou Custos Variáveis) pode apresentar alterações quando considerados os diversos

Pelas armadilhas de queda foram registrados cinco indivíduos, totalizando quatro espécies; para o percurso em transecto foram registrados 19 indivíduos representados