🚀 Seu cérebro COBOL está pronto para Python? O guia que acelera a migração em horas, não anos

 

Bellacosa Mainframe apresenta Python para Engenheiros e Analistas de Mainframe

🚀 Seu cérebro COBOL está pronto para Python? O guia que acelera a migração em horas, não anos

Python tornou-se uma linguagem estratégica para engenheiros de mainframe que desejam expandir suas habilidades para automação, integração moderna, Data Engineering e Inteligência Artificial. 

Para profissionais acostumados com COBOL, JCL e DB2, Python oferece um modelo mental mais simples e produtivo, substituindo estruturas como WORKING-STORAGE por variáveis dinâmicas, PERFORM por loops e FILE SECTION por manipulação direta de arquivos. 

Com bibliotecas poderosas e sintaxe clara, é possível automatizar rotinas operacionais, processar logs, integrar sistemas legados a APIs REST, consumir serviços web e construir pipelines de dados com muito menos código. 

Python também facilita DevOps, testes de batch, RPA corporativo e modernização de aplicações críticas. Seu uso crescente em nuvem, analytics e machine learning torna essa linguagem uma ponte natural entre o ambiente z/OS e o ecossistema digital atual. 

Aprender Python é, portanto, um passo essencial para mainframe engineers que desejam permanecer relevantes na transformação tecnológica.

🐍🔥 Cheatsheet Python para Mainframe Engineers

🧠 Mental Model — COBOL → Python

Conceito Mainframe	Equivalente Python
Program	Script / Module
WORKING-STORAGE	Variáveis
PIC clauses	Tipagem dinâmica
PERFORM UNTIL	while
PERFORM VARYING	for
COPYBOOK	Module / Class
FILE SECTION	File handling
DB2 cursor	Iteração
JCL orchestration	Scripts + Scheduler

---

📦 Variáveis (sem DATA DIVISION 😎)

COBOL

01 WS-NUM PIC 9(4) VALUE 100.

Python

ws_num = 100

✔ Sem declaração
✔ Sem tamanho fixo
✔ Tipagem dinâmica

---

📚 Estruturas de Dados — “Working Storage Turbo”

🔹 List → Tabelas OCCURS

clientes = ["Ana", "João", "Maria"]
clientes.append("Carlos")

👉 Similar a:

OCCURS n TIMES

---

🔹 Dictionary → Registro com campos nomeados

cliente = {
    "nome": "Ana",
    "saldo": 1500
}

👉 Mistura de:

✔ Registro
✔ Índice por chave
✔ Estrutura dinâmica

---

🔹 Tuple → Registro imutável

coordenada = (10, 20)

👉 Ideal quando dados não devem mudar.

---

🔹 Set → Lista sem duplicatas

codigos = {101, 102, 102, 103}

Resultado:

{101, 102, 103}

👉 Excelente para deduplicação de dados.

---

🔎 Indexação

nome = "BELLACOSA"

nome[0]   # B
nome[-1]  # A

👉 Python começa em ZERO (como C, não como COBOL).

---

⚖️ Condições (IF sem THEN/END-IF)

saldo = 100

if saldo > 0:
    print("Positivo")
else:
    print("Negativo")

---

🔁 Loops

🔹 For (PERFORM VARYING)

for i in range(5):
    print(i)

---

🔹 For em coleção

for cliente in clientes:
    print(cliente)

👉 Cursor implícito.

---

🔹 Enumerate (índice + valor)

for i, nome in enumerate(clientes):
    print(i, nome)

---

🔹 While (PERFORM UNTIL)

x = 0

while x < 5:
    print(x)
    x += 1

---

🧩 Funções (Subprogramas leves)

def calcular_taxa(valor):
    return valor * 0.05

Chamada:

taxa = calcular_taxa(1000)

---

📏 Built-ins que substituem muito código COBOL

len(lista)        # tamanho
sum(lista)        # soma
max(lista)
min(lista)
sorted(lista)

---

⚠️ Tratamento de Erros (sem Abend 😎)

COBOL

ON EXCEPTION

Python

try:
    x = int("abc")
except ValueError:
    print("Erro de conversão")

---

📂 Arquivos (QSAM moderno)

Leitura

with open("dados.txt", "r") as f:
    for linha in f:
        print(linha)

---

Escrita

with open("saida.txt", "w") as f:
    f.write("Hello Mainframe")

👉 with garante fechamento automático.

---

🧱 Classes (Estruturas + Comportamento)

class Conta:
    def __init__(self, saldo):
        self.saldo = saldo

    def depositar(self, valor):
        self.saldo += valor

Uso:

c = Conta(1000)
c.depositar(500)

---

🔍 Tipos e Debug

type(x)

---

🚀 Automação — O Superpoder

Executar comandos do sistema

import os

os.system("dir")

---

Processar arquivos em lote

import glob

for arquivo in glob.glob("*.txt"):
    print(arquivo)

---

🌐 Integração moderna

Consumir API

import requests

r = requests.get("https://api.github.com")
print(r.status_code)

👉 Equivalente moderno de MQ + Web Services.

---

🧠 Padrões mentais úteis

Python é:

✔ Scriptável
✔ Interativo
✔ Orientado a objetos
✔ Ideal para automação
✔ Excelente para integração

---

💥 Onde Python brilha para Mainframe Engineers

🔥 Automação operacional
🔥 DevOps e pipelines
🔥 Testes de batch
🔥 Processamento de logs
🔥 APIs REST para legado
🔥 Data Engineering
🔥 Machine Learning
🔥 RPA e scripting corporativo

---

☕ Frase estilo War Room

👉 COBOL mantém o mundo funcionando.
Python automatiza o mundo que muda.

 

Bellacosa Mainframe uma visão para padawans do VSAM

💥 VSAM: O “Banco de Dados Gratuito” do z/OS — Muito Mais do Que Você Imagina

🧠 Explicação Enriquecida para Padawns

📌 O que é VSAM?

Tradução:
VSAM significa Virtual Storage Access Method. O termo “Access Method” surgiu lá nos anos 60 com o OS/360 e basicamente define como os dados são acessados (disco, fita, etc.).

Comentário Bellacosa:
👉 “Access Method” é o motor invisível do I/O no mainframe.
👉 VSAM é otimizado para disco — esqueça fita aqui (só backup/export).

---

📌 Tipos principais: ESDS vs KSDS

Tradução:

• ESDS (Entry Sequenced Data Set)
  • Acesso via RBA (Relative Byte Address)
• KSDS (Key Sequenced Data Set)
  • Acesso via chave ou RBA
  • Possui índice

Comentário prático:

Tipo	Quando usar	Mentalidade
ESDS	Log, append-only, histórico	“grava e nunca mexe”
KSDS	CRUD clássico	“mini banco de dados”

💡 Insight importante:
KSDS = VSAM mais próximo de banco relacional
ESDS = VSAM mais próximo de log estruturado

---

📌 Alternate Index (AIX)

Tradução:
Você pode criar índices alternativos (AIX) para acessar registros por outras chaves.

Comentário:
👉 Isso é o equivalente a índices secundários no DB2
👉 Mas aqui você controla tudo manualmente

💣 E aqui nasce a dor:

• consistência
• manutenção
• performance

---

📌 Cluster, Componentes e Sphere

Tradução:

• ESDS → Data component
• KSDS → Data + Index component
• Conjunto com AIX → chamado de Sphere

Comentário:
👉 “Sphere” é basicamente o ecossistema do dataset VSAM
👉 Em produção, isso vira uma mini arquitetura de dados

---

🚀 VSAM na Vida Real

Tradução:
VSAM continua sendo amplamente usado porque é:

• rápido
• escalável
• já vem com z/OS
• não exige banco adicional

Comentário forte:
💣 VSAM é o NoSQL original do mainframe
Antes de MongoDB existir, o z/OS já fazia isso há décadas

---

🔥 Caso real: Criando um Key/Value Store com VSAM

O autor implementa um banco estilo NoSQL key/value.

---

📌 Requisitos do sistema

Tradução + Expansão:

• Fácil inserir/recuperar chave
• Persistente (VSAM)
• Rápido
• Sem limite de tamanho
• Permite agrupamento de chaves

Comentário:
👉 Isso é literalmente um Redis raiz no mainframe

---

🧪 Exemplo prático

Xsysvar 'MDLB URL'='https://MakingDevelopersLivesBetter.wordpress.com'
Xsysvar 'MDLB URL'

Saída:

https://MakingDevelopersLivesBetter.wordpress.com

💡 Tradução mental:
👉 SET / GET de um banco NoSQL
👉 Só que rodando em USS + VSAM

---

📦 Agrupamento de dados

Xsysvar -PZOS -C'z/OS CSI' CSI=MVS.GLOBAL.CSI 
Xsysvar -l CSI

Saída:

ZOS CSI MVS.GLOBAL.CSI z/OS CSI

Comentário:
👉 Aqui entra conceito de namespace / grouping
👉 Muito parecido com:

• tags
• collections
• schemas

---

🧠 Design inteligente do VSAM

📌 Problema: chave não pode ser longa

VSAM exige:

• chave fixa
• tamanho definido

---

💡 Solução genial

O autor divide a chave em:

Parte	Tipo
fixa	até 15 bytes
variável	até 32K

---

Comentário avançado:
👉 Isso resolve:

• limitação do VSAM
• performance de indexação
• flexibilidade

💣 Isso é arquitetura de baixo nível de respeito.

---

🧬 Layout do registro VSAM

Estrutura:

Campo	Função
I	flag ativo/inativo
P	product-id
K	chave
V	valor
offsets	ponteiros
T	área variável
F-I	filtros

---

🔥 Insight poderoso

👉 VSAM aqui está sendo usado como:

• banco
• indexador
• storage engine

👉 Tudo manual

💣 Isso é o que bancos modernos fazem internamente!

---

⚠️ Limitação crítica do ESDS

Problema:

• não permite aumentar tamanho do registro

Solução usada:

• marca registro antigo como inativo
• cria novo registro

---

💥 Tradução prática

👉 Isso é um UPDATE = DELETE + INSERT

Exatamente como:

• Kafka log
• bancos append-only

---

🧑‍💻 Acesso via C no z/OS

Funções usadas:

• fopen()
• fread()
• fwrite()
• flocate()
• fupdate()

---

📌 Exemplo lógico

flocate(file, key);
fread(...);
fupdate(...);

---

💡 Comentário

👉 Isso é praticamente uma API de banco
👉 Só que nível kernel/mainframe

---

🔍 Função mais importante: vsamxlocate

O que faz:

• busca chave
• aplica filtros
• percorre registros

---

💥 Tradução moderna

👉 Isso é um:

• SELECT com WHERE
• • scan manual

---

🚀 Criação do VSAM (automação)

Comando:

crtvsam cluster repro key

---

💡 Comentário

👉 Isso substitui:

• JCL complexo
• IDCAMS manual

👉 Usando Z Open Automation Utilities

---

🔥 Conclusão (estilo Bellacosa)

👉 VSAM não é “arquivo”
👉 VSAM é um engine de dados low-level

💣 Você pode construir:

• banco NoSQL
• cache distribuído
• config store
• sistema transacional

---

🧠 Sacadas de Ouro

• VSAM = NoSQL antes do NoSQL
• ESDS = log append-only
• KSDS = índice + acesso direto
• AIX = índices secundários
• UPDATE = recriação de registro
• Performance vem do design da chave

---

🚀 Expansão além do texto (o pulo do gato)

💣 Se você quiser levar isso pro próximo nível:

Você pode:

1. Criar um Redis-like no z/OS

• VSAM + C + USS

2. Criar API REST

• z/OS Connect
• consumindo VSAM

3. Integrar com COBOL

READ VSAM-FILE
   KEY IS WS-KEY

---

🔥 Pergunta provocativa pra você

👉 E se você substituísse config files, tabelas pequenas e até alguns DB2 por VSAM bem modelado?

💣 Você reduziria:

• custo
• latência
• dependência

 

Bellacosa Mainframe e os daods e seus repositorios

☕ Um Café no Bellacosa Mainframe

🧙‍♂️ SHIROE E A DUNGEON DOS DADOS — QUANDO O COBOL DESCOBRIU QUE DATA LAKE NÃO ERA UM LAGO, DATA MART NÃO ERA SUPERMERCADO E O WAREHOUSE NÃO TINHA EMPILHADEIRA

Data Warehouse, Data Lake, Data Mart, Lakehouse, ETL, ELT, Schema-on-Write, Schema-on-Read, Star Schema, governança, CICS, Db2, IMS, VSAM, MQ, SMF — e o dia em que Shiroe percebeu que armazenar 8 petabytes de dados não significava absolutamente nada se ninguém soubesse onde estava o cadastro correto do cliente.

---

🎬 PRÓLOGO — BEM-VINDO A ELDER TALE, PROGRAMADOR COBOL

O jovem programador COBOL acordou assustado.

Olhou em volta.

Não havia ISPF.

Não havia SDSF.

Não havia nem aquela reconfortante tela preta com letras verdes capaz de avisar:

READY

Em seu lugar havia uma enorme cidade medieval.

Guerreiros caminhavam pelas ruas. Magos discutiam estratégias. Mercadores anunciavam poções. Aventureiros corriam atrás de monstros.

— Onde estou?

Uma voz respondeu atrás dele:

— Akiba.

Ele se virou.

Óculos redondos. Capa. Cajado. Expressão de quem provavelmente havia acabado de analisar quinze diagramas de arquitetura antes do café da manhã.

Era Shiroe, de Log Horizon.

— Você é um aventureiro?

— Programador COBOL.

Shiroe ajeitou os óculos.

— Quase a mesma coisa.

— Preciso voltar ao mainframe.

— Primeiro você precisa compreender uma dungeon.

— Qual?

Shiroe apontou para três enormes construções no horizonte.

Na primeira estava escrito:

DATA WAREHOUSE

Na segunda:

DATA LAKE

E na terceira:

DATA MART

Mais distante havia uma quarta construção misteriosa:

LAKEHOUSE

O programador respirou fundo.

— Posso dar CANCEL?

— Não.

— ROLLBACK?

— Também não.

— Então ferrou.

Shiroe sorriu.

— Agora você está aprendendo Data Engineering.

---

🏰 CAPÍTULO 1 — TRÊS CONSTRUÇÕES, TRÊS MISSÕES DIFERENTES

Existe uma simplificação excelente para começar:

WAREHOUSE = dados confiáveis para a empresa

LAKE      = dados diversos e flexíveis em escala

MART      = dados preparados para uma área específica

O erro começa quando interpretamos isso como:

"Preciso escolher apenas um deles."

Não necessariamente.

Data Warehouse, Data Lake e Data Mart não são três produtos disputando uma vaga.

Eles representam padrões arquiteturais com objetivos diferentes e podem coexistir.

Uma empresa pode possuir simultaneamente:

Sistemas Operacionais
        |
        v
    Data Lake
        |
        v
 Data Warehouse
        |
   +----+----+
   |    |    |
   v    v    v
 Mart  Mart  Mart

E arquiteturas mais recentes podem substituir ou reorganizar partes desse desenho com Lakehouse, streaming, produtos de dados e outras abordagens.

Shiroe escreveria no quadro:

"Não comece escolhendo a tecnologia. Comece descobrindo o problema."

É uma excelente regra de arquitetura.

---

🏭 CAPÍTULO 2 — DATA WAREHOUSE: O GRANDE ARMAZÉM DA GUILDA

A tradução literal de warehouse é armazém.

Mas não imagine um galpão onde alguém joga caixas pela janela.

Um bom armazém possui:

• organização;

• classificação;

• endereçamento;

• controle;

• inventário;

• procedimentos;

• segurança;

• rastreabilidade.

Um Data Warehouse segue filosofia semelhante.

Ele procura disponibilizar dados preparados para análise empresarial.

Imagine uma corporação contendo:

ERP
CRM
Folha de pagamento
E-commerce
Mainframe
Aplicativos
Sistemas financeiros
Logística

Cada sistema pode representar uma entidade de maneira diferente.

Um sistema registra:

CLIENTE = 00012345

Outro:

CUSTOMER_ID = 12345

Outro trabalha principalmente com:

CPF = 123.456.789-00

O Data Warehouse não deveria simplesmente copiar tudo e desejar boa sorte ao analista.

Existe um trabalho de integração, transformação, padronização e governança.

Um fluxo tradicional poderia ser:

FONTES
  |
  v
EXTRAÇÃO
  |
  v
TRANSFORMAÇÃO
  |
  v
VALIDAÇÃO
  |
  v
DATA WAREHOUSE
  |
  +------> BI
  +------> Dashboards
  +------> KPIs
  +------> Relatórios
  +------> Analytics

Essa organização permite responder perguntas corporativas.

---

⚔️ CAPÍTULO 3 — OLTP NÃO É ANALYTICS

Nosso programador COBOL pergunta:

— Mas se os dados já estão no Db2, para que copiar?

Shiroe desenha duas missões.

Primeira:

Qual é o saldo da conta 12345?

Segunda:

Qual foi a evolução do comportamento
de compra dos clientes paulistas
nos últimos cinco anos,
separada por faixa etária,
canal, produto e mês?

São problemas diferentes.

O primeiro pertence tipicamente ao universo OLTP — Online Transaction Processing.

Precisamos processar rapidamente operações individuais.

No mainframe poderíamos ter:

Cliente
   |
   v
API
   |
   v
CICS
   |
   v
COBOL
   |
   v
Db2

Uma transação chega, é processada e recebe resposta.

Já a segunda pergunta pode envolver milhões ou bilhões de registros, agregações, cruzamentos e histórico.

Não queremos transformar cada consulta de BI numa invasão bárbara ao sistema transacional.

É uma separação importantíssima:

OPERACIONAL
"O que está acontecendo?"

ANALÍTICO
"O que aconteceu e o que podemos aprender?"

---

📜 CAPÍTULO 4 — SCHEMA-ON-WRITE: PREENCHA A FICHA ANTES DE ENTRAR NA GUILDA

Uma característica historicamente associada aos Data Warehouses é Schema-on-Write.

Antes de armazenar o dado na estrutura analítica definitiva, sabemos como queremos representá-lo.

Imagine:

CREATE TABLE VENDAS (
    ID_VENDA       BIGINT,
    ID_CLIENTE     BIGINT,
    DATA_VENDA     DATE,
    VALOR          DECIMAL(15,2),
    ID_PRODUTO     INTEGER
);

Chega um evento:

{
  "cliente": 12345,
  "produto": 991,
  "valor": 199.90
}

Precisamos interpretar e transformar aquilo para a estrutura desejada.

Há disciplina.

E disciplina tem custo.

Precisamos definir:

tipos
chaves
regras
relacionamentos
qualidade
significado

Mas recebemos algo importantíssimo em troca:

confiança.

Quando duas áreas perguntam quanto a companhia faturou em agosto, o ideal não é receber:

Financeiro: R$ 97 milhões
Vendas:     R$ 103 milhões
Marketing:  R$ 112 milhões
Igor:       depende

🤣

Se cada área possui sua própria definição de "faturamento", temos um problema semântico, não simplesmente tecnológico.

---

🌊 CAPÍTULO 5 — DATA LAKE: SHIROE MANDA GUARDAR O LOOT

Agora imagine outra necessidade.

Temos:

CSV
JSON
XML
Parquet
logs
documentos
imagens
eventos
telemetria
streams
dados de IoT

Nem sempre sabemos antecipadamente todas as análises que faremos.

Entra o Data Lake.

A filosofia é muito mais flexível.

        FONTES
          |
 +--------+--------+
 |        |        |
JSON     CSV      LOG
 |        |        |
 +--------+--------+
          |
          v
      DATA LAKE

O Lake pode armazenar enormes quantidades de dados estruturados, semiestruturados e não estruturados.

Isso o torna muito atraente para:

Data Science
Machine Learning
Big Data
Experimentação
Streaming
Exploração
Histórico massivo

Mas existe uma diferença importante.

O Lake não deve ser confundido com:

"HD gigantesco onde jogamos qualquer coisa."

Esse caminho leva diretamente para outra criatura.

---

🐊 CAPÍTULO 6 — O DATA SWAMP: O BOSS QUE NINGUÉM QUER ENFRENTAR

Shiroe leva o programador até uma região pantanosa.

Existem oito petabytes de dados.

— Impressionante! — diz o COBOLzeiro.

— Encontre o cadastro correto dos clientes.

Silêncio.

— Qual diretório?

— Ninguém sabe.

— Quem criou os arquivos?

— Não sabemos.

— Quando?

— Também não.

— Qual é o formato?

— Depende.

— São dados de produção?

— Talvez.

— Posso confiar?

— Boa pergunta.

Parabéns.

Seu Data Lake evoluiu para:

DATA SWAMP.

Um pântano de dados.

Esse é um dos maiores riscos de uma arquitetura de Lake mal governada.

Guardar é fácil.

Descobrir, compreender, proteger e confiar é difícil.

Por isso entram conceitos como:

Metadata
Data Catalog
Data Lineage
Data Quality
IAM
Classificação
Criptografia
Retenção
Auditoria
Governança

Um Lake sem metadados pode ser como encontrar um dataset chamado:

CLIENTES_FINAL_V3_NOVO_FINAL2_OK.csv

e descobrir que existem outros 83 arquivos parecidos.

Qual é o correto?

Bem-vindo à dungeon.

---

🔮 CAPÍTULO 7 — SCHEMA-ON-READ: PRIMEIRO GUARDE, DEPOIS INTERPRETE

Data Lakes são tradicionalmente associados ao conceito de Schema-on-Read.

Simplificando:

No Warehouse:

definimos estrutura
        |
        v
carregamos os dados

No Lake:

armazenamos os dados
        |
        v
interpretamos conforme consumo

Imagine bilhões de eventos:

{
  "timestamp": "2026-09-22T03:17:00",
  "transaction": "ABC991",
  "response_time": 824,
  "region": "SP"
}

Um cientista de dados talvez queira:

timestamp
response_time
region

Um engenheiro de segurança pode querer outros atributos.

A flexibilidade é enorme.

Mas não transforme a distinção entre Schema-on-Write e Schema-on-Read numa religião.

Plataformas modernas misturam estratégias.

Arquitetura de dados evoluiu.

---

🛒 CAPÍTULO 8 — DATA MART: A LOJA ESPECIALIZADA DE AKIBA

Imagine agora que o Data Warehouse possui informações de:

RH
Financeiro
Marketing
Vendas
Logística
Clientes
Produtos
Fraudes
Fornecedores

A equipe de Marketing precisa realmente navegar por tudo?

Provavelmente não.

Criamos então uma visão especializada.

             DATA WAREHOUSE
                   |
       +-----------+-----------+
       |           |           |
       v           v           v
     MART        MART        MART
   FINANCEIRO    VENDAS     MARKETING

O Data Mart entrega dados preparados para determinado domínio, departamento ou caso de uso.

O Mart de Marketing poderia conter:

Cliente
Campanha
Canal
Segmentação
Conversão
Lifetime Value

O Financeiro:

Receita
Despesa
Margem
Impostos
Fluxo de Caixa

E Vendas:

Produto
Vendedor
Região
Meta
Receita
Comissão

Isso reduz a complexidade para o usuário.

---

⭐ CAPÍTULO 9 — O STAR SCHEMA E A PARTY DE CINCO PERSONAGENS

Shiroe desenha uma estrela.

No centro:

               DIM_CLIENTE
                    |
                    |
DIM_PRODUTO --- FATO_VENDA --- DIM_TEMPO
                    |
                    |
                 DIM_LOJA

Temos um Star Schema.

No centro fica normalmente a tabela fato, contendo eventos e medidas.

Por exemplo:

FATO_VENDA

ID_CLIENTE
ID_PRODUTO
ID_TEMPO
ID_LOJA
QUANTIDADE
VALOR
DESCONTO
CUSTO

Ao redor ficam dimensões.

Elas respondem perguntas como:

Quem?
O quê?
Quando?
Onde?
Como?

Assim conseguimos perguntar:

Quanto vendemos do produto X no interior de São Paulo em agosto?

A tabela fato fornece as medidas.

As dimensões fornecem contexto.

É uma ideia extremamente poderosa para BI.

---

🔄 CAPÍTULO 10 — ETL vs ELT: A ORDEM DOS FEITIÇOS IMPORTA

Outro conceito que o jovem COBOLzeiro precisa dominar:

ETL

EXTRACT
   |
   v
TRANSFORM
   |
   v
LOAD

Primeiro extraímos.

Depois transformamos.

Finalmente carregamos no destino.

Mas existe:

ELT

EXTRACT
   |
   v
LOAD
   |
   v
TRANSFORM

Primeiro extraímos e carregamos.

Depois usamos a capacidade da plataforma para realizar transformações.

Portanto:

Warehouse = ETL

não é uma regra universal.

Ambientes modernos utilizam muito ELT.

E frequentemente encontramos combinações.

Shiroe diria:

"A sequência depende da estratégia da raid."

---

🏠 CAPÍTULO 11 — SURGE O LAKEHOUSE

Nos limites de Akiba existe a quarta construção.

Lakehouse.

A ideia tenta combinar características historicamente associadas aos dois mundos.

Do Lake:

escala
flexibilidade
múltiplos formatos
armazenamento econômico

Do Warehouse:

governança
SQL
estrutura
qualidade
BI
gerenciamento de tabelas

Em forma de feitiço:

DATA LAKE
    +
capacidades de DATA WAREHOUSE
    =
LAKEHOUSE

Isso tornou a velha discussão:

"Lake ou Warehouse?"

muito menos binária.

As fronteiras ficaram borradas.

E continuam evoluindo.

---

🖥️ CAPÍTULO 12 — SHIROE ENCONTRA UM IBM Z NO MEIO DA DUNGEON

Agora chegamos à parte divertida.

No subsolo de Akiba existe uma máquina.

Na placa:

IBM Z

Shiroe encontra:

COBOL
CICS
IMS
Db2
VSAM
MQ
JES

O programador pergunta:

— Precisamos transformar o mainframe num Data Lake?

— Não!

Eis um ponto fundamental.

O IBM Z pode continuar desempenhando brilhantemente sua função de System of Record e plataforma transacional.

Imagine:

              IBM Z
                |
      +---------+---------+
      |         |         |
     Db2       IMS       VSAM
      |         |         |
      +---------+---------+
                |
        CDC / ETL / APIs
         MQ / Streaming
                |
                v
        Plataforma de Dados

CDC significa Change Data Capture.

Em vez de executar cargas gigantescas indiscriminadamente, podemos capturar mudanças relevantes e propagá-las para outros ambientes.

Também podemos utilizar:

MQ
APIs
Batch
Streaming
ETL/ELT

dependendo do caso.

---

💳 CAPÍTULO 13 — A COMPRA DE R$ 3.499

Imagine uma compra.

Valor: R$ 3.499
Horário: 03:17
Local: São Paulo
Canal: Internet

No sistema transacional, queremos algo como:

TRANSACTION_ID
ACCOUNT
VALUE
STATUS

Precisamos autorizar ou recusar rapidamente.

Mas no Warehouse aquela mesma realidade pode virar:

FATO_VENDA
DIM_CLIENTE
DIM_TEMPO
DIM_CANAL
DIM_PRODUTO

No Lake podemos preservar:

evento JSON
logs
clickstream
telemetria
informações antifraude

E no Data Mart de fraude:

cliente
valor
device
localização
risco
score

Veja a mágica.

Não estamos falando necessariamente de quatro eventos diferentes.

Estamos falando de diferentes representações e usos dos dados relacionados ao mesmo evento de negócio.

---

🔐 CAPÍTULO 14 — RAW NÃO SIGNIFICA "PODE TUDO"

Um aventureiro aparece correndo.

— Shiroe! Criei nosso Lake!

— Excelente.

— Coloquei CPF, cartões, tokens, credenciais, documentos e tudo mais!

Shiroe congela.

🤣

Dados brutos não significam dados sem controle.

Um Data Lake corporativo continua precisando de:

IAM
RBAC/ABAC
Encryption
Masking
Tokenization
Auditing
Retention
Classification
Lineage
LGPD

A flexibilidade aumenta a importância da governança.

Se você centraliza enormes quantidades de informação sensível, está também criando um ativo extremamente interessante para um atacante.

---

🧭 CAPÍTULO 15 — PASSO A PASSO PARA NÃO CONSTRUIR A ARQUITETURA AO CONTRÁRIO

Antes de escolher tecnologia, faça perguntas.

Passo 1 — Identifique as fontes

Db2?
IMS?
VSAM?
Oracle?
SAP?
APIs?
Kafka?
Arquivos?
Logs?

Passo 2 — Descubra os consumidores

Quem utilizará?

Executivos?
BI?
Data Scientists?
Marketing?
Financeiro?
Fraude?
IA?

Passo 3 — Descubra a latência necessária

O dado precisa chegar:

em 20 ms?
em 1 segundo?
em 5 minutos?
uma vez por hora?
durante o batch noturno?

Isso muda completamente a arquitetura.

Passo 4 — Determine qualidade e governança

Pergunte:

Quem é o dono?
Qual é a fonte oficial?
Quem pode acessar?
Quanto tempo guardar?
É informação pessoal?
Pode sair do mainframe?

Passo 5 — Escolha o padrão apropriado

Precisa de analytics corporativo confiável?

Warehouse pode fazer sentido.

Precisa preservar enormes volumes heterogêneos para exploração?

Lake pode fazer sentido.

Uma área específica precisa de dados curados?

Mart pode fazer sentido.

Precisa combinar capacidades?

Lakehouse pode entrar na conversa.

---

🥚 EASTER EGG — 03:17 E O INCIDENTE DO DATA LAKE

Às exatamente:

03:17:00

um alerta dispara.

JOB DLK0317 ABEND

O operador chama Shiroe.

— Perdemos o Data Lake!

Shiroe pergunta:

— Backup?

— Temos.

— Catálogo?

— Não.

— Lineage?

— Não.

— Metadata?

— Não.

— Documentação?

— O Igor estava fazendo.

Shiroe tira os óculos.

Silêncio.

O programador COBOL sussurra:

— Então não perdemos o Lake.

Shiroe olha para ele.

— Exatamente.

— Perdemos o mapa.

E essa talvez seja a melhor lição deste artigo.

---

🗺️ CAPÍTULO 16 — DATA LINEAGE: O MAPA DA DUNGEON

Data Lineage responde:

De onde veio este dado e o que aconteceu com ele?

Imagine:

VSAM CLIENTES
      |
      v
    CDC
      |
      v
RAW CUSTOMER
      |
      v
TRANSFORMAÇÃO
      |
      v
CURATED CUSTOMER
      |
      v
DATA MART
      |
      v
DASHBOARD CFO

Se o CFO encontra um número estranho no dashboard, precisamos conseguir voltar pela trilha.

Dashboard
   ^
   |
Mart
   ^
   |
Transformação
   ^
   |
Origem

Para um veterano de mainframe, essa filosofia deveria soar familiar.

Rastreabilidade sempre foi assunto sério em ambientes críticos.

---

🧠 CAPÍTULO 17 — A PERGUNTA QUE VALE MAIS QUE PETABYTES

No final da aventura, Shiroe coloca quatro placas sobre a mesa:

DATA LAKE
DATA WAREHOUSE
DATA MART
LAKEHOUSE

E pergunta:

— Qual é a melhor?

O jovem programador já aprendeu a armadilha.

— Depende do problema.

Shiroe sorri.

Exatamente.

Porque a pergunta madura não é:

"Onde vamos guardar os dados?"

É:

"Qual jornada esse dado precisa percorrer desde sua origem até produzir uma decisão?"

Podemos desenhar:

         SISTEMA OPERACIONAL
                |
                v
       CAPTURA / INTEGRAÇÃO
                |
       +--------+--------+
       |                 |
       v                 v
   DATA LAKE        DATA WAREHOUSE
       |                 |
       +--------+--------+
                |
                v
          CAMADA CURADA
                |
       +--------+--------+
       |        |        |
       v        v        v
      MART     MART     MART
       |        |        |
       +--------+--------+
                |
                v
          BI / ML / IA

Ou arquiteturas diferentes podem ser mais apropriadas.

A tecnologia muda.

A pergunta permanece.

---

🎓 EPÍLOGO — SHIROE ENTREGA O CAJADO AO PROGRAMADOR COBOL

Ao final da dungeon, nosso aventureiro finalmente encontra o terminal.

Na tela:

READY

Ele sorri.

Agora compreende que COBOL, CICS, Db2, IMS e VSAM não estão isolados do mundo moderno dos dados.

Muito pelo contrário.

Imagine o fluxo:

COBOL
  |
CICS
  |
Db2 / IMS / VSAM
  |
CDC / MQ / APIs / Batch / Streaming
  |
  v
PLATAFORMA DE DADOS
  |
  +----> Lake
  |
  +----> Warehouse
  |
  +----> Lakehouse
  |
  +----> Marts
  |
  v
BI / Analytics / ML / IA

O programa COBOL que processa uma transação às 03:17 pode estar produzindo o evento que amanhã será usado por um dashboard, um modelo antifraude ou um algoritmo de Machine Learning.

É a mesma empresa.

É o mesmo negócio.

São diferentes etapas da vida do dado.

E existe algo ainda mais importante.

Um Data Warehouse de última geração com dados ruins continua produzindo respostas ruins.

Um Data Lake de 50 petabytes sem catálogo continua sendo um pântano de 50 petabytes.

Um Data Mart rápido com definições incorretas continuará entregando rapidamente a resposta errada.

E colocar IA sobre tudo isso não resolve magicamente o problema.

Só permite errar em uma velocidade extraordinária.

Shiroe ajeita novamente os óculos:

Dados precisam de estratégia antes de precisarem de tecnologia.

O programador COBOL finalmente digita:

LOGOFF

Antes de desaparecer de Elder Tale, olha uma última vez para o mapa:

       TRANSAÇÃO
           |
           v
          DADO
           |
           v
       CONTEXTO
           |
           v
      INFORMAÇÃO
           |
           v
      CONHECIMENTO
           |
           v
        DECISÃO

Agora ele entende.

O Data Lake preserva.

O Data Warehouse organiza, integra e prepara para confiança analítica.

O Data Mart aproxima o dado de um domínio ou grupo de consumidores.

O Lakehouse procura combinar características antes separadas.

ETL e ELT determinam diferentes estratégias para movimentação e transformação.

Schema-on-Write e Schema-on-Read representam filosofias distintas de estruturação.

Star Schema ajuda a transformar eventos em perguntas de negócio.

Catálogo diz o que existe.

Lineage conta de onde veio.

Governança determina como aquilo pode ser utilizado.

E o mainframe?

O mainframe continua lá.

Processando milhões de transações enquanto todo mundo discute nomes novos para problemas que ele conhece há décadas.

Na saída da dungeon existe uma pequena inscrição.

Quase ninguém percebe.

O programador aproxima a lanterna e lê:

//SHIROE  JOB ...

//* --------------------------------------------
//* TODO DADO TEM UMA ORIGEM.
//* TODO NUMERO PRECISA DE CONTEXTO.
//* TODO DASHBOARD PRECISA DE CONFIANCA.
//*
//* E TODO PROGRAMADOR QUE ENCONTRAR
//* CLIENTES_FINAL_V7_FINAL_OK_AGORA_VAI.CSV
//* DEVE ABRIR UM INCIDENTE IMEDIATAMENTE.
//*
//* 03:17
//* --------------------------------------------

Ele ri.

Em algum lugar de Akiba, Shiroe também.

Fim da raid.

☕ Bellacosa Mainframe — porque modernizar não significa abandonar aquilo que funciona; significa compreender onde cada peça da arquitetura pertence.