Uma metodologia de caracterização de serviços de mineração de dados

UMA METODOLOGIA DE CARACTERIZAÇO

DE SERVIÇOS DE MINERAÇO DE DADOS

Belo Horizonte, Minas Gerais

UMA METODOLOGIA DE CARACTERIZAÇO

DE SERVIÇOS DE MINERAÇO DE DADOS

Dissertação apresentada ao Curso

de Pós-Graduação em Ciênia da

Computação da Universidade

Fede-ral de Minas Gerais omo requisito

parial para a obtenção do grau de

Mestre em Ciênia da Computação.

Belo Horizonte, Minas Gerais

FOLHA DE APROVAÇO

Uma Metodologia de Caraterização de Serviços de

Mineração de Dados

LEONARDO CHAVES DUTRA DA ROCHA

Dissertação defendidae aprovada pelabana examinadora onstituída por:

Prof.Wagner Meira Junior Orientador

Universidade Federalde Minas Gerais

Prof. Dorgival Olavo Guedes Neto

Universidade Federalde Minas Gerais

Prof.Renato Antonio C. Ferreira

Universidade Federalde Minas Gerais

Profa.Luila Ishitani

PontifíiaUniversidade Católiade Minas Gerais

ServiçosWebestãosetornandoumpadrãoparaodesenvolvimentodeumgrande

onjuntode apliaçõesqueutilizamaInternet. Umexemplodesse tipodeapliação

éamineraçãode dados,ujoobjetivoéextrairinformaçõesúteisde um grande

on-juntode dados. UmserviçoWebde mineraçãode dadosbemsuedido deveumprir

osrequisitosdeinteraçãodeumatarefademineraçãodedadoseosrequisitosde

pro-essamento intensivo e armazenamento de grandes onjuntos de dados geralmente

assoiadosàs ténias empregadas. Nesta tese apresentamos uma metodologiapara

araterização de serviços Web omputaionalmente intensivos, em partiular

ser-viços de mineração de dados. Nossa metodologia de araterização foa em ambos

os lados do serviço, interativo e não interativo, bem omo o relaionamento entre

eles. Nós apliamos nossa metodologia a um serviço de mineração de dados real,

o Tamanduá. Os resultados mostram que há uma alta variabilidade entre os

usuá-rios em termos de omportamento, mas eles agem de formasimilar om respeito à

natureza das tarefas de mineração que eles requisitam e em omo eles analisam os

resultados. Nossos resultados também mostram que nós podemos dividir os

usuá-riosemdois gruposdistintos, um grupo queutiliza osistema de formaseqüenial e

outro que apresenta um omportamentoassínrono, impondo uma demanda maior

ao sistema. Esses resultados não só mostram a apliabilidade de nossa proposta,

mas também abre novas direções em termos de meanismos de sustentação para

esse tipo de sistema Web. Alémdisso, nós também determinamos modelos de

dis-tribuições estatístias que podem ser utilizadaspara a geraçãode argas sintétias

Web servies are beoming a standard for deploying a large spetrum of

appli-ations using the Internet. One example of suh appliation is data mining, whih

aims to extrat useful information from large sets of data. A suessful data

mi-ning servie must fulll both interation requirements of a data mining task, and

the intensive proessing and large storage requirements usually assoiated with the

tehniques employed. In this paper we present a methodology for haraterizing

omputationally intensive Web servies, in partiular data mining servies. Our

haraterization methodology fouses on both the interative and non-interative

sides of the servie, as well as their relationships. We applied our methodology on

an atual data mining servie, Tamanduá. The results show that there is a high

variability among users in terms of their behavior, but they at similarly with

res-pet to the nature of the data miningtasks they request and how they analyze the

results. Our results alsoshow thatweare able todivide the users into two distint

groups, one that uses the system in a sequential fashion and other that presents

an asynhronous behavior, plaing a bigger demand on the system. These results

not only show the appliability of our approah, but also open new diretions in

terms of system support mehanisms for suh Web servies. Further, we are also

abletodeterminestatistialdistributionsthat maybeused forgeneratingsyntheti

Primeiramente agradeço a Deus por mas essa oportunidade em minha vida.

Agradeço a minha mãe querida, no verdadeiro sentido da palavra ME, por me

ensinar osverdadeiros valores da vidaomo honestidade, aráter, humildadee

per-severança. Agradeçopelo seu apoioinondiional,por ser o paidoDiogona minha

ausênia (e que ausênia nesses últimos anos...), por ser meu pai quando preisei,

minhaamiganosmomentosdediuldade. Mãe, voêmeensinouoquantoé

impor-tanteoonheimentoehojeáestouembusadele,adavez mais. Muitoobrigado!

Te amo muito!!!

Agradeço aos meus dois pais: papai e vov Chaves, que, mesmo não presente

mais entre nós, de uma formainexpliável,me sussurravam forçaegarra para lutar

e não desistir do meu sonho. Agradeço aos meus irmãos Leandroe Luiano. Voês

dois são meus melhores amigos, ompanheiros. Mesmo sem entender muito bem

o que eu estava fazendo, estavam sempre do meu lado! Amo demais voês dois, e

sempreserá assim.

Agradeço aminha amada Elisapeloompanheirismo inondiional,prourando

sempreentenderminhaausêniaemasa,meapoiandoemminhasdeisões,pormais

difíeisqueamesmasfossem,revezandoomigonaslongasmadrugadasdosprimeiros

meses de vidado nosso lho. Amor, sabemos o quanto foi e é difíil,passamos por

tudo juntos, ontinuamos lutando juntos e sempre estaremos juntos...TE AMO!!

Agradeço ao meu sogro José Braga e a a minha sogra Inez Helena, pelo amor e

arinho om que voês uidaram e uidam do nosso Diogo. Por me aolherem na

famíliade voês, não omo omarido daElisamas omoum lho.

Agradeço ao meu lho e amigo Diogo. Diogo, hoje, om 1 ano e 3 meses voê

nãoentendeoquantovoê foi,éesempreseráimportanteemminhavida. Graçasa

voê meu lho, aprendia ter um pouo mais de paiênia, aprendi o quantoé bom

amar de forma inondiional. Graças a voê, me sinto muito importante porque

te vendo assim, tão pequenino e tão inoente, vejo o quanto voê preisa de mim.

Se hoje voê não entende, espero que um dia isso aonteça, mas independente de

lhamos juntos desde de 2000, quando após uma aula de AEDS3 voê me onvidou

para uma iniiação ientía. Desse dia para á foram muitos trabalhos, muitos

artigos publiados, muitos artigos reusados, mas ao mesmo tempo muita amizade

e onversa. Seu entusiasmo, paiênia e dediação em ensinar é algo ontagiante.

Hoje, após 5 anos trabalhando juntos, tenho por voê uma profunda admiração e

respeito. MuitoobrigadomesmoMeira!! Agradeçotambémaosprofessoreseamigos

Renato e Dorgival por serem pessoas extraordinárias! Na ausênia do Meira, eram

voês que me ajudavam, era a voês que eu reorria om minhas dúvidas, e voês,

sempre muito eduados e om toda a paiênia do mundo, me ajudavam.

Agra-deçodemaisavoês pelas longasonversassobre avida,me aonselhandodiantede

algumasdas diuldadesnesses quase dois anos.

Devo grandeparte desse trabalhoao meu amigo eompanheiro de trabalho

Pe-droCalais. Sãodoisanosdeonvivêniade muitotrabalhoeaprendizado. Agradeço

muito a voê meu amigo, por abraçar este trabalhoomo se fosse seu próprio

tra-balho, obrigado mesmo, de oração. Tenho erteza de que daqui a dois anos será

voê quem estará apresentando sua dissertação!! Muito obrigado Pedro, e ontinue

assim!

Ao pessoal da seretaria (Túlia, Maristela, Renata, Gilmara, Cida, Sheila, Lu,

Fernanda, Cláudia, Stella, Valéria, Snia , Emília , Lizete, Orlando, Alexandre,

Gilberto e Geraldo) meu muito obrigado pelo apoio e amizade durante todos esses

anos. Voês todos são pessoas maravilhosas!

Agradeço ao pessoal do speed, aos desmaiados, ao pessoal de Lafaiete e ao Bar

doBetopelosmomentosdedesontração. Nãosódetrabalhoviveohomem,evoês

ontribuírame muito nessa aminhada, me proporionando momentos de alegria e

desontração para esqueer um pouo o trabalho árduo que está por trás de uma

1 Introdução 1

1.1 Coneitos . . . 3

1.2 Motivação . . . 5

1.3 Objetivo . . . 6

1.4 Desrição . . . 6

1.5 Organização . . . 7

2 Trabalhos Relaionados 8 2.1 Web Servies . . . 8

2.2 Serviços de Mineraçãode Dados . . . 11

2.3 Caraterizações Web . . . 12

3 Metodologia 15 3.1 Arquitetura dos Sistemas Caraterizados . . . 15

3.2 Dimensões de Caraterização. . . 17

3.3 Coleta de Dados. . . 18

3.3.1 Preparação dos Dados . . . 20

3.4 Metodologia de Caraterização . . . 21

3.4.1 VisãoGeral . . . 21

3.4.2 Sessões de Usuários . . . 22

3.4.3 Comportamentode Usuários . . . 23

3.4.4 Tarefas de Usuários . . . 26

3.5 Sumário . . . 27

4 Estudo de Caso 28 4.1 Arquitetura Tamanduá . . . 28

4.2 Resultados . . . 32

4.2.1 VisãoGeral daCarga de Trabalho. . . 33

4.2.3 Comportamentode Usuário . . . 37

4.2.4 Tarefas de Usuários . . . 42

4.3 Sumário . . . 48

5 Conlusões e Trabalhos Futuros 50 5.1 Conlusões . . . 50

5.2 TrabalhosFuturos. . . 51

5.2.1 Caraterização de Outros Algoritmos . . . 52

5.2.2 Caraterização de Outros Grupos de Usuários . . . 52

5.2.3 Apliaçãoda MetodologiaemOutros Contextos . . . 52

5.2.4 Geradorde CargasSintétias . . . 53

5.2.5 Análise TemporaldoComportamentodos Usuários . . . 53

A Exemplos dos Logs dos Servidores 55

B Exemplo do Log Uniado 57

1.1 Desoberta de onheimentoem banosde dados. . . 3

3.1 Arquitetura doSistema Objeto de Caraterização . . . 16

3.2 Proesso de Geraçãodos USIMGs . . . 24

4.1 A arquitetura Tamanduá . . . 29

4.2 Caraterização das Sessões de Usuários . . . 35

4.3 Distribuição doNúmero de Tarefas porSessão . . . 36

4.4 USIMG de todas asSessões . . . 38

4.5 USIMG das Sessões doGrupo0 . . . 40

4.6 USIMG das Sessões doGrupo1 . . . 41

4.7 Distribuição doTempo entre Chegada de Tarefas (minutos) . . . 42

4.8 Popularidadedos Parâmetros doAlgoritmo Apriori . . . 43

4.9 Base de Dados X . . . 46

4.10 Base de Dados Y . . . 47

4.1 Sumárioda Carga(CV = Coeientede Variação) . . . 33

4.2 Sumárioda CargaConsiderada noProessos de Chegada de Sessão ede Tarefas (CV= Coeiente ofVariação) . . . 34

4.3 Sumáriodas Distribuições . . . 36

4.4 Freqüênia das Requisições- todas sessões . . . 38

4.5 Sumáriodas Caraterístias doUSIMG . . . 39

4.6 Freqüênia das Requisições- Grupo 0 . . . 40

4.7 Freqüênia das Requisições- Grupo 1 . . . 41

4.8 Relação entre os Parâmetros do AlgoritmoApriori. . . 44

4.9 Desrição das Base de Dados . . . 45

4.10 Renamentodas Tarefas . . . 45

A.1 Log doServidor de Apliação doTamanduá . . . 55

A.2 Log doServidor de Mineraçãodo Tamanduá . . . 55

A.3 Log doServidor de Dados doTamanduá . . . 55

A.4 Log doServidor de Visualizaçãodo Tamanduá . . . 56

Introdução

AWebtemidomuitoalémde suapropostainiialdeserumaplataformasimples

de troa doumentos e está se tornando de fato um ambiente para desdobramento

de uma grande variedade de apliações. Iniialmente, essas apliaçõeseram

desen-volvidas (euma grandepartedelas aindaé)usandooprotoolo HTTP. Noentanto,

tenologiasWebServiesvêmsetornandoaesolhadeumnúmeroadavez maiorde

apliaçõesquesão providasatravésdaWeb, motivadaporsuasaraterístiasde

in-teroperabilidade, asquaispermitemque apliaçõesdiferentes interajam eexeutem

sob uma variedade de plataformase arabouços.

Enquanto onúmero ea variedade das apliaçõesaumentam, nós podemos

tam-bémobservarquenovosrequisitosfunionaisenão-funionaispreisamsersatisfeitos

omo a exeução de tarefas de omputação intensiva, manipulação de grandes

vo-lumes de dados e visualização de padrões de informação ada vez mais omplexos.

Ao mesmo tempo, métrias tradiionais de desempenho Web tal omo tempo de

resposta ao usuário devem ser mantidas em níveis aeitáveis. As exigênias e as

araterístias destas novas apliações baseadas na Web, assim omo o

omporta-mento de seus usuários, preisam ser araterizados e ompreendidos de modo que

sepossa lidar om asdemandas eas expetativas desses usuários.

Um exemplo de tal apliaçãoé a mineração dos dados. Da perspetiva da

apli-ação, a mineração de dados tem omo objetivo extrair informações úteis de um

grandeonjunto de dados. Umexemplo de talinformaçãosão asregras de

assoia-ção, istoé,relaionamentos ausais entre elementosde dados. Apliaçõesannias

de regras de assoiação são usualmente onheidas omo análise de esta de

om-pras, que busa enontrar orrelações entre os artigos omprados por lientes em

um supermerado ou em qualquer outra loja. Um exemplo de regra de assoiação

para esse ontexto pode ser 70%dos lientes que ompram leiteompram também

nos maisdiversos ampos. Porexemplo,asompanhias de artãode réditopodem

usarregrasdaassoiaçãoparadetetar fraudes,umsupermeradopode usá-laspara

maximizarseu luroouotimizaroposiionamentode seusprodutos nas prateleiras.

Os algoritmos de mineração de dados, que são o núleo dessas apliações, são,

em geral, omputaionalmente intensivos e exigem um espaço de armazenamento

bastante signiativo, em onseqüênia dos dados de entrada, que são geralmente

volumosos, e dos dados que são gerados durante sua exeução, inluindo os

resul-tados nais. Além disso, a informação extraída por esses algoritmos é geralmente

omplexa, sendo um ampo ativo de pesquisa o projeto e a implantação de

me-táforas visuais que ajudam usuários a ompreender as informações mineradas. O

uso de um serviço Web de mineração de dados é araterizado pela interação

tí-pia de apliaçõesWeb, que segueum padrãode requisição-resposta,e tambémpor

requisições de exeução de tarefas de mineração de dados, que são essenialmente

assínronas,seassemelhandoaargasemlote(bath),quepodemterlongaduração.

Em onseqüênia destas araterístias, os usuários desses sistemas omportam-se

diferentemente, misturando interatividade e requisições em lote. Além disso, os

usuários aprendem também omo extrair melhor e mais rapidamente a informação

do sistema, à medida que o usam. Em onseqüênia, a arga do sistema omo um

todoésigniativamentediferentedas apliaçõesWeb tradiionaise deve-se, assim,

ompreendê-la om o objetivo de melhoraro projeto dessas apliações assim omo

aesalabilidade 1

das mesmas.

Neste trabalhoapresentamos uma metodologiahierárquiade araterização de

serviços de mineração de dados providos pela Internet. Além disso apresentamos

uma araterização detalhada de um serviço desse tipo. Pelo onheimento que

temos, é a primeira araterização de serviços desta natureza, isto é, um serviço

Web que ombine requisições interativas e em lote. Embora nosso estudo foalize

uma apliação espeía, a metodologia que nós propomos é apliável a qualquer

tipo de serviço Web que apresente araterístias similares. Nós apliamos nossa

metodologiapara araterizar a arga de um serviço de mineração de dadosreal, o

Tamanduá[Tam05℄,quepossuía3onjuntosdedadosdisponíveisparamineraçãode

dadoseum totalde145usuáriosregistrados. Aoletadosdadosfoifeitanoperíodo

de Abrila Maiode 2005, quando houve usuários submetendotarefas de mineração,

visualizandoresultados e avaliando osistema.

1

Entende-se por esalabilidade a apaidadeque o serviço possui de manter aqualidade de

1.1 Coneitos

A Mineração de dados pode ser denida omo a "extração de informações

im-plíitas, previamentedesonheidas e potenialmente úteis de grandesbases de

da-dos" [WF00℄. Trata-se de uma etapa de um proesso muito mais amplo onheido

omo Desoberta de Conheimentos em Bano de Dados, ou simplesmente KDD

(Knowledge Disovery in Databases) [HK00℄. Este proesso é onstituído de ino

passosprinipais(Figura1.1) quepodem ser agrupadosemtrês etapas: preparação

dosdadosompostadospassosdeseleção,preproessamentoetransformação;

deso-berta de padrõesomposta dopasso de mineração de dados; visualizaçãoomposta

dopasso de avaliação/interpretaçãode resultados.

Figura 1.1: Desoberta de onheimento embanos de dados.

A primeira etapa do proesso KDD é a etapa de preparação dos dados. Esta

etapainluidiversastarefas,omoastarefasde limpezadosdados(pararemoçãode

inonsistênias, eliminaçãode ruídos e tratamento de valores ausentes), integração

dedados(paraombinaçãodedadosdediferentesfontes), seleçãodeatributos (para

esolhados dados mais relevantes para mineração)e transformaçãode dados (onde

téniasomodisretização,normalizaçãoouagregaçãosãoapliadassobreosdados

para tornar a sua forma mais onveniente). A segunda etapa do proesso KDD é

a etapa de mineração de dados propriamente dita. Esta etapa onsiste de tarefas

que podem levar à desoberta de diferentes tipos de padrões. Dentre essas tarefas,

destaam-setrêstipos: análisedeassoiações,quebusaenontrar orrelaçõesentre

itensdeumonjuntodedados;análisedeagrupamentos,quebusaorganizarositens

deumabase dedadosemonjuntos,de aordoomalgumritériode similaridade;e

lassiação,queonsistenadesobertade modelosquedesrevamasaraterístias

seja onheida, possa ser lassiado om base nas suas araterístias onheidas,

através dautilizaçãodos modelos.

A tereira etapa do proesso KDD é a apresentação para os usuários dos

re-sultados obtidos na mineração. Nesta etapa, são utilizadas metáforas visuais para

representaçãodospadrõesmineradosdeformaapossibilitarumainterpretaçãolara

e inequívoa do onheimento desoberto. São ofereidos também meanismos que

permitem ao usuário interagir om os resultados, ltrando os mais relevantes,

ex-plorandoosrelaionamentosexistentes entre elesedetalhandoaquelesque foremdo

seu interesse [FGW02, SD02℄.

Cada uma dessas etapas pode ser vista omo uma unidade de trabalho

inde-pendente, podendo ser exeutada emmomentose loais distintos. Um sistema que

implementasse todas essas etapas pode exigir investimentos muito altos, em geral

maiores do que aqueles que as organizações podem ou estão dispostas a fazer. No

entanto, uma divisão de esforços, onde instituições distintas se espeializemem

di-ferentes etapas do proesso e disponibilizemas soluções desenvolvidas naforma de

serviços,demaneiraqueoutrasorganizações,omneessidadessemelhantes,possam

usufruirdelas,minimizaesseproblema. Para queessadivisão possaaonteer,é

ne-essárioqueseuse uma arquitetura denidausandopadrõesabertos,possibilitando

assimainteroperabilidade 2

entre osváriosomponentes. Dessaforma,assoiadoao

uso amploqueaWeb vemapresentando nos últimosanos, tenologiasWeb Servies

se apresentam omo uma boa solução para prover ada uma das etapas do KDD

omo serviços.

Webserviessãoamaisreenteevoluçãonospadrõesde desenvolvimentode

apli-açõesdistribuídas permitindo queapliaçõesooperem failmentee ompartilhem

informações e dados umas om as outras. Teniamente, Web servies são serviços

distribuídosque proessam mensagens SOAP(Simple Objet Aess Protool)

odi-adas em XML, enviadas através de HTTP e que são desritas através de WSDL

(Web Servies Desription Language) e que usam tenologias programáveis e

reuti-lizáveis que aproveitam a exibilidade da Internet [FF03℄. Com eles é possível ter

uma innidade de apliativosonetados em rede, mesmo rodando emplataformas

diferentes, forneendo informações a todos os seus lientes, pareiros e

funioná-rios. As tenologias Web Servies tentam fazer a omuniação entre apliaçõestão

fáil quanto a Web tornou a publiação de doumentos [Shi02℄. Através dessas

2

Interoperabilidadepode serdenida omoapaidade deompartilhar e troarinformações

eproessosentreambientesheterogêneos,autnomosedistribuídos,detal formaqueumsistema

(informatizadoounão)possaseomuniardeformatransparente (ouomaispróximodisso)om

tenologias é possível a riação de apliações distribuídas, om vários omponentes

espalhados pelaInternet,trabalhando emooperação para a realizaçãode tarefas.

UmadasprinipaisrazõesparaoresenteinteresseemtenologiasWebservies

é que eles permitem uma Arquitetura Orientada a Serviços SOA (Servie-Oriented

Arhiteture). Quando se utilizaWeb servies para a onstrução de talarquitetura,

as soluções onsistem de oleções de serviços autnomos, identiados por URLs,

om interfaes doumentadas através de WSDL e proessando mensagens XML.

SOA éum omplementoa abordagens orientadas aobjetose proedimentais.

1.2 Motivação

A mineração de dados ofereida omo Web Servie trata-se de uma estratégia

novaquepossuialgumasaraterístiasemomum omapliaçõesWeb tradiionais

omo omério eletrnio, biblioteas digitais, vídeo sob demanda, aprendizado à

distânia et. Em todos esses serviços podemos observar uma variabilidade nos

pers de usuários, queemdiferentes sessões 3

, realizamrequisiçõesde usto variado.

Alémdisso, essasapliaçõespodemser araterizadasporpáginasWeb omplexase

geradas dinamiamente, om onteúdo personalizado e integradas a um sistema de

bano de dados, ao mesmo tempoque satisfazem alguns requisitos de qualidade de

serviço (por exemplo,bom desempenho ealta disponibilidade) [MA02℄.

Noentanto,alémdessasaraterístiasjáitadas,serviçosdemineraçãodedados

possuem outras araterístias próprias que os difereniam dos demais. Esse tipo

de serviço, apesar de possuir altograu de interatividade om os usuários, também

possui proessamento emlote que são representados pelas tarefas de mineração de

dados propriamente dita. Essas tarefas, araterizadas por um algoritmo,poruma

base de dados epor parâmetrosutilizadosnos mesmos,são normalmenteintensivas

omputaionalmente.

Sistemas dessa natureza têm resido emuso e apliabilidade,omo

onseqüên-ianatural dapopularizaçãode serviços Web e doseu resente uso omo anal de

aesso a serviços omputaionalmente intensivos. O entendimento de omo

usuá-rios interagem om tais sistemas em termos de sua atuação e do uso onjunto dos

omponentes interativos (sínronos) eem lote (assínronos)ainda está em aberto.

Entender a aleatoriedade assoiada ao modo omo os usuários soliitam ada

serviço dessas apliações, assim omo a arga gerada por eles, se torna uma tarefa

indispensável na análise da viabilidade da estratégia e na busa de soluções para

3

sessõessãoaraterizadasporumonjuntoderequisiçõesfeitasporumdeterminadousuário,

melhora de desempenho e disponibilidade para tornar o sistema esalável. Uma

ferramenta importanteque provê esse entendimento é a araterização do

ompor-tamento dos usuários e da arga geradaporeles. Entretanto, por se tratar de uma

estratégianovaparaoprovimentode serviçosWeb,omaraterístiaspróprias,

a-raterizações tradiionais omo as apresentadas em [AKR01℄, [Bor83℄ e [DKB02℄

não são apropriadas. Este enário motivou-nos a desenvolver uma metodologia de

araterização mais abrangente, que ontemple não somente as araterístias

o-muns a outras apliações Web, mas também as araterístias espeías dessas

apliações, trabalhoeste inéditoaté então.

Atravésdaapliaçãodessametodologiadearaterização,serápossívelfazeruma

análise de omo os usuários reagem ao omportamento sínrono ou assínrono do

sistema,entendendoomosuasrequisiçõesserelaionamemtermosdesimilaridades

e diferenças. Além disso, através dela será possível prover subsídios para geração

de argas sintétias éis ao omportamento do usuário, além de desenvolver um

modelo de previsão de desempenho e disponibilidade voltado para o gereniamento

e planejamento de apaidade desses serviços.

Apesardametodologiater sidodesenvolvidafoadaemserviços demineraçãode

dados, elapode ser muito bem apliadana araterização de outras apliações que

possuam araterístiassimilaresàs apliaçõesde mineração de dados omo

aplia-çõesde ompartilhamentoremotoedistribuídodeinformações [TKC

+

04,AEM

+

04,

BMPZ02,DCJ

+

05℄, de análisede riso emapliaçõesnaneiras[Col05℄,ambientes

de pesquisasde arqueologiavirtualede diagnóstiolimátiodistribuído[Ser05℄,de

mirosopiavirtual [ABB

+

98℄, de análise de plaentas[PH05℄ dentre outros.

1.3 Objetivo

O objetivo deste trabalho é apresentar uma metodologia de araterização de

serviçosdemineraçãodedados,elaboradaombaseemmetodologiastradiionaisde

araterizaçãoWeb enas araterístiasespeíasdessesserviços omorequisições

omputaionalmente intensivas (em lote), requisições interativas e a sobreposição

entre elas.

1.4 Desrição

Este trabalho apresenta, portanto, uma metodologia para araterizar serviços

•

padrão de aesso dos usuários do sistema om o objetivo de enontrar

mode-los que representem informações temporais relaionadas à arga riada pelos

usuários,omo eles iniiam assessões equão longaé a duração das mesmas.

•

arateri-zamosopadrãodas requisiçõesdosusuários. Issosigniaentendero

ompor-tamento dos usuários em termos das requisições dos mesmos aada uma das

funionalidadesdosistemaeomoessasrequisiçõesestãorelaionadasdurante

uma sessão, omo por exemplo a sobreposição entre asrequisições interativas

enão interativas.

•

padrãode suas requisições, nesse nível de nossa metodologiaaraterizamos e

modelamos a natureza das requisições. Em mineração de dados, requisições

importantessão asexeuçõesde algoritmosdemineraçãode dados,outarefas.

Para a avaliação da metodologia, utilizaremos a plataforma do projeto T

aman-duá [Tam05℄, que é uma arquitetura para a distribuição do proesso KDD, onde

repositórios de dados, servidores de mineração e servidores de visualização são

dis-ponibilizados por diferentes instituições e integrados através das tenologias Web

Servies para a realização de tarefas espeías. No apítulo 4 é apresentada a

arquitetura dosistema de forma mais detalhada.

1.5 Organização

O trabalhoestá organizadoem mais quatro apítulos além desta introdução. O

apítulo 2 apresenta um estudo feito om trabalhos de araterização e avaliação

de omportamento de usuários, além de outros trabalhos relaionados a serviços

de mineração e arquiteturas baseadas em tenologias Web Servies. O apítulo 3

apresenta a metodologia de araterização proposta neste trabalho. No apítulo 4

apresentamos um estudo de aso apliando a metodologiaproposta emum sistema

real de serviços de mineração de dados, Tamanduá. Nesse apítulo desrevemos a

arquitetura Tamanduá de formadetalhada,e apresentamos o resultados obtidosna

apliaçãoda metodologianessa arquitetura; por m no apítulo 5 apresentamos as

Trabalhos Relaionados

Este apítuloapresenta uma síntese dos prinipaistrabalhos relaionadosa

ser-viços de mineração de dados e arquiteturas baseadas em tenologias Web Servies.

Apresentamos, dessaforma,umaoletâneade artigosientíospubliados em

sim-pósios e onferênias, além de artigos ténios e apítulos de livros relaionados a

araterizaçãoeplanejamentodeapaidadede apliaçõesWebtradiionaisque

ser-viram de base para a realização deste trabalho. No entanto, por se tratar de uma

abordagemreente, não foram enontrados trabalhos relaionados à araterização

deserviçosdemineraçãodedadosoudeoutrosserviçosomaraterístiassimilares.

Dessaformadividimosostrabalhosemtrêsgrupos. ASeção2.1desrevealgumas

apliações Web que vêm fazendo uso de tenologias Web Servies além de algumas

avaliações de aspetos no uso dessas tenologias que devem ser onsiderados; a

Se-ção 2.2 apresenta os trabalhos relaionados a serviços de mineração de dados; e,

nalmente na Seção 2.3 apresentamos os esforços de pesquisa na araterização da

interaçãoentre usuários eserviços Web enas formas de extraçãode informaçõesdo

uso dosistema para ns de araterização. Além disso, disutimos aaraterização

de argas de trabalho assoiadas om a exeução de tarefas de mineração.

2.1 Web Servies

Christopher Ferris et al. [FF03℄ dene Web Servie omo sendo uma apliação

de software identiada por uma URI, ujas as interfaes e ligações sejam apazes

de serem denidas, desritas, edesobertas omo artefatos XML,suportandoassim

interaçõesdiretasomoutrosagentes de software usandotroade mensagens

basea-das emXML através dos protoolos de Internet. Emomplementoaessa denição,

para Almeida e Menasé [AM02℄, Web Servie desreve funionalidades de negóio

In-ternet, om o propósito de prover um meanismo para que outras ompanhias ou

programas usem ou omplementem oserviço. Já em [MA02, MA00℄esses mesmos

autores disutem detalhadamente questões relaionadas à qualidade de serviço em

todosostiposdeserviçosWeb,usandoumaabordagemquantitativa,alémdeprover

um arabouço para entender asomplexasrelaçõesda Web e omo issoimpatano

desempenho e disponibilidade dos serviços.

JáexistemhojediversostrabalhosqueutilizamtenologiasWebServies [TKC

+

04,

AEM

+

04,BMPZ02,DCJ

+

05℄. Em [TKC

+

04℄,KerryL.Tayloretal.,apresentauma

arquiteturabaseadaemWebServiesparaproverumanovaplataformaparafailitar

pesquisas naárea de saúdedenominadade HRDN(Health Researh Data Network).

Essa plataformafoiriada omo intuitode ompartilhare analisardados

distribuí-dos de formasegura. Umtrabalhosemelhante éapresentado em [AEM

+

04℄. Neste

artigoosautores apresentam uma arquitetura de gerênia eolaboraçãodistribuída

de dados relaionados a diagnóstios de âner de mama, uma vez que estes

pos-suem umaltograu de variabilidadedentrodapopulação. Essa arquitetura também

é baseada em tenologias Web Servies. Ainda na direção de ompartilhamento

de informação, um trabalho bastante interessante é apresentado por Baglietto et

al.[BMPZ02℄. Nesse trabalhoosautores desrevem umaarquitetura também

base-adaemWeb Serviesquepossibilitaoompartilhamentode informaçõesde negóios

de uma mesma área. Alémdisso os autores apresentam um estudo de aso real de

uso da arquitetura noPorto de Gênova. E,porm, em [DCJ

+

05℄os autores

apre-sentam um sistema olaborativo entre partiipantes remotos em uma tele-imersão

onstruído utilizandoWeb Servies e Mirosoft Visual Studio .Net.

OutrapropostaqueutilizatenologiasWeb Servieédesritaem [Col05℄. Nesse

trabalho, o autor apresenta uma apliação na qual proessos omputaionalmente

intensivos e paralelos, relaionados a análise de riso de merado, são gereniados

através de um front-end Web. Outros trabalhos relaionados ao uso de tenologias

Web Servie omo solução podem ser enontrados em [Ser05℄, onde temos desde

propostas de ompartilhamento de dados até gerênia de proessos

omputaional-menteintensivos, omo por exemplo um ambiente de pesquisa arqueológia virtual

e um sistemade diagnóstiolimátio distribuído,dentre outros.

Alémde propostasde arquiteturas baseadasemtenologiasWebServies,existe

naliteraturaumonjuntomuitograndedetrabalhosqueavaliamalgunsdosaspetos

relaionados a esse modelo [GSC

+

00, CGB02, GSC

+

04, AGLG04, Mi02, DP02,

KS03,SCP04℄. Em [GSC

+

00℄, osautoresdisutemodesempenhodos protoolosde

omuniaçãoentreserviçosremotosparaomputaçãoientía,maisespeiamente

ontextos. Através de experimentos os autores mostram que o SOAP, por si só,

não é eiente o bastante para apliações ientías de larga esala, mas, quando

usadoemonjuntoom um arabouço de multi-protoolos de hamadaremota,sua

eiênia melhora signiativamente, podendo ser utilizado omo um protoolo de

ontrole universal.

Um trabalho semelhante é apresentado em [CGB02℄, no qual os autores

in-vestigam as limitações de algumas tenologias Web Servies em omputação

ien-tía. Nesse trabalho os autores detetam quais são as deiênias que limitam o

SOAP em termos de desempenho em apliações ientías de omputação

inten-siva,alémde implementaremum novaversãode melhordesempenhoparaomesmo.

Em [AGLG04℄, os autores também apresentam um proposta de omo melhorar o

desempenho doSOAP.

Ainda om relação à avaliação de tenologias Web Servies, em [GSC

+

04℄ os

autores omparam e ontrastam algumas das ferramentas mais populares para

im-plementação de arquiteturas baseadas em Web Servies, provendo omo resultado

diretrizesparaodesenvolvimentodeprojetosnessasarquiteturasommelhor

desem-penho. Neste trabalho são avaliadas o onjunto de ferramentas de implementação

SOAP mais utilizadas reentemente, omo gSOAP

2

.

4

M ay

28

1

.

2

1

.

1

.

4322

1

.

1

JavaRMI, CORBA, HTTP. Outros trabalhos omo [KS03, SCP04 ℄ também

apre-sentam omparações entre outras tenologias de implementação de Web Servies

muito utilizadasatualmente.

Alémdessestrabalhos,temosumartigoem [Dim05℄queexpliaomotenologias

WebServiesestãosetornandopopulares,ouseja,padrãoparaodesenvolvimentode

apliaçõesque gereniam proessosomputaionalmenteintensivose um Workshop

internodaMirosoft [Wor05℄quedisutetenologiasparaapliaçõesdeomputação

intensivade dadosusando Web Servies

Em suma, a diversidade e apliabilidade de tenologias Web Servies é muito

ampla e resente, sendo para nós uma motivação para a realização de estudos de

araterização de arga de trabalhonesses ambientes.

Nesta Seçãoapresentamosumestudodeapliaçõesimplementadasombasenas

tenologiasWeb Servieexistentes, assimomo umestudode avaliaçõesdessas

apli-ações. Esses estudosforamfeitosomo intuitode entenderomo essas tenologias

vêmsendo utilizadasnos mais diversos ontextos, destaandoa importânia dessas

no enário atual de desenvolvimento de apliativos. Além disso, entender a

objetivo é propor uma metodologia de araterização de serviços de mineração de

dados baseados nessas arquiteturas.

2.2 Serviços de Mineração de Dados

Existem alguns trabalhos relaionados à disponibilização de serviços de

minera-ção de dados omo serviços na Internet. Umadas primeiras propostas foi

apresen-tada por Sarawagi et. al. em [SN00℄, noqual alguns desaos no provimentodesse

tipode serviços são disutidos, taisomo padrões paradesrição de modelosde

mi-neração, integração de modelos de origens distintas, segurança e onabilidade, e

personalizaçãousando dados dousuário.

Já Krishnaswamy et al. [KZL01b, KZL01a℄ ompararam diversos provedores de

serviçosde mineraçãodedadosbaseados naInternet,omodigiMine[dig02℄e

Infor-mation Disovery[Dis02℄. Usuáriossubmetemasrequisiçõesdemineraçãoenviando

seus dados ao provedor de serviços (om quem normalmentea empresa possui um

ontrato) e aessam os resultados através de uma interfae Web. Após disutirem

situaçõesde uso desses serviçose questõesrelaionadasa ada um, propuseramum

modelo de múltiplos provedores de serviço, denindo os protoolos de interação e

um meanismode troadeinformaçõese desriçãode requisiçãoportarefa baseado

em XML. Além desse trabalho, Krishnaswamy apresenta em [KZL03℄ um modelo

para mineração de dados baseado em agentes. Resumidamente, nessa proposta são

os agentes que vão até o loal onde os dados estão armazenados, que é o mesmo

onde amineração é feita.

Além dos trabalhos disutidos aima, existe ainda um onjunto grande de

pro-postas de serviços de mineração de dados utilizandogrades omputaionais (grids)

[MHHK99, CTT01 , CTT02 , CT03 , BHTW03b, BHTW03a, KBTH04℄. Em ada

um desses trabalhos são apresentadas propostas de utilização de grades

omputa-ionais, disutindo questões relaionadas a infraestruturaneessária, arquiteturas e

desempenho das mesmas. Em [MHHK99℄ temos um dos primeiros relatos de uma

implementaçãodistribuídade umalgoritmode mineraçãode dados. Nesse trabalho

os autores implementaram uma versão paralela de um algoritmo de agrupamento

sobre vários ambientes geograamentedistribuídos.

Nostrabalhos [CTT01 ,CTT02 , CT03 ℄enontramosasprimeiraspubliações

so-breinfraestruturaparaserviçosdemineraçãodedadossobregrids. Nessestrabalhos,

os autores apresentam uma arquitetura de software para apliações de desoberta

de onheimento distribuídas e paralelas denominada Knowledge Grid, onstruída

grid. Apesar deapresentaroambiente, osautoresnão apresentam nenhum asoreal

de uso domesmo.

Em [BHTW03b , BHTW03a, KBTH04, VJF

+

04℄ enontramos trabalhos mais

reentes sobre mineração de dados emambientes distribuídos. Peter Brezany et al.

em [BHTW03b ℄ apresentam os prinípios para projetos de serviços de mineração

de dados de alto desempenho em ambientes grid, além de apresentar um desses

serviços. Osmesmos autoresapresentam em [BHTW03a ℄o GridMiner,uma

infra-estrutura paramineração de dadosemgrid, baseada nos prinípiosapresentados no

artigoanterior([BHTW03b ℄). Umainfraestruturabastantesemelhanteadosartigos

anterioresé proposta em [KBTH04℄.

Jáem [VJF

+

04℄,osautoresapresentamumaimplementaçãoaltamenteesalável

de um algoritmo de mineração de regras de assoiação. Esse algoritmo foi

imple-mentado para ser exeutado de forma paralela em lusters, baseado no paradigma

Filter Labeled-Stream, desrito nopróprio artigo.

Em resumo, podemos observar que mineração de dados é uma apliação que

vem sendo bastante estudada, apesar de não termos enontrado nenhum registro

de uso emoperação real delas. A validaçãodessas apliaçõesainda é um problema

em aberto, investiu-se muito no desenvolvimento dessas apliações mas pouo se

sabesobre os usuáriosrealmente usariamas arquiteturas propostas, omo seria seu

omportamento, sendomais uma motivação para arealização desse trabalho.

Apesardenão fazerpartedessetrabalhoproporqualqueroutraarquiteturapara

oprovimentode serviçosde mineraçãodedados,onheer asdiversasarquiteturas e

implementaçõesdessesserviçosexistenteséfundamentalparaentenderas

araterís-tiase osrequisitosdosmesmos,e assimproporuma metodologiade araterização

desses serviços. De qualquer forma,foram trabalhos fundamentaispara a proposta

de metodologiaapresentada neste trabalho.

2.3 Caraterizações Web

Existem diversas frentes de pesquisa relaionadas om a araterização de

ser-viços Web [AKR01, Bor83, AJ99, AW97℄. Em [Bor83℄, os autores apresentam a

araterização de omportamento de usuários de um sistemade onsultas on-line a

uma bibliotea universitária nos Estados Unidos. Métrias omo tipo de onsultas

realizadas, padrõesde uso do sistema, tempo gasto para exeução de tarefas foram

quantiadasno trabalho. Um estudoda esalabilidade de um sistemade ompras

Web é apresentado em [AKR01℄. Esse estudo foi feito om base na araterização

de serviços e produtos, taxa de requisições e requisições por liente. Um estudo

semelhante é apresentado em [AJ99℄, porém relaionado ao provimento de vídeos

ao vivo pela Internet, no qual os autores fazem um estudo da arga gerada pelos

usuários em um Web Site que ofereia a transmissão dos jogos da opa do mundo

de futebolde 1998 aovivo. Tambémem [AW97 ℄é apresentada umaaraterização

de arga de apliações em três ambientes distintos: ambiente aadêmio, ambiente

organizaional de pesquisa ientía e ambiente omerial. Em todos esses

traba-lhosaimamenionados,assimomoem [Pit98,DKB02℄,asmétriasutilizadaspor

eles foram utilizadasem nossa araterização nos níveis de sessão e tarefa de nossa

metodologia. Entretanto,essasmétriasnão são suientes paraesse trabalho,uma

vez que o ritério de interaçãousuário-sistema e seus diferentes tipos de requisição

(interativa eem lote) não são tratadas.

No artigo [JvO04℄ é apresentado um método de extração de informações

rele-vantes sobre o omportamento de navegação dos usuários em serviços Web. Além

desse artigo, em [JvO04℄ é apresentado um modelo de previsão de omportamento

de usuário. Em outros dois artigos [CJ90, RMP90 ℄ são apresentadas propostas de

aquisição de onheimento. Apesar de não fazer parte do nosso trabalho propor

qualquer método de previsão de omportamento ou de aquisição de onheimento,

as ténias utilizadas nesses dois artigos, de erta forma, foram úteis para extrair

informações do uso do sistema em nossa araterização, além de servir omo base

para identiaçãode renamentoentre astarefas requisitadas pelos usuários.

Wassermanet. al.[WMSR04℄apresentaramumaaraterizaçãodeargade

inte-ligêniade negóios baseados nobenhmarkTPC-H .O benhmarkTPC-H onsiste

de um onjunto de onsultas que imitam apliações omplexas de análise de

negó-ios, empartiular aatividade de um forneedor porataado. Ela nãorepresenta a

atividadede nenhum segmentoem partiular, mas simo de uma empresa quedeve

ontrolar, vender ou distribuir um produto mundialmente. Eles onsideraram 22

onsultas do benhmark e as agruparam em quatro grupos, baseados na demandas

das mesmas por proessamento e entrada e saída, em partiular araterizando a

demanda de suas bases de dados. O proesso de agrupamento é baseado em um

trabalho anterior de Calzarossa e Serazzi [CS94 ℄. Sua suposição é que a exeução

de uma apliaçãopode ser expressa em termos da quantidade e dos SLAs de ada

um dos tipos de onsultas. Sua proposta é diferente da nossa no sentido que eles

não foalizam a interação dos usuários om o sistema, mas assumem que o

ben-hmark representa a arga que os usuários reais gerariam e avaliam a demandas

orrespondente.

[MA02,MA00℄,que tratamde questõesrelaionadas aplanejamentode apaidade

eaimportâniadissopara oprovimentode umserviço esalávelede boaqualidade,

alto desempenho e boa disponibilidade, além de apresentarem um modelo de

re-presentaçãode padrãode omportamentode usuáriodenominadoCBMG(Customer

Behavior Model Graph) utilizado emvários ontextos [HTMRG

+

04,NAR

+

04℄, que

serviu omo ponto de partida para a riação do modelo de representação utilizado

emnossotrabalhononíveldeomportamentodeusuáriodenominado

USIMG(User-System Interation Model Graph)que será apresentado na Seção 3.4.3.

Apesardosesforços aimamenionados,nós nãoonseguimosenontrar nenhum

trabalhoquealvejasse aaraterização de serviços de mineraçãode dadosoude um

sistemaWebque apresentasse araterístiassimilarestaisomotarefas

omputai-onais intensivas e assínronas. De qualquer forma,os trabalhos apresentados nesse

Metodologia

Neste apítulodesrevemos a metodologiade araterização proposta neste

tra-balho. Nossa metodologia tem por objetivo guiar a exeução de araterizações

de sistemas que possuem araterístias interativase não-interativas,a m de

ana-lisar o omportamento dos usuários desses sistemas, quantiando, qualiando e

modelandoa arga riadapor eles.

Antes de apresentarmos a metodologia de araterização propriamente dita, é

importante denirmos a arquitetura do sistema que pretendemos araterizar, ou

seja,denirosomponentes daarquiteturaeosmeanismosde interaçãoentre esses

omponentes. Alémdisso,desrevemos quaissãoosrequisitosdearaterização

des-sessistemaseomooletareprepararosdadosneessáriosparaessaaraterização.

Essas informações são apresentadas nas seções seguintes, seguidas da metodologia

propriamente dita.

3.1 Arquitetura dos Sistemas Caraterizados

Ossistemasemfoonestetrabalhosãoumaespeializaçãodesistemasprovedores

de serviços Web tradiionais no sentido de que o usuário aessa todos os reursos

do sistema utilizando reursos da Web. Entretanto, esses sistemas se distinguem

de serviços Web tradiionais por possuir um ou mais omponentes assínronos que

normalmenteexeutamrequisiçõesomputaionalmenteintensivas,àsemelhançade

serviçosemlote em omputadores de grandeporte. Um bomexemplodesse tipode

sistema são osserviços de mineração de dados.

A arquitetura dos sistemas objeto desta metodologia de araterização é

om-posta basiamentede 3omponentes (Figura3.1):

•

•

que provêem serviços sínronos baseados no protoolo HTTP ou outro

proto-olo similar, e que servem de entreposto para as requisições assínronas aos

servidores em lote, assim omo o aesso aos seus resultados, ou seja, são os

responsáveispelaintermediação entre os usuáriose osservidores emlote; e

•

omputaionalmenteintensivasomo algoritmosde mineração de dados.

Figura 3.1: Arquitetura doSistemaObjetode Caraterização

Nesteontexto,osserviçosprovidospelosservidoresinterativossãosínronos,ou

seja,osusuáriossubmetem requisiçõesaos servidoreseaguardam uma resposta dos

mesmos para então submeter uma nova requisição. A arga de trabalho observada

no sistemas interativos é onseqüênia da interatividade dos usuários, ou seja, ela

é função de variáveis omo a freqüênia de submissão de requisições, da natureza

dessas requisições edo usto de ada uma delas.

Ao inorporarmos omponentes assínronos, representados pelos servidores em

lote, háduas mudanças fundamentaisque devemser levadas emonsideração aose

analisara arga. Primeiro, oomportamentodos usuáriosdeixa de ser diretamente

afetado pela latênia das requisições que geralmente não é altano aso de serviços

Web tradiionais, ou seja, o usuário não preisa mais esperar a resposta de uma

requisição para efetuar outra, várias requisições podem ser disparadas em paralelo

pelosusuáriospodendohaverassimsobreposiçãotemporalentreváriosproessosem

lote. Segundo, a arga assínrona gerada pelos usuários é independente da

usuáriopodeontinuarinteragindoomosistemaenquantoumadeterminadatarefa

é exeutada nos servidores em lote, de tal forma que um dado usuário pode estar

submetendorequisiçõesinterativaseemlotequeserãosatisfeitasporservidores

dife-rentessimultaneamente. Nesse segundoaso aargatambémpoderáser fortemente

inueniadapelanaturezados resultados obtidos,ouseja, asoosresultados

enon-tradosnãosejamsatisfatórios,novasrequisiçõesserãosubmetidasaos servidoresem

lote.

Dessa forma, temos que o funionamento desses sistemas pode ser dividido, de

formasimpliada, emtrês meanismos de interaçãodesritos abaixo:

•

servidor interativoe normalmenteespera a resposta para submeter uma nova

requisição. Ou seja, orresponde a interaçõestípias de sistemas WEB

tradi-ionais;

•

as-sínronaaumservidor interativoquea repassaaoservidor emlote

orrespon-dente. Emgeraltrata-sedeumasoliitaçãoomputaionalmenteintensivaque

possivelmente irá demoraralgum tempo (minutos, horas ou até mesmo dias)

para ser nalizada; e

•

assín-rona feita em algum momento no passado, que é armazenada pelo sistema

quandodasua onlusão. Aqualquer momentoduranteautilizaçãointerativa

dosistema, ousuário pode aessara resposta de uma requisição onluída.

Dada a desrição da arquitetura do sistema que pretendemos araterizar, om

seus omponentes e meanismos de interação, devemos denir as dimensões da

a-raterização. A desrição dessas dimensões é apresentada naSeção a seguir.

3.2 Dimensões de Caraterização

Uma metodologia de araterização de omportamento de usuários dos serviços

desritosnaSeção3.1devetratartrêstiposderequisitos: padrãodeaessodos

usuá-rios; padrão das requisições dos usuários; e a natureza dessas requisições. Assim a

metodologiadeveonsiderartantoosomponentesinterativosquantonão-interativos

da arquitetura, além do relaionamento entre eles. É a partir daaraterização de

ada um desses omponentes que se torna possível obter todas as informações

A dimensão padrãode aesso refere-se à modelagem das informaçõestemporais

de arga dos usuários, ou seja, visa determinar a freqüênia das interações entre

usuários e sistemas e determinar o quanto ada uma dessas interação dura. Essa

informação é obtida a partir dos serviços interativos, pois são eles os responsáveis

por todainteração dosistema om osusuários

O padrão de requisições dos usuários é a dimensão que se refere à modelagem

doque ousuário fazenquantoestá interagindo omo sistema, ouseja,quais são as

funionalidades do sistema soliitadas e omo essas soliitações são feitas ao longo

da sessão de interação usuário-sistema. As funionalidades requisitadas podem ser

tanto sínronas quanto assínronas e as mesmas podem estar sobrepostas em uma

mesma sessão. Para a obtenção dessas informações, os sistemas interativos e em

lote, ouseja,osomponentes interativose não-interativos,devemser analisados em

onjunto.

A tereira eúltima dimensão se refere à análise danatureza das requisiçõesdos

usuários,ouseja,modelarosdetalhesdasrequisiçõesassínronasdosusuários. Nesse

tipo de serviço, as tarefas mais importantes a serem analisadas são as assínronas

por serem tarefas que normalmente demandam mais tempo e proessamento. No

entanto, para araterizar essas tarefas deve-se antes entender suas araterístias.

Asinformaçõesneessáriasparaaaraterizaçãodessadimensãosãoobtidasapartir

dos registros de atividadedos servidores emlotes.

Determinadas quais asdimensõesde araterização que devemser onsideradas

pela metodologia, a etapa seguinte é desrever omo deve ser feita a oleta dos

dadosneessários para essa araterização. Dessa forma,aSeçãoaseguir apresenta

detalhadamenteomo essa oleta deve ser feita.

3.3 Coleta de Dados

Aoletadedadoséfeitadeformadesentralizada,ouseja,adaumdossistemas

que ompõem a arquitetura é responsável pelo registro das requisições feitas a ele.

Nossistemas interativososlogspodemser feitosa partirdos logstradiionais

gera-dos pelos servidores Web om algumas alterações para que as requisições a outros

sistemastambémsejamarquivadas,assim omoanaturezadelas. Jáossistemasem

lote devem passar por um proesso de instrumentação ompleta para que todas as

requisições queheguem a eles ousaiam deles seja registradas.

Emambososasos,anoção desessãoéregistradadesdeaoletade dados. Uma

sessãode usuárioéuma seqüêniaontíguade requisiçõessubmetidas porum

um limiarpré-estabeleido. Esta noção é largamente empregada em sistemas Web

e será estendida aqui nosentido de inorporar as requisições assínronas, queserão

onsideradasomo parte da sessão onde elas foramrequisitadas, embora possam se

estender porperíodosde inatividadedousuário oumesmooutrassessões. A

justi-ativapara essa estratégia é que, apesar da sua dispersão temporal, o momentoda

requisiçãoéoúnionoqualousuárioatuadiretamentenoilodevidadarequisição

assínrona.

Todasoliitaçãode um usuárioé feitaatravésdos sistemas interativos,assim os

mesmos são os responsáveis pelo registro delas. Cada uma dessas requisições deve

ser registrada ontendo a identiação da sessão de origem, o dia, mês, ano, hora,

minuto e segundo (a que denominamos timestamp) da requisição, além dos dados

quearaterizamanatureza darequisição,porexemplo,noaso de umasoliitação

deumatarefademineraçãodedados,deve-seregistrarqualoalgoritmoutilizado,os

parâmetrosdos algoritmosesolhidos, além dabase de dados e atributos queforam

seleionados. Uma importanteinformação que deve ser registrada é oidentiador

dousuário assoiadoà sessão de origem datarefa nosistema omoum todo.

Cada requisiçãode usuáriopode fazerom queosistemainterativogereuma ou

maisrequisiçõesaossistemasemlote. Cadavezqueumsistemainterativogerauma

soliitação a um sistema em lote, o mesmo deve registrar a mesma em seus logs.

Além disso, o servidor em lote também deve fazer o registro de que foi aionado.

No sistema interativo de onde originou-se a soliitação, o registro deve onter o

identiador da sessão de origem, um identiador da requisição que a originou, o

identiadordo servidor de destino da requisição eo timestamp, além dos detalhes

e parâmetros da requisição. No servidor em lote de destino deve-se registrar o

identiador da sessão de origem, um identiador da requisição que a originou, o

identiadordo servidor de origem da requisição e o timestamp. Requisições entre

ossistemasemlote tambémpodemoorrereoregistrodessasrequisiçõesdevemser

feitasda mesmaforma.

Para ada requisição submetida, seja dos usuáriosaos sistemas interativos, seja

entre os sistemas que ompõe a arquitetura (interativos e em lote), existe uma

resposta assoiada, ou seja, toda requisição deve ter uma resposta. Da mesma

forma que as requisições são registradas nos logs dos servidores orrespondentes,

asrespostas a essas também devemser registradas, onde osmesmos identiadores

utilizadosnosregistrosdasrequisiçõesdevemserutilizadosnasrespetivasrespostas.

Nestetipodearquitetura,porsetrataremdaintegraçãode servidoresinterativos

emlote,pode oorrer queum determinadasessão de usuáriosejanalizada, mesmo

Independentedom de uma sessão,os proessos ontinuamsendo exeutados até o

m dos mesmos. Assimosregistros preisamontinuar sendofeitosrefereniando a

sessão nalizada até que asrequisiçõesassínronas estejam onluídas.

Nesse proesso de oleta de dados, os identiadores exerem um papel

fun-damental pois serão eles os responsáveis em estabeleer as ligações entre logs de

diferentes servidores, omo veremos na Seção a seguir. Além disso, os relógios dos

servidores que ompõemada um dos sistemas interativos ouem lote, devemestar

sinronizados para manter a onsistênia temporal dos dados, omo também será

disutido a seguir.

3.3.1 Preparação dos Dados

Cada servidor da arquitetura, seja ele interativoou emlote, possui um log

(re-gistro)das requisiçõesfeitasaele,assimomoasrespostasaadaumadelas. Possui

tambémregistrados asrequisiçõesque elefaz aos outros servidores 1

. Assim, após a

oleta dos dados, um passo fundamental é a sua onsolidação, ou seja, a partir de

logsoletadosde formaindependenteedistribuídaentreosservidoresqueompõem

aarquitetura, devemos riar um logúnio que agrupe todos os registros.

Oprimeiropasso desse proesso de agrupamentoé realizaraveriação de

inte-gridadedos registros para quenão haja inonsistênias, ou seja,deve-se veriar se

todoregistrode requisiçãoqueéenviadade umsistemaparaoutropossui oseu

or-respondente informandoquando a requisiçãohegou no sistemade destino,se todo

registro de resposta a uma requisição em um sistema possui o orrespondente no

sistemaqueoriginouarequisição et. Essa veriação de integridade éfeitaatravés

dos identiadoresmenionados naSeçãoanterior, quepermitemaompanhartoda

atrajetóriade uma requisição. Caso aintegridade dos logsseja violada,os mesmos

devemser desartados.

Feita esse veriação de integridade, o próximopasso é o agrupamento

propria-mentedito,oloandotodososregistrosde todosossistemasemumúnioarquivoe

posteriormenteordenandoesse arquivoúniopelotimestampdosregistros. Daívem

a neessidade menionada na Seção anterior de que os servidores de ada um dos

sistemasdevemestar omseus relógiossinronizados,aso ontrárioinonsistênias

podem oorrer, omo por exemplo, uma requisição hegar ao sistema de destino

antes que a mesma tenha sido enviada pelo servidor de origem, ou o registro de

duração de exeução de uma tarefa ser menoroumaior doquerealmente foi. Neste

1

Emboraestejamososservidoresinterativoseemloteomoomponentesatmios,épossível

e usual que haja requisiçõesentre servidoresde mesma natureza, a exemplo de arquiteturas de

últimoaso,ainonsistêniapoderianãoser perebida elevaraumaaraterização

equivoada.

Outra exemplo importante de transtorno que uma dissironização traria seria

om relação a análise do omportamento, no qual os logs poderiam registrar que

uma tarefa de um determinado usuário ou menos tempo em exeução do que

realmenteou.

Finalizado esse proesso de preparação dos dados, o resultado é um únio log

queontémtodos osregistrosde todosossistemas,agrupados deformaonsistente.

Através desse logé possível obter todo o históriode todas as requisições de todos

usuáriosquesubmeteramrequisiçõesaosservidoresdeformadiretaouindireta. Esse

é o log utilizado na extração dos dados neessários para a araterização de arga

dosistema.

3.4 Metodologia de Caraterização

Denida aarquiteturadosistema,asdimensõesde araterização,eaestratégia

de oleta e preparação dos dados podemos apresentar a metodologia de

arate-rização propriamente dita. Apesar de existirem diversos sistemas que poderiam se

enaixarperfeitamentenomodelodearquiteturaapresentado,omomirosopia

vir-tual apresentada em [ABB

+

98℄ e análise de plaenta [PH05℄, a denição de nossa

metodologia está foada espeiamente em sistemas de mineração de dados. No

entanto,omoveremosaseguir,ametodologiaéapliávelaqualquertipodeserviço

Web queapresentearaterístias similares,desdeque asdevidas adaptaçõessejam

feitas.

3.4.1 Visão Geral

Nossa metodologia é modelada de forma hierárquia em três níveis, onde ada

níveléresponsávelpelaaraterizaçãodeumadasdimensõesdenidasnaSeção3.2:

sessões de usuários, omportamento de usuários e tarefas de usuários. O nível de

sessão de usuário ompreende métrias omo o proesso de hegada de usuários ao

sistema,duraçãode sessãoet. Onívelde omportamentode usuáriofoanasações

desempenhadas pelos usuários durante ada uma das suas sessões (ada requisição

que eles submeteram, por exemplo). É importante que esse nível de araterização

expliiteuma araterístiaimportantede sistemasmineraçãode dados: a

sobrepo-siçãotemporalentrerequisiçõessínronaseassínronas,ouseja,ousosimultâneode

quan-tia o proesso de hegada dos trabalhos de proessamento (tarefas), da natureza

delas, dos parâmetros esolhidos para ada exeuçãoet.

Osdoisprimeirosníveisseapliamaqualquersistemaquepossuaaraterístias

semelhantes aos sistemas de mineração de dados. O tereiro nível é que depende

diretamente da natureza do sistema, ou seja, ada sistema possui tarefas próprias,

omaraterístiaspróprias. Assim,énestenívelqueasmétriasdevemseralteradas

para permitir araterizarapliações diferentes.

Os ritérios de ada nível da metodologia podem ser apliados sobre todas as

sessões de usuários ou apenas sobre um sub-grupo dessas sessões. Através de

aná-lise de similaridade nos padrões de requisições de usuários para um dado serviço,

diferentes grupos de sessões de usuários podem ser identiados e a ada um

des-ses grupospodem ser araterizados de formaindependente. Nósapresentamos um

exemplo dessa estratégia posteriormenteemnossos resultados. Nas seções a seguir,

nósdisutimos adauma dostrês níveisdametodologiadearaterização emmaior

detalhe.

3.4.2 Sessões de Usuários

Este nível do nosso modelo de araterização modela o padrão de aesso dos

usuários do sistema. O objetivo nesse nível é enontrar modelos que representem

umainformaçãotemporalrelaionadaàargariadapelosusuáriosqueiniiamuma

sessãonosistema,determinandoquãofreqüentementeelesaessamosistemaequão

longa são essas sessões. Duas métrias diferentes e omplementares são propostas

aqui:

•

ahegadade duas sessões onseutivasao sistema;

•

ativos,isto é,submetendo requisições.

Além dessas, é também importante araterizar o número das requisições

sub-metidas ao sistema durante ada sessão. Isso quantia o número de ações que

ada usuário exeuta enquanto está onetado ao sistema, e omo essas ações são

distribuídastemporalmente. Emnossa metodologianós propomoso uso de um

his-togramadedistribuição dasrequisiçõesporada sessão,mostrando omoassessões

são agrupadas em termos donúmerode tarefas emada sessão.

Aaraterizaçãodesessõesdeusuárioséumaferramentaimportanteparadenir,

Essainformaçãopermiteavaliaroshábitosdosusuários,porexemplodeterminando

períodos duranteos quaishouve uso intenso,e é fundamentalpara a onstrução de

ferramentasde geraçãode arga,porexemplo.

3.4.3 Comportamento de Usuários

Umaetapaessenialnametodologiade araterizaçãoéaanálisedos padrõesde

requisiçõesdos usuários. Isso signiaaanálisede adauma dasrequisiçõesqueele

requisitaaadafunionalidadedosistemaeemomoessespedidosserelaionam

du-ranteumasessão. Umaténiademodelagemqueéamplamenteutilizadanestes

a-soséoCustomerBehavior ModelGraph,ouCBMG[MA00,HTMRG

+

04,NAR

+

04℄.

CBMGs são grafos de transição de estado emque ada nó ouestado representa

al-guma funionalidade do sistema que pode ser requisitada pelo usuário e as arestas

representam as transiçõesentre as funionalidades disponíveis. Cada aresta reebe

um valor que representa a probabilidade de um usuário deixar um determinado

estadoe aionaroutro, o queaontee quando eledeidesoliitar umanova

funio-nalidade, uma vez que apreedente já foi exeutada.

A metodologia CBMG é uma representação semantiamente ria e ondensada

do omportamento dos usuários, onde diferentes grupos de usuários podem ser

re-presentadosporCBMGsindividuaisquesediferemnos estadosonsideradosepelas

probabilidades das transições entre eles. Quando esta separação nos grupos é

de-sejada, ténias de agrupamento são usadas para determinar as melhores soluções

para agruparsessões.

Entretanto, CBMGs são limitadosà representação de omportamentosde

usuá-riosquesãosempreseqüeniais,ouseja,ondeapenasumafunionalidadeéaessada

por vez, e transições aonteem quando o usuário naliza uma determinada

funi-onalidade e deide iniiar um outra. Os sistemas alvo dessa metodologia de

ara-terização, entre os quais se inluem sistemas de mineração de dados, estão sujeitos

a omportamento de usuários que são essenialmente seqüeniais omo a riação

de tarefas e avisualização de seus resultados, mas também a atuações assínronas,

uma vez que os proessos de mineração podem ser exeutados independentemente

das sessões dos usuários. Os usuários podem deidir interagir de forma

ompleta-mente seqüenial, esperando que ada tarefa seja nalizada antes de requisitar um

nova funionalidade, mas eles podem também optar em trabalhar om outra

ta-refa enquanto esperam uma determinada tarefa nalizar a exeução. Do ponto de

vistaderepresentaçãodoomportamento,devemosserapazes dearaterizartanto

transições referentes ao omportamento dos usuários, quando uma nova requisição

exeutadas(freqüentementeindependentes) emparalelo. Issosigniaqueaténia

doCBMG,seapliadaem suaformaonvenional,nãopode serusadaparamodelar

taisapliações. Esta foia motivaçãopara a riaçãode uma nova representação que

permitamodelar oomportamentoquandoosusuários iniiammúltiplasatividades

em paralelo. Nós denominamos esse modelo de USIMG, User-System Interation

Model Graph, o qual é introduzido neste trabalho. No USIMG, ada vértie

repre-senta um estado no sistema, que pode ompreender apenas uma ação interativa,

a exemplo do CBMG, ou uma ação em lote, ou ambas, o que é representado pelo

hamadoestadoomposto, queagregaduas oumaisaçõesque estejamaonteendo

nosistema omo um todosob osauspíios de um dado usuário.

Para riar os USIMGs, o primeiro passo é identiar as funionalidades do

sis-tema edeterminar osmarosque indiamoiníio e om de ada uma delas. Cada

uma dessas funionalidades identiadas formam o onjunto de estados que

deno-minamosde estadossimples. Umavez feitoisso, opróximopasso éordenar

rono-logiamenteo iníio e o m de ada uma das funionalidades. Nós podemos assim

identiardinamiamente osestados quenós denominamosde estados ompostos

observando omomentoquando múltiplasatividadesforaminiiadas,masque ainda

não foram nalizadas. Esses estados ompostos são assim uma omposição de dois

ou mais estados simples que estão ativos simultaneamente. A Figura 3.2 ilustra o

proesso para a riação dos USIMGs. Mais uma vez destaamos a importânia da

sinronizaçãodos relógiosentre osservidores, aso ontrário, aidentiação

equivo-ada do iníio e/ou do m de uma requisição do usuário pode aarretar a geração

de estados que não representem de formareal oomportamentodomesmo.

Figura3.2: Proesso de Geraçãodos USIMGs

O algoritmode onstrução dos USIMGs é bastante simples e se baseia emuma

requisições dos usuários enontradas nologs, ordenadas ronologiamente.

Primei-ramenteinsere-seoestadodeiníiodasessãonoUSIMG.Posteriormente,paraada

elementoontido nessa lista, veria-se qualo seu tipo, ouseja,iníio oum. Casa

sejao iníiode uma requisição,insere-se amesma emumaoutra listaqueontém o

estadoatualdousuário. Feitaainserção,insere-seoonteúdodessalistanoUSIMG,

pois esse onteúdo é agora um novo estado do usuário. Além disso, insere-se uma

arestanoUSIMGdoúltimoestadodomesmopara oestadoqueaaboude ser

inse-rido. Se otipodarequisiçãofor om, ouseja,a requisiçãofoinalizada, remove-se

a mesma da lista de estado que mantém o estado atual do usuário. Se essa lista

não estivervazia, signiaqueousuárionalizouuma determinadatarefa mas

on-tinuatrabalhandoomoutras,ouseja,um novoestado,representado peloonteúdo

atual dalistade estados. Basta,então, inserirnovamente oonteúdo dessa listano

USIMG, além da aresta do último estado do USIMG para o estado que aabou de

ser inserido. Se após a remoção a mesmapermaneer vazia, signia que o usuário

simplesmentenalizou todas suas tarefas pendentes, ou seja, não foi para nenhum

novo estado. Ao nal do tratamento de todas as requisições, basta aresentar o

estado de m de sessão e uma aresta do último estadodo USIMG para esse estado

nal. A seguir nós apresentamos o pseudo-ódigo desse algoritmo de álulo dos

estadosdos USIMGs:

CalulaEstadosUSIMG(

lista

requisicoes

1.

estado

anterior

=

2.

InsereEstadoU SIM G

(

estado

anterior

);

2. para toda

(

requisicao

ı

∈

lista

requisicoes

)

3. se

(

requisicao

ı

.tipo

=

)

4.

InsereLista

(

lista

estado

atual, requisicao

ı

);

5.

InsereEstadoU SIM G

(

lista

estado

atual

);

6.

InsereArestaU SIM G

(

estado

anterior, lista

estado

atual

);

7.

estado

anterior

=

lista

estado

atual

;

8. senão se

(

requisicao.tipo

=

)

9.

RemoveLista

(

lista

estado

atual, requisicao

ı

);

10. se

(

T amanhoLista

(

lista

estado

)

>

0)

11.

InsereEstadoU SIM G

(

lista

estado

atual

);

12.

InsereArestaU SIM G

(

estado

anterior,

lista

estado

atual

);