 |
| Bellacosa Mainframe e a engenharia de dados |
☕ Um Café no Bellacosa Mainframe
Engenharia de Dados para um Programador COBOL Padawan
Você Não Está Mudando de Profissão. Está Descobrindo que Sempre Trabalhou com Dados.
"Toda geração acredita que inventou a Engenharia de Dados. Quem passou décadas desenvolvendo em COBOL sabe que mover, transformar, validar e proteger dados sempre foi o coração do Mainframe."
Se existe uma palavra que domina o mercado de tecnologia atualmente, ela é Dados.
Data Engineer.
Data Lake.
Data Warehouse.
Data Mesh.
Data Fabric.
Big Data.
Analytics.
Machine Learning.
Inteligência Artificial.
Para quem acompanha as vagas do LinkedIn, parece que surgiu uma profissão completamente nova.
Mas será que surgiu mesmo?
Se você é um Programador COBOL Padawan, talvez esteja olhando para esse universo pensando:
"Isso não é para mim."
Ou talvez pior.
"Vou precisar esquecer tudo o que aprendi nos últimos anos."
Nada poderia estar mais distante da realidade.
Na verdade, existe uma notícia excelente.
Boa parte da Engenharia de Dados nasceu exatamente nos ambientes onde o COBOL reina há mais de sessenta anos.
Hoje vamos tomar um café e descobrir por que um programador COBOL possui muito mais vantagens para aprender Engenharia de Dados do que imagina.
O maior equívoco sobre Engenharia de Dados
Quando alguém fala "Data Engineer", muitas pessoas imaginam imediatamente alguém escrevendo Python.
Outros imaginam Spark.
Outros imaginam nuvem.
Outros imaginam Inteligência Artificial.
Tudo isso faz parte da profissão.
Mas nada disso explica sua essência.
A verdadeira Engenharia de Dados pode ser resumida em uma única pergunta:
Como garantir que a informação certa chegue ao lugar certo, no momento certo, com qualidade e segurança?
Perceba.
Não estamos falando de linguagem.
Não estamos falando de banco de dados.
Não estamos falando de cloud.
Estamos falando de engenharia.
E engenharia sempre existiu.
O COBOL sempre foi uma linguagem de dados
Vamos imaginar um programa extremamente simples.
READ CLIENTE
IF STATUS = "A"
COMPUTE LIMITE = SALARIO * 3
WRITE CLIENTE-APROVADO
END-IF
O que esse programa faz?
Não desenha telas.
Não cria animações.
Não faz gráficos.
Ele faz algo muito mais importante.
Transforma dados.
Exatamente o trabalho de um pipeline moderno.
Hoje essa transformação poderia estar escrita em:
Python.
Spark.
SQL.
Scala.
Mas o conceito permanece exatamente o mesmo.
Entrada.
Transformação.
Saída.
Um pipeline moderno não é muito diferente de um Job Batch
Vamos comparar.
No Mainframe
Arquivo VSAM
↓
Programa COBOL
↓
SORT
↓
IDCAMS
↓
DB2
↓
Relatório
Agora veja um ambiente moderno.
API
↓
Python
↓
Spark
↓
Data Lake
↓
Data Warehouse
↓
Dashboard
Mudaram as ferramentas.
O fluxo continua praticamente idêntico.
Receber.
Transformar.
Validar.
Persistir.
Consumir.
É por isso que muitos profissionais de Mainframe aprendem Engenharia de Dados com enorme facilidade.
Eles já entendem o processo.
Só precisam aprender novos nomes.
Nível 1 — SQL e Linux
Toda jornada começa aqui.
Algumas pessoas desprezam SQL.
Grave isto.
Quem domina SQL domina dados.
SQL continua sendo a língua universal da informação.
Não importa se você usa:
Oracle
SQL Server
PostgreSQL
MySQL
Db2
Snowflake
BigQuery
Databricks
Spark SQL
Todos conversam através de SQL.
No Linux acontece algo parecido.
Quem trabalha com z/OS talvez ache curioso.
Mas muitos comandos Linux lembram bastante utilitários clássicos do Mainframe.
Por exemplo.
Localizar informações.
Linux
grep CPF clientes.txt
Mainframe
SORT INCLUDE
Contar registros.
Linux
wc -l arquivo.txt
Mainframe
ICETOOL COUNT.
Filtrar.
Ordenar.
Mesclar.
Tudo isso já fazia parte do universo Batch décadas antes do Big Data existir.
Nível 2 — Programação
Aqui normalmente aparece Python.
Mas poderia ser Java.
Scala.
Go.
Até mesmo COBOL.
Sim.
COBOL continua sendo usado em pipelines modernos.
Principalmente quando o dado nasce no Mainframe.
O objetivo agora não é consultar dados.
É automatizar processos.
Imagine.
Você precisa:
baixar arquivos
consumir APIs
descompactar
validar
gerar logs
carregar banco
enviar e-mail
Tudo isso exige programação.
Não importa a linguagem.
O importante é pensar em automação.
O primeiro choque: APIs
Muitos programadores COBOL perguntam:
"O que é uma API?"
A resposta mais simples é:
Uma API é um programa conversando com outro programa.
Só isso.
Você já fazia isso.
CICS fazia isso.
MQ fazia isso.
IMS fazia isso.
A diferença é que hoje a conversa normalmente acontece usando:
HTTP
JSON
REST
GraphQL
gRPC
O conceito continua exatamente igual.
Nível 3 — Spark
Aqui começa a diversão.
Imagine que seu programa COBOL processa:
5 milhões de registros.
Funciona muito bem.
Agora imagine:
5 bilhões.
Não existe CPU suficiente.
Surge então o processamento distribuído.
Em vez de uma máquina.
Cem máquinas.
Ou mil.
Cada uma processando uma pequena parte.
Esse é o Spark.
Ele divide o problema.
Depois reúne os resultados.
É como um enorme SORT distribuído.
Spark não substitui SQL
Esse é outro mito.
Na prática.
Boa parte do Spark moderno utiliza SQL.
Ou Spark SQL.
Ou DataFrames.
Ou seja.
O conhecimento adquirido anteriormente continua sendo utilizado.
Nada é perdido.
Tudo evolui.
Nível 4 — Cloud
Aqui muita gente se assusta.
Parece outro universo.
Na verdade, não é.
Cloud é apenas um novo datacenter.
Só que alugado.
Imagine um CPD gigantesco.
Você liga um servidor.
Usa.
Desliga.
Paga apenas pelo tempo utilizado.
É isso.
Claro.
Existem centenas de serviços.
Mas a ideia continua simples.
Infraestrutura sob demanda.
O que muda para o Engenheiro de Dados?
Antes.
Você tinha um servidor.
Agora possui dezenas.
Centenas.
Tudo automatizado.
Surge então uma nova preocupação.
Escalabilidade.
Monitoramento.
Custos.
Segurança.
Nível 5 — Inteligência Artificial
Chegamos ao assunto da moda.
Todo mundo quer trabalhar com IA.
Mas poucos entendem uma verdade simples.
A IA depende completamente da Engenharia de Dados.
Imagine um modelo treinado com:
CPFs inválidos.
Datas erradas.
Valores duplicados.
Clientes repetidos.
O resultado será desastroso.
Existe uma frase muito antiga.
Garbage In.
Garbage Out.
Entrou lixo.
Sai lixo.
Por isso.
Antes da Inteligência Artificial.
Existe um profissional invisível.
O Engenheiro de Dados.
Ele garante que os dados sejam:
limpos
organizados
consistentes
históricos
auditáveis
confiáveis
Sem isso.
Nenhum ChatGPT.
Nenhum Copilot.
Nenhum modelo funciona adequadamente.
Mas existe algo ainda mais importante...
A imagem que inspirou este artigo mostra uma sequência de tecnologias.
Ela está correta.
Mas incompleta.
Porque existem conhecimentos que nunca saem de moda.
Modelagem de Dados
Se existe um superpoder do programador COBOL, é este.
Quem desenvolveu sistemas bancários conhece:
Cliente.
Conta.
Agência.
Contrato.
Movimentação.
Parcela.
Histórico.
Relacionamentos.
Tudo isso é modelagem.
Sem um bom modelo.
Nem Spark salva.
Nem IA resolve.
Nem Cloud ajuda.
Qualidade dos Dados
Imagine um cadastro onde o mesmo cliente aparece quinze vezes.
Ou um saldo negativo impossível.
Ou datas inexistentes.
Quem resolve?
Não é a IA.
É engenharia.
Validação.
Regras.
Auditoria.
Consistência.
Exatamente como fazemos há décadas em sistemas críticos.
Observabilidade
No Mainframe existe SDSF.
SMF.
RMF.
Logs.
Mensagens JES.
Abends.
Tudo isso existe para observar o ambiente.
Hoje fazemos exatamente a mesma coisa.
Só mudaram as ferramentas.
Monitoramos:
pipelines
latência
falhas
volumes
distribuição
anomalias
A filosofia continua igual.
Nunca confiar.
Sempre medir.
Governança
Poucos assuntos cresceram tanto.
Hoje toda empresa pergunta:
Quem alterou esse dado?
Quem acessou?
Quem apagou?
Quando?
Por quê?
No Mainframe isso sempre foi levado muito a sério.
RACF.
Auditoria.
Perfis.
Permissões.
Hoje apenas ampliamos esse conceito.
Versionamento
Você conhece Endevor?
ISPW?
ChangeMan?
Parabéns.
Você já trabalhou com gestão de versões antes mesmo do Git existir.
Hoje usamos GitHub.
GitLab.
Bitbucket.
Mas o princípio permanece.
Nunca alterar produção diretamente.
Sempre controlar mudanças.
DataOps
Assim como surgiu DevOps.
Hoje existe DataOps.
Automatizar testes.
Validar qualidade.
Executar pipelines.
Fazer deploy.
Documentar.
Monitorar.
Tudo automaticamente.
Isso reduz erros humanos.
Aumenta confiabilidade.
E acelera entregas.
O conhecimento mais importante continua sendo o negócio
Imagine dois profissionais.
O primeiro conhece:
Spark.
Kafka.
Snowflake.
Airflow.
Terraform.
Kubernetes.
Python.
Databricks.
O segundo conhece apenas SQL.
Mas entende perfeitamente:
crédito
seguros
contabilidade
tributação
previdência
Qual deles gera mais valor?
Na maioria das empresas.
O segundo.
Porque tecnologia resolve problemas.
Mas somente quem entende o negócio consegue resolver o problema correto.
O programador COBOL já possui metade da jornada concluída
Esse talvez seja o maior segredo da Engenharia de Dados.
Profissionais de Mainframe normalmente já dominam:
✔ Processamento Batch
✔ Integridade transacional
✔ Bancos relacionais
✔ Modelagem
✔ Performance
✔ Grandes volumes
✔ Segurança
✔ Auditoria
✔ Sistemas críticos
✔ Dados corporativos
O que falta aprender?
As ferramentas modernas.
E ferramentas podem ser aprendidas.
Princípios levam anos para serem construídos.
A verdadeira evolução
Muitos imaginam a carreira assim.
COBOL
↓
Python
↓
Spark
↓
Cloud
↓
IA
Na realidade.
Ela é muito mais parecida com isto.
Negócio
│
┌──────────────┼──────────────┐
│ │ │
Modelagem Engenharia Arquitetura
│ │ │
├──────────────┼──────────────┤
│ │ │
SQL Programação Segurança
│ │ │
├──────────────┼──────────────┤
│ │ │
Spark Cloud Observabilidade
│ │ │
└──────────────┼──────────────┘
│
DataOps
│
Inteligência Artificial
Observe que a IA aparece quase no final.
Isso não é coincidência.
Ela depende de tudo o que veio antes.
Um café antes de voltar ao código...
Existe uma frase muito comum nas redes sociais:
"Aprenda IA."
Eu faria uma pequena correção.
Aprenda Engenharia.
Porque tecnologias mudam.
Spark um dia será substituído.
Novos bancos aparecerão.
Novas linguagens surgirão.
Novos frameworks nascerão.
Assim como Clipper deu lugar a outras soluções, e como muitas ferramentas de ETL evoluíram ao longo das décadas, o ecossistema continuará mudando.
Mas alguns princípios permanecem praticamente imutáveis desde os primeiros sistemas corporativos:
Dados precisam ser confiáveis.
Processos precisam ser previsíveis.
Sistemas precisam ser auditáveis.
Arquiteturas precisam ser sustentáveis.
Segurança nunca é opcional.
O negócio deve orientar a tecnologia, e não o contrário.
É exatamente por isso que um Programador COBOL não está começando do zero ao olhar para a Engenharia de Dados. Pelo contrário: ele já carrega uma bagagem construída em ambientes onde disponibilidade, consistência e integridade sempre foram requisitos inegociáveis.
No fim das contas, a maior transformação não é aprender Python, Spark ou Cloud. É perceber que o trabalho sempre foi o mesmo: transformar dados em informação confiável para apoiar decisões.
As ferramentas evoluem.
Os nomes mudam.
As interfaces ficam mais modernas.
Mas a boa engenharia continua sendo reconhecida pelos mesmos atributos de décadas atrás: simplicidade, clareza, desempenho, confiabilidade e foco no problema de negócio.
Então, Padawan, da próxima vez que ouvir alguém dizer que Engenharia de Dados é "uma profissão completamente nova", sorria, tome mais um gole do seu café e lembre-se: os mainframes já movimentavam bilhões de registros por dia quando muitos dos conceitos modernos ainda nem tinham nome.
