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.

Translate

segunda-feira, 5 de outubro de 2020