Pular para conteúdo

Resultados e Conclusão da Engenharia de Dados: Do Legado ao Modern Data Lakehouse

A jornada de migração do projeto InfoEscola representou um desafio profundo de engenharia reversa e modernização de infraestrutura. O objetivo de resgatar 30 anos de histórico de um sistema obsoleto (MySQL 5.1) e transformá-lo em um ativo analítico confiável foi concluído com sucesso.

Abaixo, apresentamos o resumo dos resultados e as conclusões das fases técnicas que estabeleceram a fundação de dados do projeto.

🧱 Fase 1: Modernização e Carga de Schema (DDL)

  • O Resultado: Toda a estrutura lógica do banco de dados legado foi convertida e modernizada para padrões atuais. Foram migrados com sucesso 100% dos artefatos: 467 Tabelas, 77 Views, 722 Rotinas e 6 Eventos.
  • A Conclusão: A estratégia de separar a criação de tabelas "nuas" da aplicação de constraints (chaves estrangeiras e índices) provou-se vital. O desenvolvimento de um extrator inteligente permitiu corrigir dinamicamente incompatibilidades do legado, como a conversão de engines obsoletas (MyISAM para InnoDB), a adequação de character sets (latin1 para utf8mb4) e o ajuste de tipos de dados problemáticos antes mesmo de tocarem o novo servidor.

⛏️ Fase 2: Extração de Dados (O Desafio do Legado)

  • O Resultado: Cerca de 100GB de dados brutos foram extraídos do servidor "idoso" sem causar interrupções ou estouros de memória, gerando arquivos otimizados em formato Parquet na camada Bronze (GCS).
  • A Conclusão: O uso de Python com ConnectorX (Rust) e Apache Arrow permitiu paralelismo e altíssima performance. A principal lição desta fase foi a adoção da "programação defensiva" (Pushdown Transformations): não se pode confiar na integridade de dados legados. Inconsistências severas — como 274 espaços em branco contíguos em colunas de texto, "datas zero" (0000-00-00) e dados binários corrompidos — foram higienizadas diretamente na origem via SQL, utilizando conversões para Hexadecimal (HEX()) e lógicas de NULLIF.

📤 Fase 3: Carga no Cloud SQL (Ingestão em Massa)

  • O Resultado: As 467 tabelas foram populadas em um banco de dados moderno (Cloud SQL MySQL 8.0) utilizando rotinas automatizadas e transacionais de Bulk Loading (LOAD DATA FROM GOOGLE CLOUD STORAGE / LOCAL INFILE).
  • A Conclusão: O carregamento exigiu rigor para contornar restrições modernas. A decisão arquitetural de ingerir os dados brutos convertidos em Hexadecimal provou-se a solução definitiva para evitar a expansão de encoding (Data truncated) e a corrupção de binários (ex: senhas criptografadas), revertendo-os com segurança no destino através da função UNHEX(). A aplicação das constraints após a carga dos dados garantiu alta velocidade e atuou como um validador de integridade em lote.

🕵️ Fase 4: Validação dos Dados (O "Sherlock")

  • O Resultado: A reconciliação provou 100% de paridade bit a bit entre os sistemas para todos os registros migrados. A contagem de linhas e o conteúdo exato das 467 tabelas bateram perfeitamente.
  • A Conclusão: Scripts simples de diff não escalam. O sucesso da auditoria dependeu de uma arquitetura baseada em Checksums Agregados no Servidor (BIT_XOR(MD5(CONCAT_WS...))) processados em fatias (chunks). Isso moveu o trabalho pesado para o motor do banco de dados, reduzindo o tráfego de rede a meros bytes e permitindo o isolamento cirúrgico de anomalias (como a deriva de dados / data drift entre os momentos de extração e carga) com ferramentas forenses customizadas. O banco de dados legado foi oficialmente "arquivado" após essa validação.

🗂️ BigQuery: Catalogação Serverless (O Data Lakehouse)

  • O Resultado: A camada Bronze (arquivos Parquet no Google Cloud Storage) foi instantaneamente disponibilizada para consultas analíticas massivas no BigQuery sem a necessidade de duplicar os dados.
  • A Conclusão: Ao invés de realizar uma carga física de dados cara, adotou-se o padrão Serverless usando Tabelas Externas (External Tables). Um script Python automatizado leu a estrutura do GCS e mapeou os arquivos utilizando a inferência nativa de esquema do Parquet e ativando o Partition Pruning automático via hive_partitioning_mode = 'AUTO'. Isso transformou um repositório de arquivos "frios" em um motor de Data Lakehouse de altíssimo desempenho, pagando apenas pelos dados lidos durante a consulta.

🎯 Conclusão Final do Projeto de Engenharia

O projeto InfoEscola ultrapassou a premissa de um simples "dashboard de BI". As fases de engenharia demonstraram a capacidade de pegar um sistema no fim de sua vida útil, extrair seu conhecimento bruto com segurança e construir um ecossistema de dados moderno, escalável e perfeitamente auditável.

Com a origem legada isolada e a camada Bronze estabelecida como uma Fonte Única de Verdade (Single Source of Truth) inabalável no GCS e BigQuery, o terreno técnico "duro" foi vencido. O projeto agora avança com segurança total para a Engenharia Analítica (Camadas Silver/Gold) e para o Storytelling Visual com Dash e DuckDB, focando em traduzir essa rica base de dados operacionais em valor claro, métricas de negócio interativas e narrativas contundentes para o portfólio.