Processamento de Dados Massivos PDF

PDF gerado usando o pacote de ferramentas em cdigo aberto mwlib. Veja http://code.pediapress.com/ para mais informaes.
PDF generated at: Wed, 03 Sep 2014 19:11:16 UTC

Processamento de Dados
Massivos
Contedo
Pginas
Introduo 1
Aspectos gerais do ambiente de Big Data 2
O desafio de escalabilidade 5
O modelo de programao MapReduce 6
O ambiente Hadoop 8
Outros ambientes 11
Projeto e implementao de aplicaes Big Data 16
Minerao de Itemsets Frequentes 19
Agrupamento baseado em densidade 32
R-tree 45
Identificao de ciclos em grafos 50
API para processamento estatstico 59
Avaliao do algoritmo PageRank 73
Maximizao de expectativas 87
Agregao eficiente de dados temporais 96
Classificao associativa incremental (LAC) 105
Entropia de Shannon em redes de contedo categorizado 115
Processamento de streams de tweets 121
Concluso 130
Referncias
Fontes e Editores da Pgina 131
Fontes, Licenas e Editores da Imagem 132
Licenas das pginas
Licena 134
Introduo
1
Introduo
Introduo
A evoluo dos sistemas computacionais e a difuso do acesso Internet em diversas formas esto dando origem ao
que muitos denominam a Idade da Informao
[1]
. Os volumes massivos de dados produzidos pelas mais diversas
fontes, como medies coletadas por sensores dos mais diversos tipos, registros (logs) dos servios oferecidos pela
Web, diversos tipos de contedo produzidos pelos usurios no que se convencionou chamar de Web 2.0, tudo isso
apresenta novos desafios e possibilidades. As possibilidades so inmeras, sempre baseadas na ideia de se derivar
novo conhecimento a partir da anlise de tais volumes de dados. Os desafios, por sua vez, envolvem questes como
definir formas eficientes de coletar e armazenar toda informao, garantir sua preservao e acesso eficientes, bem
como extrair informao til de tais volumes de dados. Dado o interesse geral devido ao seu potencial, essa rea vem
recebendo grande ateno na imprensa tcnica e mesmo na imprensa em geral, sendo denominada Big-data. Neste
trabalho, pretendemos discutir o problema de como processar esses grandes volumes de dados.
Exatamente o que se entende por big-data depende bastante do contexto
[2]
. Apesar de normalmente se associar o
conceito apenas a volumes extremamente grandes de dados, na verdade a definio abrange trs dimenses, que
devem ainda ser consideradas em perspectiva para cada usurio: volume, velocidade e variedade
[3]
.
Certamente, volume uma dimenso claramente associada a dados massivos. Um infogrfico produzido por GOOD,
Oliver Munday e IBM
[4]
representa alguns desses volumes. Entre eles, pode-se ver que a cada minuto so
carregados no Youtube o equivalente a 20 horas de vdeo, que h em mdia 50 milhes de tweets por dia e que 2,9
milhes de mensagens de e-mail so enviados por segundo. Entretanto, a definio de volume massivo deve ser
tambm ajustada em funo dos recursos disponveis para seu processamento. Nem todas as organizaes possuem
os recursos computacionais de uma empresa como Google ou Facebook; em muitos casos, dados na casa de centenas
de Gigabytes j apresentam um desafio para serem processados, considerando-se os recursos disponveis.
Uma segunda dimenso a velocidade com que os dados so gerados e com que precisam ser processados em
diversos casos. Por exemplo, o Observatrio da Web
[5]
coleta um grande volume de informaes em tempo real de
diversas fontes, como stios de notcias, blogs e Twitter, para gerar diversas anlises atualizadas a cada minuto
durante eventos transmitidos ao vivo. Nesse caso, o desafio processar o volume de dados gerado ao longo do tempo
e em tempo hbil, o que denominado processamento de streams.
Finalmente, a variedade dos dados e dos resultados esperados tambm so determinantes para a definio de
big-data. A possibilidade de se coletar informaes textuais, fotos, udio e vdeo tornam muitas vezes invivel o uso
de sistemas de gerncia de bancos de dados tradicionais. A explorao de informaes de redes complexas,
representando relacionamentos entre pessoas e/ou eventos d origem a grafos complexos, que tambm no so
facilmente armazenados em sistemas convencionais.
Enfim, o processamento de dados massivos de forma eficiente exige o uso de paralelismo, tanto para o
armazenamento dos dados quanto para seu processamento. Dessa forma, o acesso aos dados acelerado, j que
leituras em paralelo se tornam possveis, e o processamento dividido entre diversas unidades de processamento,
acelerando a gerao de respostas. Esse modelo de paralelismo, usualmente conhecido como o padro
dividir-para-conquistar, ou diviso-e-conquista.
Apesar desse modelo de processamento j ser largamente conhecido da comunidade de processamento paralelo, ele
tambm vem ganhando larga aceitao nas tarefas de big-data pelo surgimento de ambientes de processamento
desenvolvidos especificamente para esse tipo de atividade. Alm disso, esses grandes volumes de dados surgem
normalmente no contexto de aplicaes em nuvem, que executam em grandes datacenters, onde recursos para
armazenamento e processamento distribudo j existem na forma de um grande nmero de mquinas convencionais
interligadas por redes de alta velocidade.
Introduo
2
Considerando todos esses fatores, o restante deste livro abordar os elementos principais para viabilizar o
processamento de dados massivos. Na seo2, o ambiente dos datacenters atuais discutido em mais detalhes, para
caracterizar melhor as restries e demandas impostas sobre os ambientes de execuo. Um aspecto essencial
associado ao ambiente de execuo o sistema de armazenamento dos dados, que tambm ser discutido. Com base
nessa anlise, a seo 3 discute os desafios enfrentados para se garantir o alto desempenho nesse ambiente. Em
seguida, a seo4 introduz o modelo de programao MapReduce, que se tornou um dos mais populares na rea, e a
seo5 d detalhes do Hadoop, a principal implementao do modelo. Apesar de sua popularidade, entretanto,
MapReduce e Hadoop no so a soluo para todos os problemas. A seo6 apresenta ambientes desenvolvidos para
facilitar o processamento de certos tipos de dados e certos tipos de algoritmos que no se adaptam bem ao modelo
MapReduce. Ainda nesse sentido, a seo7 descreve uma metodologia para o desenvolvimento de aplicaes
big-data e traz diversos estudos de caso desenvolvidos pelos alunos da disciplina Processamento de Dados Massivos
do Departamento de Cincia da Computao da Universidade Federal de Minas Gerais (DCC/UFMG). Finalmente, a
seo 8 apresenta algumas consideraes finais.
Referncias
[1] Wang, W.-L. Viewpoint: information in the information age. Communications of the ACM 42(6) June 1999, 2324
[2] Jacobs, A. The pathologies of big data. Communications of the ACM 52(8), Aug. 2009, 3644.
[3] Corrigan, D. What is big data?. (http:/ / www-01.ibm.com/ software/ data/ bigdata/ ) - visitado em outubro de 2012.
[4] http:/ / www. bimeanalytics. com/ wp-content/ uploads/ 2011/ 09/ world-of-data. jpeg
[5] http:/ / observatorio. inweb. org. br/
Aspectos gerais do ambiente de Big Data
O ambiente de execuo
Dados massivos esto frequentemente relacionados ao modelo de computao em nuvem. Nesse caso, servios so
oferecidos de forma transparente de localizao e adaptando-se s demandas dos usurios. O processamento real e,
de forma relacionada, o armazenamento dos grandes volumes de dados envolvidos, se d em datacenters instalados
em algum lugar da rede. Para melhor entendermos os modelos de processamento de dados massivos devemos, ento,
entender como esse ambiente se organiza e como os dados so armazenados.
Arquitetura de datacenters
Em um datacenter, recursos computacionais so organizados de forma concentrada, a fim de melhor controlar o
consumo de energia necessria para o funcionamento dos equipamentos e para a refrigerao dos mesmos
[1]
. Dada a
economia de escala envolvida, os computadores utilizados so computadores convencionais, off-the-shelf, cada um
com boa capacidade de processamento, memria e discos. Os computadores so instalados em racks, com dezenas
de mquinas por rack. Em cada rack instalado um comutador (switch) Ethernet, denominado switch de topo de
rack (TOR), que interliga as mquinas do rack velocidade de 1 Gigabit por segundo, de forma no bloqueante
(todas as mquinas podem se comunicar a 1 Gpbs, desde que o padro de comunicao seja igualmente distribudo
entre elas). Os switches TOR so ento interligados por switches de backbone utilizando diversos links para cada
rack, ou mesmo links de 10 Gpbs. Uma representao geral dessa infraestrutura ilustrada na figuraa seguir. Em
datacenters muito grandes, pode at existir um segundo nvel de comutadores, para expandir o alcance da rede
[2]
.
3
Arquitetura bsica de uma rede de datacenter.
No caso de ambientes em nuvem essa tende a ser a organizao mais comum para as unidades de processamento,
sem servidores de armazenamento dedicados, pois eles se tornam gargalos para os grandes volumes de
processamento envolvidos. Qualquer soluo de armazenamento e processamento deve, ento, considerar que todos
os elementos do sistema tm arquitetura semelhante, apesar de poderem ser heterogneos em capacidade. Alm
disso, importante manter em mente que a comunicao entre unidades em um mesmo rack pode se dar a uma
velocidade maior que entre mquinas de racks diferentes, uma vez que a capacidade dos links que ligam os switches
TOR ao backbone quase sempre menor que a capacidade agregada das mquinas em um rack. Por exemplo, um
rack pode ter de 20 a 40 mquinas, cada uma com pelo menos uma interface Ethernet Gigabit. Usualmente, a
conexo dos TORs para o backbone no passar de quatro links de 1 Gbps ou, no mximo, um link de 10 Gbps.
Para tornar as coisas ainda mais desafiadoras, por serem equipamentos semelhantes e sem recursos especiais para
tolerncia a falhas, qualquer elemento (computadores e switches) pode falhar a qualquer instante. De fato, dado o
grande nmero de equipamentos normalmente agrupados em um datacenter, as chances de alguma falha ocorrer
relativamente alta. Qualquer soluo de armazenamento e processamento nesse caso deve ser capaz de lidar com
falhas de forma transparente para o usurio.
Armazenamento de dados
Considerando-se essa arquitetura, para garantir o melhor desempenho durante o processamento, dados devem ser
distribudos entre os discos das diversas mquinas de forma que possam ser lidos em paralelo, para serem
processados tambm em paralelo. Apesar de algumas solues mais simples deixarem a tarefa de organizar os dados
dessa forma a cabo do usurio, idealmente essa funcionalidade deve ser oferecida por um sistema de armazenamento
distribudo. Historicamente, sistemas de arquivo paralelos
[3]
foram desenvolvidos para esse fim no contexto de
sistema de processamento de alto desempenho (HPC). Entretanto, no contexto de dados massivos, observou-se que
os padres de acesso aos dados tendem a ser mais simples que nos ambientes de HPC e solues particulares tm se
mostrado mais adequadas nesse contexto . O modelo mais adotado para esse fim tem sido o modelo proposto pelo
Google File System (GFS)
[4]
e tambm implementado pelo Hadoop File System (HDFS)
[5]
.
No Google File System, arquivos so escritos sequencialmente quando criados, ou dados so acrescentados
sequencialmente ao final de um arquivo j existente (append). Alteraes no so possveis depois que um dado
escrito e o objetivo tornar eficiente padres de acesso que percorram todo o arquivo de cada vez. Para isso,
4
arquivos so dividos em blocos grandes (usualmente 64 MB), que so distribudos pelos discos de diversas mquinas
do sistema e replicados para aumentar a disponibilidade dos mesmos.
No GFS (e HDFS), cada sistema de arquivos tem uma mquina escolhida como servidor do espao de nomes
(namenode), responsvel tambm por armazenar os metadados de cada arquivo. A estrutura de arquivos do GFS
isolada e independente da rvore de diretrios usual acessada por cada mquina. Os acessos se do atravs de uma
biblioteca especial e no atravs da interface de chamadas de sistema.
Ao criar um arquivo, um cliente registra seu nome com o namenode e comea a escrever os blocos em mquinas
escolhidas no mesmo rack em que executa o processo escritor (para aproveitar a melhor banda entre mquinas no
mesmo rack). Uma vez escrita essa primeira cpia o cliente continua seu processamento, enquanto o servidor de
armazenamento do GFS que recebeu o bloco (denominado datanode) passa a replicar o mesmo em um outro
datanode, escolhido normalmente em um outro rack (para evitar problemas com falhas que afetem um rack inteiro).
Usualmente cada bloco replicado trs vezes (apesar desse nmero poder ser configurado pelo usurio para cada
arquivo) e uma terceira cpia feita ento pelo segundo datanode para um outro datanode no mesmo rack (de novo,
aproveitando a banda local).
Ao abrir um arquivo para leitura, o cliente se comunica como namenode e recebe dele a lista de blocos do arquivo,
com a identificao dos namenodes que armazenam cada bloco. O cliente pode ento escolher de qual namenode
requisitar os dados de que necessita baseado em critrios de proximidade. Dessa forma, vrios clientes podem
escolher ler partes diferentes do arquivo a partir de datanodes diferentes, aumentando a banda de leitura dos dados.
Periodicamente, processos administrativos verificam a disponibilidade de cada datanode e os blocos armazenados
em cada um, comandando novas cpias ou movendo blocos entre ns para garantir o balanceamento entre eles. Esses
processos tambm cuidam de comandar a redistribuio de blocos quando novos datanodes so acrescentados ao
sistema, ou comandar novas replicaes quando algum n falha.
Esses so elementos importantes do ambiente normalmente utilizado para processamento de dados massivos. A
seo a seguir discute os principais aspectos de escalabilidade e eficincia que precisam ser considerados nesse caso,
para ento discutirmos nas sees seguintes os modelos de processamento disponveis.
Referncias
[1] Barroso, L., e Holzle, U. The Datacenter as a Computer: An Introduction to the Design of Warehouse-scale Machines (http:/ / www.
morganclaypool.com/ doi/ pdf/ 10. 2200/ s00193ed1v01y200905cac006). Synthesis lectures in computer architecture. Morgan & Claypool,
2009.
[2] Greenberg, A., Hamilton, J., Maltz, D.A., and Patel, P. The cost of a cloud: research problems in data center networks. SIGCOMM Computer
Communication Review 39(1), Dec. 2008, 6873.
[3] Nagle, D., Serenyi, D., and Matthews, A. The panasas activescale storage cluster: Delivering scalable high bandwidth storage. In Proceedings
of the 2004 ACM/IEEE conference on Supercomputing (Washington, DC, USA, 2004), SC 04, IEEE Computer Society, pp.53.
[4] Ghemawat, S., Gobioff, H., and Leung, S.-T. The google file system (http:/ / research. google. com/ archive/ gfs. html). SIGOPS: Operation
Systems Review 37(5), 2003, 2943
[5] Borthakur, D. The Hadoop Distributed File System: Architecture and Design (http:/ / hadoop. apache. org/ docs/ r0. 18. 0/ hdfs_design. pdf).
The Apache Software Foundation, 2007.
O desafio de escalabilidade
5
Escalabilidade e eficincia de aplicaes Big Data
Um dos grandes desafios para a construo de aplicaes BigData que sejam escalveis e eficientes que essas
aplicaes demandam recursos em trs dimenses e as demandas variam drasticamente entre aplicaes ou mesmo
durante a sua execuo. Nesta seo buscamos entender as dimenses, as fontes de degradao de desempenho e
como elas podem ser caracterizadas, entendidas e minimizadas.
Distinguimos trs tipos de recursos (ou dimenses) que devem ser providos pela plataforma computacional para a
execuo de aplicaes Big Data, as quais so tipicamente paralelas e distribudas: processamento, comunicao e
armazenamento. Processamento se refere computao propriamente dita que executada em uma ou mais CPUs.
Comunicao se refere transferncia de dados entre CPUs utilizando recursos de redes de comunicao.
Armazenamento se refere s operaes de preservao de dados de entrada ou computados em disco rgido ou outra
tecnologia de armazenamento perene.
Uma perspectiva de caracterizao das aplicaes sobre o quanto elas utilizam os recursos de cada uma dessas
dimenses. A meta nesse caso utilizar ao mximo os recursos durante todo o perodo de execuo, o que no
possvel para a maioria das aplicaes, mas cuja anlise e mensurao permite entend-las melhor. Assim, dada uma
dimenso e os recursos disponveis, podemos mensurar quanto dos recursos ser efetivamente utilizado a cada
instante do tempo.
Considerando a dimenso de processamento, cada unidade de processamento pode estar, a cada instante do tempo
em um de trs estados: processamento, ocioso e computao adicional (overhead). Processamento caracterizado
por computao associada soluo do problema original, a qual normalmente distribuda entre as unidades de
processamento. O processador fica ocioso quando no possui processamento a realizar, como consequncia de
paralelismo insuficiente ou desbalanceamento de carga, ou quando est aguardando dados de ou sincronizando com
alguma outra unidade de processamento. A computao adicional todo o processamento que no realizado
originalmente na aplicao, mas passa a ser realizado em consequncia da paralelizao. Podemos citar trs
exemplos de computao adicional. O primeiro exemplo toda computao associada a primitivas de comunicao e
sincronizao. O segundo exemplo computao associada soluo original que replicada por questes de
eficincia, como a inicializao de variveis locais. O terceiro exemplo computao adicional realizada para
atender requisies de outros processos, como obteno de dados, em geral realizadas por daemons ou mecanismos
semelhantes.
Em termos de comunicao, cada canal de comunicao, representado pela interface de rede, pode estar ocupado ou
no. Aqui consideramos que a sua ocupao est associada aplicao em foco e outras aplicaes que porventura
estejam utilizando o canal, embora quantificadas, no so relevantes para o entendimento e melhoria do desempenho
da aplicao. O tempo de comunicao, isto , o tempo para envio de uma mensagem entre duas unidades de
processamento pode ser dividido entre conteno e tempo de transmisso. O tempo de transmisso depende do
volume de dados a ser transmitido, da latncia de comunicao entre as unidades de processamento e da banda
passante do meio. A conteno depende da configurao instantnea da aplicao e seus fluxos de processamento.
importante ressaltar que o fato do canal estar ocupado pode afetar a utilizao de outros componentes, como
unidades de processamento ficarem ociosas enquanto contendem por um canal de comunicao.
Em termos de armazenamento, cada dispositivo de armazenamento, por exemplo um disco ou partio de disco,
pode estar ocioso ou executando uma operao. A complexidade dos dispositivos de armazenamento os torna
bastante difcil de serem quantificados e entendidos plenamente. Em primeiro lugar porque esses dispositivos so
extremamente agressivos em termos de replicao (caching e buffering) e carga especulativa (prefetching), o que os
torna muito difcil de entender. Mais ainda, a possibilidade de usar dispositivos para memria virtual torna o cenrio
6
ainda mais complexo. Podemos avaliar esses dispositivos de forma encapsulada, verificando apenas quando eles
esto executando alguma operao ou no, assim como a natureza da operao em termos da poro de cdigo que a
invocou e qual a finalidade da invocao (p.ex., leitura, escrita, armazenamento temporrio ou permanente).
Em suma, h um primeiro desafio que a monitorizao de aplicaes nesse cenrio e quantificao dos usos dos
vrios componentes. O segundo desafio, que pode demandar anlises envolvendo mais de um componente e
instncias de um mesmo componente, explicar o que causou o comportamento observado. Desta forma, uma
estratgia de avaliao que ser aplicada para o desenvolvimento de aplicaes sempre considerar essas dimenses,
mapeadas nos vrios componentes de processamento, comunicao e armazenamento, a sua taxa de utilizao e a
natureza ou finalidade do uso.
O modelo de programao MapReduce
O modelo MapReduce
Conforme discutido anteriormente, um dos aspectos essenciais do processamento de dados massivos exprimir o
processamento de forma que o maior volume possvel de dados seja acessado (lido) e processado em paralelo,
aumentando a velocidade final do processamento. Um modelo que se mostrou particularmente bem sucedido nesse
aspecto foi o MapReduce, proposto pela Google em 2004
[1]
.
Princpio geral
O modelo opera sobre o Google File System, de onde os dados podem ser lidos de forma eficiente, em paralelo. Os
arquivos so vistos como listas de registros simples, como linhas, ou registros formatados segundo algum padro
definido pelo usurio. Cada registro lido do arquivo representado por um par (chave,valor) (p.ex., o nmero de
cada linha e o texto nela encontrado).
O processamento a ser realizado deve ser ento descrito por duas funes simples que do nome ao modelo e operam
sobre chaves e valores:
map(), que recebe como entrada pares chave/valor e os processa, gerando como sada novos pares chave/valor,
potencialmente de tipos diferentes dos anteriores,
reduce(), que recebe como entrada chaves produzidas como sada da funo anterior, junto com uma lista de
todos os valores associados a cada chave, e produz novamente como sada outro(s) par(es) chave/valor.
Conceitualmente, o modelo se reduz a uma verso particular do diviso-e-conquista j discutido anteriormente. Em
particular, cada registro (par chave/valor) extrado do arquivo de entrada pode ser potencialmente processado em
paralelo, de forma independente de todos os demais. A sincronizao durante o processamento ocorre ao final da
fase do map, quando todos os pares com chaves iguais devem ser agrupados para serem processados juntos na fase
de reduo. Novamente h potencialmente oportunidade para um alto grau de paralelismo, j que cada chave (com
sua lista de valores) pode ser processada separadamente.
Exemplo de aplicao
Com base na descrio resumida das primitivas na seo anterior, podemos ilustrar melhor o modelo com uma
aplicao simples, ContaPalavras, que visa contar todas as ocorrncias de cada palavra encontrada em uma base
de dados textual. O arquivo original seria, ento, o texto base, de onde o sistema capaz de identificar e ler as linhas
a partir dos blocos do arquivo. Nesse caso, o MapReduce gera pares do tipo (posio,linha), com a posio no
arquivo (em bytes) onde cada linha se inicia como chave e o texto de cada linha nele encontrada como valor.
O modelo de programao MapReduce
7
A funo de mapeamento, nesse caso, deve ento quebrar a linha em palavras e emitir um valor unitrio para cada
palavra (como que contando aquela ocorrncia):
map(key, value):
// key: posio da linha; value: texto da mesma
for each word w in value:
emit(w, 1) // O valor e' definido com 1 sempre
No modelo original do MapReduce, emit() a funo usada para produzir novos pares chave/valor de sada, que
seriam ento armazenados em um novo arquivo, novamente sobre o Google File System.
A funo de reduo ento receberia uma lista de uns para cada palavra encontrada no texto e bastaria ento contar
(somar) todos os valores recebidos:
reduce(key, values):
// key: uma palavra; value: iterador para a lista
result = 0
for each count v in values:
result += v
emit(key, result) // contagem de cada palavra
O resultado final, ento, sero pares de palavras e inteiros indicando o nmero de vezes que cada palavra foi
encontrada.
Aspectos de execuo
Apesar de sua relativa simplicidade, a grande aceitao do modelo se deveu em parte facilidade com que questes
como o aproveitamento de paralelismo em diversos nveis (p.ex., mquinas multicore em um cluster),
balanceamento de carga e tolerncia a falha so facilmente tratados.
Para melhor aproveitar o poder computacional de cada n de processamento, o modelo permite ainda a definio de
uma funo combine(), que serve para realizar o pr-processamento das listas de valores gerados por cada n que
executa a funo map(), quando esse processamento pode reduzir o volume de comunicao entre ns. Essa funo
pode ser usada para j gerar um valor agregado para todos os valores associados por cada chave em um n, de forma
que apenas um valor precise ser enviado para os ns redutores para cada chave. No caso do programa
ContaPalavras, o mesmo cdigo da funo reduce() poderia ser usado: todas as ocorrncias de uma dada
palavra em um n seriam combinadas e ao invs de enviar uma lista de uns para o redutor, cada n j enviaria o
resultado da contagem (soma) da lista local para o redutor, que continuaria somando os valores recebidos dos vrios
ns de map() para obter a contagem final.
O balanceamento de carga e a tolerncia a falhas so obtidos por um mesmo mecanismo: o sistema acompanha o
trmino das tarefas no sistema e quando comea a ter recursos desocupados re-edita tarefas que ainda no foram
completadas, aproveitando o primeiro resultado que se torne disponvel.
Referncias
[1] Dean, J., and Ghemawat, S. Mapreduce: simplified data processing on large clusters (http:/ / research. google. com/ archive/ mapreduce.
html). In Proceedings of OSDI'04: Sixth Symposium on Operating System Design and Implementation, 2004.
O ambiente Hadoop
8
O ambiente Hadoop
Hadoop
Apesar da importncia conceitual dos trabalhos sobre o Google File System e o modelo MapReduce, o sistema
descrito pelos autores se manteve propriedade nica da Google, no tendo sido distribudo externamente. Isso mudou
apenas com a divulgao do Hadoop, um ambiente de cdigo aberto que implementa os princpios daqueles dois
sistemas de forma bastante aproximada, apesar de algumas diferenas. Hadoop foi desenvolvido originalmente por
Michael J. Cafarella e Doug Cutting, este ltimo funcionrio da Yahoo!. Com o passar do tempo, o projeto passou a
ser hospedado pela Apache Software Foundation e vem recebendo contribuies de diversas fontes, principalmente
da prpria Yahoo!.
As principais diferenas entre Hadoop e o modelo original da Google so a linguagem (Hadoop escrito em Java,
enquanto GFS/MR so escritos em C/C++) e o fato do HDFS no permitir a operao de escrita ao fim de arquivos
j criados (append). No HDFS, arquivos s podem ser abertos para escrita quando de sua criao; depois disso se
tornam apenas de leitura. Essas duas diferenas acarretam algumas outras, como a mudana da interface de
programao, uma maior amarrao entre a interface do sistema de arquivos HDFS e classes Java para o
processamento dos contedo dos arquivos em funo do tipo do contedo e uma extenso do modelo de entrada para
lidar com diretrios (usar todos os arquivos em um diretrio como entrada) ao invs de apenas arquivos isolados.
Esta ltima alterao se deve a uma simplificao do HDFS relacionada forma de atualizao de arquivos.
Normalmente, ao final de uma aplicao MapReduce, cada n que executa uma tarefa de reduo gera um arquivo de
sada independente, numerado em funo dos ns participantes da aplicao. Isso porque o HDFS no permite que
diversos processos escrevam em um mesmo arquivo em paralelo. J que a sada das aplicaes gera arquivos dessa
forma, a entrada do programa tambm aceita a indicao de um diretrio, de forma que a sada de uma aplicao
possa ser usada como entrada para outras.
Um exemplo de programao
Considerando-se as diferenas de implementao, no caso do Hadoop vale a pena analisar detalhadamente o cdigo
realmente utilizado para a aplicao ContaPalavras, ao invs de apenas um pseudo-cdigo mais abstrado. O
cdigo apresentado a seguir foi obtido do tutorial sobre Hadoop da Yahoo!
[1]
, uma fonte de consulta altamente
recomendada para detalhes sobre elementos de instalao, programao e execuo no Hadoop. Outra fonte que
merece meno o tutorial da Apache Software Foundation
[2]
.
A funo map define os tipos dos pares chave/valor de entrada e sada (linha 2). Neste caso, para um arquivo texto,
Hadoop entrega cada linha com uma chave que corresponde posio (em bytes) do comeo da linha (texto) em
relao ao comeo do arquivo, da usar um inteiro longo. A chave produzida pelo map ser uma palavra (texto) e o
valor ser um inteiro. Os tipos terminados em Writable so usados pelo Hadoop para lidar com a leitura e escrita dos
mesmos nos arquivos do HDFS corretamente (serializao e desserializao).
Outros detalhes de configurao so a definio do tipo de arquivo de sada (OutputCollector) que receber os pares
chave/valor do tipo indicado (linha 8). A classe Reporter usada para gerar dados de acompanhamento da execuo
para o sistema.
O cdigo realmente responsvel pelo processamento est entre as linhas 10 e 15: o valor recebido como entrada
transformado em um string, que dividido em tokens, que so enviados para a sada com a chamada de
output.collect.
O cdigo do redutor, apresentado a seguir, tambm exige detalhes de declarao de tipos de entrada e sada, que
neste caso so iguais: palavra(texto)/inteiro (linha 2). Como a funo de reduo recebe uma lista de valores, o
segundo tipo um iterador sobre a lista de valores associados a cada chave (linha 4). Os outros elementos da
O ambiente Hadoop
9
definio so semelhantes ao caso do map.
O ncleo de processamento est entre as linhas 7 e 11 nesse caso: o loop itera sobre todos os valores recebidos para
cada palavra (todos valendo um, nesse caso, j que no foi definido um combiner) e o valor final da contagem para
cada palavra lanado com um output.collect.
Finalmente, Hadoop requer um cdigo de configurao que identifique para o sistema as funes a serem usadas, os
arquivos de entrada e sada com seus tipos, etc. Essas informaes so definidas por um objeto de configurao que
construdo para esse fim como na listagem a seguir.
As linhas 8 e 9 identificam as classes que definem as operaes de mapeamento e reduo. As linhas 11 e 12
associam arquivos armazenados no HDFS entrada e sada do programa. O nome usado como entrada pode ser o de
um arquivo especfico ou de um diretrio contendo diversos arquivos, que sero todos processados da mesma forma,
potencialemente em paralelo. J o nome usado para a sada deve sempre ser o de um diretrio vazio, onde sero
criados arquivos para cada n de processamento que executar a funo de reduo.
O tipo dos pares chave/valor de sada definido pelos comandos nas linhas 5 e 6. Com os comandos usados, a sada
ser gerada como arquivo texto, com um caractere de tabulao separando a chave do valor em cada linha. Como
no h comandos semelhantes para a entrada, o tipo assumido o de arquivo de texto simples. O sistema oferece
tambm a opo de tratar a entrada como um arquivo texto com chaves e valores separados por um caractere de
tabulao (como o gerado pela sada do programa), ou como um arquivo com registros complexos, caso em que o
programador dever fornecer uma classe de leitura adequada. Neste ltimo caso h detalhes que precisam ser
tratados em relao ao processamento de registros que ultrapassam o limite de um bloco do arquivo no HDFS. Este e
outros detalhes da interface de programao podem ser encontrados no tutorial da Yahoo!.
Ao se executar o mtodo runJob do objeto de configurao que descreve a aplicao (linha 14), o ambiente de tempo
de execuo do Hadoop passa a executar a tarefa. Os passos envolvidos nesse processo so descritos a seguir.
Ambiente de execuo
Para melhor compreender o comportamento de uma aplicao paralela Hadoop importante entender os passos de
sua execuo. Esses passos so ilustrados na figuraabaixo e descritos a seguir. Os nmeros entre parnteses se
referem aos passos na figura.
Representao do ambiente de execuo do Hadoop.
O ambiente Hadoop
10
Ao disparar o programa da aplicao, o Hadoop dispara os processos que faro parte da execuo (1). Um processo
mestre, responsvel por coordenar os demais, disparado junto aplicao original do usurio e processos
trabalhadores so disparados no conjunto de mquinas configurados durante a instalao do Hadoop.
Com base na informao sobre o arquivo de entrada, o mestre identifica os trabalhadores que foram disparados mais
prximo de cpias dos blocos do arquivo e atribui a cada um deles parte das tarefas de map, identificando os pedaos
do arquivo que devem ser processados por cada trabalhador, denominados splits (2). Os trabalhadores comeam
ento a ler pedaos do arquivo e produzir os pares chave/valor para a tarefas de map (3). Os pares chave/valor
produzidos nessa etapa so assinalados para um dos processos trabalhadores escolhidos para a reduo por uma
funo de assinalamento. Essa funo normalmente uma funo de hash simples, parametrizada pelo nmero de
redutores, mas pode ser substituda por outro tipo de mapeamento definido pelo usurio. O resultado do map ento
armazenado localmente na mquina em que cada trabalhador executa, agrupado pelos identificadores dos processo
de reduo assinalados pela funo de mapeamento (4). medida que tarefas de mapeamento sobre splits
completam, os trabalhadores informam o mestre sobre quais chaves foram geradas no processo e identificam os
arquivos gerados para cada n responsvel pela reduo (5).
O mestre, medida que cada split do arquivo de entrada completado, coleta a informao sobre os arquivos
intermedirios e notifica cada n trabalhador que executar um reduce sobre quais ns de map j tm arquivos
intermedirios com chaves destinadas a eles (6). Os redutores ento contactam os ns identificados e vo
requisitando esses arquivos usando consultas HTTP. Os pares chave/valor recebidos vo sendo ordenados por suas
chaves, para garantir a gerao correta das listas de valor para cada chave de forma completa (7). Quando os
trabalhadores que executam as tarefas de mapeamento terminam e todos os pares chave/valor intermedirios esto
disponveis para os processos de reduo adequados, a funo reduce comea a ser executada para cada chave
assinalada para um trabalhador pela funo de mapeamento. A sada de cada trabalhador envolvido na reduo
escrita em um arquivo individual no HDFS, todos no mesmo diretrio indicado pelo usurio na configurao da
aplicao (8).
O nmero de trabalhadores pode ser configurado pelo usurio, mas em geral calculado automaticamente pelo
Hadoop, em funo do tamanho da entrada (nmero de splits) e do nmero de mquinas disponveis.
Como no MapReduce original, Hadoop usa replicao de tarefas para conseguir balanceamento de carga e tolerncia
a falhas. medida que as tarefas de um certo tipo vo terminando, o processo mestre dispara novas execues de
tarefas que esto levando mais tempo para serem completadas em outros ns. Alm disso, ele monitora o estado de
todos os trabalhadores a fim de detectar ns que tenham deixado de responder. Nesse caso, ele identifica todas as
tarefas que haviam sido atribudas a um n (sejam maps ou reduces) e as atribui novamente a outros ns ainda
ativos.
Referncias
[1] Yahoo! Hadoop Tutorial (http:/ / developer. yahoo.com/ hadoop/ tutorial/ index. html) - visitado em outubro de 2012.
[2] Apache Software Foundation. Map/Reduce Tutorial (http:/ / hadoop. apache. org/ docs/ stable/ mapred_tutorial. html), 2010. - visitado em
outubro de 2012
Outros ambientes
11
Outros ambientes
Outros ambientes
Apesar de sua larga aplicao, importante observar que o modelo MapReduce e o Hadoop tm limitaes.
Primeiramente, muitas aplicaes requerem mais do que um passo de mapeamento e outro de reduo. O
programador deve, ento, descrever sua aplicao com sequncias de maps e reduces. Especialmente se as tarefas a
serem executadas so parte de um algoritm iterativo ou consultas semelhantes s normalmente executadas em um
banco de dados tradicional, isso exige um processo de codificao de cada operao.
Uma segunda limitao o fato de toda a comunicao ser baseada em arquivos. Isso implica em maiores latncias
na movimentao de dados, o que pode limitar o desempenho da aplicao se no h um nvel de paralelismo
suficiente para o volume de processamento esperado. Esse problema se torna ainda mais visvel quando a tarefa
exige diversos passos Map/Reduce.
Finalmente, h certos contextos de aplicao que tm se tornado mais relevantes com o aumento do volume de dados
e da importncia de certos tipos de aplicaes que no se adequam bem ao modelo Map/Reduce. Entre eles,
podemos citar o processamento de grandes grafos e o processamento de fluxos contnuos de dados, que no se
ajustam bem ao modelo de etapas do Map/Reduce e ao uso de arquivos como elementos de armazenamento e
processamento.
Sistemas de gerncia de dados (NOSQL)
Muitas das tarefas desenvolvidas em sistemas de processamento de dados massivos ainda se assemelham muito a
consultas tradicionais em bancos de dados relacionais. Realizar uma projeo, uma seleo ou um join sobre um
conjunto de linhas de entrada exige uma ou mais sequncias de maps e reduces. Para simplificar a tarefa dos
usurios nesses casos, diversos tipos de sistemas de gerncia de dados foram propostos e implementados sobre a
plataforma Hadoop ou em outros contextos semelhantes. Esses sistemas costumam ser denominados de forma geral
como NOSQL, usualmente interpretado como Not Only SQL, em contraposio linguagem de consulta
usualmente utilizada em bancos de dados relacionais.
Para a automao de consultas, dois dos primeiros sistemas desenvolvidos so os ambientes Pig
[1]
e Hive
[2]
,
desenvolvidos originalmente pela Yahoo! e Facebook, respectivamente, e posteriormente distribudas como cdigo
aberto.
Pig oferece uma linguagem de consultas procedural, algumas vezes comparada a Perl, para a expresso de tarefas
sobre arquivos que representam uma base de dados organizada como linhas de texto representando registros. O
trecho de cdigo a seguir ilustra o uso de Pig para consultar um arquivo com registros de URLs com suas categorias
e seu valor de pagerank (PR), calcular o PR mdio para cada categoria e exibir apenas aquelas com PR acima de um
mnimo e com quantidade alta de URLs.
urls_ok = FILTER urls BY pagerank > 0.25
grupos = GROUP urls_ok BY categoria
grupos_maiores = FILTER grupos
BY COUNT(urls_ok) > 10E5
resultado = FOREACH grupos_maiores GENERATE
category, AVG(urls_ok.pagerank)
Hive, por outro lado, se apresenta como um sistema de armazm de dados com uma linguagem de consulta que
prxima a um subconjunto de SQL. Tabelas so normalmente definidas como arquivo textuais com campos
separados por tabulaes. Em Hive, a mesma consulta anterior tomaria a forma de uma consulta semelhante a SQL,
Outros ambientes
12
como ilustrado a seguir. O ambiente de processamento se encarregaria de transformar a consulta em uma sequncia
de maps e reduces que geraria o resultado desejado. Comandos adicionais poderiam ser usados para produzir um
arquivo como sada.
SELECT categoria, AVG(pagerank)
FROM urls
WHERE pagerank > 0.25
GROUP By categoria
HAVING COUNT(*) > 10E5;
Diversas solues para estruturao dos arquivos armazenados no GFS ou HDFS de forma mais eficiente para
consultas j foram propostas e so largamente utilizadas. Essas solues so em geral sistemas de armazenamento
denominados chave-valor (key-value stores), onde a informao armazenada em funo de uma chave
pr-definida. Esses sistemas, ao contrrio da interface padro do sistema de arquivos, permitem consultas e
atualizaes de contedo associado a qualquer chave. Exemplos de sistemas desse tipo so o BigTable
[3]
, proposta
original da Google, o HBase
[4]
, uma implementao do mesmo conceito para o Hadoop, e outros, como Apache
Cassandra
[5]
e Dynamo
[6]
. Em geral, esses sistemas garantem apenas consistncia eventual do contedo e oferecem
compromissos diferentes de implementao em funo de diferentes requisitos de aplicao.
Outras solues buscam novas formas de organizao dos dados que ofeream maior estrutura para os dados e poder
de expresso nas consultas, bem como formas de organizao que permitam a criao de bases de dados distribudas
geograficamente entre diversos datacenters. Exemplos de projetos nessa linha incluem Megastore
[7]
e Spanner
[8]
,
ambos da Google, PNUTS
[9]
da Yahoo!, Dremel
[10]
e outros.
Anthill
O ambiente de processamento Anthill
[11]
foi desenvolvido no DCC/UFMG para dar suporte a um ambiente de
minerao de dados em larga escala denominado Tamandu
[12]
. Seu modelo de programao se basea no paradigma
denominado filtro-fluxo (filter-stream), onde o processamento descrito como operaes executados por filtros que
processam um fluxo de dados que passa por eles. Cada filtro descrito de forma que mltiplas instncias possam ser
criadas para processar elementos do fluxo em paralelo, obtendo paralelismo de dados. Filtros podem ser encadeados
de forma a executar diversas etapas de processamento sobre um fluxo, transformando os dados a cada estgio,
criando paralelismo de tarefas. Um exemplo de uma aplicao com quatro filtros ilustrada na figuraa seguir.
Outros ambientes
13
Representao da estrutura de uma aplicao executando no ambiente de processamento distribudo Anthill
Ao contrrio do modelo MapReduce, aplicaes no Anthill podem executar operaes genricas sobre os dados em
cada filtro, no estando restritas a operaes apenas que se encaixem em mapeamentos e redues. Alm disso, os
fluxos podem implementar diferentes padres de distribuio dos dados entre as instncias, como round-robin
(elementos so distribudos de forma cclica), broadcast (elementos replicados para todas as cpias de um filtro) e
labeled (rotulado, onde elementos com uma mesma chave so sempre direcionados para o mesmo destino). Com o
fluxo rotulado, processamento do tipo MapReduce pode ser facilmente implementado. Uma limitao do ambiente
atual que no h um sistema de arquivos integrado como no caso de HDFS e GFS: os dados devem ser distribudos
entre os ns de processamento pelo usurio, que deve definir o filtro de leitura para extrair os dados dos diversos
arquivos.
A comunicao entre filtros no Anthill se d por canais de comunicao na rede, sem o uso de arquivo
intermedirios, o que reduz a latncia e aumenta a possibilidade de explorao de paralelismo por operaes que
podem ser superpostas comunicao. Alm disso, o Anthill permite a expresso de fluxos de comunicao com
realimentao, onde o resultado de uma etapa do processamento injetado de volta em um estgio anterior da cadeia
de filtros. Esse recurso possibilita a implementao eficiente de algoritmos cclicos como os encontrados em
aplicaes de minerao de dados que operam com o refinamento de solues intermedirias.
Alguns outros ambientes de programao tambm evitam as limitaes do MR/Hadoop relacionadas ao uso de
arquivos para comunicao. Em particular, o Dryad
[13]
, da Microsoft, permite que o usurio represente seu
processamento como um grafo direcionado, tambm seguindo o modelo filtro-fluxo. No caso do Dryad, uma
linguagem especial oferece construtores para que o programador construa o grafo de comunicao. O ambiente de
execuo cuida da comunicao e o escalonamento de tarefas a partir de ento.
Fluxos de dados (streams)
A operao contnua de servios em nuvem tem gerado diversas fontes de dados ininterruptas que criam novas
possibilidades de processamento e novas demandas. No Observatrio da Web, uma parte do processamento consiste
na observao de mensagens enviadas pelo Twitter. Um extrator obtm continuamente novas mensagens (twits)
sobre um determinado tema, de onde so extradas as hashtags usadas e as palavras usadas para posteriormente se
fazer a anlise do contedo.
Outros ambientes
14
A natureza contnua dos dados torna complicado o uso de sistemas baseados em arquivos, como o Hadoop. Essa
orientao a arquivos exige que os dados sejam armazenados a cada unidade de tempo (dia, hora, etc.), causando um
atraso entre o momento de coleta e processamento. No DCC-UFMG, com base na experincia com o Anthill, foi
desenvolvido o Watershed
[14]
, onde os elementos de processamento so orientados a fluxos ininterruptos. Outros
sistemas orientados a streams incluem o IBM S4
[15]
, rebatizado InfoSphere Streams, e o Twitter Storm
[16]
,
recentemente liberado como projeto de cdigo aberto.
Grafos
Outro contexto que tem ganhado ateno da comunidade aquele das aplicaes de processamento de grandes
grafos, que surgem da representao de relacionamentos entre usurios em redes sociais, por exemplo. Apesar de
haver muitos trabalhos sobre o uso de Hadoop nesses casos, a maioria dos algoritmos sobre grafos tem
caractersticas que no se adaptam bem ao modelo MapReduce. Esses algoritmos frequentemente exigem diversas
iteraes sobre o conjunto de dados, bem como padres de comunicao irregulares ditados pela estrutura dos grafos
considerados. Essas opraes so difceis de representar como etapas de mapeamento e reduo isoladas.
Frente a esses problemas, a prpria Google desenvolveu um ambiente de processamento especfico para esse
contexto, o Pregel
[17]
, baseado no paradigma de processamento bulk synchronous (BSP)
[18]
. Nesse modelo, os
algoritmos so expressos do ponto de vista de cada n, que pode trocar mensagens com outros ns do grafo (no s
seus vizinhos). A execuo progride em etapas denominadas supersteps, em que cada n primeiramente recebe todas
as mensagens enviadas para ele no superstep anterior, executa o algoritmo a ele assinalado e envia mensagens para
outros ns (que s sero entregues ao final do superstep). Apesar de forar a ocorrncia de barreiras de
sincronizao, esse modelo escala bem para grafos muito grandes e simplifica as questes de consistncia entre ns,
j que a comunicao s ocorre entre supersteps. Uma implementao de cdigo aberto do Pregel foi realizada no
DCC/UFMG, resultando no sistema Rendero
[19]
.
Para grafos que no atingem as dimenses daqueles para que o Pregel foi criado, o modelo BSP limita a eficincia do
processamento. O ambiente GraphLab
[20]
segue uma linha completamente diferente de operao, relaxando as
restries e garantias de consistncia no processamento dos ns. O algoritmo tambm deve ser expresso em termos
de ns, mas permitido a um n acessar (e alterar) atributos associados s arestas e aos ns vizinhos. Esse recurso
aumenta a facilidade de execuo em paralelo de diversos ns, mas transfere para o programador a responsabilidade
de lidar com o impacto devido a possveis inconsistncias.
Referncias
[1] Olston, C., Reed, B., Srivastava, U., Kumar, R., and Tomkins, A. Pig latin: a not-so-foreign language for data processing. In Proceedings of
the 2008 ACM SIGMOD international conference on Management of data (New York, NY, USA, 2008), SIGMOD 08, ACM,
pp.10991110.
[2] Thusoo, A., Sarma, J.S., Jain, N., Shao, Z., Chakka, P., Anthony, S., Liu, H., Wyckoff, P., and Murthy, R. Hive - a warehousing solution
over a map-reduce framework. PVLDB 2, 2 (2009), 16261629.
[3] Chang, F., Dean, J., Ghemawat, S., Hsieh, W.C., Wallach, D.A., Burrows, M., Chandra, T., Fikes, A., and Gruber, R.E. Bigtable: A
distributed storage system for structured data. ACM Transactions on Computer Systems 26, 2 (June 2008), 4:14:26.
[4] Borthakur, D., Gray, J., Sarma, J.S., Muthukkaruppan, K., Spiegelberg, N., Kuang, H., Ranganathan, K., Molkov, D., Menon, A., Rash, S.,
Schmidt, R., and Aiyer, A. Apache hadoop goes realtime at facebook. In Proceedings of the 2011 ACM SIGMOD International Conference on
Management of data (New York, NY, USA, 2011), SIGMOD 11, ACM, pp.10711080.
[5] Lakshman, A., and Malik, P. Cassandra: a decentralized structured storage system. SIGOPS Operating Systems Review 44, 2 (Apr. 2010),
3540.
[6] DeCandia, G., Hastorun, D. , Jampani, M., Kakulapati, G. , Lakshman, A., Pilchin, A. , Sivasubramanian, S. , Vosshall, P. , Vogels, W.,
Dynamo: amazon's highly available key-value store, Proceedings of twenty-first ACM SIGOPS symposium on Operating systems principles,
2007, 14-17
[7] Baker, J., Bond, C., Corbett, J., Furman, J.J., Khorlin, A., Larson, J., Leon, J.-M., Li, Y., Lloyd, A., and Yushprakh, V. Megastore: Providing
scalable, highly available storage for interactive services. In Proceedings of the Fifth Biennial Conference on Innovative Data Systems
Research (CIDR) (Asilomar, CA, 2011), pp.223234.
Outros ambientes
15
[8] Corbett, J.C., Dean, J., Epstein, M., Fikes, A., Frost, C., Furman, J., Ghemawat, S., Gubarev, A., Heiser, C., Hochschild, P., Hsieh, W.,
Kanthak, S., Kogan, E., Li, H., Lloyd, A., Melnik, S., Mwaura, D., Nagle, D., Quinlan, S., Rao, R., Rolig, L., Saito, Y., Szymaniak, M.,
Taylor, C., Wang, R., and Woodford, D. Spanner: Googles globally-distributed database. In Proceedings of the Tenth Symposium on
Operating System Design and Implementation (OSDI) (Hollywood, CA, 2012), USENIX.
[9] Cooper, B.F., Ramakrishnan, R., Srivastava, U., Silberstein, A., Bohannon, P., Jacobsen, H.-A., Puz, N., Weaver, D., and Yerneni, R. Pnuts:
Yahoo!s hosted data serving platform. In Proceedings of VLDB Endoment. 1, 2 (Aug. 2008), 12771288.
[10] Melnik, S., Gubarev, A., Long, J.J., Romer, G., Shivakumar, S., Tolton, M., and Vassilakis, T. Dremel: interactive analysis of web-scale
datasets. In Proceedings of VLDB Endoment 3, 1-2 (Sept. 2010), 330339.
[11] Ferreira, R.A., Meira, Jr., W., Guedes, D., Drummond, L. M.A., Coutinho, B., Teodoro, G., Tavares, T., Araujo, R., and Ferreira, G.T.
Anthill: A scalable run-time environment for data mining applications. In Proceedings of the 17th International Symposium on Computer
Architecture on High Performance Computing (Washington, DC, USA, 2005), SBAC-PAD 05, IEEE Computer Society, pp.159167.
[12] Guedes, D., Jr., W.M., and Ferreira, R. Anteater: A service-oriented architecture for high-performance data mining. IEEE Internet
Computing 10, 4 (2006), 3643.
[13] Isard, M., Budiu, M., Yu, Y., Birrell, A., and Fetterly, D. Dryad: distributed data-parallel programs from sequential building blocks. In
Proceedings of the 2nd ACM SIGOPS/EuroSys European Conference on Computer Systems 2007 (New York, NY, USA, 2007), EuroSys 07,
ACM, pp.5972.
[14] Alvesde SouzaRamos, T.L., Oliveira, R.S., deCarvalho, A.P., Ferreira, R. A.C., and MeiraJr., W. Watershed: A high performance
distributed stream processing system. In Proceedings of the 2011 23rd International Symposium on Computer Architecture and High
Performance Computing (Washington, DC, USA, 2011), SBAC-PAD 11, IEEE Computer Society, pp.191198.
[15] Neumeyer, L., Robbins, B., Nair, A., and Kesari, A. S4: Distributed stream computing platform. In Proceedings of the 2010 IEEE
International Conference on Data Mining Workshops (Washington, DC, USA, 2010), ICDMW 10, IEEE Computer Society, pp.170177.
[16] Twitter. Storm stream processing (https:/ / github.com/ nathanmarz/ storm/ wiki) - visitado em outubro de 2012.
[17] Malewicz, G., Austern, M.H., Bik, A.J., Dehnert, J.C., Horn, I., Leiser, N., and Czajkowski, G. Pregel: a system for large-scale graph
processing. In SIGMOD 10: Proceedings of the 2010 international conference on Management of data (New York, NY, USA, 2010), ACM,
pp.135146.
[18] Goudreau, M.W., Lang, K., Rao, S.B., Suel, T., and Tsantilas, T. Portable and efficient parallel computing using the BSP model. IEEE
Transactions on Computers 48, 7 (July 1999), 670689.
[19] Macambira, T.A., and Guedes, D. A middleware for parallel processing of large graphs. In Proceedings of the 8th International Workshop
on Middleware for Grids, Clouds and e-Science (New York, NY, USA, 2010), MGC 10, ACM, pp.7:17:6.
[20] Low, Y., Bickson, D., Gonzalez, J., Guestrin, C., Kyrola, A., and Hellerstein, J.M. Distributed Graphlab: a framework for machine learning
and data mining in the cloud. In Proceedings of VLDB Endowment 5, 8 (Apr. 2012), 716727.
Projeto e implementao de aplicaes Big Data
16
Projeto e implementao de aplicaes
Nesta seo, primeiro apresentamos uma metodologia para a construo de aplicaes big-data. Esta metologia se
divide em cinco etapas, detalhadas nas sees a seguir. Aps esse detalhamento, apresentamos alguns estudos de
caso de desenvolvimento de aplicaes de processamento de dados massivos desenvolvidas pelos alunos da
disciplina no DCC/UFMG.
Descrio da aplicao
A primeira etapa da metodologia a descrio da aplicao. Essa descrio tem por objetivo identificar claramente a
aplicao a ser paralelizada e o contexto da paralelizao. A descrio consiste das seguintes informaes:
Denominao: Para fins de referncia, importante estabelecer uma denominao para a aplicao, a qual pode ser
o nome do algoritmo, da famlia de algoritmos ou mesmo da aplicao como um todo que faz uso de um ou mais
algoritmos.
Contexto: O contexto da aplicao apresenta informaes histricas sobre a mesma, assim como a sua evoluo em
termos de propostas e cenrios de aplicao. Informaes sobre a sua relevncia, impacto e aplicabilidade tambm
so pertinentes. Essas informaes podem subsidiar e explicar requisitos, cargas de trabalho e parmetros de
execuo, alm de prover indicaes sobre qual algoritmo (se houver mais que um) o mais apropriado para a
paralelizao.
Algoritmo(s): A descrio do algoritmo deve ser feita em alguma linguagem ou pseudo-linguagem de fcil
entendimento, em geral com caractersticas imperativas. O nvel de detalhe dessa descrio deve ser tal que seja
possvel replicar e reimplementar o algoritmo, mesmo que fazendo uso de tipos abstratos de dados conhecidos. Caso
haja mais de um algoritmo aplicvel, todos devem ser descritos e detalhados, o que se configura um importante
subsdio para a paralelizao.
Exemplo(s) de Funcionamento: A metodologia ora apresentada se baseia fortemente no entendimento do
funcionamento dos vrios algoritmos, o que fundamental para capturar as interaes entre os componentes de
processamento, armazenamento e comunicao. Assim, exemplos didticos mostrando o funcionamento de cada
algoritmo descrito para entradas de pequena magnitude (toy problems) so um importante subsdio.
Requisitos: A elicitao dos requisitos a serem atendidos pela aplicao paralelizada uma informao chave no
apenas para o processo de paralelizao em si, mas para a escolha dos componentes e plataformas a serem utilizados,
assim como a sua integrao. A seguir apresentamos alguns requisitos tpicos, mas a lista no exaustiva, devendo
ser revisitada e estendida diante do contexto da aplicao, da sua paralelizao e do seu uso. So eles: escalabilidade,
armazenamento, latncia e tolerncia a falhas.
Escalabilidade a propriedade de um sistema ou aplicao de aumentar a sua capacidade de processamento medida
que aumenta o volume de dados a serem processados. A informao de escalabilidade importante a estimativa do
volume de dados a ser processado e a expectativa de eficincia computacional esperada ao process-los. A eficincia
computacional um aspecto determinante da infra-estrutura necessria para executar a aplicao paralelizada, alm
de afetar outros requisitos como latncia.
Armazenamento se refere expectativa de volume de dados a ser processado e gerado como resultado do
processamento. Os requisitos de armazenamento podem ser divididos entre armazenamento em memria e em disco,
ou outro dispositivo de armazenamento perene. Os requisitos de armazenamento tambm podem ser detalhados ao
longo da execuo de um algoritmo ou mesmo entre os vrios algoritmos usados. Latncia se refere aos limites em
termos de tempo de execuo para a aplicao, ou algoritmos que a compem. Normalmente derivados do cenrio de
17
aplicao.
A tolerncia a falhas especifica tanto as garantias a serem providas pelo algoritmo em relao a dados e resultados
que sejam garantidamente preservados, assim como quanto da plataforma seja afetada sem que haja prejuzo em
termos de processamento, armazenamento e comunicao.
Paralelizaes existentes: Uma ltima informao relevante para a descrio da aplicao a identificao e breve
descrio das paralelizaes existentes, com nfase nos algoritmos, nas oportunidades de paralelizao exploradas,
cenrios de aplicao e plataformas utilizadas. Neste caso, a intuio que vrios desses resultados possam ser
reutilizados ou estendidos.
Projeto
Durante a fase de projeto que so identificadas as oportunidades de paralelismo e sobreposio de computao,
armazenamento e comunicao a serem exploradas. Identificamos quatro componentes no projeto:
Oportunidades de paralelizao: As oportunidades de paralelizao so as vrias possibilidades de computao
concorrente inerentes a cada algoritmo a ser paralelizado. A oportunidade de paralelizao deve ser descrita em
termos das pores de cdigo a serem executadas em paralelo e os dados que elas acessam. Pode tambm ser
interessante apresentar o grau de concorrncia potencial em funo do tamanho da entrada ou outro parmetro de
execuo.
Padres de acesso aos dados: Os padres de acesso aos dados especificam como cada uma das oportunidades de
paralelizao elencadas acessam as vrias estruturas de dados manipuladas em cada algoritmo a ser paralelizado.
Esses padres podem ser definidos em termos de distncias entre acessos concorrentes e sua regularidade. Por
exemplo, se temos um loop embaraosamente paralelo que inicializa um vetor, o padro de acesso ao mesmo
apresenta distncia 1 entre os acessos. Os padres de acesso tambm devem considerar se os dados esto em
memria ou em algum dispositivo de armazenamento. Para esse ltimo caso, devemos tambm indicar quando os
dados armazenados sero novamente utilizados e at que ponto a possibilidade de realizar operaes assncronas e
sobrepostas com outras interessante.
Padres de comunicao: Os padres de comunicao materializam os fluxos de dados entre unidades de
processamento, novamente considerando cada uma das oportunidades de paralelizao elencadas. Dada uma
configurao de processos e a distribuio da computao entre eles, queremos determinar se h alguma regularidade
nas origens e destinos de dados trafegados entre processos. Mais ainda, identificamos o quanto possvel antecipar o
envio dos dados no contexto da oportunidade de paralelizao, de forma a explorar as possibilidades de sobreposio
entre computao e comunicao.
Linha do tempo integrada: A linha do tempo integrada tambm construda por oportunidade de paralelizao,
identificando, para um conjunto de unidades de processamento, armazenamento e comunicao a sua atuao ao
longo da execuo. A linha do tempo resultante permite avaliar a aplicao paralelizada de forma integrada, entender
compromissos entre as vrias oportunidades de paralelizao e identificar potenciais fontes de degradao de
desempenho.
18
Desenvolvimento
Durante a etapa de desenvolvimento, as estratgias em cada dimenso so escolhidas e detalhadas. Este
detalhamento visa subsidiar a sua implementao eficiente em diferentes plataformas tanto em termos de primitivas
(ambientes de programao) quanto de eficincia das operaes (ferramentas).
Estratgias de paralelizao: devem detalhar, para cada oportunidade de paralelizao escolhida, os seus detalhes
de implementao, o que pode variar considerando se a paralelizao por dados ou tarefas, por exemplo. A
implementao tambm inclui detalhes das operaes de armazenamento e comunicao. Em termos de
armazenamento, devemos detalhar as estruturas de dados utilizadas e a sua distribuio temporal. Em termos de
comunicao, os dados a serem comunicados, quando eles podem e/ou devem ser enviados e recebidos e outros
aspectos como roteamento. A partir destas informaes, detalhamos as estratgias de armazenamento e comunicao.
Estratgias de armazenamento: definem os requisitos das plataformas e mecanismos a serem utilizadas. No caso
de armazenamento em memria voltil, alm das estruturas de dados, consideramos estruturas de sincronizao, seu
escopo e sua natureza. J para armazenamento em plataformas perenes, os requisitos em termos de armazenamento e
principalmente recuperao dos dados armazenados devem ser considerados. Mais ainda, devemos considerar
estratgias que utilizem armazenamento como estratgia de compartilhamento de dados.
Estratgias de comunicao: avaliam quais dados devem ser enviados quando. Aspectos como buffering,
marshalling, e prefetching devem ser considerados e avaliados para fins de eficincia. A adequao das primitivas de
comunicao e a a eficincia das implementaes deve tambm ser considerada. Por exemplo, multicast
frequentemente uma operao de alto custo em vrias plataformas.
Em suma, ao fim da etapa de desenvolvimento, temos os requisitos da aplicao paralelizada detalhados nas vrias
dimenses.
Implementao
A etapa de implementao visa detalhar como a aplicao paralelizada vai funcionar em uma plataforma
computacional alvo.
Plataformas e ferramentas: Devem ser indicadas as plataformas e ferramentas a serem utilizadas, assim como
justificadas as escolhas em termos dos requisitos elicitados nas etapas anteriores.
Integrao de plataformas e ferramentas: Deve ser detalhado como as vrias plataformas e ferramentas sero
integradas, por exemplo, mapeando a linha do tempo integrada no ambiente de execuo e verificando a sua
adequao e completude.
Detalhes de implementao: Aqui so indicados outros detalhes de implementao, como caractersticas das
plataformas computacionais e mesmo mecanismos adicionais que devem ser incorporados para alcanar o modelo de
funcionamento desejado.
Avaliao
A fase de avaliao tem por objetivo verificar se as vrias premissas se confirmam e se a paralelizao atingiu os
seus objetivos. Caso no tenha sido o caso, permite identificar as fontes de degradao de desempenho que so o
ponto de partida para a reavaliao do processo de paralelizao.
Carga de trabalho: O primeiro passo do processo de avaliao a definio de uma ou mais cargas de trabalho que
permitam uma avaliao to realista quanto possvel de quo bem os requisitos da aplicao foram atingidos. A
carga de trabalho pode consistir de dados de entrada para aplicao ou um conjunto de tarefas a serem executadas,
entre outras possibilidades. A carga de trabalho tambm define os conjuntos de parmetros a serem utilizados, assim
como a justificativa da pertinncia da avaliao do seu impacto.
19
Avaliao experimental: A avaliao experimental consiste em realizar o plano experimental que permita exercitar
as vrias dimenses da carga de trabalho. importante mencionar que a aplicao paralelizada deve ser
instrumentada para obter as medidas necessrias para a avaliao.
Anlise de resultados: Uma vez que os experimentos tenham sido concludos, deve-se avaliar o quanto os vrios
requisitos foram satifeitos e as limitaes da paralelizao. Uma lista no exaustiva de aspectos a serem avaliados
seria: identificao de gargalos, tendncias, escalabilidade e nvel de aderncia a requisitos.
Anlise Crtica: O estgio final da avaliao deve discutir as prioridades em termos das decises de projeto e
implementao a serem reavaliadas e retificadas se for o caso, subsidiando um novo ciclo de desenvolvimento.
Estudos de caso
Durante o segundo semestre de 2012, o material deste wikilivro foi usado como base para a disciplina de
Processamento de Dados Massivos do DCC/UFMG. Durante o curso, alunos desenvolveram trabalhos na rea com
base em alguns problemas sugeridos e tambm seus interesses pessoais. As sees a seguir detalham a experincia
de cada aluno/grupo.
Minerao de Itemsets Frequentes
Descrio da aplicao
Esta seo apresenta uma discusso acerca do problema de minerao de itemsets frequentes no contexto de
processamento de dados massivos (ou big-data).
Denominao
Minerao de Itemsets Frequentes (MIFs)
Dado um conjunto de transaes , o objetivo da Minerao de Itemsets Frequentes encontrar todos os conjuntos
de itens (itemsets) tais que o suporte seja maior ou igual a um suporte mnimo previamente estabelecido. Define-se
suporte de um itemset como sendo a porcentagem de transaes onde este itemset aparece.
Formalmente, podemos definir a tarefa de minerar itemsets frequentes como:
Seja um conjunto de itens (o conjunto de todos os artigos de um
supermercado, por exemplo). Seja uma base de dados de transaes, isto , uma tabela de duas
colunas, a primeira corresponde ao TID (identificador da transao) e o segundo corresponde
transao propriamente dita, ou seja, um conjunto de itens (por exemplo, os itens comprados por um
cliente). Os elementos de so chamados de transaes. Um itemset um subconjunto no vazio de
. Diz-se que uma transao suporta um itemset se .
A seguir, so apresentadas sucintamente algumas definies importantes para o entendimento da aplicao discutida
ao longo das prximas sees:
Itemset: Conjunto com um ou mais itens;
Suporte: Frequncia de ocorrncia de um conjunto de itens (itemset);
Suporte Mnimo: Frequncia mnima de ocorrncia que um itemset deve possuir para ser considerado frequente;
Itemset frequente: Itemset que possui um suporte igual ou superior um suporte mnimo;
Itemset frequente maximal: Dado o conjunto frequente de itemsets F, um itenset X, pertencente F, ser
maximal se e somente se para todo Y, tambm pertencente a F, X no seja um subconjunto de Y.
A propriedade Apriori, muito importante na minerao de itemsets frequentes, estabelece o seguinte:
20
Sejam e dois itemsets tais que . Se frequente, ento tambm frequente. Assim,
para que um itemset seja frequente necessrio que todos itemsets contidos nele sejam tambm
frequentes. Caso um nico itemset contido em no seja frequente, o suporte de nem precisa ser
computado, pois sabe-se de antemo que nunca poder ser frequente.
Contexto
Um dos conceitos mais poderosos no contexto de minerao de dados a identificao de itemsets frequentes.
Minerao de itemsets frequentes so uteis em inmeros contextos, dentre as quais destacam-se: anlise de logs na
web, anlise baseada em mercado, minerao de regras de associao, entre outras tarefas de minerao de dados.
Alm disso, vrios algoritmos dependem da gerao eficinte de itemsets frequentes. Um exemplo o algoritmo
LAC, cuja carga gasta na gerao de regras de associao (que atua por meio da identificao de itemsets frequentes)
corresponde a cerca de 90% do processamento. Esse algoritmo ser discutido em outra seo desse WikiBook.
Existem vrios algoritmos para minerao de itemsets frequentes, dentre os quais destacam-se:
Apriori
Eclat
FP-Growth
SON
Na discusso apresentada ao longo dessa seo, usaremos o algoritmo SON
[1]
.
Motivao
fato que, atualmente, uma absurda quantidade de dados gerada a cada dia. A anlise desses dados comumente
revela informaes de grande importncia. Uma abordagem padro para se fazer esse tipo de anlise fazer uso de
estratgias de minerao de dados, que muitas vezes so fortemente dependentes da gerao de itemsets frequentes.
Nesse sentido, o investimento em estratgias eficientes para minerao de itemsets frequentes em grandes volumes
de dados de suma importncia.
Algoritmo
Exemplo de entrada e sada de qualquer
algoritmo de minerao de itemsets frequentes
A figura direita apresenta um exemplo de entrada e a sada
correspondente gerada por qualquer algoritmo de minerao de
itemsets frequentes. Nesse exemplo, uma base contendo quatro
transaes minerada considerando um suporte de 50%. Isso significa
que um itemset frequente se este aparece em duas ou mais transaes
dessa base.
Para gerar essa resposta, o algoritmo SON pode usar qualquer outro
algoritmo algoritmo para minerao de itemsets frequentes, como o
Apriori, Eclat, entre outros. O objetivo desse algoritmo minerar
itemsets frequentes em bases maiores que a memria principal. Para
tanto, o algoritmo SON usa uma estratgia de particionamento da base de dados por transaes, onde cada partio
sequencialmente processada na memria principal e os resultados parciais so gravados em memria secundria.
Grosso modo, o objetivo do algoritmo SON fazer com que minerao de itemsets frequentes possa ser feito em um
nico computador cuja memria principal seja menor que o tamanho da base.
21
Exemplo de funcionamento
As figuras abaixo exemplificam a aplicao do algoritmo SON em uma base contendo oito transaes. Fora o
particionamento da base, o algoritmo possui trs fases: (1) minerao de itemsets frequentes locais em cada partio;
(2) agregao das contagens locais usando a unio dos itemsets frequentes maximais gerados na etapa anterior --
chamados Upper Bounds; e (3) soma final e filtragem pelo suporte. Nesse exemplo possvel verificar que, como o
algoritmo processa uma partio por vez e os resultados intermedirios so gravados em disco, pode-se processar
uma base de transaes contendo oito transaes em uma memria principal que comporta apenas quatro.
Requisitos
Nessa seo, apresentam-se os requisitos de escalabilidade, armazenamento, latncia e tolerncia a falhas
considerados no projeto.
Escalabilidade
Ao duplicar o nmero de processadores disponveis para processamento, desejvel que o processamento execute
duas vezes mais rpido. Isto , almeja-se obter um speed-up prximo ao linear. De fato, esse resultado foi alcanado
pela abordagem aqui apresentada.
Armazenamento
Em muitos cenrios reais o volume de dados tal que no possvel armazen-lo em apenas uma mquina. Sendo
necessrio um conjunto de mquinas para comportar esse volume. Esse o cenrio ideal para anlise da aplicao
aqui desenvolvida.
Latncia
Consideramos nesse projeto que a identificao de itemsets frequentes seja um processo offline e portanto no
assumimos nenhum requisito de latncia. Deseja-se porm obter speed-up prximo ao linear.
Tolerncia a falhas
Dado o grande volume de dados e o tempo necessrio para processamento, comum que aplicaes de big-data
possuam tolerancia a falhas. Embora na presente aplicao tal quesito tambm seja importante, no entraremos no
mrito de propor estratgias de tolerancia a falhas nesse trabalho. Diversos frameworks implementam tolerancia a
falhas, evitando que o programador tenha tais preocupaoes. Portanto, deixaremos isso por conta do framework a ser
utilizado. Alm disso, a existencia ou no de tolerancia a falhas no est intrinsecamente relacionada ao algoritmo.
Assim, para o contexto em questo assumimos que isso no crtico.
22
Projeto
Oportunidade de paralelizao
Conforme j mencionado em sees anteriores, comum que aplicaes de minerao de dados dependam da
extrao de itemsets frequentes em grandes volumes de dados. Muitas vezes esses volumes no podem ser
armazenados em uma nica mquina. Nesse sentido, uma abordagem natural particionar a base de dados de forma
que cada n seja responsvel por armazenar e processar um subconjunto da totalidade.
A oportunidade de paralelizao explorada nesse trabalho o particionamento da base de dados por transaes.
Dessa forma, cada n responsvel por um subconjunto das transaes. Vale observar que o particionamento por
trasaes mais indicado em casos onde a quantidade de transaes muito maior que a quantidade de itens
presentes em cada transao. Caso contrrio, o particionamento por itens poderia ser mais mais indicado.
A estratgia adotada nesse trabalho semelhante oportunidade de paralelizao explorada pelo algoritmo Parallel
SON (PSON)
[2]
, um algoritmo paralelo para extrao itemsets frequentes. Grosso modo, o PSON uma verso
paralela do algoritmo SON. Assim como no algoritmo SON, no PSON a dependncia de dados proveniente do
princpio Apriori tambm no problema. Na infraestrutura de computao, a qual pode ser descrita como um grafo
onde cada n uma mquina, a dependncia maior intra n.
O algoritmo SON, e por consequncia o PSON, se beneficia do seguinte princpio:
Um itemset frequente global, certamente frequente local em pelo menos uma das parties.
A primeira fase do algoritmo PSON consiste diviso da base de dados por transaes. Em seguida, extrai-se o
conjunto de itemsets frequentes maximais (IFMs) em cada partio. Note que esse passo que pode ser feito
paralelamente. A prxima etapa a unio dos conjuntos de IFMs gerados, tal unio consiste ento no conjunto de
candidatos ao ttulo de itemsets frequentes globais. O ltimo passo a contagem de cada elemento do conjunto
potncia de cada candidato em todas as parties e posterior soma do nmero de ocorrncias e filtragem dos itemsets
frequentes globais.
Padres de acesso aos dados
Padro de acesso aos dados
Na abordagem aqui apresentada, os dados so particionados por
transaes. Cada n de processamento atua em um subconjunto das
transaes existentes na base original. Especificamente, cada partio
gravada em um arquivo distinto.
Considerando que a base j esteja particionada, cada partio
acessada em dois momentos durante o processamento. Em cada acesso,
as transaes correspondentes cada partio so lidas para a memria
principal e feito o processamento. Portanto, para que o
processamento ocorra de forma eficiente o particionamento da base de
dados deve considerar um parmetro importante, o tamanho da
memria principal. Assim, nenhuma partio deve ser maior que a
memria principal, caso contrrio o overhead causado pelo gerenciamento da memria virtual (e consequentemente
uso da memria secundria) poderia reduzir drasticamente a eficincia do processamento.
O primeiro acesso refere-se gerao dos itemsets frequentes em cada partio. O segundo, ocorre aps a unio dos
itemsets frequentes maximais gerados na primeira etapa. Nesse momento, cada partio novamente lida do disco.
A figura direita dessa pgina apresenta um diagrama temporal que representa visualmente o padro de acesso aos
dados adotado nesse trabalho. Nessa figura, cubos representam processos e cada cilindro representa uma partio dos
dados.
23
Vale observar que, conceitualmente, apenas uma leitura necessria, visto que as mesmas parties so lidas duas
vezes. Porm, do ponto de vista de projeto h beneficios em separar as leituras. Tais benefcios ficaram claros ao
longo do texto. Grosso modo, a base apenas precisa estar na memria principal durante a montagem da estrutura de
dados requisitada pelo algoritmo de extrao de itemsets frequentes a ser usado em cada partio e durante a
contagem dos itens na ltima fase; portanto, remover esses dados da memria principal libera espao para a prpria
extrao de itemsets frequentes locais e outros processamentos. Alm disso, no h perdas significatvas de
desempenho.
Outro ponto importante , dependendo de como a presente estratgia implementada, haver mais ou menos acessos
a disco. Caso a implementao seja feita em Hadoop, por exemplo, haveria mais acessos a disco, visto que grande
parte da comunicao ocorre por meio de arquivos.
Padres de comunicao
Padro de comunicao
Para tornar mais clara a explicao do mtodo faz-se necessria uma
distino clara entre o n central e os ns de processamento de
transaes. O n central responsvel por gerenciar a computao dos
ns que processam transaes (ou doravante, ns de processamento). A
figura direita dessa pgina apresenta um diagrama que representa os
padres de comunicao da abodagem proposta.
No contexto de trocas de mensagens, o processamento pode ser
descrito como segue. O n central envia uma mensagem para cada n
de processamento, o objetivo enviar os parmetros necessrios e
iniciar a identificao dos itemsets frequentes em cada partio. To
logo cada n de processamento termine esse passo, uma mensagem
contendo o conjunto de itemsets frequentes maximais enviada ao n central, que faz a unio dos conjuntos
recebidos e envia uma nova mensagem a cada n de processamento contendo os itemsets frequentes maximais
gerados. Nesse momento, os ns de processamento fazem o desmembramento de cada conjunto maximal, por meio
da gerao do conjunto potncia, e efetua a contagem de cada elemento em sua respectiva partio. Ao fim dessa
contagem, cada n de processamento envia uma mensagem ao n central, que por sua vez efetua a totalizao e faz a
filtragem deixando como resultado apenas os itemsets frequentes maximais globais.
Em suma, o processamento envolve quatro momentos de troca de mensagem:
1. 1. N central envia mensagem aos ns de processamento para iniciar a computao dos IFMs locais
2. 2. Ns de processamento enviam mensagem ao n central contendo os IFMs locais
3. 3. N central envia mensagem aos ns de processamento contendo a unio dos IFMs locais
4. 4. Ns de processamento enviam ao n central mensagens contendo as contagens parciais
Note que o n central sempre envia mensagens idnticas aos ns de processamento (salvo o nome dos arquivos na
mensagem de inicializao), que por sua vez enviam sempre mesagens (potencialmente) distintas ao n central.
24
Linha do tempo integrada
A figura abaixo apresenta uma linha do tempo integrada que exemplifica o comportamento do mtodo em termos de
acesso aos dados, processamento executado e trocas de mensagens.
Implementao
Nesta seo, so discutidos os principais aspectos de implementao do algoritmo.
Estratgia de paralelizao
Algumas ferramentas e abstraes podem auxiliar o projeto e desenvolvimento de aplicaes no contexto de
processamento massivo e big-data. Encontrar aquela que mais naturalmente se adequa ao problema em questo
uma etapa importante do projeto. Dentre as ferramentas e abstraes disponveis, destacam-se:
1. 1. Ferramentas para processamento de streams;
2. 2. Processamento descrito em forma de fluxo em grafos;
3. 3. Ferramentas para processamento de grafos grandes;
4. 4. Abstrao MapReduce.
A oportunidade de paralelizao aqui descrita pode ser implementada por meio de duas chamadas MapReduce
[3]
,
conforme descrito a seguir.
25
Etapa Objetivo
1
o
mapeamento
Extrao dos itemsets frequentes maximais (IFMs) locais de cada partio
1
a
reduo
Unio dos IFMs
2
o
mapeamento
Contagens locais baseadas na unio dos IFMs
2
a
reduo
Totalizao e filtragem pelo suporte
A estratgia supracidata foi implementada em C++ usando o framework MapReduce++, descrito nas prximas
seo. As quatro caixas abaixo apresentam o cdigo das funes de mapeamento e reduo nas duas chamadas do
MapReduce. O cdigo apresentado apenas a ttulo de curiosidade, o intuito mostrar como tais funes so
implementadas nesse framework. O leitor pode pular esses cdigos sem prejuzo de intrepretao e entendimento da
abodagem adotata para implementar a estratgia proposta.
class FMIMapper : public MaPI_StrMapper {
public:
FMIMapper(MaPI_StrMapReduce * mr, MaPI_StrSerializer * s):MaPI_StrMapper(mr,s){};
virtual vector< pair<string,string> > map( pair<string,string> a )
{
vector< pair<string,string> > mapped;
// ... some parts are omited
vector<Transaction> transactions = transactionReader.read(filename); // Building transaction set
ItemsetMiner * miner = new Eclat(vocabulary, minsupport, maxrulesize); // Calling Eclat
InvList * invlist = miner->mine(transactions);
for (pair< set<unsigned>,set<unsigned> > mfi : (*invlist) )
{
stringstream str; str << mfi.second.size() << ' ';
vector<unsigned> termids(mfi.first.begin(),mfi.first.end());
for (unsigned termid : termids) str << vocabulary.terms[termid] << ' ';
mapped.push_back(make_pair(a.second,str.str()));
}
return mapped;
};
};
class FMIReducer : public MaPI_StrReducer {
public:
FMIReducer(MaPI_StrMapReduce * mr, MaPI_StrSerializer * s):MaPI_StrReducer(mr,s){};
virtual pair<string,string> reduce( pair<string, vector<string> > bs )
{
stringstream reduced;
for (unsigned i = 0 ; i < bs.second.size() ; ++i) reduced << bs.second[i] << '\n';
return pair<string,string>(bs.first,reduced.str());
};
};
class SubsetCountMapper : public MaPI_StrMapper {
public:
26
SubsetCountMapper(MaPI_StrMapReduce * mr, MaPI_StrSerializer * s):MaPI_StrMapper(mr,s){};
virtual vector< pair<string,string> > map( pair<string,string> a )
{
vector< pair<string,string> > mapped;
string filename = a.first;
string filename_subsets = a.second;
SubsetHandler subsetHandler;
vector<pair<string, unsigned> > subset_counting = subsetHandler.countsubsets(filename, filename_subsets);
for (pair<string,unsigned> itemset : subset_counting)
{
stringstream str; str << itemset.second << ' ';
mapped.push_back(make_pair(itemset.first,str.str()));
}
return mapped;
};
};
class SubsetCountReducer : public MaPI_StrReducer {
public:
SubsetCountReducer(MaPI_StrMapReduce * mr, MaPI_StrSerializer * s):MaPI_StrReducer(mr,s){};
virtual pair<string,string> reduce( pair<string, vector<string> > bs )
{
unsigned sum(0);
for (unsigned i = 0 ; i < bs.second.size() ; ++i) sum += atoi(bs.second[i].c_str());
stringstream reduced; reduced << sum;
return pair<string,string>(bs.first,reduced.str());
};
};
Estratgia de armazenamento
Cada partio da base de dados armazenada em um arquivo de transaes. Trata-se de um arquivo de caracteres
(textual), porm nada impede o uso de arquivos binrios de bloco ou mesmo gerenciadores de banco de dados.
Estratgia de comunicao
A implementao feita nesse trabalho baseia-se no framework MaPI, que integra o projeto MapReduce++ (conforme
discute-se na prxima seo). Esse framework uma camada de abstrao sobre MPI, ou Message Passing Interface.
Portanto, a comunicao feita por trocas de mensagens.
27
Execuo
Plataforma e ferramentas
A estratgia aqui apresentada foi implementada usando MapReduce++.
MapReduce++
MapReduce++
[4]
um projeto open-source cujo objetivo disponibilizar diferentes implementaes da abstrao
MapReduce na linguagem de programao C++. Esse projeto define uma interface padro para desenvolvimento de
bibliotecas MapReduce, que serve como base para suas implementaes. Atualmente, MapReduce++ contm duas
implementaes paralelas do modelo MapReduce:
MapMP - uma biblioteca MapReduce para multi-processadores (memria compartilhada) baseada em OpenMP
MaPI
[5]
- um framework MapReduce para multi-computadores (memria distribuda) baseado em Message
Passing Interface (MPI)
H tambm uma terceira verso, chamada SeqMR, que tem como objetivo auxiliar o usurio durante a etapa de
desenvolvimento. Trata-se de uma verso sequencial para desenvolvimento. Portanto, caso o usurio no possua o
ambiente de execuo, este pode desenvolver a aplicao MapReduce usando SeqMR que no requer nenhum
recurso alm do gcc/g++. Finalizada a etapa de desenvovimento, o usurio deve ento fazer pequenas adaptaes no
cdigo para explorar o paralelismo intrnseco s tarefas de mapeamento e reduo. So alteraes como mudar a
herana das classes de SeqMR para MapMP, no caso de memria compartilhada, ou para MaPI no caso de memria
distribuda. Nesse ltimo caso, faz-se necessria tambm a criao de serializadores e a inicializao dos servidores
de mapeamento e reduo.
Uma boa forma comear o desenvolvimento de aplicaes usando implementaes baseadas em MapReduce++
(alternativa quela apresentada no paragrafo anterior) baseando nos exemplos disponveis no projeto. Visto que os
dados da aplicao aqui discutida podem no caber em uma s mquina, a implementao MaPI a mais indicada
para o nosso propsito. A seguir, apresentado um passo-a-passo desde o download at a execuo de um programa
MaPI.
MaPI: Download
Baixe a verso mais atual do MapReduce++ no SourceForge
http:/ / sourceforge. net/ projects/ mapreducepp/
MaPI: Instalao no Ubuntu Linux
Para desenvolver e executar programas MaPI, necessrio ter compilador g++ e suporte para desenvolvimento e
execuo de programas baseados em MPI.
Instale o g++ com o seguinte comando no terminal:
$ sudo apt-get install g++
Para suporte a MPI, pode-se usar a implementao OpenMPI (recomendada):
$ sudo apt-get install openmpi-bin libopenmpi-dev
ou MPICH2, se preferir:
$ sudo apt-get install mpich2
28
MaPI: Exemplo de aplicao
A seguir apresentamos um exemplo de aplicao, onde o MapReduce descrito pela herana de duas classes
abstratas. Especificamente, so implementadas as funes map de MaPI_Mapper e reduce de MaPI_Reducer. Neste
exemplo, um vetor contendo trs elementos (chave,valor) de tipo (int,char) mapeado por uma funo que apenas
transmite a entrada para a sada (isto , no faz nada) e reduzido por uma funo que agrupa elementos de mesma
chave. O cdigo apresentado abaixo (nota: algumas partes so omitidas, o cdigo completo est disponvel no
SourceForge).
#include "../MaPI/MaPI.h"
#include <iostream>
#define MRType int,char,int,char,string
class MyMapper : public MaPI_Mapper<MRType> {
public:
virtual vector< pair<int,char> > map( pair<int,char> a )
{
vector< pair<int,char> > m(1,a);
cout << "\tMapping..\n";
return m;
};
};
class MyReducer : public MaPI_Reducer<MRType> {
public:
virtual pair<int,string> reduce( pair<int, vector<char> > bs )
{
string reduced;
for(unsigned i=0;i<bs.second.size();i++) reduced += bs.second[i];
cout << "\tReducing..\n";
return make_pair(bs.first,reduced);
};
};
int main(int argc,char** argv)
{
MaPI_MapReduce<MRType> mapReduce;
MySerializer serializer;
MyMapper mapper(&mapReduce,&serializer);
MyReducer reducer(&mapReduce,&serializer);
mapReduce.initServers(argc,argv);
vector< pair<int,char> > input;
input.push_back(make_pair(1,'a'));
input.push_back(make_pair(2,'b'));
input.push_back(make_pair(1,'c'));
vector< pair<int,string> > output = mapReduce.run(mapper,reducer,input);
cout << output << endl;
return 0;
}
O usurio deve especificar os seguintes cinco tipos:
da chave e do valor de entrada
29
da chave e do valor intermedirio
do valor de reduo
Para compilar e executar o programa o usurio deve usar a seguinte linha de comando, onde "-np 3" significa que
mpirun usar trs processos:
$ mpiCC ex01.cpp -o program && mpirun -np 3 ex01
Ao executar o comando acima, a aplicao de exemplo produzir a seguinte sada, onde a ltima linha o resultado
produzido pelo MapReduce.
Mapping..
Mapping..
Mapping..
Reducing..
Reducing..
vector(2) [pair(1 , "ac") , pair(2 , "b")]
MaPI: Configurao do cluster
At ento, os testes foram executados em uma mquina apenas. Para usar um cluster, necessria a instalao do ssh
client e server.
$ sudo apt-get install openssh-server openssh-client
Como iniciar e parar um servidor ssh:
$ sudo /etc/init.d/ssh start
$ sudo /etc/init.d/ssh stop
Avaliao
Nesta seo so apresentados os experimentos computacionais e uma discusso analtica acerca dos resultados.
Carga de trabalho
Para a execuo dos experimentos computacionais, foram utilizadas bases de dados de diversos tamanhos. Essas
bases de dados se dividem em duas categorias. Na primeira categoria, variou-se o nmero de transaes (N) e
fixou-se o nmero de itens por transao (D). Enquanto na segunda categoria ocorreu o oposto, isto , o nmero de
transaes (N) foi fixado e o nmero de itens por transao (D) foi variado. A seguir a tabela apresenta as bases de
dados utilizadas e seus respectivos tamanhos em MB:
Categoria 1 Categoria 2
N = 100.000 e D = 10 (2.7 MB) N = 300.000 e D = 10 (8.4 MB)
N = 300.000 e D = 10 (8.4 MB) N = 300.000 e D = 20 (14.2 MB)
N = 500.000 e D = 10 (13.7 MB ) N = 300.000 e D = 50 (31 MB)
N = 1.000.000 e D = 10 (27,9 MB) ---
N = 3.000.000 e D = 10 (82,7 MB) ---
As duas categorias de base de dados de testes expressam a dimensionalidade dos problemas de minerao de
itemsets frequentes em dados massivos, ou seja, no mundo real as grandes bases de dados crescem em termos de
nmero de transao e em nmero de itens por transao. Por isso as duas variaes foram exploradas.
30
Avaliao
Planejamento experimental
O objetivo deste trabalho apresentar uma soluo paralela distribuda que melhore a performance, em termos de
tempo de execuo, a tarefa de minerao de itemsets frequentes. Para tanto, sero apresentados resultados de testes
variando-se tanto o nmero de transaes de uma base de dados, quanto o nmero de itens por transao, conforme
detalhado na seo anterior.
Para cada base de teste, a estratgia implementada foi executada utilizando 1, 2, 4 e 8 ns de processamento e o
tempo total de processamento foi medido para posterior anlise. Vale observar que a diviso da base de dados uma
etapa anterior ao processamento, isso representa bem os casos reais visto que o objetivo no final aplicar o
algoritmo em bases que no caibam em uma mquina apenas, portanto em casos reais no contexto de processamento
massivo a diviso da base tambm seria feita previamente ao processamento. Assim, o tempo aqui medido
desconsidera o trabalho de particionamento da base.
Ambiente Computacional
Para a execuo dos testes foi utilizado um cluster com oito ns de processamento. Cada n do cluster composto de
uma Virtual CPU (VCPU) com 2 GB de memria RAM e 10 GB de HD. O sistema operacional utilizado em cada n
foi o Ubuntu 12.04. O algoritmo foi implementado em C++.
Resultados
A seguir so apresentados os grficos demonstrando o speedup e tempo de execuo utilizando-se as bases de dados
de testes da primeira categoria, onde variou-se o nmero de transaes. Observe que, quanto maior o nmero de
transaes melhor o speedup.
Speedup obtido para diferentes nmeros de transaes
Tempo de execuo obtido para diferentes nmeros de transaes
Tambm foi coletado o tempo de execuo e o speedup para a segunda categoria de bases de teste, onde variou-se o
nmero de itens por transao. Os resultados so apresentados nos grficos a seguir. Note que nesse caso o speedup
obtido no to bom. Esse fato previsto e discutido na seo "Projeto", ao aumentar o nmero de transaes
aumenta-se tambm a dependabilidade entre os dados (intrnseca ao Princpio Apriori) durante o primeiro
mapeamento. Trata-se de uma dependabilidade intra-n, durante a gerao de itemsets frequentes na primeira etapa
de mapeamento.
31
Speedup obtido para diferentes valores de itens
por transao
Tempo de execucao obtido para diferentes
valores de itens por transao
Anlise Crtica
Na grande maioria dos casos prticos, o nmero de transaes muito maior que o nmero de itens por transao.
Resultados para esse cenrio so apresentados no conjunto de testes correspondentes Categoria 1, como definido na
seo "Carga de Trabalho", cujos grficos de speedup e tempo de execuo so os primeiros mostrados na seo
anterior.
Nesse sentido, os resultados indicam que a abordagem aqui desenvolvida para minerao de itemsets frequentes
escalvel em contextos prticos. Essa concluso vem do fato de que o speedup aumenta com o aumento da base de
dados, chegando quase ao speedup linear -- caso ideal. Outro fato que refora essa concluso que as maiores bases
usadas nesse trabalho ainda so muito pequenas se comparadas s bases prticas atuais.
Portanto, os resultados levam a crer que, ao aumentar o nmero de transaes (e consequentemente o tamanho) da
base de dados para dimenses compatveis com aplicaes reais, o speedup seria ainda melhor, isto , ainda mais
prximo do linear. Obviamente isso no pode ser tomado como verdadeiro sem a execuo de testes adequados que
comprovem essa concluso. Afinal, ao se aumentar a base em tais propores, aspectos at ento ignorados, como a
fragmentao de pacotes que carregam mensagens pela rede que interconecta os ns do cluster, poderiam gerar
algum overhead interferindo no tempo de execuo.
Referncias
[1] A. Savasere, E. Omiecinski, and S.B. Navathe, An efficient algorithm for mining association rules in large databases. Intl. Conf. on Very
Large Databases, pp. 432444, 1995.
[2] Tao Xiao; Chunfeng Yuan; Yihua Huang; PSON: A Parallelized SON Algorithm with MapReduce for Mining Frequent Sets. (http:/ /
ieeexplore. ieee. org/ xpl/ login. jsp?tp=& arnumber=6128512& url=http:/ / ieeexplore. ieee. org/ xpls/ abs_all. jsp?arnumber=6128512)
Parallel Architectures, Algorithms and Programming (PAAP), 2011.
[3] Dean, J., and Ghemawat, S. Mapreduce: simplified data processing on large clusters (http:/ / research. google. com/ archive/ mapreduce.
html). In Proceedings of OSDI'04: Sixth Symposium on Operating System Design and Implementation, 2004.
[4] MapReduce++ (http:/ / sourceforge.net/ projects/ mapreducepp/ ) no SourceForge
[5] Ribas, S; Perch, M; Coelho, IM; Munhoz, PA; Souza, MJF; Aquino, ALL; A Framework for Developing Parallel Optimization Algorithms.
(http:/ / homepages. dcc.ufmg.br/ ~sabir/ papers/ 2010-pdcs-MaPI. pdf) Informatics. ACTA Press, 2010.
Agrupamento baseado em densidade
32
Descrio
Denominao
Agrupamento de dados massivos baseado em densidade.
Contexto
A minerao de dados uma rea da computao que visa a anlise de dados para extrao de informao e
conhecimento. As tarefas de minerao podem ser divididas em supervisionadas, quando so usados registros
conhecidos para o aprendizado de mquina, e no-supervisionada quando no h uso de registros para induzir os
resultados.
O agrupamento uma tarefa no-supervisionada de minerao de dados que consiste em dividir os registros da base
de dados em grupos de forma a deixar os mais similares entre si em grupos iguais e os menos similares em grupos
distintos. Essa tarefa possui inmeras aplicaes, dentre as quais pode-se destacar os sistemas de recomendao,
predio de funes proteicas e resoluo de entidades.
Trs dos principais algoritmos de agrupamento so o K-means
[1]
, o Expectation Maximization - EM
[2]
e o DBScan
[3]
. Ao contrrio do DBScan, o K-Means e o EM so algoritmos que exigem como parmetro o nmero de grupos a
serem formados e no so capazes de formar grupos com formatos arbitrrios, alm de serem sensveis presena de
excees. Porm o DBScan o algoritmo mais caro entre eles: apresenta custo quadrtico em relao ao tamanho da
base.
Considerando que essa abordagem baseada em densidade fundamental para algumas aplicaes, como por
exemplo, quando o nmero de grupos no conhecido ou quando h excees na base, e se observado o crescente
volume de dados disponveis, torna-se desejvel a utilizao desse algoritmo para suportar dados massivos de forma
que o agrupamento possa ser realizado com eficincia e escalabilidade.
Algoritmo
O DBScan um algoritmo de agrupamento baseado em densidade de registros por regio, o que permite a formao
de grupos no-convexos e com formatos arbitrrios. A figura 1 mostra um exemplo de registros que s podem ser
agrupados corretamente utilizando-se esse algoritmo devido ao formato arbitrrio dos grupos.
Figura 1: Situao em que os registros s podem
ser agrupados corretamente utilizando-se um
algoritmo baseado em densidade.
Essa tcnica recebe dois valores como parmetros: o valor de corte D que indica a distncia mxima que dois pontos
podem estar para eles serem considerados vizinhos e o nmero mnimo de vizinhos N que um ponto deve ter para ser
considerado um ponto de centro, conforme ser mostrado.
33
A definio de vizinhana V nesse contexto para um determinado ponto P dada pelo conjunto de pontos que esto a
uma distncia d menor ou igual a D, ou seja,
V(P) = {Y | d(P,Y) <= D}.
A principal limitao em termos de eficincia do DBScan a sua primeira etapa que consiste em calcular a distncia
entre todos os pares possveis de registros da base B para definir quantos vizinhos cada um possui e ento
classific-los como ponto de centro, ponto de borda ou exceo. Os pontos de centro so aqueles que possuem N ou
mais vizinhos. Os pontos de borda no possuem N ou mais vizinhos mas so vizinhos de um ponto de centro. Os
registros considerados excees possuem menos de N vizinhos e no so vizinhos de nenhum ponto de centro. A
figura 2 ilustra as trs classificaes que um ponto pode receber nesse algoritmo.
Figura 2: Classificao dos pontos de acordo com o DBScan sendo o valor do parmetro N igual a 5.
Aps essa etapa de classificao, os pontos de centro so percorridos e seus vizinhos so assimilados a seu grupo. Se
um dos vizinhos do ponto de centro que est sendo percorrido for outro ponto de centro X, o algoritmo passa a
percorrer os vizinhos de X. Observa-se que a ordem de percorrimento dos pontos de centro no alteram a disposio
dos pontos de centro entre os grupos, porm pode influenciar na assimilao dos pontos de borda aos grupos. Os
pontos excees no so assimilados a nenhum grupo, independente da ordem de percorrimento. O algoritmo abaixo
mostra os passos executados pelo DBScan conforme
[4]
.
DBScan(B, D, N):
Para cada registro P em B {
Computa os vizinhos de P;
Classifica P;
}
grupoAtual = 0;
Para cada ponto de centro P no visitado {
grupoAtual++;
34
Assimila(P, grupoAtual);
}
Retorna resultado do agrupamento;
Assimila(P, grupoAtual):
Assimila P ao grupo grupoAtual;
Para cada vizinho Q de P {
Assimila Q ao grupo grupoAtual;
Se Q ponto de centro {
Assimila(Q, grupoAtual);
}
}
Quanto ao armazenamento, a implementao original do DBScan utiliza a estrutura R*-tree
[5]
para manter todos os
registros em memria secundria.
35
Exemplo de funcionamento
Essa seo mostra passo-a-passo como o DBScan realiza o agrupamento para os dados mostrados na figura 3 com
parmetros de distncia e nmero mnimo de vizinhos iguais a e , respectivamente.
Figura 3: Distribuio dos pontos a serem agrupados.
Inicialmente, a distncia entre os pares de registros so calculados. Os valores esto mostrados na tabela abaixo.
Ponto 1 2 3 4 5 6 7 8
1 0
2 - 0
3 - - 0
4 - - - 0
5 - - - - 0
6 - - - - - 0
7 - - - - - - 0
8 - - - - - - - 0
A medida que os pares de pontos tm suas distncias calculas, os pontos so classificados como ponto de centro, de
borda, ou exceo. Observa-se que nesse exemplo para dois pontos serem considerados vizinhos eles devem estar a
uma distncia menor ou igual a . O resultado da classificao est mostrado abaixo.
36
Classificao Pontos
Pontos de centro 3,5,6,8
Pontos de borda 1,4
Excees 2,7
Na segunda fase do DBScan, os pontos de centro so percorridos. O primeiro grupo criado possui o ponto de centro
3 e durante o percorrimento de seus vizinhos, os pontos 5 e 6 so assimilados a esse grupo. O segundo grupo criado
possui inicialmente o ponto de centro 8 e a medida que seus vizinhos so perridos, os pontos 1 e 4 tambm so
assimilados a ele. Os pontos 2 e 7 no so vizinhos de nenhum ponto de centro e por isso no so assimilados a
nenhum grupo. A figura 4 mostra o resultado do agrupamento para esse exemplo.
Figura 4: Resultado final do agrupamento.
Requisitos
Os principais requisitos para a execuo distribuda ou em paralelo do DBScan so a escalabilidade, o
balanceamento e a tolerncia a falhas.
Escalabilidade
A escalabilidade um fator fundamental nesse contexto de algoritmos para dados massivos. Para que a
escalabilidade seja satisfeita, necessrio garantir que no haja gargalos, ou seja, a memria, o processador e a rede
de todos os ns devem estar trabalhando com a mesma carga, sem ociosidade em espera por outro evento.
37
Balanceamento de carga
O balanceamento de carga um dos fatores que contribui para escalabilidade. A diviso desbalanceada dos dados e
tarefas entre os ns em uma abordagem distribuda tem como consequncia a formao de gargalos e ociosidade, que
deixariam ineficiente a aplicao para dados massivos.
Tolerncia a falhas
A tolerncia a falhas importante para o agrupamento distribudo pois a ausncia de alguns registros no processo
tem o poder de influenciar a qualidade do resultado. Na maioria das aplicaes voltadas para dados massivos, a
tolerncia de falhas satisfeita com a replicao de registros em diferentes ns e com a projeo de algoritmos que
no possuem um nico ponto de falha.
Paralelizaes existentes
Esta seo descreve como o a implementao do DBScan j foi realizada para suportar grandes volumes de dados.
Em
[6]
apresentado uma implementao paralela do DBScan com uma abordagem mestre-escravo: enquanto o
ncleo mestre realiza a etapa de assimilao de grupos, os escravos respondem a consultas de vizinhana usando a
estrutura R*-Tree para armazenamento.
Em P-DBSCAN
[7]
, a base particionada e o agrupamento feito de forma independente entre os ns de forma
distribuda. Ao final, h uma agregao dos resultados de cada n para formar o resultado final. Quanto ao
armazenamento, a estrutura utilizada a Priority R-Tree
[8]
que uma variao eficiente da R-Tree. Nessa
implementao h a limitao de haver um nico n para juntar os resultados do agrupamento feito por todos os ns.
Alm disso, os pontos considerados excees por um n no so tratados posteriormente na juno dos grupos,
portanto grupos densos podem ser perdidos se seus registros estiverem divididos entre os ns.
De forma similar ao P-DBSCAN, o MR-DBSCAN
[9]
, proposto em , uma implementao distribuda do DBScan
com quatro estgios e que utiliza o paradigma Map-reduce
[10]
. A primeira etapa consiste em dividir a base entre os
ns de forma balanceada e de forma a deixar os registros mais prximos no mesmo n. Em seguida, na fase map, o
DBScan executado de forma independente dentro de cada n. A terceira etapa a fase reduce: todos os ns so
analisados para descobrir em quais situaes o mesmo n foi agrupado para diferentes grupos, ou seja, feito um
mapeamento da juno e remarcao dos grupos que realizada na quarta e ltima etapa. Os resultados mostraram
que a escalabilidade e a eficincia dessa abordagem so bastante satisfatrias.
Em SDBDC
[11]
, que uma melhora do DBDC
[12]
, tambm realizada a tarefa de agrupamento baseada em
densidade de forma distribuda. Nessa abordagem, os pontos centrais de cada n so determinados e a partir deles, os
pontos representativos globais so identificados. A partir dessa informao sobre os pontos representativos globais,
os pontos de cada n so rotulados para os grupos. Portanto essa tcnica parte de uma informao local para gerar
uma anlise global e novamente gerar uma informao local. H a possibilidade do usurio balancear a quantidade
de pontos considerados representativos em cada n, o que pode aumentar o tempo de execuo e a qualidade ou
realizar uma execuo mais rpida com menos qualidade.
Considerando os trabalhos existentes de paralelizao do DBScan, conclui-se que o agrupamento distribudo baseado
em densidade no uma tarefa trivial e h vrios fatores a serem balanceados j que invivel atender a todos.
Alguns desses fatores so a comunicao, a descentralizao de tarefas, a completude e a qualidade da soluo.
Se h muita centralizao das tarefas, perde-se em escalabilidade porm h ganhos quanto completude e
qualidade do agrupamento. Por exemplo, se o agrupamento feito de forma independente entre os ns para que
depois haja uma unio centralizada dos grupos, quanto mais informaes for considerada de cada n, maior ser a
qualidade, porm menor ser a eficincia. Por exemplo, se os pontos considerados excees no forem considerados
nessa etapa de unio dos grupos, pode-se perder informaes sobre os grupos que poderiam ser formados se esses
pontos estivessem juntos. Por outro lado, a escalabilidade da aplicao seria comprometida se esses pontos fossem
38
considerados.
A comunicao outro fator que se comporta de forma similar centralizao: quanto mais comunicao, maior ser
o overhead da aplicao, porm melhor a qualidade dos resultados. Em nenhum dos trabalhos vistos houve uso de
comunicao durante o processo de execuo do algoritmo nos ns.
Portanto, como o agrupamento baseado em densidade depende de informaes globais sobre vizinhana entre os
pontos e a implementao paralela ou distribuda deve ser capaz de encontrar um balanceamento entre agregao dos
dados globais (centralizao ou comunicao), eficincia e qualidade.
Projeto
Essa seo descreve o projeto de implementao da abordagem distribuda do DBScan. Para essa anlise, o
algoritmo ser tratado por duas etapas: a primeira o clculo da distncia entre todos os pares possveis de registros
e a segunda a etapa de percorrimento dos pontos centrais e assimilao de pontos aos grupos.
Oportunidades de paralelizao
A primeira etapa a mais custosa do algoritmo e representa uma oportunidade de paralelismo j que pode ser feita
de forma independente entre todos os pares, sendo que um cuidado a ser tomado garantir a completude e a
no-redundncia na distribuio dos pares. O paradigma Map-reduce pode ser considerado uma soluo aderente, em
que a fase map seria o clculo das distncias entre todos os pares e a etapa reduce seria a classificao dos pontos
como ponto de centro, ponto de borda ou exceo. O objetivo final dessa etapa ter a informao sobre quais pontos
so vizinhos e qual a classificao de cada ponto.
Outra soluo de paralelismo para a primeira etapa seria dividir os registros entre os ns e calcular apenas a distncia
dos pares de registros de cada n de forma independente. Tratando-se de grandes volumes de dados, essa segunda
abordagem mais adequada, j que a primeira resultaria em um grande volume de informaes sobre vizinhana, o
que tornaria invivel a consulta e a distribuio dessas informaes para todos os ns.
Em uma abordagem distribuda, a paralelizao da segunda etapa s pode ser feita dividindo-se os registros entre os
ns e executando a etapa de percorrimento dos pontos centrais e assimilao dos grupos de forma independente
dentro de cada um. A variao nesse processo ocorre na quantidade de registros distribudos por n.
Padro de acesso aos dados
Quando o agrupamento realizado com base na densidade de registros, necessrio manter e consultar a informao
sobre quais registros so vizinhos, qual a classificao de cada ponto e quais pontos j foram agrupados e para qual
grupo. Essas informaes podem ser armazenadas ou de forma centralizada com uso de memria compartilhada ou
de forma distribuda. Mais uma vez, o fato do algoritmo ser distribudo e direcionado para grandes volumes de dados
torna invivel o uso de memria compartilhada. O controle de acesso e escrita tornaria essa atividade um gargalo
para execuo. Portanto as informaes devem estar distribudas entre os ns e desejvel que haja particionamento
dos dados devido ao grande volume de dados para armazenamento.
39
Padro de comunicao
A comunicao do DBScan distribudo deve ocorrer no momento em que os grupos so formados. Para isso h duas
possibilidades: realizar a comunicao entre os ns durante a etapa de assimilao dos grupos ou realizar o
agrupamento sem comunicao entre os ns para depois realizar uma operao de juno dos grupos considerando os
grupos formados por todos os ns.
A figura 5 resume a linha do tempo considerando as possibilidades discutidas para a implementao do DBScan
distribudo.
Figura5: Possibilidades para a linha do tempo do DBScan distribudo considerando as
estratgias de paralelizao, de acesso aos dados e de comuncao discutidas.
Considerando a proposta exploratria e investigativa do trabalho e voltada para grandes volumes de dados, a soluo
escolhida consiste em dividir os dados em blocos, distribuindo entre os ns apenas os dados referentes a seus pontos
e fazendo uso de comunicao na realizao do agrupamento. A proposta de calcular a distncia de todos os pares
possveis tornaria essa etapa um gargalo, principalmente em termos de armazenamentos se aplicada a dados
massivos. J a proposta de realizar agrupamento de forma independente para depois unir os grupos foi realizada em
dois dos trabalhos mais relevantes com a mesma proposta. Portanto, dentre as opes que no tornam a primeira
etapa um gargalo para a execuo, foi escolhida a opo ainda no explorada.
40
Desenvolvimento
Essa seo descreve com mais detalhes a proposta de agrupamento distribudo para grandes volumes de dados para
que as decises do projeto permitam sua implementao independentemente das ferramentas e plataformas.
Estratgias de paralelizao
Conforme mostrado, a primeira etapa do algoritmo consiste em calcular a distncia entre os pares de pontos, o que
uma tarefa custosa, com complexidade quadrtica em termos do nmero de registros. A proposta de dividir os pontos
em blocos e calcular apenas a distncia intra bloco torna essa tarefa escalvel e eficiente.
Esse paralelismo de dados ser aplicado tambm na segunda etapa: cada n vai executar o DBScan de forma
independente considerando apenas a distncia entre os pontos recebidos e calculada na primeira etapa. Como cada n
ter informaes apenas de seus registros, a comunicao deve garantir que as informaes seja transmitidas com
algum critrio para definir a granularidade na transmisso de informaes.
Um cuidado a ser tomado que a qualidade do agrupamento final depender diretamente de como os dados foram
particionados em blocos: se os blocos apresentarem pontos muito distantes entre si, os ns formaro poucos grupos e
encontraro muitas excees, conforme mostrado na figura 6, em que cada quadrado representa um n de
processamento e os pontos vermelhos representam pontos que poderiam ter formado um grupo, mas no estavam em
quantidade suficiente em nenhum dos ns para tal. Conforme ser mostrado, uma estratgia para reduzir a
probabilidade de ocorrer essa situao replicar os pontos nos ns.
Figura 6: Exemplo de situao em que a separao dos dados impede a formao de um grupo: enquanto os
pontos do primeiro n formaram o grupo em azul e os pontos do segundo n formaram o grupo amarelo, os
pontos em vermelho no estavam em quantidade suficiente em nenhum n para formar um grupo.
Para que essa condio seja satisfeita, o particionamento dos dados feito com a funo Z-order curve que mapeia
dados multi-dimensionais para apenas uma dimenso preservando a localidade dos registros. O grande risco de que
um gargalo seja formado: caso essa etapa de pr-ordenaao dos dados para definir o paticionamento no seja
implementada de forma eficiente, a replicao dos dados ser a nica alternativa para evitar que situaes como a da
figura [exemplo] ocorram. Uma abordagem map-reduce tambm poder ser aplicada no particionamento caso essa
etapa esteja comprometendo a escalabilidade da aplicao.
41
Estratgias de armazenamento
Como em algumas aplicaes a eficincia mais importante que a preciso do agrupamento e em outras o inverso
ocorre, desejou-se algum mecanismo que permita o balanceamento entre qualidade e tempo de execuo no
armazenamento. A soluo encontrada foi a diviso do espao dimensional e a possibilidade de replicao de
registros entre os ns.
A diviso do espao dimensional deve ser realizada de maneira similar ao espao do CAN
[13]
, uma rede par a par
proposta em . Com essa diviso, a aplicao no armazena e transmite informaes de cada ponto, o que seria
ineficiente para dados massivos: as informaes trocadas so referentes s parties e a granularidade do
particionamento ser um parmetro do programa.
O outro mecanismo para permitir esse balanceamento entre tempo de execuo e qualidade e ainda garantir
tolerncia a falha a replicao de pontos em diferentes ns. Nesse caso, um parmetro de execuo define quantas
vezes cada ponto ser replicado entre os ns. Alm de aumentar a tolerncia a falhas de ns, esse parmetro ajuda a
evitar situaes em que vrios pontos vizinhos ficam espalhados e por isso no formam um grupo ao final da
execuo.
A figura 7 mostra todas as informaes que um n precisa armazenar. Nesse exemplo com duas dimenses, o n
dever armazenar informaes sobre quais dos seus pontos so vizinhos, a classificao de cada ponto (de centro, de
borda ou exceo) e quais parties j foram assimiladas a um grupo. A informao sobre os grupos formados deve
ser a mesma em todos os ns: os grupos marcados de amarelo e azul foram informados por outros ns.
Figura 7: Informaes que cada n precisa armazenar: a posio dos pontos, a qual grupo pertence cada partio, quais os pontos
vizinhos e qual a classificao de cada ponto.
Estratgia de comunicao
A comunicao deve ser realizada para informar e sincronizar informaes sobre quais parties foram assimiladas a
qual grupo. Nesse caso, no necessrio direcionar as mensagens, elas devem ser enviadas para todos. Tambm no
necessrio sincronizao ou uso de barreiras: se dois ns enviam mensagem ao mesmo tempo informando que a
mesma partio pertence a um de seus grupos, cada n deve saber interpretar a informao baseando-se no tipo de
ponto que levou assimilao da partio ao grupo. Portanto, a cada vez que um ponto assimilado a um grupo, o
n deve enviar uma mensagem avisando qual o tipo desse ponto e qual partio foi assimilada a qual grupo.
42
Se dois ou mais ns enviarem mensagem informando que uma partio contendo pelo menos um ponto de centro
pertence a um determinado grupo, a interpretao de todos os ns devem ser de que esses grupos devem ser unidos.
A figura 8 representa essa situao: a partio (2,3) foi assimilada para dois grupos diferentes no primeiro e no
terceiro n. Aps o recebimento da mensagem informando que aquela partio contendo um ponto de centro foi
assimilada para os grupos A e B, todos os ns fazem a juno desses grupos.
Figura 8: Procedimento de comunicao quando dois pontos de centro (ou um ponto de centro e um de borda)
tm sua partio assimilada para um grupo ao mesmo tempo. Os ns informam os demais sobre a assimilao
e ao receber as duas mensagens, os ns juntam os grupos.
Se essa situao ocorrer apenas com parties de borda, os ns devem manter a informao processada por ltimo.
Nesse caso haver ns armazenando diferentes grupos para a mesma partio e apenas ao final, quando haver a
produo do resultado final, ser definido a qual grupo a partio de borda pertence. Essa situao em que a
definio de um ponto de borda no determinstica tambm ocorre no DBScan tradicional, j que a ordem de
execuo dos pontos centrais pode fazer com que os pontos de borda sejam assimilados a grupos distintos. Essa
situao est ilustrada na figura 9.
43
Figura 9: Procedimento de comunicao quando duas parties que no contm ponto de centro so
assimiladas a grupos distintos ao mesmo tempo. Ao final de todo o procedimento ser escolhida uma das
configuraes.
Implementao
Essa seo descreve a implementaao em andamento da aplicao.
Plataformas e ferramentas
A implementao da aplicao faz uso do framework Apache Hadoop
[14]
, implementado na linguagem Java e
usando-se o mdulo Hadoop Distributes File System para armazenamento. A comunicao utiliza RMI Remote
Method Invocation, uma interface de programao que permite a execuo de chamadas remotas, na qual um objeto
ativo em uma mquina virtual Java pode interagir com objetos ativos de outros ns. Mais detalhes da implementao
sero apresentadas quando a mesma for concluda.
Detalhes de implementao
Seguem os detalhes e algumas definies realizadas durante a fase de implementao.
A identificao dos grupos deve unvoca. A soluo com nmeros sequenciais para todos os ns pode representar
um problema se dois ns criarem grupos ao mesmo tempo, portanto cada n deve ter sua prpria sequncia de
identificadores de grupos. Alm disso, cada n tem um identificador nico e a identificao dos grupos feita a
partir da concatenao do identificador nico do n com o nmero de sequncia atual do n. Por exemplo, o
segundo grupo do n nomeado ID4 identificado por ID4.2.
Quando dois grupos so unidos, o novo grupo formado nomeado com a concatenao dos grupos que deram
origem a ele. Por exemplo se o grupo ID4.2 e ID9.7 forem unidos, o grupo resultante ser identificado por
ID4.2.ID9.7.
44
Avaliao
Aps a concluso da implementao do cdigo, a avaliao da aplicao ser realizada utilizando uma base de dados
contendo informaes sobre filmes disponibilizada pelo Netflix em uma competio de sistemas de recomendao. A
base contm aproximadamente 100 milhes de registros com avaliaes de filmes.
Concluso
O projeto descrito visa a implementao do algoritmo de agrupamento DBScan distribudo e com o propsito de
tratar grandes volumes de dados.
Conforme mostrado na reviso bibliogrfica, a maioria dos trabalhos existentes com a mesma proposta realizam o
agrupamento de forma independentes entre os ns para depois realizarem a unio e o tratamento da fronteira entre os
grupos criados pelos mltiplos ns. A proposta desse trabalho realizar o agrupamento dividindo-se os registros
entre os ns, e agrup-los utilizando comunicao para informar quais parties foram assimiladas a quais ns.
Conforme mostrado na seo "Desenvolvimento", h duas possibilidades para o controle de eficincia e qualidade: a
granularidade da diviso do espao e a quantidade de vezes que cada registro replicado. A principal ferramenta de
implementao o framework Apache Hadoop e ao final dessa etapa, a avaliao ser realizada com uma grande
base de dados de filmes.
Espera-se que ao final do processo o resultado seja uma aplicao escalvel e eficiente para agrupar com qualidade
grandes volumes de dados, alm de publicaes acadmicas na rea de big data.
Referncias
[1] K-Means (http:/ / projecteuclid. org/ DPubS?service=UI& version=1. 0& verb=Display& handle=euclid. bsmsp/ 1200512992),
[2] Expectationmaximization (http:/ / www.jstor.org/ discover/ 10. 2307/ 2984875?uid=3737664& uid=2129& uid=2& uid=70& uid=4&
sid=21101653427993),
[3] DBScan (http:/ / dns2. icar.cnr. it/ manco/ Teaching/ 2005/ datamining/ articoli/ KDD-96. final. frame. pdf),
[4] Data Mining and Analysis:Foundations and Algorithms (http:/ / www. dcc. ufmg. br/ miningalgorithms/ files/ pdf/ fdma. pdf)
[5] R*-tree (http:/ / dbs. mathematik. uni-marburg. de/ publications/ myPapers/ 1990/ BKSS90. pdf),
[6] Experiments in parallel clustering with dbscan (http:/ / www. di. unipi. it/ ~coppola/ didattica/ ccp0506/ papers/ LNCS2150_21500326. pdf), .
[7] P-DBScan (http:/ / bib. dbvis. de/ uploadedFiles/ 17.pdf)
[8] The priority r-tree: A practically eficient and worst-case optimal r-tree (http:/ / www. daimi. au. dk/ ~large/ Papers/ prtreesigmod04. pdf), .
[9] MR-DBScan (http:/ / ieeexplore. ieee. org/ xpl/ login.jsp?tp=& arnumber=6121313& url=http:/ / ieeexplore. ieee. org/ xpls/ abs_all.
jsp?arnumber=6121313),
[10] Map-reduce (http:/ / static. usenix. org/ event/ osdi04/ tech/ full_papers/ dean/ dean. pdf)
[11] Scalable Density Based Distributed Clustering (http:/ / pdf. aminer. org/ 000/ 541/ 673/ scalable_density_based_distributed_clustering. pdf),
.
[12] Density Based Distributed Clustering (http:/ / www. dbs. ifi. lmu. de/ Publikationen/ Papers/ EDBT_04_DBDC. pdf),
[13] Content Addressable Network (http:/ / www. eecs. harvard. edu/ ~mema/ courses/ cs264/ papers/ p13-ratnasamy. pdf)
[14] Apache Hadoop (http:/ / hadoop. apache.org/ ).
R-tree
45
R-tree
Em um mundo cada vez mais digitalizado natural que as referncias espaciais, que fazem parte do nosso dia-a-dia,
ocupando um grande espao em nossas vidas, ocupem muito espao na web. H uma inifinidade de aplicaes que
requerem dados espaciais, tais como mapas, servios de recomendao de lugares, redes sociais, etc. O mundo
no-digital consiste em uma quantidade muito grande de informaes e essas aplicaes s fazem sentido se forem
capazes de manipular grande parte dos dados desse mundo. preciso ento pensar em estruturas de processamento
capazes de lidar com um grande volume de dados, transformando-os em uma estrutura que permita uma manipulao
eficiente. O exemplo mais simples e direto desse tipo de problema e aplicao consiste em pontos, com coordenadas
geogrficas (lat/long, por exemplo), representando entidades (localizao de restaurantes, hotis, cidades, pessoas,
pessoas em lugares, etc.). Embora o cenrio parea corriqueiro h uma dificuldade nesse tipo de situao ao se lidar
com a quantidade de informao codificada dessa forma. Uma vez que se tem uma base com milhes dessas
entidades, uma busca espacial linear simples torna-se proibitiva, ainda mais se as consultas forem frequentes (como
geralmente o so: quantos restaurantes h perto de mim?, quantas pessoas visitaram cidades em um raio de 50
quilmetros do ponto X?). preciso construir uma estrutura de dados capaz de atender a essas consultas de forma
eficiente. Uma estrutura apta a lidar com consultas a dados espaciais com eficincia a R-tree
[1]
. Como o prprio
nome indica trata-se de uma rvore de busca, que evita que a busca seja feita em todos os dados.
R-tree
[2]
A ideia principal por trs da R-tree organizar os objetos prximos em retngulos envolventes mnimos (MBR -
minimum bounding retangle). Nas folhas da rvore o MBR envolve um grupo de objetos, nos nveis superiores o
MBR envolve os MBRs que formam os seus filhos. A pesquisa envolve checar se o objeto da pesquisa tem
interseco com os retngulo envolventes, se no h interseco com determinado MBR, no preciso checar nos
ns filhos. Quanto h interseco com um n folha preciso checar todos os objetos que o compe. A R-tree uma
rvore balanceada. De forma semelhante ao que acontece em uma B-tree, esse balanceamento conseguido ao
limitar o nmero de filhos que cada n possui a M. Quando a insero dos objetos faz com que um n exceda esse
nmero de filhos, acontece um rebalanceamento que consiste, basicamente, em dividir o n que excedeu o nmero
de filhos. Do ponto de vista da busca de um determinado objeto a R-tree bastante eficiente, pois no necessrio
pesquisar por todos os objetos. Isso significa que ela pode ser utilizada mesmo para situaes nas quais a R-tree no
pode ser completamente carregada em memria principal. Nesse tipo de cenrio os ns podem ser mapeados para
pginas de disco, permitindo acessos eficientes mesmo em uma memria mais lenta. A maior dificuldade na R-tree
sua construo, que precisa garantir que a rvore estar balanceada e ao mesmo tempo que os retngulos mnimos
cobriro a menor rea possvel, no total. Isso porque quanto maior essa rea, maior o nmero de retngulos que tero
interseco com o objeto pesquisado, no importando o tamanho do objeto. Isso levar a um nmero maior de
comparaes desnecessrias. R-trees podem armazenar vrios tipos de dados espaciais, desde pontos
multidimensionais a polgonos. O presente trabalho abordar o caso em que se deseja trabalhar com pontos com
coordenadas geogrficas em duas dimenses. No entanto, fcil perceber que as tcnicas apresentadas no seriam
muito diferentes se aplicadas a outro tipo de objetos.
Busca
Cada n formado por um identificador e um conjunto de MBRs representando os filhos. A busca inicia-se no
n-raiz. Para cada n pesquisado verifica-se a interseco da MBR dos filhos com o objeto da busca, se ocorre a
interseco o n interseccionado adicionado ao conjunto dos ns que precisam ser pesquisados. Quando um
n-folha atingido todos os objetos que o constituem, e que em muitos casos, como no caso de pontos
bidimensionais, compe a pgina do prprio n-folha, so checados contra o objeto da pesquisa.
R-tree
46
Insero
Para inserir tambm parte-se do n-raiz. Para cada n, se o objeto a ser inserido est contido em um dos filhos, basta
tentar inseri-lo nesse n. Caso no esteja completamente contido em um dos filhos preciso utilizar uma heurstica
para definir em qual n inseri-lo. A heurstica utilizada pela R-tree original, como proposta por Guttman, consiste em
escolher o n cujo MBR ser menos expandido para acomodar o novo dado. A R*-tree
[3]
tambm considera que no
caso de empate nesse critrio ser escolhida a subrvore representada pelo MBR de menor rea. Ao chegar ao
n-folha o objeto inserido no prprio n. Como h um limite de ocupao para cada n pode acontecer de isso
levar a um nmero de objetos que excede o mximo permitido. Nesse caso preciso dividir o n que excede o
nmero de elementos permitidos. Ento ser preciso definir como dividir os objetos contidos no n excedido (S)
entre os novos ns (A e B). Como o nmero de possibilidades exponencial ser preciso utilizar uma heurstica. A
heurstica utilizada geralmente consiste em escolher inicialmente dois objetos ou ns (dentro do n cujo tamanho foi
excedido) que tenham a maior distncia entre si. Esses dois elementos sero colocados em em A e B. Ento para
cada objeto, ou n, desse grupo excedido calcula-se o acrscimo no MBR se adicionado a A ou B e o atribui ao n
cuja insero desse elemento representa o menor acrscimo de rea para o MBR. Como so criados dois novos ns, e
esses dois novos ns tero o mesmo pai do antigo n, pode acontecer de ser excedido o nmero de filhos do pai
desses ns. Nesse caso sero aplicados os mesmos algoritmos a esse pai, e assim por diante at chegar raiz se for
necessrio, o que pode levar criao de uma nova raiz, aumentando o tamanho da rvore.
Abordagem paralela
O processo de busca de uma R-tree estvel pode ser completamente paralelizado, pois trata-se apenas de leituras dos
dados. Isso aliado ao fato de que uma busca consiste em uma srie de operaes simples e que a R-tree uma rvore
balanceada significa que no h um gargalo de processamento das buscas devido ao desenho da R-tree. No entanto, o
processo de criao de uma R-tree custoso, pois embora muitas inseres necessitem apenas uma busca seguida de
uma insero em um n folha, as etapas de checagem da melhor subrvore, no caso em que h mais de um n-filho
para inserir determinado objeto, e principalmente a diviso de um n que excedeu o nmero mximo de filhos, so
operaes caras e que envolvem alteraes significativas na estrutura da rvore, que impossibilitariam uma
paralelizao ingnua. Essa dificuldade de paralelizao esbarra em uma exigncia de se trabalhar com esse tipo de
estrutura em um ambiente de big-data. E como vivemos em um mundo que possui, e precisa trabalhar, com um
nmero cada vez maior de dados, preciso desenvolver uma abordagem capaz de lidar com uma R-tree nesse tipo de
contexto.
Abordagem MapReduce para construo da R-tree
Ariel Carry et al.
[4]
apresentam uma abordagem para construo da R-tree em um ambiente de big-data utilizando o
modelo de programao conhecido como MapReduce
[5]
. O modelo MapReduce procura abstrair as dificuldades de
se trabalhar com uma estrutura de clusters, com dados distribudos e processamento paralelo. Para conseguir essa
abstrao o modelo trabalha apenas com duas funes bsicas de controle de fluxo. A funo map, que responsvel
por definir um processamento individual para cada partio dos dados, e uma funo reduce, que capaz de
organizar os dados vindos da funo map executada anteriormente, aglutinando os dados processados. Por essa
descrio superficial do modelo j possvel perceber que a implementao da R-tree nesse ambiente no pode ser
feita diretamente. Para resolver essa situao ser preciso utilizar trs passos. So esses passos:
1. 1. Computao da funo de particionamento;
2. 2. Construo das R-trees;
3. 3. Consolidao das R-trees em uma R-tree final.
A ideia por trs das trs fases permitir a construo de R-trees, separadamente, sobre diferentes parties dos
pontos e consolidar essas R-trees em uma nica R-tree. As duas primeiras fases so paralelas, sendo a segunda a fase
de maior computao. A terceira e ltima fase deve ser feita de forma sequencial, mas sua computao bem menor.
R-tree
47
As trs fases sero agora vistas em detalhes.
Computao da funo de particionamento
Precisamos definir parties sobre as quais sero criadas as R-trees separadamente. Essas parties precisam ter o
mesmo tamanho, ou um tamanho muito prximo. Devem tambm possuir uma proximidade entre os pontos que as
compe, ao mesmo tempo em que esses pontos devem estar o mais distante possvel dos pontos nas outras parties.
Essa exigncia acontece porque se tivermos duas R-trees de parties diferentes tratando de pontos prximos, os
MBRs dos ns que contm esses pontos em uma partio tero muita sobreposio com os ns de outra partio, e
como j vimos anteriormente isso torna a R-tree ineficiente. A forma utilizada para definir essas parties faz uso de
uma estrutura conhecida como curva de preenchimento de espao (space filling curve). Essas curvas consistem em
caminhamentos que induzem uma ordem em espaos multidimensionais com dois objetivos bsicos:
Todo ponto do espao faz parte da curva, logo todo ponto do espao tem uma ordem definida por essa curva;
Dois pontos prximos no espao multidimensional tambm so prximos segundo a ordem definida pela curva e
dois pontos distantes segundo a curva tambm so distantes no espao multidimensional (essa relao varia
dependendo dos pontos analisados, mas mantm-se suficientemente coerente para a maioria dos pontos).
Essas propriedades dessas curvas permitem que sejam utilizadas para definir mais facilmente as distncias entre os
pontos que compem a base. No caso especfico desse trabalho utilizada a curva Z (z-curve
[6]
), mas outras curvas
poderiam ter sido escolhidas. Uma das vantadens da curva Z sua facilidade para gerar a ordem segundo seu
caminhamento. Basta concatenar as coordenadas do ponto que se deseja avaliar e ordenar os dgitos segundo a sua
ordem nas coordenadas originais, de forma que os dgitos de mais alta ordem fiquem juntos. Por exemplo, se um
ponto tem duas coordenadas 011 e 101, as coordenadas desse ponto na curva de ordem Z sero 011011. Uma vez
que temos uma forma de definir uma ordem para todos os pontos da base, bastaria ordenar esses pontos e trabalhar
sobre as parties segundo essa ordem. No entanto como trata-se de uma base muito grande esse processamento
seria custoso demais. A soluo ento definir apenas os pontos que esto nos limites dessas parties, definindo-a a
partir desses pontos. A forma escolhida para definir esses pontos tomar pontos aleatrios na base como amostra, e a
partir desses pontos definir as parties. Sero tomadas L amostras da base de forma paralela. Cada mapper tomar
L/M pontos aleatoriamente de sua base e calcular seu valor unidimesional segundo a curva Z. Esses valores sero
emitidos para o reducer. O reducer ordenar os L valores recebidos. Caso o nmero de valores ainda seja muito
grande para ordenamento em memria principal poder-se-ia utilizar mais uma fase, com uma algoritmo de ordenao
map-reduce como o TeraSort
[7]
. Uma vez ordenados, so tomados pontos dessa lista, em que o nmero
de parties desejados, comeando no ponto , depois , , etc. Esses pontos so utilizados para definir
uma funo de partio em que os limites das parties so definidos por esses pontos. Essa funo pode ser
formalmente definida como sendo:
Dessa forma essa fase produzir uma lista de valores unidimensionais que sero utilizados para particionar todos os
dados. Em termos de entradas e sadas temos:
R-tree
48
Funo Input: (Key, Value) Output: (Key, Value)
Map (o.id, o.P) (C, U(o.P))
Reduce (C, list(ui, i=1, ..., L)) S'
em que o um ponto, que possui um identificador o.id e suas coordenadas o.P, C uma constante qualquer e S a
lista de valores unidimensionais.
Construo das R-trees
Uma vez que temos como particionar os dados, podemos construir R-trees diferentes para cada partio. Isso
significa que a construo das R-trees pode ser feita paralelamente. Primeiramente, preciso particionar os dados
propriamente ditos, uma vez que eles esto distribudos no cluster e s o que temos como particion-los, atravs da
funo de particionamento obtida na fase anterior. Para fazer esse particionamento cada mapper ter a funo de
particionamento e a utilizar para dividir os seus dados, emitindo para cada reducer, segundo a partio do dado, ou
seja a chave emitida ser a partio e o valor ser o ponto. Cada reducer receber os pontos de sua partio e
construir a R-tree normalmente, como se fosse uma R-tree sequencial normal, como abordado anteriomente. Dessa
forma a sada dessa fase tantas R-trees quantas forem as parties definidas inicialmente. O paralelismo dessa etapa
est restringido pelo nmero de parties definidas a priori. Quanto maior o nmero de parties maior o nmero de
reducers construindo r-trees paralelamente. No entanto um nmero muito grande de parties em relao ao nmero
de pontos pode levar a uma degenerao das parties e uma consequente degenerao das r-trees criadas, que
tendero a ter maior sobreposio entre si.
Funo Input: (Key, Value) Output: (Key, Value)
Map (o.id, o.P) (f(o.P), o)
Reduce (f(o.P), list(oi, i=1, ..., A)) tree.root
Consolidao das R-trees
A ltima fase no executada em uma ambiente map-reduce. Trata-se de um processamento sequencial, que
processa as R-trees formadas na etapa anterior para produzir uma s R-tree. Como as parties tendem a ter o mesmo
nmero de pontos, cada R-tree deve possuir o mesmo nmero de pontos, e provavelmente a mesma altura, embora
possa haver uma pequena variao. Isso significa que para forma a nova R-tree basta tomar o MBR de cada raiz e
inserir em um rvore inicialmente vazia. Essa abordagem significa que o custo dessa ltima fase o custo de
insero de P objetos (P o nmero de parties) em uma R-tree, o que um custo muito menor do que a criao de
uma R-tree com os pontos originais.
Toda a soluo apresentada pode ser resumida no seguinte esquema:
Modelo esquemtico da soluo proposta
R-tree
49
Abordagem de filtros (streams) para construo da R-tree
Se analisarmos a figura apresentada ao final da seo anterior, embora essa represente a soluo apresentada, difcil
ver naturalmente trs fases nesse esquema. Isso significa que esse abordagem artificial ao problema. E de fato
trata-se de uma abordagem que se deve muito mais ao modelo map-reduce do que ao problema em si. Mas podemos
pensar em um modelo que represente melhor esse esquema, de fato, podemos mapear muitas dessas entidades desse
esquema a filtros de processamento, conforme a seguinte figura, em que os filtros esto pintados:
Esquema da soluo mostrando filtros
Os filtros fazem parte do modelo, naturalmente, servindo uns de entradas aos outros e resultando na R-tree dos
pontos de entrada. Embora do ponto de vista da modelagem esse esquema faa mais sentido, o resultado final e o
esforo computacional sero o mesmo da abordagem map-reduce apresentada anteriormente. No entanto, a
abordagem utilizando streams mais flexvel, pois os filtros no processam sequencialmente, mas podem ser
pensados como um processamento contnuo. Essa mudana de paradigma significa duas vantagens. Primeiramente,
seria mais fcil pensar essa soluo para uma situao em que esses pontos so processados de forma contnua, como
em uma aplicao que seja alimentada com novos dados constantemente. A segunda vantagem que esses filtros
poderiam ser retroalimentados, aumentando o auto-conhecimento do processamento e assim possibilitando uma
maior eficincia. Podemos adicionar os seguintes canais de comunicao entre os filtros, apresentados com linhas
tracejadas:
Modelo de filtros com comunicao entre si
Essa comunicao permitiria, por exemplo, adicionar um comportamento que verificasse o tamanho das parties
medida em que os dados so lidos pelo filtro particiona pontos, e no caso em que a partio estiver muito
desbalanceada o procedimento de definio da funo de partio, que envolve trs filtros, pode ser realizado
novamente. Outro comportamento que poderia surgir com esse modelo seria o de analisar o comportamento dos
filtros que calculam as r-trees de cada partio em comparao com o resto do processo que poderia definir se o
nmero de parties escolhido um bom compromisso em termos da quantidade de paralelismo.
R-tree
50
Referncias
[1] [1] Antonin Guttman. R-trees: a dynamic index structure for spatial searching. SIGMOD Rec., 14(2):4757, June 1984
[2] http:/ / en. wikipedia. org/ wiki/ R-tree
[3] http:/ / en. wikipedia. org/ wiki/ R*-tree
[4] [4] Ariel Cary, Zhengguo Sun, Vagelis Hristidis, and Naphtali Rishe. Experiences on processing spatial data with mapreduce. In Proceedings of
the 21st International Conference on Scientic and Statistical Database Management, SSDBM 2009, pages 302319, Berlin, Heidelberg, 2009.
SpringerVerlag
[5] http:/ / en. wikipedia. org/ wiki/ MapReduce
[6] http:/ / en. wikipedia. org/ wiki/ Z-order_curve
[7] [7] Owen O'Malley. Terabyte sort on apache hadoop, 2008.
Identificao de ciclos em grafos
Introduo
Deteco de Ciclos por Busca em Profundidade
Um mtodo eficiente para detectar ciclos em grafos direcionados por meio do algoritmo de busca em profundidade.
Intuitivamente, o algoritmo comea num n raiz (selecionando algum n como sendo o raiz, no caso de um grafo) e
explora tanto quanto possvel cada um dos seus ramos, antes de retroceder
[1][2]
.
Formalmente, um algoritmo de busca em profundidade realiza uma busca no-informada que progride atravs da
expanso do primeiro n filho da rvore de busca, e se aprofunda cada vez mais, at que o alvo da busca seja
encontrado ou at que ele se depare com um n que no possui filhos (n folha). Ento a busca retrocede e comea
no prximo n. Numa implementao no-recursiva, todos os ns expandidos recentemente so adicionados a uma
pilha, para realizar a explorao.
Pseudo-Cdigo
Entrada: Um grafo G e um vrtice v de G
1 procedimento DFS(G,v):
2 marcar v como explorada
3 para cada aresta e em G.arestasAdjacentes(v) fazer
4 se aresta e estiver no-explorada ento
5 w G.vrticeAdjacente(v,e)
6 se vrtice w estiver no-explorado ento
7 marcar e como uma aresta de avano
8 chamar recursivamente DFS(G,w)
9 seno
10 marcar e como aresta de retorno
11 todo o caminho de w at v representa um ciclo
A seguir apresentado um exemplo da execuo do algoritmo de busca em profundidade. A aresta (4,2), na cor
verde, representa uma aresta de retorno, e o caminho (2,3,4) representa um ciclo do grafo.
51
Deteco de Ciclos por Busca em Profundidade
Anlise do Algoritmo
A ordem de complexidade em relao ao custo de tempo de execuo do algoritmo de deteco de ciclos por busca
em profundidade (|V| + |E|), onde |V| o nmero de vrtices do grafo e |E| o nmero de arestas. O custo de
armazenamento (espao em memria) do algoritmo (|V|).
Deteco de Ciclos no Contexto de Dados Massivos
No contexto de dados massivos, a estrutura do grafo pode ser grande o suficiente para saturar facilmente o poder de
processamento ou a capacidade de memria de uma nica mquina, surgindo a necessidade de paralelizar o
algoritmo de deteco de ciclos. Entretanto, principalmente devido sua caracterstica recursiva, uma desvantagem
do algoritmo de busca em profundidade o fato de ser dificilmente paralelizvel, embora o algoritmo seja
assintoticamente timo.
Portanto, necessrio um algoritmo que divida o problema de deteco de ciclos em subproblemas entre ns de
computao, de modo que os ns busquem por cclos de maneira paralela, garantindo que todos os ciclos sero
encontrados. Prope-se ento, um algoritmo para deteco de ciclos de grafo por passagem de mensagens
[3]
entre os
vrtices, baseado no modelo Pregel
[4]
de processamento de grafos da Google. Esse modelo apresenta uma
abordagem centrada nos vrtices em que os vrtices do grafo trabalham juntos para detectar ciclos.
Algoritmo de Deteco de Ciclos por Passagem de Mensagens
O modelo do Pregel consiste basicamente em uma sequncia de iteraes, em cada uma das quais um vrtice recebe
mensagens enviadas por outros vrtices na iterao anterior e enviar mensagens para outros vrtices.
O mtodo inicia com cada vrtice enviando para seus vizinhos uma mensagem com uma lista contendo apenas o
prprio vrtice. Os passos seguintes consistem de pequenas computaes realizadas sobre as listas recebidas por
mensagens de outros vrtices. Se o vrtice no recebeu mensagem alguma, ento o vrtice se desativa. O algoritmo
termina quando todos os vrtices esto inativos.
Para cada lista recebida, se o vrtice receber uma lista contendo a si prprio em qualquer posio exceto a primeira, o
vrtice rejeita a mensagem. Se a lista recebida comear com o prprio vrtice, ento um ciclo foi detectado. Para as
demais listas recebidas, o vrtice se adiciona ao final da lista e a encaminha para todos os seus vizinhos.
Por definio, temos que e vrta lista dices, que pode ser vista como uma sequncia ordenada de vrtices, representa
um caminho no grafo
[5]
. Portanto, quando um vrtice recebe uma lista em que o primeiro elemento da lista o
prprio vrtice, temos que o caminho representado por aquela lista teve incio no prprio vrtice, isto , a lista
representa um ciclo no grafo.
A seguir apresentado um exemplo da execuo do algoritmo de deteco de ciclos por passagem de mensagens.
Pode-se observar que no passo (d), o vrtice 2 recebe uma mensagem em que a lista de vrtices iniciada pelo
prprio vrtice 2, detectando assim um ciclo no grafo (2,3,4). No passo (e), o vrtice 2 rejeita uma mensagem
contendo a si prprio na segunda posio da lista. Pode-se notar que a lista rejeitada contm o ciclo detectado
52
anteriormente, e por esse motivo que o vrtice 2 aparece no meio da lista rejeitada, pois o ciclo um sub-caminho
do caminho representado pela lista rejeitada no passo (e). Por fim, no passo (f) todos os vrtices so desativados e
no existem mais mensagens sendo enviadas pelo grafo, terminando a execuo do algoritmo.
Deteco de Ciclos por Passagem de Mensagens
No passo (d) do exemplo, todos os trs vrtices detectam o ciclo (2,3,4). Para assegurar que apenas um dos vrtices
reportem a deteco, pode-se detectar o ciclo apenas do vrtice cujo identificador seja o menor (por algum critrio de
ordenao) dentre os demais vrtices do ciclo, onde no exemplo seria o vrtice 2.
Anlise do Algoritmo
O nmero total de iteraes do algoritmo paralelo ser igual ao tamanho do maior caminho de vrtices distintos do
grafo mais algumas poucas iteraes iniciais ou finais. Portanto o nmero de iteraes do algoritmo paralelo ser
(|V|), sendo que o maior caminho distinto possvel de um grafo seria contendo todos os vrtices do grafo.
Pseudo-Cdigo no Modelo Pregel de Programao Paralela
Como mencionado anteriormente, o algoritmo proposto baseado no modelo Pregel da Google. Nesse modelo de
programao paralela, os programas de usurio so expressos como sequncias de iteraes, chamadas de
supersteps, nas quais cada vrtice recebe mensagens enviadas por outros vrtices na iterao anterior, envia
mensagens para outros vrtices, e modifica seu prprio estado e o estado das arestas de sada. O modelo Pregel
projetado para implementaes em clusters de computadores que sejam eficientes, escalveis e tolerante a falhas, de
maneira que detalhes referentes distribuio so escondidos pela abstrao da API.
O usurio desse modelo implementa um mtodo chamado COMPUTE, que ser executado por todos os vrtices
ativos em cada superstep. O vrtice se desativa votando para parar (halt) e o algoritmo como um todo termina
quando todos os vrtices esto simultaneamente desativados e no existem mais mensagens sendo enviadas.
Aps carregar a estrutura do grafo, cada n computacional do cluster de computadores fica responsvel por um
conjunto de vrtices do grafo, e responsvel tambm por executar o mtodo COMPUTE a cada supersteps para os
vrtices sob sua responsabilidade.
O pseudo-cdigo abaixo apresenta o algoritmo seguindo o modelo Pregel.
Entrada: Mensagens msgs recebidas no superstep anterior.
1 procedimento COMPUTE(msgs):
2 se superstep = 0 ento
3 enviar o ID do vrtice para todos os vizinhos
4 seno
5 se no recebeu nenhuma mensagem ento
6 votar para parar
7 seno
8 para cada mensagem msg de msgs fazer
9 se msg iniciar com o ID do vrtice atual e ID for o menor da msg ento
10 msg contm novo ciclo encontrado
53
11 seno
12 se msg no contm o ID do vrtice atual ento
13 inserir ID no final da lista em msg
14 encaminhar msg para todos os vizinhos
Implementao Paralela no Sistema GraphChi
Considerando que a implementao principal do modelo Pregel da Google possui cdigo fechado, pode ser
interessante avaliar uma alternativa ao modelo Pregel. Uma das alternativas o sistema GraphChi
[6]
da GraphLab.
Esse sistema fornece uma engine para processamento de grafos, no contexto de dados massivos, em uma nica
mquina. O sistema apresenta um processamento baseado em disco (memria secundria) para computao eficiente
de grafos de grande escala.
Diferentemente do modelo Pregel, GraphChi uma engine baseada em memria compartilhada. Em GraphChi, cada
vrtice e cada aresta armazena um dado. A comunicao entre os vrtices durante o processamento paralelo
realizada com base nos dados armazenados pelos vrtices e arestas.
De maneira semelhante ao modelo Pregel, GraphChi tambm apresenta uma abordagem centrada nos vrtices. A
engine do GraphChi consiste basicamente em uma sequncia de iteraes, nas quais, para cada vrtice executado
uma funo de atualizao (update). Antes de cada iterao a engine executa uma funo chamada before_iteration e
aps cada iterao executada a funo after_iteration.
A seguir apresentado uma implementao do algoritmo de deteco de ciclos em grafos por passagem de
mensagens usando o sistema do GraphChi. Esta implementao fornece uma abstrao semelhante ao modelo Pregel
sobre a engine do GraphChi, incluindo a abstrao de passagem de mensagens, o que conveniente para o algoritmo
de deteco de ciclos proposto.
Toda aplicao do sistema GraphChi deve implementar a classe abstrata GraphChiProgram. A classe
GraphChiProgram fornece os mtodos pblicos apresentados pelo cdigo da classe CycleDetection a seguir.
#include "graphchi_basic_includes.hpp"
using namespace graphchi;
typedef vid_t VertexDataType;
typedef list<list<vid_t>*>* EdgeDataType;
graphchi_engine<VertexDataType, EdgeDataType> *enginePtr;
int countIteration;
size_t finishedVertices;
#define activateVertex() finishedVertices--
#define initIteration() finishedVertices = gcontext.nvertices
#define closeIteration() if(finishedVertices==gcontext.nvertices)
enginePtr->set_outside_closing(true)
class CycleDetection : public GraphChiProgram<VertexDataType, EdgeDataType> {
public:
void update(graphchi_vertex<VertexDataType, EdgeDataType> &vertex, graphchi_context &gcontext);
void before_iteration(int iteration, graphchi_context &gcontext);
void after_iteration(int iteration, graphchi_context &gcontext);
void before_exec_interval(vid_t window_st, vid_t window_en,
graphchi_context &gcontext);
54
void after_exec_interval(vid_t window_st, vid_t window_en,
graphchi_context &gcontext);
private:
void sendInitialMessageToNeighbours(graphchi_vertex<VertexDataType, EdgeDataType> &vertex);
void sendMessageToNeighbour(graphchi_vertex<VertexDataType, EdgeDataType> &vertex, int
neighbourId, list<vid_t> *value);
void deleteMessages(list<list<vid_t>*> *msgs);
bool hasInMessages(graphchi_vertex<VertexDataType, EdgeDataType> &vertex);
vid_t getMinVertexId(graphchi_vertex<VertexDataType, EdgeDataType> &vertex, list<vid_t> *value);
bool vertexListContains(graphchi_vertex<VertexDataType, EdgeDataType> &vertex, list<vid_t> *value);
list<vid_t> *copyVertexList(list<vid_t> *vList);
void outputCycle(list<vid_t> *value);
};
O cdigo a seguir apresenta a implementao do mtodo update que equivalente funo COMPUTE do modelo
Pregel. O mtodo update a implementao principal do algoritmo de deteco de ciclos por passagem de
mensagens apresentado anteriormente pelo pseudo-cdigo da funo COMPUTE.
Basicamente, a implementao consiste em percorrer todas as arestas de entrada, recolhendo todas as "mensagens"
recebidas, para poder realizar o processamento nas listas de vrtices recebidas. Para cada lista de vrtice recebida,
realizado o processamento sobre a lista e, caso necessrio, a lista com o novo vrtice encaminhada para as arestas
de sada.
void CycleDetection::update(graphchi_vertex<VertexDataType, EdgeDataType> &vertex, graphchi_context
&gcontext) {
if (countIteration == 0) {
sendInitialMessageToNeighbours(vertex);
} else {
if(hasInMessages(vertex)){
activateVertex();
}
for(int i=0; i < vertex.num_inedges(); i++) {
list<list<vid_t>*> *inMsgs = vertex.inedge(i)->get_data();
if(inMsgs && inMsgs->size()>0){
for(int j=0; j < vertex.num_outedges(); j++) {
list<list<vid_t>*>::iterator msgList;

for(msgList = inMsgs->begin(); msgList!=inMsgs->end();
msgList++){
list<vid_t> *value = copyVertexList((*msgList));
if(value->front()==vertex.vertexid){
vid_t minId = getMinVertexId(vertex, value);
if(minId==vertex.vertexid){
outputCycle(value);
}
55
delete value;
}else if(!vertexListContains(vertex, value)){
sendMessageToNeighbour(vertex, j, value);
}else delete value;
}
}
deleteMessages(inMsgs);
}
}
}
}
Os mtodos implementados no cdigo a seguir fornecem a implementao necessrio no modelo GraphChi para
oferecer uma abstrao do trmino de execuo da aplicao com base nos vrtices estarem ativos ou no,
semelhante ao modelo Pregel.
void CycleDetection::before_iteration(int iteration, graphchi_context
&gcontext) {
initIteration();
}

void CycleDetection::after_iteration(int iteration, graphchi_context
&gcontext) {
if(countIteration>0)
closeIteration();
countIteration++;
}
void CycleDetection::before_exec_interval(vid_t window_st, vid_t
window_en, graphchi_context &gcontext) {}
void CycleDetection::after_exec_interval(vid_t window_st, vid_t
window_en, graphchi_context &gcontext) {}
Os mtodos a seguir apresentam algumas funes teis para o algoritmo principal e algumas delas auxiliam na
abstrao de passagem de mensagens. Observe que o mtodo outputCycle apenas uma ilustrao. Esse mtodo
deve receber uma lista contendo os IDs dos vrtices que representam um ciclo, e executar alguma computao sobre
o ciclo recebido, que melhor convir para a aplicao em questo.
void CycleDetection::sendInitialMessageToNeighbours(graphchi_vertex<VertexDataType, EdgeDataType>
&vertex) {
vertex.set_data(vertex.vertexid);
for(int i=0; i < vertex.num_outedges(); i++) {
list<list<vid_t>*> *edge_value = new list<list<vid_t>*>;
list<vid_t> *msg = new list<vid_t>;
msg->push_back(vertex.vertexid);
edge_value->push_back(msg);
vertex.outedge(i)->set_data(edge_value);
}
56
}
void CycleDetection::sendMessageToNeighbour(graphchi_vertex<VertexDataType, EdgeDataType> &vertex,
int neighbourId, list<vid_t> *value) {
list<list<vid_t>*> *outvalue = vertex.outedge(neighbourId)->get_data();
value->push_back(vertex.vertexid);
outvalue->push_back(value);
}
void CycleDetection::deleteMessages(list<list<vid_t>*> *msgs) {
for(list<list<vid_t>*>::iterator it = msgs->begin(); it!=msgs->end(); it++){
delete (*it);
}
msgs->clear();
}
bool CycleDetection::hasInMessages(graphchi_vertex<VertexDataType, EdgeDataType> &vertex) {
for(int i=0; i < vertex.num_inedges(); i++) {
list<list<vid_t>*> *inMsgs = vertex.inedge(i)->get_data();
if(inMsgs->size()>0) return true;
}
return false;
}
vid_t CycleDetection::getMinVertexId(graphchi_vertex<VertexDataType, EdgeDataType> &vertex, list<vid_t>
*value) {
vid_t minId = vertex.vertexid;
for(list<vid_t>::iterator it = value->begin(); it!=value->end(); it++){
if( (*it)<minId ) minId = (*it);
}
return minId;
}
bool CycleDetection::vertexListContains(graphchi_vertex<VertexDataType, EdgeDataType> &vertex, list<vid_t>
*value) {
list<vid_t>::iterator it = value->begin();
while(it!=value->end()){
if( (*it)==vertex.vertexid ) return true;
it++;
}
return false;
}
list<vid_t> *CycleDetection::copyVertexList(list<vid_t> *vList) {
list<vid_t> *value = new list<vid_t>;
for(list<vid_t>::iterator it = vList->begin(); it!=vList->end(); it++){
value->push_back(*it);
57
}
return value;
}
void CycleDetection::outputCycle(list<vid_t> *value) {
cout << "CYCLE: [ ";
for(list<vid_t>::iterator it = value->begin(); it!=value->end(); it++){
cout << (*it) << " ";
}
cout << "]" << endl;
}
GraphChi uma soluo razovel em termos de custo e benefcio. Apesar de no apresentar escalabilidade em
termos de ns de computao, apresenta certa escalabilidade em relao ao tamanho dos dados de entrada, devido
sua caracterstica de trabalhar em disco (memria secundria).
Experimentos
Os experimentos foram realizados em uma aplicao de exemplo, usado a implementao do sistema GraphChi, para
encontrar grupos de nmeros sociveis, tambm chamados de aliquot cycles, estudados em Teoria dos Nmeros. O
grafo uma representao de um subconjunto dos nmeros naturais relacionados pela soma dos seus divisores
prprios, tambm chamada de aliquot sum.
Grupos sociveis so ocorrncias raras nos nmeros naturais. O primeiro grupo socivel de ordem maior ou igual a
dois o par amigvel (220, 284), o segundo grupos socivel (1184, 1210).
Experimento #1
O primeiro experimento foi executado para um grafo de 4544641 vrtices. O tempo total para execuo de todas as
iteraes foi de 70,7115 segundos (1,18 minutos), realizando um total de 64 iteraes, com tempo mdio de 1,08787
segundos para processar cada vrtice a cada iterao.
Para esse grafo de 4544641 vrtices, basicamente representando o intervalo de nmeros naturais [0, 4544641], foram
encontrados 49 grupos sociveis de ordem maior ou igual a dois.
Experimento #2
O segundo experimento foi executado para um grafo de 13485277 vrtices. O tempo total para a execuo de todas
as iteraes foi de 326,722 segundos (5,45 minutos), realizando um total de 79 iteraes, com tempo mdio de
4,08402 segundos para processar cada vrtice a cada iterao.
Para esse grafo de 13485277 vrtices, basicamente representando o intervalo de nmeros naturais [0, 13485277],
foram encontrados 71 grupos sociveis de ordem maior ou igual a dois.
58
Experimento #3
4.18037 segundos para processar cada vrtice a cada iterao.
Experimento #4
4,92826 segundos para processar cada vrtice a cada iterao.
Referncias
[1] http:/ / pt.wikipedia. org/ wiki/ Busca_em_profundidade
[2] Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest and Clifford Stein, Introduction to Algorithms, The MIT Press, 3rd Ed. (2009).
[3] ROCHA, Rodrigo C. O., A Method of Searching Sociable Numbers Using Graph Theory: An Implementation on Large Computer Clusters,
(2013).
[4] Grzegorz Malewicz, Matthew H. Austern, Aart J.C Bik, James C. Dehnert, Ilan Horn, Naty Leiser and Grzegorz Czajkowski, Pregel: a
system for large-scale graph processing, Proceedings of the 2010 ACM SIGMOD International Conference on Management of Data,
SIGMOD '10 (2010), 135--146.
[5] John A. Bondy, Uppaluri S. R. Murty, Graph Theory, Springer, 1st Ed. (2008).
[6] Aapo Kyrola, Guy Blelloch, and Carlos Guestrin, GraphChi: Large-scale graph computation on just a PC, OSDI (2012).
API para processamento estatstico
59
Descrio da Aplicao
Denominao
API para processamento estatsticos em grandes volumes de dados
Contexto
Extrair informaes estatsticas de bases de dados uma tarefa bastante comum. Bancos relacionais j trazem em
suas implementaes suporte a diversas funes, tais como soma, mdia, contabilizao, etc.
Em se tratando de grandes volumes de dados, tarefas dessa natureza tambm so de grande importncia. Existem
algumas implementaes que facilitam essa tarefa, como o caso do Hive
[1]
e Pig
[2]
, dentre outros. Entretanto, o
usurio obrigado a conhecer detalhes de tecnologias muitas vezes diferentes daquelas que est habituado. Neste
contexto, a API aqui proposta visa prover uma srie de funes para processamentos estatsticos em grandes volumes
de dados, oferecendo ao usurio uma interface bastante simples.
So providas funes corriqueiras como soma, mximo, mnimo, mdia, desvio padro e contagem, bem como
funes mais elaboradas como particionamento de base, diviso em quantis e criao de tabela de contingncia
N-dimensional.
Um caso particular de uso a o processamento da base de dados do SUS para produo de indicadores com vrios
recortes diferentes, ou ainda sua diviso para validao de algoritmos em um contexto reduzido.
Algoritmo
Os algoritmos aqui descritos operam sobre uma ou mais das seguintes variveis:
T - base de dados com as transaes;
f - condio de filtragem, utilizada para limitar um escopo de trabalho na base T;
i - atributo (ou dimenso) da base T que ser alvo do processamento;
i_t - valor do atributo i na transao t;
g - atributos (ou dimenses) que sero usados para gerao de agrupamentos. Quando aplicvel, cada tupla de
valores distintos de g na base T ser considerada como critrio para agrupamento de registros.
g_i(i=1..N) - cada uma das N tuplas distintas de g na base T. Se g for indefinido, ento todo t E T ser considerado
pertencente a um mesmo grupo g_1.
Mximo
Maior valor assumido pelo atributo i na base T em cada grupo g, limitando as transaes t quelas que atendem ao
critrio f.
funo mximo(T, i, g, f)
mximo[g_k(k=1..N)] <= VAZIO
para cada t E T | t atende a f
se i_t > mximo[g_k | t E g_k] ento
mximo[g_k] <= i_t
fim se
fim para
fim funo
60
Mnimo
Menor valor assumido pelo atributo i na base T em cada grupo g, limitando as transaes t quelas que atendem ao
critrio f.
funo mnimo(T, i, g, f)
mnimo[g_k(k=1..N)] <= VAZIO
se i_t < mnimo[g_k | t E g_k] ento
mnimo[g_k] <= i_t
fim se
fim para
fim funo
Soma
Soma de todos os valores assumidos pelo atributo i na base T para cada grupo g, limitando as transaes t quelas
que atendem ao critrio f.
funo soma(T, i, g, f)
soma[g_k(k=1..N)] <= 0
soma[g_k | t E g_k] += i_t
fim para
fim funo
Mdia
Mdia dos valores assumidos pelo atributo i na base T em cada grupo g, limitando as transaes t quelas que
atendem ao critrio f.
funo mdia(T, i, g, f)
soma[g_k(k=1..N)] <= 0
elementos[g_k(k=1..N)] <= 0
soma[g_k | t E g_k] += i_t
elementos[g_k | t E g_k] ++
fim para
para cada k (1..N)
mdia[g_k] <= soma[g_k] / elementos[g_k]
fim para
fim funo
Contagem
Conta o nmero de transaes t que esto agrupadas em cada grupo g_i, limitando estas transaes apenas aquelas
funo conta(T, g, f)
conta[g_k(k=1..N)] <= 0
conta[g_k | t E g_k] ++
fim para
61
fim funo
Desvio padro
Desvio padro dos valores assumidos pelo atributo i na base T em cada grupo g, limitando as transaes t quelas
funo desvio(T, i, g, f)
diferenaQuadrado[g_k(k=1..N)] <= 0
mdia(T, i, g, f)
diferenaQuadrado[g_k | t E g_k] += (i_t - mdia[g_k])^2
elementos[g_k | t E g_k] ++
fim para
para cada k (1..N)
desvio[g_k] <= raizQuadrada(diferenaQuadrado[g_k] / elementos[g_k])
fim para
fim funo
Particionamento
Particionamento da base em subconjuntos determinados por cada cada grupo g_i, limitando as transaes t quelas
que atendem ao critrio f. Cada grupo g_i gera uma nova base, composta por todas as transaes contida no grupo
g_i.
funo particiona(T, g, f)
particao[g_k(k=1..N)] <= VAZIO
particao[g_k | t E g_k] += t
fim para
fim funo
Quantis
Particionamento das transaes da base T que atendem ao critrio f em subconjuntos, de forma que o intervalo entre
o valor mnimo e mximo para o atributo i dividido em q faixas e cada transao t alocada no subconjunto
equivalente faixa que se enquadra i_t.
funo quantis(T, q, i, f)
minimo = min(T, q, i, f)
mximo = max(T, q, i, f)
f = divide(mximo - mnimo, q)
quantis[f_k(k=1..q)] <= VAZIO
para cada t E T | t atende ao critrio f
quantis[f_k | f_(k-1) < i_t <= f_k] += t
fim para
fim funo
62
Contingncia
Gera a tabela de contingncia
[3]
e as margens para as transaes t E T que atendem ao critrio f, considerando os
atributos definidos em g.
funo contingncia(T, g, f)
contingncia[g_k(k=1..N)] <= 0
contingncia[g_k | t E g_k] ++
fim para
para cada s | s subconjunto prprio de g_k(k=1..N)
margem[s] = 0
para cada k (1..N)
se g_k contm s ento
margem[s] += contingncia[g_k]
fim se
fim para
fim para
fim funo
Exemplo de Funcionamento
Considerando a base de dados T a seguir:
UF SEXO ANO PROCEDIMENTO AMBULATORIAL VALOR
MG M 2010 A 10
MG M 2011 B 2
MG F 2010 C 4
SP F 2010 A 10
SP F 2010 A 10
SP F 2011 B 2
MT M 2011 B 2
MT F 2011 C 4
MS F 2010 A 10
RS F 2010 B 2
As sadas para cada comando so:
mximo(T, VALOR, {UF, SEXO}, {PROCEDIMENTO = A})
63
UF SEXO VALOR
MG M 10.0
MS F 10.0
SP F 10.0
mnimo(T, VALOR, {UF, ANO}, NULL)
UF ANO VALOR
MG 2010 4.0
MG 2011 2.0
MS 2010 10.0
MT 2011 2.0
RS 2010 2.0
SP 2010 10.0
SP 2011 2.0
soma(T, VALOR, {UF, ANO}, {PROCEDIMENTO EM (A, C)})
UF ANO SOMA
MG 2010 14.0
MS 2010 10.0
MT 2011 4.0
SP 2010 20.0
mdia(T, VALOR, {UF}, NULL)
UF MDIA
MG 5.33
MS 10.0
MT 3.0
RS 2.0
SP 7.33
desvio(T, VALOR, {UF}, NULL)
64
UF DESVIO
MG 5.89
MS 0.0
MT 1.41
RS 0.0
SP 6.53
conta(T, {PROCEDIMENTO}, {ANO = 2010})
PROCEDIMENTO OCORRNCIAS
A 4
B 1
C 1
particiona(T, {UF, PROCEDIMENTO}, NULL)
UF SEXO ANO PROCEDIMENTO VALOR
MT F 2011 C 4
MT M 2011 B 2
MS F 2010 A 10
MG F 2010 C 4
MG M 2010 A 10
MG M 2011 B 2
65
SP F 2010 A 10
SP F 2010 A 10
SP F 2011 B 2
RS F 2010 B 2
quantis(T, 3, VALOR, NULL)
Nesse exemplo, uma faixa ficou sem representantes
MG M 2010 A 10
SP F 2010 A 10
SP F 2010 A 10
MS F 2010 A 10
MG M 2011 B 2
MG F 2010 C 4
SP F 2011 B 2
MT M 2011 B 2
MT F 2011 C 4
RS F 2010 B 2
contingncia(T, {UF, PROCEDIMENTO, ANO}, NULL)
Tabela de contingncia
UF PROCEDIMENTO ANO OCORRNCIAS
MG A 2010 1
MG B 2011 1
MG C 2010 1
MS A 2010 1
MT B 2011 1
MT C 2011 1
RS B 2010 1
SP A 2010 2
SP B 2011 1
Margens da dimenso PROCEDIMENTO
66
PROCEDIMENTO OCORRNCIAS
A 4
B 4
C 2
Margens da dimenso UF
UF OCORRNCIAS
MG 3
MS 1
MT 2
RS 1
SP 3
Margens da dimenso ANO
ANO OCORRNCIAS
2010 6
2011 4
Margens das dimenses UF e ANO
UF ANO OCORRNCIAS
MG 2010 2
MG 2011 1
MS 2010 1
MT 2011 2
RS 2010 1
SP 2010 2
SP 2011 1
Margens das dimenses PROCEDIMENTO e ANO
PROCEDIMENTO ANO OCORRNCIAS
A 2010 4
B 2010 1
B 2011 3
C 2010 1
C 2011 1
Margens das dimenses UF e PROCEDIMENTO
67
UF PROCEDIMENTO OCORRNCIAS
MG A 1
MG B 1
MG C 1
MS A 1
MT B 1
MT C 1
RS B 1
SP A 2
SP B 1
Requisitos
Escalabilidade
As implementaes no impem limite ao volume de dados que so capazes de processar e nem ao nmero de ns de
processamento. Por funcionar sobre a plataforma Hadoop, a escalabilidade da biblioteca depende diretamente da
escalabilidade deste ltimo.
Tolerncia a falhas
As implementaes fornecem o mesmo nvel de tolerncia a falhas que o sistema de arquivos distribudo HDFS do
Hadoop.
Armazenamento
As bases de dados a serem processadas ficam armazenadas no HDFS, que , por natureza, um sistema de arquivos
distribudo construdo principalmente para facilitar o acesso aos dados pelos ns de processamento do cluster
Hadoop.
Latncia
Os algoritmos implementados so pensados para trabalhar em batch, no sendo recomendados para processamento
em tempo real, como comum em operaes estatsticas de sistema de banco de dados.
Tabela de contingncia.
[4]
Diviso em quantis.
[5]
68
Projeto
As funes de agregao simples, tais como mximo, mnimo, soma, contagem e mdia (soma/contagem) so
trivialmente paralelizveis, uma vez que possvel dividir o conjunto de dados, executar o algoritmo de forma
independente sobre cada conjunto, e promover a juno dos resultados parciais. Isto torna o processamento
escalvel, bastando aumentar o nmero de ns para comportar um maior volume de dados ou melhorar a
performance.
O clculo do desvio padro envolve o clculo da mdia e posterior clculo da diferena quadrtica de cada elemento
para a mdia. Os dois passos devem ser sequenciais, pois no se pode calcular a diferena antes que a mdia seja
conhecida. No entanto, a mdia pode ser obtida de forma paralela, bem como a diferena. Neste ltimo caso, a base
pode ser distribuda e cada n informado do valor da mdia. Cada n pode trabalhar de forma independente sobre
seu conjunto de dados, produzindo as diferenas quadrticas que, numa fase de reduo, servio na composio do
clculo do desvio.
O particionamento tambm passvel de paralelizao, dado que a base de dados pode ser dividida e cada parte pode
ser processada de forma independente, separando os registros em cada partio. Um ponto importante a ser levantado
aqui que a quantidade de dados escritos igual quantidade de dados lidos, ao contrrio das funes de agregao
que exigem muito mais leitura que escrita. Haver aqui uma concorrncia na escrita dos registros, j que vrios
processos podem alimentar uma mesma partio.
Similarmente, a tabela de contingncia pode ser construda a partir do processamento independente de blocos da base
de dados e posterior juno. As margens podem ser computadas medida que a tabela materializada para
minimizar comunicao entre os ns, uma vez que os atributos j estaro previamente agrupados.
Para a diviso da base em quantis so necessrios dois passos: o primeiro para calcular as faixas de cada quantil e o
segundo para separao efetiva dos dados nos respectivos slots. Por serem passos dependentes, devem ser
executados de forma sequencial. Entretanto, cada um dos passos pode ser paralelizado. O clculo das faixas para os
quantis passa pela soma e posterior diviso pelo nmero de faixas. A maior parte da computao, que a soma,
conforme observado anteriormente, pode ser paralelizada. A separao dos registros em quantis pode ser distribuda
quebrando-se a base em partes menores e distribuindo aos ns, juntamente com as faixas dos quantis. Cada n pode
processar o que lhe cabe e dar a sada no quantil correto. A escrita deve ser controlada, j que vrios processos
podem concorrer nesse momento. Tambm aqui importante observar que o nmero de registros lidos e escritos so
idnticos, salvo pela utilizao de filtros.
Em todos os casos no h dependncia no acesso aos dado visto que so totalmente distribudos e processados
exclusivamente pelos respectivos ns. H concorrncia, em alguns casos, na escrita dos dados. Isso pode ser um
gargalo, j que este fenmeno ocorre justamente nas funes que do sadas a um maior nmero de registros.
Padres de comunicao
Nas funes de agregao simples, particionamento e contingncia no h necessidade de comunicao entre os ns
durante a leitura e processamento, tampouco na fase de agregao.
O particionamento capaz de escrever no arquivo de sada medida que os registros so lidos, sendo desnecessrias
as comunicaes entre os ns (exceto entre os produtores e consumidores).
Para o clculo do desvio padro necessrio comunicar o valor da mdia a todos os ns para que possam, assim,
iniciar o processamento.
69
No caso da diviso em quantis, as faixas claculadas na primeira passada devem ser repassadas a todos os ns, ponto
a partir do qual a alocao dos registros poder ser iniciada.
Desenvolvimento
Em todas as funes h uma forte caraterstica de paralelismo de
dados, j que estes so distribudos. Em nenhuma situao foi
observado paralelisme de tarefas sobre os mesmo dados.
O produto das funes armazenado em disco. Nos casos dos quartis e
do desvio padro, os valores calculados no primeiro passo so deixados
em memria primria.
Estratgias de comunicao
Nos casos onde a comunicao necessria, o agregador dispara todos
os leitores do segundo passo j com os valores necessrios para os
prximos clculos (mdia, no desvio padro e faixas, na diviso em
quantis).
Implementao
A soluo implementada sobre as plataformas Hadoop
[6]
e Pig, alm
de fazer uso da biblioteca DataFu
[7]
.
A linguagem Pig Latin facilita a construo de programas na
arquitetura MapReduce de uma forma limpa e intuitiva, sem a
necessidade de escrever diretamente as funes map e reduce. Funes
como foreach encapsulam mapeamentos, enquanto construes group
by mascaram as redues. No caso de utilizao de vrios
mapeamentos e redues, a plataforma Pig colabora tambm na
otimizao da troca de mensagens. Outro ponto a se considerar aqui a
facilidade de construo e depurao das funes, visto que possvel
fazer execuo local sem a necessidade de iniciar toda a estrutura
Hadoop/HDFS, isto de uma forma bastante transparente.
Solues com utilizao da arquitetura MapReduce diretamente e
tambm da plataforma Hive foram avaliadas. No entanto, a facilidade de desenvolvimento e de manipulao de
arquivos oferecidas pelo Pig pesaram a seu favor.
A API construda na linguagem Java, utilizando a ferramenta Maven
[8]
para gerenciar o ciclo de vida do
desenvolvimento. Isso possibilita que o mdulo seja facilmente includo como dependncia em outros projetos dessa
70
natureza. possvel, ainda, sua utilizao em projetos Java que no seguem a estrutura definida pelo Maven e
tambm como programa stand alone.
Integrao de plataformas e ferramentas
A API no necessita ser executada diretamente sobre a plataforma Hadoop; a prpria plataforma Pig se encarrega de
reconhecer e disparar os jobs.
As bases de dados so arquivos CSV carregados no HDFS, utilizando como separador o caracter ponto e vrgula. O
prprio sistema de arquivos j faz a distribuio dos blocos entre os diversos ns. Os mapeadores leem dos ns mais
prximos e consomem os blocos, comunicando o resultado aos redutores via arquivo no mesmo sistema de arquivos.
Nos casos onde so necessrias duas fases de leitura, o final da primeira fase de agregao j dispara os novos
mapeamentos, repassando as informaes solicitadas ao passo seguinte. O controle da escrita concorrente em
arquivos feita pelo prprio HDFS.
A funo para diviso em quantis utiliza a funo de quantis do DataFu para o clculo das faixas.\
Apesar de vrias dessas funes estarem disponveis ou serem facilmente alcanveis com a utilizao de
plataformas como Hive e Pig, a API oculta os detalhes de baixo nvel da distribuio, podendo ser utilizada por
qualquer desenvolvedor que tenha os conhecimentos bsicos de orientao por objeto.
Avaliao
Carga de trabalho
O desempenho da API desenvolvida foi avaliado atravs da aplicao de suas funcionalidades para analisar uma base
de dados de grandes dimenses. Esta base contm centenas de milhes de registros, e a anlise estatstica destes no
vivel utilizando uma abordagem no distribuda.
A fim de avaliar tambm a escalabilidade da API para bases de dados de tamanhos variados, a base de dados original
foi subdividida em vrias bases menores. Essa subdiviso permite avaliar o padro de complexidade das
funcionalidades disponibilizadas pela API.
Avaliao experimental
A anlise da API foi realizada atravs de mltiplas execues de cada uma de suas funcionalidades sobre as bases de
dados de diversos tamanhos. Para cada uma das execues foi analisado o tempo de execuo, quantidade de dados
lidos e a quantidade de maps e reducers executados.
As funcionalidades testadas esto listadas a seguir, contudo importante destacar que somente algumas das
funcionalidades de agregao foram testadas, pois a maioria possui complexidade semelhante.
Mdia
Soma
Desvio
Quantis
Contingncia
Particionamento
Cada uma das funcionalidades foi testada atravs de sua execuo sobre bases de dados de diversos tamanhos.
71
Clculo da mdia
Tempo de execuo Nmero de tarefas
Diviso em cinco quantis
Clculo do desvio padro
72
Gerao da tabela de contingncia para trs atributos
Particionamento por trs atributos
Anlise de resultados
Os resultados foram obtidos com variao apenas do tamanho da entrada. Outra condio interessante de ser
observada a variao do nmero de ns de processamento, o que deveria ser feito em trabalhos futuros.
Em todos os casos, interessante observar o comportamento linear com tendncia assinttica dos algoritmos a partir
de um determinado volume de registros (4000000, no caso da mdia). Ademais, o nmero de mapeadores sempre
significativamente maior que o nmero de redutores.
Anlise Crtica
O comportamento linear assinttico nas funes de agregao sugere que o cluster tende a trabalhar prximo ao seu
limite de processamento ao se aumentar o tamanho da entrada. A adio de mais ns, no caso de aumento de dados,
dever subir o limite assinttico, melhorando o desempenho.
O Hadoop assume que as redues devero agregar dados, consumindo muito e produzindo pouco. Por esta razo, o
nmero de redutores significativamente menor que o de mapeadores. Isso vlido para grande parte das funes,
mas no uma assumpo vlida para as funes de gerao de quantis e particionamento. possvel que o
desempenho seja melhorada nesses casos com um melhor balanceamento das tarefas.
73
Codigo Fonte
O cdigo fonte pode ser encontrado aqui
[9]
, podendo ser usado e distribudo livremente.
Referncias
[1] (http:/ / hive.apache.org), Hive
[2] (http:/ / pig.apache. org), Pig
[3] (http:/ / en.wikipedia. org/ wiki/ Contingency_table), Tabela de contingncia
[4] (http:/ / dx. doi. org/ 10.1109/ CLUSTER.2010. 43), Computing Contingency Statistics in Parallel: Design Trade-Offs and Limiting Cases
[5] (http:/ / www.cs.ucsb. edu/ ~suri/ psdir/ ency.pdf), Quantiles on Streams
[6] (http:/ / hadoop. apache. org/ ), Hadoop
[7] (http:/ / engineering. linkedin. com/ open-source/ introducing-datafu-open-source-collection-useful-apache-pig-udfs), DataFu
[8] (http:/ / maven.apache.org), Maven
[9] http:/ / www. dcc.ufmg.br/ ~motta/ PDM-API-Estatistica. zip
Avaliao do algoritmo PageRank
Descrio da Aplicao
Denominao
Algoritmo PageRank.
Contexto
A busca de informao no uma tarefa trivial. A rea da recuperao de informao vem lidando com esse
problema h dcadas, antes mesmo da criao da Web, desenvolvendo sistemas para busca de jornais, artigos
cientficos e patentes. A busca na Web se torna mais difcil ainda, devido a sua natureza evolutiva de constante
crescimento e modificao.
Uma soluo proposta para o problema de busca de pginas na Web que utilizado pelo Google o algoritmo
PageRank. Ele tenta medir a importncia de cada pgina levando em considerao a topologia da rede formada pelas
ligaes entre as pginas atravs dos hyperlinks. Mesmo sendo proposto inicialmente para pginas da Web, ele pode
ser aplicado em qualquer rede, onde o resultado final do algoritmo um valor numrico atribudo a cada nodo,
medindo sua respectiva influncia naquela rede.
Algoritmo
Numa rede com n nodos, atribui-se inicialmente o valor de 1/n para cada um. Depois disso, realizamos uma regra de
atualizao um determinado nmero k de vezes. A regra de atualizao a seguinte: cada nodo compartilha seu valor
atual de PageRank igualmente com todos os nodos que segue, e cada nodo atualiza seu valor para ser a soma das
partes que recebeu. A teoria do PageRank diz que at mesmo uma pessoa que clica em links aleatoriamente vai,
eventualmente, parar de clicar. A probabilidade, a qualquer passo, que uma pessoa continue clicando dado por um
fator de amortecimento (damping factor) d, que geralmente configurado para ter o valor 0,85. O fator de
amortecimento subtrado de 1 e o resultado adicionado ao produto do fator de amortecimento pela soma das
partes que o nodo recebeu.
1 para cada vertice :
2
3
4 para cada iteracao , enquanto :
74
5 para cada vertice :
6
7
Na figura abaixo possvel visualizar os nodos de um grafo com seus respectivos valores de PageRank. Podemos
observar que o vrtice B o que tem o maior valor, e pode ser considerado o mais relevante, de acordo com o
conceito do algoritmo. Observe tambm que o vrtice E, mesmo tendo muitas arestas de entrada, no tem um
PageRank alto, o que indica que os nodos que esto ligados a ele no tem tanta relevncia. Da mesma forma, o
vrtice C tem um PageRank alto no por ter muitas arestas, mas justamente por ser referenciado pelo vrtice B.
Fase "Apply" do GraphLab
Requisitos
Escalabilidade: A escalabilidade necessria devido ao fato da rede ser dinmica, ou seja, novos vrtices e
ligaes podem ser criados ou removidos a qualquer instante, e do grande volume de dados que chega na faixa
dos milhes de vrtices e bilhes de arestas.
Armazenamento: A aplicao no demanda muito armazenamento em memria principal devido para o clculo
em si, devido s propriedades comutativa e associativa do clculo do valor PageRank, no sendo necessrio
armazenar num mesmo instante todos os valores utilizados. Entretanto, devido a magnitude dos grafos
trabalhados na aplicao, necessrio uma quantidade significativa de espao em disco para armazenar o grafo.
J o resultado (sada) do algoritmo demanda pouco espao, pois necessrio apenas os IDs dos vrtices e seus
respectivos valores de PageRank finais.
Latncia: O dinamismos da rede torna o clculo do PageRank necessrio constantemente. A taxa de atualizao
depende do cenrio de aplicao, podendo ser semanal, dirio ou at mesmo horrio. Nesse caso, o clculo do
valor de PageRank de todos os vrtices deve ser feito em tempo hbil.
75
Tolerncia a falhas: O algoritmo necessita que os valores de PageRank dos vrtices estejam sincronizados em
relao s iteraes, ou seja, somente valores de uma mesma iterao devem ser utilizados para atualizao.
Como para o clculo de um vrtice necessrio os valores de todos os vizinhos, necessrio que haja uma
estabilidade dos nodos de computao.
As primeiras propostas de paralelizao do algoritmo PageRank foram desenvolvidas implementando a verso
matricial do algoritmo em resolvedores de sistema linear paralelos
[1]
.
Outra estratgia utilizada o esquema "URL Host", que aproveita a estrutura hierrquica da WEB para fazer a
parelizao. Basicamente o que ele faz agrupar os vrtices de pgina de um mesmo domnio (host) e fazer a
computao distribuda. Apesar de eficiente, essa estratgia fica limitada a grafos que representem pginas de
internet, sendo inadequada para uma abordagem mais genrica
[2]
.
Existem algumas verses de PageRank que fornecem valores aproximados, que na maioria das vezes justificado
pela eficincia no tempo de execuo, e uma vertente desses algoritmos faz uma abordagem paralela. Uma dessas
abordagens utiliza um esquema MapReduce que utiliza um modelo probabilstico e utiliza o mtodo de Monte Carlo
para calcular os valores.
[3]
H ainda tentativas de implementao do algoritmo em placas grficas (GPUs), que so arquiteturas fortemente
paralelas e com enorme poder de processamento
[4]
. Apesar de eficientes, a maioria dessas abordagens fica limitada
pela memria local limitada, ento para aplicaes prticas de alto porte, necessria uma estratgia auxiliar.
Projeto
Como o clculo do rank de um nodo em uma iterao depende do rank na iterao anterior dos nodos que apontam
para este nodo, este passo de calcular o novo rank pode ser executado paralelamente para cada nodo.
O valor do rank anterior no pode ser mudado enquanto esse passo executado e isso pode ser evitado. Ao terminar
esse passo, necessrio sincronizar as linhas de execuo para que a prxima iterao leia valores de ranks
atualizados.
A paralelizao pode ser ampliada se os somatrios de ranks forem divididos. A lista de nodos apontadores seria
dividida e o rank parcial seria calculado separadamente, j que soma em ordem diferente tem o mesmo resultado.
Entretanto isso cria uma etapa adicional para combinar os resultados parciais.
Entretanto essa oportunidade paralelizao no garante balanceamento de carga entre cada thread, porque enquanto
um nodo pode ser apontado por apenas um nodo, outro pode ser apontado por inmeros. O balanceamento pode ser
melhorado fazendo as threads somarem nmeros aproximados de nodos; os nodos que tem mais apontadores seriam
divididos entre mais threads, enquanto uma thread pode fazer o somatrio para mais de um nodo.
76
Cada nodo tem como dados o cojunto de nodos para o qual ele aponta e o valor de page rank atual. necessrio que
o nodo em cada iterao veja um grafo invertido, que tenha a lista de nodos que apontam para ele. E ele precisar
saber o valor do rank atual desses nodos junto com o nmero de nodos para os quais eles apontam ou apenas a
diviso entre esses dois valores.
Quando um algoritmo paralelo executa no mesmo computador, as threads podem ter memria compartilhada e isso
permite que cada thread leia todas as informaes que precisar sobre o grafo e o custo disso relativamente baixo.
Quando o volume de dados muito grande, o processamento teria tempo de execuo longo e os dados podem no
caber em um s disco rgido. A soluo seria fazer processamento distribudo. Isso requer que cada computador do
cluster receba os dados necessrios dos nodos que ele precisar e ao final de cada iterao o nodo precisar saber o
novo valor de rank de cada nodo que ele precisa e isso gera muitas mensagens de comunicao na rede.
Padres de comunicao
necessrio fazer comunicao para sincronizar as threads no final de cada iterao para que o novo valor de rank
seja atualizado no momento certo para no prejudicar as outras threads que ainda estejam executando e tambm para
comear a prxima iterao lendo valores de rank atualizados. Essa sincronizao pode ser vista como duas
barreiras, em que a primeira espera todos os somatrios terminar e a segunda espera todos os ranks serem
atualizados.
Em processamento distribudo, o novo valor de rank deve ser enviado para todas as threads que usaro esse valor na
prxima iterao. Assim, o nmero de mensagens trocadas na rede em cada iterao seria igual ao nmero de arestas
do grafo, e esse grande nmero de mensagens pode sobrecarregar a rede.
Quando h uma thread por nodo, cada thread processa de maneira independente sua lista de apontadores e no final
necessrio esperar todas as outras threads terminar para poder atualizar o rank do nodo e receber novos valores de
rank. Alm da comunicao para sincronizao, em implementao distribuda, necessrio comunicao para
enviar e receber valores do rank calculados durante a iterao.
Desenvolvimento
Hadoop
A implementao do PageRank usando Hadoop executa um nmero de iteraes definido como argumento do
programa. Cada iterao tem uma fase de "map" e "reduce", alm das fases de leitura de dados da iterao anterior e
escrita para o prxima iterao. O programa comea lendo um arquivo de entrada contendo o grafo e carrega os
dados do grafo no Hadoop.
O "damping factor" um argumento opcional do programa. O valor padro 0.85 e para desativar basta definir o
valor como 1.0.
77
A etapa "map" executada paralelamente para cada dado. Ela tem como entrada a chave sendo o identificador do
nodo e como valor o rank atual do n. Cada nodo passa no "map" uma vez e tem como sada cada nodo apontado por
ele e o valor de rank dividido pelo nmero de nodos apontados.
public void map(
Text uid,
DoubleWritable data,
OutputCollector<Text, DoubleWritable> output,
Reporter reporter
) throws IOException {
List<Text> followees = followees_list.get(uid);
DoubleWritable dw = new DoubleWritable(data.get() /
followees.size() );
Text followee = new Text();
for (Text f : followees ){
followee.set( f );
output.collect(followee, dw);
}
output.collect(uid, new DoubleWritable(0)); //Para manter no
grafo
}
A etapa "reduce" tem como entrada a chave sendo o identificador do nodo e uma lista de valores de rank/nmero de
nodos apontados j calculados na etapa anterior. Essa etapa vai somar os valores dessa lista e retornar o novo valor
de rank para o nodo identificado pela chave.
public void reduce(
Text key,
Iterator<DoubleWritable> values,
OutputCollector<Text, DoubleWritable> output,
Reporter reporter
) throws IOException {
double pagerank = 0;
while (values.hasNext()){
DoubleWritable dw = values.next();
pagerank += dw.get();
}
pagerank *= damping_facotr;
pagerank += first_term; // first =
(1-damping_facotr)/number_of_nodes
output.collect(key, new DoubleWritable(pagerank));
}
Como foi falado, essa estratgia no garante balanceamento de carga na etapa "reduce", porque o tempo de execuo
para nodos com mais apontadores seria mais longo por ter mais valores no iterador para somar.
78
Ao terminar uma iterao os dados so salvos no sistema de arquivos virtual distribudo do Hadoop (HDFS) para
serem lidos no incio da prxima iterao. Esse sistema de arquivos abstrado para o programador.
A gerncia da execuo feita pela funo principal do programa que inicia cada iterao de map-reduce. Assim, o
Hadoop encarregado de criar as threads e dividir a carga, sincronizar e transportar dados nas etapas map e reduce, e
escrever a sada da iterao.
GraphLab
Foi implementada a verso no normalizada do PageRank, ou seja, ao somar os valores de PageRank de todos os
vrtices o resultado igual ao nmero de vrtices, e no igual a 1. Observe que caso existam vrtices "dangling" (no
tm aresta de sada) a soma no sera totalizada, mas a ordenao relativa dos vrtices ser a mesma.
O GraphLab prov um paradigma de programao ideal para se trabalhar com grafos. O principal elemento da
plataforma o "Vertex Program", que executado em cada vrtice do grafo. O "Vertex Program" tem 3 fases de
execuo: (1) gather, que executada nas arestas adjacentes ao vrtice e retorna um valor, (2) apply, que agrega os
valores retornados pela fase anterior e (3) scatter, que novamente executado nas arestas adjacentes do vrtice.
Utilizando esse pardigma, o algoritmo PageRank ser feito por paralelizao de dados a nvel de vrtice. Como para
o clculo do valor de PageRank de um vrtice s necessrio valores de vrtices adjacentes, temos uma ferramenta
que se adequa muito bem para a resoluo do problema. Cada vrtice armazenar apenas seu respectivo valor de
PageRank e a atuzalizao ser feita atravs de um "Vertex Program", que tambm armazena um valor auxliar de
erro.
Na fase "gather" apenas as arestas de entrada so utilizadas, das quais o vrtice recebe os valores de PageRank para
atualizar seu prprio valor. Cada aresta (u, v) ativa na fase "gather" vai retornar o valor PR(u)/O(u), que corresponde
a um valor parcial da soma de atualizao.
Fase "Gather" do GraphLab no algoritmo PageRank
79
A fase "apply" vai receber os valores parciais j somados, ento basta atualizar o valor de acordo com o dumping
factor. Alm disso, ainda na fase "apply", vamos armazenar o valor de error calculando a diferena entre o novo e o
antigo valor de PageRank, que ser utilizado para decidir quais vrtices devero ser atualizados.
Fase "Apply" do GraphLab no algoritmo PageRank
A fase "scatter" utilizada para ativar vrtices que devero ter seus valores atualizados na prxima iterao do
algoritmo. Portanto, caso o valor de erro do vrtice seja menor do que o valor mximo de tolerncia, nenhuma aresta
ser ativa. Caso o valor de erro seja maior, sero ativas as arestas de sada. Cada aresta (u, v) ativa na fase "scatter"
vai assinalar o vrtice v para execuo na prxima iterao. Ou seja, um vrtice s ser convocado para execuo na
prxima iterao se pelo menos um de seus vizinhos de entrada ainda no tiver convergido, pois so justamente os
vrtices utilizados para o clculo de seu PageRank.
Fase "Scatter" do GraphLab no algoritmo PageRank
80
O armazenamento feito atravs do protocolo NFS, de forma que o acesso base de dados seja transparente igual
entre os vrtices. A base de dados pode ser dividida em arquivos, sendo uma opo de balanceamento explcito,
entretanto como o protoclo j NFS prov o acesso aos vrtices, optamos por deixar o balanceamento a carga do
framework.
A comunicao ser feita sempre entre vrtices e de forma transparente, devido a utilizao do paradigma de
programao do GraphLab. interessante observar que, como a verso do algoritmo PageRank implementada a
no normalizada, no necessrio o compartilhamento de valores globais entre os vrtices, como o nmero totais de
vrtices, que seria necessrio para a verso normalizada.
Implementao
Utilizamos um ambiente virtual com Ubuntu OpenStack com quatro servidores virtuais com Hadoop e GraphLab
configurados para executar os programas distribudos. Cada mquina virtual tem um processador de dois ncleos,
4GB de Ram e 10GB de HD, rodando Ubuntu 12.04.
Integrao de plataformas e ferramentas
Hadoop
Fizemos uma implementao em Apache Hadoop 1.0.4, usando linguagem Java. O Hadoop tem o recurso HDFS
(Hadoop Distributes File System) para armazenamento de dados.
GraphLab
A verso do GraphLab utilizada foi a 2.1.4434, e a verso do MPI foi o MPICH2 verso 1.2.1. Alm disso foi
utilizado o daemon NFS do Linux para compartilhar as bases de dados.
Hadoop
Fizemos uma implementao em Apache Hadoop 1.0.4, usando linguagem Java.
O Hadoop tem o recurso HDFS (Hadoop Distributes File System) para armazenamento de dados.
GraphLab
A implementao foi feita em linguagem C++, com o objetivo de ser mais genrica possvel, podendo executar em
qualquer tipo de grafo.
#include <string>
#include <fstream>
#include <graphlab.hpp>
#define DAMPING_FACTOR 0.85
#define MAX_ERROR 1e-6
81
// Estruturas de Dados
typedef double Vertice;
typedef graphlab::empty Aresta;
typedef graphlab::distributed_graph<Vertice, Aresta> Grafo;
// Algoritmo
class PageRank :
public graphlab::ivertex_program<Grafo, double>,
public graphlab::IS_POD_TYPE
{
private:
double error;
public:
edge_dir_type gather_edges(icontext_type &context, const
vertex_type &vertex) const {
return graphlab::IN_EDGES;
}
gather_type gather(icontext_type &context, const vertex_type
&vertex, edge_type &edge) const {
return edge.source().data() /
edge.source().num_out_edges();
}
void apply(icontext_type &context, vertex_type &vertex, const
gather_type &total) {
double valor_novo = (1 - DAMPING_FACTOR) +
DAMPING_FACTOR*total;
error = std::fabs(vertex.data() - valor_novo);
vertex.data() = valor_novo;
}
edge_dir_type scatter_edges(icontext_type &context, const
vertex_type &vertex) const {
if (error > MAX_ERROR) {
return graphlab::OUT_EDGES;
}
else {
return graphlab::NO_EDGES;
}
}
void scatter(icontext_type &context, const vertex_type &vertex,
edge_type &edge) const {
context.signal(edge.target());
}
};
void pagerank_valor_inicial(Grafo::vertex_type& vertice) {
vertice.data() = 1.0;
}
82
// Saida
class pagerank_writer {
public:
std::string save_vertex(Grafo::vertex_type v) {
std::stringstream saida_linha;
saida_linha << v.id() << " " << v.data() << std::endl;
return saida_linha.str();
}
std::string save_edge(Grafo::edge_type e) {
return "";
}
};
// Main
int main(int argc, char** argv) {
// Inicializa GraphLab
graphlab::mpi_tools::init(argc, argv);
graphlab::distributed_control dc;
// Parametros de Entrada
graphlab::command_line_options clopts("Algoritmo PageRank.");
std::string arquivo_entrada_grafo = "/shared/data/grafo.adj";
std::string arquivo_saida = "/shared/results/temp";
std::string formato_grafo = "adj";
clopts.attach_option("entrada", arquivo_entrada_grafo, "Arquivo de
entrada do grafo");
clopts.attach_option("formato", formato_grafo, "Formato do arquivo
do grafo: 'tsv' ou 'adj'");
clopts.attach_option("saida", arquivo_saida, "Arquivo de saida com
os valores de PageRank calculados para cada vertice");
if(!clopts.parse(argc, argv)) {
dc.cout() << "ERRO: Argumentos de linha de comando invalidos." << std::endl;
return EXIT_FAILURE;
}
// Carrega o grafo
Grafo grafo(dc);
grafo.load_format(arquivo_entrada_grafo, formato_grafo);
grafo.finalize();
// Executa algoritmo
grafo.transform_vertices(pagerank_valor_inicial);
graphlab::omni_engine<PageRank> engine(dc, grafo, "synchronous");
engine.signal_all();
engine.start();
83
const float tempo = engine.elapsed_seconds();
dc.cout() << "Terminou de executar em " << tempo << " segundos." << std::endl;
// Saida
grafo.save(arquivo_saida, pagerank_writer(), false, true, false);
// Finaliza GraphLab
graphlab::mpi_tools::finalize();
return EXIT_SUCCESS;
}
Avaliao
Carga de trabalho
Foi utilizado bases de dados gerada aleatoriamente utilizando algoritmo de gerao de grafos aleatrios
[5]
. Os
nmeros de vrtices utilizados foram variados de 100 mil at 900 mil, com a probabilidade de formao de aresta
fixa em 0.0001.
Tambm foi utilizada uma base de dados real coleatada da rede social do Google+, mas por motivos de tempo no
foi possvel a avaliao da execuo.
Avaliao experimental
GraphLab
Tamanho da entrada
Nesta anlise medimos o tempo de execuo do algoritmo variando o tamanho da entrada, ou seja, o nmero de
vrtices no Grafo.
No grafo abaixo fizemos a avaliao para diversas configuraes de processamento, variando de 1 nodo de
processamento at 8. Podemos observar que o crescimento quadrtico est presente em todas as configuraes,
contunde com a complexidade do algoritmo.
84
Tempo de execuo variando tamanho da entrada
Neste grfico est representado o valor de speedup em relao a configurao de 1 nodo de processamento e 8 nodos
de processamento (4 mquinas virtuais com 2 ncleos cada). interessante observar que para valores abaixo de 500
mil nodos o uso de processamento paralelo no vantajoso (speedup < 1), devido ao overhead causado pelo
framework.
Speedup variando tamanho da entrada
85
Escalabilidade
Nesta anlisa avaliamos o comportamento do algoritmo quando adicionamos diferentes nmeros de ncleos de
processamento. Podemos observar na figura abaixo que o algoritmo razoavelmente escalvel, indicando que o
aumento de nodos para para processamento paralelo vale a pena e pode ser realizado facilmente para melhorar o
desempenho do algoritmo.
Tempo de execuo para escalabilidade
86
Anlise de resultados
Iteraes
Nesta anlisase contabilizamos o nmero de iteraes necessrias para a converso do algoritmo. Podemos observar
que para valores de entrada maiores o nmero de iteraoes menor, indicando uma converso mais rpida em termos
do nmero de iteraes, apesar do tempo de execuo ser maior.
Nmero de iteraes em relao ao tamanho da entrada
Anlise Crtica
A utilizao do framework GraphLab teve resultados satisfatrios. A programao relativamente fcil, apesar da
configurao e instalao no sistema demandar tempo. O Hadoop, apesar da implementao do PageRank ser
possvel, no to trivial. Se levarmos em conta a facilidade de programao e o desempenho do algoritmo,
escolheramos o framework GraphLab ao invs do Hadoop. Isso mostra que o Hadoop no bom em todas as
situaes.
Referncias
[1] [1] Atish Das Sarma, Anisur Rahaman Molla, Gopal Pandurangan, Eli Upfal, "Fast Distributed PageRank Computation", CoRR, 2012
[2] [2] Christian Kohlschtter , Ru Chirita , Wolfgang Nejdl, "Efficient parallel computation of PageRank", ECIR, 2006
[3] [3] Bahman Bahmani, Kaushik Chakrabarti, Dong Xin, "Fast Personalized PageRank on MapReduce"
[4] [4] WU, T. et al., "Efficient pagerank and spmv computation on amd gpus". ICPP, 2010
[5] [5] Vladimir Batagelj and Ulrik Brandes, "Efficient generation of large random networks", Phys. Rev. E, 71, 036113, 2005.
Maximizao de expectativas
87
Maximizao de Expectativas
Nesta seo apresentamos o algoritmo conhecido como Maximizao de Expectativas, em especial sua utilizao em
ambientes distribudos que permitem o processamento de dados massivos, ou big data. Esta seo se divide em cinco
sees a seguir: Descrio, Projeto, Desenvolvimento, Implementao e Avaliao. Finalmente, fazemos um breve
estudo de caso do algoritmo, quando foi aplicado em uma competio, tambm de "big data".
Descrio da Aplicao
Aqui iremos descrever o algoritmo conhecido como Maximizao de Expectativas que, em conjunto com a maneira
como iremos aplic-lo ao cenrio distribudo para o tratamento de dados massivos.
Definio
O algoritmo Maximizao de Expectativas, mais conhecido pelo seu nome ingls Expectation Maximization ou EM,
pertece a uma classe de tcnicas estatsticas para a estimativa de parmetros para modelos estatsticos quando
existem variveis latentes (ou escondidas). Os parmetros encontrados so estimativas por mxima verossimilhana
ou maximum likelihood estimates (MLE).
Por modelo estatsticos estamos nos referindo , basicamente, uma equao que descreve relaes entre variveis
atravs de distribuies de probabilidade. Essas distribuies tornam as relaes estocsticas ao invs de
deterministas. J variveis latentes so variveis que no so diretamente observadas nos dados. Dessa maneira, elas
devem ser inferidas baseado nas variveis que foram de fato observadas. A mgica do EM que ele capaz de
lidar tanto com as variveis latentes quanto com os parmetros simultaneamente. Finalmente, a verossimilhana de
um conjunto de parmetros , basicamente, a probabilidade desses parmetros gerarem os resultados obtidos. O
MLE um mtodo de inferncia dos parmetros com verossimilhana (ou probabilidade) mxima. O EM uma
generalizao, portanto, do MLE em cenrios que existem variveis latentes. usual se utilizar o logaritmo da
verossimilhana (ou log-likelihood), porque a funo logaritmica uma funo crescente e o logaritmo uma
operao monotnica, isto , os parmetros que maximizam a funo original tambm maximizam a verossimilhana
e por consequncia o log-likelihood.
Contexto
O algoritmo de Maximizao de Expectativas foi explicado e batizado em um famoso artigo de 1977 por Arthur
Dempster, Nan Laird, e Donald Rubin. quando disseram que o mtodo j havia sido proposto outras vezes por
autores que os precederam. Em particular, um tratamento bem detalhado do algoritmo EM para famlias
exponenciais foi publicado por Rolf Sundberg em sua tese e diversos artigos, seguido de sua colaborao com Per
Martin-Lf e Anders Martin-Lf. O artigo de Dempster-Laird-Rubin em 1977 generalizou o mtodo e traou uma
anlise de sua convergncia para uma classe maior de problemas. Dessa maneira esse artigo estabeleceu o EM como
uma importante ferramenta na anlise estatstica.
Entre os usos histricos mais famosos, est o de como Kevin Knight utilizou o EM para quebrar o cdigo de uma
sociedade secreta de mais de 250 anos, ao invs de depender num dicionrio pr-definido, ele computou a traduo
de todas as palavras russas (idioma do documento previamente misterioso) para o ingls, e para cada uma delas
inventar uma chave para transformar todo documento para o ingls (Fonte
[1]
).
Outro uso de importncia do EM est descrito no artigo de Abhinandan Das, Mayur Datar, Ashutosh Garg e Shyam
Rajaram, onde eles descrevem como o algoritmo foi utilizado, dentro da concepo do MapReduce, para a filtragem
colaborativa. Outros usos importantes do algoritmo esto nas reas de clusterizao e classificao de dados. Como
88
ser demonstrado mais a frente, possvel identificar, facilmente, oportunidades de paralelizao e distribuio de
cargas de trabalho para ele.
Algoritmo
Como mencionado anteriormente, o algoritmo de Maximizao de Expectativas uma generalizao da estimativa
de mxima verossimilhana para o caso dos dados incompletos. Em particular, o EM tenta achar os parmetros
que maximizam a probabilidade logaritmica dos dados observados. Em linhas gerais, o problema de
otimizao abordado pelo EM mais difcil que a otimizao realizada pela estimativa de mxima verossimilhana.
No caso onde os dados esto completos, a funo objetivo tem um nico timo global, e que na
maioria das vezes pode ser encontrado de forma fechada. Em contraste, no caso dos dados incompletos, a funo
tem mltiplos mximos locais e nenhuma soluo de forma fechada.
Para lidar com isso, o EM reduz a difcil tarefa de otimizar em uma sequncia de subproblemas de
otimizao mais simples, cujas funes objetivo tem um nico mximo global que, dessa vez, podem ser
encontrados de forma fechada. Esses subproblemas so escolhidos de uma maneira que garante que suas solues
correspondentes , ,... e iro convergir para um timo local de .
Mais especificamente, o algoritmo expectation maximization alterna entre duas fases:
Durante a fase E, o EM escolhe a funo que limita inferiormente totalmente, e para a qual
;
Durante a fase M, o algoritmo passa para o novo conjunto de parmetros que maximiza .
A medida que o limiar inferior se aproxima da funo objetivo em , temos que
, desta maneira, a funo objetivo
monotonicamente aumenta a cada iterao do EM.
Um exemplo de um problema que pode ser resolvido atravs do Expectation Maximization, e que ser utilizado no
restante do trabalho
[2]
: dadas duas moedas, cada uma delas com vis desconhecido, suponha que uma moeda
aleatria selecionada uniformemente a lanada N vezes. Esse experimento repetido M vezes (para cada
lanamento, uma das moedas selecionada aleatoriamente). Qual o vis das moedas? Podemos identificar os
conceitos explicitados anteriormente:
Parmetros do modelo: Os vises das moedas;
Varivel latente: A seleo das moedas.
O que teria acontecido se a escolha das moedas fosse revelada? Teramos um cenrio de MLE tradicional. Os
parmetros (vises) poderiam ser estimados atravs de: vis estimado da moeda A = nmero de coroa observadas no
lanamento da moeda A / nmero de vezes que a moeda A foi lanada, e de maneira similar para a outra moeda. Mas
como o EM funciona para o problema mencionado?
1. 1. Define valores iniciais para os vises das moedas;
2. 2. Uma distribuinao de probabilidades sobre a escolha desconhecida das moedas definida baseado nos
parmetros atuais;
3. 3. Novos pariametros so estimados utilizando-se o MLE baseados nas probabilidaes de distribuio encontradas no
ltimo passo;
4. 4. Retorne ao passo 2 (at a convergncia).
A figura link
[3]
apresenta um exemplo para esse cenrio descrito.
89
Requisitos
Como mencionado anteriormente, um dos primeiros requisitos o de que exista varivel latente no modelo a ser
estudado, seja ela ausente na observao, ou seja ela propositalmente escondida. Alm disso necessrio saber a
funo de distribuio de probabilidade da qual se deseja descobrir os parmetros. Para alguns cenrios essa funo
no to evidente e pode demandar certo esforo para ser corretamente definida.
Paralelizaes Existentes
Abhinandan Das, Mayur Datar, Ashutosh Garg e Shyam Rajaram apresentaram uma das paralelizaes mais famosas
na litetura. No artigo entitulado Google News Personalization: Scalable Online Collaborative FIltering onde eles
utilizam o Expectation Maximization para encontrar os parmetros de mxima verossimilhana para o modelo em
questo. Eles definem e isolam propriamente as fases E e M do algoritmo dentro do modelo e observam que a
execuo do algoritmo, para o volume de dados em questo invivel (na poca cerca de 80GiB de memria
primria seria necessrio). Dessa maneira eles separam usurios e itens (objetos em questo) e mapeam a etapa E
para a etapa Map, e a M para a etapa Reduce. Na realidade, abordagem bastante similar utilizada em nossa estudo
de paralelizao e distribuio da computao.
Projeto
Oportunidades de Paralelizao
Tomando o exemplo que ser utilizado durante o trabalho, est apresentado na tabela abaixo o passo E do algoritmo
de Maximizao de Expectativas. importante notar que cada uma das linhas representa um lanamento com uma
moeda desconhecida. As duas tabelas seguintes apresentam a distribuio de probabilidade definida sobre ambas as
moedas e as duas ltimas representam o nmero de caras (H) e coroas (T) para a distribuio computada.
Lanamentos Probabilidade A Probabilidade B Expectativa A Expectativa B
H T T T H H T H T H 0.45 0.55 2.2 H, 2.2 T 2.8 H, 2.8 T
H H H H T H H H H H 0.80 0.20 7.2 H, 0.8 T 1.8 H, 0.2 T
H T H H H H H T H H 0.73 0.27 5.9 H, 1.5 T 2.1 H, 0.5 T
H T H T T T H H T T 0.35 0.65 1.4 H, 2.1 T 2.6 H, 3.9 T
T H H H T H H H T H 0.65 0.35 4.5 H, 8.6 T 2.5 H, 1.1 T
importante notar que cada linha encapsula todas as informaes necessrias (juntamente com os parmetros
estimados na iterao anterior) e pode ser calculada de maneira independente. Essa a oportunidade para a
paralelizao dessa computao, extremamente adequada para a etapa Map, no modelo de programao MapReduce.
Aps cada uma das probabilidades terem sido calculadas a hora de estimar os novos parmetros (os vises) para
cada uma das moedas. Isso se d com a soma das duas ltimas colunas e a aplicao do MLE. Novamente fcil
notar que, com o resultado da fase Map, basta aplicar a etapa Reduce do modelo MapReduce para obtermos os novos
parmetros e realizar outra etapa de MapReduce.
90
Padres de Acesso aos Dados
No existem necessidades ou observaes especiais de acesso aos dados alm do j citado anteriormente, de que
cada n ir guardar uma frao dos dados que de sua competncia. Um nico detalhe especial de que o valor para
os parmetros da iterao anterior deve estar disponvel para todos os ns.
Padres de Comunicao
Aqui novamente no h detalhes especiais a serem mencionados. Cada bloco de arquivo, que foi distribudo para
cada n contm todas as informaes necessrias para o processamento que ele deve realizar. Dessa maneira, no
existe a possibilidade de dead-locks ou de starvation, ou qualquer outro dano causado pela ociosidade em funo de
comunicao no bem realizada. Os nicos dados recebidos a cada iterao do processamento distribudo so os
parmetros, e os enviados, os nmeros esperados de caras e coroas para a funo de distribuio definida.
Obviamente, funes de probabilidade calculadas no passo E devem ser repassadas no passo Reduce, mas esse
detalhe implcito ao modelo de programao MapReduce.
Linha do Tempo Integrada
A linha do tempo abaixo ilustra a linha do tempo do processamento do algoritmo de Maximizao de Expectativas,
como discutido anteriormente. Cada n ir receber um ou mais linhas do dado bruto, lembrando que cada linha
corresponde um lanamento das moedas. Isso possvel graas a independncia do clculo dos valores para a
distribuio de probabilidade, aps a obteno do primeiro valor para os parmetros (feito nesse trabalho de maneira
aleatria). Essa tarefa coordenada pela etapa Map.
Em seguida, a etapa Reduce, se encarrega de agregar os valores computados para os valores esperados para a cada
distribuio avaliada, para por fim, estipular novos parmetros e recomear o ciclo MapReduce at que haja
converso para os valores dos parmetros.
Linha do tempo para o Algoritmo EM dentro do
modelo MapReduce
91
Desenvolvimento
Estratgias de Paralelizao
A soluo encontrada para distribuir o algoritmo entre vrios ns bastante direta: calcular a verossimilhana de
cada conjunto de lanamentos em paralelo atravs do map e para cada moeda calcular a nova distribuio de
probabilidades a partir da verossimilhana encontrada para moeda.
Inicia-se com um conjunto de P(x)=cara para cada moeda, de forma randmica
Enquanto probabilidade de cada moeda continua mudando:
mapper(linha,conteudo):
[cara,coroa] = conteudo.split()
//calcula probabilidade de que cada lancamento pertenca a uma das moedas
for moeda in moedas:
emits(moeda, [num_coroas, num_caras])
reduce(moeda, jogadas[num_coroas, num_caras]):
numero_caras = 0
numero_coroas = 0
for jogada in jogadas:
numero_coroas += jogada[0]
numero_caras += jogada[1]
//emite novo likelihood da moeda
probabilidade_cara = numero_caras/(numero_caras+numero_coroas)
//emite a probabilidade de que a moeda d cara
emits(moeda, probabilidade_cara)
Estratgias de Armazenamento
Contamos com somente um arquivo de entrada para alimentar o algorimto de maximizao de expectativas. Neste
arquivo - com tamanho que pode chegar 1gb - cada linha representa um conjunto de lanamentos feito com uma
moeda desconhecida.
Inicialmente, transferimos o arquivo para o HFS (Hadoop File System) escolhendo o nvel de redundncia igual 2.
Isso significa que nosso arquivo separado em CHUNKS de dados e cada chunk copiado em dois diferentes ns.
Observe que cada chunk completo, isto , contm linhas completas do arquivo original. Isto importante para
mantermos o clculo em paralelo e independente das verossimilhanas dos conjuntos de lanamentos e as provveis
probabilidades de cada moeda.
92
Armazenamento de arquivo de texto com
redudncia no HFS
Estratgias de Comunicao
A execuo de programas em ambientes distribudos pode trazer
benefcios se o tempo para iniciao dos programas e troca de dados
no forem overhead maior do que o ganho com a paralelizao da
tarefa.
A estratgia MapReduce reduzir ao mximo a troca de dados entre os
ns que trabalham para realizar uma tarefa. Neste paradigma, o
objetivo levar o processamento at onde os dados esto e no o
inverso. Portanto, inicialmente, quando se transfere os arquivos para o
HFS eles so distribudos em chunks pelos ns disponveis no cluster.
O processamento de Map ocorre em cada um dos ns que j possuem
parte dos dados. Dados so transferidos somente no caso de queda de
mquina e/ou grave desbalanceamento.
Por fim, terminadas as tarefas de Map, os dados resultantes so transferidos para os worker que esto rodando as
tarefas de Reduce. Seguindo a estratgia MapReduce, o recomendvel que estes dados no sejam complexos e
pequenos o suficiente para no causar overhead na rede. No caso da nossa tarefa, esses dados so somente as novas
contagens geradas pela verossimilhana entre o conjunto de lanamentos e a probabilidade P(cara) de cada moeda
que podem ser expressas utilizando o tipo Double.
Implementao
Plataformas e Ferramentas
Utilizamos o Hadoop File System
[4]
verso 1.03 para armazenamento dos nosso dados de forma distribuda e
programas nossa estratgia de MapReduce utilizando a API do Apache Hadoop.
O Hadoop File System um sistema distribudo, escalvel, portvel e open-source escrito em Java que suporta a
execuo de aplicaes que exigem uma quantidade grande dados de forma distribuda. Ele foi inspirado nos artigos
escritos pela Google descrevendo o Google File System
[5]
que tambm implementa o paradigma de MapReduce.
A configurao do cluster onde trabalhamos foi feita a partir do OpenStack
[6]
, software para fcil gerenciamento de
infraestruturas virtualizadas. Nosso cluster continha quatro mquinas virtuais diferentes.
Integrao de Plataformas e Ferramentas
Para integrao das plataformas, substitumos o sistema Java openSDK das mquinas virtuais ubuntu pelo sistema da
Sun - para o qual o Hadoop melhor adaptado. Utilizamos um namenode com rplica e quatro datanodes com nvel
de redundncia igual a 2.
Utilizamos a API Java do Hadoop para criarmos nossas tarefas de MapReduce, assim como o nosso driver para
iniciao dos Jobs.
93
Detalhes de Implementao
Note que a dificuldade que temos aqui consiste em passar os novos valores de probabilidade para os maps a cada
iterao. Note que precisamos passar somente P(cara), uma vez que P(coroa) pode ser dado por 1-P(cara). Para isso,
utilizamos do JobConf. O JobConf acessvel a todo processo de map e reduce e permite que lhe sejam atribudos
parmetros com valores de tipos primitivos e recuper-los durante a execuo atravs do mtodo get().
public static class Map extends MapReduceBase implements Mapper<LongWritable, Text, IntWritable, DoubleArrayWritable>{

private double bias_1;
private double bias_2;

//recupera o valor dos das probabilidades j calculadas para cada
moeda
public void configure(JobConf job){
probabilidade_1 = Double.parseDouble(job.get("probabilidade_1"));
probabilidade_2 = Double.parseDouble(job.get("probabilidade_2"));
}
public void map(LongWritable key, Text linha, OutputCollector<IntWritable, DoubleArrayWritable>
output){
String line = value.toString();

double[] caraProbabilidades = new double[2];
caraProbabilidades[0] = probabilidade_1;
caraProbabilidades[1] = probabilidade_2;
//retorna dois vetores que contabilizam os provveis lanamentos
que geraram cara e coroa para cada moeda
DoubleArrayWritable[][] verossimilhancas =
gera_verossimilhancas(line, caraProbabilidades)

try{
output.collect(new IntWritable(1), verossimilhancas[0]);
output.collect(new IntWritable(2), verrossimilhancas[1]);
}catch(Exception e){
System.out.println("erro");
}
}
}
A tarefa de reduce se encarrega de receber as contagens de arremessos de acordo com o nmero da moeda e gerar a
nova probabilidade de P(cara) para cada moeda.
public void reduce(IntWritable moeda, Iterator<DoubleArrayWritable> lancamentos,
OutputCollector<IntWritable, DoubleWritable>output, Reporter reporter){
double numero_caras = 0;
double numero_coroas = 0;
while(jogadas.hasNext()){
DoubleWritable[] lancamento = (DoubleWritable[])
94
lancamentos.next().get();
numero_caras += lancamento[HEADS].get();
numero_coroas += lancamento[TAILS].get();
}
try{
Double probabilidade_cara =
numero_caras/(numero_caras+numero_coroas);
output.collect(moeda, new DoubleWritable(probabilidade_cara));
}catch(Exception e){
System.out.println("erro no reduce");
}
}
O nosso driver por onde inicia-se a execuo do programa. Uma vez iniciada, a cada iterao testa-se a
convergncia, isto , se a diferena entre os valore de P(cara) de cada uma das novas moedas entre iteraes menor
que certo limiar.
public static void main(String[] args) throws Exception{
//recupera probabilidades a partir de arquivo com o mesmo nome do
argumento
double probabilidade_1 = recupera_probabilidade("probabilidade_1");
double probabilidade_2 = recupera_probabilidade("probabilidade_2");
while(true){
JobConf conf = new JobConf(EMD.class);
conf.setJobName("EM");

//seta probabilidades no JobConf
job.set("probabilidade_1", Double.toString(probabilidade_1));
job.set("probabilidade_2", Double.toString(probabilidade_2));

//configuracoes de rotina
conf.setOutputKeyClass(IntWritable.class);
conf.setOutputValueClass(DoubleWritable.class);
conf.setMapOutputKeyClass(IntWritable.class);
conf.setMapOutputValueClass(DoubleArrayWritable.class);

conf.setMapperClass(Map.class);

conf.setReducerClass(Reduce.class);

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

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

JobClient.runJob(conf);

95
double prob_1_old = probabilidade_1;
double prob_2_old = probabilidade_2;
probabilidade_1 = recupera_probabilidade("probabilidade_1");
probabilidade_2 = recupera_probabilidade("probabilidade_2");
//testa convergencia
if(Math.abs(probabilidade_1 - prob_1_old)>0.000001 &&
Math.abs(probabilidade_2 - prob2_old)>0.000001)
break
}
}
Avaliao
Carga de Trabalho
A carga de trabalho foi gerada artificialmente. A diviso do trabalho feita com base no conjunto de lanamentos e,
portanto, um grande nmero de conjuntos de lanamentos foram gerados aleatoriamente para duas moedas, uma com
P(cara) = 0.7 e outra com P(cara) = 0.4. O Objetivo conseguir agrupar os conjuntos de lanamentso nos seus
prprios cluster, numa mistura gaussiana, descobridno os parmetros P(cara) de cada moeda.
Foram gerados 100,000,000,000 que foram escritos em um arquivo de texto. Cada linha representa um lanamento
contendo dois inteiros: o nmero de caras e o nmero de coroas. A representao de todos os lanamentos utilizando
dois inteiros de 4 bytes para cada lanamento utiliza aproximadamente 0.75Gb.
Avaliao Experimental
A avaliao foi feita inicialmente sobre um single-node cluster rodando localmente e depois se expande para o
cluster com quatro mquinas, sendo um namenode que tambm funciona como datanode. O arquivo contendo a lista
de lanamentos carregada inicialmente de forma a j ser particionada entre os ns antes da execuo das tarefas.
Mede-se o tempo de execuo at a convergncia para uma verso serial da aplicao e compara-se com os
resultados alcanados com o algoritmo distribudo.
Anlise de Resultados
[andamento]
Para um n o processamento local.
Tempo gasto para processar 100,000,000 pontos
no EM
96
Note que o speedup quase de 2 vezes aumentando para dois ns, mas, no entanto, ele no to grande
aumentando-se mais ns. Isso se deve ao fato o tamanho da ram da mquina (2Gb) ser o fato limitante para
processamento dos 100,000,000 pontos. Dividindo-se o workload em duas mquinas, divide-se tambm a quantidade
de memria necessria para o processamento. No entanto, a memria deixa, ento , de ser o principal gargalo.
Anlise Crtica
A vantagem do uso do Hadoop foi em dividir os dados desde o incio utilizando o sistema distribudo e seguir a
filosofia de "mandar o processamento para onde temos dados". No entanto, se tvessemos que distribuir os dados
enquanto exetvamos o algoritmo de EM, provavelmente no teramos obtidos resultados to bons, uma vez que a
rede seria um gargalo para transmisso de dados.
[1] http:/ / www. wired. com/ dangerroom/ 2012/ 11/ ff-the-manuscript/ all/
[2] (http:/ / ai. stanford. edu/ ~chuongdo/ papers/ em_tutorial. pdf), What is the expectation maximization algorithm? by Chuong B Do and
Serafim Batzoglou
[3] https:/ / archive. is/ 20130422234439/ 4.bp.blogspot. com/ -6Rp1CLypNyo/ T-z2Gok0DII/ AAAAAAAAAOE/ RYCmUGk_2Cs/ s1600/
figure. jpg
[4] (http:/ / hadoop. apache. org/ ),Hadoop File System (HFS)
[5] (http:/ / research. google.com/ archive/ gfs.html) The Google File System, by Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung
[6] (http:/ / www.openstack. org/ ), OpenStack
Agregao eficiente de dados temporais
Introduo
O objetivo deste documento apresentar o projeto da disciplina Processamento de Dados Massivos do curso de
mestrado em Cincia da Computao. O projeto consiste no projeto, implementao e avaliao experimental de um
arcabouo para agregao eficiente em dados temporais em bancos de dados no relacionais.
Motivao e Justificativa
A tecnologia NoSQL idealizada pelos desenvolvedores da Web 2.0 e comunidades que perceberam que os bancos
de dados relacionais no so ideais para o gerenciamento de sites de redes social em tempo real onde os dados so
volumosos e heterogneos(Lee, Tang, and Choi 2012).
Especificamente, NoSQL se refere classe de sistemas de armazenamento de dados que significativamente
diferente dos bancos de dados relacionais convencionais. Por exemplo, NoSQL no exige esquema pr-definido,
relacionamento e chaves. Consultas de junes tambm no so suportadas.
Bancos de dados NoSQL so de baixo custo, sem esquema rgido e horizontalmente escalveis para novos recursos
computacionais sobre demanda, essa escalabilidade horizontal tambm conhecida como sharding. Os bancos
NoSQL podem ser dos tipos:
(i) Key/Value, que simplesmente o armazenamento de vrias chaves e um valor para cada uma delas;
(ii) Wide column store, que um armazenamento inspirado no Big Table da Google e suporta vrias linhas, colunas e
sub colunas;
(iii) Document store, onde os dados so armazenados em formas de documentos JSON ou similares; e
(iv) Graph store, que armazenam grafos e fornecem meios de navegao no grafo.
Todos esses tipos so paradigmas diferentes dos bancos relacionais(Cattell 2011). Especificamente nos bancos de
dados de chave-valor (key/value) orientado a documentos (Document store), os dados so armazenados em colees
e cada coleo contm um ou mais documentos. Comparando com bancos de dados relacionais, colees so
97
anlogas s tabelas e documentos so anlogos aos registros (linhas da tabela).
As tecnologias para bancos de dados NoSQL tm evoludo constantemente. Porm, ainda no existe suporte a
consultas temporais. Bancos de dados temporais um tema relevante da rea de Bancos de Dados, estando bem
consolidado e exaustivamente discutido nos mais diversos contextos (bancos de dados relacionais, orientado a
objetos, XML, e afins). Por exemplo, frequentemente aparecem situaes em que necessrio manter o histrico de
como os registros mudam com o tempo. Bancos de dados temporais tradicionais resolvem esse problema e fornecem
maneiras eficientes de consultar os dados temporais atravs da linguagem de consulta TSQL2(R. T. Snodgrass
1995).
Um dado temporal pode ser unitemporal ou bitemporal. Um dado unitemporal armazena a informao do perodo em
que o dado existe no banco de dados temporal. O dado bitemporal alm de armazenar o perodo em que o dado
existe, tambm armazena o perodo em que ele vlido. Dessa forma, os dados bitemporais permitem que haja um
dado que exista no banco de dados em um determinado perodo mas no seja vlido neste mesmo perodo. Tanto os
dados unitemporais quanto os bitemporais podem ser implementados como uma linha em uma tabela de um banco de
dados relacionais(Johnston and Weis 2010). A Figuraabaixo ilustra a diferena entre esses tipos.
LINK PARA FIGURA
[1]
Uma tabela no temporal pode ser mapeada para o modelo unitemporal atravs da adio de dois meta campos, bd e
ed, para cada linha. bd indica a data inicial da qual a linha existe e ed indica a data final. A chave primria, pk, da
nova tabela composta pela chave primria da tabela no temporal e pelos novos campos bd e ed. Assim, uma linha
da tabela no temporal pode ter vrias verses na tabela unitemporal, cada uma delas representa o dado em um
perodo diferente de tempo. De maneira anloga, uma tabela no temporal pode ser mapeada para o modelo
bitemporal atravs da adio de quatro meta campos bd1, ed1, bd2 e ed2. Neste caso, bd1 e ed1 indica o perodo em
que o dado existe e bd2 e ed2 indica o perodo em que o dado vlido.
At agora, as implementaes mais famosas de bancos de dados temporais foram escritas para bancos de dados SQL
ou XML(Wang and Zaniolo 2008)(Wang, Zaniolo, and Zhou 2008). Neste projeto, introduzimos funes temporais
para um banco de dados NoSQL orientado a documentos (schemaless). Esse novo banco de dados traz grandes
benefcios para a rea de bancos de dados e significa um avano nos bancos de dados NoSQL pois permite unir todas
as vantagens e tendncias dos bancos NoSQL com as vantagens de um banco de dados temporal. Dessa forma, torna
possvel, por exemplo, lidar com grandes volumes de dados temporais atravs de fcil particionamento horizontal
usufruindo de toda a flexibilidade de utilizar em esquema no rgido, que pode sofrer mutaes com o tempo se
adequando ao contexto do tempo em que o dado existe.
Com relao implementao das caractersticas temporais, existem algumas questes que os gerenciadores de
bancos de dados precisam resolver. Regras de restrio de integridade referencial (chave estrangeira) so um pouco
mais complexas, quando um registro removido em cascata em bancos de dados temporais relacionais. Neste caso,
registros em estados antigos da base podem referenciar o dado atual a ser removido; tais registros no podem ser
removidos em cascata uma vez que sero necessrios para consultar um estado antigo da base. Essas questes de
restrio de integridade no so um problema para bancos de dados NoSQL orientados a documentos porque esse
tipo de banco no suporta chaves estrangeiras.
Outra questo relevante na implementao de um banco de dados temporal a eficincia das consultas de agregao,
que normalmente so caras porque precisam de relacionar os dados recuperados na consulta. Por exemplo, suponha
um banco de dados de funcionrios, a tarefa de calcular a mdia do salrio dos funcionrios para cada departamento
custosa. necessrio recuperar todos os funcionrios, agrupar por departamento, em seguida somar os valores dos
salrios por grupo e dividir pelo nmero de funcionrios de cada grupo. Em um banco de dados temporal, o custo
ainda maior porque antes de realizar esses procedimentos necessrio descobrir quais registros do banco so
pertinentes no perodo de tempo especificado. O banco de dados temporal tem de ser bem projetado para consultar o
mnimo de registros possvel nessas consultas para ter um bom desempenho.
98
Tendo em vista os benefcios dos bancos NoSQL e a tendncia da Web em us-los para sistemas de tempo real e alta
disponibilidade, percebe-se que essa tecnologia tem grande potencial e um tema relevante e atual. Apesar disso,
ainda h uma carncia de funcionalidades temporais nesses bancos. Funcionalidades temporais so necessrias em
diversos cenrios, por exemplo, em servios de auditoria (quando frequentemente se faz necessrio analisar dados
passados atravs de consultas complexas, como as que envolvem agregao). Um banco de dados temporal viabiliza
essa anlise de maneira muito prtica. Por isso, desenvolvimento de mtodos eficazes para consultar e agregar dados
temporais em ambientes NoSQL mostra-se necessrio.
Objetivos Gerais e Especficos
O objetivo geral deste projeto consiste em desenvolver um arcabouo em um ambiente NoSQL, com dados
orientados a documentos, para permitir realizar consultas complexas, como de agregao, em dados temporais de
forma eficiente.
O arcabouo foi montado a partir de um banco de dados NoSQL existente e, portanto, os objetivos especficos do
projeto foram:
(i) Elaborar um modelo de armazenamento de dados e processamento de consultas que permita manter o histrico do
banco de dados em qualquer momento passado do tempo.
(ii) Implementar um mecanismo que garanta a consistncia dos dados temporais de forma que os intervalos de tempo
armazenados em diversos registros sempre formem uma linha contnua.
(iii) Definir uma interface de consulta temporal e implementar um proxy para o driver do banco de dados para aceitar
consultas temporais e convert-las para consultas nativas utilizando os meta campos temporais definidos no modelo
de armazenamento de dados definido no objetivo (i).
(iv) Realizar o sharding do banco de dados de forma a garantir a eficincia das consultas temporais mesmo em bases
grandes e em cenrios de agregao.
Reviso Literria
Este captulo revisa a literatura relevante relacionada a bancos de dados temporais e bancos de dados NoSQL. Ao
final, discutido como este trabalho se compara aos trabalhos citados.
Banco de Dados Temporais
Um banco de dados convencional apaga o dado antigo quando atualizado. Assim, apenas os dados atuais residem
no banco. Em algumas aplicaes no apropriado descartar os dados antigos. Nesses casos, necessrio associar
valores de tempo aos dados para indicar seus perodos de validade(Codd 1983). A incorporao de tempo impe
uma ordem cronolgica dentro do banco de dados. Esses bancos so chamados de bancos de dados temporais. O
tempo tem papel importante no processamento dos dados(Bolour et al. 1982).
Jones, et al.(S. Jones and Mason 1980)(Susan Jones, Mason, and Stamper 1979) e Snodgrass(R. Snodgrass 1987)
desenvolveram modelos para bancos de dados temporais. Eles desenvolveram linguagens de consulta poderosas e as
implementaram. As ideias bsicas deles sobre os fundamentos do modelo so essencialmente iguais. Eles
consideram o tempo de incio e tempo de trmino como atributos especiais. Esses atributos especiais so usados para
consultar o banco de dados em diferentes estados do tempo.
Snodgrass(R. Snodgrass 1987) fornece uma semntica para uma linguagem temporal chamada TQUEL que prov
processamento de consultas temporais usuais atravs dos campos de incio e trmino. Ben-Zvi(Ben-Zvi 1982) e
Gadia(Gadia 1988) propem modelos diferentes para bancos de dados temporais e definem a lgebra relacional para
as consultas de seus modelos.
99
Banco de dados NoSQL
Sistemas de gerenciamento de bancos de dados hoje so a tecnologia predominante para armazenar dados
estruturados na web em aplicaes de negcios. Desde 1970(Codd 1983) esses armazenamentos de dados, baseando
em clculos relacionais e fornecendo facilidades ad hoc para consultas SQL(Chamberlin and Boyce 1974), vm
sendo adotados frequentemente e so entendidos como a nica alternativa para armazenamento de dados acessvel
para mltiplos clientes de forma consistente.
Apesar de terem surgido abordagens diferentes nesses anos como bancos de dados XML, essas tecnologias nunca
foram adotadas to amplamente no mercado como foram os RDBMs.(Pokorny 2011). Nos ltimos anos, entretanto,
o pensamento "one size fits all" fez com que a forma de armazenamento de dados fosse repensada, tanto no meio
acadmico quanto no meio empresarial. Isso encadeou o surgimento de uma grande variedade de bancos de dados
alternativos. Essas alternativas so frequentemente generalizadas como NoSQL, que tem como caracterstica usarem
esquemas no relacionais(Obasanjo 2009).
Apesar de ser uma tecnologia relativamente nova, NoSQL significativo por ser uma abordagem frequente de
bancos de dados para computao em nuvem e em sistemas de grande volumes de dados(Lee, Tang, and Choi
2012). A alta taxa de adoo dos bancos NoSQL em sistemas de computao em nuvem pode ser explicada
principalmente pela alta facilidade de fazer sharding nesses bancos, o que possibilita dividir o armazenamento dos
dados em vrias mquinas de maneira mais simples do que nos bancos de dados relacionais, que normalmente
exigem uma remodelagem agressiva do esquema para realizar o sharding.
Enquadramento deste trabalho no Estado da Arte
Conforme apresentado neste captulo, estudos sobre banco de dados temporais esto bem consolidados e estudos de
banco de dados no relacionais tm sido realizados em diversos trabalhos. Entretanto, as duas reas no so
estudadas em conjunto. Especificamente, este trabalho teve por finalidade definir e implementar um arcabouo de
banco de dados temporal em uma estrutura de dados NoSQL orientada a documentos. importante ressaltar que esta
a primeira vez que esta combinao de estudos foi feita. Obteve-se um arcabouo com alta escalabilidade, fcil
particionamento horizontal (sharding), modelo de dados flexvel (schemaless) e alto desempenho em consultas
temporais de agregao.
Desenvolvimento
A proposta deste trabalho consiste em criar um banco de dados temporal NoSQL orientado a documentos. O ponto
de partida para este trabalho foi o banco de dados open source MongoDB. A implementao foi feita atravs de um
Proxy do driver de Python (pymongo) para o MongoDB.
Proxy do banco de dados
As rotinas de UPDATE, DELETE e INSERT foram reescritas para no apagarem os dados antigos em um comando
de atualizao ou remoo. Alm disso as novas rotinas so responsveis por preencher meta campos nos
documentos para indicar o perodo de validade de cada dado.
Os meta campos tm como objetivo principalmente de viabilizar o uso do conceito de temporalidade no banco de
dados. Para isso, so definidos os campos:
_id_pai: o id do documento com a ltima verso dos dados em questo.
_inicio: data em que o documento foi inserido no banco.
_fim: data em que o documento passou a ser invlido.
Junto adio meta campos, a modificao de rotinas possibilita o funcionamento proxy do banco de dados junto s
abstraes da temporalidade em questo.
100
A rotina do UPDATE, por exemplo, foi substituida por:
Atualiza a data de _fim para a data atual.
Clona o documento no banco e realiza as atualizaes nesse novo documento.
A data de incio do documento clonado passa a ser a data atual e a data de fim passa a ser nula.
O _id documento original atribudo ao campo _id_pai do documento clonado.
No exemplo de um sistema de banco de dados de um empresa, teramos ento o seguinte cenrio: um funcionrio,
Joo Silva, cujo salrio inicial era de 1.000, teve o valor aumentado para 2000 no dia 13/12/2012. No banco de
dados, o documento que armazena os dados do salrio do funcionrio Joo Silva passa por um operao de
UPDATE, que segue toda lgica explicada anteriormente.
Desta forma, o estado do banco passa de:
... {
nome: 'Joao Silva',
salario: '1.000,00', ...,
_id: 1,
_id_pai: 1,
_inicio: 01/10/2012,
_fim: 12/12/2012
}
Para:
{
nome: 'Joao Silva',
salario: '2.000,00', ...,
_id: 2,
_id_pai: 1,
_inicio: 13/12/2012,
_fim: NULL
}, ...
Linguagem de consulta
Foi definida uma linguagem de consulta temporal para o banco de dados e o Proxy do MongoDB foi especializou o
mtodo de consulta para fazer o parser desta nova linguagem e convert-la para uma consulta nativa que utiliza os
meta campos de validade dos dados.
Foi definido um novo operador $dbDate que aceita as seguintes sintaxes:
{$dbDate: <date>}: faz uma query no estado do banco em uma data especfica.
{$dbDate: {$gte: <date>, $lte: <date1>}}: faz uma query em estados de um intervalo de tempo especfico.
Considere os seguintes exemplos:
1. db.empregados.find({salario: {$gt: 1000}, $dbDate: 01/01/2012})
2. db.empregados.find({salario: {$gt: 1000}, $dbDate: {$gte: 01/01/2012, $lte: 31/12/2012}})
A consulta 1 seleciona todos os empregados com o salrio maior do que 1.000,00 no dia 01/01/2012. J a conulta 2
seleciona todos os empregados que tiveram o salrio maior do que 1.000,00 em algum momento do ano de 2012.
O Proxy do mtodo de consulta ir interpretar essas consultas e transform-las respectivamente nas seguintes
consultas:
101
1. db.empregados.find({salario: {$gt: 1000}, _inicio: {$lte: 01/01/2012}, $or: [{_fim: {$gte: 01/01/2012}}, {_fim: null}]})
2. db.empregados.find({salario: {$gt: 1000}, _inicio: {$lte: 31/12/2012}, $or: [{_fim: {$gte: 01/01/2012}}, {_fim: null}]})
O operador $dbDate foi transformado em operadores de nativos do MongoDB e as consultas passaram a usar os
meta campos temporais de forma trasparente para o usurio. Na primeira consulta, a data de incio deve ser menor ou
igual a data do estado do banco desejada. A data de fim deve ser maior do que a data desejada ou igual a nulo. A
segunda consulta foi elaborada de forma anloga.
Uma consulta sem o operador $dbDate tambm transformada. Considere a consulta abaixo.
db.empregados.find({salario: {$gt: 1000}})
Por definio, uma cosulta sem o operador $dbDate considera apenas os registros do estado atual do banco, por isso,
a consulta acima transformada para a seguinte:
db.empregados.find({salario: {$gt: 1000}, _fim: null})
Sempre que uma consulta pesquisa pelo campo _id necessrio transformar a query para utilizar o campo _id_pai, j
que a cada atualizao de um registro implica na criao de um novo documento com um novo _id. O campo _id_pai
recebe o valor do _id original para indicar qual o documento referenciado.
Dessa forma, a seguinte consulta:
db.empregados.findOne({_id: ObjectId(1111111111111)})
transformada para:
db.empregados.findOne({_id_pai: ObjectId(1111111111111)})
Experimentos
Por fim, o arcabouo desenvolvido foi testado com grandes dados particionados horizontalmente em vrias mquinas
e agrupados pelos meta campos de validade dos documentos. Nesta etapa final, a metodologia proposta foi avaliada
experimentalmente.
Base de dados
A base de dados utilizada de um software de vendas de uma empresa de elevadores. Cada possvel venda
representada por um documento da coleo de elevadores. Esses documentos sofrem atualizaes dirias com dados
do local de instalao do elevador, o registro de ligaes feitas para o cliente, a possibilidade de fechamento da
venda e vrios outros campos que sero omitidos no exemplo de documento abaixo em prol da didaticidade.
{
"_id" : ObjectId("5081f8eef5a40f129d0043c8"),
"_id_pai" : ObjectId("5081f8eef5a40f129d0043c8"),
"_inicio" : ISODate("2012-06-20T11:14:40.521Z"),
"_fim" : ISODate("2012-06-30T15:20:12.189Z"),
"preco_final" : 10000,
"possibilidade_de_fechamento" : "alta",
"fase" : "Proposta",
"localinstalacao" : {
"complemento" : "",
"engenheiro_responsavel" : "",
"bairro" : "",
102
"cidade" : {
"uf" : "MG",
"id" : ObjectId("5081f8e7f5a40f129d0005b7"),
"nome" : "Belo Horizonte"
},
"logradouro" : "",
"observacoes" : "",
"numero" : "",
"distancia_da_base" : "",
"situacao" : "",
"telefone_local" : "",
"tipo_do_estabelecimento" : "",
"cep" : ""
},
"nome_do_estabelecimento" : "Residencial Miguel Prado",
"vendedor" : {
"username" : "joao.silva",
"fullname" : "Joo Silva"
},
...
}
O documento acima uma representao parcial de uma possvel venda de elevador. No contexto da empresa de
vendas, necessrio fazer consultas no estado atual do banco para acompanhar as vendas e tambm necessrio
fazer consultas temporais para analisar a evoluo da venda com o tempo e fazer minerao de dados para obter
padres de evoluo de venda que levam ao fechamento da venda ou no.
A base de dados tem outras colees alm da de elevador, mas nos exemplos mostrados neste trabalho vamos focar
na coleo de elevador apenas.
Esta coleo possui 1.978.201 documentos representando 48.117 possibilidades de vendas nicas. Portanto, cada
venda tem aproximadamente 41,1 alteraes. O tamhno ocupado pela coleo de 25,43 GB.
Particionamento de dados e ndices
Os dados foram particionados em trs mquinas virtuais, cada uma com 8GB de RAM e 10GB de HD. O campo de
particionamento foi o _fim. Isso possibilita que todos os dados atuais da base (que tem o campo _fim nulo) fiquem na
mesma mquina, proporcionando um ganho de performance para consultas no estado atual da base.
Foram criados ndices nos campos de _inicio, _fim e _id_pai. Esses ndices so usados em praticamente todas as
consultas temporais e otimizam as consultas em estados antigos da base de dados.
Resultados
Para testar a performance do banco de dados, foram selecionadas duas consultas de agregao.
1. db.elevador.aggregate(
{
$match: {_fim: null},
$group: {
_id: '$xxx',
avg: {'$avg': '$preco_final'},
103
}
}
);
2. db.elevador.aggregate(
{
$match: {
$or: [{_fim: {$gte: ISODate("2012-06-20T00:00:00.000Z")}}, {_fim: null}],
_inicio: {$lte: ISODate("2012-06-20T00:00:00.000Z")},
$group: {
_id: '$xxx',
avg: {'$avg': '$preco_final'},
}
}
);
A primeira consulta calcula a mdia dos preos dos elevadores no estado atual da base. A segunda consulta calcula a
mdia dos preos dos elevadores no estado da base do dia 20/06/2011.
A primeira consulta executou em 0,922 segundos e pesquisou 48.117 documentos quando executada em um
ambiente de uma nica mquina. Quando executada em um ambiente de 3 mquinas, foram gastos 0,987 segundos e
48.117 documentos foram consultados. O grfico abaixo mostra este resultado.
LINK PARA O GRAFICO 1 (EPS)
[2]
LINK PARA O GRAFICO 1 (PNG)
[3]
O tempo de execuo da primeira consulta em ambiente com vrias mquinas e ambiente com uma mquina apenas
quase igual porque uma consulta no estado atual da base e o particionamento horizontal garante que os dados
atuais fiquem agrupados na mesma mquina.
A segunda consulta executou em 1.291 segundos e pesquisou 453.839 documentos quando executada em um
ambiente de uma nica mquina. Quando executada em um ambiente de 3 mquinas, foram gastos 1.677 segundos e
453.839 documentos foram consultados. O grfico abaixo mostra este resultado.
LINK PARA O GRAFICO 2 (EPS)
[4]
LINK PARA O GRAFICO 2 (PNG)
[5]
O tempo de execuo da consulta temporal baixo porque os ndices nos meta campos _inicio e _fim garantem que o
mnimo de decoumentos possveis sejam consultados para simular o estado passado do banco de dados.
Concluso
Este trabalho introduziu funcionalidades temporais em bancos de dados NoSQL de forma escalvel. possvel
trabalhar com grande qantidade de dados, manter o histrico de atualizaes sobre eles e consultar estados passados
dos dados de maneira eficiente.
Como trabalhos futuros pretende-se implementar as funcionalidades temporais diretamente no cdigo fonte de um
banco de dados NoSQL ao invs de fazer um Proxy. Essa implementao trar mais ganho de performance para as
consultas.
104
Referncias
Ben-Zvi, Jacov. 1982. The time relational model.
Bolour, A., T. L. Anderson, L. J. Dekeyser, and Harry K. T. Wong. 1982. The Role of Time in Information
Processing: A Survey. SIGMOD Record 12: 2750. http:/ / dblp. uni-trier. de/ db/ journals/ sigmod/ sigmod12.
html#BolourADW82
[6]
.
Cattell, Rick. 2011. Scalable SQL and NoSQL data stores. SIGMOD Rec. 39 (may): 1227.
doi:10.1145/1978915.1978919. http:/ / doi. acm. org/ 10. 1145/ 1978915. 1978919
[7]
.
Chamberlin, Donald D., and Raymond F. Boyce. 1974. SEQUEL: A structured English query language. In
Proceedings of ACM SIGFIDET workshop on Data description, access and control, 249264. New York, NY, USA:
ACM. doi:10.1145/800296.811515. http:/ / doi. acm. org/ 10. 1145/ 800296. 811515
[8]
.
Codd, E. F. 1983. A relational model of data for large shared data banks. Commun. ACM 26: 6469.
[9]
.
Gadia, Shashi K. 1988. A homogeneous relational model and query languages for temporal databases. ACM Trans.
Database Syst. 13: 418448. doi:10.1145/49346.50065. http:/ / doi. acm. org/ 10. 1145/ 49346. 50065
[10]
.
Johnston, Tom, and Randall Weis. 2010. Managing Time in Relational Databases: How to Design, Update and
Query Temporal Data. Morgan Kaufmann.
Jones, S., and P. J. Mason. 1980. Handling the Time Dimension in a Data Base. In International Conference on
Databases, 6583.
Jones, Susan, Peter Mason, and Ronald K. Stamper. 1979. LEGOL 2.0: A relational specification language for
complex rules. Inf. Syst. 4: 293305.
Lee, Ken Ka-Yin, Wai-Choi Tang, and Kup-Sze Choi. 2012. Alternatives to relational database: Comparison of
NoSQL and XML approaches for clinical data storage. Computer Methods and Programs in Biomedicine.
doi:10.1016/j.cmpb.2012.10.018. http:/ / www. sciencedirect. com/ science/ article/ pii/ S0169260712002805
[11]
.
Obasanjo, Dare. 2009. Building scalable databases: Denormalization, the NoSQL movement and Digg. http:/ /
www. 25hoursaday. com/ weblog/ 2009/ 09/ 10/
BuildingScalableDatabasesDenormalizationTheNoSQLMovementAndDigg. aspx
[12]
.
Pokorny, Jaroslav. 2011. NoSQL databases: a step to database scalability in web environment. In Proceedings of
the 13th International Conference on Information Integration and Web-based Applications and Services, 278283.
New York, NY, USA: ACM. http:/ / doi. acm. org/ 10. 1145/ 2095536. 2095583
[13]
.
Snodgrass, Richard. 1987. The temporal query language TQuel. ACM Trans. Database Syst. 12: 247298.
[14]
.
Snodgrass, Richard T., ed. 1995. The TSQL2 Temporal Query Language. Kluwer.
Wang, Fusheng, Carlo Zaniolo, and Xin Zhou. 2008. ArchIS: an XML-based approach to transaction-time temporal
database systems. VLDB J. 17: 14451463. doi:http:/ / dx. doi. org/ 10. 1007/ s00778-007-0086-6.
Wang, Fusheng, and Carlo Zaniolo. 2008. Temporal queries and version management in XML-based document
archives. Data and Knowledge Engineering 65: 304324. doi:http:/ / dx. doi. org/ 10. 1016/ j. datak. 2007. 08. 002.
105
Referncias
[1] http:/ / homepages.dcc. ufmg. br/ ~eduardo.barbosa/ pdm_wikilivro/ data-organization. pdf
[2] http:/ / homepages.dcc. ufmg. br/ ~eduardo.barbosa/ pdm_wikilivro/ grafico1. eps
[3] http:/ / homepages.dcc. ufmg. br/ ~eduardo.barbosa/ pdm_wikilivro/ grafico1. png
[4] http:/ / homepages.dcc. ufmg. br/ ~eduardo.barbosa/ pdm_wikilivro/ grafico2. eps
[5] http:/ / homepages.dcc. ufmg. br/ ~eduardo.barbosa/ pdm_wikilivro/ grafico2. png
[6] http:/ / dblp. uni-trier.de/ db/ journals/ sigmod/ sigmod12. html#BolourADW82
[7] http:/ / doi. acm.org/ 10. 1145/ 1978915. 1978919
[8] http:/ / doi. acm.org/ 10. 1145/ 800296. 811515
[9] http:/ / doi. acm.org/ 10. 1145/ 357980. 358007
[10] http:/ / doi. acm. org/ 10. 1145/ 49346. 50065
[11] http:/ / www.sciencedirect.com/ science/ article/ pii/ S0169260712002805
[12] http:/ / www.25hoursaday. com/ weblog/ 2009/ 09/ 10/ BuildingScalableDatabasesDenormalizationTheNoSQLMovementAndDigg. aspx
[13] http:/ / doi. acm. org/ 10. 1145/ 2095536. 2095583
[14] http:/ / doi. acm. org/ 10. 1145/ 22952. 22956
Classificao associativa incremental (LAC)
Classificao uma tcnica constantemente aplicada em Knowledge Discovery in Databases (KDD) no processo de
minerao de dados. O KDD um processo de extrao de conhecimento de bancos de dados, em geral, bancos de
dados histricos. Um dos exemplos mais conhecidos a respeito de KDD sobre a descoberta de que aos finais de
semana a venda de fraldas estava relacionadas a venda de cervejas em uma grande rede de supermercados dos
Estados Unidos.
Porm, quando fala-se de Big Data considera-se os dados em curtos espaos de tempo e em grande quantidade, ou
seja, no so minerados bancos de dados histricos, em relao a vrios meses, e sim bancos de dado semanais,
dirios. Assim, necessrio que as tcnicas de minerao de dados e aprendizado de mquina aplicadas em Big Data
sejam escalveis para trabalhar com grandes volumes de dados e em tempo prximo de real.
Sendo assim, aplicar classificao no contexto de big data necessita de adaptao dos algoritmos quanto a
dependncia de dados, overhead de comunicao de rede, etc. Realiza essas adaptaes classificao torna-se uma
importante ferramenta da extrao de conhecimento em big data.
Diante este desafio, a adaptao de algoritmos de classificao para big data, este trabalho direciona a adaptao do
algoritmo Lazy Associative Classification (LAC) para um ambiente distribudo. O LAC um algoritmo que cria
modelos de classificao sob demanda para cada dado a ser classificado. Esta caracterstica cria uma possibilidade de
paralelismo, uma vez que pode-se distribuir os dados a serem classificados para diversos ns de computao para
que sejam instanciados diversos classificadores LAC com um mesmo conjunto de exemplos.
Alm disso o LAC possui algumas caractersticas que permitem a otimizao para a realizao da classificao de
dados que reduzem a quantidade de acessos aos conjunto de exemplos, fornecendo a mesma taxa de acerto.
Portanto, este trabalho tem como objetivo o aproveitamento de tais caractersticas para o desenvolvimento de um
algoritmo distribudo, chamado Distributed Lazy Associative Classification. A principal caracterstica do LAC
utilizada o cache de regras frequntes que objetiva-se em armazenar as regras de associao mais frequentes
evitando analisar o conjunto de exemplos para re-extra-las. Desta forma o Distributed Lazy Associative
Classification tem por objetivo maximizar o uso deste recurso por meio de agrupamento de dados por similaridade.
A hiptese deste trabalho que ao processar conjuntos de dados de teste aos quais cada conjunto possua instncias
com alta similaridade, a utilizao do cache aumentar. Sumarizando, o que o Distributed LAC assume que quanto
maior a similaridade do conjunto de teste processado, maior a utilizao do cache de regras.
106
Classificao Automtica
Classificao automtica uma tcnica desenvolvida em aprendizado de mquina e minerao de dados. Em se
tratando da rea de aprendizado de mquina, classificao automtica se encaixa em aprendizado supervisionado que
trata-se de um processo que induz uma funo (modelo) inicialmente desconhecida (Mitchel 2006)
[1]
. Isto
feito a partir de um conjunto de dados de exemplo , em que xirepresenta os atributos de um dado e a
varivel resposta referente a classe a que pertence. Tais dados so utilizados para "mostrar" ao algoritmo o
mapeamento das entradas para as sadas desejadas .
Para realizar a induo desta funo os algoritmos de classificao utilizam tcnicas inspiradas em estatstica at em
computao natural (algoritmos genticos, colnias de formigas, etc). Vrios destes algrotimos possuem duas fazes:
treino e classificao. A fase de treino responsvel pela induo da funo que ir classificar dados ainda
desconhecidos. A fase de teste a aplicao de tal funo a cada dado do conjunto de teste os quais so classificados.
Outros algoritmos no possuem a fase de treino separada da fase de classficificao. Este algoritmos so conhecidos
como Lazy ou Sob Demanda. O processo de classificao realizado por estes algoritmos tal que para cada dado do
conjunto de teste construda um modelo de classificao, ou seja, o modelo de classificao construdo sob
demanda para cada dado do teste.
Lazy Associative Classification (LAC)
Lazy Associative Classification (LAC) um algoritmo de classificao associativo proposto por Veloso et al. (2006)
[2]
. LAC um algoritmo no paramtrico baseado em exemplos (conjunto de treinamento), ou seja, o processo de
aprendizado se d pela induo de um modelo de classificao durante a etapa de treino.
De acordo com Veloso et al. (2006)
[2]
LAC no usa nenhuma estratgia para minimizao de erros ou suposies
invlidas sobre a distribuo dos dados. Assim, as regras estradas so aplicadas para descrever os dados e estimar as
probabilidades de uma determinada instncia de teste pertencer a cada classe. O LAC gera, para cada instncia de
teste, um modelo sob demanda durante o processo de treinamento.
A Gerao de modelo sob demanda para cada teste feita extraindo regras de associao que contm apenas os
atributos de usando o conjunto de treinamento. As regras extradas so do tipo , em que um
subconjunto dos atributos de e o rtulo da i-sima classe. Este tipo de regra conhecida como Regra de
Associao de Classe (Class Assocication Rule) (CAR) devido ao fato de que os atributos esto sempre esquerda e
a classe direita na regra. Extradas as regras, a classe de cada ti computada atravs dos votos dados pelas regas. O
LAC utiliza limiares mnimos de suporte e confina para evitar a extrao de regras de associao inteis.
No Algoritmo 1 apresentamos o pseudo-cdigo do LAC que recebe como entrada o conjunto de treinamento e teste,
limiares mnimos de suporte e confincia e um limite mximo para o tamanho das regras extradas. Para cada
instncia tipertencer a cada classe. Na linha 7 atribui-se o rtulo da classe que obteve maior probabilidade tido
conjunto de teste extrado um conjunto de regras de associao que respeite os limiares de suporte, confina e
tamanho da regra (linha 2). Seguindo, entre as linhas 3 6 so computadas as probabilidades da instncia
pertencer a cada classe. Na linha 7 atribui-se o rtulo da classe que obteve maior probabilidade .
Pseudo-cdigo do Lazy Associative
Classification. Adaptado de (Veloso et al.
2006)
[2]
107
Extrao de Regras de Associao e o LAC
A extrao de regras de associao uma tarefa de minerao de dados, tambm conhecida como Minerao de Item
Sets Frequentes. Seu objetivo encontrar conjuntos de itens que possuem correlao em um banco de dados de
transaes.
O conceito de regas fortes de Agrawal et al. (1993)
[3]
deu origem a este tpico de pesquisa. O primeiro algoritmo
para Minerao de Itens Sets Frequentes foi o Apriori proposto por Agrawal e Srikant (1994)
[4]
.
A extrao de regras de associao tem um alto custo computacional, sendo que o algoritmo fora bruta possui
complexidade exponencial. Outros algoritmos foram propostos para este fim, que fazem uso de heursticas de podas
e limitaes de tamanhos de regras, alguns exemplos so o Eclat e FP-growth.
O LAC pode utilizar no processo de induo de regras qualquer algoritmo de minerao de itens sets frequentes.
Contudo para reduzir a dimensionalidade dos dados o LAC aplica antes do processo de extrao de regras a projeo
de dados.
O LAC realiza a projeo de dados do dado de teste sobre o conjunto de exemplos. Em suma, a projeo consiste em
um conjunto de exemplos que obtido depois de remover todos atributos no inclusos na instncia de teste. Um
exemplo apresentado nas Tabelas 1 e 2. Na Tabela 1 apresentado o conjunto de exemplos , composto por 10
exemplos, e a instncia de teste , a ser classificada.
Conjunto de exemplos e instncia de teste.
Adaptado de (Veloso et al. 2006)
[2]
Aps a projeo de sobre o conjunto de exemplos ao qual ser utilizada para a extrao de regras de
associao apresentado na Tabela 2. Percebe-se que de 10 exemplos, restaram apenas 5, reduzindo
consideravelmente a quantidade de exemplos a serem inspecionados.
Conjunto de exemplos projetado em relao a
instncia de teste. Adaptado de (Veloso et al.
2006)
[2]
Aps a projeo de dados o algoritmo de minerao de itens sets frequentes executado. Porm vrias regras so
frequentemente extradas e no eficiente extra-las toda vez que um dado de teste analizado. Assim, o LAC
tambm incorpora um cache de regras frequentes, em que quando uma regra frequente extrada, esta inserida
neste repositrio, reduzindo a quantidade de acesso ao conjunto de exemplos.
O cache do LAC um importante recurso a ser utilizado em um contexto de big data, em que possvel armazenar
modelos de classificao (conjunto de regras) e evitar o re-trabalho de extra-los a cada instncia
108
Distributed LAC - Otimizao de Cache
O Distributed LAC direciona-se a duas frentes: possibilitar a classificao de dados de forma distribuda, tornando o
processamento de grandes bases de dados plausvel; e otimizar o uso do cache de regras implementado no LAC no
trabalho de Veloso et al. (2006).
Para otimizar o uso da cache parte-se do princpio de que para instncias semelhantes, ou seja, aquelas que possuem
vrios atributos com o mesmo valor, so geradas vrias regras em comum. Sendo assim, se for possvel gerar grupos
baseados em similaridade, ao processar esses grupos o princpio anterior satisfeito.
Agrupar dados em grupos uma outra tcnica de aprendizado de maquina e minerao de dados, tambm chamada
de clustering. Outra forma de se gerar grupos similares pode ser escolhendo-se uma instncia aleatriamente e
ordenar o restante por similaridade a esta escolhida. Assim separa-se o conjunto de dados em quantos grupos forem
desejados.
Portanto o Distributed LAC necessita antes de classificar os dados agrup-los. Um esquema, simplificado, pode ser
visto na Figura 1, em que os itens de cores parecidas so agrupados e processados pela mesma CPU. Este o
primeiro passo do algoritmo.
Primeira fase do Distributed LAC.
Quando a CPU acionada para realizar a classificao ocorre processo de treinamento, que no caso do LAC trata-se
de carregar o conjunto de exemplos e criar ndices para facilitar a extrao de regras. A Figura 2 mostra um esquema
de como isso feito.
Segunda fase do Distributed LAC.
O processo mostrado na Figura 2 se repete para cada grupo e o processamento do Distributed LAC finalizado.
Implementao em Hadoop
Map
Cada mapper recebe como entrada um arquivo de texto que contem as instancias de teste a serem processadas. O
formato do arquivo de entrada :
<key>\t<instance>
<key>\t<instance>
.
.
.
<key>\t<instance>
109
Sendo que dentro de um mesmo arquivo todas as instancias possuem a mesma chave, para cada linha a funo de
map realiza o processo de classificao e extrai os dados pertinentes, no nosso caso o nmero de hits e misses da
cache, e os escreve na sada da funo onde sero processados pelas funes de reduce. A seguir apresentamos a
funo de Map:
public void map(Text key, Text value, Context context) throws
IOException, InterruptedException {
String line = value.toString();
try {
Result result =
this.classifier.distributionForInstance(line.split(" "));
context.write(missesText, new IntWritable(result.getMisses()));
context.write(hitsText, new IntWritable(result.getHits()));
} catch (Exception e) {
e.printStackTrace();
}
}
Reduce
O processo de reduce neste caso consiste apenas em somar os nmeros de hits e misses e retornar a soma de cada
um, a seguir apresentamos o implementao utilizada:

public void reduce(Text key, Iterable<IntWritable> results, Context context)
throws IOException, InterruptedException {
int value = 0;
for (IntWritable result : results) {
value += result.get();
}
context.write(key, new IntWritable(value));
}
Decises de Implementao
Evitando a diviso dos arquivos de entrada
Por padro o Hadoop divide cada arquivo de entrada em vrios chunks que so processador por diferentes mappers,
este processo feito para aumentar o grau de paralelismo.
Contudo, este processo no o adequado para nossa aplicao, visto que queremos processar cada arquivo em um
nico mapper desta forma a cache do LAC ser aproveitada adequadamente. Para garantir que cada arquivo seja
processado por apenas um mapper foi extendida a classe de input desejada, no nosso caso
KeyValueTextInputFormat, e sobrecarregamos o mtodo isSplitable() de forma que retornase false.
110
Distribuindo o Classificador
Para que cada mapper possa processar o arquivo com as instncias de teste necessrio que cada mapper possua um
classificador treinado, uma soluo seria antes de realizar o processamento em cada mapper obter o classificador
previamente serializado por meio do HDFS, porm isto pode acarretar em um overhead considervel. Uma
alternativa para este problema copiar o classificador serilizado para cada maquina e assim o mapper acessa o
arquivo localmente. O Hadoop fornece a classe DistributedCache para este tipo de situao, contudo durante nossos
experimentos tivemos vrios problemas com esta funcionalidade, desta forma replicamos a funcionalidade desta
classe por meio de scripts em bash.
Avaliao Experimental
Nesta seo detalhado o processo de experimentao e avaliao da soluo apresentada.
Implementao do LAC
Neste trabalho foi utilizada a implementao do LAC para Weka
[5]
disponvel em http:/ / code. google. com/ p/
machine-learning-dcc-ufmg/
[6]
e impemetada por Gess Dafe.
Neste trabalho foram feitas as seguinte modificaes na implementao do LAC:
Insero de cdigo para contagem de Misses e Hits no Cache de regras;
Criao de um mtodo para treinar o classificador a partir de um Buffer de arquivo e classificar instncias
baseadas em vetores de String.
Conjunto de dados
Nos experimentos realizados foi utilizada uma base de dados textuais de Tweets coletados enter Junho e Outubro de
2010 tendo como foco as eleies presidenciais do Brasil. A ento candidata Dilma Rousseff lanou um perfil no
Twitter durante um anncio pblico e usou esta rede social como uma das principais fontes de informo para seus
eleitores. A campanha atraiu mais de 500.000 seguidores e Dilma foi a segunda pessoa mais citada no Twitter em
2010. Houve segundo turno nas eleies e Dilma Rousseff foi eleita com 56% dos votos.
Foram coletadas 446.724 mensagens referindo Dilma Rousseff no Twitter durante sua campanha, sendo selecionadas
aleatriamente 66.643 destas mensagens para rotulao manual. As mensagens foram rotuladas de forma a traar o
sentimento de aprovao em relao a candidada neste perdo. A aprovao varia consideravelmente devido a vrias
afirmaes polemicas e ataques polticos. O conjunto de dados contm somente mensagens em Portugus com
62.089 termos distintos e cada mensagem foi rotulada em Positivo ou Negativo, resultado em 46.808 mensagens
Positivas e 19.835 Negativas.
Mtodo de Avaliao
O foco deste trabalho maximizar a utilizao do Cache de Regras de Associao utilizado pelo LAC. Sendo assim,
os experimentos realizados visam extrair mtricas que comprovem ou no a maximizao do uso deste recurso. As
mtricas utilizadas para medir quanto o Cache utilizado so a quantidade de Misses e Hits. A primeira mede
quantas regras novas tiveram que ser extradas, uma vez que o padro requerido no foi encontrado. Por outro lado, a
segunda mtrica mede a quantidade de regras que foram utilizadas do Cache.
Com a finalidade de medir a quantidade de Misses e Hits submetemos o Distributed LAC a quatro senrios
diferentes baseados na primeira fase de execuo do algoritmo, o Particionamento de Dados:
1. 1. Particionamento Aleatrio: Este mtodo consiste em particionar de forma aleatria o teste em N grupos de
tamanho iguais. A principal vantagem deste mtodo que cada mapper processa uma quantidade de instancias
iguais, desta forma distribuindo melhor a carga. Contudo este mtodo no leva em conta a cache e pode acabar
gerando um grande nmero de misses na cache;
111
2. 2. Particionamento por Similaridade: Este mtodo consiste na separao do conjunto de testes por meio de
algoritmos de clustering. A principal vantagem deste mtodo que instancias semelhantes gerar regras
semelhantes e portanto maximizar o uso da cache. Porm este mtodo pode gerar clusteres desbalanceados o que
pode acabar se tornando um gargalo;
3. Particionamento por Similaridade com Cortes: Este mtodo consiste na separao do conjunto de testes por meio
de duas etapas. Na primeira etapa separamos o conjunto de testes utilizando algoritmos de clustering. Na segunda
etapa realizamos um processo de corte nos grupos grandes de forma a evitar overhead de rede para transmitir
grupos muito grandes;
4. 4. Particionamento Temporal: A coleo de dados foi obtida atravs da API de Streams do Twitter. Desta forma os
dados naturalmente esto agrupados temporalmente, ou seja, tweets de um mesmo intervalo de tempo possuem
um vocabulrio prximo. Assim, os dados de teste sero ordenados temporalmente e divididos em conjuntos de
tamanhos iguais;
Atravs destes mtodos de particionamento espera-se comprovar que a quantidade de Misses no Particionamento
Aleatrio (1) maior do que nos Particionamentos por Similaridade (2) e (3), pois as instncias processadas em (1)
podero necessitar de conjuntos de regras discrepantes, obrigando a extrao frequente de regras. Assim como os
particionamentos (2) e (3), ao processar o particionamento (4) espera-se conjuntos mais coesos.
Realizamos dois conjuntos de experimentos, em que o primeiro utilizamos o mtodo de experimentao utilizado o
10-folds-cross-validation, para comparar entre os particionamentos (1), (2), (3). Para o particionamento (1) o
conjunto de teste separado aleatriamente na funo Map. Os particionamentos (2) e (3) feito o agrupamento no
conjunto de teste e gerado um arquivo para cada grupo. No caso do particionamento (3) os grupos grandes so
divididos em grupos menores. Cada um desses grupos ento carregado e processado em Maps diferentes.
No segundo conjunto de experimentos comparamos o particionamento (1) e (4) e optamos por criar conjuntos de
treino com 60% da base e teste com 40%. Foram criados 5 conjuntos utilizando esta metodologia.
Algoritmos de Agrupamento
Foram avaliados os seguintes algoritmos de agrupamento:
K-means
[7]
DBSCAN
[8]
EM
[9]
Em testes preliminares o que apresentou melhores resultados, no nosso caso gerou grupos mais balanceados foi o
K-means. Portanto este algoritmo foi utilizado em todos os experimentos subsequentes.
Resultados
Primeira Avaliao
Tempo de Execuo
Este experimento visa medir o desempenho dos mtodos proposto. Como podemos ver o mtodo de agrupamento foi
o pior, isto se deve ao fato dos grupos gerados serem desbalanceados, desta forma a distribuio de carga no igual
entre todas as maquinas do cluster. Enquanto isso o mtodo de gerao de parties aleatrias obteve um bom
desempenho, principalmente quando geramos um arquivo para cada processador do cluster e piorando quando
geramos mais arquivos. Finalmente, o mtodo de agrupamento com cortes apresentou os melhores resultados quando
geramos um grande nmero de arquivos, provavelmente porque apesar de menores os arquivos so mais "coesos" e
tomam proveito da cache. Vale lembrar que o depois de gerar os grupos este mtodo realiza um corte dividindo os
arquivos grandes, desta forma gerando um nmero maior de arquivos a serem processados.
112
Tempos de execuo de cada mtodo
Estatsticas da Cache
Nesta seo medimos o aproveitamento da cache por cada mtodo, como esperado os mtodos que utilizam o
K-means apresentam os melhores resultado enquanto que o mtodo de particionamento aleatrio tende a piorar seus
resultados conforme o nmero de grupos aumenta.
Total de Hits na Cache
Total de Misses na Cache
Tamanhos dos grupos
A seguir apresentamos os dados referentes a distribuio das instancias nos grupos, analisando o tamanho mximo e
mnimo dos grupos gerados pelos mtodos propostos. No grfico que mede tamanho mximo dos grupos gerados
podemos notar que o mtodo de agrupamento por similaridade no boa alternativa, pois no distribui os dados de
forma adequada. Enquanto isso o mtodo de agrupamento com cortes acaba distribuindo melhor as instncias o que
aliado a boa utilizao da cache explica seu bom desempenho nos nossos experimentos.
Cluster Mximo
113
Cluster Mnimo
Segunda Avaliao: Particionamentos (1) e (4)
A avaliao experimental realizada consiste em tomar vantagem da relao temporal da coleo de dados utilizada
como forma de obter particionamentos mais coesos. Realizamos dois tipos de experimentos:
1. 1. LAC Parametrizado: Confiana = 0.01, Suporte = 0.01 e Tamanho Mximo das regras = 3;
2. 2. LAC No Parametrizado: Confiana = 0.00, Suporte = 0.00 e Tamanho Mximo das regras = 3.
O objetivo das duas configuraes verificar se as podas por suporte e confiana aumentam a utilizao do cache de
regras. Na figura a baixo est listado o resultado obtido dos experimentos com as duas configuraes e os dois tipos
de particionamentos (1) e (4).
Relao entre Hit/Miss
Observa-se que ao processar os dados utilizando o particionamento (4) (Particionamento Temporal) a utilizao do
cache aumenta consideravelmente em relao ao particionamento (1). Outro resultado evidente que ao utilizar o
LAC Parametrizado o uso do cache tambm aumenta em relao ao LAC No Parametrizado quando os dados so
processados pelo particionamento (4).
Diante destes resultados pode-se concluir que:
Ao definir valores de confiana e suporte aumenta a utilizao do cache de regras;
Para dados temporais o particionamento (4) aumenta a utilizao do cache independentemente de configurar
valores de Confiana e Suporte para o LAC.
Alm de avaliar a utilizao do cache, neste caso tambm necessrio avaliar o quo preciso o LAC utilizando
Confiana e Suporte. Veloso et al. 2006
[2]
mencionam que no h valores genricos para Confiana e Suporte, sendo
dependente do domnio do dados e da modelagem. Os resutados desta comparao para este trabalho podem ser
visualizados na figura a baixo.
114
Acurcia LAC Parametrizado vs LAC No
Parametrizado
Nota-se que tanto no LAC Parametrizado como no LAC No Parametrizado a acurcia no penalizada ao utilizar o
Particionamento Temporal, desta forma esta estrategia nos oferece uma melhora de desempenho sem implicar em
perda de qualidade dos resultados gerados pelo classificador. Alm disso, como comentado acima os valores para
Confiana e Suporte variam de aplicao para aplicao e resultam em performances diferentes, neste caso
configurar Confiana e Suporte iguais a 0.0 resultou em melhor performance do que a outra configurao.
Concluso
Em este projeto, apresentamos tres estrategias para tornar o LAC um classificador distribuido utilizando o Hadoop e
analisamos diferentes formas de particionar o teste para tentar melhorar otimizar o acesso a cache de regras.
Como nossos experimentos demostram um fator de grande importncia a boa distribuio das instancias em vrios
grupos. Isto aliado a estrategias de agrupamento, por similaridade ou ordenao temporal, pode levar a um melhor
desempenho. Desta forma teremos uma melhor distribuio de carga conjuntamente com um melhor aproveitamento
da cache interna do LAC.
Implementao Utilizada
O cdigo utilizado encontra-se disponivel no github
[10]
.
Referncias Bibliogrficas
[1] Mitchell, T. M. (2006). The discipline of machine learning. Machine Learning, Carnegie Mellon University, School of Computer Science,
Machine Learning Dept., n. July, p. 17, 2006 (http:/ / www. cs. cmu. edu/ ~tom/ pubs/ MachineLearning. pdf),
[2] Veloso, A., Meira Jr., W., and Zaki, M. J. (2006). Lazy associative classification. In Proceedings of the Sixth International Conference on
Data Mining, ICDM 06, pages 645--654, Washington, DC, USA. IEEE Computer Society. (http:/ / dl. acm. org/ citation. cfm?id=1193367),
[3] Agrawal, R.; Imieliski, T.; Swami, A. (1993). Mining association rules between sets of items in large databases. Proceedings of the 1993
ACM SIGMOD international conference on Management of data - SIGMOD '93. pp. 207 (http:/ / dl. acm. org/ citation. cfm?id=170072),
[4] Agrawal, R. and Srikant, R (1994). Fast algorithms for mining association rules in large databases. Proceedings of the 20th International
Conference on Very Large Data Bases, VLDB, pages 487-499, Santiago, Chile, September 1994. (http:/ / dl. acm. org/ citation.
cfm?id=672836),
[5] Mark Hall, Eibe Frank, Geoffrey Holmes, Bernhard Pfahringer, Peter Reutemann, Ian H. Witten (2009); The WEKA Data Mining Software:
An Update; SIGKDD Explorations, Volume 11, Issue 1. (http:/ / dl. acm. org/ citation. cfm?id=165627),
[6] Machine Learning Group UFMG (http:/ / code.google.com/ p/ machine-learning-dcc-ufmg/ ),
[7] http:/ / en. wikipedia. org/ wiki/ K-means_clustering
[8] http:/ / en. wikipedia. org/ wiki/ DBSCAN
[9] http:/ / en. wikipedia. org/ wiki/ Expectation%E2%80%93maximization_algorithm
[10] https:/ / github. com/ rloliveirajr/ BigDataML
Entropia de Shannon em redes de contedo categorizado
115
Entropia de Shannon em redes de contedo
categorizado
Descrio da Aplicao
Entropia de Shannon uma medida de imprevisibilidade em uma varivel aleatria
[1]
, que quantifica o valor
esperado da informao contida na mensagem. Esta mtrica, basicamente nos diz o quo previsvel o contedo
avaliado. Valores prximos de 0 indicam grande previsibilidade enquanto o contrrio sugere um comportamento
mais aleatrio. Extrapolamos este conceito, no intuito de quantificar o quo especialista ou generalista so usurios
de uma rede na qual o contedo gerado por eles pre-categorizado. A aplicao aqui proposta foi utilizada para
analisar usurios da rede social online Pinterest, uma rede baseada em compartilhamento de videos e imagens
pre-categorizados em 33 categorias. Vale ressaltar que o algoritmo proposta generalizado para qualquer rede de
contedo categorizado.
Denominao
Entropia de Shannon.
Contexto
Anlise de comportamento de usurios uma rea bastante explorada e complexa, existem diversos estudos na
literatura focados nas mais diversas redes sociais e servios. Nossa contribuio para este campo da cincia foi o de
propor um algoritmo voltada para analise de especificidade/generalidade do contedo pre-categorizado gerado por
usurios de uma rede. No intuito de demostrar uma aplicao para o sistema, analisamos 683.273 usurios da rede
Pinterest e seus 229.661.143 items categorizados em 33 diferentes categorias.
Algoritmo
Entropia de Shannon definida por:
onde N o nmero de categorias utilizadas pelo usurio e Pi a probabilidade geral dos items serem da categoria N.
De maneira geral, quanto mais prximo H for de 0, mais previsvel o contedo do usurio , portanto mais
especialista em determinadas categorias.
Exemplo: Pinterest
Os usurios da rede possuem albums categorizados em 33 categorias pre-definidas. Esses albums por sua vez,
contem fotos ou videos de interesse do usurio. Em essncia a estrutura de contedo dentro da rede se assemelha ao
seguinte:
116
Portanto o usurio mais generalista possvel, seria aquele que coleciona o mesmo nmero de items para todas as 33
categorias. Desta forma sua entropia seria definida por:
Enquanto o mais especialista seria aquele que gera contedo apenas para uma nica categoria:
Requisitos
Escalabilidade: Escalabilidade necessria devida a quantidade de items a serem processados, em nosso
exemplo a mdia de items por usurio foi de 336 items.
Armazenamento: A aplicao no demanda muito armazenamento em memria principal, devido ao calculo ser
individual por usurio e os dados necessrios serem pre-processados. Portanto apenas os suas respecitivas
informaes devem ser carregadas. Entretanto, devido ao volume do contedo gerado, necessrio uma
quantidade significativa de espao em disco, outra limitao a natureza da coleta dos dados. Eles foram
coletados utilizando http-requests que retornava 50 items por vez. Desta maneira, se o usurio possui muitos
albums e muitos items, seu nmero de arquivos relacionados ser bastante elevado. Na prtica, a consequncia
disto que muitas vezes o limit de INodes do HD foi estourado, forando-nos a dividir o conteudo do usurio em
HDs/Maquinas diferentes. Quanto ao resultado do algoritmo, sua demanda de espao pequena, pois necessrio
apenas os IDs dos vrtices e seus respectivos valores finais.
Projeto
Como o calculo de entropia individual para cada usurio, e seu calculo depende somente da natureza da
distribuio do seu contedo, uma primeira paralelizao evidente: cada map ser responsvel pelo calculo de um
usurio. Porem h uma massiva quantidade de contedo para cada usurio, por isso decidiu-se realizar duas
paralelizaes na forma de dois procedimentos map-reduce. O primeiro ser responsavel pelo pre-processamento dos
dados necessrios para o calculo da entropia: cada map sera responsvel pela identificao dos items de um album
117
especfico e o reduce far a sumarizao desses dados em um vetor de tamanho N, onde N o nmero de
categorias existentes. O segundo map receber este vetor e ira calcular o Pi (probabilidade) de cada categoria para
este usurio e o reduce simplemente utilizar este dado para o calculo de H(x), mostrado da Seo Algoritmo.
Como dito antes, por limitaes de armazenamento possvel que contedo de um usurio esteja distribuido em
maquinas/HDs diferentes. Portanto preciso, durante o primeiro map-reduce que as maquinas recebem os dados por
completo do usurio, gerando assim um alto trafego de comunicao na rede. Porem uma vez feito isso, todas as
informaes necessrias para o segundo map-reduce j estaro disponveis em memria e portanto mensagens
adicionais no precisaro ser feitas.
Toda a aplicao se resume a dois paradigmas de map-reduce. Portanto, obviamente o primeiro deve terminar por
completo antes de comear o prximo. Porem dentro de um mesmo map-reduce, como h sempre vrias threads para
processar as informaes de um usurio, elas no precisam esperar que acabe todo o processo de um usurio para
comear a pegar informaes do outro. Pois a sincronia nesse nivel feita pelo reduce.
Desenvolvimento
Como explicado anteriormente, o calculo da entropia foi dividido em dois procedimentos map-reduce. Extrapolando
esta ideia para a rede especifica do Pinterest, temos:
O primeiro map-reduce, tem como entrada um vetor contendo o identificador do usurio e os albums associados a
ele. O map pega cada album e cria duas rows, uma associando a categoria dele com o nmero de items e outra (sum)
dedicada a ser agregada pelo reduce, isto feito pois para o calculo da entropia necessario calcula a probabilidade
geral da categoria e para calcular isso necessrio saber o somatrio dos items que o usurio possui e os item
associados a cada categoria. Este primeiro Map pode ser definido por:
118
Na fase de reduce, o resultado do Map agregado em um vetor de forma que cada row contenha a identificao da
categoria, o nmero de items associados a ela e o nmero total de items do usurio. Basicamente, a ideia que todas
as informaes necessrias para calcular a probabilidade de categoria para cada usurio estejam disponveis. Este
reduce pode ser representado por:
O segundo map-reduce, recebe como entrada a sada do primeiro reduce. Primeiramente calcula a Probabilidade Pi
(N Photos / "Sum") de cada categoria e realiza a multiplicao Pi * log(Pi).
119
Desta maneira, o trabalho do reduce se resume em agregar todos os P(i) em modulo e dividir pelo nmero de
categorias utilizadas pelo usurio, neste caso o nmero de rows associadas a ele.
Estrategias de Armazenamento
Ao terminar uma iterao os dados so salvos no sistema de arquivos virtual distribudo do Hadoop (HDFS) para
serem lidos no incio da prxima iterao. Esse sistema de arquivos abstrado para o programador.
A cada iterao do map-reduce, o sistema responsvel por sincronizar e transportars os dados, portanto a grande
maioria de mensagens trocar na realidade abstrada do programador. Apenas um cuidado maior tomado na hora
da transio entre os dois map-reduces implementados, pois o primeiro deve acabar antes do segundo comear.
120
Implementao
Utilizamos um ambiente composto por 5 servidores, sendo 3 deles com 16 cores intel(R) Xeon(R) E5620 @
2.40GHz, 32gb de memria ram e 2 HDs Sata de 3 tera. Os outros dois servidores possuem a mesma confgurao,
porem com 8 cores ao invs de 16 e 24 gb de ram. O ambiente foi montado utilizando Hadoop com o sistema de
arquivos distribuido HDFS (Hadoop Distributed File System). O sistema operacional de todos os servidores o
Ubuntu 12.04.
Resultados
A seguir, mostramos o resultado da entropia de categoria dividido por gneros. possvel perceber que mulheres
tendem a ser mais generalistas que homens. De forma semelhante, podemos usar a mesma mtrica e metodologia
para entender a origem dos contedos na internet (eg, uma figura do www.deviantart.com). Usa-se a mesma equao
da Entropia de Shannon, substituindo pelo nmero de domnios diferentes usado pelo usurio e pela
probabilidade de um pin ser daquele domnio especfico, de forma a calcular a sua Entropia de Domnimo. Os
resultados a seguir revelam, de novo, que mulheres so mais generalistas que homens na rede.
Entropia de Shannon para categorias e domnio de origens dos contedos por usurio, dividido por gnero
Referncias
[1] [1] Ihara, Shunsuke (1993). Information theory for continuous systems. World Scientific. p. 2. ISBN 978-981-02-0985-8.
Processamento de streams de tweets
121
Geeser - A tool for processing raw tweet streams
Application Description
Definition
Geeser Project intends to give a toolbox for data analyists to work with massive tweet streams in a distributed and
scalable environment. For that, Geeser is based on Storm, an open-source fault-tolerant stream processing system.
Geeser implements natural language processing activities and simple statistics, such as word counting and trending
topics.
In this first stage of the project (that is shown here), we are proposing a distributed way to preprocess tweet streams
to extract main textual features. More than that, we are showing practical use of Storm stream processing framework
in a challenging context. It is import to stress that this project do not aim do optimize or speedup any specific
algorithm. My only concern is to make it feasible to run some algorithms in massive streams.
Context
Processing tweet streams is a great challenge for data analysts and for Twitter's infrastructure as well. Storm was
developed specially to tackle the problem of processing such streams. In this context, the amount of messages may
vary through time. Consequently, the load of the system is not constant.
At this stage it is possible to process each message individually. Then it is quite easy to distribute this algorithm. The
challenge here is to minimize bandwidth usage. Another goal is to create a system that is robust enough to hold the
unbalanced load through time.
Storm Framework
Storm is a distributed, fault-tolerant realtime computation system. It was originaly cocieved by Twitter on a
successfull attempt to distribute it's processing workload.
Main Concepts
Storm is mainly composed by 2 types of processing units: Bolts and Spouts. Spouts generate streams, while Bolts
consume and produce new streams in it's output. It's model is similar to the traditional producer-consumer approach
seen on early networks applications. The simplicity of producer-consumer aproach works out to be one storm
greatest strenghts.
122
The graph generated by the conection of bolts and spouts is called topology. It maps what the cluster will do. It is a
very simple abstraction that helps software engeneers to work the modules spearatelly. The comunication protocol
between the processing units is based on tuples, similarlly to JSON. Therefore, in CAP Theorem, Storm attends to
the Avalability and Partition Tolerance requirement. Because tuples might get out of order in the the process.
Storm permits multiple processes in each Spout and Bolt allowing data paralelism inside the processing unit. It is a
good idea to make tuples as indepent as possible in order to use the system full parallelism capacity.
Components
Storm's requires 3 main software components to work: Nimbus, Zookeeper, and Workers. Nimbus is the component
responsible for code deployment on the worker nodes. Tha Apache Zookeeper is a software for load control on the
nodes. Zookeeper load is quite low since its only function is to choose which node will process the next tuple. If fault
tolerance is a requirement, the number of Zookeerper processes should be increased, for most cases, only one
running is enough. For details on how to install such requirements, check on the Install section.
123
The system bootstrap works as follows. All worker nodes report to the Zookeeper as soon as the code is submited to
Nimbus. Then the binary code is submited to each worker node. When the worker nodes are ready to take a job,
Zookeeper sends each node a tuple to be processed. And this is done until a spout sends a terminate signal.
Development tests
Storm has a mode for software testing in a single machine. This can be achieved by setting a single working node or
with the code submissions method. Unit testing is also quite easy since we can use Java for that.
Multilanguage
Is easy to implement Bolts and Spouts in other languages than Java. The simplest way to do that is implementing
ShellBolt class (I am explaning that on the API section).
Storm's API
Storm has a mode for software testing in a single machine. This can be achieved by setting a single working node or
with the code submissions method
124
Code Submission methods
Apache Maven
Maven is a software project management tool that uses a project oriented model (POM), which is written in XML. It
helps to build a jar package that is easy deliverable to nimbus. To use it we use the following command to compile it:
Leiningen
A alternative to maven is the Leiningen, which automates project similarly to Maven but it is written to work with
Clojure methods. That way it is possible to write topologies em Clojure and deploy them using:
Major drawbacks
Network Every big data system has to worry with two major bottle necks: Network and processing. Storms deal fine
with processing bottlenecks. The data parallelism and Zookeeper garantees a good load ddistribution. However, the
system doesn't optimize the network usage. The tuples may have different sizes as the comunication between nodes
may have different latencies and bandwidth.
I believe that there is room for optimizing the network bottleneck by dynamically adjusting the communication
based on the link latency and on the network saturation. For instance, if the comunication between two bolts is very
intensive in a moment perhabs it is best that both run on the same worker machine.
Dependency The system depends on a bunch of software that may loose compatibility in a long range support. This
may be critical to storm project. There are some big data systems that are more stable because they depend on fewer
third party software.
Examples of Storm Usage
In this section I am covering simple usages of storm that help to didacally understand how storm work. In here we
are working with examples ssen in the storm-starter.
Exclamation Topology
The exclamation topology is a very simple topology that has only one objective: Add exclamation marks at the end
of random words. In this example, we have two instances of the same object ExclamationBolt. The tuple in this case
is just a simple string. One interesting fact in this example is that the order is not important so we can create a
superscalar topology.
In this case, we have 10 processes for the spout, 3 for Exclamation Bolt 1 and 2 for exclamation Bolt 2. The run is
quite fast and the overhead is only done. We can see a sample of the output in the figure below
125
Word Count Topology
The Word Count topology is another simple topology that is used to count words in sentences. For that, a spout
randomly emits a set of 5 different sentences. Then, there is a bolt implemented in Python to split the sentences.
Finally, a bolt to count word frequencies:
Maybe a good improvement in this Topology would be adding some persistency in the word count structure. That
way it would be possible for another bolt to consult a certain word frequency. I am showing this on the following
sections. For now, I am focusing on the sytax and the results and the implementation of this. Bellow, an example of
the output:
Single Join Topology
This is the most complex example in this section. In here it is necessary to implement methods that do the join
considering that the tuples came unordered. For that, the communication buffer is used to wait until the correct
example. Also, timeouts are used to solve starvation problems in this approach. Because of that Joins in Storm's
topologies might introduce bottle necks that should be avoided at all costs
126
Requirements
As it was said in previously, the main requirement in our system is scalability. It is necessary that we can process a
high volume of tweets in the same time. To make matters even worse, we have to deal with a highly dinamic load.
Other important feature of this system is that it need to be fault tolerant. We can't allow to loose a stream due to a
machine crash or a network failure.
Opportunities
The main parallelism opportunities in this project is the possibility to include other activities running while the
preprocessing run. And this is quite easy to be done using Storm framework. In here, I am showing a simple
application that
Project
Stages
The Geeser Project propose several stages. In each stage, a different activity is added to work on the stream parallely.
For instance, word count and trending topics on second stage and entity disambiguation on the third stage.
For each stage, I propose to write a set of spouts and bolts that are necessary to reach the corresponding objective.
That way, developers can mount a topology according their necessity:
1. 1. Stage 1: Basic Spouts and Raw Tweet textual processing
2. 2. Stage 2: Word Counting and Trending Topics Bolts
3. 3. Stage 3: Entity Disambiguation Bolt
Communication patterns
The communication will be fully detailed in the project final API. It is based on the non-structured database JSON.
This is a standard communication on Storm's protocol, which is based only on tuples.
This is a simple protocol and ideal to work on databases which tends to have several processing nodes that are
independent.
Proposed topologies on Geeser's first stage
Basically, the main topology proposed on the first stage is composed of a single spout which reads the tweet stream
from a file to simulate a connection to Twitter's API. This was the only option since the virtual machines had only 10
GB of space.
The following bolts, projects the full JSON tweet to comunicate only the text of the message to the next bolt. This
following bolt will process those texts.
127
Implementation
The Storm nodes need to implement some functions to work:
Code Examples
Each spout and bolt is a class. Multilang bolts may be implemented using classes that inherits ShelBolt, which runs
the bolt in a virtual shell.
The comunication is implemented by the mother class. Usually, we use BaseBasicBolt and BaseRichSpout for
implementing bolts and spouts. In those cases, we have to implement some functions that concerns the activity done
by the bolt or spout.
Bolt Interface
void prepare()
This funcion is called before any tuple is transmited to a certain bolt.
int execute(Tuple tuple, BasicOutputCollector collector)
This funcion is called when a new tuple gets to the bolt. It should call other funcions important to processing. And it
is done call collector.emit(Values) to send another tuple to the next bolt
void fail(Object id);
void ack(Object id);
Bolts may also add ack to be sure that a tuple was delivered to the next bolt.
void declareOutputFields(OutputFieldsDeclarer declarer)
Declare the Output Filed on the outgoing tuple.
Map<String, Object> getComponentConfiguration()
Get the configuration of the bolt set by the conf class.
Spout Interface
void open()
Execute before the first tuple is sent. It can be used, for instance, to establish connections to Twitter's sample API
void nextTuple()
Iterates over each tuple generated. Emiting it using emit function.
void close()
It is called when nextTuple() returns. Used for finishing connections
Map<String, Object> getComponentConfiguration()
Get the configuration of the spout set by the conf class.
void fail(Object id)
void ack(Object id)
Dealing with communication fails.
void declareOutputFields(OutputFieldsDeclarer declarer)
128
Declare the Output Filed on the outgoing tuple.
Topology Builder
Here is the example of the topology builder:
TopologyBuilder builder = new TopologyBuilder();
builder.setSpout("spout", new TwitterFileSpout(), 1);
builder.setBolt("project", new FilterTweet(), 5)
.shuffleGrouping("spout");
builder.setBolt("filter", new FilterTweet(), 5)
.shuffleGrouping("project");
builder.setBolt("print", new PrinterBolt(), 1)
.shuffleGrouping("filter");
Config conf = new Config();
conf.setDebug(false);
conf.setNumWorkers(3);
if(args!=null && args.length > 0) {
StormSubmitter.submitTopology(args[0], conf,
builder.createTopology());
} else {
conf.setMaxTaskParallelism(3);
LocalCluster cluster = new LocalCluster();
cluster.submitTopology("word-count", conf,
builder.createTopology());
cluster.shutdown();
}
}
Communication
Communication process is completely abstracted from the developer. We only need to minimize the consuption of
network bandwith since Storm does not manage it well.
Python Bolts
We have python libraries that implements Storm's protocol. It is quite easy to use such libraries. I am showing the
code used of the language cleaner bolt. In that code, tup is the incoming tuple. and emit sends the outgoing tuple.
import storm
class StreamFilterBolt(storm.BasicBolt):
def process(self, tup):
try:
text = cleanText(tup.values[0])
except:
text = ''
storm.emit([text])
129
StreamFilterBolt().run()
Avaliation
Considering the requirements of this project which focus scalability and fault tolerance over latency. I evaluated the
Storm capabilities of distributing process and making a massive stream scalable to be processed. The main results of
this project is to build the foundation to many bolts and spouts designed specially to the Web Observatory project. It
also helps the software development processes because each bolt is a black box that may be implemented by many
different people in different languages.
Load on Bolts
For simple Twitter jobs, Storm managed to distribute jobs in a fair way. None worker node recived more jobs than
another. This is a good result that shows that our system scales well enough for a huge twitter load.
Nimbus Logs
Now I am showing the final output of the proposed topology. It process raw tweet to return trigrams without
hashtags, char repetition, links, trigrams generations and other details.
Conclusion
In this project, it is shown that it is possible to create a complex distributed system for processing massive tweet
streams. This system is scalable and very flexible. Topologies can be modified for several different purposes making
it ideal to the Web Observatory and Data Science research projects. Even though, speedup gains may be not
aplicable (since we should be able to serially process big data in a single computer), there is an enourmous gain in
scalability.
The main contribution here is to check the viability and add knowledge to Web Observatory of Storm framework.
This framework helps not only software development but make it possible to deal with massive streams. The gain for
this project is imensurable in many terms.
Concluso
130
Concluso
Concluso
A rea de processamento de dados massivos j se consolidou como uma das novas fronteiras do processamento de
alto desempenho. Neste texto apresentamos um apanhado da rea, com nfase sobre o modelo de programao
MapReduce e o ambiente de execuo Hadoop, que oferece uma implementao de cdigo aberto do modelo. O
material aqui apresentado deve servir como uma introduo programao com Hadoop, mas certamente mais
informaes so necessrias para o domnio do tema. As referncias apresentadas devem ser suficientes nesse
sentido.
Apesar de sua popularidade, certamente Hadoop no a soluo para todos os problemas de processamento de dados
massivos. Algumas das reas em que outras solues so ainda necessrias foram identificadas, bem como as
principais inciativas em cada rea. A bibliografia apresentada pode servir como ponto de partida para aqueles que
desejem se aprofundar em qualquer desses tpicos.
Fontes e Editores da Pgina
131
Fontes e Editores da Pgina
Introduo Fonte: http://pt.wikibooks.org/w/index.php?oldid=243019 Contribuidores: DorgivalGuedes, MGFE Jnior
Aspectos gerais do ambiente de Big Data Fonte: http://pt.wikibooks.org/w/index.php?oldid=243904 Contribuidores: DorgivalGuedes, MGFE Jnior
O desafio de escalabilidade Fonte: http://pt.wikibooks.org/w/index.php?oldid=243021 Contribuidores: DorgivalGuedes, MGFE Jnior
O modelo de programao MapReduce Fonte: http://pt.wikibooks.org/w/index.php?oldid=243022 Contribuidores: DorgivalGuedes, MGFE Jnior
O ambiente Hadoop Fonte: http://pt.wikibooks.org/w/index.php?oldid=243903 Contribuidores: DorgivalGuedes
Outros ambientes Fonte: http://pt.wikibooks.org/w/index.php?oldid=243920 Contribuidores: DorgivalGuedes, SrMilanez
Projeto e implementao de aplicaes Big Data Fonte: http://pt.wikibooks.org/w/index.php?oldid=243023 Contribuidores: DorgivalGuedes, MGFE Jnior
Minerao de Itemsets Frequentes Fonte: http://pt.wikibooks.org/w/index.php?oldid=243858 Contribuidores: Acnazarejr, MGFE Jnior, Sabir Ribas, 8 edies annimas
Agrupamento baseado em densidade Fonte: http://pt.wikibooks.org/w/index.php?oldid=253147 Contribuidores: Algum, Fernandocarvalho3101, MGFE Jnior
R-tree Fonte: http://pt.wikibooks.org/w/index.php?oldid=243219 Contribuidores: Felipebuzatti, MGFE Jnior
Identificao de ciclos em grafos Fonte: http://pt.wikibooks.org/w/index.php?oldid=245742 Contribuidores: Abacaxi, MGFE Jnior, RochaRodrigoCO, 1 edies annimas
API para processamento estatstico Fonte: http://pt.wikibooks.org/w/index.php?oldid=243613 Contribuidores: Edre, Heitormotta, MGFE Jnior
Avaliao do algoritmo PageRank Fonte: http://pt.wikibooks.org/w/index.php?oldid=254001 Contribuidores: Abacaxi, Gabrielmagno, MGFE Jnior, SrMilanez, 4 edies annimas
Maximizao de expectativas Fonte: http://pt.wikibooks.org/w/index.php?oldid=272335 Contribuidores: Arturhoo, MGFE Jnior, Rotlink, Silvioribeiro
Agregao eficiente de dados temporais Fonte: http://pt.wikibooks.org/w/index.php?oldid=243922 Contribuidores: Eduardomb81, MGFE Jnior
Classificao associativa incremental (LAC) Fonte: http://pt.wikibooks.org/w/index.php?oldid=247115 Contribuidores: Carlos.freitas, Carlosalessandrosena, CommonsDelinker, MGFE
Jnior, Rloliveirajr, 7 edies annimas
Entropia de Shannon em redes de contedo categorizado Fonte: http://pt.wikibooks.org/w/index.php?oldid=250532 Contribuidores: Bobmath, CommonsDelinker, MGFE Jnior, Ottoni,
Raphaottoni, 6 edies annimas
Processamento de streams de tweets Fonte: http://pt.wikibooks.org/w/index.php?oldid=263064 Contribuidores: Alexandre Davis, MGFE Jnior, 2 edies annimas
Concluso Fonte: http://pt.wikibooks.org/w/index.php?oldid=245743 Contribuidores: Abacaxi, DorgivalGuedes
Fontes, Licenas e Editores da Imagem
132
Arquivo:ArquiteturaDC.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:ArquiteturaDC.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores:
User:DorgivalGuedes
Ficheiro:HadoopRTS.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:HadoopRTS.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores:
User:DorgivalGuedes
Arquivo:Anthill.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Anthill.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores: User:DorgivalGuedes
Ficheiro:Pson-0.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Pson-0.png Licena: Creative Commons Attribution-Sharealike 3.0,2.5,2.0,1.0 Contribuidores: Sabir (eu,
autoria prpria) e Antnio
Ficheiro:pson-1.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Pson-1.png Licena: Creative Commons Attribution-Sharealike 3.0,2.5,2.0,1.0 Contribuidores: Sabir Ribas
Ficheiro:Pson-4.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Pson-4.png Licena: Creative Commons Attribution-Sharealike 3.0,2.5,2.0,1.0 Contribuidores: Sabir Ribas
Ficheiro:padrao-de-comunicacao.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Padrao-de-comunicacao.png Licena: Creative Commons Attribution-Sharealike
3.0,2.5,2.0,1.0 Contribuidores: Sabir Ribas
Ficheiro:linha-do-tempo-integrada.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Linha-do-tempo-integrada.png Licena: Creative Commons Attribution-Share Alike
Contribuidores: Sabir Ribas
Ficheiro:Speedup_transacao.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Speedup_transacao.png Licena: Creative Commons Attribution-Sharealike 3.0,2.5,2.0,1.0
Contribuidores: Antnio Carlos Nazar Jnior
Ficheiro:Tempo_transacao.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Tempo_transacao.png Licena: Creative Commons Attribution-Sharealike 3.0,2.5,2.0,1.0
Ficheiro:Speedup_dimensao.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Speedup_dimensao.png Licena: Creative Commons Attribution-Sharealike 3.0,2.5,2.0,1.0
Ficheiro:Tempo_dimensao.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Tempo_dimensao.png Licena: Creative Commons Attribution-Sharealike 3.0,2.5,2.0,1.0
Ficheiro:Situacao.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Situacao.png Licena: Public Domain Contribuidores: Fernandocarvalho3101
Ficheiro:Classificacao.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Classificacao.png Licena: Public Domain Contribuidores: Fernandocarvalho3101
Ficheiro:Pontos.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Pontos.png Licena: Public Domain Contribuidores: Fernandocarvalho3101
Ficheiro:AgrupamentoFinal.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:AgrupamentoFinal.png Licena: Public Domain Contribuidores: Fernandocarvalho3101
Ficheiro:Linha.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Linha.png Licena: Public Domain Contribuidores: Fernandocarvalho3101
Ficheiro:ExemploDB.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:ExemploDB.png Licena: Public Domain Contribuidores: Fernandocarvalho3101
Ficheiro:Armazenamento.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Armazenamento.png Licena: Public Domain Contribuidores: Fernandocarvalho3101
Ficheiro:Comunicacao.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Comunicacao.png Licena: Public Domain Contribuidores: Fernandocarvalho3101
Ficheiro:Comunicacao2.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Comunicacao2.png Licena: Public Domain Contribuidores: Fernandocarvalho3101
Ficheiro:Esquema solucao.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Esquema_solucao.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores:
Felipe Buzatti Nascimento
Ficheiro:Esquema solucao filtros.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Esquema_solucao_filtros.png Licena: Creative Commons Attribution-Sharealike
3.0,2.5,2.0,1.0 Contribuidores: Felipe Buzatti Nascimento
Ficheiro:Modelo solucao filtros comunic.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Modelo_solucao_filtros_comunic.png Licena: Creative Commons
Attribution-Sharealike 3.0 Contribuidores: Felipe Buzatti Nascimento
Ficheiro:GraphDFS.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:GraphDFS.png Licena: Creative Commons Zero Contribuidores: RochaRodrigoCO
Ficheiro:GraphDCMP.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:GraphDCMP.png Licena: Creative Commons Zero Contribuidores: RochaRodrigoCO
Ficheiro:Edre heitor Linhas de tempo1.jpg Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Edre_heitor_Linhas_de_tempo1.jpg Licena: Creative Commons Attribution 3.0
Contribuidores: Edre
Ficheiro:Edre heitor Media-duracao.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Edre_heitor_Media-duracao.png Licena: Creative Commons Attribution 3.0
Ficheiro:Edre heitor Media-tasks.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Edre_heitor_Media-tasks.png Licena: Creative Commons Attribution 3.0 Contribuidores:
Edre
Ficheiro:Edre heitor Quantis-duracao.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Edre_heitor_Quantis-duracao.png Licena: Creative Commons Attribution 3.0
Ficheiro:Quantis-tasks.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Quantis-tasks.png Licena: Creative Commons Attribution 3.0 Contribuidores: Edre
Ficheiro:Edre heitor Desvio-duracao.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Edre_heitor_Desvio-duracao.png Licena: Creative Commons Attribution 3.0
Ficheiro:Edre heitor Desvio-tasks.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Edre_heitor_Desvio-tasks.png Licena: Creative Commons Attribution 3.0 Contribuidores:
Edre
Ficheiro:Edre heitor Contingencia-duracao.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Edre_heitor_Contingencia-duracao.png Licena: Creative Commons Attribution 3.0
Ficheiro:Edre heitor Contingencia-tasks.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Edre_heitor_Contingencia-tasks.png Licena: Creative Commons Attribution 3.0
Ficheiro:Edre heitor Particionar-duracao.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Edre_heitor_Particionar-duracao.png Licena: Creative Commons Attribution 3.0
Ficheiro:Edre heitor Particionar-tasks.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Edre_heitor_Particionar-tasks.png Licena: Creative Commons Attribution 3.0
Imagem:PageRanks-Example.svg Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:PageRanks-Example.svg Licena: Public domain Contribuidores: en:User:345Kai,
User:Stannered
Ficheiro:Pagerank graphlab gather.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Pagerank_graphlab_gather.png Licena: Creative Commons Attribution-Sharealike
3.0,2.5,2.0,1.0 Contribuidores: Gabriel Magno
Ficheiro:Pagerank graphlab apply.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Pagerank_graphlab_apply.png Licena: Creative Commons Attribution-Sharealike
133
Ficheiro:Pagerank graphlab scatter.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Pagerank_graphlab_scatter.png Licena: Creative Commons Attribution-Sharealike
File:Pagerank graphlab grafico n.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Pagerank_graphlab_grafico_n.png Licena: Creative Commons Attribution-Sharealike
File:Pagerank graphlab grafico speedup.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Pagerank_graphlab_grafico_speedup.png Licena: Creative Commons
Attribution-Sharealike 3.0,2.5,2.0,1.0 Contribuidores: Gabriel Magno
File:Pagerank graphlab grafico p.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Pagerank_graphlab_grafico_p.png Licena: Creative Commons Attribution-Sharealike
File:Pagerank graphlab grafico iterations.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Pagerank_graphlab_grafico_iterations.png Licena: Creative Commons
Attribution-Sharealike 3.0,2.5,2.0,1.0 Contribuidores: Gabriel Magno
File:Hadoop EM linha do tempo.jpg Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Hadoop_EM_linha_do_tempo.jpg Licena: Creative Commons Attribution-Sharealike 3.0
Contribuidores: User:Arturhoo
File:Armazenamento.jpg Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Armazenamento.jpg Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores:
User:Silvioribeiro
Ficheiro:Grafico de segundos x Nmero de Ns.jpg Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Grafico_de_segundos_x_Nmero_de_Ns.jpg Licena: Creative Commons
Attribution-Sharealike 3.0 Contribuidores: User:Silvioribeiro
Ficheiro:Lac algorithm.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Lac_algorithm.png Licena: Attribution Contribuidores: Veloso, A., Meira Jr., W., and Zaki, M. J.
Ficheiro:Training_projection_1_lac.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Training_projection_1_lac.png Licena: Attribution Contribuidores: Veloso, A., Meira Jr.,
W., and Zaki, M. J.
Ficheiro:Training_projection_2_lac.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Training_projection_2_lac.png Licena: Attribution Contribuidores: Veloso, A., Meira Jr.,
W., and Zaki, M. J.
Ficheiro:Esquema 1.svg Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Esquema_1.svg Licena: Creative Commons Attribution 3.0 Contribuidores: Roberto L. de Oliveira Jnior
Ficheiro:Esquema 2.svg Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Esquema_2.svg Licena: Creative Commons Attribution 3.0 Contribuidores: Roberto L. de Oliveira Jnior
File:Tempo1.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Tempo1.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores: User:Carlosalessandrosena
File:Hits1.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Hits1.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores: User:Carlosalessandrosena
File:Misses1.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Misses1.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores: User:Carlosalessandrosena
File:Maximo1.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Maximo1.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores: User:Carlosalessandrosena
File:Minimo1.xcf Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Minimo1.xcf Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores: User:Carlosalessandrosena
Ficheiro:Chart bigdata.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Chart_bigdata.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores: Roberto L.
de Oliveira Jnior
File:Acuracia.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Acuracia.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores: User:Carlosalessandrosena
Ficheiro:pinterestConteudo.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:PinterestConteudo.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores:
User:Raphaottoni
Ficheiro:mapReduceCompleto.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:MapReduceCompleto.png Licena: Creative Commons Attribution-Sharealike 3.0
Contribuidores: User:Raphaottoni
Ficheiro:primeioMap.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:PrimeioMap.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores:
User:Raphaottoni
Ficheiro:primeiroReduce.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:PrimeiroReduce.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores:
User:Raphaottoni
Ficheiro:segundoMap.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:SegundoMap.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores:
User:Raphaottoni
Ficheiro:segundoReduce.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:SegundoReduce.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores:
User:Raphaottoni
File:Resultados.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Resultados.png Licena: Creative Commons Attribution-Sharealike 3.0,2.5,2.0,1.0 Contribuidores: Joo Paulo
Pesce
Ficheiro:Storm-example.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Storm-example.png Licena: Creative Commons Attribution-Sharealike 3.0,2.5,2.0,1.0 Contribuidores:
Alexandre Davis
File:Storm-components.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Storm-components.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores:
User:Alexandre Davis
File:ExclamationTopology.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:ExclamationTopology.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores:
File:Log Exclamation.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Log_Exclamation.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores:
File:WordCountTopology.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:WordCountTopology.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores:
File:Log wordCount.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Log_wordCount.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores:
File:SingleJoinTopology.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:SingleJoinTopology.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores:
File:Log comb.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Log_comb.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores: User:Alexandre Davis
File:Image-med6.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:Image-med6.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores: User:Alexandre
Davis
File:BoltLoad.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:BoltLoad.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores: User:Alexandre Davis
File:FinalLog.png Fonte: http://pt.wikibooks.org/w/index.php?title=Ficheiro:FinalLog.png Licena: Creative Commons Attribution-Sharealike 3.0 Contribuidores: User:Alexandre Davis
Licena
134
Licena
Creative Commons Attribution-Share Alike 3.0
//creativecommons.org/licenses/by-sa/3.0/

Processamento de Dados Massivos PDF

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Processamento de Dados Massivos PDF

Transféré par

Droits d'auteur :

Formats disponibles

PDF gerado usando o pacote de ferramentas em cdigo aberto mwlib. Veja http://code.pediapress.com/ para mais informaes.

PDF generated at: Wed, 03 Sep 2014 19:11:16 UTC

Vous aimerez peut-être aussi