Projetos de BI: melhores práticas com Qlikview

De que se trata o artigo

Veja nesse artigo dica de melhores práticas para desenvolvimento de aplicações em Qlikview para projetos de BI (Business Intelligence) .

Em que situação o tema é útil

É comum em grandes projetos de BI a definição de uma vasta coleção de indicadores para apoiar na tomada de decisão que utilizarão dados compartilhados em diversas visões a serem desenvolvidas. Este artigo será útil para desenvolvedores que precisam otimizar suas aplicações e/ou precisam organizar melhor seus dados em projetos de média/alta complexidade, onde serão desenvolvidos múltiplos indicadores/visões com grande volume e reuso de dados extraídos das fontes transacionais, visando aumento de performance das aplicações e melhor estruturação dos projetos em Qlikview.

Atualmente a maior parte das empresas busca tecnologias que facilitem o acesso a dados estratégicos de seu negócio. Com ações mais eficientes e resultados mais significativos da gestão de dados para tomadas de decisões, empresas passaram a investir em ações de BI para alcançar suas metas, promover a compreensão do processo de captura e utilização de informações externas e internas, e o desenvolvimento e monitoramento de estratégias coerentes ao momento competitivo.

Para tal necessidade, hoje existem diversas soluções disponíveis no mercado para atender os anseios dos gestores nas organizações . O Qlikview é uma dessas soluções disponíveis que atende muito bem às expectativas e agrega muito valor aos negócios, trabalhando de uma forma diferente em relação às tradicionais ferramentas de BI, pois possui uma tecnologia inovadora que possibilita aos gestores fazer perguntas sem que os mesmos estejam presos ou engessados a uma estrutura hierárquica de dados pré-definida, dando possibilidades de diversas combinações de análise.

Qlikview é uma plataforma de Business Discovery - possibilidade de unir dados externos permitindo uma análise com novas hipóteses ou questionamentos - que permite analisar rapidamente os dados de múltiplas fontes de forma que os gráficos apresentem com precisão as suas necessidades e processos. Trata-se de uma plataforma associativa in-memory, ou seja, funciona como a nossa mente fazendo associações ao ligar dados de diversas fontes com apenas alguns cliques. Ao invés de agregar dados em cubos inflexíveis, cria-se um grande arquivo com todas as associações conhecido no produto como “ Data Cloud ”.

Desta forma, todos os dados relevantes em todas as dimensões ficam disponíveis na memória RAM. Tudo isso é permitido, também, graças à tecnologia AQL (Associative Query Logic), conhecido também como modelo associativo, onde as queries são feitas na estrutura de dados da ferramenta, que elimina a necessidade de cubo de dados, substituindo a estrutura de cubos por “nuvem de dados”.

Os projetos de BI implementados com esta ferramenta, comumente utilizam a mesma estrutura dos projetos tradicionais, onde temos a etapa de ETL (extração, tratamento e carga dos dados), criação de um repositório de dados transacionais (Data Warehouse) e as aplicações para análise dos dados (front-end). Para tratar destas etapas, o Qlikview utiliza duas extensões de arquivos principais:

Arquivos QVD à Arquivo nativo do Qlikview que contém uma tabela de dados. A leitura destes dados neste tipo de arquivo é infinitamente mais rápida do que outras fontes de dados.

Arquivos QVW à Arquivos que contém as aplicações, script de carregamento dos dados, dashboard, relatórios e regras de negócio do projeto.



Atualmente um dos maiores desafios dos projetos de BI é criar aplicações amigáveis, com layouts, funcionalidades que superem as expectativas e com performance otimizada, pois o tempo de processamento para o cruzamento pode ser decisivo para criar uma barreira de utilização por parte do usuário. Já imaginou estar analisando um indicador onde o resultado do cruzamento leve cerca de 10 à 30 minutos para ser processado e exibido na tela? Além disso, outra questão crítica é a organização/manutenção destes projetos mais complexos, que utilizam e reusam um grande volume de dados que são utilizados por diversas visões (repetição de scripts de carregamento dos dados em várias aplicações/visões).

Pensando nestes aspectos, uma boa prática de desenvolvimento que pode ser utilizada é a criação de um arquivo “transformador” que servirá de base para as aplicações/visões, deixando-as mais leve e otimizando o carregamento dos dados. Este arquivo tem por objetivo fazer a transformação dos dados conforme as regras de negócio, a fim de eliminar o máximo de processamento nas aplicações.

O que fazer É comum que desenvolvedores Qlikview façam o tratamento dos dados no momento da extração. Particularmente discordo desta prática pelos seguintes aspectos:

Tempo de acesso à bases transacionais: Sabemos que a carga dos dados é um detalhe crítico nos projetos de BI, pois o nível de processamento é muito alto nas bases de dados no momento da carga, podendo comprometer a sua utilização por parte dos sistemas transacionais. Sendo assim, quanto maior o número de consultas (tratamentos realizados para extração dos dados), mais tempo levará para fazer a extração dos dados. Imagine um cenário com produção de mais de um milhão de registros por dia, que a sua extração envolve centenas de tabelas, onde a carga inicia no período da noite e invade o expediente do dia seguinte... Isto é comum em organizações que analisam dados de múltiplas filiais. Tal situação pode comprometer e, até mesmo, inviabilizar a utilização destas bases por parte dos sistemas transacionais.

Subutilização da potencialidade da ferramenta: Conforme citado no início do artigo, o Qlikview processa muito mais rápido (faz leitura) um arquivo QVD do que qualquer outra fonte de dados. Sendo assim, a utilização deste tipo de arquivo sempre será uma boa prática quando se pensar em desempenho e performance das aplicações.

Por conta dos aspectos supracitados, é interessante que se faça o mínimo de tratamento possível no momento da extração, deixando esta tarefa para o arquivo “transformador”.

Após extração dos dados, são gerados os arquivos QVD’s com os dados da fonte transacional. Em posse destes arquivos salvos em um diretório, cria-se um novo arquivo QVW (transformador) que conterá o script de carregamento destes QVD’s e será feito o tratamento dos dados de acordo com as regras de negócio, gerando como produto novos arquivos QVD’s com os dados tratados. A partir disso, todas as aplicações/visões criadas podem utilizar os novos QVD’s com o carregamento dos dados otimizados, diminuindo significativamente o processamento e, também, a repetição de códigos nas demais aplicações que utilizem os mesmos dados.

Figura 2. Sugestão de estrutura de projetos Qlikview com a criação do Transformador para tratamento dos dados antes da aplicação.

Conclusão

A dica deste artigo não é criar uma metodologia, e sim boas práticas baseadas em experiências reais onde performance e organização do projeto, no que diz respeito à reuso dos dados, eram fatores críticos para o sucesso da implantação do Qlikview. Os benefícios das informações citadas neste artigo poderão ser melhor avaliados em projetos com grande volume de dados, com cenários mais complexos e que tenham usuários finais que necessitem de informações em tempos menores.