O saldo no core diverge do saldo no relatório gerencial. Qual é a fonte da verdade?

Depende da pergunta que está sendo feita, e eu começaria separando dois conceitos. O core é o Source of Record do saldo: é onde o lançamento nasce e é autoritativo sobre o fato. O relatório vem da Source of Truth analítica, que é a visão consolidada, datada e governada usada para decidir. As duas podem divergir sem que nenhuma esteja errada, porque o relatório tem corte temporal, regra contábil e às vezes exclusão de lançamentos em contingência. Então minha primeira ação não é escolher um número, é reconciliar: comparar o mesmo corte, isolar se a diferença é de janela de ingestão, de regra de negócio ou defeito real. Para saldo em tempo real ao cliente, a resposta é o core. Para o número que vai ao regulador, é a visão consolidada, porque ela é auditável e reproduzível. O que não pode existir é divergência sem explicação documentada e sem alerta quando ela sai da faixa esperada.

A diretoria leu sobre Data Mesh e quer adotar. Vocês têm quatro domínios grandes, um time central de dados com fila de três meses e nenhuma plataforma self-serve. O que você recomenda?

Eu concordaria com o diagnóstico e discordaria do primeiro passo. A fila de três meses é sintoma clássico do gargalo central que o Mesh ataca, então a direção faz sentido. Mas os quatro princípios se sustentam juntos: sem plataforma self-serve, descentralizar propriedade só transfere o problema para times que não têm ferramenta, e sem governança federada computacional cada domínio inventa seu padrão de qualidade e de privacidade. Eu começaria pela plataforma e pelo contrato de dados, escolheria um domínio piloto com time de engenharia maduro, como cartão, e trataria uma ou duas tabelas como produto de verdade: dono nomeado, SLA de atualização, schema versionado, catálogo. Mediria tempo de entrega antes e depois. Se o piloto não reduzir a fila, o problema é de plataforma ou de capacidade do domínio, e escalar o modelo só multiplicaria o custo de coordenação.

Além da ementa

Além da ementa · tema 25 de 30

Arquiteturas de dados

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

Por que cai

Arquitetura é onde a banca mede senioridade. Qualquer pessoa lista nomes; o que separa é dizer o que cada escolha custa e em que condição você mudaria de ideia. A pergunta sobre fonte da verdade é a que mais expõe quem nunca conciliou número com área de negócio.

Pré-teste · 1 de 2

responda antes de ver

Qual é o custo característico da arquitetura Lambda?

Confiança:

Vídeo · português · 9 min

Contrasta as duas arquiteturas em pouco tempo e com desenho de camadas. Ignore o recorte de produto Azure e fique com o raciocínio: o que some quando você tira a camada batch.

Em uma frase

Arquitetura de dados é a escolha de onde o dado mora, quem manda nele e quantas vezes a mesma regra é escrita — e cada opção cobra num lugar diferente.

Lambda contra Kappa

Lambda tem duas camadas de processamento. A batch reprocessa o histórico inteiro e produz o número correto, com latência de horas. A speed processa o que chega agora e produz um número aproximado, em segundos. A camada de serviço junta as duas na hora da consulta: histórico da batch, últimas horas da speed.

Kappa elimina a camada batch. Tudo é stream, e reprocessar histórico é reler o log de eventos desde o começo com o código novo.

	Lambda	Kappa
Caminhos de processamento	Dois: batch e speed	Um: stream
Custo principal	A mesma regra escrita duas vezes, que diverge com o tempo	Depender do log reter histórico e reprocessar volume grande por stream
Quando faz sentido	Regra batch complexa que não se traduz bem para stream	Lógica que cabe em stream e log com retenção suficiente

Warehouse, Lake e Lakehouse

	Data Warehouse	Data Lake	Lakehouse
Schema	On write: modela antes de carregar	On read: aplica na leitura	On read com contrato de tabela por cima
Dado que aceita	Estruturado	Qualquer formato	Qualquer formato, com tabelas governadas sobre os arquivos
Transação	ACID nativo	Não tem: escrita parcial é visível	ACID pela camada Delta, Iceberg ou Hudi
Custo de armazenamento	Alto	Baixo (objetos)	Baixo (objetos)
Risco típico	Rigidez e fila de modelagem	Virar pântano sem catálogo e qualidade	Complexidade de operar a camada de tabela
Uso no banco	Relatório regulatório estável	Payload cru de PIX, log, áudio	Tabelas de transação com MERGE e time travel para auditoria

Data Mesh

Mesh responde a um gargalo organizacional: um time central de dados que não dá conta da fila de pedidos de quatro áreas de negócio. Quatro princípios:

1Propriedade descentralizada por domínio: quem gera o dado responde por ele
2Dado como produto: dono, consumidor, contrato, SLA, documentação, descoberta
3Plataforma de dados self-serve: o domínio publica sem depender do time central
4Governança federada computacional: regras globais decididas em conjunto e aplicadas por automação

Um data product não é uma tabela publicada. É uma tabela com dono nomeado, consumidor conhecido, SLA de atualização, qualidade medida e presença no catálogo. O contrato de dados é o acordo explícito de schema, semântica, frequência e política de mudança — o que transforma quebra silenciosa em violação detectável.

Source of Record e Source of Truth

Este par é o que mais derruba candidato, porque parece sinônimo e não é.

Source of Record— O sistema onde o dado nasce e que é autoritativo sobre o fato original. O core bancário é o SoR do lançamento. O sistema de cadastro é o SoR do endereço. Se a base analítica discorda do SoR sobre o que aconteceu, é a base analítica que se explica.

Source of Truth— A visão consolidada, tratada e governada que a organização usa para decidir. A SoT reúne vários SoRs, resolve duplicidade, aplica regra de negócio e corte temporal, e é a referência do relatório e do indicador.

Elas divergem por bons motivos. Corte temporal diferente (o core é agora, o relatório é o fechamento de ontem às 23h59). Regra distinta (lançamento em contingência que a contabilidade ainda não reconhece). Atraso de ingestão. E, às vezes, defeito real.

A resposta profissional não é eleger um número, é reconciliar: comparar o mesmo corte, isolar a causa, documentar a explicação e configurar alerta para quando a diferença sair da faixa esperada. Divergência explicada é operação normal; divergência sem explicação é incidente.

Modern data stack, em uma frase

Conjunto de ferramentas gerenciadas e desacopladas — ingestão, armazenamento em nuvem, transformação em SQL, orquestração, catálogo e BI — montadas por integração em vez de por plataforma única.

Se quiser outro ângulo

Resumo curto dos princípios do Mesh. Assista já perguntando quais deles exigem mudança de organograma, porque é aí que a banca costuma cutucar.

Como cai na sabatina

“O saldo no core diverge do saldo no relatório. Qual é a fonte da verdade?”

Erros comuns

Descrever Lambda e Kappa como opções equivalentes. Lambda cobra caro em manter a mesma regra escrita duas vezes; Kappa cobra em reprocessamento de histórico pelo próprio stream. Sem citar esse custo, a resposta vira lista.
Tratar Lakehouse como marketing de Data Lake. O que muda é concreto: formato de tabela com transação, evolução de schema e time travel sobre armazenamento de objetos.
Dizer que Data Mesh é arquitetura técnica. Os quatro princípios são organizacionais antes de tudo; sem times de domínio com dono, o Mesh vira lake bagunçado com nome novo.
Confundir Source of Record com Source of Truth. SoR é onde o dado nasce; SoT é a visão consolidada e governada usada para decidir. Podem ser sistemas diferentes sem que ninguém esteja errado.
Responder que a fonte da verdade é sempre o core bancário. Para saldo em tempo real, sim; para o número do relatório regulatório de fechamento, a verdade é a visão consolidada e datada, não a tela do momento.
Propor Data Mesh para uma empresa com um time de dados de oito pessoas. Governança federada e plataforma self-serve exigem escala organizacional; abaixo dela, é overhead.

Flashcards

Card 1 de 14

0 certos · 0 a rever

Drill

SoR ou SoT?

Para cada afirmação, classifique o papel do sistema descrito.

1.O core bancário, que registra o lançamento no instante em que a transação de cartão é autorizada.
2.A tabela gold de posição consolidada de clientes, usada pelo relatório regulatório e pela diretoria.
3.O sistema de cadastro, onde o cliente informa o endereço no onboarding.
4.A visão unificada de cliente que resolve duplicidade entre cadastro, cartão e seguros e escolhe o endereço vigente.
5.O extrator do PIX, que grava na zona raw o payload cru recebido do SPI.

Drill

Qual arquitetura responde ao cenário?

Escolha a arquitetura mais adequada e prepare uma frase justificando o custo que você aceita.

1.Relatório regulatório mensal sobre dados estruturados, com modelagem estável há anos e exigência forte de rastreabilidade.
2.Guardar por sete anos o payload cru de PIX, log de app e áudio de call center, sem saber ainda que perguntas serão feitas.
3.Tabelas de transação que precisam de atualização corretiva, leitura concorrente por Spark e SQL, e reconstrução de um estado passado para auditoria.
4.Um conglomerado com áreas de cartão, seguros, crédito e câmbio, cada uma com time de engenharia próprio, e uma fila de meses no time central de dados.
5.Uma fintech com doze pessoas no total, sendo duas de dados, e um único banco transacional.

Quiz · 1 de 2

O que o Lakehouse acrescenta a um Data Lake?

Explique para um gerente

Explique para o diretor de operações, em um minuto, por que o número do relatório de saldo pode legitimamente diferir do número da tela do gerente, sem que nenhum dos dois esteja errado.

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 saldo no core diverge do saldo no relatório gerencial. Qual é a fonte da verdade?
· A diretoria leu sobre Data Mesh e quer adotar. Vocês têm quatro domínios grandes, um time central de dados com fila de três meses e nenhuma plataforma self-serve. O que você recomenda?

Responder no simulado

Para ir além

PróximoAWS para engenharia de dados