Quando um número considerável de utilizadores nas grandes empresas necessitam não só de relatórios web, mas também da possibilidade de efectuar análises flexíveis em dados e relatórios que recebem, o processamento analítico deve ser transferido para a máquina do utilizador. Esta é a base de uma arquitectura de data publishing: os cubos multi-demensionais são acedidos pelo utilizador na web como mais um tipo de conteúdo. Para além disso, o eficiente paradigma do data publishing permite o licenciamento por servidor e o acesso massivo aos dados através de um viewer.
À medida que as empresas se expandem para lá do firewall corporativo na busca de maiores ganhos de eficiência, as aplicações analíticas tendem a crescer concomitantemente. Os grandes fabricantes de BI falam de democratização da informação, enquanto as maiores empresas de software suspeitando que o mercado já ultrapassou a fase dos utilizadores prematuros estão também agora a disponibilizar soluções nesse sentido.
As vicissitudes das grandes empresas e a situação actual da economia levam a que mais gestores sejam obrigados a disponibilizar uma visão mais clara dos dados corporativos aos analistas dentro da empresa, mas também aos fornecedores, aos clientes, aos reguladores e aos empregados, que, em conjunto, constituem o ADN da tomada de decisão nas organizações de hoje em dia.
O desafio que se coloca é encontrar uma arquitectura de análise e reporting de dados que possa satisfazer não apenas meia dúzia de peritos, mas também uma grande quantidade de utilizadores anónimos que estejam cientes do potencial das ferramentas analíticas na obtenção dos seus objectivos.
A querela do acesso em massa
O web reporting e o software analítico tem seguido a tendência da maior parte das aplicações de TI: antes da revolução dos desktops, os utilizadores acediam aos computadores centrais através de terminais estúpidos. Assim que os PCs se tornaram mais comuns, as aplicações migraram para os desktops, onde o BI, tal como o conhecemos hoje, efectivamente nasceu no início dos anos 90.
Quando o data warehousing se tornou popular, os dados tornaram-se o alvo das aplicações analíticas, mas isso requereu transportar de novo a aplicação para um computador central, e assim nascia a era do cliente/servidor.
Os protocolos web substituíram os protocolos cliente /servidor nas implementações actuais destas aplicações, mas, por outro lado, permaneceram essencialmente na mesma. Escalar o número de utilizadores num ambiente cliente/servidor congestiona o recurso partilhado: o servidor. A solução tradicional é transferir a aplicação para uma máquina maior ou criar algoritmos de gestão de carga que corram num cluster de servidores.
Mas esta solução serve apenas para adiar os problemas, quando aquilo que de facto necessitamos é uma arquitectura onde os recursos computacionais cresçam de acordo com o número de utilizadores.
A arquitectura do data publishing
A arquitectura do data publishing está assente na premissa de que a interacção com relatórios web e de que a análise dos dados é feita de forma mais eficaz no desktop do utilizador final. Um servidor deve estar rotinado para disponibilizar dados e software de análise como conteúdo; o servidor não pode ser um elemento computacional partilhado, caso contrário o escalamento não é possível.
O segundo dinamizador na elaboração de uma arquitectura deste tipo é a natureza da web como meio de distribuição de conteúdo. Os dados, os relatórios formatados e as aplicações analíticas devem ser acessíveis pelo utilizador final da mesma forma e com a mesma facilidade do que qualquer outro conteúdo.
Os componentes primários na arquitectura são o designer, o builder e o applet de web reporting e de análise do lado do cliente. No caso mais simples, um administrador utiliza o designer para preparar um perfil ou definição e corre o builder ligando o cubo MOLAP resultante a um website. O fluxo de dados neste processo está ilustrado na Figura 1.
Num ambiente standard, os dados publicados e o software de web reporting e análise são disponibilizados para o cliente como qualquer outro conteúdo, não causando no servidor uma carga superior pelo facto de existir um grande número de utilizadores, já que a análise é feita no PC de cada cliente.
Num sistema destes, o utilizador sofrerá latência de rede cada vez que interagir com os dados para não falar do tempo de processamento no servidor partilhado , não podendo aceder ou analisar dados se estiver offline.
Nesta arquitectura, o servidor não é usado como recurso de computação, embora esteja disponível para outros serviços que podem ir para além da simples análise. Por exemplo, o utilizador pode desejar pesquisar os dados que servem de suporte a um web report ou trocar pontos de vista acerca dos dados com outros utilizadores. O administrador pode também querer disponibilizar links do relatório noutros locais do website provavelmente outros cubos MOLAP ou em páginas doutros websites.
Comparação entre a arquitectura de Data Publishing e de Cliente / Servidor
A arquitectura de data publishing oferece fundamentalmente uma solução MOLAP, onde o tamanho dos cubos é mantido pequeno através da criação de cubos com sub-conjuntos de dados para questões específicas. Este modelo tira partido da compressão inerente à formação do cubo devido à compressão dos dados.
Os cubos podem ainda sofrer uma compressão maior a fim de reduzir o custo de os transferir para o utilizador. Na maior parte dos casos, centenas megabytes de dados virgens são transformados num cubo com algumas dezenas ou centenas de kilobytes, facilmente acessíveis por qualquer utilizador. A Figura 2 compara a arquitectura de data publishing com cliente/servidor.
Extensões da arquitectura básica de data publishing
Existem algumas variações notáveis do cenário básico de implementação de uma arquitectura de data publishing, incluindo a construção de cubos parametrizáveis, cubos on demand, interacção com componentes interligados e colaboração.
Construção de cubos parametrizáveis
O cenário mais simples lidava com um bloco monolítico de dados estáticos. Em muitas aplicações, os dados mudam ao longo do tempo e são subdivididos com fins diferentes. Um exemplo disto são os dados demográficos que mudam ao longo do tempo, podendo ser subdivididos de várias formas, dependendo dos objectivos do utilizador.
O administrador pode definir um pequeno conjunto de definições de cubos que representem os diferentes problemas que os utilizadores estão interessados em resolver. Estas características de cubos podem ser aplicadas a diferentes subconjuntos de dados para diferentes períodos temporais ou diferentes regiões geográficas. Neste caso, o administrador construiria cubos parametrizáveis para cada definição.
Cubos à medida
Se a situação anterior permite gerar facilmente gerar cubos de dados para um website de acordo com um parâmetro definido, pode porém acontecer que existam tantos cubos possíveis que se torna oneroso gerá-los e armazená-los. Por outro lado, pode também acontecer que apenas um subconjunto imprevisível de todos os cubos possíveis seja acedido, tornando-se dispendioso gerá-los todos sempre.
Uma forma mais apropriada para construir cubos numa situação destas é ter cubos OLAP construídos à medida, usando parâmetros específicos ou fornecidos pelo próprio utilizador quando o pedido é feito. Isto torna a transacção com o servidor mais sofisticada do que uma simples busca de ficheiros, mas o processamento dos dados continua a ser feito na máquina do utilizador, mantendo a escalabilidade da arquitectura.
Análise com componentes interligados
Existem várias razões pelas quais um utilizador possa querer interagir com componentes interligados enquanto analisa dados MOLAP numa arquitectura de data publishing.
1. Recuperar um subconjunto da fonte de dados do cubo em análise
2. Salvar um relatório (o produto final de uma análise) para ser utilizado por outrém
3. Navegar para um cubo de dados relacionado contendo, talvez, informações mais detalhadas sobre um elemento particular, e
4. Navegar para uma webpage relacionada talvez um documento que descreva os dados ou a parte deles seleccionada pelo utilizador.
Colaboração
Um aspecto importante da análise de dados é a gravação de relatórios personalizados derivados de sessões de análise on-line. Uma vez gravados no servidor, estes relatórios ficam não só disponíveis para o utilizador em sessões futuras mas também para outros utilizadores. E como os dados são disponibilizados como conteúdo num formato com um tamanho semelhante a muitos anexos de e-mail, torna-se inteiramente viável enviar esses dados por e-mail para um determinado grupo de trabalho.
Para além disso, e se o administrador de sistemas o permitir, os membros de um grupo de trabalho podem também salvar os seus próprios relatórios personalizados no mesmo cubo OLAP.
Conclusão
A arquitectura de data publishing descrita neste artigo vai de encontro às necessidades das grandes empresas que trabalhem sobre a rede das redes e que queiram tornar o processo de tomada de decisão acessível não só dentro da empresa, mas também para além do firewall corporativo, sem se preocuparem com o licenciamento por utilizador. Equipados com nada mais do que um browser, muitas centenas e mesmo milhares de utilizadores podem, através de um simples clique, ter acesso a informação analítica.
Depois desse clique, esses utilizadores podem criar os seus próprios relatórios personalizados que poderão, por sua vez, ser partilhados e modificados por grupos de trabalho espontaneamente criados. Para as organizações dos mercados verticais das finanças, saúde, servidos de dados e mesmo da administração pública que procurem um ROI palpável mas que não consigam suportar os custos de hardware e de licenças associados a uma arquitectura cliente/servidor, este modelo merecerá, sem dúvida, uma séria ponderação.
Mike Kelly
2003-06-23
Traduzido e adaptado de DM Review
Centro de Informação-DATABASE & BUSINESS INTELLIGE