O time de negócio pede um relatório diário de transações e propõe rodar a consulta direto no banco do core bancário, fora do horário de pico. O que você responde?

Eu não faria, e a razão principal não é velocidade, é risco de contenção. Uma consulta analítica varre milhões de linhas e disputa CPU, memória e cache com a carga transacional; dependendo do nível de isolamento, ela ainda segura bloqueios ou força o banco a manter versões antigas de linha por muito tempo. Fora de pico o risco cai, mas o pico se desloca: fechamento, folha e feriado bagunçam essa janela. Tem também o modelo: o core é normalizado para escrever com integridade, então o relatório vira dez joins e ninguém consegue manter. O que eu proponho é extrair o dado para uma camada analítica, modelada em fato e dimensão, com carga incremental. Se a pressa for grande, uma réplica de leitura resolve a contenção como paliativo, mas não resolve o modelo nem o histórico, e eu deixaria isso claro.

Descreva como você montaria o fluxo de dados de transações de cartão desde o core até o relatório do time de risco.

Começo pela extração incremental do core, por data e hora de processamento ou por CDC, para não varrer a tabela inteira todo dia e não competir com a carga transacional. O dado cru cai em staging, espelho da origem, volátil, sem regra nenhuma. Da staging eu trato: padronizo tipo e fuso, deduplico por chave da transação, trato nulo e valor fora de faixa, e reconcilio o total do dia contra o controle da origem. Depois modelo dimensionalmente: uma fato de transação com grão de uma linha por transação autorizada, com valor e MCC como métricas, e dimensões de cliente, cartão, estabelecimento, canal e tempo. A carga é idempotente, por sobrescrita de partição de data, para o job poder ser reexecutado sem duplicar. Por cima disso publico o data mart de risco. E cuido de dado pessoal desde a staging, com mascaramento e controle de acesso, por causa da LGPD.

Fundamentos

Fundamentos · tema 2 de 30

OLAP, OLTP e ETL

35 min · 2 vídeos · 14 cards · 2 drill

Por que cai

É o tema que separa quem entende arquitetura de quem só escreve SQL. A banca usa a pergunta do relatório no banco transacional para ver se você raciocina sobre lock, contenção e modelo, ou se responde só 'porque é lento'.

Pré-teste · 1 de 2

responda antes de ver

O time de risco quer rodar, às 10h de um dia útil, um SELECT com seis joins e GROUP BY sobre a tabela de transações do core bancário. Qual é o principal risco técnico?

Confiança:

Vídeo · português · 13 min

Percorre as características lado a lado, que é exatamente o formato do comparativo que a banca espera ouvir. Assista anotando qual característica você conseguiria justificar sem olhar a tabela.

Em uma frase

OLTP registra a transação no instante em que ela acontece; OLAP responde perguntas sobre o conjunto histórico dessas transações; ETL é o processo que leva o dado de um mundo para o outro.

Dois propósitos, portanto dois desenhos

A diferença não começa no desempenho. Começa na pergunta que cada sistema existe para responder.

O sistema transacional existe para que o PIX saia da sua conta e entre na conta do beneficiário sem sumir no meio. Isso exige atomicidade, integridade referencial e resposta em milissegundos. Para conseguir isso, o modelo é normalizado: cada informação em um lugar só, sem redundância, para que a escrita seja pequena e consistente.

O sistema analítico existe para responder qual foi o ticket médio por segmento nos últimos 24 meses. Isso exige varrer muita linha, agregar e cruzar contexto. Para conseguir isso, o modelo é desnormalizado em fato e dimensão, e o armazenamento costuma ser colunar, porque a consulta lê poucas colunas de muitas linhas.

Aspecto	OLTP	OLAP
Propósito	Registrar a operação do dia a dia	Analisar o histórico para decidir
Unidade de trabalho	Transação curta, poucas linhas	Consulta longa, muitas linhas
Modelo	Normalizado, terceira forma normal	Dimensional: fato e dimensão
Carga	Escrita intensa, leitura por chave	Leitura intensa, escrita em lote
Histórico	Estado atual e janela recente	Anos de histórico preservado
Latência esperada	Milissegundos	Segundos a minutos
Concorrência	Milhares de sessões curtas	Dezenas de consultas pesadas
Exemplo no banco	Autorizar compra no cartão	Inadimplência por safra de originação

Por que não fazer o relatório direto no transacional

Essa é a pergunta que a banca faz. Três motivos, em ordem de peso:

Contenção. Uma consulta que varre milhões de linhas disputa CPU, memória, cache e I/O com as transações que estão acontecendo agora. O efeito aparece como latência na autorização de cartão, que é justamente o que não pode acontecer.

Bloqueio e versões. Dependendo do nível de isolamento, a consulta longa segura bloqueios de leitura ou obriga o banco a manter versões antigas de linha enquanto ela roda. Isso incha o mecanismo de versionamento e atrasa quem escreve.

Modelo. O core é normalizado. Perguntar "ticket médio por segmento e canal" ali vira uma consulta com dez joins, difícil de escrever, difícil de manter e cara de executar. E o histórico que a pergunta pede muitas vezes já foi expurgado do transacional.

O data warehouse e suas camadas

Data warehouse é o repositório integrado, histórico e orientado a assunto que serve a carga analítica. Ele não é uma tabela grande: é um caminho com camadas, e cada camada existe para desacoplar um problema.

1Staging: área de pouso do dado extraído, o mais próximo possível da origem. Volátil, sem regra de negócio. Existe para que a extração não dependa da transformação.
2ODS: base integrada de várias origens, granular e atual, para consumo operacional. Ex.: visão do cliente no atendimento. Não é lugar de histórico analítico.
3Warehouse: o núcleo integrado, histórico, com dimensões conformadas — a mesma dimensão de cliente valendo para cartão, crédito e investimentos.
4Data mart: recorte por domínio, já modelado para consumo. Ex.: data mart de cartões para o BI da área.

Modelagem dimensional, o mínimo para a sabatina

A tabela fato— tabela que guarda os eventos mensuráveis do negócio, com métricas e chaves para as dimensões registra o que aconteceu: uma transação de cartão, com valor, data e as chaves de cliente, produto e estabelecimento.

A tabela dimensão— tabela que descreve o contexto do evento e fornece filtros e agrupamentos registra o contexto: quem é o cliente, qual o produto, qual a agência, qual o dia.

E antes das duas vem o grão: a resposta para "o que é uma linha desta fato". Uma transação autorizada? Um dia por conta? Um mês por contrato? O grão define quais dimensões cabem e quais métricas podem ser somadas.

O aprofundamento de esquema estrela, floco de neve e dimensão que muda com o tempo vem no tema de modelagem de dados. Para a sabatina de fundamentos, saber definir fato, dimensão e grão com um exemplo bancário já cobre.

ETL como processo

1Extract: tira o dado da origem, de preferência incremental (por data de processamento ou por CDC), para não varrer tudo todo dia.
2Transform: padroniza tipo e fuso, deduplica por chave, trata nulo e valor fora de faixa, aplica regra de negócio, conforma dimensões e reconcilia total contra a origem.
3Load: grava no destino de forma idempotente — sobrescrita de partição ou merge por chave — para que reexecutar o job não duplique nada.

Como responder isso em voz alta

Comece separando propósito, não desempenho. Diga o que cada sistema existe para fazer, mostre que o propósito determina o modelo, e só então liste as consequências: contenção, bloqueio, join e histórico. Feche com o caminho staging, warehouse, data mart e um exemplo de cartão ou PIX. Cerca de noventa segundos, e a rubrica inteira está coberta.

Se quiser outro ângulo

Fecha a parte que o primeiro vídeo não cobre: as camadas entre a origem e o relatório. Repare no papel de cada camada e por que staging não é lugar de consulta.

Como cai na sabatina

“Por que não fazer o relatório direto no banco transacional?”

Erros comuns

Dizer que a diferença é só desempenho. Desempenho é consequência; a causa é propósito diferente, que leva a modelo diferente, carga diferente e garantia diferente.
Achar que OLAP significa obrigatoriamente cubo. Cubo foi a implementação dominante nos anos 2000; hoje OLAP é o tipo de carga, servida por warehouse colunar, lakehouse ou motor MPP.
Confundir normalizado com bom. Terceira forma normal serve para escrever com integridade; para ler agregado ela cobra dezenas de joins por consulta.
Tratar staging como se fosse camada de consumo. Staging é área de pouso, volátil, espelho da origem; quem consulta staging herda o modelo do sistema fonte e todos os defeitos dele.
Esquecer o grão da tabela fato. Sem definir a que corresponde uma linha, a soma duplica e ninguém descobre até o número chegar errado na diretoria.
Responder ETL como 'três scripts'. O que a banca quer ouvir é o processo: extração incremental, tratamento de qualidade, conformação de dimensão e carga idempotente.

Flashcards

Card 1 de 14

0 certos · 0 a rever

Drill

OLTP ou OLAP?

Classifique cada carga de trabalho pelo perfil dominante. Decida antes de abrir a resposta e diga em voz alta a justificativa.

1.Autorizar uma compra no crédito e atualizar o limite disponível.
2.Calcular a inadimplência por safra de originação nos últimos 36 meses.
3.Consultar o saldo da conta no aplicativo.
4.Comparar volume de PIX por faixa de horário e por canal, mês a mês.
5.Registrar a alteração de endereço no cadastro do cliente.
6.Levantar quantos clientes usaram os três canais no mesmo mês, nos últimos dois anos.

Drill

Onde mora esse dado?

Para cada situação, diga em que camada do data warehouse o dado deve estar: staging, ODS ou data mart.

1.Cópia bruta do arquivo diário de transações de cartão recebido da bandeira, ainda sem tratamento.
2.Visão integrada e atual do cliente, montada de quatro sistemas, usada pelo atendimento durante a ligação.
3.Fato de transação de cartão com dimensões de cliente, produto, estabelecimento e tempo, consumida pelo BI de cartões.
4.Tabela temporária com o delta das últimas 24 horas do cadastro, apagada depois da carga.

Quiz · 1 de 2

Qual afirmação descreve melhor a relação entre ETL e data warehouse?

Explique para um gerente

Explique para o gerente da agência por que o relatório de rentabilidade dele não sai do mesmo banco que autoriza o PIX dele.

Responda em voz alta antes de seguir. Se travar numa palavra técnica, é sinal de que ainda não entendeu essa parte.

Perguntas de sabatina deste tema

· O time de negócio pede um relatório diário de transações e propõe rodar a consulta direto no banco do core bancário, fora do horário de pico. O que você responde?
· Descreva como você montaria o fluxo de dados de transações de cartão desde o core até o relatório do time de risco.

Responder no simulado

Para ir além

PróximoData Centric e Data Driven