Guia completo de engenharia de dados no Brasil: data warehouse, pipelines, lakehouse, BI e LGPD

O que este guia cobre

Toda empresa acima de um certo tamanho descobre a mesma coisa: os dados existem, estão espalhados em dez sistemas, e ninguém consegue responder a uma pergunta simples da diretoria sem passar dois dias montando planilha. Engenharia de dados é a disciplina que resolve isso. Ela pega dado bruto espalhado e o transforma em algo confiável, atualizado e pronto para decisão. Feita bem, ninguém percebe que existe. Feita mal, a empresa toma decisão errada com número errado e nem sabe.

Escrevi este guia para quem precisa estruturar dados numa empresa brasileira e não tem paciência para buzzword de fornecedor de nuvem. O conteúdo vem de projetos que a Bradata entregou, incluindo migrações de bilhões de linhas, e de conversas com diretores que já queimaram orçamento em data lake que virou pântano. Vou tratar do que é um data warehouse e qual escolher, de pipelines ETL e ELT, do modelo lakehouse, de BI, de governança e LGPD, de migração em escala e do custo real de cada decisão.

É um texto longo. Use os títulos para ir direto ao ponto que interessa.

Por que dados espalhados custam caro

Antes da solução, vale enxergar o problema com honestidade. Numa empresa que cresceu sem estratégia de dados, cada área tem sua fonte de verdade. O comercial olha o CRM, o financeiro olha o ERP, o marketing olha a plataforma de campanha, a operação olha uma planilha. Cada número está certo dentro do seu sistema e errado em relação aos outros, porque ninguém definiu qual é o número oficial.

O sintoma clássico: a diretoria pede o faturamento do mês e recebe três valores diferentes de três áreas. Cada um defende o seu, ninguém está mentindo, e a reunião vira debate sobre planilha em vez de decisão sobre negócio. O custo disso não aparece na fatura da nuvem. Aparece em decisão adiada, em oportunidade perdida e em confiança corroída no próprio dado.

Engenharia de dados resolve isso criando uma camada única onde o dado de todos os sistemas é reunido, limpo, reconciliado e servido com uma definição só. É a diferença entre dez fontes de verdade e uma.

Data warehouse: o repositório central de decisão

O data warehouse é o coração da operação de dados. É um banco desenhado não para rodar a operação, mas para responder pergunta analítica sobre ela. Ele reúne o dado de todos os sistemas, organizado para consulta rápida em cima de grandes volumes históricos.

A diferença entre o banco que roda o sistema e o data warehouse é de propósito. O banco transacional é otimizado para gravar uma venda por vez, rápido e seguro. O data warehouse é otimizado para ler milhões de vendas de uma vez e somar, agrupar e comparar. Rodar análise pesada no banco de produção derruba o sistema. É para isso que o warehouse existe: separar a carga analítica da operacional.

No Brasil, em 2026, a decisão de data warehouse gira em torno de três nomes de nuvem, mais opções open source. Cada um tem perfil próprio, e a escolha errada custa em conta mensal e em retrabalho.

Data warehouse	Perfil	Onde brilha	Cuidado
Azure Synapse	Integrado ao ecossistema Microsoft	Quem já vive em Azure e Power BI	Custo se descuidar do dimensionamento
Snowflake	Separa storage de processamento	Cargas variáveis, muitos usuários	Fatura por consumo pode surpreender
BigQuery	Serverless, paga por consulta	Volume grande, uso esporádico	Consulta mal escrita custa caro
Databricks	Lakehouse, forte em dado bruto	Ciência de dados e volume massivo	Curva de aprendizado maior

A escolha depende menos de qual é o melhor no papel e mais de onde sua empresa já está e como o dado é consultado. Empresa que já roda Microsoft e usa Power BI tem atrito baixo com o Synapse. Empresa com carga que varia muito ao longo do dia se beneficia da separação de storage e processamento do Snowflake. Empresa com volume enorme e consulta esporádica economiza no modelo por consulta do BigQuery. Comparei os três a fundo, com número de custo e cenário de workload brasileiro, em Synapse, Snowflake e BigQuery: qual data warehouse escolher. Se você está nessa decisão agora, leia antes de assinar qualquer contrato de nuvem.

Pipelines: ETL, ELT e a diferença que importa

O dado não vai sozinho dos sistemas para o warehouse. Alguém precisa extrair, mover, limpar e organizar. Esse trabalho é o pipeline, e é onde vive a maior parte do esforço de engenharia de dados. Duas siglas dominam a conversa: ETL e ELT.

ETL significa extrair, transformar, carregar. Você pega o dado da fonte, transforma e limpa fora do warehouse, e só então carrega o resultado pronto. É o modelo clássico, bom quando a transformação é pesada e o warehouse é caro para processar.

ELT significa extrair, carregar, transformar. Você joga o dado bruto no warehouse primeiro e transforma lá dentro, usando o poder de processamento do próprio warehouse. É o modelo moderno, que ganhou força porque os warehouses de nuvem ficaram poderosos e baratos para processar. Ele tem a vantagem de guardar o dado bruto, o que permite refazer a transformação quando a regra muda sem reextrair da fonte.

Aspecto	ETL	ELT
Onde transforma	Fora do warehouse	Dentro do warehouse
Guarda o dado bruto	Geralmente não	Sim
Refazer transformação	Reextrai da fonte	Reprocessa o que já está lá
Melhor quando	Transformação pesada, warehouse caro	Warehouse potente, regra muda muito
Ferramentas comuns	Ferramenta de ETL dedicada	dbt e o próprio warehouse

A escolha entre os dois não é religião. Depende do custo de processamento do seu warehouse e de quão instável é a regra de negócio. Empresa cuja definição de métrica muda toda hora ganha com ELT, porque refaz a transformação sem tocar na fonte. O ponto crítico em qualquer dos dois é a confiabilidade: um pipeline que quebra silenciosamente e entrega dado desatualizado é pior que não ter pipeline, porque a diretoria decide achando que o número está fresco.

Um pipeline sério tem monitoramento, alerta quando falha, e um jeito de saber se o dado de hoje já chegou. Sem isso, você tem um cano que às vezes entope e ninguém percebe até a reunião dar errado.

Lakehouse: juntando o data lake e o warehouse

Por anos houve duas escolas. O data warehouse, estruturado e caro, bom para dado organizado. E o data lake, um repositório barato que guarda qualquer coisa, do CSV ao log de aplicação, sem estrutura rígida. O data lake resolvia o custo mas virava pântano com frequência: dado jogado sem catálogo, sem qualidade, que ninguém conseguia usar.

O lakehouse é a tentativa de juntar o melhor dos dois. Ele guarda dado bruto barato como um data lake, mas com uma camada de estrutura, catálogo e governança por cima, como um warehouse. Na prática, você tem o custo de armazenamento do lake com a confiabilidade de consulta do warehouse. Databricks empurrou muito esse modelo, e os warehouses tradicionais foram incorporando características de lakehouse.

Vale para quem tem volume grande de dado semiestruturado, como log, evento e dado de sensor, além do dado tabular do ERP e do CRM. Uma empresa que só precisa analisar venda e financeiro não precisa de lakehouse, um warehouse resolve. Uma empresa que também quer analisar comportamento de usuário, telemetria de frota ou dado de IoT ganha com a flexibilidade do lakehouse. Não é a escolha padrão para todo mundo, é a escolha certa quando o tipo de dado extrapola o tabular.

BI: transformar warehouse em decisão

Ter dado organizado no warehouse não gera valor sozinho. Alguém precisa olhar e decidir. Essa é a função do BI, business intelligence, a camada de painéis e relatórios que os humanos consomem. É onde o investimento em dados encontra o usuário final.

As ferramentas dominantes no Brasil são Power BI, muito forte por causa da penetração da Microsoft, Looker e Metabase entre as open source. A escolha importa menos do que a modelagem por trás. Um painel bonito em cima de dado mal modelado mente com confiança, e mentir com gráfico é pior do que não ter gráfico.

O erro mais comum em BI não é técnico, é de propósito. A empresa cria dezenas de painéis que ninguém olha, cada gerente pedindo o seu, e o time de dados vira fábrica de relatório. BI que funciona começa da pergunta de negócio, não do dado disponível. Poucos painéis, respondendo às perguntas que realmente movem decisão, valem mais que cem dashboards que enfeitam a intranet. A disciplina de cortar painel inútil é tão importante quanto a de construir o útil.

Um ponto sobre o self-service. A promessa de que qualquer gestor monta seu relatório sozinho só funciona sobre uma camada de dado bem modelada e governada. Sem isso, cada um monta do seu jeito, com sua definição de faturamento, e voltamos ao problema das três verdades. Self-service sem governança é a fábrica de divergência.

Governança e LGPD: a parte que ninguém quer e todo mundo precisa

Governança de dados é o conjunto de regras sobre quem pode ver o quê, de onde cada dado veio, o que cada campo significa e por quanto tempo o dado é guardado. É a parte menos glamourosa da engenharia de dados e a que evita problema sério, inclusive jurídico.

No Brasil, a LGPD elevou governança de boa prática a obrigação legal. Dado pessoal de cliente e funcionário no warehouse traz responsabilidade concreta: você precisa saber onde o dado está, quem acessa, com que finalidade, e ter como apagá-lo quando a base legal cai. Um data warehouse que copiou dado pessoal de dez sistemas sem controle de acesso e sem catálogo é uma exposição de LGPD esperando para acontecer.

Elemento de governança	O que resolve	Exigência LGPD
Catálogo de dados	Saber o que existe e onde	Mapear dado pessoal
Controle de acesso	Quem vê o quê	Minimizar acesso ao necessário
Linhagem de dados	De onde cada número veio	Rastrear origem e uso
Mascaramento	Esconder dado sensível de quem não precisa	Proteção de dado pessoal
Retenção	Por quanto tempo guardar	Não guardar além do necessário

O ponto prático: governança precisa ser desenhada no início do projeto de dados, não remendada depois. Colocar controle de acesso e mascaramento num warehouse que já tem dado sensível espalhado por todo lado é retrabalho caro e cheio de brecha. Empresa que trata governança como fase final do projeto costuma nunca chegar a ela, e o dado sensível fica exposto por anos.

Migração em escala: mover bilhões de linhas sem parar a operação

Chega o momento em que a empresa decide mover de um banco antigo, de um data warehouse legado ou de uma dúzia de planilhas para uma plataforma de dados moderna. Quando o volume é grande, isso deixa de ser cópia de arquivo e vira projeto de engenharia sério.

Os desafios são concretos. O volume, porque mover bilhões de linhas leva tempo e a operação não pode parar durante a migração. A qualidade, porque dado legado carrega décadas de informalidade, campo preenchido errado, duplicado, encoding quebrado. A reconciliação, porque depois de mover você precisa provar que o dado novo bate com o antigo, linha por linha, senão ninguém confia. E o corte, o momento de virar a chave do sistema antigo para o novo sem perder transação no meio.

A estratégia que funciona raramente é o big bang, virar tudo de uma vez num fim de semana. Migração em escala costuma ser incremental: você move o histórico primeiro em lote, mantém os dois sistemas sincronizados por um período, valida a reconciliação, e só então corta. É mais lento e muito mais seguro. Vivemos isso num projeto de migração de 4 bilhões de linhas para Azure Synapse, com os problemas reais de volume, reconciliação e corte que descrevi em como migramos 4 bilhões de linhas para Azure Synapse. Quem vai encarar uma migração grande vai achar lá os detalhes que ninguém conta antes.

O custo real de uma operação de dados

Dado moderno tem custo em três frentes que se somam, e a maioria só enxerga uma.

A primeira é a nuvem: armazenamento e processamento. Aqui mora a surpresa mais comum, a fatura que explode porque alguém escreveu uma consulta ruim que varre o warehouse inteiro, ou porque o dimensionamento ficou generoso demais e roda ocioso pagando. A conta de nuvem em dados é controlável, mas exige disciplina de otimização de consulta e de dimensionamento. Sem isso, o warehouse barato do papel vira caro no boleto.

A segunda é a ferramenta: licença de BI, de ETL, de catálogo. Cada uma cobra por usuário ou por consumo, e a soma cresce sem barulho. A terceira, e a maior, é gente: engenheiro de dados é caro e escasso no Brasil, e a operação de dados precisa de manutenção contínua, porque pipeline quebra, regra muda, fonte nova aparece.

Frente de custo	Peso típico	Onde estoura
Nuvem (storage e processamento)	25% a 40%	Consulta ruim, dimensionamento generoso
Ferramentas (BI, ETL, catálogo)	15% a 25%	Licença por usuário se multiplicando
Pessoas (construção e manutenção)	40% a 55%	Escassez e rotatividade de engenheiro

O erro de orçamento clássico é achar que o projeto de dados termina quando o warehouse entra no ar. Ele não termina, ele começa. A operação de dados é contínua, e empresa que orça só a construção descobre tarde que não tem quem mantenha. É por isso que muitas escolhem terceirizar a engenharia de dados com um parceiro que constrói e sustenta, em vez de montar e perder um time inteiro que o mercado paga mais para levar embora. A software house da Bradata atua nesse modelo, construindo a plataforma de dados e mantendo o pipeline rodando.

Perguntas frequentes

Qual data warehouse é o melhor? Não existe o melhor absoluto, existe o certo para o seu caso. Empresa já em Azure com Power BI tem atrito baixo no Synapse. Carga que varia muito ao longo do dia ganha com Snowflake. Volume enorme com uso esporádico economiza no modelo por consulta do BigQuery. A escolha depende de onde você já está e de como o dado é consultado, não de ranking de fornecedor. Faça a conta com o seu padrão de uso.

ETL ou ELT, qual usar? Depende do custo de processamento do seu warehouse e de quão instável é a regra de negócio. ELT guarda o dado bruto e deixa refazer a transformação sem reextrair da fonte, o que é ótimo quando a definição de métrica muda muito. ETL faz sentido quando a transformação é pesada e o warehouse é caro para processar. Muitos projetos modernos usam ELT com dbt, mas não é dogma.

Preciso de data lake, lakehouse ou só warehouse? Se você analisa só dado tabular de ERP e CRM, um warehouse resolve. Se também tem volume grande de log, evento, telemetria ou dado de IoT, o lakehouse dá flexibilidade sem virar pântano como o data lake puro costumava virar. Não adote lakehouse por moda, adote quando o tipo de dado extrapola o tabular e o volume justifica.

A LGPD complica meu projeto de dados? Ela adiciona obrigação, não impede o projeto. Você precisa saber onde há dado pessoal, controlar quem acessa, mascarar o sensível e poder apagar quando a base legal cai. O erro é tratar isso como fase final e nunca chegar lá. Desenhe governança e controle de acesso desde o início, porque remendar depois num warehouse cheio de dado sensível é caro e cheio de brecha.

Quanto custa montar uma operação de dados? Tem três frentes: nuvem, ferramentas e gente. A nuvem é controlável com disciplina de otimização de consulta. As ferramentas cobram por usuário ou consumo. A gente é a maior fatia, porque engenheiro de dados é caro e escasso, e a operação precisa de manutenção contínua. O erro de orçamento é achar que acaba quando o warehouse sobe. Ele começa aí. Orce a manutenção, não só a construção.

Posso migrar bilhões de linhas sem parar a operação? Sim, mas raramente de uma vez. A estratégia segura é incremental: mover o histórico em lote, manter os dois sistemas sincronizados por um período, validar a reconciliação linha por linha e só então cortar. Big bang num fim de semana é tentador e arriscado. Migração grande é projeto de engenharia com reconciliação séria, não cópia de arquivo, e o corte é a parte mais delicada.

Fechamento

Engenharia de dados existe para transformar dado espalhado em decisão confiável. O centro é o data warehouse, alimentado por pipelines confiáveis, servido por BI que responde a perguntas de negócio, protegido por governança que atende à LGPD. O erro caro não é escolher a nuvem errada, é achar que o projeto termina quando o warehouse sobe, quando na verdade a operação de dados é contínua e a manutenção é a maior parte do custo.

Se você quer estruturar dados na sua empresa, do primeiro pipeline à migração de volume grande, a Bradata já entregou plataformas de dados e migrações de bilhões de linhas com reconciliação completa. Fale com a gente para uma conversa sem folheto.