Para quem trabalha na área de Business Intelligence, não é incomum depararmo-nos com problemas de dados e passarmos várias horas a analisar tabelas e processos, com o objectivo de identificar os motivos pelos quais os sistemas não apresentam os resultados esperados. Quando finalmente se chega ao cerne do problema, mais uma vez, não é incomum que seja por uma das razões apresentadas em baixo:
> Problemas nos sistemas fonte
> Problemas de carregamentos (Jobs)
> Configurações em falta
Uma vez terminada esta investigação, o mais provável é termos de tomar novas iniciativas que levem à resolução do problema: alterando configurações, correndo novos processos, contactando utilizadores de negócio ou de IT…. Após alguns dias, semanas ou mesmo meses, é possível que nos deparemos com um problema semelhante. Nessa altura podemos, ou não, ainda nos lembrarmos do que tínhamos feito exactamente quando o problema apareceu pela primeira vez. Isto pode levar a que tenhamos que repetir as mesmas actividades. Não é também incomum que, só nos apercebamos do problema quando informados por um utilizador de negócio, o que não é a forma mais pro-activa de olhar para este tipo de questões.
De forma a mitigar este tipo de situações, já temos actualmente disponíveis no mercado, soluções de Data Quality (pagas ou grátis) que nos podem ajudar nestas tarefas. De experiência própria, instalar um novo software em máquinas de clientes, é algo que pode não ser tão linear e que pode requerer um conjunto de aprovações adicionais que nem sempre são fáceis de obter. Para situações como esta, onde é útil ter uma solução que seja facilmente implementada e que de certa forma possa reduzir o esforço de monitorização deste tipo de soluções, ter uma solução simplificada deste tipo, tem-se revelado muito proveitosa no meu dia-a-dia. Pode não ser uma solução State-of-the-art, mas pode ajudar bastante nestas actividades. Pode inclusivamente ser um ponto de partida para outras soluções mais “oficiais”.
A solução que tenho trabalhado tem a vantagem de poder ser rapidamente aplicada a um projecto que envolva Bases de Dados. Como é feito totalmente em SQL, pode funcionar em vários vendors de Bases de Dados. O propósito deste artigo é descrever, de um ponto de vista High-Level, um algoritmo que uma vez implementado, possa ser reutilizado em vários projectos.
Esta solução é constituída por duas partes:
> Motor de Qualidade, onde guardamos a lógica dos testes e os seus resultados
> Motor de Notificações, onde podemos informar os utilizadores de um determinado problema. Esta notificação é feita por email. Podemos ter múltiplas notificações e também destinatários.
Algoritmo Simplificado
O algoritmo simplificado é apresentado na figura em baixo:
De forma sumária, temos uma execução do sistema de testes, manualmente ou num Schedule, no canto superior esquerdo da imagem. Estes resultados são armazenados numa tabela central de registos (um registo por teste e período temporal). Isto é depois consultado pelo sistema de notificações que pode ou não, dependendo da definição da notificação, enviar esta informação por email com os testes que falharam. Esta notificação, para além de enviar informação relevante dos registos em falha, pode também incluir uma descrição dos passos necessários para resolver um determinado problema. Isto é especialmente útil, quando estas notificações são enviadas directamente para os utilizadores de negócio. Adicionalmente, como os dois sistemas podem funcionar de forma independente, no sistema de notificações podemos também incluir informação adicional que podem por exemplo ter origem em tabelas de erros externas, desde que relevante para os utilizadores.
A solução de envio das notificações por email, apresenta algumas vantagens, nomeadamente a possibilidade de enviar os avisos directamente para os utilizadores (incluindo os passos para a resolução do problema), bem como o facto da mensagem chegar directamente à caixa de correio do utilizador, sem a necessidade de ferramentas adicionais ou relatórios. Um senão é o facto de nas organizações termos limites ao tamanho dos anexos que conseguimos enviar. Não obstante, podemos não enviar a notificação por email e recorrer a outro tipo de soluções de notificação.
Algoritmo Detalhado
Para uma explicação mais detalhada da ideia, podemos olhar mais abaixo o diagrama.
Sistema de Qualidade
> Tabelas
> Tabela Tests - contém os testes que serão executados pelo Sistema de Qualidade. Por cada teste, existe uma coluna com código de SQL, que será executado de forma a validar uma determinada situação
> Tabela Test Results – contém os resultados das execuções dos testes, um resultado de teste por data. Não são guardados aqui dados detalhados dos registos em erro ou das falhas. Para isso existe a tabela seguinte.
> Tabela Rejected Records – Pode conter os conjuntos de dados detalhados que que estão em erro ou num estado de inconsistência
> Stored Procedures
> Execute Data Quality Tests – Este é o processo principal do Sistema de Qualidade de Dados. É usado para chamar cada um dos testes armazenados na tabela de testes e correr cada instrução de SQL, cujo resultado será então guardado em duas tabelas. Uma com o resultado agregado da execução do teste (se correu com sucesso ou não) e outra com o detalhe dos registos que falharam nesta execução.
> Quality Tests Manage Error Tables – Ter uma tabela de registos rejeitados, pode-se revelar um problema, caso não tenhamos uma forma de gerir o seu tamanho e crescimento. De forma a evitar o crescimento descontrolado dos dados, este processo vai remover registos mais antigos, com uma periodicidade e retenção, previamente configurados
> Lógica
> Um teste é seleccionado da tabela de testes, de forma manual ou por schedule. Como nota, a lógica do teste terá sempre de funcionar de forma a que se retornar dados é um erro e caso não retorne nada é um sucesso
> O teste de SQL é executado e é testado se o número de linhas retornadas é zero ou diferente de zero
> Se for zero, significa que o teste é um sucesso. O resultado de sucesso é guardado na tabela de Test_Results e não são inseridos registos na tabela de Rejected Records
> Se for diferente de zero, significa que o teste não teve sucesso. Isto é guardado na tabela Test_Results como uma falha e os registos em erro podem ser colocados na tabela Rejected Records
> Uma vez completados todos os testes, o Stored Procedure para limpar tabelas de erros é executado de forma a apagar registos mais antigos, de acordo com os parâmetros de retenção definidos.
Sistema de Notificações
> Tabelas
> Tabela Emails Configurations – contém os endereços de email usados pelo Sistema de Notificações, bem como as regras usadas para estas. As regras são variadas, passando desde o Subject do email, o nome do anexo, a prioridade…
> Stored Procedures
> Quality Tests Notify – Este é o componente principal do Sistema de Notificações. É usado para chamar cada uma das notificações presente na tabela de notificações. Ele obtém as configurações de cada uma delas e envia os resultados por email ou outra forma definda
> Lógica
> Uma notificação é seleccionada da tabela de notificações, manualmente ou por schedule
> De acordo com os parâmetros definidos, a notificação será enviada
> Para aquelas que são enviadas por email, o utilizador receberá uma mensagem com um anexo das inconsistências detectadas.
Conclusão
Como foi referido anteriormente, a ideia deste artigo é apresentar uma solução de alto nível para a Monitorização da Qualidade de Dados e Gestão de Notificações, que poderá ser útil para projectos pequenos ou para situações bem definidas. Isso pode ser uma solução interessante como ponto de entrada deste tipo de ferramentas. Isto também pode ser útil quando estamos em modo de projecto, a fim de controlar possíveis problemas com os dados e, de uma forma pró-activa, detectar problemas e corrigi-los.
.
.
.
.