Seu pipeline de PIX consome de um tópico Kafka com entrega ao menos uma vez. O time de negócio reclamou de transações duplicadas no relatório. Como você investiga e resolve?

Primeiro eu confirmo se a duplicidade é de evento ou de linha. Se o mesmo identificador de transação aparece duas vezes com o mesmo conteúdo, é reentrega, o que é esperado nessa garantia. A correção não é mudar o Kafka, é tornar o destino idempotente: aplicar com MERGE pela chave da transação, ou deduplicar por chave e janela antes de gravar. Se o conteúdo difere, aí não é duplicata, é atualização, e o problema é o destino estar dando append em vez de upsert. Também checaria o momento do commit de offset: quem comita antes de gravar perde dado, quem comita depois pode reprocessar, e é por isso que o destino precisa aguentar reprocesso. Só consideraria exatamente uma vez se o custo de deduplicar fosse maior que o custo do processamento transacional fim a fim, o que raramente é o caso.

Além da ementa

Além da ementa · tema 24 de 30

Ingestão e CDC

Q: Como você replicaria a tabela de contas do core bancário para o lake sem pesar no core?

Eu não consultaria o core em ciclo. Usaria CDC lendo o log de transações, com Debezium ou AWS DMS conforme o que já existe no banco, porque isso captura INSERT, UPDATE e DELETE sem gerar carga de consulta sobre as tabelas que atendem o cliente. O desenho seria carga inicial uma vez, em janela combinada com o time do core, e a partir daí só o fluxo de mudanças. Publicaria no Kafka usando o número da conta como chave, para preservar ordem por conta, e aplicaria no lake com MERGE numa tabela Delta, tratando delete como marcação lógica para não perder rastro exigido por auditoria. Combinaria com o dono do core o impacto de habilitar o log lógico, que não é zero, e monitoraria o atraso de replicação. Se o core for um sistema onde não dá para habilitar CDC, aí eu negociaria uma réplica de leitura e faria a extração dela, nunca da instância primária.

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

Por que cai

Ingestão é a fronteira entre o mundo transacional e o analítico, e é onde o banco tem mais medo: consulta mal feita no core afeta cliente pagando cartão. A banca usa este tema para ver se você pensa no impacto sobre a origem, não só no destino.

Pré-teste · 1 de 2

responda antes de ver

Por que ler o log de transações captura mais do que consultar a tabela por data de atualização?

Confiança:

Vídeo · português · 14 min

Explica CDC como padrão de integração e não como produto, que é exatamente o recorte da sabatina. Preste atenção em como ele justifica o baixo impacto sobre o sistema de origem.

Em uma frase

Ingestão é como o dado sai da origem e entra no lake; CDC é fazer isso lendo o log de transações do banco de origem, de modo a capturar toda mudança sem consultar as tabelas que atendem o cliente.

Full ou incremental

Carga full copia a tabela inteira toda vez. É simples, é à prova de bug de watermark e é o que você faz numa tabela de domínio com 400 linhas. Em tabela de 30 milhões de contas, vira leitura pesada na origem, janela longa e nenhuma informação sobre o que mudou.

Carga incremental copia só o que mudou desde a última execução, guiada por uma watermark— marca do ponto até onde você já leu — um timestamp ou um identificador crescente. Barata, mas depende de o critério ser confiável.

CDC: ler o log em vez de perguntar

O banco de origem já escreve toda alteração num log de transações, porque precisa dele para durabilidade e recuperação. CDC consome esse log e publica cada INSERT, UPDATE e DELETE como um evento.

Três motivos para preferir isso a consultar por timestamp:

1Captura DELETE — a consulta por timestamp não vê linha que sumiu
2Não perde atualização intermediária — o log tem cada versão, a consulta só vê a última
3Não pesa no OLTP — lê o log, não as tabelas que atendem autorização de cartão

Debezium é o conector open source que lê o log de PostgreSQL, MySQL, SQL Server e Oracle e publica em Kafka. AWS DMS é o serviço gerenciado que faz carga inicial e replicação contínua para destinos como S3 e Redshift. Debezium dá mais controle sobre o formato do evento; DMS dá menos operação.

MERGE: a peça que fecha o CDC

Um fluxo de mudanças aplicado com INSERT transforma o destino num log, não numa tabela. Update vira linha nova; delete não existe.

O que fecha o ciclo é upsert, o MERGE: casa pela chave de negócio, atualiza quando existe, insere quando não existe, e trata delete — em banco, quase sempre como marcação lógica, porque auditoria e LGPD exigem rastro do que foi removido e quando.

Kafka, o vocabulário que cai

Conceito	O que é	Consequência prática
Tópico	Canal lógico nomeado por assunto	Um tópico por evento de negócio: transacao-cartao, evento-pix
Partição	Divisão ordenada do tópico	Define o teto de paralelismo de consumo
Chave	Valor que escolhe a partição por hash	Número da conta como chave preserva a ordem dos eventos daquela conta
Consumer group	Conjunto de consumidores que dividem as partições	Cada partição vai para um consumidor do grupo; excedentes ficam ociosos
Offset	Posição da última mensagem lida	Guardado por grupo e partição; permite retomar e reprocessar
Retenção	Tempo ou tamanho que a mensagem permanece	Leitura não apaga; dá para voltar no tempo
Replicação	Número de cópias da partição entre brokers	Durabilidade contra perda de broker

Garantias de entrega

No máximo uma vez pode perder. Ao menos uma vez pode duplicar. Exatamente uma vez não faz nem um nem outro, mas exige suporte fim a fim e custa em latência e complexidade.

O arranjo mais comum em banco é ao menos uma vez com destino idempotente: aceita reentrega e resolve no MERGE pela chave da transação. É mais barato que garantir exatamente uma vez em toda a cadeia e dá o mesmo resultado no relatório.

Kinesis, em comparação curta

Kinesis Data Streams é o equivalente gerenciado na AWS: shard no lugar de partição, chave de partição com o mesmo papel, retenção configurável. Troca o ecossistema e o controle fino do Kafka por menos operação. Se a stack já é AWS e o time é pequeno, é escolha defensável — e dizer isso com o critério explícito vale mais do que torcer por uma das duas.

Se quiser outro ângulo

Fecha o vocabulário de Kafka em pouco tempo: tópico, partição, produtor e consumidor. Use para conferir se você sabe explicar cada termo sem olhar.

Como cai na sabatina

“Como você replicaria a tabela de contas do core bancário para o lake sem pesar no core?”

Erros comuns

Fazer carga full de tabela grande todo dia por comodidade. Custa janela, custa leitura na origem e ainda assim não conta o que aconteceu entre as fotos.
Usar data_atualizacao como marca d água sem tratar dado atrasado. Registro que chega depois com timestamp antigo fica para trás da marca e nunca é lido.
Achar que consulta incremental por timestamp captura tudo. Ela não vê DELETE e perde atualizações intermediárias entre duas leituras.
Confundir CDC com replicação de banco. CDC entrega um fluxo de eventos de mudança para quem quiser consumir; replicação mantém uma cópia idêntica e fecha a porta para transformação.
Esperar ordenação global no Kafka. A ordem é garantida por partição, então a chave que você escolhe é o que define se os eventos da mesma conta chegam em ordem.
Tratar entrega ao menos uma vez como se fosse exatamente uma vez. Sem idempotência ou chave de deduplicação no destino, uma reentrega vira lançamento duplicado.
Aplicar o fluxo de CDC no destino com INSERT. Sem MERGE, update vira linha nova e delete simplesmente não existe no lake.

Flashcards

Card 1 de 14

0 certos · 0 a rever

Drill

Escolha a estratégia de ingestão

Para cada tabela do banco, escolha a estratégia mais adequada. Justifique mentalmente antes de abrir a resposta.

1.Tabela de domínio com 400 códigos de tipo de transação, que muda uma vez por trimestre.
2.Tabela de contas do core, com 30 milhões de linhas, encerramentos e correções cadastrais retroativas.
3.Log de eventos de clique do app, append-only, com identificador crescente e sem atualização.
4.Tabela de limites de cartão, atualizada muitas vezes ao dia e usada para decidir autorização.
5.Extrato consolidado mensal fechado, gerado uma vez e nunca alterado.

Drill

Kafka: qual conceito responde ao problema?

Cada item descreve uma necessidade. Diga qual conceito de Kafka a atende.

1.Garantir que os eventos da mesma conta cheguem em ordem ao consumidor.
2.Dobrar a vazão de leitura sem que dois consumidores processem a mesma mensagem.
3.Sobreviver à perda de um broker sem perder mensagem confirmada.
4.Permitir que um consumidor novo reprocesse os últimos sete dias.
5.Retomar exatamente de onde parou depois de uma reinicialização.

Quiz · 1 de 2

Qual é a principal limitação de uma ingestão incremental baseada na coluna data_atualizacao?

Explique para um gerente

Explique para o dono do sistema de cadastro por que ler o log de transações incomoda menos o banco de dados dele do que rodar um SELECT por data de atualização a cada hora.

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

· Como você replicaria a tabela de contas do core bancário para o lake sem pesar no core?
· Seu pipeline de PIX consome de um tópico Kafka com entrega ao menos uma vez. O time de negócio reclamou de transações duplicadas no relatório. Como você investiga e resolve?

Responder no simulado

Para ir além

PróximoArquiteturas de dados