Qualidade de Dados / Data Quality

Existem algumas ferramentas de qualidade de dados que dizem funcionar em Portugal. Algumas dizem ser muito avançadas por terem um dicionário de sinónimos com muitos milhões de entradas. Outras dizem que têm ferramentas internacionais que funcionam para Portugal, apenas necessitam de pequenos ajustamentos consoante a BD a tratar. Mas na realidade quais a diferenças entre as ferramentas existentes no mercado Português?

Vamos por partes, as que referi em primeiro lugar, são ferramentas que facilmente se percebe as suas limitações. Todos sabemos que a quantidade de erros que é possível dar é totalmente ilimitada. Ou seja por cada BD que seja tratada, certamente que novas "versões" das diferentes ruas vão ser criadas. Isto apenas para referir as já existentes. Porque se houver um trabalho de actualização com novas ruas e alterações de ruas, todo um histórico de "versões" de erros tem de ser criado. Nunca se conseguem grandes resultados com estas ferramentas, porque simplesmente as actualizações são diárias e virtualmente infinitas.

Depois existem ainda outras de origem normalmente Americana ou Anglo-Saxónica e às quais foi "anexado" um street file (ficheiro com os arruamentos) e que supostamente, trabalham sem problemas. Aqui temos um outro problema, que são as especificidades de um país como Portugal. Nestes mercados não existem a Rua, Travessa, Largo e Beco da Liberdade, tudo na mesma cidade. Logo aqui em muitos casos existem problemas na identificação/normalização das ruas.

Conheço este problema muito bem porque há pouco mais de 10 anos, andei a fazer um estudo para a "importação" de ferramentas disponíveis no mercado internacional e foram estes alguns dos problemas com que me deparei e hoje mais de 10 anos depois, continuam actuais como nesse tempo.

Então no final qual a solução?

A solução é um misto das duas, ou seja uma ferramenta que consiga "gerar" automaticamente esse histórico de erros, contando com mais de uma dezena de algoritmos internos, entre os quais o fuzzy logic, Patricia structure, Levenshtein distance e muitos outros, mas que por outro lado esteja adaptado ao mercado Português. Essa adaptação demorou quase dois anos, mas os resultados finais que conseguimos obter falam por si.

A confiança neste software é tão grande que o disponibilizamos na internet para que se possa testar. Mais nenhum outro está disponível desta forma e isso diz um pouco da confiança que se tem nos produtos. Para comprovar o que digo basta fazer um teste aqui, onde podem testar com uma morada com erros e por exemplo apenas com o código postal de 4 dígitos.

Hoje em dia já existem várias hipóteses para que se possa assegurar a manutenção da qualidade dos dados em níveis elevados. Não apenas com a compra das mais avançadas ferramentas de qualidade de dados, mas igualmente adoptando as mais modernas e económicas versões de Saas. Dependendo do numero de registos a serem tratados, existem inúmeras hipóteses: desde a compra da normalização de um valor predeterminado de registos, quer sejam 10.000 anuais quer sejam muitos milhões. Tudo isto num "tratamento" que é feito no momento mais importante de qualquer operação que envolve dados. O momento da inserção/alteração/modificação.

Imaginemos que na inserção de um registo é colocado apenas "Liberdade, 14 3 Esq" e que nessa cidade existem a Rua a Travessa e o Largo da Liberdade. Este registo muito dificilmente ficará correcto na Base de dados. Sendo que o mais certo é que venha a trazer custos para a empresa com a devolução de toda a correspondência que for enviada. Por outro lado e mesmo que seja feito um trabalho de ETL em cima desta BD, não há software nenhum que possa normalizar esta rua e caso algum o faça tem apenas 33% de hipóteses de acertar na "correcção". Mas por norma é assinalado e não é corrigido.

Tudo isto poderia ser evitado, caso no momento de inserção dos dados o utilizador recebesse uma mensagem que dissesse: "Existem 3 hipóteses de normalização: Rua da Liberdade, Travessa da Liberdade e Largo da Liberdade". Com estas hipóteses e com a possibilidade de perguntar directamente ao cliente, caso estejamos a falar de um Call Center, ou de um atendimento directo ao publico, o problema seria de imediato resolvido.

Neste caso estamos mais uma vez a falar de moradas, mas o mesmo se aplica relativamente aos duplicados e a muitos outros campos em que temos erros mais ou menos frequentes, mas que estão certamente identificados. Sempre que um determinado erro frequente ocorra há a hipótese de criar um alerta para que imediatamente se possa resolver o problema.

Existem como foram sendo descritas ao longo dos posts anteriores várias formas de normalização, correcção, actualização e validação das moradas, sendo o tratamento em modo batch sem dúvida o mais económico, para quem não tem volume de dados que comporte a compra das aplicações que funcionam logo na entrada dos dados. Embora seja essa a forma em que sem dúvida vamos ter os melhores resultados, nem sempre é possível fazer esse investimento.

Esta forma de tratamento obriga a um ciclo de tratamentos, mais ou menos frequentes consoante o volume de dados e de alterações que existam nos dados.

Neste tratamento de dados é feita a comparação dos dados existentes, com os dados existentes no ficheiro que contem as localidades, as respectivas ruas com, em muitos casos, os respectivos números de porta. Desta forma e recorrendo aos mais avançados algoritmos combinados, conseguimos ter resultados que são em muito superiores ao que por norma se consegue verificar. A segurança e qualidade dos dados e das aplicações é tal que é possível fazer testes neste demo online.

Esta é a melhor demonstração que podemos fazer da qualidade das nossas aplicações.

Na vertente Batch, vão existir no ficheiro final campos com uma descrição de todas as alterações que tenham sido efectuadas a cada um dos registos. Existem igualmente códigos que assinalam se os registos foram ou não alterados ou se não foi possível fazer a normalização / correcção / validação dos mesmos. Existem casos em que simplesmente não é possível fazer a normalização. Podem ser inúmeras as causas para essa não normalização, especialmente num país com as particularidades de Portugal. Mas mesmo com estas particularidades, estaremos sempre a falar em percentagens de normalização muito elevadas.

As ferramentas Real Time de qualidade de dados funcionam tal como foi já anteriormente referido a todo o momento permitindo assim que os dados estejam sempre actualizados e que a qualquer momento a qualidade dos dados possa ser assegurada de forma a que quando a informação seja necessária ela esteja correcta e actualizada.

Desta forma podemos confiar na informação existente nas nossas BD's evitando assim os picos que surgem nos processos de ETL que vimos anteriormente. Imaginado que o ciclo implementado para os processos de ETL era de um ano, se depois de nove meses de ter sido executado um processo de ETL fosse feita uma contagem, o que iria acontecer era que provavelmente os dados não seriam de todo fiáveis. Com as aplicações a funcionar em Real Time nunca chegamos a ter dados muito incorrectos. Podem haver algumas discrepâncias nos dados, mas será sempre valores residuais.

Este gráfico mostra a diferença entre as metodologias. Se a um dado momento nos for por exemplo pedido uma contagem de residentes numa determinada rua, com as aplicações Real Time em funcionamento não necessitamos de grandes esforços de normalização para conseguirmos dar esses valores porque sabemos que essa rua está sempre escrita da mesma forma e como tal não necessitamos de queries muito complexas para obter um resultado correcto. No exemplo dado anteriormente em que um processo de ETL tenha sido executado nove meses antes, o normal será procurar uma "Rua Principal"; "R Principal"; "R. Principal" e mesmo assim não existe a certeza de termos uma contagem com todos os registos da Rua Principal. Se no lugar da Rua Principal colocarmos uma Avenida Calouste Gulbenkian as hipóteses crescem exponencialmente.

A informação cada vez mais é um bem essencial a todas a empresas e não ter acesso a essa informação rapidamente pode ter consequências catastróficas.

Na grande maioria dos casos os projectos de limpeza de dados ou qualidade de dados, são projectos simples de ETL, em que existem várias abordagens.

Há projectos que são "simples". É feita a Extracção dos dados, o seu tratamento (Transform) e posteriormente o seu carregamento em BD (Load). Com estes projectos há uma aproximação a uma verdadeira qualidade de dados, mas se "olharem" com mais atenção vão verificar que na realidade, os dados nunca chegaram realmente a ficar limpos nos valores que são apresentados. Estes processos de ETL demoram algum tempo, e durante esse tempo, alguns dos dados que estão a ser tratados, estão a ser alterados pelos utilizadores. Ou seja, quando a BD é reposta, esses dados para alem de não poderem ser carregados, as alterações que entretanto foram efectuadas trouxeram mais "lixo" para o sistema.

E depois? Na semana seguinte a este projecto há novos dados, alterações e todo um conjunto de processos que fazem os dados voltar ao seu estado de falta de qualidade.

Existem outras abordagens, que já vi serem implementadas por grandes empresas em Portugal, que são ainda mais chocantes, que é a execução de projectos de ETL de forma progressiva. Ou seja, primeiro por exemplo tratam os registos que têm o código postal 1000. Depois os 1050 e assim sucessivamente. Este processo apenas permite que uma empresa fique eternamente a fazer a limpeza de dados, porque quando chegam ao fim do processo, estão os dados iniciais já totalmente "sujos". Apenas continuam o processo Ad aeternum.

Os processos ETL devem ser o principio de qualquer projecto de qualidade de dados. Durante o processo de ETL deve ser implementada uma solução online que permita a manutenção dos dados actualizados, evitando assim estar sempre a implementar processos ETL, com os elevados custos inerentes.

Aqui podem ver uma demonstração de como podem funcionar estas aplicações que em termos de moradas evitam a entrada de "lixo" para o sistema.