Construindo uma Plataforma de Dados do Zero: Um Guia de Campo

Uma empresa de logística em crescimento acelerado no Brasil. Receita dobrando ano após ano. Equipe de engenharia com quarenta pessoas. E nenhum dashboard em que alguém confiasse.

Quando cheguei, os dados da empresa viviam em quatro sistemas separados: um banco de dados relacional sustentando o produto principal, um document store com informações de motoristas e rotas, arquivos planos exportados de uma ferramenta legada de gestão de armazém e uma plataforma de análise de terceiros que ninguém mantinha. O CEO tomava decisões perguntando o mesmo número para três pessoas diferentes e tirando a média das respostas. A equipe de operações rodava relatórios exportando CSVs e colando em planilhas. O financeiro reconciliava a receita na mão todo mês porque dois sistemas nunca concordavam sobre o total.

Não havia time de dados. Nem Data Warehouse. Nem pipelines. Nem orquestração. Nem monitoramento. A empresa havia crescido de 10 para 200 funcionários em três anos, e a infraestrutura de dados não havia crescido nada.

Meu trabalho era construir uma plataforma de dados do zero. Não avaliar fornecedores nem escrever um deck de estratégia. Construir de fato — arquitetura, implementação, pipelines, modelos, dashboards — e depois entregar para o time que a manteria depois da minha saída.

Foi isso que aprendi. Não a teoria, mas o guia de campo: as decisões que importam, a ordem que realmente funciona e os erros que todos cometem (inclusive eu).

A primeira pergunta: você precisa mesmo de uma plataforma?

Antes de projetar qualquer coisa, você precisa responder honestamente se uma plataforma de dados é a solução certa. Nem toda empresa precisa de uma. Uma plataforma introduz complexidade — pipelines para manter, infraestrutura para monitorar, esquemas para evoluir, pessoas para contratar. Se a sua necessidade real é "um dashboard para o CEO", talvez você seja melhor atendido por uma ferramenta de BI conectada diretamente ao seu banco de produção com uma réplica de leitura.

Aqui está o framework de decisão que uso:

A empresa de logística marcava todas as caixas. Quatro fontes heterogêneas. Líderes de negócio pedindo análises diariamente. Volumes de dados crescendo 40% a cada trimestre. E um CTO comprometido, pronto para contratar um engenheiro de dados assim que a plataforma estivesse construída. Então construímos.

Arquitetura: as quatro camadas

Toda plataforma de dados que construí — e foram várias — converge na mesma arquitetura de quatro camadas. Não porque seja teoricamente elegante, mas porque é a estrutura mais simples que resolve os problemas reais que você vai enfrentar.

O Lake: sua apólice de seguro

O lake armazena dados brutos exatamente como chegaram dos sistemas-fonte. Sem transformações, sem limpeza, sem modelagem. Apenas cópias imutáveis, append-only. Essa é a sua apólice de seguro. Quando (não se) você descobrir que uma transformação estava errada, ou que uma regra de negócio mudou retroativamente, ou que alguém precisa de dados que você não achava importantes seis meses atrás, o lake permite voltar ao original e recalcular tudo.

Já vi times pularem o lake para economizar tempo. Todos, sem exceção, se arrependeram em seis meses. O custo de armazenar dados brutos é irrisório comparado ao custo de perdê-los.

O Warehouse: a fonte única de verdade

O warehouse contém tabelas analíticas modeladas, testadas e documentadas. É aqui que os dados brutos se tornam úteis — limpos, unidos, enriquecidos e moldados para perguntas de negócio. Quando alguém pergunta "qual foi a receita do mês passado?", deve haver exatamente um lugar para olhar, e a resposta deve ser a mesma independentemente de quem consulte.

Estruturo o warehouse em três zonas: staging (cópias limpas das tabelas de origem), intermediate (joins e cálculos de lógica de negócio) e marts (tabelas finais otimizadas para domínios específicos de negócio). Esse padrão staging-intermediate-mart não é original, mas funciona porque torna a lógica de transformação rastreável. Quando um número parece errado, você pode caminhar de trás para frente do mart até a tabela de staging e encontrar exatamente onde a lógica divergiu da realidade.

Orquestração: o sistema nervoso

A orquestração cuida de agendamento, dependências, monitoramento e alertas. É a camada que garante que os dados fluam pela plataforma com confiabilidade e que alguém saiba quando eles não fluem. Na empresa de logística, começamos com um orquestrador de workflow simples — nada exótico. A chave foi acertar o gerenciamento de dependências: uma tabela de mart não deve atualizar até que toda tabela de staging da qual ela depende tenha carregado com sucesso.

Análise: onde o valor é entregue

A camada de análise é onde os usuários de negócio interagem com os dados. Dashboards, relatórios, queries ad-hoc, exploração self-service. Essa é a única camada que o negócio realmente vê, o que a torna a única camada com que ele se importa. Tudo abaixo existe para tornar essa camada confiável e rápida.

Por que a ordem importa? Porque cada camada depende da camada de baixo. Você não consegue modelar tabelas de warehouse sem dados brutos no lake. Você não consegue construir dashboards confiáveis sem tabelas modeladas no warehouse. E você não consegue rodar nada disso sem a orquestração mantendo o pipeline vivo. As camadas não são só organizacionais — são uma cadeia de dependência.

A sequência de construção que realmente funciona

Aqui está o maior erro que vejo em plataformas de dados greenfield: construir de baixo para cima. O time gasta três meses construindo uma camada de lake abrangente. Depois dois meses modelando o warehouse. Aí finalmente conectam uma ferramenta de BI e mostram um dashboard para o negócio. Cinco meses depois, o negócio vê valor pela primeira vez, e metade dos modelos está errada porque ninguém validou contra perguntas reais.

A abordagem certa é uma fatia vertical. Comece com uma pergunta de negócio — aquela que causa mais dor — e construa o caminho mais fino possível da fonte até o dashboard. Um sistema-fonte. Uma tabela do lake. Um modelo no warehouse. Um dashboard. Prove valor na semana dois, não no mês três. Depois amplie.

Na empresa de logística, a primeira fatia foi custo de entrega por rota. A COO passava duas horas toda segunda-feira de manhã calculando isso à mão a partir de exportações de planilhas. Conectamos o banco relacional (uma fonte), carregamos as tabelas de pedidos e rotas no lake, construímos um modelo no warehouse que fazia o join com os dados de custo e colocamos um dashboard na frente dela. Duas semanas. Naquela segunda-feira, ela tinha o número em 30 segundos em vez de duas horas.

Essa primeira vitória comprou tudo: patrocínio executivo, paciência do time, orçamento para a próxima fatia. Na semana quatro tínhamos três fatias rodando. Na semana oito, a plataforma cobria os quatro sistemas-fonte e o financeiro estava usando no fechamento mensal.

A abordagem horizontal teria entregue a mesma plataforma — eventualmente. Mas a abordagem vertical entregou valor continuamente, validou nossos modelos contra perguntas reais e construiu a confiança organizacional que nos permitiu tomar decisões mais ousadas depois.

Migração: a parte difícil sobre a qual ninguém te avisa

Diagramas de arquitetura são limpos. Migração é uma bagunça. Mover dados de quatro sistemas-fonte heterogêneos para uma plataforma unificada — sem interromper a operação — é onde a maior parte do trabalho de verdade acontece. E é onde estão as lições mais dolorosas.

Eis o que aprendi migrando os dados da empresa de logística:

Extração incremental é inegociável

Nunca faça full-scan em um banco de produção a cada execução do pipeline. Extraia apenas o que mudou desde a última execução usando timestamps, CDC ou replicação baseada em log. Full scans funcionam no dia um, quando você está carregando o histórico. Depois disso, eles vão acabar com a performance do seu sistema-fonte e com o tempo de execução do seu pipeline. Na empresa de logística, a tabela de pedidos tinha 40 milhões de linhas. Um full scan levava 90 minutos e causava latência visível no produto. A extração incremental levava 30 segundos.

Pipelines idempotentes salvam sua sanidade

Todo pipeline precisa produzir o mesmo resultado seja executado uma vez ou dez. Isso significa apagar-e-substituir por partição, não appends cegos. Quando um pipeline falha pela metade (e ele vai), você precisa ser capaz de reexecutá-lo sem criar duplicatas. O sistema legado da empresa de logística não tinha timestamps confiáveis, o que significava que não dava para fazer extração incremental de verdade. Em vez disso, fazíamos snapshots diários completos com idempotência em nível de partição: cada execução substituía a partição inteira do dia, então reexecuções eram seguras.

Mapeamento de esquema é o trabalho intelectual

Conectar em um banco e copiar tabelas é a parte fácil. A parte difícil é entender o que os dados significam. O banco relacional da empresa de logística tinha uma coluna chamada status na tabela de pedidos com valores de 1 a 7. Sem documentação. O desenvolvedor original havia saído dois anos antes. Foram três dias lendo código da aplicação e entrevistando o pessoal de operações para montar um mapeamento completo. Multiplique isso por cada tabela em quatro sistemas-fonte e você entende por que cronogramas de migração sempre estouram as estimativas.

Validação de dados captura o que testes não conseguem

Testes automatizados verificam se as transformações funcionam corretamente. A validação de dados verifica se os próprios dados fazem sentido. Checks de contagem de linhas (carregamos mais ou menos o mesmo número de linhas que ontem?), monitoramento de taxa de nulos (uma coluna que normalmente está 99% preenchida caiu de repente para 80%?), checks de intervalo (há valores negativos em um campo que deveria ser sempre positivo?). Pegamos uma mudança de esquema no document store três horas depois dela ter acontecido porque nosso monitor de taxa de nulos disparou. Sem isso, só teríamos descoberto o problema quando o dashboard da COO mostrasse números errados — provavelmente na segunda-feira de manhã.

A questão do time: quem mantém isso depois que você sai?

Uma plataforma de dados sem um time para mantê-la é uma bomba-relógio. Funciona muito bem por três meses, aí o primeiro sistema-fonte muda seu esquema, um pipeline quebra, ninguém sabe consertar, e o negócio volta para as planilhas.

Na empresa de logística, a questão do time foi a parte mais difícil do engajamento — mais difícil que a arquitetura, mais difícil que a migração. Eis o que aprendi:

Você precisa de pelo menos uma pessoa desde o dia um

Mesmo que a empresa não esteja pronta para contratar um time de dados completo, um engenheiro precisa estar embarcado na construção da plataforma desde o início. Não revisando PRs depois do fato. Pair programming, tomando decisões em conjunto, entendendo o porquê das coisas terem sido desenhadas daquele jeito. Na empresa de logística, tínhamos um engenheiro backend que dedicava 50% do tempo à construção da plataforma. Na semana seis, ele já depurava falhas de pipeline sozinho. Na semana doze, conseguia construir novos pipelines do zero.

Documentação é a entrega

Registros de decisões de arquitetura para cada escolha significativa. Runbooks para cenários de falha comuns. Um dicionário de dados para cada tabela do warehouse. Um guia de monitoramento explicando o que cada alerta significa e como responder. Escrevi tudo isso enquanto construíamos, não depois. A documentação era o sistema imunológico da plataforma — a coisa que a manteve viva depois que saí.

A primeira contratação certa é um analytics engineer, não um data engineer

Isso é contraintuitivo. A plataforma precisa de engenharia de dados para rodar, mas o que o negócio precisa é de alguém que saiba construir novos modelos no warehouse e novos dashboards. Um analytics engineer que sabe escrever SQL, construir modelos e conversar com stakeholders de negócio entrega mais valor contínuo do que um data engineer otimizando performance de pipeline. Contrate o analytics engineer primeiro. A infraestrutura deveria ser estável o suficiente para não precisar de atenção diária de engenharia — se precisar, você construiu errado.

O que eu adicionaria hoje: uma base de conhecimento

Se eu estivesse construindo hoje a plataforma daquela empresa de logística, adicionaria um quinto componente que não existia no meu design original: uma base de conhecimento estruturada.

Toda plataforma greenfield gera uma quantidade enorme de conhecimento institucional: por que escolhemos este warehouse e não aquele, o que significam os valores da coluna status, como o formato de exportação do sistema legado muda durante o fechamento mensal, o que acontece quando o lag de replicação do document store passa de 30 segundos. Esse conhecimento vive na cabeça das pessoas, em threads do Slack, em documentação espalhada que ninguém mantém.

Uma base de conhecimento captura tudo isso num formato estruturado, pesquisável e cruzado. Não uma wiki que humanos precisam manter (porque eles não vão). Uma base de conhecimento mantida por um LLM, onde você joga documentos-fonte — registros de decisões de arquitetura, postmortems, notas de reunião, documentação de esquema — e o LLM constrói e mantém uma wiki estruturada com pontuação de confiança, detecção de contradições e referências cruzadas.

Por que isso importa especificamente para plataformas greenfield:

• Onboarding — quando a primeira contratação de dados chega e eu saio, ela não precisa fazer engenharia reversa de cada decisão. A base de conhecimento tem registros de decisões de arquitetura explicando por que o warehouse está estruturado assim, por que usamos idempotência em nível de partição em vez de merge, por que o sistema legado recebe um snapshot diário completo em vez de extração incremental.
• Debugging — quando um pipeline quebra às 3 da manhã, a base de conhecimento tem os padrões de falha: "Quando a taxa de nulos do document store sobe acima de 5% na tabela de motoristas, verifique lag de replicação upstream antes de investigar o pipeline." Esses padrões são invisíveis no código, mas críticos para a operação.
• Evolução — quando o negócio pedir uma nova fonte de dados seis meses depois da minha saída, a base de conhecimento tem o playbook de integração: como abordamos cada fonte anterior, quais eram as armadilhas comuns, como eram os padrões de extração. O próximo engenheiro não começa do zero — começa da experiência acumulada da construção.

Escrevi sobre isso em detalhes em A Estratégia da Base de Conhecimento, e abri o código de um template que você pode usar: knowledge-base-template. Se você está construindo uma plataforma de dados, construa a memória dela junto. Ambas compõem.

A conclusão

Construir uma plataforma de dados do zero é uma das coisas de maior impacto que você pode fazer por uma empresa em crescimento. Ela transforma a tomada de decisão de intuição em evidência, de planilhas mensais em dashboards em tempo real, de números conflitantes em uma fonte única de verdade.

Mas os detalhes importam mais do que a ambição. Eis o que eu diria a qualquer um começando essa jornada:

• Não construa até ter certeza de que precisa. Uma ferramenta de BI com conexões diretas é suficiente para muitas empresas. Uma plataforma introduz complexidade que você terá que manter para sempre.
• Comece com uma fatia vertical, não com uma fundação horizontal. Uma fonte, uma pergunta, um dashboard. Prove valor na semana dois. Amplie a partir daí.
• A arquitetura de quatro camadas funciona. Fontes, lake, warehouse, análise. Não é a única forma, mas é a arquitetura mais simples que lida com a complexidade do mundo real sem superengenharia.
• Migração é a parte difícil. Orce o dobro do tempo que você acha. Mapeamento de esquema, validação de dados e lidar com as idiossincrasias dos sistemas-fonte é onde a engenharia de verdade acontece.
• Planeje o time desde o dia um. A plataforma precisa sobreviver à sua saída. Embarque alguém cedo, documente sem parar, contrate um analytics engineer antes de um data engineer.
• Construa a base de conhecimento junto com a plataforma. Cada decisão, cada falha, cada idiossincrasia de esquema — capture tudo. A plataforma e sua memória institucional compõem juntas.

A arquitetura mais simples que atende às necessidades atuais com pontos claros de extensão. Não projete para a escala do Google no dia um. Projete para os próximos doze meses, com costuras limpas por onde o seu eu do futuro possa estender. As empresas que acertam em dados não constroem as maiores plataformas — constroem as do tamanho certo, e as constroem com a sabedoria de evoluir.