 |
| Bellacosa Mainframe e desafio de analisar dados com Python e Pandas |
☕💣 O DIA EM QUE O ESTAGIÁRIO DESCOBRIU QUE IA NÃO É MÁGICA — E QUE 90% DOS PROJETOS DE DADOS MORREM ANTES DE CHEGAR À PRODUÇÃO
Existe uma lenda moderna circulando pelos corredores das empresas.
Ela diz que basta instalar Python, importar Pandas, rodar meia dúzia de notebooks, colocar um gráfico colorido no Power BI e, de repente, a organização inteira se transforma em uma potência orientada por dados.
É uma história bonita.
Mas também é uma das maiores mentiras tecnológicas do século XXI.
Se você trabalhou alguns anos em Mainframe, sabe exatamente do que estou falando.
No mundo z/OS, ninguém acreditava que um programa COBOL estava pronto apenas porque compilou.
No entanto, na era dos notebooks e dashboards, muita gente acredita que um projeto está concluído apenas porque o gráfico ficou bonito.
E é exatamente aí que começam os problemas.
O nascimento do caos
Todo projeto de dados começa da mesma forma.
Alguém chega com uma frase aparentemente simples:
"Precisamos analisar nossos dados."
Parece inofensivo.
Então surgem os CSVs.
Planilhas.
Arquivos Excel.
Dados extraídos de APIs.
Tabelas SQL.
Arquivos JSON.
E, inevitavelmente, aquela planilha mantida por alguém do financeiro que ninguém sabe exatamente como foi construída.
Nesse momento, o profissional de dados descobre uma verdade brutal:
Os dados do mundo real são muito mais bagunçados do que qualquer exemplo de curso.
Muito mais.
O primeiro choque: os dados estão errados
A primeira lição de qualquer analista é simples.
Nunca confie nos dados.
Jamais.
Antes de qualquer gráfico, modelo ou dashboard, existe uma etapa fundamental:
Validação.
Em Python, isso normalmente começa com:
head()
info()
describe()
isnull().sum()
Esses comandos parecem simples.
Mas eles revelam coisas assustadoras.
Colunas vazias.
Valores negativos impossíveis.
Datas inválidas.
Campos misturando texto e números.
Duplicidades.
Informações faltando.
Em outras palavras:
A realidade.
No Mainframe, chamávamos isso de saneamento de entrada.
No mundo moderno, chamam de Data Quality.
Mudou o nome.
Não mudou o problema.
O terror dos valores ausentes
Todo iniciante aprende rapidamente o significado de NaN.
E descobre que ele aparece em todos os lugares.
A coluna AGE do Titanic?
Vazia para centenas de passageiros.
A coluna CABIN?
Mais vazia que sala de reunião numa sexta-feira às 18h.
É aí que surge uma das decisões mais importantes de qualquer projeto:
O que fazer com os valores ausentes?
Ignorar?
Excluir?
Preencher?
Usar média?
Mediana?
Modelos preditivos?
Não existe resposta universal.
Existe apenas análise crítica.
Quem acredita que existe uma receita mágica para limpeza de dados provavelmente nunca colocou um modelo em produção.
O dia em que o gráfico enganou todo mundo
Depois da limpeza surge a visualização.
E aqui acontece outro fenômeno interessante.
As pessoas começam a acreditar mais no gráfico do que nos dados.
Um gráfico bonito possui um poder quase hipnótico.
Mas gráficos também mentem.
Ou melhor:
Pessoas podem usá-los para mentir.
Um eixo mal configurado.
Uma escala inadequada.
Uma agregação incorreta.
E pronto.
Uma decisão milionária pode ser tomada baseada em uma interpretação equivocada.
Por isso o profissional sério aprende rapidamente:
Visualização não substitui análise.
Ela apenas ajuda a comunicar análise.
Histograma, Boxplot e a arte de enxergar padrões
Quando começamos a explorar dados, algumas ferramentas tornam-se indispensáveis.
O histograma mostra distribuição.
O boxplot revela dispersão.
O gráfico de dispersão mostra correlações.
Parece simples.
Mas esses gráficos respondem perguntas fundamentais:
Onde estão os valores mais frequentes?
Existem outliers?
Existe relação entre variáveis?
Há comportamento anormal?
No Mainframe fazíamos isso analisando relatórios gigantescos.
Hoje fazemos isso visualmente.
Mas o objetivo continua exatamente o mesmo.
Descobrir o que os dados estão tentando nos dizer.
Python não é só Pandas
Existe outro mito muito popular.
O de que Python se resume a Pandas.
Não.
Python é um ecossistema inteiro.
Pandas organiza os dados.
Matplotlib cria gráficos.
Plotly adiciona interatividade.
Requests conversa com APIs.
SQLite armazena informações.
Pytest valida comportamentos.
Logging registra eventos.
Time mede desempenho.
Cada biblioteca resolve um problema específico.
E quando utilizadas juntas criam algo poderoso.
Uma plataforma completa de automação e análise.
O inimigo invisível chamado exceção
Se existe algo que o Mainframe ensinou bem foi respeito pelo erro.
Quem já viu um ABEND em produção entende isso.
No Python o equivalente aparece em forma de exceções.
ZeroDivisionError.
ValueError.
TypeError.
FileNotFoundError.
E muitos outros.
A diferença entre um profissional experiente e um aventureiro normalmente aparece aqui.
O aventureiro ignora erros.
O profissional os trata.
Porque sabe que sistemas reais falham.
Arquivos desaparecem.
APIs ficam indisponíveis.
Usuários digitam valores absurdos.
E o software precisa sobreviver a tudo isso.
Logs: o diário secreto da aplicação
Outro hábito herdado do Mainframe é registrar eventos.
Durante décadas operadores analisaram logs.
Hoje continuamos fazendo exatamente a mesma coisa.
Apenas mudaram as ferramentas.
Logs ajudam a responder perguntas importantes:
O que aconteceu?
Quando aconteceu?
Quem executou?
Qual foi o erro?
Sem logs, investigar falhas é praticamente arqueologia digital.
Com logs, torna-se uma análise técnica.
Por isso aplicações profissionais usam logging.
Não print.
Testes: a diferença entre coragem e imprudência
Muitos programadores confundem confiança com sorte.
"Eu executei uma vez e funcionou."
Excelente.
Mas isso não significa nada.
É por isso que testes existem.
Pytest tornou essa tarefa extremamente simples.
Uma função.
Um assert.
Uma expectativa.
Se o comportamento mudar inesperadamente, o teste acusa.
Parece básico.
Mas salva projetos inteiros.
Toda alteração relevante deveria ser seguida por nova execução dos testes.
Sempre.
Sem exceções.
Clean Code não é frescura
Existe uma resistência curiosa ao conceito de código limpo.
Algumas pessoas acreditam que o importante é funcionar.
Errado.
Código é escrito uma vez.
Mas lido centenas de vezes.
Por isso nomes descritivos importam.
Funções pequenas importam.
Modularização importa.
Organização importa.
Código confuso custa dinheiro.
Muito dinheiro.
Especialmente quando o autor original já não trabalha mais na empresa.
O poder da modularização
Projetos pequenos sobrevivem ao caos.
Projetos grandes não.
Quando o sistema cresce, modularização deixa de ser luxo.
Passa a ser necessidade.
Cada função deve possuir responsabilidade clara.
Cada módulo deve resolver um problema específico.
Cada componente deve ser reutilizável.
Isso reduz complexidade.
Facilita manutenção.
E melhora a qualidade geral do software.
Performance: a verdade aparece no cronômetro
Existe uma frase clássica:
"Premature optimization is the root of all evil."
Mas ignorar performance também é perigoso.
É por isso que medir importa.
O módulo time permite descobrir exatamente quanto tempo uma operação leva.
Sem medições, toda otimização vira chute.
Com medições, ela vira engenharia.
E engenharia sempre vence opinião.
Escalabilidade: o momento da verdade
Todo código funciona com cem registros.
O desafio começa com cem milhões.
É aí que surge a palavra escalabilidade.
Um sistema escalável consegue crescer sem colapsar.
Consegue lidar com aumento de carga.
Com aumento de volume.
Com aumento de usuários.
Projetos que ignoram escalabilidade costumam funcionar perfeitamente.
Até o dia em que deixam de funcionar.
Machine Learning não é adivinhação
Chegamos então ao assunto favorito do mercado.
Machine Learning.
Aqui surgem métricas importantes.
Precision.
Recall.
RMSE.
MAPE.
WSS.
Cada uma responde perguntas diferentes.
Precision pergunta:
"Quando o modelo disse que era positivo, quantas vezes acertou?"
Recall pergunta:
"Quantos positivos reais o modelo encontrou?"
RMSE mede erro na unidade original.
MAPE mede erro percentual.
WSS avalia dispersão em clustering.
Sem métricas, modelos são apenas opiniões sofisticadas.
Com métricas, tornam-se sistemas mensuráveis.
Storytelling: a habilidade esquecida
Existe um erro comum.
Acreditar que análise termina quando o modelo termina.
Não termina.
Na verdade, ali começa a parte mais difícil.
Comunicar resultados.
Storytelling com dados significa transformar números em narrativa.
Explicar contexto.
Mostrar padrões.
Interpretar resultados.
Demonstrar relevância.
Porque uma análise perfeita que ninguém entende possui valor próximo de zero.
Dashboards: o cockpit da empresa
Finalmente chegamos aos dashboards.
Eles não existem para serem bonitos.
Existem para acelerar decisões.
Um dashboard bem construído responde perguntas rapidamente.
Mostra indicadores críticos.
Destaca anomalias.
Facilita ações.
Quando bem feito, torna-se o painel de controle da organização.
Quando mal feito, vira apenas decoração corporativa.
A grande lição
Depois de tudo isso surge uma conclusão interessante.
A tecnologia mudou.
As ferramentas mudaram.
Os nomes mudaram.
Mas os princípios continuam os mesmos.
Validação.
Controle.
Monitoramento.
Teste.
Documentação.
Performance.
Organização.
Disciplina.
Os profissionais de Mainframe aprenderam essas lições há décadas.
E agora a nova geração de cientistas de dados está redescobrindo exatamente os mesmos conceitos.
A diferença é que hoje usamos Python.
Ontem usávamos COBOL.
Mas a verdade permanece.
Dados ruins geram decisões ruins.
Código ruim gera sistemas ruins.
Processos ruins geram resultados ruins.
E nenhuma quantidade de Inteligência Artificial consegue corrigir isso.
Porque, no final das contas, a tecnologia mais importante de qualquer projeto continua sendo a mesma desde os tempos dos cartões perfurados:
O cérebro de quem está operando a máquina.
☕💣
