Projecto e Implementação de um Sistema de Data Webhousing

Projecto e Implementação de um Sistema de Data
Webhousing
Nélio Guimarães, Alice Marques
{pg11036, pg10914}@alunos.uminho.pt
Resumo. Com a globalização e a competição entre organizações, as formas
usuais de negócio estão a mudar. O que era normal no passado está agora
ultrapassado devido ao aparecimento da internet. Esta recente ferramenta de
negócio está a diminuir o contacto directo com os clientes. Pela Internet (sites
das organizações) os utilizadores podem navegar livremente enquanto
observam o que o site lhes oferece. Assim, é muito importante para as empresas
compreenderem padrões de navegação, tempos de sessão, entre outras
características dos seus clientes. Este trabalho de pesquisa, pretende
implementar um sistema de data webhousing desenhado para suportar a
informação sobre o acesso a um determinado site.
Palavras chave: data webhouse, clickstreams, logs, data warehouse, clique,
crawlers, web.
1 Introdução
Em 1992 surgiu pela primeira vez um conceito que veio mudar o mundo tal como o
conhecíamos até essa altura. A World Wide Web (WWW) veio alterar costumes,
conceitos e acima de tudo formas de vida. Diariamente a Web é inundada por novos
utilizadores, justificando assim o forte investimento que as organizações fazem sobre
este espaço. Cada vez mais uma organização que não possua um sitio na Web é vista
como uma organização sem relevância empresarial, e mesmo aquelas que possuem
locais na Web têm preocupações acrescidas no que diz respeito à sua administração.
Assim como o hall de entrada de uma empresa poderá ser o espelho desta, também as
páginas do seu sítio Web devem ter um design apelativo e acima de tudo profissional,
pois será este o primeiro contacto com potenciais clientes no comércio electrónico.
No entanto, a administração Web vai muito mais além da questão estética,
passando desde a questão tecnológica (toda a infra-estrutura que suporta os conteúdos
Web) até à análise de acessos. Assim como no comércio tradicional, em que conhecer
os clientes e as suas características pode ser uma mais valia competitiva, também no
mundo Web o conhecimento sobre clientes – aqui a noção de cliente deve ser
entendida não só como um potencial comprador de algo (comércio electrónico) mas
também como um simples visitante – pode trazer alguma vantagem competitiva ou
sucesso na Web. É, então por isso, que muitas organizações começam a fazer análises
exaustivas aos seus ficheiros de Web logs de forma a estabelecer padrões de
navegação e/ou perfis de utilização. Este tipo de análises pode servir simplesmente
para organização de conteúdos Web e elaboração de estatísticas, mas também como
fonte de dados para a construção de modelos de recomendação – entenda-se modelos
de recomendação como o resultado de algoritmos de data mining sobre o conjunto de
dados – de forma a descobrir quais os produtos e serviços que mais interessam aos
seus potenciais clientes, afim de diminuir o tempo de pesquisa e aumentar o grau de
satisfação. Um cliente satisfeito poderá voltar a comprar e implicitamente é um
excelente meio de divulgação.
Usualmente a tecnologia utilizada para estabelecer padrões de navegação assenta
muito no conceito de data webhouse (DWeb). Em [1] a definição de DWeb pode ser
vista como uma instância de um data warehouse (DW), povoado com dados
provenientes de clickstream, de forma a fornecer um conjunto de metadados que serão
a base para análises On-Line Analytical Processing (OLAP). Em suma, o que se
pretende com a elaboração deste artigo de investigação é a apresentação de um
conjunto de técnicas e modelos de dados com vista à elaboração de um DWeb capaz
de responder a um vasto leque de interrogações, de forma a obter informação
necessária para estudos estatísticos e futuras remodelações do site.
2 Sistemas de data webhousing
O processo de tomada de decisão em organizações modernas nem sempre é uma
tarefa simples. Na realidade, um sistema de apoio à decisão é sempre algo bastante
complexo. O grande volume de informação e as constantes alterações às regras de
negócio exigem a estes sistemas constantes mutações, tornando-se por vezes bastante
instáveis. Contudo, as possibilidades de análise que estes sistemas (quando bem
modelados) colocam ao dispor dos agentes de tomada de decisão, são uma mais valia
no competitivo mundo actual.
Um dos pontos fortes dos sistemas de DW é a modelação dimensional [1][12]. Ao
contrário do tradicional modelo relacional [2] baseado em entidades interligadas entre
si, a modelação dimensional assenta no conceito de dimensão e tabelas de facto [1].
Sendo um DWeb uma instancia de um DW, em que as fontes de dados são ficheiros
de log de servidores Web, é igualmente possível fazer estudos segundo vários eixos
de análise e assim obter conhecimento, que de outra forma seria algo extremamente
difícil.
A integração dos dados de clickstream num DWeb permite diversos tipos de
análises. Questões relacionadas com comportamento de clientes que visitam o sitio
Web, hot pages, como são efectuadas as pesquisas, qual a sequência de cliques, quais
as áreas mais procuradas entre outras questões, serão de fácil análise. A informação
de clickstream não é apenas mais uma fonte de dados, esta apresenta uma série de
características que a diferencia dos dados recolhidos de um sistema operacional.
Habitualmente é bastante heterogénea devido há não uniformização dos formatos e
poderá estar espalhada pelos vários servidores da organização ou até mesmo em
servidores fora desta, dificultando o processo de recolha de dados.
2.1 Fontes de dados do Data Webhouse
As fontes de um DWeb podem surgir de dois locais distintos. Dos locais mais
clássicos, como os sistemas operacionais que contêm informação operacional
(clientes, produtos, fornecedores, etc.) e de ambientes Web: dados de clickstream [3].
2.2.1 Formatos Standard de Log
Usualmente nos ficheiros de log encontram-se os pedidos efectuados via HTTP, pelos
browsers ao servidor Web. Como em todas as tecnologias Web, também no formato
dos logs existem vários standards, nomeadamente os criados pelas entidades: World
Wide Web Consortium (W3C) e National Center for Supercomputing Applications
(NCSA).
• NCSA Common Log Format (CLF).
• NCSA Extended Common Log Format (ECLF) ou Combined Log Format.
• W3C Extended Log Format (ELF)
Definido pela primeira vez em [4], [5] o CLF é um tipo de log de formato fixo
ASCII, como tal não pode ser alterado ou adaptado. Está disponível para sítios Web e
para serviços SMTP e NNTP. Foi criado com a intenção de acabar com os formatos
proprietários tornando-se assim no primeiro standard. Guarda informação referente a :
• Remote host – endereço IP do computador que acedeu ao site.
• Ident – Identidade remota fornecida pelo cliente do pedido HTTP, pode ser
desconhecida nesse caso representa-se por ‘-‘.
• Authuser – O nome com que o utilizador se autenticou no site, pode ser
desconhecido nesse caso representa-se por ‘-‘
• Date – Data e hora em que o servidor terminou de atender o pedido.
• Request – Indica o pedido feito ao servidor.
• Status – Código de estado http retornado ao cliente.
• Bytes –Numero de bytes enviados pelo servidor ao cliente.
De seguida apresenta-se um fragmento de um log de um servidor Web no formato
CLF:
66.82.9.16 - asilva [30/Aug/2004:01:12:27 +0000] "GET
/images/main_nor2.gif HTTP/1.1" 200 73797
"http://www.utilities.h12.ru/Free-Download-C-17.html" "Mozilla/
Assim como o CLF também o ECLF [5] foi criado pela NCSA. É o resultado do
CLF por acréscimo de dois novos campos, o referenciador e o agente HTTP. Cada um
deles contém a seguinte informação:
• Referenciador – representa a página que conduziu o utilizador até ao sitio Web,
caso seja desconhecido representa-se por ‘-‘.
• Agente HTTP – identifica o navegador Web.
Um exemplo do formato ECLF é o seguinte:
189.12.157.159 - - [28/Jan/2008:00:00:01 -0500] "GET
/image/degois.jpg HTTP/1.1" 200 5199
"http://repositorium.sdum.uminho.pt/handle/1822/4641" "Mozilla/4.0
(compatible; MSIE 7.0; Windows NT 5.1)"
Criado pela W3C com intenção de obter um standard que satisfizesse as
necessidades de clientes, servidores e proxies [6],[7], o ELF encontra-se no formato
ASCII e é possível ser parametrizado. Ao contrário dos formatos anteriores, o formato
ELF contém no inicio um cabeçalho informando sobre os parâmetros que estão a ser
guardados. Um exemplo do formato ELF é o seguinte:
#Version: 1.0
#GMT-Offset: -0500
#Software: Oracle9iAS Web Cache/2.0.0.2.0
#Start-Date: 2002-10-24 00:00:15
#Fields: c-ip c-dns c-auth-id date time cs-method cs-uri sc-status
bytes cs(Cookie) cs(Referrer) time-taken cs(User-Agent)
#Date: 2002-10-24 00:00:15
10.32.37.2 pcmfr03.someorg.org jsmith 2002-10-24 00:00:18 GET
/admin/images/office.jpg 200 350
"Server_Webcache_pool=1443321748;ORA_UOM_AGID=%2fMP%2f8M7%3f%3fDh3
V H"
"http://www.someorg.org/nl/about.html" 6 "Mozilla/4.5 [en] (WinNT;
I)"
Na implementação realizada, os servidores Web guardam os ficheiros de log no
formato NCSA Extended Common Log Format (ECLF).
2.2 Modelação Dimensional
A modelação de um DWeb pode ser vista da mesma forma que a modelação de um
DW tradicional. Assim como na modelação de um DW, também na modelação de um
DWeb a escolha do nível de detalhe (tradicionalmente chamado de granularidade [1])
é uma tarefa extremamente importante, visto que é a partir desta definição que se
poderá conhecer o tipo de factos a analisar. Na modelação do DWeb em questão, três
níveis de detalhe poderiam ser utilizados:
• Registo de sessões completas por hora.
• Registos por pedido.
• Registo de pedidos por sessão.
Comparando os três níveis de detalhe optou-se por fazer a implementação do grão
que permite a analise do registo de sessões completas por hora. Analisar factos de
registo por pedidos não se apresentou como uma mais valia, ao mesmo tempo, com o
modelo construído para o registo de sessões completas por hora, é igualmente
possível construir a sequência de cliques (clickstream) de uma sessão.
2.2.1 Tabela de Factos
Na figura 1 é apresentado o modelo dimensional para a análise de registo de sessões
completas por hora. Na realidade, com o esquema apresentado a análise de registo por
sessão é também uma possibilidade, visto que a tabela ponte (TP_Session) usada
contém todos os registos de pedidos efectuados numa determinada sessão.
Figura 1. – Esquema dimensional para análise de sessões completas.
Como é possível verificar as medidas escolhidas são:
•
•
•
•
•
•
•
•
•
•
Pedidos – Número de pedidos efectuados na sessão.
m_Gets – Número de pedidos efectuados com o método get.
m_Post – Número de pedidos efectuados com o método post.
m_Head – Número de pedidos efectuados com o método head.
m_Outros – Número de pedidos efectuados com outros métodos.
status_Sucesso – Número de pedidos efectuados com sucesso.
status_redirecionado – Número de pedidos redireccionados.
status_Erro – Número de pedidos falhados.
bytes_enviados – Número de bytes enviados pelo servidor.
session_duration – Tempo de duração da sessão.
No total, o modelo dimensional é constituído por sete dimensões (Computador,
Referenciador, UserAgent, Data, Tempo, Pedido) uma das quais degenerada [1]
(SessionID), uma tabela ponte (TP_session) e dez medidas.
2.2.2 Dimensão Computador
A dimensão computador (tabela 1) visa identificar o computador de onde é
proveniente o pedido http ao servidor. A informação obtida é construída através do
endereço IP registado nos logs. Usando um ficheiro de dados [8] que contém o
intervalo de endereços de IP alocados por Internet Service Provider (ISP) é possível
obter o código ISO assim como o nome do país da entidade detentora do IP.
Tabela 1 – Atributos da dimensão Computador.
Atributo
Descrição
Exemplo
Ipaddress
Endereço de IP da entidade detentora do
pedido HTTP
Código ISO do país de origem do IP
País de origem da entidade dentora do IP
“87.196.186.46”
CódigoISOPaís
Pais
“PT”
“Portugal”
2.2.3 Dimensão User Agent
Um agente http (tabela 2) é a aplicação do cliente, conjuntamente com um protocolo
de rede, usada para efectuar o pedido ao servidor. Um agente pode ser de vário tipos,
entre eles, Web browsers, clientes de e-mail, search engine bots (“crawlers”).
Tabela 2 – Atributos da dimensão User Agent.
Atributo
Descrição
Exemplo
Agent_id
Tipo
Agent_name
Texto_log
Chave identificadora do agente.
Tipo do agente.
Nome do agente.
Texto existente no ficheiro log referente ao
agente.
1
“Crawler”
“GoogleBot”
2.2.4 Dimensão Calendário
Para caracterizar o dia de ocorrência do facto construiu-se a dimensão calendário
(tabela 3). Esta dimensão contém informação detalhada sobre datas para um período
de doze anos.
Tabela 3 – Atributos da dimensão Calendário.
Atributo
Data_id
Dia_semana
Dia_semana_nr
Dia_mes_nr
Dia_ano_nr
Tipo_dia
Semana_nr
Mes
Mes_nr
Quarter
Semestre
Ano
Descrição
Chave identificadora do dia.
Nome do dia da semana.
Número do dia da semana.
Número do dia no mês.
Número do dia no ano.
Fim-de-Semana ou dia de trabalho.
Número da semana no ano.
Nome do mês.
Número do mês no ano.
Número do trimestre no ano.
Número do semestre no ano.
Ano.
Exemplo
1
“Monday”
3
20
20
“weekend”
3
“Janeiro”
1
1
1
2008
2.2.5 Dimensão Hora
A dimensão Hora (tabela 4) guarda informação referente a cada uma das vinte e
quatro horas do dia, caracterizando desta forma a hora de ocorrência do facto.
Tabela 4 – Atributos dimensão Tempo.
Atributo
Hora
Período
Descrição
Exemplo
Chave identificadora da dimensão tempo.
Corresponde a hora.
Período do dia.
15
“Tarde”
2.2.6 Dimensão Referenciador
Por referenciador (tabela 5) deve entender-se o conjunto de atributos que identificam
o local que referenciou o pedido http. Este pode ser interno ao site, ou seja, um link
para o próprio site, ou então um link externo ao site.
Tabela 5 – Atributos da dimensão Referenciador.
Atributo
referrer_id
Tipo
URI
motor_pesquisa
Descrição
Chave identificadora do referenciador.
Tipo do referenciador
Local que referenciou
Se foi proveniente de um motor de pesquisa.
Exemplo
1
“interno”
“www.google.pt”
“y”
2.2.7 Dimensão Pedido
A dimensão pedido (tabela 6) identifica o conteúdo pedido ao site. De uma forma
simples, um pedido pode ser visto como objectos individuais descarregados após um
clique num link. Conceptualmente, um pedido pode ser entendido como tudo aquilo
que é descarregado após o clique num link. Contudo, todos os objectos descarregados
são registados individualmente, isto é, quando se abre uma página Web que contém
um número n de objectos no ficheiro de log, ficam registado os n pedidos, um por
cada objecto.
Tabela 6 – Atributos da dimensão Pedido.
Atributo
request_id
Request
Tipo
tipo_classe
Descrição
Chave identificadora do pedido.
Texto do pedido que ficou registado no log.
Tipo do pedido.
Tipo da classe do pedido
Exemplo
1
“/”
“pdf”
“PS”
2.2.8 Dimensão Sessão
Sendo a sessão uma dimensão degenerada [1], não possui qualquer tabela. É um
índice inteiro sequencial que identifica a sessão, permitindo desta forma utilizar
funções de agregação sobre o atributo sessão.
3 Povoamento do Data Webhouse
Assim como num sistema de DW, também em sistemas de DWeb os processos ETL
devem ser conceptualmente vistos da mesma forma. No entanto, devido à
heterogeneidade das fontes e ao eventual volume de dados a integrar, a
implementação dos processos de ETL requer especial atenção.
De uma forma simplista, o processo de ETL para o sistema em questão (figura 2)
consiste numa fase de extracção de dados, seguida de uma fase de transformação, e
por fim uma fase de integração no sistema final. Todos estes processos são suportados
por uma área de retenção (AR), que para além de servir como uma zona
centralizadora serve também como um local onde os dados podem ser combinados.
Figura 2 – O Processo de ETL.
3.1 Extracção
O processo de extracção de dados pode ser visto como um mecanismo de recolha, que
simplesmente extrai os dados das fontes e os coloca na AR. Tecnicamente, os dados
podem ser recolhidos de forma incremental ou completa. De forma incremental, os
dados colectados são aqueles que não foram recolhidos desde o último acesso. Este
pode ser um mecanismo especialmente útil caso os ficheiros de log se encontrem
espalhados por vários servidores da organização, ou até mesmo fora desta.
Num caso de recolha completa, os dados são colectados ao mesmo tempo. Ora,
para o sistema em questão, visto que é recolhido um número limitado de ficheiros de
log, usualmente um ficheiro por dia, o método de recolha completa será o mais
adequado.
Os dados são recolhidos diariamente entre as 00h15 e as 00h20 de um local
partilhado na rede e colocados na AR de forma a serem convenientemente
trabalhados. Simultaneamente, um processo acede à Web baixando um ficheiro que
será utilizado na resolução de IPs.
3.2 Transformação
Durante a fase de transformação, são realizadas as operações necessárias para a
integração dos dados no DWeb. Os dados sofrem operações de junção, limpeza, entre
outras. Quando prontos e uniformizados, os dados são colocados em tabelas na área
de retenção onde são mantidos, para posterior carregamento para o DWeb.
3.2.1 Identificação de sessões
Tendo os registos das visitas disponíveis, é necessário reconstruir a sessão do
utilizador. Uma sessão pode ser definida como o conjunto de cliques feitos por um
utilizador, desde o momento em que este acede ao website, até ao momento em que o
abandona. A identificação de sessões visa agrupar, num identificador único, todas as
acções realizadas por um utilizador no site.
Existem dois tipos de estratégias para reconstrução de sessões: pró-activas e
reactivas[9]. As estratégias pró-activas atribuem um identificador de sessão enquanto
o utilizador está a interagir com o site. Por outro lado, as estratégias reactivas tentam
atribuir um identificador de sessão a cada pedido, depois destes terem ocorrido.
Nos ficheiros de log utilizados para a realização deste trabalho, não existia
nenhuma identificação de sessão, pelo que as técnicas utilizadas para a reconstrução
de sessões foram técnicas reactivas, ou seja, o identificador de sessão será atribuído
pela análise dos ficheiros de log.
Identificar todos os pedidos feitos pelo mesmo utilizador durante um acesso,
constitui o primeiro passo para a reconstrução de sessões. Obtêm-se todos os
endereços de IP ordenados por data e hora e, caso exista uma diferença maior do que
15 minutos entre dois pedidos sequenciais p1 e p2, considera-se que o p2 pertence a
uma nova sessão. O intervalo de 15 minutos de inactividade entre dois pedidos
sequenciais foi escolhido tendo em conta três parâmetros: o tipo de utilizadores, o tipo
de acessos e o conteúdo informativo. O facto de ser um site para pesquisa de
informação, leva-nos a concluir que o tipo de acesso por parte de utilizadores é
directo e conciso, logo o tempo de inactividade de 15 minutos oferece uma boa
margem de segurança na identificação de sessões.
3.2.2 Identificação de crawlers
Um crawler pode ser definido como um programa que utiliza o protocolo HTTP[11] e
que tenta passar por um utilizador normal de modo a conseguir obter informação
(todo o conteúdo de um site). Os objectivos deste tipo de programas podem ser vários,
alguns são benéficos para a organização (caso dos crawlers de motores de pesquisa) e
outros prejudiciais (caso dos crawlers maliciosos que tentam obter informação
confidencial).
Muitos dos acessos a websites são feitos por crawlers e não por utilizadores
comuns. Em [10] podemos ver que 5% a 40% dos registo de visitas de um site são
feitas por crawlers, provocando um grande número de registos nos logs dos
servidores Web, criando assim uma falsa imagem de utilização do site. De facto, os
responsáveis pela administração Web das organizações podem de várias formas
restringir o acesso a este tipo de programas. Mas será que assim o pretendem? Será
benéfico para as organizações este tipo de restrições?
Analisando cuidadosamente algumas estatísticas, verificamos que a grande maioria
dos acessos a sites são referenciados por links externos, links recolhidos por crawlers
e indexados por motores de pesquisa. Ora restringir o acesso não é de facto do
interesse das organizações. Contudo existem várias técnicas que podem ser
implementadas de forma a minimizar a percentagem de acessos por crawlers nas
estatísticas globais.
A técnica utilizada na implementação do DWeb em questão, consiste em tentar
identificar os crawlers com recurso ao campo user agent, comparando o valor
existente no campo com uma lista de crawlers já conhecidos. Este método apresenta
no entanto alguns problemas. Na verdade, funciona apenas caso os logs do servidor
Web apresentem o campo user agent e apenas permite detectar crawlers previamente
conhecidos. Um problema adicional advém do facto de ser necessário manter a lista
de crawlers conhecidos sempre actualizada, colocando assim um esforço adicional na
manutenção do DWeb.
3.2.3 Construção das dimensões e tabela de factos
Elaborado todo o pré-processamento dos dados, é agora necessário construir as
dimensões e a tabela de factos.
A dimensão calendário é gerada automaticamente na altura da criação do DWeb
para um período de 11 anos, a começar em 01-01-2008 e a acabar em 31-12-2019. Tal
como na dimensão calendário, também a dimensão hora é gerada de forma
automática na altura de criação do DWeb.
No caso da dimensão pedido esta é alimentada pela informação existente nos
ficheiros de log do servidor. Os dados do ficheiro são processados e limpos para
posterior povoamento da dimensão.
Relativamente à dimensão referenciador esta é construída com a informação
existente nos ficheiros de log cruzada com a informação de uma tabela contendo os
principais motores de pesquisa, de forma a identificar se o site que referenciou o
pedido é ou não um motor de pesquisa.
A dimensão computador é construída a partir do processamento dos dados dos log,
complementada com a resolução de IPs. A identificação da entidade detentora do IP é
feita recorrendo a um ficheiro que contém a informação dos IPs alocados por ISP.
Por fim a dimensão user agent é construída através dos ficheiros de log dos
servidores Web. A identificação do user agent utilizado vai permitir saber se o pedido
foi efectuado por um crawler ou por um utilizador normal.
Depois de preenchidas todas as dimensões, atribuem-se chaves de substituição [1]
a cada um dos registos. As chaves de substituição das dimensões são números
sequenciais sem qualquer significado.
Após construídas as dimensões, e atribuídas as chaves de substituição, é altura de
construir a tabela de factos para o grão escolhido. Existem várias medidas a serem
preenchidas na tabela de factos para análise de secções completas. Todas estas
medidas são calculadas a partir da informação extraída directamente dos ficheiros de
log, nomeadamente a partir de:
• Pedidos – Número de pedidos efectuados na sessão, é a contagem de todos os
pedidos efectuados durante a sessão.
• m_Gets – Número de pedidos efectuados com o método get, é a contagem de
todos os pedidos da sessão em que o método utilizado foi o get.
• m_Post – Número de pedidos efectuados com o método post, é a contagem de
todos os pedidos da sessão em que o método utilizado foi o post.
• m_Head – Número de pedidos efectuados com o método head, é a contagem de
todos os pedidos da sessão que o método utilizado foi o head.
• m_Outros – Número de outros pedidos, é a contagem de todos os pedidos da
sessão, em que o método utilizado não foi nenhum dos três anteriores.
• status_Sucesso – Número de pedidos efectuados com sucesso, é a contagem de
todos os pedidos da sessão que foram respondidos com sucesso pelo servidor.
• status_redirecionado – Número de pedidos redireccionados, é a contagem de
todos os pedidos da sessão que foram redireccionados pelo servidor.
• status_Erro – Número de pedidos falhados, é a contagem de todos os pedidos da
sessão que não foram respondidos pelo servidor.
• bytes_enviados – Número de bytes enviados pelo servidor Web durante uma
sessão, é a soma do número de bytes enviados em cada um dos pedidos da
sessão.
• session_duration – Tempo de duração da sessão, é a soma do tempo que
demora a servir cada uma dos pedidos da sessão.
Tendo já construído todas as dimensões e a tabela de factos falta apenas construir
a tabela ponte. A chave primária da tabela é uma chave composta, em que cada um
dos atributos é uma chave estrangeira para a tabela de factos e para a dimensão
pedido. Para além da chave primária composta, a tabela ponte é guarnecida de um
número sequencial indicador da ordem do pedido na sessão. Este numero é calculado
através do campo data e tempo do ficheiro de log, permitindo assim construção de
todos os pedidos de uma sessão.
3.3 Integração e Operações
Terminado o processo de transformação de dados, estes encontram-se prontos para
serem integrados no DWeb. No DWeb devem ser criadas tabelas com a mesma
estrutura das dimensões e da tabela de factos existentes na área de retenção, pois desta
forma a integração dos dados torna-se mais simples, não sendo necessário executar
queries muito complexos.
O processo de carregamento de dados terá de seguir uma ordem específica, caso
contrário problemas de violação da chaves estrangeiras podem acontecer. Assim
sendo, a integração dos dados no DWeb é feita na seguinte ordem: primeiro integramse as dimensões, depois integra-se a tabela de factos (possui chaves estrangeiras para
todas as dimensões) e por fim a tabela ponte.
Ao integrar os dados nas dimensões é necessário ter algum cuidado para não serem
inseridos registos repetidos. De facto, podem já existir valores nas dimensões
resultantes de povoamentos anteriores. Para prevenir problemas de valores repetidos
alguns cuidados são fundamentais. Antes de se povoar uma dimensão com um novo
registo verifica-se se ele já existe. Caso exista pode ser necessário actualiza-lo. Caso
ainda não exista o novo registo vai ser inserido normalmente na respectiva dimensão.
Na tabela 7 são apresentados os tempos de processamento para o primeiro
povoamento, obviamente que para os povoamentos seguintes a dimensão calendário e
hora não serão alteradas, esperando-se assim uma ligeira quebra no tempo total de
processamento. Como se pode constatar, o maior esforço computacional encontra-se
no povoamento da dimensão computador e nas tabelas de facto e ponte. Estes valores
são facilmente explicados com base em dois factos: a dimensão computador utiliza
um processo extra, computacionalmente pesado para a resolução de IPs e as tabelas
de facto e ponte no seu povoamento fazem uso de várias junções (é sempre uma
função de elevado peso computacional, dependendo do tamanho da tabela) entre
tabelas.
Tabela 7 – Tempos de processamento.
Processo
Descrição
Tempo
pov_dim_cal
pov_dim_hora
Pov_dim_ref
Pov_dim_agnt
Identf_sessoes
Pov_dim_req
Pov_tf_tp
Pov_dim_comp
Povoamento da dimensão calendário
Povoamento da dimensão hora
Povoamento da dimensão referenciador
Povoamento da dimensão user agent
Identificador de sessões
Povoamento da dimensão pedido
Povoamento da tabela de facto e tabela ponte
Povoamento da dimensão computador
1 seg.
1 seg.
2 seg.
3 seg.
1min 2 seg.
2 min 9 seg.
7 min 22 seg.
10 min 8 seg.
4 Geração de Relatórios
Tendo o DWeb construído e os dados integrados, é agora necessário disponibilizar a
informação aos administradores do site para que eles possam através da análise dessa
informação, melhorar os serviços disponíveis.
Vão ser gerados relatórios para três tipos: cralwers, utilizadores normais e todos os
acessos. Os relatórios disponibilizados serão, diários, semanais, mensais e anuais.
Os relatórios diários serão construídos depois da integração diária e são
disponibilizados aos administradores até ás 10 horas do dia seguinte. Os semanais são
construídos depois da integração do ultimo dia da semana, e são entregues na
segunda-feira da semana seguinte aquando da entrega do relatório diário. Os mensais
são construídos após a integração do ultimo dia do mês e são entregues no primeiro
dia do mês seguinte. Por fim os anuais são construídos após a integração do ultimo
dia do ano, e são entregues durante o decorrer da primeira semana do ano seguinte.
A estrutura de cada relatório será idêntica mudando apenas o nível da hierarquia
(Ano, Mes, Semana, Dia) ao qual são agregados os dados.
Cada relatório é composto por um pequeno resumo (informação estatística relativa
ao período de analise) e por diferentes secções: analise de acessos por país, hot pages,
páginas de entrada e de saída do site, tipos de ficheiros mais pedidos, tipo de browser
mais utilizado, principais referenciadores, quais as alturas de maior acesso (hora, dia,
semana, mes), entre outros
Um exemplo de uma secção do relatório, em que é analisado a distribuição de
sessões por pais, é o seguinte.
Figura 3 – Distribuição de sessões por país.
5 Conclusões e Trabalho Futuro
Quando se parte para a implementação de um sistema analítico algumas decisões têm
de ser tomadas e validadas antes de se iniciar a modelação do sistema.
Para o projecto em questão algumas interrogações funcionais surgiram.
Obviamente que quando surgem interrogações algumas decisões têm de ser tomadas
de forma a contornar qualquer problema futuro. A primeira interrogação a surgir
relacionava-se com a escolha do sistema de gestão de bases de dados. Inicialmente a
escolha recaiu sobre a ferramenta MySQL, no entanto feitos alguns testes de carga
verificou-se que a versão 5.1 era extremamente instável e não escalonável, isto é,
grandes volumes de informação provocaram algumas falhas no sistema, optou-se
então por uma ferramenta consolidada do mercado, o Microsoft SQLServer.
Um outro problema surgiu no momento da especificação do nível de detalhe da
dimensão hora. Sendo um site em que o volume de acessos por minuto não é
demasiado concluiu-se que fazer a analises á hora seria o mais indicado, desistindo da
ideia de analisar ao minuto ou até mesmo ao segundo.
Um novo problema surgiu aquando da implementação do processo de resolução de
IPs do povoamento da dimensão computador. Inicialmente fez-se uso de uma
biblioteca já existente, no entanto quando submetida a alguns testes, vários IPs
ficaram por resolver. Partimos então para a implementação de uma biblioteca própria,
que apesar do esforço extra veio-se a revelar extremamente precisa nos resultados.
Por fim, um ultimo problema digno de registo, apareceu aquando da fase de
implementação. Será mais eficiente uma programação multithreading? Será que o
esforço inerente á implementação multithreading compensará em termos de
performance do sistema? Ambas as questões foram ponderadas e uma decisão foi
tomada. Dado o tempo disponível na janela de oportunidade (8 horas disponíveis)
optou-se por uma implementação single thread, visto que o esforço para implementar
computação multithread não compensaria em termos de performance final.
Em suma, a implementação do sistema correu dentro dos padrões estipulados. Com
maior ou menor dificuldade todos os problemas foram ultrapassados e no momento o
sistema encontra-se em fase de estabilização antes de se proceder ao processamento
final.
Tendo o DWeb construído e estabilizado, pode-se agora implementar um sistema
de processamento analítico, que nos vai permitir explorar de forma eficiente
informação sobre os utilizadores que acedem ao site. Para além disso também se
podem aplicar técnicas de Data Mining, que nos vão permitir extrair conhecimento da
informação. Com a aplicação destas técnicas pretende-se descobrir relacionamentos
entre os dados, e através deles estabelecer perfis de utilização Web. A definição
desses perfis vai permitir melhorar a forma como a informação do site é
disponibilizada aos utilizadores e assim melhorar o seu funcionamento.
Como trabalho futuro podemos ainda melhorar alguns aspectos da implementação
do DWeb:
• Aumentar o número de formatos de ficheiros de log aceites pelo programa, dado
que neste momento apenas aceita logs no formato ECLF.
• Melhorar os algoritmos de detecção de crawlers, bem como os de delimitações
de sessões.
• Optimizar os processos já desenvolvidos, de modo a melhorar os tempos de
processamento dos ficheiros de log.
Referências
1. Kimball, R., Reeves, L., Thornthwaite, W., Ross, M. and Thornwaite, W. The Data
Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing and Deploying
Data Warehouses with CD Rom. John Wiley \& Sons, Inc., 1998.
2. Codd, E.F. The relational model for database management: version 2. Addison-Wesley
Longman Publishing Co., Inc., 1990.
3. Borges, E., Sistemas de Data Webhousing: análise, desenho, implementação e exploração de
sistemas reais, Tese de Mestrado, Mestrado em Informática, 2004.
4. A Loutonen “The Common LogFileFormat”,1995.
http://www.w3.org/pub/WWW/Deamon/User/Config/Logging.html.
5. Documentação do servidor “NCSA HTTPd”. NCSA, http://hoohoo.ncsa.uiuc.edu/docs/
6. Phillip M. Hallam-Baker, Brian Behlendorf: “Extended Log Format”. W3C Working Draft
WD-logfile-960323, 1996, http://www.w3.org/pub/WWW/TR/WD-logfile.html.
7. Phillip M. Hallam-Baker, Brian Behlendorf: “Extended Log File Format”. World Wide Web
Journal: The Web Five Years After, Volume1, Number 3, O’Reilly & Associates, Setembro,
1996, http://www.w3journal.com/3/s2/hallam.htm.
8. Maxmind, GeoIP, Country, http://www.maxmind.com/.
9. Myra Spiliopoulou, Bamshad Mobasher, Bettina Berendit, Mike Nakagawa: A framework
for the evaluation of session reconstruction heuristics in Web usage analysis. Informs
Journal on Computing. Abril 2003.
10. Ron Kohavi, Rajesh Parekh: Ten Supplementary Analyses to improve E-commerce Web
sites. In Proceedings of Fifth International Workshop on Knowledge Discovery the Web
WebKDD’2003- WebMining as a Premise to Effective and Intelligent Web Applications.
Agosto 2003.
11. Michael Chau, Hsinchun Chen: Personalised and Focused Web Spiders. Web Intelligence,
Springer-Verlag, Fevereiro, 2003.
12. Kamble, A.S. A conceptual model for multidimensional data Proceedings of the fifth on
Asia-Pacific conference on conceptual modelling - Volume 79, Australian Computer
Society, Inc., Wollongong, NSW, Australia, 2008.