[ARTIGO] HOUSTON, NÓS TEMOS UM PROBLEMA - A CARGA DO BI RODOU?

HOUSTON, NÓS TEMOS UM PROBLEMA - A CARGA DO BI RODOU?

POR 

GRIMALDO OLIVEIRA E JURACY ALMEIDA

Relembrando o grande problema que a NASA passou ao lançar uma espaçonave para mapear a Lua, tendo um problema que demorou a ser identificado, o mesmo é análogo em projetos de BI que não possuem um controle de seus processos. Todos sabem que a construção de um projeto de Business Intelligence (BI) envolve diversas etapas, desde o levantamento dos dados com os gestores, até o levante da construção da famosa modelagem de dados multidimensional, terminando com a implementação dos dashboards no cliente. Mas, será que apenas isso basta? Neste artigo procuramos apresentar o pós-implantação de um projeto de Business Intelligence, que formas de acompanhamento das cargas (Staging, Dimensão e Fatos) podem ser criadas ou sugeridas para que se tenha segurança e controle do “Buffet de dados“ que está sendo oferecido aos usuários finais. Podemos pensar em gerenciar desde um simples controle sobre o total de dados que transita entre as tabelas de um Data Warehouse (DW) até um sofisticado sistema de análise das consultas identificando as que mais são acessadas e seus tempos de execução.

Entretanto, a necessidade de se criar controles de acompanhamento em sistemas de informação não é algo novo, é tão antigo que com certeza você deve conhecer a forma mais comum deles, analisar log´s de sistemas, sejam estes ligados a softwares Hospitalares, Educacionais, Recursos Humanos e principalmente os Financeiros. Todas as empresas não desejam ser surpreendidas com uma mensagem pela manhã “SEU SISTEMA TRAVOU!!!”, mas travou aonde?

Em projetos de BI especificamente no processo que controla as carga de um Data Warehouse, alvo das nossas explicações, costumamos criar uma estrutura conhecida como ALERTAS que facilitam a vida de quem executa a manutenção deste processo e que garante o funcionamento de forma adequada e contínua. Geralmente estes ALERTAS são constituídos de tabela de dados e gráficos que são transmitidos por e-mail sempre ao final das cargas de um Data Warehouse. Lembro que neste momento não apresentaremos os códigos de programas sobre estes ALERTAS estes serão tema de um novo artigo. Apresentaremos agora quais abordagens você deverá implementar, veja como montar a estrutura de controle:

Relatório de controle de carga

O objetivo deste alerta é informar após a execução das cargas de um Data Warehouse, se as cargas de Staging, Dimensão e Fato foram bem sucedidas, caso acorra algum problema, o erro é capturado e exibido na tabela de dados, vejamos:

Exemplo:

DW	Inicio Carga	Fim Carga	Situação	Erro
VENDAS	12/11/2014 01:03:00	12/11/2014 01:33:00	EXECUTADO COM SUCESSO
CONTAS A PAGAR	12/11/2014 02:05:00	12/11/2014 02:45:00	ERRO CARGA	Violation of Primary Key constraint dim_fornecedor

Note que a carga do Data Warehouse de Contas a Pagar apresentou um erro de violação de chave primária, identificando o objeto dim_fornecedor imediatamente, a ação pelo analista de DW é direta sem perda de tempo.

Espaço utilizado

A intenção é permitir um controle mais apurado pelo DW do espaço utilizado no banco de dados que irá armazenar os dados de Staging, Dimensão e Fato. Com este controle podemos gerenciar o espaço e prever quando necessitamos acrescentar mais.

Para acompanhamento deste tipo de ALERTA, geralmente apresentamos gráficos de barra, exibindo os totais de espaço utilizado e disponível. Nos nossos exemplos utilizaremos do banco de dados ORACLE, assim algumas terminologias próprias da tecnologia irão ser apresentadas nos gráficos. Vejamos:

Verificamos que a TableSpace (Cada TableSpace em um banco de dados consiste em um ou mais arquivos denominados arquivos de dados (datafiles)) de Vendas está para ficar sem espaço, portanto será necessário uma intervenção pelo DBA da empresa que gerencia o DW para que o processo de carga não seja afetado. Interessante que o analista de DW e o DBA conversem sobre um percentual seguro para aumento automático da TableSpace, pois desta maneira não haveria intervenção humana.

Crescimento das tabelas Fato

Responsáveis por armazenar as métricas e indicadores geradas pela organização, as tabelas fato, em um projeto de BI, tendem a ser as tabelas com o maior número de registros do banco.

No início do projeto, milhares ou milhões de registros são inseridos nestas tabelas para cargas dos dados históricos. Ao colocar o projeto em execução, as cargas diárias, mensais ou anuais fazem com que estes objetos cresçam ainda mais em volume.

Ter um acompanhamento deste crescimento das fato é algo muito importante para o gestor do BI e os gestores envolvidos, pois a preocupação neste assunto envolve a escalabilidade e performance do projeto.

Assim, observe um exemplo gráfico de controle de crescimento:

Observe que ao longo do tempo a tabela FATO COMISSÃO tem um crescimento considerável, saindo de 460.000 registros em 10/2014 e chegando a mais de 1.000,000 (hum milhão) de registros em pouco menos de dois meses. Este ponto de atenção deve ser considerado no “Capacity Plainning”, planejamento de crescimento, do banco de dados e da infraestrutura para comportar o crescimento de volume nos próximos anos.

Duração das cargas

A chamada ‘janela’ de carga é um aspecto considerado como crítico em muitas organizações, pois esse é o período do dia que as cargas de sistemas e do BI podem ser executadas com o mínimo de impacto ao ambiente e aos usuários.

Ter em mãos o tempo de cada carga do BI de maneira ágil e precisa, possibilita a equipe de BI, acompanhar, sem o uso de ferramentas, a duração das cargas.

Permite também uma análise do espaço de tempo disponível para realização de outras cargas e também quais cargas serão impactadas em uma possível manutenção do ambiente pela equipe de infraestrutura.

  

Vejamos um exemplo de controle de tempo de carga:

	DURAÇÃO DA CARGA( HH:MM)
BI	MÊS 10/2014	MÊS 11/2014	MÊS 12/2014
VENDAS (HORA INICIO: 00:35)	00:55	00:52	01:03
CONTAS A PAGAR (HORA INICIO: 04:05)	01:10	01:11	01:15

Analisando a planilha e o gráfico, verifica-se o tempo médio e também a informação da hora de início das cargas, ajudando na análise e inserção de novas cargas.

Utilização do BI

Quando se tem vários projetos de BI sob a responsabilidade de uma mesma equipe, o acompanhamento do uso e acesso pelos clientes é um aspecto importante e estratégico, pois ao se identificar um comportamento crescente de desuso pelo cliente em determinado assunto, a equipe do projeto pode pró-ativamente acompanhar mais de perto estes usuários para entender os motivos do baixo acesso. Este tipo de acompanhamento possibilita também identificar a necessidade de novos treinamentos na ferramenta OLAP ou de novas reuniões com os gestores do negócio para reavaliação dos dados oferecidos.

Contrariamente, analisar muitos acessos também é importante, pois oferece a gestão do BI a possibilidade de identificar os assuntos mais acessados e que por sua vez se torna o mais crítico para o cliente.

Verificando o gráfico podemos concluir que a FATO VENDA é a mais utilizada do BI VENDAS e a FATO PARCELADO no BI CONTAS A PAGAR dentre os meses analisados. 

Já a FATO CARTÃO e a FATO COMISSÃO tem pouco acesso, o que sugere uma conversa com os gestores para compreender a baixa utilização a estes assuntos, discutindo o que pode ser melhorado para que estes dados possam ser utilizados em sua plenitude.

Top 10 consultas mais acessadas  

Complementando o tópico anterior, um outro controle interessante é saber quais as TOP 10 consultas mais acessadas. Conhecer essas análises mais acessadas permite a equipe do BI saber quais objetos são mais críticos e como seus clientes estão fazendo uso do produto.

É necessário conhecer os objetos mais críticos, pois no momento que conhecemos essas consultas, identificamos os objetos (fatos e dimensões) e assim atribuímos um peso maior a estes na realização de qualquer manutenção.

Conhecer as consultas mais acessadas também permite que a equipe de BI, saiba se estão sendo construídas análises para apoio gerencial e decisório ou se estão apenas gerando “listões”. A partir daí, com esse conhecimento a equipe de BI poderá tomar outras ações para melhor aproveitamento do projeto.

Vejamos um exemplo de Top 10 mais acessadas:

BI	Consultas	Acessos (Quantidade de consultas)
VENDAS	Análise Vendas 102014	15
	Lista Vendedor	12
	gerente grupo	11
	Relatorio 1	11
	Vendas Aprovadas	10
	Cartao	9
	Rel Vendedor	7
	Lista Cartao Vendas	3
	Rel cartao	3
	Vendas Vendendor	3
CONTAS A PAGAR	pagamentos lista	22
	rel contas	19
	rel lista cartoes	9
	listao pagamentos	8
	pag 10	6
	top dividas	6
	relatorio a pagar	5
	rel parcelados	4
	rel luiza 10	4
	rel marcia	4

Veja que nesta planilha dos TOP 10 temos os nomes das análises mais acessadas e que a equipe de BI poderá avaliar ações de melhorias (colocação das consultas em cache, particionamento dos dados, dentre outros)  para que o gestor do negócio tenha sempre um acesso mais rápido as consultas mais usuais.

Top 10 consultas mais demoradas

Conhecer as consultas mais demoradas permite a equipe de BI antecipar-se a demanda e pró-ativamente dialogar com os clientes para realizar um trabalho conjunto e saber onde está o gargalo das análises, se nos objetos que compõem a análise, no formato da consulta,  na falta de critérios ou filtros ou outros pontos que poderão ser avaliados.

Modelo de top 10 consultas mais demoradas:

BI		Tempos(HH:MM:SS)
VENDAS	Análise Vendas 102014	00:25:14
	Rel cartao	00:17:44
	gerente grupo	00:16:55
	Relatorio 1	00:16:40
	Vendas Aprovadas	00:15:09
	Cartao	00:10:01
	Rel Vendedor	00:08:30
	Lista Cartao Vendas	00:07:14
	Lista Vendedor	00:07:00
	Vendas Vendendor	00:05:32
CONTAS A PAGAR	pagamentos lista	00:21:11
	rel contas	00:20:14
	rel lista cartoes	00:12:08
	listao pagamentos	00:05:09
	pag 10	00:05:00
	top dividas	00:04:30
	relatorio a pagar	00:04:22
	rel parcelados	00:04:08
	rel luiza 10	00:04:07
	rel marcia	00:04:03

A partir do momento que sabemos que a análise “Análise Vendas 102014” está demorando mais de 25 minutos, a equipe de BI pode atuar no melhoramento da estrutura dos objetos que compõem esta consulta, adicionando novos índices, particionando e outros.

Template de acompanhamento das cargas

Agora que entendemos alguns pontos de controles num projeto de Business Intelligence, vejamos abaixo um exemplo contemplando todos os pontos destacados neste artigo:

Este modelo, pode ser enviado diariamente por e-mail a equipe do BI permitindo assim um monitoramento fácil de todos os projetos controlados e uma ação mais rápida.

Acreditamos que um controle eficiente das cargas e dos acessos aos dados em um projeto de BI facilita o diagnóstico de erros de maneira rápida e eficiente, assim como a coleta de informações a respeito dos projetos que estão sob a responsabilidade da equipe.

A implementação deste modelo de controle não exige muito esforço, necessitando apenas existir alguma estrutura que concentre os dados das cargas. Essa estrutura pode ser desenvolvida e passa a armazenar os dados de todos os projetos de Business Intelligence.

Consideramos que com essa estrutura o “caos” poderá ser evitado e monitorado caso ocorra.

Compatilhe no Google Plus

Sobre Grimaldo Oliveira

Mestre pela Universidade do Estado da Bahia (UNEB) no Curso de Mestrado Profissional Gestão e Tecnologias Aplicadas à Educação (GESTEC) com o projeto “GESMOODLE – Ferramenta de acompanhamento do aluno de graduação, no ambiente virtual de aprendizagem(MOODLE), no contexto da UNEB“. Possui também Especialização em Análise de Sistemas pela Faculdade Visconde de Cairu e Bacharelado em Estatística pela Universidade Federal da Bahia. Atua profissionalmente como consultor há mais de 15 anos nas áreas de Data Warehouse, Mineração de Dados, Ferramentas de Tomada de Decisão e Estatística. Atualmente é editor do blog BI com Vatapá. Livro: BI COMO DEVE SER - www.bicomodeveser.com.br