estudo hadoop

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SULINSTITUTO DE INFORMTICA

CURSO DE CINCIA DA COMPUTAO

WAGNER KOLBERG

Simulao e Estudo da Plataforma HadoopMapReduce em Ambientes Heterogneos

Trabalho de Concluso

Prof. Dr. Cludio Fernando Resin GeyerOrientador

Porto Alegre, Dezembro de 2010

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SULReitor: Prof. Carlos Alexandre NettoVice-Reitor: Prof. Rui Vicente OppermannPr-Reitora de Graduao: Profa. Valquiria Link BassaniDiretor do Instituto de Informtica: Prof. Flvio Rech WagnerCoordenador do CIC: Prof. Joo Csar NettoBibliotecria-Chefe do Instituto de Informtica: Beatriz Regina Bastos Haro

SUMRIO

LISTA DE ABREVIATURAS E SIGLAS . . . . . . . . . . . . . . . . . . . . 5

LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

LISTA DE TABELAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

RESUMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1 INTRODUO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.1 Motivao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2 Organizao do Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2 TECNOLOGIAS E CONCEITOS ENVOLVIDOS . . . . . . . . . . . . . 122.1 Processamento Distribudo . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.1 Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.2 Computao em Grade . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.3 Desktop Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.4 Balanceamento de Carga . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 MapReduce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.1 Arquitetura do Framework . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.2 Etapas e Otimizaes Internas . . . . . . . . . . . . . . . . . . . . . . . 162.2.3 GFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.4 Backup Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3 Hadoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.1 Escalonamento de Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.2 Execuo Especulativa . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3.3 HDFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.4 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 MAPREDUCE EM AMBIENTES HETEROGNEOS . . . . . . . . . . . 223.1 Descrio do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.3 Modificaes Propostas . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.3.1 Modificao 1 - Distribuio de Dados . . . . . . . . . . . . . . . . . . . 243.3.2 Modificao 2 - Execuo Especulativa . . . . . . . . . . . . . . . . . . . 253.4 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.1 Plano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2 Ambiente de Desenvolvimento e Testes . . . . . . . . . . . . . . . . . . . 274.2.1 SimGrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2.2 Grid5000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5 ESPECIFICAO DO SIMULADOR . . . . . . . . . . . . . . . . . . . 325.1 Objetivos do Simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2 Limitao do Estado Atual . . . . . . . . . . . . . . . . . . . . . . . . . 325.3 Uso do Simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.4 Comparao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.5 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.1 Validao do Simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.1.1 Descrio do Aplicativo Utilizado na Validao . . . . . . . . . . . . . . 356.1.2 Configurao dos Jobs e Resultados . . . . . . . . . . . . . . . . . . . . 366.2 Adaptao a Ambientes Heterogneos . . . . . . . . . . . . . . . . . . . 396.3 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

7 CONCLUSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

REFERNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

ANEXO A EXEMPLO DE PROGRAMAO NO HADOOP . . . . . . . . 45

ANEXO B ARQUIVO DESCRITOR DE PLATAFORMA . . . . . . . . . . 47

ANEXO C ARQUIVO DESCRITOR DE APLICAO . . . . . . . . . . . 48

ANEXO D CDIGO FONTE DA VALIDAO DO SIMULADOR . . . . . 49

LISTA DE ABREVIATURAS E SIGLAS

API Application Programming Interface

CPU Central Processing Unit

DTD Document Type Definition

DFS Distributed File System

GFS Google File System

GPU Graphics Processing Unit

HDFS Hadoop Distributed File System

LATE Longest Approximate Time to End

MRSG MapReduce-SimGrid

XML Extensible Markup Language

LISTA DE FIGURAS

Figura 2.1: Pseudocdigo de programao no MapReduce . . . . . . . . . . . . 14Figura 2.2: Fluxo simplificado de execuo e dados do MapReduce . . . . . . . 15Figura 2.3: Fases de Shuffle e Sort no MapReduce . . . . . . . . . . . . . . . . . 16Figura 2.4: Fluxo de dados da funo Combine . . . . . . . . . . . . . . . . . . 17Figura 2.5: Arquitetura do GFS . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Figura 2.6: Arquitetura do HDFS . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Figura 3.1: Distribuio de dados no HDFS . . . . . . . . . . . . . . . . . . . . 24Figura 3.2: Nova distribuio de dados proposta . . . . . . . . . . . . . . . . . . 24Figura 3.3: Processamento dos dados distribudos no HDFS . . . . . . . . . . . . 25

Figura 4.1: Relao entre os componentes do SimGrid . . . . . . . . . . . . . . 28Figura 4.2: Distribuio geogrfica dos clusters na Grid5000 . . . . . . . . . . . 29

Figura 6.1: Validao do MRSG com 20 ncleos . . . . . . . . . . . . . . . . . 37Figura 6.2: Validao do MRSG com 20 ncleos (fases) . . . . . . . . . . . . . . 38Figura 6.3: Validao do MRSG com 200 ncleos . . . . . . . . . . . . . . . . . 38Figura 6.4: Validao do MRSG com 200 ncleos (fases) . . . . . . . . . . . . . 39Figura 6.5: Quantidade de tarefas especulativas no modelo original . . . . . . . . 40Figura 6.6: Quantidade de mapeamentos no locais . . . . . . . . . . . . . . . . 41

LISTA DE TABELAS

Tabela 2.1: Comparao da terminologia utilizada no Hadoop . . . . . . . . . . . 19

Tabela 5.1: Comparao de recursos com o MRPerf . . . . . . . . . . . . . . . . 34

Tabela 6.1: Parmetros da validao com 20 ncleos . . . . . . . . . . . . . . . 36Tabela 6.2: Parmetros da validao com 200 ncleos . . . . . . . . . . . . . . . 37

RESUMO

MapReduce um modelo de programao voltado computao paralela em largaescala, e ao processamento de grandes volumes de dados. A implementao do modelo,e as suposies feitas em relao ao ambiente sobre o qual ser executado, influenciamfortemente no tempo de computao dos jobs submetidos.

O Hadoop, uma das implementaes mais populares do MapReduce, e que ser es-tudada neste trabalho, supe que o ambiente de execuo homogneo, prejudicando odesempenho do framework quando a grade apresenta um certo nvel de heterogeneidadeno que toca a capacidade de processamento das mquinas que a constituem.

Como ferramenta de anlise para as adaptaes propostas, desenvolvido um simu-lador para o MapReduce tendo como base o simulador de grades SimGrid com oobjetivo de facilitar a implementao e avaliao de novos algoritmos de escalonamentode tarefas e distribuio de dados, dentre outros. Dentre as vantagens proporcionadas pelouso do simulador possvel citar: a facilidade na implementao de algoritmos tericos;a agilidade em testes para uma grande variedade de configuraes; e a possibilidade deavaliar rapidamente a escalabilidade de algoritmos sem custos de infraestrutura.

Em relao ao simulador, ainda apresentada uma validao de seu comportamentoem relao ao Hadoop MapReduce, comparando execues do sistema em uma grade,com simulaes que emulam as configuraes reais. Uma vez validado o simulador, omesmo utilizado para avaliar as adaptaes do Hadoop a ambientes heterogneos.

Os resultados obtidos, tanto com a validao do simulador, quanto com a implemen-tao das adaptaes propostas, apresentaram resultados positivos, demostrando que vivel utilizar simulao para estudar e avaliar diferentes implementaes para o modeloMapReduce.

Este trabalho, portanto, consiste em um estudo do funcionamento interno do HadoopMapReduce, seu comportamento em ambientes heterogneos, e tambm prope um novosimulador, com os recursos necessrios para avaliar adaptaes em implementaes doMapReduce.

Palavras-chave: Grade, MapReduce, Hadoop, ambientes heterogneos, escalonamento,framework, programao paralela, simulao.

ABSTRACT

Simulation and Study of the Hadoop MapReduce Platform on HeterogeneousEnvironments

MapReduce is a programming model for large-scale parallel computing, and for pro-cessing large data sets. The model implementation, and the assumptions made about therunning environment, strongly affect the job execution time.

Hadoop, one of the most popular implementations of the MapReduce model, that willbe studied in this work, assumes that the execution environment is homogeneous, depre-cating its performance when the grid presents a certain level of heterogeneity, concerningthe computation power of its nodes.

As an analysis tool, a MapReduce simulator having the SimGrid simulator as itsbase system is developed to easily implement and evaluate new task scheduling anddata distribution algorithms. As advantages that a simulator provides, it is possible toname: the simplified development of theoretical algorithms; the agility to test a greatvariety of configurations; and the possibility to quickly evaluate algorithms scalabilitywithout infrastructure costs.

The simulator has its behavior validated against the Hadoop MapReduce, throughcomparisons of real executions of the framework on a real grid environment, and simu-lations that emulate the configurations used on the real execution. Once the simulator isvalidated, it is used to evaluate the modifications to the MapReduce algorithms on hetero-geneous environments.

The results of the simulator validation, and the evaluation of the proposed modifica-tions, were positive, showing that it is possible to use simulation to study and evaluatedifferent MapReduce implementations.

Therefore, this work consists of a study about the Hadoop MapReduce, its behavior onheterogeneous environments, and it also proposes modifications in this framework to im-prove its performance on this kind of environment. To evaluate the proposed adaptations,a MapReduce simulator was developed, and it will also be presented in this study.

Keywords: Grid, MapReduce, Hadoop, heterogeneous environments, scheduling, frame-work, parallel programming, simulation.

10

1 INTRODUO

Com a evoluo dos sistemas de informao e o aumento da quantidade de servi-os disponibilizados a seus usurios, cresce tambm o volume de dados que precisa serprocessado pelos sistemas computacionais. Como exemplos de computao intensiva dedados, (WHITE, 2009) aponta: a bolsa de valores de Nova Iorque, que gera um terabytede dados por dia; o Facebook, que hospeda 10 bilhes de fotos (totalizando um petabytede armazenamento); e o Large Hadron Collider (LHC), que deve produzir cerca de 15petabytes de dados por ano. Empresas na rea de busca, e.g. Google e Yahoo, tambmso timos exemplos, pois indexam trilhes de pginas da internet, e atendem bilhes derequisies diariamente.

De acordo com a IDC (International Data Corporation), a quantidade de informaocriada, capturada ou replicada em meio digital no ano de 2009 apresentou um crescimentode 62%, alcanando aproximadamente 800.000 petabytes. Para 2010, acredita-se que estevalor chegue a 1.2 milhes de petabytes. J em 2020 o crescimento esperado deve alcanaros 35 zetabytes, equivalente a 35 milhes de petabytes (GANTZ; REINSEL, 2010).

Para que a computao desta grande quantidade de informaes seja realizada emtempo vivel, cada vez mais faz-se necessria a explorao de paradigmas de programa-o paralela e processamento distribudo. Porm, desenvolver software para ambientesdistribudos uma tarefa complexa, pois envolve uma srie de conceitos e problemas quedevem ser considerados pelos programadores; como concorrncia, tolerncia a falhas,distribuio de dados e balanceamento de carga.

A fim de facilitar este processo, a multinacional Google desenvolveu o MapReduce,um modelo de programao paralela para processamento largamente distribudo de gran-des volumes de dados (DEAN; GHEMAWAT, 2008).

Alm do framework da Google, diversas implementaes para o MapReduce foramdesenvolvidas, dentre as quais, a mais conhecida e divulgada est inserida no projetoHadoop (HADOOP, 2010a), mantido pela Apache Software Foundation. Um aspecto im-portante desta implementao seu escalonador de tarefas, o qual supe que o ambientedistribudo homogneo. Assim, quando submetido execuo em ambientes heterog-neos, o Hadoop MapReduce apresenta um comportamento inadequado, prejudicando seudesempenho (KONWINSKI, 2009; ZAHARIA et al., 2008).

1.1 Motivao

H muito constatou-se que as estaes de trabalho apresentam longos perodos deociosidade, principalmente durante a noite e finais de semana, quando ficam aproximada-mente 95% do tempo disponveis (FOSTER; KESSELMAN, 2003), utilizando, ao longodo tempo, apenas 30% de sua capacidade de processamento (MUTKA; LIVNY, 1988).

11

Pesquisadores passaram, ento, a estudar o uso de estaes de trabalho como recur-sos de processamento distribudo, em alternativa aos clusters de dedicao exclusiva, queapresentam um custo muito mais elevado. Este tipo de ambiente conhecido por Desk-top Grid (FOSTER; KESSELMAN, 2003), e tem como uma importante caracterstica aheterogeneidade de seus ns.

Este trabalho tem como objetivo estudar o Hadoop MapReduce, seu comportamentoem ambientes heterogneos, e tambm propor uma alternativa ao escalonador atual, a fimde melhorar o desempenho do framework nestas condies.

As adaptaes propostas ao escalonador do Hadoop, visam o beneficio dos usuriosde Desktop Grids, uma vez que as janelas de disponibilidade das estaes que constituemestas grades podero ser aproveitadas de maneira mais eficiente.

Espera-se, tambm, que este aperfeioamento do Hadoop para Desktop Grids pro-mova a utilizao deste tipo de ambiente, o que leva a um melhor aproveitamento de re-cursos j disponveis nas organizaes, sem a necessidade da aquisio de novos clusters.Esta prtica impacta fortemente no que toca a questo de economia energtica e, conse-quentemente, emisso de dixido de carbono, compactuando com os conceitos de GreenComputing (MURUGESAN, 2008), indispensveis em nossa atualidade para alcanar umambiente de processamento computacional sustentvel.

1.2 Organizao do Texto

A continuidade deste texto est organizada como descrito a seguir. No captulo 2 soapresentadas as tecnologias relacionadas com este trabalho. No captulo 3 realizado umestudo sobre o comportamento do MapReduce em ambientes heterogneos, no qual soindicados possveis problemas, e apresentadas propostas para a soluo dos mesmos. Emseguida, nos captulos 4 e 5, passa-se descrio do simulador desenvolvido durante otrabalho e do ambiente de testes. Por fim, nos captulos 6 e 7, so respectivamente expos-tos os resultados obtidos na validao do simulador e na implementao das propostas docaptulo 3, e uma concluso com as consideraes finais do trabalho.

12

2 TECNOLOGIAS E CONCEITOS ENVOLVIDOS

Neste captulo sero apresentadas as tecnologias envolvidas no estudo realizado. Ofuncionamento de cada tecnologia exposto de maneira detalhada, a fim de permitir acompreenso dos problemas encontrados e das solues propostas neste trabalho.

So expostos, tambm, os conceitos bsicos por trs destas tecnologias. Estes concei-tos permitem ao leitor contextualizar o estudo sendo apresentado, e facilitam a compre-enso das tcnicas utilizadas para a anlise e soluo de problemas.

2.1 Processamento Distribudo

Com o avano tecnolgico das ltimas dcadas, os computadores passaram a ficarcada vez mais populares, e consequentemente seu custo foi reduzido drasticamente, per-mitindo a multiplicao desses dispositivos tanto em ambientes empresariais, quanto do-msticos. Este crescimento, aliado a avanos em reas como armazenamento e comu-nicao de informaes, possibilitou a colaborao entre recursos computacionais paraa soluo de problemas. Desta distribuio do trabalho que antes era realizado por umanica mquina, surgiu o paradigma de processamento distribudo (TOTH, 2008).

Esta linha de pesquisa envolve vrios outros conceitos relacionados com infraes-trutura, tcnicas de distribuio e balanceamento de carga, etc. que sero comentadosa seguir.

2.1.1 Clusters

Um cluster pode ser definido como um conjunto de mquinas, administrado e utili-zado por um nico indivduo, com o objetivo de solucionar problemas que levariam muitotempo em uma nica estao de trabalho (TOTH, 2008).

Dentre algumas caractersticas frequentemente observadas em um cluster, possveldestacar:

O cluster constitudo por mquinas de prateleira, apresentando baixo custo secomparado a supercomputadores.

Todos os ns esto geograficamente prximos, geralmente em um mesmo prdio.

As conexes entre as mquinas possuem altas taxas de transferncia.

As mquinas so homogneas, i.e. possuem capacidades de processamento simila-res.

13

2.1.2 Computao em Grade

Uma Grade Computacional (do ingls, Grid) consiste de um sistema que coordenarecursos de maneira no centralizada, utilizando protocolos e interfaces padronizadas,abertas, e de propsitos gerais, a fim de prover uma variedade de servios complexos deacordo com a demanda de seus usurios (FOSTER; KESSELMAN, 2003).

Ainda de acordo com Foster, o termo Grid utilizado em analogia s redes deenergia eltrica (chamadas de power grids em ingls), as quais proveem acesso difuso eletricidade (FOSTER; KESSELMAN, 2003). Assim deveria ser nas grades, com ocompartilhamento flexvel de recursos computacionais, em forma de ferramentas colabo-rativas que poderiam ser acessadas de qualquer ponto.

2.1.3 Desktop Grid

Desktop Grids so grades computacionais que, em contraste aos clusters, apresentamas seguintes propriedades:

Os ns da grade so tipicamente heterogneos. As taxas de transferncia das conexes tambm podem variar, podendo apresentar

ligaes extremamente lentas.

Os ns no esto necessariamente centralizados em um mesmo local, e podem estardispersos por todo o mundo, conectando-se atravs da Internet.

Os ns so volteis, i.e. as mquinas podem parar de responder (ou voltar a faz-lo)a qualquer momento.

Enterprise Desktop Grid

As Enterprise Desktop Grids (KONDO et al., 2007), ou Desktop Grids Empresariais,so restritas rede local de uma nica corporao. Esta restrio normalmente implica emuma rede mais rpida, uma vez que comum observar este tipo de grade com conexesde 100Mb/s e 1Gb/s.

2.1.4 Balanceamento de Carga

O balanceamento de carga uma prtica utilizada para atingir um aproveitamentotimo dos recursos do sistema distribudo, atravs de uma politica de alocao de trabalhocoerente com a capacidade de processamento dos dispositivos do sistema, a fim de obtero mesmo nvel de esforo em todos os recursos (TOTH, 2008).

2.2 MapReduce

O MapReduce, criado pela Google, um modelo de programao paralela para pro-cessamento largamente distribudo de grandes volumes de dados. Seu objetivo facilitara programao de aplicativos distribudos com este perfil. Para tal, o modelo inspira-senas primitivas Map e Reduce presentes em diversas linguagens funcionais, como Lisp eHaskell, por exemplo. Esta abordagem foi adotada pois verificou-se que, em muitos ca-sos, era necessrio mapear fragmentos dos dados de entrada a uma chave identificadora, eento processar todos os fragmentos que compartilhassem a mesma chave (DEAN; GHE-MAWAT, 2008).

14

Assim, a tarefa principal do programador implementar estas duas funes, indicandocomo o mapeamento e reduo dos dados sero computados. Todo o trabalho de distribui-o do sistema incluindo problemas de comunicao, tolerncia a falhas, concorrncia,etc. abstrado, e fica a cargo do prprio framework. Durante a execuo, as funesrecebem e emitem dados no formato de pares chave, valor. Como o tipo destes elemen-tos dependem da aplicao que ser executada, cabe ao desenvolvedor, tambm, definirestas propriedades.

Um exemplo de uso do MapReduce demonstrado na Figura 2.1, a qual contmuma aplicao cujo objetivo contar a quantidade de ocorrncias de cada palavra em umdocumento. No pseudocdigo, cada chamada da funo map recebe como valor umalinha de texto do documento, e como chave o nmero desta linha. Para cada palavraencontrada na linha recebida, a funo emite um par chave/valor, onde a chave a palavraem si, e o valor a constante 1 (um). A funo reduce, por sua vez, recebe comoentrada uma palavra (chave), e um iterador para todos os valores emitidos pela funomap, associados com a palavra em questo. Todos os valores so ento somados e um parchave/valor, contendo a palavra e seu total de ocorrncias, emitido.

1 Function map (Integer chave, String valor):2 #chave: nmero da linha no arquivo.3 #valor: texto da linha correspondente.4 listaDePalavras = split (valor)5 for palavra in listaDePalavras:6 emit (palavra, 1)7

8 Function reduce (String chave, IntegerIterator valores):9 #chave: palavra emitida pela funo map.

10 #valores: conjunto de valores emitidos para a chave.11 total = 012 for v in valores:13 total = total + 114 emit (palavra, total)

Figura 2.1: Pseudocdigo de programao no MapReduce

Para auxiliar no entendimento, a Figura 2.2 ilustra o fluxo de execuo e dados paraesta aplicao. Como entrada utilizado um arquivo texto com apenas duas linhas, cujoscontedos so primeira linha e segunda linha.

Para cada linha de texto do arquivo de entrada feita uma chamada funo map.Logo, como o arquivo possui duas linhas, duas chamadas so realizadas. Em seguida,cada funo map gera n pares chave, valor intermedirios, onde, nesta aplicao, n igual quantidade de palavras contidas na linha de texto recebida pela funo. Como cadalinha possui duas palavras, um total de quatro pares intermedirios so criados. Na fasede reduo, todos os pares intermedirios que esto associados a uma mesma chave (nestecaso, uma palavra do documento) so passados para uma chamada da funo reduce.Portanto, como existem trs palavras distintas (primeira, linha e segunda), trs re-dues so executadas. Por fim, a execuo da funo reduce retorna a soma de todosos valores presentes na lista de pares recebidos. Os resultados finais so armazenados noarquivo de sada.

15

Figura 2.2: Fluxo simplificado de execuo e dados do MapReduce

Outros exemplos de programas facilmente expressos no modelo MapReduce so: grepdistribudo, frequncia de acesso a URLs, grafo reverso de links web, ndice invertido,ordenamento distribudo, dentre outros (DEAN; GHEMAWAT, 2008).

2.2.1 Arquitetura do Framework

O modelo MapReduce pode ser executado sobre uma variedade de plataformas e am-bientes distintos. Logo, a melhor implementao do framework depende do ambientealvo. Uma implementao feita para utilizar a GPU de uma mquina, por exemplo, pro-vavelmente ser beneficiada por um comportamento distinto a uma implementao desti-nada a um grande cluster.

O Google MapReduce foi desenvolvido para grandes clusters de mquinas de prate-leira1, interligadas por uma rede do tipo switched Ethernet (DEAN; GHEMAWAT, 2008),e constitudo por basicamente dois tipos de ns: Master e Worker (denominados Mestree Trabalhador em portugus, respectivamente).

O n mestre tem como funo atender requisies de execuo (denominadas jobs2

em ingls) efetuadas pelos usurios, e gerenci-las, criando vrias tarefas (do ingls tasks)e delegando-as aos ns trabalhadores, que por sua vez so encarregados de executar defato essas tarefas, aplicando, de acordo com seu tipo, as funes map ou reduce definidaspelo usurio. Como possvel perceber, trata-se de uma tpica arquitetura mestre-escravo(do ingls master-slave) (DUBREUIL; GAGN; PARIZEAU, 2006).

A arquitetura compreende, ainda, um sistema de arquivos distribudo, onde ficam ar-mazenados os dados utilizados como entrada para os jobs. Para evitar a transfernciaexcessiva de dados, os workers do MapReduce so tambm ns do sistema de arquivos.Mais detalhes sobre este recurso so apresentados nas sees 2.2.3 e 2.3.3.

1Computadores de baixo a mdio custo. Sem hardware tolerante a falhas, por exemplo. Em ingls estetipo de equipamento denominado Commodity Machine.

2Em mais detalhes, um job refere-se a cada solicitao de execuo realizada por um usurio, e.g.executar o programa que computa a frequncia de palavras. Cada job, por sua vez, constitudo por diversastarefas (tasks) de mapeamento e reduo, criadas pelo prprio framework.

16

2.2.2 Etapas e Otimizaes Internas

Alm das fases de mapeamento e reduo, que consistem na execuo de fato dasfunes map e reduce criadas pelo programador, quatro outras etapas so caractersticasdurante a execuo do framework MapReduce. Elas so conhecidas como Input splitting,Shuffle, Sort e Combine. As trs primeiras so referenciadas, porm no detalhadas, naFigura 2.2.

A etapa Input splitting (VENNER, 2009) consiste na leitura e diviso dos dados deentrada. Cada intervalo gerado, chamado de input split, normalmente varia de 16 a 64megabytes (diretamente relacionado com o tamanho dos blocos do sistema de arquivosdistribudo) e utilizado como entrada para uma tarefa de mapeamento. Aps a diviso,cada tarefa l o contedo de seu input split e gera pares chave/valor que sero passa-dos a vrias chamadas da funo map definida pelo usurio. O componente responsvelpela leitura dos input splits conhecido como Reader (ou leitor em portugus) (DEAN;GHEMAWAT, 2008).

Cada implementao do modelo MapReduce possui uma variedade de leitores e, nor-malmente, permite que os programadores desenvolvam seus prprios componentes. As-sim o programador pode criar readers para casos especficos, como ler tuplas de um bancode dados ou registros de um arquivo binrio, por exemplo. Vale ressaltar, ainda, quecada input split recebido por uma tarefa de mapeamento, pode gerar vrias chamadas dafuno map criada pelo usurio. No exemplo da seo 2.2, uma tarefa de mapeamentochamaria a funo para cada linha de texto contida no input split, por exemplo. Estapossibilidade de extenso permite que o framework no apenas suporte uma variedade desistemas de armazenamento, mas possibilita, tambm, a utilizao de ndices pr-geradossobre os dados de entrada. ndices de bancos de dados e log rollover so exemplos citadosem (DEAN; GHEMAWAT, 2010).

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

A fase Shuffle (VENNER, 2009; WHITE, 2009), realizada a partir do momento emque cada tarefa de mapeamento passa a produzir pares intermedirios, dividida em doispassos distintos: particionamento e ordenamento. No primeiro, os pares chave/valor sodivididos em R parties de acordo com a tarefa de reduo de destino de cada chave.Logo, o valor de R corresponde quantidade de tarefas de reduo do job. J no passo deordenamento, as chaves pertencentes a uma mesma partio so ordenadas para facilitarposterior processamento. importante destacar que cada tarefa de reduo pode proces-sar vrias chaves, porm uma nica chamada funo reduce do usurio ser feita para

17

cada chave, i.e. uma funo de reduo deve processar todos os valores associados a umadeterminada chave.

Como previamente comentado, uma tarefa de reduo deve processar todas as parti-es a ela destinadas. Estes dados, contudo, esto espalhados pelos ns da rede, pois omapeamento normalmente realizado em mais de um worker. Portanto, o redutor devecopiar e fundir as parties a ele destinadas, e que foram geradas durante o Shuffle. Esteprocesso de aglutinao de parties comuns realizado na fase Sort (VENNER, 2009;WHITE, 2009). A etapa recebe este nome pois a fuso dos dados d-se atravs de ummerge-sort, otimizado pelo passo de ordenamento realizado no Shuffle, e que resulta emuma garantia de sada ordenada (por partio). A Figura 2.3 ilustra o fluxo de dados nasfases de Shuffle e Sort.

A etapa Combine, por sua vez, definida por uma funo do usurio, assim comoas fases de mapeamento e reduo, porm no obrigatria. Ela consiste em um pr-processamento da reduo, e prov um significativo ganho de desempenho para certasclasses de aplicaes (DEAN; GHEMAWAT, 2008). Esta etapa ocorre em cada workerque executa uma tarefa Map, aps o passo de ordenamento realizado durante o Shuffle.Em muitos casos, a funo reduce do usurio associativa e comutativa, tornando possvelo processamento disjunto dos valores associados a uma mesma chave. A aplicao quecomputa a frequncia de palavras um bom exemplo de tais propriedades. Considereque a funo combine igual funo reduce e que o arquivo de entrada contm aseguinte linha de texto duas vezes: palavra palavra.

Figura 2.4: Fluxo de dados da funo Combine

O fluxo de dados para o exemplo em questo demonstrado na Figura 2.4, ondeos dados iniciais, mais esquerda de cada bloco, representam os pares intermediriosemitidos pelas instncias da funo map (que so duas, devido quantidade de linhasda entrada). Neste exemplo dois workers distintos realizam os mapeamentos. possvelperceber que sem a funo combine o redutor teria que buscar e processar quatro paresintermedirios, enquanto que, ao utilizar o combine, somente dois pares so manipuladosna reduo. Logo, verifica-se que esta etapa reduz o trfego de informaes na rede e aquantidade de trabalho centralizado no redutor.

2.2.3 GFS

primeira vista, o processo de execuo do MapReduce parece transferir um grandevolume de dados pela rede para que os workers possam processar as informaes. Esteproblema, no entanto, no apresenta o impacto esperado devido a alguns fatores impor-tantes. Como visto, a funo combine um deles, realizando redues parciais sobre

18

os pares intermedirios. possvel, ainda, observar que um worker responsvel por ummapeamento, pode vir a realizar a reduo dos dados computados durante o Map, evi-tando a cpia desses dados. Um outro importante recurso utilizado pelo framework, a utilizao de um sistema de arquivos distribudo (ou apenas DFS, abreviado do inglsDistributed File System), o qual influencia fortemente a implementao do MapReduce.No framework da Google, este recurso representado pelo GFS.

O Google File System (GFS) um sistema de arquivos distribudo para aplicaescom processamento intensivo de dados (GHEMAWAT; GOBIOFF; LEUNG, 2003). Suaarquitetura consiste em um n master, e diversos chunkservers. Ambos os tipos de ns soconstitudos por mquinas de prateleira, rodando servidores a nvel de usurio. A arqui-tetura, ilustrada na Figura 2.5, considera, ainda, mquinas clientes (clients) que acessamo sistema de arquivos concorrentemente.

Figura 2.5: Arquitetura do GFS (GHEMAWAT; GOBIOFF; LEUNG, 2003)

O n mestre encarregado de manter e controlar todos os metadados do sistema dearquivos, incluindo espao de nomes (namespace), mapeamento de arquivos a chunks(pedaos de arquivos, que podem ser traduzidos como blocos do sistema de arquivos),localizao dos chunks, dentre outros. O n mestre centraliza, tambm, diversas ativida-des como balanceamento de carga dos chunkservers, garbage collection, e atendimento arequisies 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 caracterstica fundamental para obom desempenho do sistema.

Como comentado, existe uma forte ligao entre o DFS e a implementao do Map-Reduce. Isto ocorre pois os workers so tambm chunkservers, portanto, quando o esca-lonador do MapReduce atribui uma tarefa de mapeamento a um worker, ele tenta faz-lopara um n que j possua, em sua unidade de armazenamento local, uma rplica doschunks que devem ser processados, a fim de evitar a transferncia de informaes pelarede. Quando esta atribuio no pode ser realizada, o escalonador tenta passar a tarefa mquina que estiver mais prxima3 ao chunkserver que possui os dados (DEAN; GHE-MAWAT, 2008).

3O conceito de proximidade em redes bastante subjetivo, e pode referir-se, por exemplo, quantidadede ns em um caminho, ao tempo de transferncia de dados entre dois ns, e at mesmo proximidadegeogrfica. No contexto do framework MapReduce, considera-se que dois ns so prximos quando elescompartilham uma storage de dados no cluster, ou esto ligados a um mesmo switch, por exemplo.

19

Assim, quando executa-se grandes operaes MapReduce, envolvendo uma signifi-cante frao de ns do cluster, a maioria dos dados so lidos localmente e o consumo debanda praticamente nulo (DEAN; GHEMAWAT, 2008).

2.2.4 Backup Tasks

Considerando a arquitetura e funcionamento do MapReduce, seus criadores identifica-ram um possvel problema de desempenho causado por mquinas cuja performance estaqum dos demais ns da grade. Essas mquinas so denominadas stragglers (DEAN;GHEMAWAT, 2008).

Uma mquina pode tornar-se lenta por diversos problemas de hardware e software.Neste caso, as tarefas executadas em um straggler atrasam o processamento como umtodo, especialmente quando a lentido 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 so cpias de tarefas em andamento no final de operaes de ma-peamento e reduo. Quando qualquer uma das cpias de uma tarefa finalizada comsucesso, as demais so encerradas (DEAN; GHEMAWAT, 2008).

A execuo das backup tasks resulta em um alto ganho de desempenho nos jobs doMapReduce. Como exemplo deste ganho, (DEAN; GHEMAWAT, 2008) aponta um al-goritmo de ordenamento que, sem a utilizao das backup tasks, apresenta um aumentode 44% no tempo de execuo do job em relao ao comportamento normal (com backuptasks).

2.3 Hadoop

Uma das implementaes mais conhecidas do MapReduce faz parte do projetoHadoop, mantido pela Apache Software Foundation (APACHE, 2010), e que tem comofinalidade desenvolver software livre para computao distribuda, escalvel e confivel(HADOOP, 2010a). O Hadoop MapReduce uma implementao em Java do modeloe framework criado pela Google, o qual foi originalmente desenvolvido em C++. Umexemplo de programao no Hadoop pode ser visto no Anexo A.

Os conceitos que servem como base para o framework do Hadoop seguem o modelodefinido no trabalho de (DEAN; GHEMAWAT, 2008), o qual foi apresentado nas se-es anteriores. Logo, seu funcionamento extremamente semelhante ao framework daGoogle.

Google Hadoop

Master JobTrackerWorker TaskTrackerBackup task Speculative taskGFS Master HDFS NameNodeGFS Chunkserver HDFS DataNode

Tabela 2.1: Comparao da terminologia utilizada no Hadoop

Em alguns pontos da implementao, a terminologia utilizada difere do que foi previ-amente apresentado, porm possvel relacionar os termos equivalentes. Os conceitos de

20

n Master e Worker, por exemplo, so respectivamente denominados JobTracker e Task-Tracker no Hadoop. A Tabela 2.1 relaciona mais algumas equivalncias de nomenclaturae tecnologias.

2.3.1 Escalonamento de Tarefas

Assim como o framework da Google, o Hadoop MapReduce apresenta uma arqui-tetura cliente-servidor. O cdigo dos workers, portanto, constitudo de um simplesheartbeat4 que envia o estado do n ao mestre, e aguarda tarefas para ento process-las.

Quando um worker indica que est disponvel para receber mais trabalho, o n mestrelhe 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

(a) que processe dados de um bloco local, j armazenado no worker (uma vez queestes so tambm ns do HDFS).

(b) que processe dados que esto em um outro n (neste caso o worker deve rece-ber o bloco pela rede diretamente do n que o possui).

(c) especulativa (tarefas j em execuo, porm lentas).

2. Se no existem mais tarefas de mapeamento, o n mestre passa a escalonar as tarefasde reduo. Primeiramente tarefas pendentes e, por fim, tarefas especulativas. Nareduo no existe o conceito de blocos locais, uma vez que a entrada para estastarefas consiste dos resultados das tarefas de mapeamento, que esto distribudosentre os ns da grade.

Existe ainda um escalonamento entre tarefas de jobs distintos. Atualmente o algoritmoutilizado denominado Fair Scheduler, e busca uma distribuio justa da capacidade docluster entre os usurios (WHITE, 2009). O escalonamento entre jobs, contudo, no serabordado neste trabalho.

2.3.2 Execuo Especulativa

No Hadoop, a execuo especulativa (do ingls speculative execution) (WHITE,2009) representa o mecanismo de backup tasks do framework da Google.

As tarefas especulativas so executadas nos ns do cluster somente quando todas asoutras tarefas (map ou reduce)5 regulares j foram concludas, e somente para tarefasque j esto executando h pelo menos um minuto e no conseguiram atingir o mesmoprogresso, em mdia, que as demais tarefas do job (WHITE, 2009).

Para identificar as mquinas lentas, cada n do cluster envia seu progresso, e outrasinformaes, atravs do sinal de heartbeat (WHITE, 2009). Para tarefas de mapeamento,o progresso calculado atravs da frao de dados j processados, enquanto que nas ta-refas de reduo, cada fase (cpia, ordenamento e reduo) representa 1/3 do andamento(cada fase, contudo, tem seu progresso determinado em funo dos dados processados,como no mapeamento) (ZAHARIA et al., 2008).

4Mensagem enviada periodicamente ao n mestre, contendo informaes sobre o estado do worker.5O mecanismo de execuo especulativa atua no fim das fases de mapeamento e reduo de maneira

independente. No Hadoop possvel desativar o mecanismo em qualquer uma das fases, ou ambas.

21

2.3.3 HDFS

Assim como sua implementao do MapReduce, o projeto Hadoop prov uma al-ternativa Java para o GFS. O Hadoop Distributed File System (HDFS) um sistema dearquivos distribudo altamente tolerante a falhas projetado para rodar sobre hardware deprateleira (HADOOP, 2010b).

A plataforma Hadoop suporta diversos sistemas de arquivos distintos, como AmazonS3 (Native e Block-based), CloudStore, HAR, sistemas mantidos por servidores FTP eHTTP/HTTPS (este ltimo apenas como leitura), Local (destinado a unidades de armaze-namento conectadas localmente), dentre outros (WHITE, 2009). O HDFS, contudo, seusistema de arquivos padro.

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

A arquitetura do HDFS, ilustrada na Figura 2.6, segue os moldes do GFS, apresenta-dos em (GHEMAWAT; GOBIOFF; LEUNG, 2003) (HADOOP, 2010c). Assim como osistema de arquivos da Google, o HDFS possui um n mestre (denominado NameNode)responsvel por atender requisies dos usurios e gerenciar a localizao dos dados, evrios ns de dados (DataNodes) que armazenam e transmitem os dados aos usurios queos requisitarem.

Outra propriedade importante do HDFS a distribuio de dados. O sistema de ar-quivos busca manter um balanceamento na porcentagem de ocupao das storages que oconstituem atravs da redistribuio e re-replicao de blocos (WHITE, 2009).

Uma importante funcionalidade do HDFS, e que impacta fortemente no desempenhodo MapReduce, conhecida como rack awareness. Atravs desse recurso, o HDFS capaz de identificar quais DataNodes pertencem a um mesmo rack, e a partir dessa in-formao, distribuir as rplicas de maneira mais inteligente aumentando a performance eresilincia do sistema (WHITE, 2009).

22

2.4 Consideraes Finais

Este captulo proveu um conhecimento razoavelmente detalhado das tecnologias ne-cessrias para a compreenso e contextualizao dos problemas estudados neste trabalho.Foi possvel observar, tambm, que a implementao do Hadoop MapReduce, e o ambi-ente alvo do framework, so muito prximos soluo da Google.

O prximo captulo avalia possveis problemas nos sistemas apresentados, fazendouso das informaes deste captulo.

23

3 MAPREDUCE EM AMBIENTES HETEROGNEOS

A seguir realizado um estudo sobre o comportamento do Hadoop MapReduce emambientes heterogneos. So apontados possveis problemas de desempenho advindos daimplementao do framework, e posteriormente so propostas adaptaes ao sistema deexecuo especulativa e distribuio de dados, a fim de adequ-los a ambientes heterog-neos.

3.1 Descrio do Problema

O Hadoop MapReduce, apesar de construdo para mquinas de prateleira, consideraque o ambiente de execuo homogneo. De acordo com (ZAHARIA et al., 2008;KONWINSKI, 2009), a partir desta, as seguintes outras suposies so feitas pelo fra-mework:

Os ns apresentam uma taxa de trabalho semelhante. As tarefas progridem com uma taxa constante no tempo (exceto no caso de mqui-

nas faltosas).

No h custo no lanamento de tarefas especulativas para um n que, caso contrrio,estaria ocioso.

Tarefas tendem a ser lanadas e finalizadas pelos ns no mesmo instante de tempo,logo uma tarefa com baixo progresso indica um straggler.

Tarefas do mesmo tipo (Map ou Reduce) requerem aproximadamente o mesmoesforo.

Este comportamento suposto pelo Hadoop se confirma em uma importante parcelados jobs executados em ambientes homogneos. Porm, quando o ambiente de execuo heterogneo, muitas dessas suposies so quebradas. A ltima, contudo, se mantmem ambientes heterogneos pois inerente ao paradigma MapReduce (ZAHARIA et al.,2008).

Quando o ambiente heterogneo, tarefas apresentam um progresso dspar em fun-o do poder computacional dos workers. Logo, esperado que mquinas mais lentasapresentem uma taxa de trabalho menor, levando mais tempo para completar as tarefas,apesar de no estarem em um estado defeituoso. Neste caso, o lanamento de tarefasespeculativas resulta em um consumo excessivo de recursos, prejudicando os demais nsda grade, especialmente quando vrios jobs so executados simultaneamente (ZAHARIAet al., 2008; KONWINSKI, 2009).

24

A distribuio de dados no sistema de arquivos tambm pode impactar negativamentedo desempenho do MapReduce em ambientes heterogneos. Como previamente comen-tado, o HDFS busca manter a mesma proporo de uso dos discos do cluster. Assim, emdeterminadas configuraes, uma mquina lenta pode possuir a mesma quantidade (oumais) de dados que as demais. Caso outra mquina receba a tarefa de processar estesdados, necessrio transferi-los pela rede, consumindo banda e tempo.

3.2 Trabalhos Relacionados

O comportamento do Hadoop MapReduce em ambientes heterogneos j foi previa-mente analisado e trabalhado por outros pesquisadores.

Em (ZAHARIA et al., 2008; KONWINSKI, 2009) realizado um estudo que mos-tra a degradao de performance gerada pelo escalonador de tarefas do Hadoop, quandoexecutado sobre um ambiente heterogneo. Os testes foram conduzidos sobre o ambi-ente virtualizado Elastic Compute Cloud (EC2) da Amazon. apresentado, ainda, umnovo algoritmo de escalonamento, o Longest Approximate Time to End (LATE), que altamente robusto para ambientes heterogneos, e est relacionado com o mecanismo detarefas especulativas. De acordo com a pesquisa, este novo algoritmo conseguiu reduziro tempo de resposta do Hadoop pela metade em determinadas situaes.

Uma viso diferente de heterogeneidade abordada em (TIAN et al., 2009), onde talpropriedade observada na natureza das tarefas (CPU-bound e I/O-bound) e no no podercomputacional dos ns, mas que, apesar disso, prov uma melhora de aproximadamente30% no throughput do Hadoop atravs da paralelizao desses tipos de tarefas.

O trabalho realizado por (UCAR et al., 2006), apesar de no relacionar-se diretamentecom MapReduce, apresenta contribuies na distribuio de tarefas para processadoresheterogneos. Assim, como os fluxos de execuo em um cluster Hadoop esto vincula-dos com os processadores dos ns, as ideias apresentadas no estudo podem ser aproveita-das no ambiente MapReduce.

Em (WANG et al., 2009a,b) apresentado um simulador para o modelo MapReduce,chamado MRPerf, que utiliza o simulador de redes ns-2 como base para a simulao derede. No trabalho so expostos os recursos do MapReduce modelados pelo simulador, eso apresentados os resultados de uma validao do mesmo. De acordo com os autores,a replicao de blocos do sistema de arquivos distribudo, e o mecanismos de execuoespeculativa, no esto presentes no simulador. A falta destes recursos influenciam nasimulao do MapReduce sobre ambientes heterogneos, motivando o desenvolvimentode um novo simulador.

3.3 Modificaes Propostas

Com base nos problemas apresentados, advindos da execuo do Hadoop em ambi-entes heterogneos, este trabalho prope modificaes no comportamento deste sistema,atravs de adaptaes no mecanismo de execuo especulativa e distribuio de dados.Ambas modificaes so implementadas e avaliadas atravs de simulao, conforme serdemonstrado nos captulos seguintes.

As modificaes, contudo, no abordaro o problema da volatilidade de ns em Desk-top Grids, i.e. considera-se que as mquinas possuem capacidades de processamentodistintas, mas que estaro disponveis durante todo o perodo de execuo. Consequente-mente, problemas de tolerncia a falhas sero tambm desconsiderados.

25

O ambiente sobre o qual as modificaes sero avaliadas, portanto, consiste em umDesktop Grid empresarial no voltil. Esta configurao permite realizar uma anliseinicial das solues propostas, que atacam mais diretamente a propriedade de heteroge-neidade, a qual est presente no ambiente escolhido.

3.3.1 Modificao 1 - Distribuio de Dados

A primeira adaptao proposta, consiste em realizar um balanceamento de carga vin-culado capacidade de processamento dos ns, e no capacidade de armazenamento,como feito na verso atual do Hadoop.

A Figura 3.1 demostra a distribuio de dados realizada no HDFS quando os nspossuem mesma capacidade de armazenamento. Neste caso, mesmo que as mquinasapresentem poderes computacionais distintos, a quantidade de blocos armazenados emcada n a mesma. Na figura, a mquina B possui metade da capacidade de processa-mento de A, mas ambas armazenam 6 chunks cada, totalizando 12 blocos. Desta forma, on A acabaria de processar seus dados locais antes de B, e seria ordenado pelo n mestrea processar dados armazenados no outro n, gerando trfego de rede.

Figura 3.1: Distribuio de dados no HDFS

A modificao proposta pode ser observada na Figura 3.2, onde a capacidade dosns considerada na distribuio dos dados. A mquina A, por apresentar o dobro dopoder computacional de B, armazena tambm o dobro de dados, obviamente totalizandoos mesmos 12 blocos.

Figura 3.2: Nova distribuio de dados proposta

26

O objetivo deste balanceamento de carga explorar ao mximo a localidade dos dadosdurante a execuo dos jobs MapReduce, evitando a transferncia dos dados em tempode execuo.

Se considerarmos que ci a capacidade de processamento de um n i, C o somatriode todos os ci (representando o poder computacional da grade como um todo) e B aquantidade de blocos da entrada, ento a quantidade de blocos que cada n i deve receber(bi) definida atravs da frmula

bi =ciCB. (3.1)

Portanto, no exemplo anterior, as mquinas A e B tm suas quantidades de blocosrespectivamente definidas pelas equaes

bA =100

150 12 = 8

bB =50

150 12 = 4

Com esta distribuio, ambos os ns processam a totalidade de seus dados locais aomesmo tempo (Figura 3.3). Suponha que a mquina A processe 2 blocos por minuto,e B apenas 1 bloco por minuto. Neste caso, tanto A quanto B levariam 4 minutos paraprocessar seus 8 e 4 blocos respectivamente, evitando transferncia de informaes pelarede.

Figura 3.3: Processamento dos dados distribudos no HDFS

3.3.2 Modificao 2 - Execuo Especulativa

Em um ambiente heterogneo, os ns mais lentos, i.e. com menor capacidade de pro-cessamento, sero sempre considerados como stragglers pelo Hadoop. Porm, em umambiente heterogneo, este progresso dspar considerado normal, e deve ser previstopelo escalonador de tarefas. Assim, uma vez que a quantidade de dados tenha sido dis-tribuda de acordo com a poder computacional de cada n como proposto na primeira

27

modificao espera-se que, mesmo com um progresso dspar, os ns acabem a totali-dade de suas tarefas locais em um mesmo intervalo de tempo.

Portanto, a segunda modificao busca identificar stragglers atravs de uma medidaproporcional a sua capacidade de processamento, e no em relao mdia da grade.Consequentemente, um n com menor poder computacional ser marcado como stragglerapenas quando estiver abaixo de sua lentido esperada.


As modificaes apresentadas so exemplos de estudos e melhorias que podem serbuscadas no modelo MapReduce. Outros possveis problemas e situaes podem serestudados, bem como diferentes solues para os problemas apresentados, conforme ostrabalhos relacionados demostram.

Aps a identificao de uma soluo terica, uma etapa de validao deve ser exe-cutada. O plano para a realizao destes testes, e os recursos necessrios para tal, soapresentados no captulo seguinte.

28

4 METODOLOGIA

Neste captulo sero apresentadas as decises tomadas para a realizao do estudoproposto neste trabalho, como esta tarefa ser realizada, bem como as ferramentas e re-cursos utilizados neste processo, que representam o ambiente utilizado durante os testes.

4.1 Plano

Atualmente as redes de computadores variam de dezenas a milhares de dispositivos,com vrios nveis de heterogeneidade. As modificaes propostas ao Hadoop, portanto,devem apresentar resultado positivo em qualquer configurao. A fim de viabilizar tes-tes em uma variedade aceitvel de configuraes, optou-se pelo desenvolvimento de umsimulador referenciado a partir de agora como MRSG (acrnimo para MapReduce-SimGrid) para implementar e testar o novo comportamento.

A deciso de implementar um novo simulador decorreu da escassez de variedade, eda falta de alguns recursos das solues existentes. A indisponibilidade destes recursosimpacta de maneira importante na simulao do MapReduce em ambientes heterogneos.O MRPerf (WANG et al., 2009b,a), por exemplo, um simulador para o modelo Map-Reduce que utiliza o simulador de redes ns-2 como base para sua soluo. Dentre osrecursos mais relevantes para este trabalho, e no implementados pelo MRPerf, pos-svel citar a replicao de blocos de dados do HDFS limitada a 1 (uma) rplica porbloco , e o mecanismo de execuo especulativa (WANG et al., 2009b,a). Em ambi-entes heterogneos, a falta de rplicas implica a transferncia desnecessria de blocos nafase de mapeamento, uma vez que o n mais rpido acabar suas tarefas locais primeiro,e ser forado a buscar mais dados nos demais ns. A execuo especulativa tambm de fundamental importncia, conforme explicado nos captulos anteriores.

4.2 Ambiente de Desenvolvimento e Testes

A seguir sero apresentadas as tecnologias e recursos utilizados no desenvolvimentodo simulador MRSG, bem como em sua validao em relao ao comportamento real dosistema.

4.2.1 SimGrid

O desenvolvimento de um simulador de grades envolve diversos subproblemas rela-cionados com a simulao de redes e compartilhamento de recursos de processamento.Esta no uma tarefa trivial, e por si s implica grande esforo de projeto e validao dosimulador. Por esta razo optou-se pela utilizao de um simulador de grades existente

29

como base para o desenvolvimento deste trabalho. O simulador escolhido para este fimfoi o SimGrid.

O SimGrid (SIMGRID, 2010a) um conjunto de ferramentas que prov funcionalida-des para a simulao de aplicaes distribudas em ambientes heterogneos. Seu objetivo justamente facilitar a pesquisa na rea de plataformas paralelas e distribudas.

Diversos pesquisadores, vinculados a uma variedade de universidades de todo omundo, utilizam, ou j utilizaram, o SimGrid em publicaes cientficas, reforando aconfiabilidade do sistema (SIMGRID, 2010b).

O SimGrid prov diversas interfaces de programao (ou API, quando abreviado doingls Application Programming Interface) para uma variedade de linguagens. A Figura4.1 ilustra a arquitetura do simulador, e a relao entre seus componentes.

Figura 4.1: Relao entre os componentes do SimGrid (SIMGRID, 2010a)

Elencadas abaixo, esto as APIs disponibilizadas pelo SimGrid, e suas respectivascaractersticas.

MSG Voltada ao estudo e comparao de algoritmos e heursticas, como escalonamentode tarefas em sistemas distribudos, por exemplo. A interface prov funes simu-ladas de troca de mensagens e processamento de tarefas. Sua linguagem nativa deprogramao o C, porm existem implementaes para Lua e Java.

GRAS Utilizada no desenvolvimento de aplicaes reais. Alm de realizar simulaesdos aplicativos desenvolvidos com a API (com a finalidade de testar a implementa-o), a interface permite a execuo em ambientes distribudos reais.

SMPI Como o nome sugere, esta interface visa o estudo do comportamento de aplica-es MPI atravs de emulao, i.e. utiliza-se cdigo de aplicaes MPI reais nomodificadas, e o simulador emula a execuo paralela dos fluxos. Este ambiente deprogramao ainda encontra-se em fase de desenvolvimento.

SimDag Utilizado para simular aplicaes que seguem um modelo de grafo acclico di-recionado (DAG, abreviado do ingls Directed acyclic graph).

Apesar do modelo MapReduce e seu fluxo de dados seguirem um formato DAG, suasimplementaes, incluindo o Hadoop, proveem uma srie de recursos para tolerncia afalhas e otimizao de desempenho como a execuo especulativa, por exemplo que

30

divergem deste modelo. Dito isso, a interface de programao escolhida para a simulaodo Hadoop a MSG, que prov um ambiente simplificado para a anlise dos algoritmosde distribuio de dados e escalonamento de tarefas. Atravs de abstraes no tamanho detarefas e dados, a API permite tambm a variao dessas propriedades de forma simplese gil, facilitando os testes sobre uma variedade de situaes e configuraes.

4.2.2 Grid5000

Para validar a simulao do Hadoop, necessrio comparar os resultados de sua exe-cuo com aplicaes executadas em um ambiente real. Para tal, utilizou-se a infraestru-tura da Grid5000 como ambiente de validao.

A Grid5000 (GRID5000, 2010a) uma grade computacional cientfica, que visa oestudo de sistemas distribudos e paralelos em larga escala, atravs de uma plataformaexperimental altamente reconfigurvel, controlvel e monitorvel.

Atualmente, os recursos da plataforma esto geograficamente distribudos em nove lo-cais da Frana Bordeaux, Grenoble, Lille, Luxembourg, Lyon, Nancy, Orsay, Rennes,Sophia-Antipolis e Toulouse (ilustrados na Figura 4.2) abrangendo 17 laboratrios depesquisa do pas.

Figura 4.2: Distribuio geogrfica dos clusters na Grid5000 (GRID5000, 2010a)

Para a configurao e instalao de ambientes de testes na Grid5000, existe umavariedades de ferramentas disponveis. As ferramentas utilizadas nos testes deste trabalhocompreendem o OAR e o Kadeploy.

A ferramenta OAR utilizada para gerenciar os recursos dos clusters, proporcionandouma maneira de reservar quantidades arbitrrias de ns da grade, por perodos de tempoespecificados pelo usurio.

31

O Kadeploy, por sua vez, proporciona a possibilidade de clonar a instalao de sis-temas operacionais e aplicativos, reinstal-los em outros ns, e configurar cada imagematravs do uso de scripts.

Hadoop na Grid5000

O Hadoop pode ser instalado em 3 modos: Standalone, Pseudo-Distributed e Fully-Distributed. O primeira til para testar a aplicao e depurar o cdigo, e roda como umnico processo Java, em uma nica mquina. O modo Pseudo-Distributed, assim comono Standalone, executado em apenas uma mquina, porm cada daemon do Hadooproda em um processo distinto. J o modo Fully-Distributed utilizado em sistemas deproduo, realmente distribudos.

A instalao Standalone bastante simples, e requer apenas o Java 1.6 (preferivel-mente da Sun). Para instalar, basta descompactar o pacote com os fontes, e editar o ar-quivo texto conf/hadoop-env.sh (no diretrio de instalao do Hadoop) indicandoa localizao de sua instalao Java na varivel JAVA_HOME. A partir deste ponto j possvel escrever e testar aplicativos MapReduce.

A instalao dos modos Pseudo-Distributed e Fully-Distributed requerem maioresconfiguraes. Como requisitos, ainda necessrio instalar um servio de SSH, e confi-gurar o HDFS. As configuraes necessrias envolvem definir qual mquina ser o masterno MapReduce e no HDFS, e definir os workers.

A Grid5000 uma grade real, logo, para executar aplicativos MapReduce, neces-srio realizar uma instalao Fully-Distributed do Hadoop. Para facilitar este processofoi utilizado um script de configurao, que automatiza a configurao dos ns. O script,bem como instrues detalhadas de utilizao, podem ser encontrados no tutorial pre-sente na Wiki da Grid5000 (GRID5000, 2010b). O processo realizado para os testesdeste trabalho apresentado abaixo.

Primeiramente necessrio conectar-se via SSH a um local (SITE) da Grid5000 noqual se possua um usurio vlido (USER).

ssh [email protected]

Em seguida deve-se acessar a mquina frontend, de onde possvel reservar recur-sos para o experimento.

ssh frontend

Uma vez conectado ao frontend, utiliza-se o comando oarsub para realizar areserva, indicando a quantidade hosts que deseja-se alocar (nodes=NUM_HOSTS), e porquanto tempo (walltime=HH:MM:SS). A quantidade de ns especificados aqui, sera quantidade de hosts que o Hadoop usur para distribuir a aplicao (este valor estrelacionado com a quantidade de redues explicitados no cdigo).

oarsub -I -t deploy -l nodes=NUM_HOSTS,walltime=HH:MM:SS

Se a alocao for realizada com sucesso, e a conexo com o job for estabelecida, possvel partir para a instalao do Hadoop. Para facilitar, ser utilizada uma imagempronta da instalao, e um script de configurao que definir o n mestre e demais pro-priedades relevantes. A instalo das mquinas virtuais na Grid5000 d-se atravs docomando kadeploy.

32

kadeploy3 -a ~/lenny-x64-nfs-hadoop.dsc3 -f \OAR_FILE_NODES -k ~/.ssh/id_dsa.pub -s ~/config.sh

Uma vez instalado o ambiente, deve-se conectar ao n mestre do Hadoop.

ssh [email protected]

Em seguida necessrio copiar o arquivo de entrada para o novo sistema HDFS ins-talado. Para tal utiliza-se a ferramenta do hadoop, com a opo dfs para manipular osistema de arquivos.

/opt/hadoop/bin/hadoop dfs -copyFromLocal ~/data input

Por fim basta executar a aplio, informando a localizao do arquivo de entrada e odiretrio onde a sada deve ser gravada. Ambos os caminhos referem-se ao sistema dearquivos distribudo.

/opt/hadoop/bin/hadoop jar ~/tracefilter.jar \br.ufrgs.TraceFilter input output


Este captulo apresentou o ambiente de testes e os componentes utilizados na im-plementao e validao do MRSG. Uma descrio mais detalhada do simulador e suasfuncionalidades exposta no captulo 5.

33

5 ESPECIFICAO DO SIMULADOR

Neste captulo sero expostas as decises na modelagem do MRSG, suas caractersti-cas e limitaes, sua entrada e sada, bem como uma breve comparao com os recursosdo MRPerf.

5.1 Objetivos do Simulador

O MRSG tem o objetivo de facilitar a pesquisa sobre o comportamento do MapReducee possveis modificaes nessa tecnologia. Para tal, o simulador busca proporcionar:

Uma maneira simplificada de traduzir algoritmos tericos (escalonamento de tare-fas, distribuio de dados, etc) para cdigo executvel, facilitando a anlise dessesalgoritmos.

Facilidade na variao e teste de configuraes do sistema. A possibilidade de validar algoritmos em larga escala, sendo que no necessria

uma infraestrutura real.

Abaixo esto listados os recursos considerados, pelo autor, os mais importantes nasimulao do Hadoop em ambientes heterogneos, e que devem estar presentes no MRSG.Assim, pretende-se simular:

As fases de mapeamento, cpia e reduo, modelando todas as comunicaes dedados da aplicao.

O compartilhamento de recursos de rede e processamento entre os ns da grade. A replicao de blocos do HDFS. O mecanismo de execuo especulativa.

5.2 Limitao do Estado Atual

Devido inviabilidade de implementar todos os recursos desejados para o MRSG,optou-se pela excluso de algumas propriedades de baixo impacto para a simulao dosnovos algoritmos de distribuio de dados e escalonamento de tarefas. Logo, a versoatual do sistema desenvolvido no simula:

Volatilidade e falha dos ns.

34

Configurao de racks em clusters.

As propriedades desconsideradas podem ser ignoradas no contexto deste trabalho,pois o ambiente de Desktop Grid empresarial estudado no apresenta as caractersticas deum cluster convencional, como unidades de armazenamento compartilhadas (storages),por exemplo. Como tambm no sero abordados ambientes faltosos ou volteis, ondeos ns da grade variam sua disponibilidade, a primeira propriedade no ser simulada.Vale ressaltar que o modelo atual do MapReduce tambm no considera volatilidade, i.e.perodos de indisponibilidade so tratados como falhas.

Assim, para o foco deste trabalho, o MRSG implementa todos os recursos necess-rios para avaliar o comportamento do MapReduce em ambientes heterogneos quandosubmetido s modificaes propostas na seo 3.3.

5.3 Uso do Simulador

O simulador MRSG um executvel de linha de comando (testado em plataformaLinux, x86 de 32 e 64 bits), que recebe como parmetros um arquivo descritor de plata-forma, e outro de aplicao.

O descritor de plataforma (platform file) um arquivo XML que descreve a topologiada rede e a capacidade dos recursos envolvidos, incluindo o poder computacional dos nsda grade, e latncia e banda das conexes (links, em ingls) que interligam os ns. Estearquivo um padro do SimGrid, e possui uma forma bem defina de acordo com umaDTD (Document Type Definition). Um exemplo pode ser observado no Anexo B.

O arquivo de aplicao (deploy file), por sua vez, indica a funo de cada n e identi-fica o n mestre. neste arquivo que o usurio do simulador indica as configuraes deseu ambiente MapReduce, atravs de argumentos passados ao n mestre no XML, comodemostrado no Anexo C.

Como resultado de uma simulao no MRSG, alm do progresso apresentado emtempo real no terminal, o usurio pode analisar arquivos de log criados pelo simulador, osquais proveem informaes relativas localizao de blocos do HDFS e quantidade detarefas processadas por cada n.

5.4 Comparao

A Tabela 5.1 apresenta uma breve comparao entre o MRPerf e o novo simuladorMRSG, destacando alguns dos recursos mais importantes na simulao de um modeloMapReduce, presentes nos respectivos sistemas.

Os recurso no implementados no MRSG podem ser posteriormente includos ao si-mulador, para auxiliar em pesquisas com o MapReduce. Nenhuma restrio tecnolgicaexiste em relao s bibliotecas utilizadas no desenvolvimento do simulador.


Uma vez apresentada a especificao do simulador desenvolvido durante o trabalho,o captulo seguinte analisar o simulador, avaliando e validando seu comportamento emcomparao a execuo de um sistema MapReduce real. Aps esta validao, as solu-es para os problemas encontrados no MapReduce em ambientes heterogneos seroimplementadas simulador, e tambm tero seu desempenho avaliado.

35

Propriedade MRPerf MRSG

Compartilhamento de recursos (rede, processamento) Sim SimAdequado a ambientes homogneos e heterogneos No SimPermite a configurao de racks Sim NoReplicao de blocos do HDFS No SimMecanismo de execuo especulativa No SimSimula etapas internas das tarefas de forma independente Sim NoVrias unidades de armazenamento por n No No

Tabela 5.1: Comparao de recursos com o MRPerf

36

6 RESULTADOS

Na seo seguinte sero apresentados os resultados da validao do MRSG, compa-rando as simulaes realizadas com execues reais na grid5000, e posteriormente seroapresentados os resultados obtidos com a aplicao das novas polticas de distribuio dedados e execuo especulativa, conforme proposto na seo 3.3.

6.1 Validao do Simulador

A validao do simulador foi realizada atravs da comparao entre execues reaisdo Hadoop na Grid5000 e simulaes com parmetros que adequados execuo real.

6.1.1 Descrio do Aplicativo Utilizado na Validao

O aplicativo desenvolvido para os testes de validao consiste basicamente em umfiltro de log. Mais especificamente, deseja-se ler um grande arquivo, com registros demudana disponibilidade das mquinas de um ambiente de computao voluntria, e cal-cular a mdia de disponibilidade de um certo conjunto de mquinas, que sero escolhidasatravs de alguns pr-requisitos.

O arquivo de log que ser utilizado nos testes, contm informaes coletadas peloprojeto BOINC (BOINC, 2010) uma importante plataforma para computao volunt-ria e formado por diversos registros de disponibilidade dos ns que constituem estesistema de computao voluntria. Os dados so agrupados pelo ID dos ns, i.e. todos osregistros de um n aparacem de forma consecutiva e ordenados por horrio. Cada linhado log contm os seguintes campos:

1. Nmero do registro para um determinado n (comeando em zero);

2. Identificador do n;

3. Tipo do evento (0 ou 1, indicando a disponibilidade);

4. Incio do evento;

5. Fim do evento.

Cada campo separado por um caractere de tabulao. Um exemplo de conjunto deregistros deste arquivo pode ser representado pelas seguintes linhas:

0 100416828 1 1211524407.906 1211524417.9221 100416828 0 1211524417.922 1211524440.3122 100416828 1 1211524440.312 1211615915.156

37

A partir deste exemplo possvel destacar que:

Todos os registros so referentes mesma mquina, pois o ID 100416828 nas trslinhas.

So os 3 primeiros registros desta mquina, pois o primeiro campo varia de 0 a 2.

A primeira e terceira linha so registros de disponibilidade, pois contm o valor1 no tipo do evento (terceiro campo), enquanto a segunda linha um registro deindisponibilidade.

Os campos 4 e 5 representam, respectivamente, o tempo de incio e fim de cadaevento.

No total, o arquivo utilizado contm 8.8GB de tamanho, contendo mais de 1.5 anode registros, para 226,208 hosts. A filtragem realizada em cima dos registros, consisteem selecionar apenas mquinas que participaram pelo menos 300 dias do projeto, e quepossuem disponibilidade mdia de no mximo 4000 segundos (pouco mais de 1 hora).

Ao final da execuo, espera-se obter um arquivo contendo todos os hosts que pas-saram pelo filtro, e seus respectivos tempos mdios de disponibilidade e os horrios deincio e fim dos seus registros. Ou seja, apenas uma linha por mquina vlida. Consi-derando o exemplo de log anterior, caso o host passasse pelo filtro, o arquivo resultanteconteria uma linha:

100416828 45742 1211524407 1211615915

O cdigo fonte completo desta aplicao para o Hadoop MapReduce pode ser obser-vado no Anexo D.

6.1.2 Configurao dos Jobs e Resultados

No total foram realizados testes de validao com 16, 20, 32 e 200 ncleos, de acordocom a disponibilidade encontrada na grid5000. So apresentados a seguir os resultadosobtidos para os testes com 20 e 200 ncleos. Os testes com 16 e 32 ncleos obtiveramresultados semelhantes ao teste de 20, pois as configuraes utilizadas eram semelhantes,como por exemplo, a quantidade de redues, que era igual quantidade de ncleos nostrs casos.

A tabela 6.1 apresenta a configurao para o teste com 20 ncleos em maiores deta-lhes.

Parmetro Valor/Descrio

Processador AMD Opteron 250 / 2.4GHz / 1MB / 400MHzMemria 2 GBQuantidade de ncleos 20Tamanho da entrada 8,8 GBQuantidade de reduces 20

Tabela 6.1: Parmetros da validao com 20 ncleos

38

Figura 6.1: Validao do MRSG com 20 ncleos

Estas configuraes foram reproduzidas no simulador, e a comparao do tempo deexecuo pode ser observada na figura 6.1. Cada uma das fases (mapeamento, cpia ereduo) comparada e apresentada na figura 6.2.

Atravs dos grficos 6.1 e 6.2, percebe-se uma importante proximidade entre os tem-pos de execuo real e simulado, com propores adequadas de durao para todas asfases do job. Estes resultados foram observados tambm nas execues com 16 e 32ncleos.

Na validao com 200 ncleos, a grande diferena na configurao est relacionadacom a quantidade de tarefas de reduo, conforme a tabela 6.2. Enquanto os testes ante-riores foram realizados com uma quantidade de redues igual quantidade de ncleos,nesta comparao foi utilizada apenas uma tarefa de reduo. Este teste foi realizado paraverificar como o Hadoop e o simulador comportam-se em situaes peculiares.

Parmetro Valor/Descrio

Processador AMD Opteron 2218 / 2.6 GHz / 2 MB L2 cache / 800 MHzMemria 4 GB (4x512 MB + 2x1024 MB)Quantidade de ncleos 200Tamanho da entrada 8,8 GBQuantidade de reduces 1

Tabela 6.2: Parmetros da validao com 200 ncleos

possvel observar (figura 6.3) que a diferena entre os tempos totais dos jobs reale simulado, neste caso, mais acentuada que nos testes anteriores. Para uma melhorcomparao, a figura 6.4 apresenta a diferena entre cada fase do MapReduce, apontandoa cpia como a causa desta discrepncia nos tempos de execuo.

Este comportamento pode ser explicado por diversos fatores que ocorrem no ambientereal utilizado (Grid5000), e que no foram simulados no MRSG. Como exemplo poss-vel citar a interferncia de outras pesquisas que so executadas na grade, e que, apesar de

39

Figura 6.2: Validao do MRSG com 20 ncleos (fases)

no compartilharem recursos de processamento com os ns testados, compartilham recur-sos de armazenamento e rede; e a criao de apenas uma tarefa de reduo, que implicauma nica mquina ter que copiar todos os resultados intermedirios, deixando a conexomais sensvel a interferncias externas, uma vez que seu link estava sobrecarregado.

Apesar desta diferena na cpia, o simulador apresentou o comportamento esperado,indicando um acrscimo razovel no tempo de cpia. Assim, com os resultados destascomparaes, pode-se concluir que, apesar do simulador ser passvel de melhorias, seucomportamento suficientemente prximo ao comportamento real do Hadoop para testare analisar o comportamento de algoritmos tericos.

Figura 6.3: Validao do MRSG com 200 ncleos

40

Figura 6.4: Validao do MRSG com 200 ncleos (fases)

6.2 Adaptao a Ambientes Heterogneos

Uma vez que a validao do simulador MRSG foi realizada, e resultados satisfatriospuderam ser observados, as adaptaes propostas na seo 3.3 foram desenvolvidas como simulador. Os resultados obtidos com as simulaes so apresentados a seguir, e de-mostram os ganhos de desempenho obtidos pelas novas polticas de distribuio de dadose execuo especulativa, em um ambiente heterogneo.

Os testes foram executados simulando ambientes com 100, 200, 300 e 400 ncleos. Opoder computacional desses recursos foi distribudo uniformemente, representando pro-cessadores de 800MHz a 2,4GHz. Como entrada de dados, foram definidos 10 blocos porncleo, i.e. conforme a quantidade de ncleos da simulao aumentava, o mesmo acon-tecia com a entrada. A configurao de rede foi mantida como uma Switched Ethernet de100Mb/s.

Os resultados foram analisados considerando a quantidade de tarefas geradas que ne-cessitam de transferncia de dados. Desta forma possvel avaliar custos de desempenhopara diversas situaes, com tempos de latncia e larguras de banda variveis.

A figura 6.5 mostra a quantidade de tarefas especulativas geradas pelo comportamentooriginal do Hadoop, onde possvel observar que uma grande quantidade de tarefas auxi-liares so lanadas pelo escalonador, em ambas as fases de mapeamento e reduo. Estecomportamento prejudica o prprio job, pois possveis slots de reduo so ocupados pormapeamentos especulativos, e jobs concorrentes que sofrem com o uso desses recursosde processamento e rede.

Em contrapartida, como esperado, o modificao proposta no mecanismo de execuoespeculativa no gerou nenhuma tarefa deste tipo. Como o trabalho no considera falhas,e as mquinas sempre seguem a capacidade de processamento descrita no arquivo deplataforma, os ns nunca ficam abaixo de sua mdia. Esta modificao, contudo, s fazsentido quando os dados so distribudos conforme explicado na seo 3.3.

O resultado do balanceamento de carga na distribuio de dados pode, ento, ser anali-sado pelo grfico da figura 6.6, que apresenta a quantidade de mapeamentos sobre blocosno locais para o modelo original do Hadoop e para a modificao proposta.

41

Figura 6.5: Quantidade de tarefas especulativas no modelo original

Atravs deste resultado fica evidente o ganho em termos de blocos transferidos entreos ns da grade, que muito inferior ao modelo original de distribuio do Hadoop, oqual apresenta um crescimento linear de transferncias em relao ao tamanho da grade.

Estes resultados preliminares obtidos com o simulador, apesar de apresentarem umacerta margem de erro, conseguem demonstrar claramente o impacto que novas polticas dedistribuio de dados e escalonamento de tarefas podem causar num framework complexocomo Hadoop MapReduce, e como a abordagem por simulao facilita a traduo deum algoritmo terico para testes executveis que auxiliam no desenvolvimento de novasideias.


Os resultados obtidos na validao com 16, 20 e 32 ncleos, onde a quantidade deredues era igual quantidade de ncleos, obteve-se uma proximidade bastante impor-tante com a execuo real. A simulao ficou em torno de 6,75% abaixo do tempo totaldo job observado na Grid5000. Este resultado parece satisfatrio quando comparado aoMRPerf, que apresentou resultados semelhantes em sua validao, que tambm utilizauma quantidade de redues equivalente ao nmero de ncleos, com diferenas de 3,42%no mapeamento e 19,32% na reduo, para um cluster com um nico rack (WANG et al.,2009a,b).

42

Figura 6.6: Quantidade de mapeamentos no locais

43

7 CONCLUSO

Neste trabalho foi apresentado um estudo sobre o funcionamento interno do HadoopMapReduce, necessrio para compreender todas as etapas envolvidas na execuo destesistema, e que possibilitou propor melhorias sobre a plataforma.

Foi demostrado, tambm, que as adaptaes propostas distribuio de dados e ao es-calonamento de tarefas especulativas apresentam impacto positivo na execuo do Map-Reduce, reduzindo a transferncia de dados e consumindo menos recursos. Estes novosalgoritmos de distribuio de dados e escalonamento puderam ser testados de maneiramais eficiente devido ao simulador desenvolvido durante o trabalho.

O simulador MRSG foi satisfatoriamente testado e validado contra execues reais doMapReduce e, apesar de ser passvel de melhorias e aprimoramentos, foi suficiente paraa pesquisa realizada neste trabalho.

A partir da pesquisa realizada, e destes resultados obtidos, possvel citar como pos-sveis trabalhos futuros na rea: introduzir, alm da heterogeneidade, a volatilidade aoambiente para melhor caracterizar Desktop Grids; expandir o desenvolvimento do simu-lador atravs do aprimoramento dos recursos existentes e da adio dos recursos noimplementados, sendo que um simulador para a tecnologia auxilia em pesquisas na rea.

O estudo realizado, portanto, proporciona uma introduo ao MapReduce, e levantaquestes interessantes sobre as possveis adaptaes s quais o modelo est sujeito, queno esto restritas s propostas deste trabalho. Assim, espera-se que tenha sido atingidoo objetivo de incentivar a pesquisa desta tecnologia, a qual utilizada em ambientes deproduo de grandes corporaes, e que representa as inovaes que buscamos alcanarem nossa rea de atuao.

44

REFERNCIAS

APACHE. Welcome! - The Apache Software Foundation. Disponvel em:. Acesso em: abril 2010.

BOINC. BOINC. Disponvel em: . Acesso em: Maio 2010.

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

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

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

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, 2003, New York, NY, USA. Anais. . . ACM, 2003. p.2943.

GRID5000. Grid5000: home - grid5000. Disponvel em:. Acesso em:abril 2010.

GRID5000. Run Hadoop On Grid5000. Disponvel em:. Acessoem: abril 2010.

HADOOP. Welcome to Apache Hadoop! Disponvel em: .Acesso em: abril 2010.

HADOOP. HDFS Architecture. Disponvel em:. Acesso em:abril 2010.

HADOOP. HDFS - Hadoop Wiki. Disponvel em:. Acesso em: maio 2010.

45

HADOOP. Map/Reduce Tutorial. Disponvel em:. Acessoem: junho 2010.

KONDO, D.; FEDAK, G.; CAPPELLO, F.; CHIEN, A. A.; CASANOVA, H. Characte-rizing resource availability in enterprise desktop grids. Future Generation ComputerSystems, [S.l.], v.23, n.7, p.888903, 2007.

KONWINSKI, A. Improving MapReduce Performance in Heterogeneous Environ-ments. 2009. Dissertao (Mestrado em Cincia da Computao) EECS Department,University of California, Berkeley. (UCB/EECS-2009-183).

MURUGESAN, S. Harnessing Green IT: principles and practices. IT Professional, [S.l.],v.10, n.1, p.2433, jan.-feb. 2008.

MUTKA, M. W.; LIVNY, M. Profiling Workstations Available Capacity for Remote Exe-cution. In: PERFORMANCE 87: PROCEEDINGS OF THE 12TH IFIP WG 7.3 INTER-NATIONAL SYMPOSIUM ON COMPUTER PERFORMANCE MODELLING, MEA-SUREMENT AND EVALUATION, 1988, Amsterdam, The Netherlands, The Nether-lands. Anais. . . North-Holland Publishing Co., 1988. p.529544.

SIMGRID. SimGrid Home Page. Disponvel em: .Acesso em: agosto 2010.

SIMGRID. SimGrid: people around simgrid. Disponvel em:. Acesso em: agosto 2010.

TIAN, C.; ZHOU, H.; HE, Y.; ZHA, L. A Dynamic MapReduce Scheduler for Hetero-geneous Workloads. In: GCC 09: PROCEEDINGS OF THE 2009 EIGHTH INTER-NATIONAL CONFERENCE ON GRID AND COOPERATIVE COMPUTING, 2009,Washington, DC, USA. Anais. . . IEEE Computer Society, 2009. p.218224.

TOTH, D. M. Improving the productivity of volunteer computing. 2008. Tese (Douto-rado em Cincia da Computao) Bucknell University.

UCAR, B.; AYKANAT, C.; KAYA, K.; IKINCI, M. Task assignment in heterogeneouscomputing systems. J. Parallel Distrib. Comput., Orlando, FL, USA, v.66, n.1, p.3246,2006.

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

WANG, G.; BUTT, A. R.; PANDEY, P.; GUPTA, K. Using realistic simulation for perfor-mance analysis of mapreduce setups. In: LSAP 09: PROCEEDINGS OF THE 1ST ACMWORKSHOP ON LARGE-SCALE SYSTEM AND APPLICATION PERFORMANCE,2009, New York, NY, USA. Anais. . . ACM, 2009. p.1926.

WANG, G.; BUTT, A. R.; PANDEY, P.; GUPTA, K. A simulation approach to evaluatingdesign decisions in MapReduce setups. In: 2009. Anais. . . [S.l.: s.n.], 2009. p.111.

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

ZAHARIA, M.; KONWINSKI, A.; JOSEPH, A. D.; KATZ, R. H.; STOICA, I. Im-proving MapReduce Performance in Heterogeneous Environments. [S.l.: s.n.], 2008.(UCB/EECS-2008-99).

46

ANEXO A EXEMPLO DE PROGRAMAO NO HADOOP

O cdigo fonte deste anexo apresenta um exemplo de implementao da aplicaopara contagem de ocorrncias de palavras em arquivos texto utilizando o Hadoop Map-Reduce. Fonte: (HADOOP, 2010d).

package org.myorg;

import java.io.IOException;import java.util.*;

import org.apache.hadoop.fs.Path;import org.apache.hadoop.conf.*;import org.apache.hadoop.io.*;import org.apache.hadoop.mapred.*;import org.apache.hadoop.util.*;

public class WordCount {

public static class Map extends MapReduceBaseimplements Mapper {

private final static IntWritable one = new IntWritable(1);private Text word = new Text();

public void map(LongWritable key, Text value,OutputCollector output, Reporter reporter)

throws IOException {String line = value.toString();StringTokenizer tokenizer = new StringTokenizer(line);while (tokenizer.hasMoreTokens()) {

word.set(tokenizer.nextToken());output.collect(word, one);

}}

}

public static class Reduce extends MapReduceBaseimplements Reducer {

public void reduce(Text key, Iterator values,OutputCollector output, Reporter reporter)

throws IOException {int sum = 0;while (values.hasNext()) {

sum += values.next().get();}output.collect(key, new IntWritable(sum));

47

}}

public static void main(String[] args) throws Exception {JobConf conf = new JobConf(WordCount.class);conf.setJobName("wordcount");

conf.setOutputKeyClass(Text.class);conf.setOutputValueClass(IntWritable.class);

conf.setMapperClass(Map.class);conf.setCombinerClass(Reduce.class);conf.setReducerClass(Reduce.class);

conf.setInputFormat(TextInputFormat.class);conf.setOutputFormat(TextOutputFormat.class);

FileInputFormat.setInputPaths(conf, new Path(args[0]));FileOutputFormat.setOutputPath(conf, new Path(args[1]));

JobClient.runJob(conf);}

}

48

ANEXO B ARQUIVO DESCRITOR DE PLATAFORMA

49

ANEXO C ARQUIVO DESCRITOR DE APLICAO

50

ANEXO D CDIGO FONTE DA VALIDAO DO SIMU-LADOR

package br.ufrgs;

import java.io.IOException;import java.util.*;

import org.apache.hadoop.fs.Path;import org.apache.hadoop.io.*;import org.apache.hadoop.mapred.*;

public class TraceFilter {

public static class Map extends MapReduceBaseimplements Mapper {

private LongWritable k = new LongWritable();private Text v = new Text();

/* Implementacao da funcao de mapeamento. */public void map(LongWritable key, Text value,

OutputCollector output, Reporter reporter) throws IOException {

/* Separa os campos da linha em um array. */String[] fields = value.toString().split("\\s");

/* Pega o ID da maquina do segundo campo da linha. */Long machine = new Long(fields[1]);

/* Verifica se a linha representa um evento de disponibilidade.Os registros de indisponibilidade sao ignorados. */

if (fields[2].equals("1")) {/* Emite um par chave/valor intermediario, contendo o ID da

maquina (chave) e os tempos de inicio e fim do eventoconcatenados em uma string (valor). */

k.set(machine);v.set(fields[3] + ":" + fields[4]);output.collect(k, v);

}}

}

public static class Reduce extends MapReduceBase

51

implements Reducer {

/* Implementacao da funcao de reducao. */public void reduce(LongWritable key, Iterator values,

OutputCollector output, Reporter reporter) throws IOException {

Long sum = new Long(0);Long count = new Long(0);Long traceStart = new Long(Long.MAX_VALUE);Long traceEnd = new Long(0);Long start = new Long(0);Long end = new Long(0);

/* Percorre todos os registros de uma maquina, para calcular amedia e identificar o primeiro e ultimo registro. */

while (values.hasNext()) {String line = values.next().toString();

/* Pega o inicio e fim do evento atual. */String[] tokens = line.split(":");start = new Double(tokens[0]).longValue();end = new Double(tokens[1]).longValue();

/* Verifica se eh o registro mais antigo ateh o momento. */if (start < traceStart) {

traceStart = start;}/* Verifica se eh o registro mais recente ateh o momento. */if (end > traceEnd) {

traceEnd = end;}

/* Acumula o tempo do evento atual a disponibilidade total. */sum += (end - start);

/* Incrementa a contagem de registros. */count++;

}

/* Calcula a media de disponibilidade para a maquina atual. */Long mean = new Long(sum / count);

/* Filtra os registros onde a media eh menor que 4000 segundose o tempo total eh de pelo menos 300 dias (25920000s = 300d) */

if ((mean = 25920000)) {String v = String.format("% 15d ", mean);v += String.format("% 15d ", traceStart);v += String.format("% 15d ", traceEnd);/* Emite o ID da maquina atual (chave), e sua disponibilidade media

e os tempos de inicio e fim dos registros concatenados em umastring (valor). */

output.collect(key, new Text(v));}

}}

public static void main(String[] args) throws Exception {

52

JobConf conf = new JobConf(TraceFilter.class);

conf.setJobName("TraceFilter");

/* Define o a quantidade de tarefas de reducao. */conf.setNumReduceTasks(20);

/* Define o tipo dos pares chave/valor de saida. */conf.setOutputKeyClass(LongWritable.class);conf.setOutputValueClass(Text.class);

/* Indica as classes que implementam o mapeamento e reducao. */conf.setMapperClass(Map.class);conf.setReducerClass(Reduce.class);

/* Indica o tipo dos arquivos de entrada e saida. */conf.setInputFormat(TextInputFormat.class);conf.setOutputFormat(TextOutputFormat.class);

/* Le da linha de comando a origem e destino dos arquivos no HDFS. */FileInputFormat.setInputPaths(conf, new Path(args[0]));FileOutputFormat.setOutputPath(conf, new Path(args[1]));

JobClient.runJob(conf);}

}

estudo hadoop

Documents