Como estruturar um data warehouse para o setor financeiro

Um erro de modelagem em dados financeiros custa caro e demora a aparecer#

Montar um data warehouse financeiro não é escolher a ferramenta mais nova, é modelar transações, contratos e parcelas de um jeito que aguente volume, sobreviva a auditoria e não desmorone quando alguém pedir a origem exata de um número. Boa parte dos projetos que a gente recebe para resolver chegou quebrada exatamente aí: o dado existe, mas ninguém consegue explicar de onde ele veio, nem garantir que o saldo de ontem fecha com o de hoje.

No setor de serviços financeiros isso pesa mais do que em qualquer outro. É um ambiente regulado pelo Banco Central, com volume alto de transações, exigência de rastreabilidade e dados pessoais sensíveis que caem sob a LGPD, a Lei nº 13.709/2018. Um número errado de inadimplência não é só um gráfico feio, é risco regulatório e decisão de crédito tomada em cima de informação furada. Este artigo mostra como estruturar a camada de dados que sustenta análise financeira séria, e não mais um amontoado de extrações manuais.

A modelagem dimensional é a base de um data warehouse financeiro que escala#

A tentação de copiar o modelo do core bancário ou do sistema de crédito para dentro do warehouse é grande e quase sempre errada. Bancos de dados transacionais são normalizados para escrever rápido e manter consistência, não para responder perguntas analíticas. Para BI, o padrão consolidado há décadas é a modelagem dimensional em esquema estrela, proposta por Ralph Kimball, com tabelas fato no centro e dimensões ao redor.

Isso não é preferência estética. O motor VertiPaq, que roda por trás do Power BI e dos modelos semânticos do Microsoft Fabric, comprime cada coluna com base na cardinalidade dos valores. Colunas com poucos valores distintos comprimem muito bem, chaves inteiras trabalham melhor que textos longos, e o esquema estrela evita as junções profundas que derrubam performance. Replicar dezenas de tabelas normalizadas do sistema de origem é o caminho mais curto para um modelo lento e caro.

A decisão central é definir quais são os fatos e qual o grão de cada um, ou seja, o que uma única linha da tabela representa. No contexto financeiro, recomendo pelo menos três tabelas fato distintas, porque respondem a perguntas diferentes e têm granularidades que não podem se misturar.

Tabela fato	Grão (uma linha representa)	Métricas típicas	Perguntas que responde
Fato Transação	Um lançamento ou movimentação	Valor, taxa, tipo de operação	Volume transacionado, fluxo de caixa, ticket médio
Fato Contrato	Um contrato de crédito ou produto	Valor contratado, prazo, taxa	Carteira originada, mix de produto, exposição
Fato Parcela	Uma parcela de um contrato	Valor devido, valor pago, dias de atraso	Inadimplência, curva de safra, recuperação

Repare que Fato Transação é um fato transacional puro, enquanto Fato Parcela tem comportamento de acumulação ao longo do tempo, com status que muda de "a vencer" para "paga" ou "em atraso". São grãos incompatíveis. Jogar tudo numa tabela só é a origem clássica dos números que não batem, porque valor transacionado não se soma da mesma forma que saldo devedor de parcela. O modelo precisa refletir essa diferença, não escondê-la.

As dimensões são o vocabulário compartilhado do negócio. As mais importantes em um contexto financeiro:

• Dimensão Cliente: identificação, segmento, faixa de renda, região, perfil de risco. Aqui mora a maior parte do risco de LGPD, então trate documento e dados pessoais com cuidado desde o desenho.
• Dimensão Produto: linha de crédito, tipo de conta, modalidade, indexador. Essencial para analisar rentabilidade e mix de carteira.
• Dimensão Conta: conta, agência, canal de originação, status. Liga a movimentação ao relacionamento com o cliente.
• Dimensão Tempo: calendário completo, com data da operação separada da data de competência contábil, porque no financeiro elas quase nunca coincidem.
• Dimensões de apoio: canal, gerente ou originador, moeda, centro de custo.

Um cuidado que economiza muito retrabalho: use dimensões conformadas. Se "Cliente" significa a mesma coisa no Fato Transação e no Fato Contrato, precisa ser a mesma tabela física, com a mesma chave. É isso que permite cruzar volume transacionado com carteira originada sem gambiarra. E trate como dimensão de variação lenta tudo que muda no tempo, como o perfil de risco do cliente, para preservar o histórico e conseguir reconstruir uma decisão de crédito passada. Para aprofundar os cálculos sobre esse modelo, vale ler nosso material sobre boas práticas de modelagem e DAX.

As camadas medalhão organizam o caminho da origem até o painel#

Ter um bom modelo dimensional não basta se o percurso do dado bruto até ele for uma caixa-preta. A arquitetura medalhão, adotada de forma nativa no Microsoft Fabric sobre o OneLake, resolve isso separando o processamento em três camadas com responsabilidades claras.

Camada	Conteúdo	Formato e estado	Quem consome
Bronze	Cópia fiel da origem (core bancário, crédito, cadastro)	Bruto, sem transformação, histórico preservado	Engenharia de dados
Prata	Dados limpos, deduplicados, integrados e conformados	Padronizado, chaves resolvidas, regras aplicadas	Engenharia e analistas
Ouro	Modelo dimensional pronto para consumo	Fatos e dimensões, agregações de negócio	Power BI, diretoria, áreas

A camada bronze é o seu seguro. Ela guarda o dado exatamente como chegou, o que permite reprocessar quando uma regra muda ou quando você descobre um erro meses depois. Em ambiente auditado, poder provar que o número do relatório deriva sem intervenção do dado original do core vale ouro.

A prata é onde acontece o trabalho pesado: resolver o mesmo cliente que aparece com dois cadastros, padronizar códigos de produto, tratar valores em moedas diferentes, aplicar as regras de negócio que transformam lançamento cru em informação confiável. A ouro é o que o Power BI enxerga, já no formato estrela descrito acima, otimizado para leitura.

No Fabric, o OneLake funciona como uma camada de armazenamento única para toda a organização, e sobre ele você constrói tanto o Lakehouse, orientado a engenharia com Spark e notebooks, quanto o Warehouse, com experiência SQL familiar para quem vem do mundo relacional. Os dois gravam no mesmo formato aberto no OneLake, o que evita cópias duplicadas do mesmo dado. E há um recurso que muda o jogo para volume alto: o modo Direct Lake. Ele lê os dados diretamente das tabelas no OneLake, sem importar para dentro do modelo e sem consultar a origem a cada clique como o DirectQuery faz. Na prática, você tem performance próxima do modo Import com atualização quase imediata do dado do lake. Se você ainda está avaliando a plataforma, escrevemos uma análise honesta sobre o que é o Microsoft Fabric e se vale a pena. O desenho e a operação dessas camadas são exatamente o tipo de trabalho que nosso time de engenharia de dados entrega.

Governança, linhagem e LGPD não são etapa final, são premissa#

Em muitos projetos a governança entra no fim, como um selo que se cola depois que tudo já está pronto. No setor financeiro isso não funciona. A rastreabilidade precisa estar embutida na arquitetura, porque em algum momento alguém vai perguntar, com razão, de onde veio determinado número e quem teve acesso a ele.

Três frentes precisam estar resolvidas desde o começo:

• Linhagem de dados: saber, para cada indicador do painel, qual tabela de origem, qual transformação e qual regra o produziram. As camadas medalhão já ajudam nisso, porque o caminho bronze, prata, ouro é auditável por construção. O catálogo do Fabric complementa registrando de onde cada item deriva.
• Controle de acesso: nem todo analista pode ver o CPF ou o documento do cliente. Segurança em nível de linha restringe o que cada perfil enxerga, e a proteção de colunas sensíveis limita a exposição de dados pessoais. No financeiro, isso não é conforto, é obrigação regulatória.
• LGPD na prática: a Lei nº 13.709/2018 exige finalidade clara, minimização e capacidade de responder a titulares. Isso se traduz em decisões técnicas concretas, como mascarar ou anonimizar dados pessoais que não precisam aparecer no relatório, e manter registro de quem acessou o quê.

Uma regra que aplicamos sempre: o dado sensível não deve chegar à camada ouro sem passar por uma decisão explícita de exposição. Se o relatório precisa de segmento de renda, mas não do valor exato do salário, a prata já entrega a faixa e descarta o valor. Menos dado sensível circulando é menos superfície de risco, e ainda melhora a compressão do VertiPaq, porque uma coluna de faixa tem cardinalidade muito menor que uma de valor contínuo. Se esse tema é prioridade na sua operação, temos um guia completo sobre governança de dados e LGPD no Power BI.

Volume alto exige decisões conscientes de performance e capacidade#

Serviços financeiros geram volume. Uma base de transações cresce em ritmo que não perdoa modelo mal desenhado. Algumas decisões fazem diferença real quando a escala aperta.

A primeira é não trazer histórico infinito para dentro do modelo semântico sem pensar. Separe o dado quente, dos últimos meses ou anos que sustentam a operação do dia a dia, do dado frio de arquivo. O Direct Lake ajuda aqui, porque você mantém tabelas grandes no OneLake e o modelo lê sob demanda, sem inflar a memória com anos de parcelas que quase ninguém consulta.

A segunda é cuidar da cardinalidade das colunas. Identificadores de transação com milhões de valores únicos são o pior inimigo da compressão. Quando o identificador não é necessário para análise, ele fica na camada de detalhe e não sobe para o modelo de consumo. Chaves inteiras substituem chaves de texto sempre que possível.

A terceira é dimensionar a capacidade do Fabric com honestidade. A plataforma cobra por Capacity Units, e as capacidades vão do SKU F2 até o F2048. Escolher pequeno demais gera lentidão, escolher grande demais é dinheiro parado. O caminho é medir a carga real de processamento e consumo antes de fechar o tamanho, e revisar conforme o uso cresce. Não existe número mágico, existe medição. O Fabric foi anunciado pela Microsoft em 2023 e evolui rápido, então capacidades definidas há pouco tempo já merecem revisão.

A tabela abaixo resume os erros que mais vemos e o que fazer no lugar.

Armadilha comum	Consequência	O que fazer no lugar
Copiar o modelo normalizado do core	Modelo lento, junções profundas	Esquema estrela com fatos e dimensões
Misturar transação e parcela na mesma fato	Números que não somam	Fatos separados por grão
Levar CPF e valores sensíveis à camada ouro	Risco de LGPD e má compressão	Mascarar ou agrupar na prata
Importar todo o histórico para a memória	Custo alto, atualização lenta	Direct Lake e separação quente e frio
Dimensionar a capacidade no chute	Lentidão ou desperdício	Medir carga e ajustar o SKU

Com o modelo pronto e governado, o consumo em Power BI fica direto: os dashboards leem uma camada única de verdade, e o esforço deixa de ser reconciliar planilhas para virar análise de fato.

Perguntas frequentes#

Por que não usar o próprio core bancário como fonte direta do Power BI?

Porque o core é otimizado para transação, não para análise. Consultá-lo direto com relatórios pesados concorre com a operação, degrada performance dos dois lados e não reconcilia fontes diferentes. O data warehouse existe para criar uma camada analítica isolada, modelada para leitura e sem impactar o sistema que roda o dia a dia.

Preciso de três tabelas fato mesmo, ou uma só resolve?

Depende das perguntas do negócio, mas raramente uma só resolve no financeiro. Transação, contrato e parcela têm grãos diferentes e se comportam de forma diferente no tempo. Forçar tudo em uma tabela gera métricas que se somam errado e análises impossíveis de auditar. Separar por grão é o que mantém os números coerentes quando alguém cruza carteira com inadimplência.

Onde a LGPD entra na arquitetura, na prática?

Em várias camadas. Na prata, decidindo o que anonimizar ou agrupar antes de o dado seguir adiante. Na ouro, controlando o que cada perfil enxerga com segurança em nível de linha. E na governança, mantendo linhagem e registro de acesso para responder a titulares e a auditorias. A LGPD não é um módulo separado, é um conjunto de decisões distribuídas pelo desenho do warehouse.

Direct Lake substitui o modo Import de vez?

Não em todos os casos, mas resolve a maioria dos cenários de alto volume. O Direct Lake lê direto do OneLake sem importar e sem o custo de consulta do DirectQuery, com atualização quase imediata e boa performance. Ainda há situações que pedem Import, então a escolha é técnica e depende do caso.

Como escolher o tamanho da capacidade no Fabric?

Medindo. As capacidades vão do F2 ao F2048 e são cobradas por Capacity Units. O certo é estimar a carga de processamento das cargas de dados e o consumo dos relatórios, começar em um tamanho razoável e ajustar conforme o uso real, em vez de chutar alto por segurança ou baixo por economia. Revisar periodicamente é parte do trabalho, não um evento único.

Quanto tempo leva para estruturar um data warehouse financeiro do zero?

Varia com o número de fontes, a qualidade dos dados de origem e o escopo. O que encurta o caminho é começar por um recorte de valor, como a análise de inadimplência ou de carteira, entregar as camadas medalhão para esse recorte e expandir depois. Tentar modelar tudo de uma vez atrasa a primeira entrega que importa e cansa o patrocínio do projeto.

Onde começar#

Um data warehouse financeiro bem estruturado não é luxo de área técnica, é o que separa decisão baseada em dado confiável de decisão baseada em achismo com aparência de gráfico. Comece pelo grão dos fatos, imponha as camadas medalhão desde o primeiro dia e trate governança e LGPD como premissa, não como acabamento. O resto, ferramenta e capacidade, é consequência de um bom desenho.

Se você quer estruturar essa base com quem já entregou milhares de soluções Microsoft em ambientes regulados, fale com a gente.