 |
| Bellacosa Mainframe apresenta Data Analytics |
☕ Um Café no Bellacosa Mainframe
O Barão de Münchhausen Entra no CPD — Da Estatística à GenAI, sem precisar cavalgar uma bala de canhão
Ou: como Estatística, Pesquisa Operacional, Tukey, Codd, Data Warehousing, Analytics, Big Data, Data Science, Machine Learning e IA Generativa acabaram encontrando COBOL dentro do IBM Z — e por que o programador que entende os dados tem uma vantagem que nenhum dashboard consegue inventar
Prólogo — O Barão chegou ao CPD montado numa distribuição normal
Conta o Barão de Münchhausen que certa manhã atravessou uma distribuição normal montado numa média aritmética, saltou sobre três outliers, amarrou seu cavalo numa mediana e chegou ao CPD exatamente no momento em que um batch COBOL terminava de processar alguns milhões de transações.
Naturalmente, não devemos acreditar em tudo.
A parte da distribuição normal é discutível.
A parte dos milhões de transações, nem tanto.
Quem trabalha com mainframe convive diariamente com quantidades gigantescas de dados: pagamentos, cartões, seguros, contas bancárias, pedidos, estoques, reservas, faturamento, logística, transações governamentais e inúmeras outras atividades.
Durante décadas aprendemos a fazer esses sistemas funcionarem.
Agora existe uma pergunta adicional:
O que podemos aprender com os dados que esses sistemas produzem?
É aí que começa nossa viagem pelo Data Analytics.
E nosso guia será justamente o homem conhecido por contar algumas das histórias mais improváveis da literatura.
Isso será conveniente porque existe uma regra importante em análise de dados:
Se uma história parece extraordinária, procure os dados antes de acreditar nela.
1. Afinal, o que é Data Analytics?
Podemos traduzir Data Analytics como Análise de Dados.
Mas simplesmente dizer isso esconde boa parte da história.
Data Analytics é um conjunto de processos, técnicas e ferramentas utilizados para transformar dados em informações capazes de ajudar pessoas e organizações a compreender acontecimentos e tomar decisões.
Podemos representar isso assim:
DADOS
↓
PREPARAÇÃO
↓
ANÁLISE
↓
PADRÕES
↓
INSIGHTS
↓
COMUNICAÇÃO
↓
DECISÃO
Observe algo importante.
O objetivo final não é criar um gráfico.
Também não é executar Python.
Muito menos instalar alguma ferramenta milagrosa com IA.
O objetivo é tomar decisões melhores com base em evidências.
Imagine um banco processando milhões de transações.
O sistema pode saber que:
CLIENTE = 837291
VALOR = 9800
HORA = 03:17
CANAL = WEB
Esses são dados.
Mas Data Analytics começa quando perguntamos:
Esse valor é normal para esse cliente?
Ele costuma comprar às três da manhã?
Esse canal é habitual?
Houve outras compras semelhantes?
O endereço IP está relacionado à localização normalmente utilizada?
Agora os dados começaram a contar uma história.
2. “Mas quem inventou Data Analytics?”
O Barão imediatamente levanta a mão:
— Fui eu! Em 1783, durante uma viagem à Lua...
Não, Barão.
Pode abaixar a mão.
Não existe uma única pessoa reconhecida como inventora do Data Analytics.
Também não encontramos um inventor específico para a expressão Introduction to Data Analytics.
Esse é simplesmente um título descritivo usado para cursos introdutórios sobre análise de dados.
A história intelectual do Data Analytics é muito mais interessante porque várias disciplinas contribuíram para sua formação.
Uma árvore bastante simplificada seria:
ESTATÍSTICA
│
├── Pesquisa Operacional
│
├── Análise de Dados
│ └── John Tukey — 1962
│
├── Bancos de Dados
│ └── Edgar F. Codd — década de 1970
│
├── Decision Support Systems
│
├── Data Warehousing / BI
│
├── Analytics
│ └── Thomas Davenport — 2006
│
├── Big Data
│
├── Data Science
│
└── Machine Learning / GenAI
Essa árvore não deve ser interpretada como uma genealogia rígida na qual uma tecnologia simplesmente substitui a anterior.
É melhor enxergá-la como uma acumulação de conhecimentos.
Estatística continua existindo.
SQL continua existindo.
Data Warehouse continua existindo.
Machine Learning não tornou regressão inútil.
IA generativa não tornou bancos de dados obsoletos.
E, para surpresa de algumas apresentações corporativas...
COBOL também continua aqui.
3. A raiz: Estatística
Antes de existir computador, já existia a necessidade de analisar números.
Populações, comércio, agricultura, astronomia, seguros, economia e administração pública produziram problemas que exigiam métodos quantitativos.
Daí se desenvolveram conceitos fundamentais como:
média;
mediana;
moda;
variância;
desvio padrão;
distribuição;
probabilidade;
correlação;
regressão.
Para o programador COBOL, alguns desses conceitos parecem muito mais familiares quando saem do livro de estatística.
Imagine tempos de resposta:
0,31
0,29
0,30
0,32
0,31
0,30
2,87
Existe alguma coisa estranha ali.
O 2,87 merece investigação.
Chamamos valores muito afastados do comportamento esperado de outliers.
O Barão naturalmente garante que o tempo de resposta de 2,87 segundos ocorreu porque um cavalo ficou preso no canal ESCON.
A equipe de produção prefere consultar os logs.
4. Média não conta toda a história
Imagine cinco transações:
100
105
110
115
10.000
A média é:
(100 + 105 + 110 + 115 + 10000) / 5
= 2086
Mas quatro das cinco transações estão perto de 100.
Por isso precisamos conhecer também mediana e dispersão.
A mediana seria:
110
Muito mais representativa do comportamento central daquele pequeno conjunto.
A dispersão, por sua vez, ajuda a entender quanto os valores se afastam uns dos outros.
Essa é uma lição fundamental para analytics:
Um único número raramente explica um sistema complexo.
É igualmente verdadeira para performance de mainframe.
Dizer:
“O response time médio é 300 ms.”
pode esconder períodos de 50 ms e outros de 5 segundos.
Por isso média, percentis, distribuição e dispersão importam.
5. Pesquisa Operacional entra no CPD
Outra contribuição importante veio da Pesquisa Operacional.
Ela utiliza modelos matemáticos para encontrar melhores decisões diante de restrições.
Imagine:
recursos limitados
+
múltiplas alternativas
+
objetivos
+
restrições
Isso aparece em logística, produção, transporte, escalonamento e planejamento.
Para quem conhece mainframe, a ideia não deveria parecer alienígena.
Um ambiente computacional também possui:
CPU
Memória
I/O
Prioridades
Workloads
SLAs
Janelas batch
E precisamos decidir como utilizar recursos limitados da melhor maneira possível.
O WLM provavelmente cumprimentaria a Pesquisa Operacional com bastante respeito.
6. John Tukey e a Análise de Dados
Em 1962, o estatístico John Tukey publicou o influente trabalho The Future of Data Analysis.
Tukey ajudou a fortalecer a ideia de que analisar dados era uma atividade intelectual própria, não simplesmente uma aplicação mecânica da estatística.
Posteriormente, seu trabalho sobre Exploratory Data Analysis — EDA tornou-se particularmente importante.
A ideia é poderosa:
Antes de tentar provar alguma coisa, explore os dados.
Observe.
Visualize.
Procure padrões.
Procure inconsistências.
Faça perguntas.
Para um programador COBOL, podemos traduzir:
Antes de alterar o programa porque alguém disse que “o sistema está lento”, investigue.
7. Edgar F. Codd aparece carregando tabelas
Chegamos aos anos 1970.
Entra em nossa história Edgar F. Codd, pesquisador da IBM.
Codd apresentou o modelo relacional para bancos de dados.
Essa contribuição transformaria profundamente a maneira como sistemas armazenam e consultam informações.
Em vez de pensar somente em estruturas físicas, passamos a trabalhar conceitualmente com:
TABELAS
LINHAS
COLUNAS
CHAVES
RELACIONAMENTOS
E desse universo emergiria SQL.
Para o programador COBOL:
EXEC SQL
SELECT SALDO
INTO :WS-SALDO
FROM CONTA
WHERE CONTA_ID = :WS-CONTA-ID
END-EXEC.
Parece cotidiano.
Mas existe uma enorme história da computação escondida atrás desse SELECT.
8. Decision Support Systems
À medida que empresas armazenavam mais informações, surgiu outra necessidade:
usar computadores não apenas para executar operações, mas também para ajudar pessoas a decidir.
Daí crescem os Decision Support Systems — DSS.
O sistema transacional responde:
“A venda aconteceu?”
O sistema de apoio à decisão pode perguntar:
“Por que as vendas caíram?”
Perceba a mudança.
OLTP → executar o negócio
Analytics → compreender o negócio
Naturalmente os dois mundos podem se alimentar.
9. Data Warehouse e Business Intelligence
Empresas possuíam dados espalhados em diversos sistemas.
Então apareceu outro problema:
Como juntar tudo isso para análise?
Entram Data Warehouses, Data Marts, processos ETL e ferramentas de Business Intelligence.
ETL significa:
Extract
Transform
Load
Ou:
Extrair
Transformar
Carregar
Quem trabalha com mainframe talvez esteja pensando:
“Nós fazemos coisas parecidas há décadas.”
E não está totalmente errado.
Arquivos são extraídos, classificados, combinados, transformados e carregados desde muito antes de o termo data pipeline virar moda.
DFSORT poderia escrever memórias bastante interessantes sobre isso.
10. Data Wrangling — o faxineiro que salva o projeto
Dados reais são bagunçados.
Encontramos:
campos vazios
duplicidades
datas incompatíveis
valores inválidos
espaços
códigos antigos
unidades diferentes
registros incompletos
Data Wrangling é o processo de transformar esse material em algo apropriado para análise.
Um fluxo típico inclui:
Discovery
↓
Transformation
↓
Validation
↓
Publishing
Isso pode envolver:
joins;
unions;
normalização;
limpeza;
enriquecimento;
validação.
Aqui existe uma regra que merece ser escrita na parede do CPD:
IA aplicada sobre dado ruim produz erro tecnologicamente sofisticado.
Ou, na versão tradicional:
Garbage In, Garbage Out.
O Barão prefere:
Garbage In, história extraordinária Out.
11. Analytics chega à sala da diretoria
Em 2006, Thomas H. Davenport publicou na Harvard Business Review o artigo Competing on Analytics.
Ele ajudou a popularizar a utilização de analytics como instrumento de vantagem competitiva.
A pergunta empresarial deixa de ser apenas:
“Quanto vendemos?”
e passa a incluir:
Quem compra?
Quando compra?
Por que compra?
Quem provavelmente deixará de comprar?
Onde existe fraude?
O que provavelmente acontecerá depois?
Os dados começam a participar diretamente da estratégia empresarial.
12. Big Data — quando o dataset comeu demais
Depois veio a explosão de dados.
Web.
Smartphones.
Sensores.
Logs.
Redes sociais.
Streaming.
IoT.
Transações digitais.
Passamos a falar dos famosos Vs do Big Data.
Entre eles:
Volume — quantidade.
Velocity — velocidade.
Variety — variedade.
Veracity — confiabilidade.
Tecnologias distribuídas como Hadoop e Spark ganharam destaque nesse cenário.
Mas existe uma curiosidade importante para nós.
Enquanto o mundo descobria que havia dados demais...
o mainframe provavelmente respondeu:
“Interessante. Conte-me mais.”
13. Data Science
Data Science combina conhecimentos de várias áreas:
Estatística
+
Computação
+
Conhecimento do domínio
+
Métodos analíticos
Isso explica uma coisa importantíssima.
O melhor profissional não é necessariamente aquele que conhece mais bibliotecas Python.
Conhecimento do domínio importa enormemente.
E é aí que um desenvolvedor COBOL experiente possui uma vantagem.
Ele talvez conheça:
cliente
conta
apólice
pedido
pagamento
fatura
liquidação
compensação
estoque
Não apenas como colunas.
Mas como processos reais do negócio.
14. Machine Learning
Machine Learning leva a análise adiante permitindo que modelos aprendam padrões a partir dos dados.
Algumas tarefas clássicas incluem:
Classificação
Determinar uma categoria.
TRANSAÇÃO
↓
LEGÍTIMA
ou
SUSPEITA
Clustering
Agrupar elementos semelhantes sem necessariamente possuir classes previamente definidas.
clientes
↓
grupo A
grupo B
grupo C
Regressão
Investigar relações entre variáveis e produzir estimativas.
Detecção de anomalias
Encontrar comportamentos incomuns.
E essa última nos leva diretamente ao exemplo do curso.
15. O ladrão roubou o cartão — ou talvez apenas as credenciais
Imagine um cliente que normalmente:
faz 3 compras por semana
gasta aproximadamente R$ 150
compra em São Paulo
utiliza dispositivos conhecidos
De repente:
12 compras
4 minutos
valores elevados
IP incomum
localização diferente
nova preferência de entrega
Nenhum desses elementos isoladamente prova fraude.
Mas juntos formam um comportamento digno de investigação.
Esse é um excelente exemplo de detecção de anomalias.
O processo seria aproximadamente:
1. Definir o problema
↓
2. Identificar os dados necessários
↓
3. Coletar
↓
4. Limpar
↓
5. Transformar
↓
6. Analisar
↓
7. Detectar padrões/anomalias
↓
8. Visualizar
↓
9. Comunicar
↓
10. Decidir
Esse é o coração do Data Analytics.
16. Visualização — porque ninguém quer interpretar 800 mil linhas
Imagine entrar numa reunião executiva e dizer:
— Descobri o problema. Aqui estão 4,7 milhões de registros CSV.
Você provavelmente não será convidado novamente.
Visualização transforma dados em representações compreensíveis.
Podemos utilizar:
gráficos de barras;
linhas;
histogramas;
scatter plots;
mapas;
dashboards.
Um gráfico pode revelar em segundos algo escondido em milhões de registros.
Mas cuidado:
visualização não substitui análise.
Um gráfico bonito com dados incorretos continua incorreto.
Só ficou mais convincente.
17. Storytelling — o momento Münchhausen
Finalmente chegamos ao território favorito do Barão.
Contar histórias.
Mas agora precisamos fazer exatamente o contrário do nosso guia.
Nada de exageros.
Nada de inventar.
Nada de cavalgar balas de canhão.
Data Storytelling significa comunicar uma conclusão apoiada por evidências.
Uma boa narrativa pode seguir:
CONTEXTO
↓
PROBLEMA
↓
EVIDÊNCIA
↓
DESCOBERTA
↓
IMPACTO
↓
RECOMENDAÇÃO
Em vez de dizer:
“CPU aumentou.”
Podemos dizer:
“Após o crescimento de 38% do volume transacional entre 10h e 11h, observamos aumento consistente no consumo de CPU acompanhado por crescimento do response time. A análise indica concentração no workload X e recomenda investigação das transações Y.”
Agora existe história.
Existe contexto.
Existe decisão possível.
18. E então apareceu a IA Generativa
Chegamos ao capítulo mais recente.
LLMs e IA generativa conseguem:
resumir informações;
gerar consultas;
auxiliar análise;
explicar padrões;
produzir código;
ajudar na documentação;
apoiar visualizações;
conversar com bases de conhecimento.
Mas existe um detalhe delicioso.
IA precisa de dados.
Dados precisam de:
qualidade
contexto
governança
segurança
interpretação
Portanto nossa árvore não desapareceu.
Ela ficou maior.
Estatística
↓
Data Analysis
↓
Databases
↓
BI
↓
Analytics
↓
Big Data
↓
Data Science
↓
Machine Learning
↓
GenAI
Cada camada carrega ideias das anteriores.
19. O IBM Z estava no porão o tempo inteiro
Agora olhamos para o mainframe.
Ali encontramos:
COBOL
CICS
IMS
Db2
VSAM
JES2
SMF
RMF
MQ
APIs
E atrás dessas tecnologias existem dados.
Muitos dados.
Transacionais.
Operacionais.
Financeiros.
Históricos.
De performance.
De segurança.
O mainframe não é apenas uma máquina executando programas COBOL.
É também uma das maiores fontes de informação empresarial de alto valor.
20. Por que um desenvolvedor COBOL deveria aprender tudo isso?
Porque o trabalho está mudando.
Não significa abandonar:
COBOL
JCL
CICS
Db2
VSAM
Significa acrescentar:
SQL avançado
Estatística
Data Analytics
Visualização
Python
IA
Um desenvolvedor tradicional pode perguntar:
“Onde esse campo é atualizado?”
Um profissional com mentalidade analítica também pergunta:
“O que podemos descobrir analisando dez anos desse campo?”
Essa segunda pergunta abre um universo novo.
21. Um laboratório Bellacosa
Quer começar sem instalar um cluster Hadoop no quintal?
Pegue um conjunto de dados simples.
Pode ser:
DATA
HORÁRIO
TRANSAÇÃO
VALOR
CPU
RESPONSE_TIME
STATUS
Passo 1 — explore
Quantos registros existem?
Quais campos?
Há valores faltantes?
Passo 2 — limpe
Remova duplicidades.
Padronize datas.
Verifique valores inválidos.
Passo 3 — calcule
Descubra:
média
mediana
mínimo
máximo
desvio
Passo 4 — procure outliers
Quais transações fogem do comportamento esperado?
Passo 5 — relacione variáveis
Por exemplo:
volume × CPU
volume × response time
CPU × response time
Passo 6 — visualize
Crie um gráfico temporal.
Passo 7 — conte a história
Não diga apenas:
“Existe um pico.”
Explique:
quando ocorreu;
qual foi sua magnitude;
quais variáveis mudaram;
quais workloads foram afetados;
qual hipótese merece investigação.
Parabéns.
Você acabou de sair de:
“olhar relatório”
para:
“fazer análise de dados”.
22. Easter egg — o Barão encontra um outlier
No final da visita, Münchhausen olha para nosso dataset.
TEMPO_RESPOSTA
0.28
0.31
0.30
0.29
0.32
47.81
0.30
Ele aponta imediatamente para 47.81.
— Conheço esse número! Foi exatamente o tempo que levei para escapar de um pântano puxando a mim mesmo pelos cabelos!
O analista consulta SMF.
O DBA consulta Db2.
O sysprog consulta RMF.
O desenvolvedor abre os logs.
Descobrem uma contenção.
O Barão parece decepcionado.
Mas acabamos de aprender uma última lição:
Um outlier começa uma investigação. Ele não termina uma investigação.
Epílogo — Não abandone o canhão; aprenda balística
Existe uma tentação recorrente na tecnologia de anunciar que cada novidade matou tudo o que existia antes.
Cloud matou mainframe.
Java matou COBOL.
NoSQL matou SQL.
Big Data matou Data Warehouse.
Machine Learning matou estatística.
IA matou programação.
Enquanto isso, no mundo real, todas essas tecnologias continuam convivendo.
O profissional valioso não é necessariamente aquele que corre atrás de cada buzzword.
É aquele que consegue entender como as peças se conectam.
Para o desenvolvedor COBOL, Data Analytics oferece justamente essa oportunidade.
Você já conhece sistemas que produzem dados críticos.
Conhece transações.
Conhece regras de negócio.
Conhece exceções.
Conhece processamento batch.
Conhece online.
Conhece bancos de dados.
Conhece o estranho campo WS-FLAG-X9 que ninguém documentou desde 1997.
Agora acrescente:
estatística.
análise.
visualização.
storytelling.
Machine Learning.
IA.
E talvez você descubra que não precisa abandonar 30 anos de experiência para entrar no futuro.
Pode fazer algo muito mais inteligente:
colocar o futuro em cima desses 30 anos.
Nossa árvore, afinal, não cresce destruindo suas raízes.
Ela cresce justamente porque possui raízes.
GenAI
▲
Machine Learning
▲
Data Science
▲
Big Data
▲
Analytics
▲
Data Warehouse / BI
▲
DSS
▲
Databases
▲
Data Analysis
▲
Pesquisa Operacional
▲
Estatística
│
│
DADOS REAIS
│
┌──────┴──────┐
COBOL CICS
│ │
Db2 IMS
│ │
VSAM MQ/API
└──────┬───────┘
│
IBM Z
O Barão de Münchhausen sobe novamente em seu cavalo.
Olha para o IBM Z.
Olha para nosso dashboard.
Olha para a IA.
E antes de cavalgar rumo ao próximo absurdo tecnológico, deixa um conselho surpreendentemente sensato:
“Meu caro programador: eu posso inventar histórias porque sou o Barão. Você, quando trabalhar com dados, precisa provar as suas.”
☕ Bellacosa Mainframe
Do cartão perfurado à Inteligência Artificial, os dados sempre tiveram uma história para contar. Nossa profissão é aprender a ouvi-la.
Sem comentários:
Enviar um comentário