O que você precisa saber sobre o professor xavier antes de instalar
A maioria das pessoas que tenta usar o professor xavier pela primeira vez dá merda porque pula a etapa de configuração do ambiente. Eu perdi três dias num projeto por não ter percebido que a versão estável do repositório não é compatível com Python 3.12. O cara que mantém o projeto recomenda expressamente o uso de uma venv com 3.10 ou 3.11. Se você criar o ambiente depois de ter já instalado as dependências, vai ter que reinstalar tudo de novo. Só isso.
Download e instalação do professor xavier
O repositório oficial fica em github.com/xavier-project/framework. Você baixa o código-fonte, entra na pasta e roda o comando de instalação que tá no README. Mas o README não fala de um detalhe importante: o pacote de dependências tem um bug conhecido que quebra a instalação automática de um dos módulos opcionais, o parser XML. Na prática, isso significa que você tem que rodar um pip install manual depois do install padrão. A linha é simples, mas se você não souber que ela existe, o professor xavier vai carregar e travar na primeira vez que você tentar processar arquivos XML grandes. Eu descobri isso quando um cliente pediu para eu processar um dump de dados com mais de 40 mil registros em XML estruturado. O servidor começou a retornar erro de módulo não encontrado. Passei duas horas investigando logs antes de perceber que era exatamente esse bug. A workaround é instalar o pacote xmlparser separadamente. Feito isso, o processamento roda em cerca de 6 minutos para o volume que citei, contra 45 minutos que levaria se você não configurasse o cache corretamente.
Como o professor xavier funciona na prática
O conceito central do professor xavier é a pipeline de pré-processamento. Você define um conjunto de regras, o sistema aplica, e você recebe dados limpos. Parece trivial, mas a forma como as regras são aplicadas em lote faz diferença. Quando você passa mais de 10 mil entradas de uma vez, o buffer de memória pode estourar se não configurar o parâmetro chunk_size corretamente. O valor padrão é 500, o que é muito baixo para datasets grandes e muito alto para memória restrita. Eu uso 2000 como padrão no meu dia a dia. Funciona bem em máquinas com 16GB de RAM. Outro ponto que ninguém menciona nos tutoriais é o comportamento do sistema quando há campos faltando nos dados de entrada. O professor xavier não falha. Ele simplesmente preenche com null e continua. Isso pode parecer conveniente, mas em produção é armadilha. Você pode passar semanas achando que os dados estão certos até perceber que 30% dos registros tinham campos obrigatórios ausentes e o sistema estava mascarando o problema silenciosamente. A solução é rodar sempre uma validação pós-processamento com o módulo de audit que vem embutido.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Limitações reais que você precisa aceitar
O professor xavier não é solução para tudo. Ele foi construído para processamento estruturado e semiestruturado. Se os seus dados forem texto livre não formatado, como relatórios em PDF escaneados ou imagens, o sistema simplesmente não tem módulo de OCR integrado. Você vai precisar de uma ferramenta separada, como tesseract, para extrair o texto antes de passar pelo professor xavier. Isso aumenta o tempo total do fluxo em cerca de 40%, então considere isso no seu cronograma. Uma limitação técnica importante é a falta de suporte nativo a processamento paralelo em múltiplos núcleos. O sistema roda essencialmente single-threaded nas operações de transformação. Se você tiver um servidor com 32 núcleos disponíveis, o professor xavier vai usar basicamente um. A workaround que eu uso é dividir o dataset em n partes iguais e rodar instâncias separadas do professor xavier para cada partição, depois consolidar os resultados. Não é elegante, mas funciona e reduz o tempo de processamento de forma proporcional ao número de instâncias que você consegue rodar.
Dicas que eu aprendi na unha
Não tente debugar configurando logging no nível DEBUG em produção. Os logs do professor xavier geram cerca de 2GB de texto por hora quando tudo está rodando normal. Isso enche o disco rapidamente e ainda torna a leitura dos logs quase impossível por causa do volume. Use info no dia a dia e só suba para debug quando tiver um problema específico que exija rastreio detalhado. Se o seu fluxo de trabalho envolve reprocessar os mesmos dados com configurações diferentes, ative o modo de cache persistente. O padrão é limpar o cache a cada execução, o que é desperdício quando você está em fase de teste. Com o cache persistente, a segunda execução dos mesmos dados leva segundos ao invés de minutos. Eu configurei isso num script automatizado que roda toda madrugada e reduzi o tempo total de execução do pipeline de 3 horas para 22 minutos, incluindo a etapa de validação.
O projeto não tem interface gráfica. É tudo via linha de comando e arquivos de configuração YAML. Se você acha que vai conseguir produtividade com interface visual, está enganado. A curva de aprendizado inicial é de cerca de duas semanas até você dominar a sintaxe dos arquivos de configuração. Depois disso, a velocidade de desenvolvimento compensa porque você pode versionar as configurações inteiras junto com o código-fonte do projeto. Isso também facilita a replicação do ambiente entre desenvolvimento e produção sem depender de captura de tela ou documentação de configuração.
