 |
| Bellacosa Mainframe e o ETL Sem misterios conheca o classico versus o moderno |
☕ Um Café no Bellacosa Mainframe
ETL Clássico vs. ELT Moderno sem Mistérios
Da fita magnética ao Data Lakehouse: o guia definitivo do programador COBOL Padawan para entender como os dados aprenderam a viajar no tempo
Imagine a seguinte cena.
São duas horas da manhã em um grande centro de processamento de dados. As luzes da sala estão apagadas, mas centenas de pequenos indicadores piscam silenciosamente. No console do operador, uma fila de jobs atravessa o JES2. Um programa COBOL lê milhões de registros de um arquivo VSAM, consulta tabelas no Db2, gera um arquivo sequencial e o entrega para outro processo.
Depois, um job de transformação organiza os dados.
Outro job elimina duplicidades.
Outro converte datas.
Outro calcula totais.
Finalmente, já perto do amanhecer, as informações chegam ao Data Warehouse, prontas para alimentar os relatórios que os gestores abrirão durante o café da manhã.
Essa cena resume muito bem a era do ETL clássico.
Agora avance algumas décadas.
Os dados continuam vindo do mainframe, do ERP, do CRM, das APIs, das planilhas e de dezenas de sistemas. Porém, em vez de esperar uma longa janela batch noturna, as alterações podem ser capturadas quase em tempo real. Os dados brutos são carregados em uma plataforma de nuvem ou em um Lakehouse e somente depois são organizados, testados e modelados.
Essa segunda cena representa o ELT moderno.
À primeira vista, a diferença parece pequena. Afinal, ETL e ELT possuem as mesmas três letras:
O que muda é a ordem.
Mas, como diria o Sr. Spock ao examinar um fluxo de dados corporativo:
“Uma pequena alteração na sequência pode produzir consequências altamente ilógicas em todo o sistema.”
Trocar a posição do T e do L não é apenas reorganizar três letras. É alterar toda a filosofia da arquitetura de dados.
Prepare o café, ajuste o terminal 3270 e embarque conosco. Nesta missão, o programador COBOL Padawan descobrirá como os dados saíram dos arquivos sequenciais, atravessaram Data Warehouses gigantescos e chegaram aos modernos Data Lakes, Lakehouses, pipelines de CDC, dbt, dashboards e modelos de inteligência artificial.
1. Antes de tudo: o que é um pipeline de dados?
Um pipeline de dados é uma sequência organizada de etapas responsável por transportar informações de um lugar para outro.
Podemos compará-lo a uma linha de produção.
A matéria-prima chega, passa por máquinas, é inspecionada, transformada, embalada e enviada ao destino final.
No mundo dos dados, a matéria-prima pode ser:
O pipeline captura essas informações, movimenta os registros, corrige formatos, aplica regras de negócio e entrega os dados para relatórios, análises, auditorias ou inteligência artificial.
Um pipeline simplificado pode ser representado assim:
Sistema de origem
↓
Extração
↓
Transformação
↓
Carga
↓
Banco analítico
↓
Relatórios e dashboards
No modelo moderno, a ordem normalmente muda:
Sistema de origem
↓
Extração
↓
Carga dos dados brutos
↓
Transformação dentro da plataforma
↓
Modelos analíticos
↓
Relatórios, ciência de dados e IA
É exatamente aí que começa a diferença entre ETL e ELT.
2. O nascimento do ETL clássico
O ETL tornou-se extremamente popular durante os anos 1990 e 2000.
Naquela época, os recursos computacionais eram muito mais caros e limitados.
Armazenamento custava caro.
Memória custava caro.
Processamento custava caro.
Licenças de bancos de dados custavam caro.
Manter grandes volumes de dados sem uso aparente era visto como desperdício.
A filosofia dominante era:
“Não carregue tudo. Carregue somente o que estiver limpo, organizado e pronto para ser usado.”
Assim surgiu o processo clássico:
Extract → Transform → Load
Ou seja:
extrair os dados da origem;
transformar os dados fora do Data Warehouse;
carregar apenas os dados prontos.
Essa abordagem combinava muito bem com a cultura dos grandes ambientes corporativos, especialmente aqueles baseados em processamento batch.
3. ETL explicado para um programador COBOL iniciante
Vamos imaginar um cenário bancário.
Um programa COBOL processa diariamente um arquivo de movimentos financeiros.
O arquivo contém informações como:
NUMERO-CONTA
DATA-MOVIMENTO
TIPO-MOVIMENTO
VALOR-MOVIMENTO
CODIGO-AGENCIA
Esses dados precisam alimentar um Data Warehouse para que a área de negócios analise o total de depósitos, saques e transferências.
No ETL clássico, o fluxo seria parecido com este:
Db2 / VSAM / Arquivo
↓
Extração
↓
Área de staging
↓
Transformação
↓
Carga no Data Warehouse
Vamos analisar cada etapa.
4. Etapa 1 — Extract: extraindo os dados
A extração é o momento em que os dados são retirados do sistema de origem.
No mainframe, isso pode acontecer por meio de:
Um programa COBOL poderia, por exemplo, ler uma tabela Db2 e gravar um arquivo sequencial:
SELECT
ACCOUNT_ID,
CUSTOMER_ID,
BALANCE,
LAST_UPDATE
FROM ACCOUNT
WHERE LAST_UPDATE >= :DATA-ANTERIOR
O resultado seria gravado em um arquivo como:
HLQ.EXTRACAO.CONTAS.D20260716
Esse arquivo seria então enviado para a plataforma de ETL.
O ponto importante é que a extração não deveria aplicar regras complexas. Sua principal função seria capturar os dados da origem.
Contudo, na prática, muitos ambientes antigos misturavam extração e transformação no mesmo programa.
O COBOL lia a tabela, validava registros, convertia datas, alterava códigos e gravava o resultado final.
Funcionava, mas criava forte acoplamento.
5. Etapa 2 — Staging: a sala de espera dos dados
Depois da extração, os dados costumavam ser enviados para uma área temporária chamada staging.
Staging significa algo como área de preparação.
Pense nela como a doca de carga da USS Enterprise.
As caixas chegam de diferentes planetas, mas ainda não foram inspecionadas, classificadas ou distribuídas pelos compartimentos da nave.
A staging poderia conter tabelas como:
STG_CLIENTE
STG_CONTA
STG_MOVIMENTO
STG_AGENCIA
STG_PRODUTO
Os dados nessa área ainda poderiam apresentar:
A staging oferecia um espaço seguro para trabalhar antes de carregar o Data Warehouse oficial.
Em ambientes mainframe, o conceito de staging também podia aparecer na forma de datasets temporários:
//STAGE01 DD DSN=&&STAGING,
// DISP=(NEW,PASS),
// SPACE=(CYL,(100,50)),
// DCB=(RECFM=FB,LRECL=300)
O dataset temporário era criado, utilizado por outros steps e eliminado ao final do job.
Nada muito diferente de uma tabela temporária em um pipeline moderno.
A tecnologia muda. O princípio permanece.
6. Etapa 3 — Transform: onde as regras de negócio vivem
A transformação é o coração do ETL.
É nessa etapa que os dados brutos são convertidos em informações confiáveis.
Algumas transformações comuns incluem:
Padronização de datas
A origem pode trazer:
16/07/2026
O Data Warehouse pode exigir:
2026-07-16
Padronização de valores
Uma origem pode usar vírgula decimal:
1234,56
Outra pode usar ponto:
1234.56
O pipeline precisa escolher um padrão.
Tratamento de códigos
O sistema antigo pode armazenar:
A = Ativo
I = Inativo
B = Bloqueado
O modelo analítico pode exigir:
ATIVO
INATIVO
BLOQUEADO
Eliminação de duplicidades
Dois sistemas podem possuir registros do mesmo cliente.
O processo precisa decidir:
qual registro é o principal;
qual endereço é o mais recente;
qual telefone deve ser preservado;
como consolidar os dados.
Criação de métricas
O pipeline pode calcular:
Em um programa COBOL, uma transformação poderia parecer assim:
IF WS-TIPO-MOVIMENTO = 'C'
ADD WS-VALOR TO WS-TOTAL-CREDITOS
ELSE
IF WS-TIPO-MOVIMENTO = 'D'
ADD WS-VALOR TO WS-TOTAL-DEBITOS
END-IF
END-IF
Em uma ferramenta de ETL, a mesma lógica poderia ser implementada visualmente.
Em SQL:
CASE
WHEN TIPO_MOVIMENTO = 'C' THEN VALOR_MOVIMENTO
ELSE 0
END AS VALOR_CREDITO
A regra é a mesma.
O que muda é a linguagem e o lugar onde ela é executada.
7. Etapa 4 — Load: carregando o Data Warehouse
Depois que os dados fossem transformados, finalmente seriam carregados no Data Warehouse.
O Data Warehouse era cuidadosamente modelado antes da carga.
Frequentemente utilizava modelos dimensionais compostos por:
tabelas fato;
tabelas dimensão;
chaves substitutas;
históricos;
agregações;
hierarquias.
Uma tabela fato poderia conter:
FATO_VENDAS
Enquanto as dimensões poderiam ser:
DIM_CLIENTE
DIM_PRODUTO
DIM_LOJA
DIM_TEMPO
DIM_VENDEDOR
A tabela fato armazenava medidas:
quantidade;
valor;
desconto;
imposto;
margem.
As dimensões armazenavam contexto:
quem comprou;
o que comprou;
onde comprou;
quando comprou.
Esse modelo facilitava relatórios e análises.
Porém, exigia que a estrutura fosse definida antes da chegada dos dados.
Daí nasce a famosa lógica:
Primeiro modela. Depois carrega.
8. Por que o ETL era tão rígido?
Porque cada alteração precisava atravessar toda a cadeia.
Imagine que uma tabela de clientes receba um novo campo:
CANAL_PREFERENCIAL
Agora seria necessário alterar:
o sistema de origem;
o programa de extração;
o arquivo intermediário;
o layout;
a tabela de staging;
a transformação;
a tabela destino;
a documentação;
os relatórios;
os testes;
o processo de implantação;
os controles de reconciliação.
Para um programador COBOL, isso lembra a alteração de um copybook compartilhado por dezenas de programas.
Você muda um campo.
De repente, vinte módulos precisam ser recompilados.
Três interfaces quebram.
Um arquivo fica com LRECL incorreto.
Um job termina com S013.
Outro apresenta dados deslocados.
O operador liga às três horas da manhã.
A equipe inteira pergunta:
“Quem alterou o copybook?”
No ETL clássico, o mesmo fenômeno acontecia com pipelines de dados.
9. Ferramentas pesadas e lógica espalhada
Outro problema comum era a dispersão das regras.
Uma parte da lógica podia estar em:
um programa COBOL;
uma procedure SQL;
um job SSIS;
uma transformação PowerCenter;
um script Shell;
uma rotina Java;
um job Control-M;
uma stored procedure Oracle;
uma planilha mantida manualmente.
O resultado era uma arquitetura difícil de compreender.
Para descobrir como determinado campo era calculado, o analista precisava investigar cinco sistemas.
A regra podia começar em um programa COBOL, ser alterada em uma procedure e finalmente ser arredondada no relatório.
Era uma verdadeira investigação digna de Sherlock Holmes, Spock e do operador de produção mais experiente da empresa.
10. Então o que mudou?
Três transformações foram fundamentais.
10.1 O armazenamento ficou mais barato
Guardar grandes volumes de dados tornou-se economicamente viável.
Antes, armazenar tudo era um luxo.
Hoje, em muitas arquiteturas, preservar dados brutos é considerado uma vantagem.
10.2 O processamento tornou-se elástico
Plataformas modernas permitem aumentar ou reduzir capacidade conforme a necessidade.
Em vez de comprar uma máquina para o pico máximo, a empresa pode consumir recursos sob demanda.
10.3 O volume e a variedade dos dados explodiram
As organizações passaram a produzir:
Transformar tudo antes da carga tornou-se lento e caro.
Assim nasceu a filosofia do ELT.
11. ELT: primeiro carrega, depois transforma
O ELT segue este fluxo:
Extract → Load → Transform
Primeiro, o dado é extraído.
Depois, é carregado praticamente como veio da origem.
Somente dentro da plataforma moderna ele é transformado.
A nova filosofia pode ser resumida assim:
“Preserve os dados primeiro. Decida depois como utilizá-los.”
Em vez de obrigar o dado a se adaptar imediatamente a um modelo rígido, o ELT preserva a informação original.
Isso aumenta a flexibilidade.
12. A camada Raw ou Bronze
Em arquiteturas modernas, os dados brutos costumam ser armazenados em uma camada chamada:
Raw;
Bronze;
Landing;
Ingestion;
Source.
Essa camada preserva o dado original.
Imagine que o mainframe envie um arquivo contendo:
00012320260716125000C0000000015000
O registro pode ser armazenado exatamente como chegou.
Depois, outras camadas interpretam os campos.
Uma arquitetura em camadas pode ser:
Bronze → Silver → Gold
Bronze
Dados brutos.
Pouco ou nenhum tratamento.
Silver
Dados limpos, padronizados e reconciliados.
Gold
Dados preparados para negócio, relatórios e indicadores.
Uma analogia mainframe seria:
Arquivo de entrada
↓
Arquivo validado
↓
Arquivo consolidado
↓
Relatório final
O conceito não é totalmente novo.
A novidade está na escala, nas ferramentas e na velocidade.
13. O que é um Data Lake?
Um Data Lake é um repositório capaz de armazenar grandes volumes de dados em diversos formatos.
Ele pode guardar:
arquivos CSV;
JSON;
Parquet;
imagens;
vídeos;
logs;
arquivos de áudio;
dados estruturados;
dados semiestruturados;
dados não estruturados.
A principal vantagem é a flexibilidade.
Porém, existe um risco.
Sem organização, governança e catálogo, o Data Lake pode virar um Data Swamp, ou pântano de dados.
Os arquivos estão lá, mas ninguém sabe:
quem criou;
qual versão é válida;
o que cada coluna significa;
se os dados estão completos;
se há informações sensíveis;
quem pode utilizá-los.
Curiosidade importante: guardar tudo não significa compreender tudo.
Um Data Lake sem governança pode ser apenas um gigantesco diretório de arquivos com nomes misteriosos.
Algo como:
FINAL.CSV
FINAL2.CSV
FINAL_CORRETO.CSV
FINAL_CORRETO_AGORA_VAI.CSV
FINAL_DEFINITIVO_V7.CSV
Todo profissional de tecnologia já encontrou uma pasta assim em algum momento da vida.
14. O que é um Data Lakehouse?
O Data Lakehouse tenta unir as vantagens do Data Lake e do Data Warehouse.
Do Data Lake, ele herda:
Do Data Warehouse, ele herda:
organização;
consultas SQL;
desempenho;
governança;
controle de qualidade;
suporte a transações;
modelagem analítica.
Em termos simples:
Data Lake + Data Warehouse = Data Lakehouse
Não é uma soma perfeita, mas ajuda o COBOL Padawan a compreender o conceito.
O Lakehouse busca permitir que os mesmos dados sirvam para:
dashboards;
relatórios;
ciência de dados;
machine learning;
inteligência artificial;
auditoria;
análises exploratórias.
15. Change Data Capture: capturando apenas o que mudou
Um dos elementos mais importantes do ELT moderno é o CDC, ou Change Data Capture.
No processamento tradicional, uma tabela inteira podia ser extraída diariamente.
Imagine uma tabela com 500 milhões de registros.
Mesmo que apenas 10 mil registros tivessem mudado, o processo poderia copiar tudo novamente.
Isso consome:
CPU;
disco;
rede;
tempo;
janela batch;
paciência do operador.
O CDC captura apenas alterações:
Exemplo:
Registro 1001 foi incluído
Registro 2050 foi alterado
Registro 3100 foi excluído
Essas mudanças são enviadas para a plataforma analítica.
No ecossistema mainframe, o CDC pode observar alterações em:
Db2;
IMS;
VSAM;
logs transacionais;
filas;
streams de eventos.
Isso permite integrar sistemas centrais com plataformas modernas sem executar extrações completas o tempo todo.
16. Batch não morreu
Existe uma ideia equivocada de que arquiteturas modernas eliminaram o batch.
Não eliminaram.
O batch continua extremamente importante.
Folhas de pagamento, fechamentos contábeis, consolidações financeiras, faturamento e processamento de grandes volumes ainda utilizam jobs em lote.
O que mudou foi a coexistência entre diferentes velocidades.
Hoje, uma arquitetura pode possuir:
O mainframe também participa dessa arquitetura híbrida.
Um programa COBOL pode continuar processando arquivos à noite, enquanto alterações críticas são enviadas por CDC durante o dia.
Não é uma guerra entre antigo e moderno.
É uma federação de tecnologias.
E, como toda boa federação, cada membro possui sua função.
17. O papel do dbt na transformação moderna
O dbt, conhecido como data build tool, ajudou a transformar a maneira como as equipes escrevem SQL.
Antes, o SQL podia ficar espalhado por:
procedures;
scripts;
jobs;
ferramentas visuais;
notebooks;
arquivos locais.
O dbt trouxe práticas de engenharia de software para a transformação de dados.
Entre elas:
Um modelo dbt pode ser semelhante a:
SELECT
CUSTOMER_ID,
SUM(AMOUNT) AS TOTAL_AMOUNT
FROM {{ ref('stg_transactions') }}
GROUP BY CUSTOMER_ID
A função ref declara que esse modelo depende de outro.
Assim, a ferramenta entende a ordem de execução.
Em vez de manter uma sequência escondida em dez agendadores diferentes, o pipeline passa a possuir um grafo claro de dependências.
Para o programador COBOL, isso pode ser comparado a mapear todos os programas chamados por um módulo principal.
PGMMAIN
├── CALL PGMCLI
├── CALL PGMCON
└── CALL PGMREL
No dbt, a lógica é parecida:
RAW_CUSTOMER
↓
STG_CUSTOMER
↓
DIM_CUSTOMER
↓
REPORT_CUSTOMER
A diferença é que o grafo pode ser documentado e executado automaticamente.
18. O dbt resolve tudo?
Não.
O dbt resolve muito bem a parte de transformação SQL dentro de uma plataforma de dados.
Mas ele não é responsável por tudo.
Ele não substitui necessariamente:
É importante evitar a síndrome da ferramenta mágica.
Nenhuma ferramenta resolve sozinha arquitetura, processo, pessoas, governança e qualidade.
O dbt organiza muito bem o “T”.
Mas o restante da missão ainda precisa de uma tripulação.
19. Orquestração: o maestro do pipeline
A orquestração define:
o que executa primeiro;
o que depende de quê;
o que fazer em caso de falha;
quantas tentativas realizar;
quando disparar alertas;
quais prazos devem ser cumpridos.
No mainframe, JCL, JES2 e schedulers já exercem esse papel há décadas.
Considere:
//STEP01 EXEC PGM=EXTRATOR
//STEP02 EXEC PGM=TRANSFOR,COND=(0,NE,STEP01)
//STEP03 EXEC PGM=CARREGA,COND=(0,NE,STEP02)
O fluxo está claro:
extrair;
transformar;
carregar.
Se o STEP01 falhar, os próximos podem não executar.
Ferramentas modernas fazem algo semelhante por meio de DAGs, grafos acíclicos direcionados.
O conceito parece novo, mas o veterano do mainframe olha para ele e pensa:
“Isso é uma cadeia de jobs com um nome mais elegante.”
E ele não está totalmente errado.
20. ETL versus ELT em uma tabela prática
| Característica | ETL clássico | ELT moderno |
|---|
| Ordem | Extrai, transforma, carrega | Extrai, carrega, transforma |
| Local da transformação | Fora do destino analítico | Dentro do Warehouse ou Lakehouse |
| Dados brutos | Frequentemente descartados | Normalmente preservados |
| Modelagem | Antes da carga | Pode evoluir após a carga |
| Flexibilidade | Menor | Maior |
| Storage | Tratado como recurso caro | Geralmente mais acessível |
| Processamento | Servidor ETL dedicado | Plataforma analítica |
| Mudança de schema | Pode quebrar o pipeline | Pode ser absorvida com mais flexibilidade |
| Uso típico | DW tradicional | Cloud Warehouse e Lakehouse |
| Governança | Forte antes da carga | Deve existir em múltiplas camadas |
21. ETL ainda é útil?
Sim, e muito.
O ELT não matou o ETL.
Existem situações em que transformar antes de carregar é obrigatório.
Por exemplo:
dados pessoais que precisam ser mascarados;
informações médicas;
dados bancários;
números de documentos;
segredos comerciais;
restrições regulatórias;
limites de residência de dados;
necessidade de reduzir volumes;
destino com capacidade limitada.
Imagine um arquivo contendo CPF, salário e informações de saúde.
Carregar tudo em uma plataforma sem proteção e decidir depois o que mascarar seria perigoso.
Nesse caso, parte da transformação precisa ocorrer antes da carga.
Portanto, muitas arquiteturas modernas usam uma abordagem híbrida:
Extração
↓
Mascaramento e validação
↓
Carga na camada bruta protegida
↓
Transformações analíticas
É uma combinação de ETL e ELT.
22. O mainframe dentro da arquitetura moderna
O IBM Z não está fora dessa evolução.
Na verdade, ele frequentemente é a origem dos dados mais importantes da empresa.
Sistemas mainframe podem armazenar:
Uma arquitetura moderna pode ser:
CICS / IMS / COBOL
↓
Db2 / VSAM / IMS DB
↓
CDC / MQ / API / Arquivo
↓
Data Lakehouse
↓
dbt
↓
Modelo analítico
↓
Power BI / Tableau / Qlik
↓
IA e Machine Learning
Observe que o programa COBOL não desapareceu.
Ele continua processando a transação central.
O que mudou foi a forma de distribuir e explorar os dados produzidos por ele.
23. Exemplo completo: dados de cartão de crédito
Vamos construir um exemplo.
Um sistema COBOL processa compras de cartão.
Cada transação contém:
NUMERO-CARTAO
DATA-HORA
ESTABELECIMENTO
VALOR
PAIS
CODIGO-RESPOSTA
No ETL clássico
O COBOL gera um arquivo ao final do dia.
O arquivo é enviado ao servidor de ETL.
A ferramenta valida os registros.
Os dados são enriquecidos.
As moedas são convertidas.
Transações inválidas são separadas.
Os dados prontos são carregados no DW.
O relatório é atualizado pela manhã.
No ELT moderno
As transações são capturadas por CDC ou streaming.
Os dados brutos são carregados no Lakehouse.
Uma camada Silver padroniza moedas e datas.
Uma camada Gold calcula indicadores.
O dashboard é atualizado em intervalos menores.
Um modelo de fraude analisa padrões quase em tempo real.
O sistema COBOL continua sendo a fonte confiável.
O ELT amplia as formas de consumir seus dados.
24. Qualidade de dados continua sendo obrigatória
Um dos maiores perigos do ELT é interpretar “carregar tudo” como “aceitar qualquer coisa sem controle”.
Isso seria um erro.
Dados brutos podem ser preservados, mas precisam de:
catálogo;
segurança;
linhagem;
classificação;
testes;
monitoramento;
regras de retenção;
controle de acesso.
Testes comuns incluem:
Teste de unicidade
CUSTOMER_ID não pode se repetir.
Teste de nulidade
ACCOUNT_ID não pode ser nulo.
Teste de integridade
Todo CUSTOMER_ID de ACCOUNT deve existir em CUSTOMER.
Teste de domínio
STATUS deve ser A, I ou B.
Teste de volume
A carga diária não pode cair 90% sem gerar alerta.
Qualidade de dados não desaparece no ELT.
Ela apenas muda de lugar e se torna mais automatizada.
25. Schema-on-write e schema-on-read
Uma diferença conceitual importante é a relação entre dados e esquema.
Schema-on-write
O esquema é definido antes da gravação.
Isso é comum no Data Warehouse clássico.
Definir tabela
↓
Validar formato
↓
Carregar dados
Schema-on-read
O dado é armazenado primeiro.
O esquema é aplicado quando ele é lido.
Armazenar dado bruto
↓
Interpretar conforme a necessidade
O ETL tradicional está mais próximo do schema-on-write.
O Data Lake está mais próximo do schema-on-read.
O Lakehouse tenta equilibrar os dois.
26. Curiosidades para o COBOL Padawan
Curiosidade 1 — O batch já fazia pipelines
Muito antes de “pipeline de dados” virar expressão de moda, equipes mainframe já encadeavam jobs com JCL e schedulers.
Curiosidade 2 — Staging não é invenção recente
Datasets temporários, arquivos intermediários e tabelas de trabalho existem há décadas.
Curiosidade 3 — CDC também não nasceu ontem
A captura de alterações em logs transacionais possui uma longa história em bancos corporativos.
Curiosidade 4 — SQL virou código de engenharia
Ferramentas modernas aproximaram SQL de práticas já comuns em linguagens como COBOL, Java e Python: versionamento, testes e revisão.
Curiosidade 5 — ELT pode gerar custos enormes
Carregar tudo é fácil. Processar tudo repetidamente pode ser caro.
Uma query mal escrita em uma plataforma elástica pode escalar muito bem — inclusive a conta.
27. Dicas práticas para o programador COBOL iniciante
Dica 1 — Aprenda SQL de verdade
Entenda:
JOIN;
GROUP BY;
funções de janela;
CTE;
agregações;
tratamento de nulos;
datas;
performance.
O SQL é uma ponte entre o mainframe e a engenharia de dados moderna.
Dica 2 — Entenda arquivos
Continue dominando:
FB;
VB;
LRECL;
EBCDIC;
ASCII;
delimitadores;
copybooks;
packed decimal;
zoned decimal.
Grande parte dos problemas de integração nasce no formato dos dados.
Dica 3 — Aprenda JSON e APIs
Sistemas modernos frequentemente trocam dados em JSON.
Compreender APIs REST e z/OS Connect amplia muito o horizonte do programador COBOL.
Dica 4 — Estude Git
Versionamento não é exclusivo do código Java.
SQL, JCL, scripts, modelos dbt e documentação também devem ser versionados.
Dica 5 — Aprenda conceitos, não apenas ferramentas
Ferramentas mudam.
Os conceitos permanecem:
extração;
transformação;
carga;
dependência;
qualidade;
reconciliação;
governança;
observabilidade.
Dica 6 — Nunca ignore reconciliação
Sempre compare:
Registros extraídos
Registros transformados
Registros rejeitados
Registros carregados
A equação precisa fechar.
Extraídos = Carregados + Rejeitados
Quando não fecha, existe um fantasma no pipeline.
28. Passo a passo para compreender uma arquitetura de dados
Quando encontrar um pipeline, faça estas perguntas.
Passo 1 — Qual é a origem?
Db2?
VSAM?
IMS?
API?
Arquivo?
ERP?
Passo 2 — Como os dados são extraídos?
Batch?
CDC?
Streaming?
API?
Unload?
Passo 3 — Onde os dados brutos ficam?
Staging?
Data Lake?
Tabela temporária?
Dataset?
Passo 4 — Onde ocorre a transformação?
Programa COBOL?
Ferramenta ETL?
SQL?
dbt?
Spark?
Passo 5 — Quem orquestra?
JES2?
Control-M?
Airflow?
Scheduler de nuvem?
Passo 6 — Como a qualidade é validada?
Contagens?
Testes automáticos?
Regras de integridade?
Passo 7 — Quem consome?
Power BI?
Relatório batch?
Aplicação?
IA?
Auditoria?
Passo 8 — Como falhas são tratadas?
Restart?
Retry?
Checkpoint?
Reprocessamento?
Rollback?
Essas perguntas revelam a arquitetura real, independentemente das ferramentas utilizadas.
29. Easter egg: a diretiva secreta do ETL
Nos arquivos perdidos da Federação, existe uma suposta diretiva de engenharia de dados conhecida como Diretiva ETL-1701:
“Nenhum dado deverá entrar no computador central da nave antes de ser validado, padronizado e aprovado pelo oficial de ciência.”
Essa era a filosofia do ETL clássico.
Anos depois, durante uma missão em um quadrante desconhecido, a tripulação percebeu que descartar dados considerados inúteis poderia eliminar pistas valiosas.
Nasceu então a Diretiva ELT-1701-D:
“Preserve o dado original. A informação aparentemente irrelevante de hoje pode ser a chave lógica da missão de amanhã.”
A letra D, naturalmente, é uma homenagem à Enterprise-D.
Coincidência?
Talvez.
Mas no Bellacosa Mainframe, coincidências tecnológicas costumam esconder um dataset catalogado.
30. ETL ou ELT: qual é melhor?
A resposta lógica é:
Depende.
Use ETL quando:
dados precisam ser protegidos antes da carga;
o volume deve ser reduzido;
o destino possui limitações;
regras precisam ser aplicadas previamente;
a governança exige forte controle antecipado.
Use ELT quando:
deseja preservar dados brutos;
precisa de flexibilidade;
utiliza uma plataforma analítica poderosa;
pretende criar múltiplos modelos;
trabalha com ciência de dados e IA;
precisa reprocessar históricos.
Use uma arquitetura híbrida quando:
segurança e flexibilidade são igualmente importantes;
existem sistemas legados e modernos;
parte das regras deve ocorrer antes da carga;
outras transformações podem acontecer depois.
Na maioria das grandes empresas, essa última opção é a mais realista.
Conclusão: o T apenas mudou de cabine
A evolução do ETL para o ELT representa muito mais do que a inversão de duas letras.
O ETL nasceu em um mundo no qual armazenamento e processamento eram caros. Por isso, os dados precisavam ser limpos, filtrados e modelados antes de entrar no Data Warehouse.
O ELT ganhou força em um mundo de armazenamento abundante, plataformas elásticas, nuvem, grandes volumes, inteligência artificial e necessidades analíticas que mudam rapidamente.
No ETL, o modelo decide o que entra.
No ELT, o dado entra primeiro e o modelo pode nascer depois.
Entretanto, isso não significa que o ETL esteja ultrapassado, que o batch tenha morrido ou que o mainframe tenha ficado para trás.
Muito pelo contrário.
Os sistemas COBOL, Db2, IMS, VSAM e CICS continuam gerando os dados mais críticos de inúmeras empresas. A diferença é que agora esses dados podem viajar por CDC, APIs, MQ, arquivos e eventos até plataformas modernas, nas quais são transformados, testados, modelados e utilizados em dashboards, algoritmos e aplicações de inteligência artificial.
O programador COBOL Padawan que compreende ETL e ELT deixa de enxergar apenas o programa e começa a enxergar a jornada completa do dado.
Ele entende de onde o registro nasceu.
Como foi extraído.
Onde foi armazenado.
Que regras foram aplicadas.
Quem consumiu a informação.
E o que acontece quando alguma etapa falha.
Essa visão transforma um simples programador em um verdadeiro engenheiro de sistemas corporativos.
No fim, o “T” não desapareceu.
Ele apenas mudou de posição.
Mudou de servidor.
Mudou de ferramenta.
Mudou de cabine na Enterprise.
Mas continua sendo responsável por uma das tarefas mais importantes de toda a engenharia de dados: transformar registros isolados em informação confiável.
E, como diria o Sr. Spock diante de um pipeline perfeitamente reconciliado:
“Dados sem contexto são apenas registros. Dados transformados com lógica tornam-se conhecimento.”
Vida longa ao COBOL.
Vida longa ao SQL.
E vida longa aos pipelines que conectam o IBM Z ao futuro.
