O Arqueólogo de Dados: O que aprendi sobre ETL ao ler arquivos de dados 'na mão' nos anos 90

Hoje, ouvimos falar constantemente em Engenharia de Dados, ETL (Extração, Transformação e Carga) e migração de sistemas legados. É uma indústria multimilionária de ferramentas complexas e consultorias caras, focada num único problema: como tirar dados valiosos de um sistema antigo e "fechado" e trazê-los para um sistema novo.

Nos anos 90, nós não tínhamos as ferramentas, mas tínhamos exatamente o mesmo problema. Para a minha empresa, a CompCet, a migração de dados não era um desafio técnico; era a nossa principal arma comercial.

Naquela época, a concorrência era feroz; nós "roubávamos" muitos clientes de concorrentes, e eles roubavam os nossos também. Quase sempre, o cliente só concordava em mudar de sistema se garantíssemos que nenhum dado antigo seria perdido (leia também o artigo "Um Novo Horizonte – Clipper e a Conquista do Mercado PME" que aborda a migração de dados como estratégia de negócio). Se a gente conseguisse garantir a transformação total dos dados deles, era quase certo que o cliente vinha junto. Isso dava uma tranquilidade para eles, que valia bem mais do que qualquer funcionalidade nova.

O desafio era imenso. Eu tinha de converter de tudo: arquivos DBF, arquivos “.DAT”, até planilhas Lotus 1-2-3. Mas o verdadeiro pesadelo eram os "arquivos estruturais", pois eles não tinham um formato lógico definido: cada programador criava a sua estrutura e gravava diretamente no arquivo.

Não havia documentação, não havia mapa, não havia dicionário de dados. Era um cofre fechado. A única forma de ler aquilo era fazer "arqueologia de dados": eu tinha de abrir o arquivo num editor hexadecimal e tentar descobrir "na mão" o tamanho de cada campo, apenas olhando para os padrões dos bytes. Se eu errasse um único byte no offset, perdia a leitura do arquivo inteiro.

Como eu não tinha ferramentas prontas para isto (nem sequer conhecia o dBase naquela altura para ler DBFs comuns ), tive de construir a minha própria ferramenta. Escrevi um programa em C que apelidei de "descascador de arquivos". Era uma ferramenta que "lia qualquer coisa". Eu passava-lhe os parâmetros que tinha descoberto "na mão": o tamanho do offset, o tamanho de cada campo que queria ler, se era texto ou estrutural, e ele lia o arquivo binário e trazia-me os dados.

O projeto mais "cabeludo" que peguei foi um arquivo .DAT que não conseguia decifrar de forma alguma. Não era texto linear ou uma estrutura que eu conseguisse mapear. Parecia estar tudo criptografado. Depois de muito penar e de olhar horas para aqueles dados, descobri o método: a "criptografia" genial do programador era simplesmente gravar todas as palavras ao contrário de forma estrutural. Assim que percebi isso, fiz a minha ferramenta ler tudo ao contrário, e o arquivo foi "decodificado".

Naquela época, sem internet, esta habilidade não me deu "reputação"; ninguém fora da empresa sabia o que eu fazia. Mas deu-me algo mais importante: vantagem competitiva para fechar negócios e tempo livre para desenvolver, porque o problema que poderia travar alguns de meus concorrentes (a migração) era o nosso trunfo inicial.

Hoje, as ferramentas de ETL são fantásticas, mas muitas delas falham quando encontram um arquivo verdadeiramente "quebrado". A lição que aprendi é que a verdadeira engenharia de dados não está em saber configurar a ferramenta moderna; está na paciência e na capacidade de descer ao nível do byte, entender a estrutura fundamental da informação e, se for preciso, construir a ferramenta que faça o trabalho.

Este artigo é baseado numa história de "Dos 5 Minutos de uma Fita Cassete a 40 Anos de Código", as memórias do autor.
Leia a história completa aqui.