📊 A Diferença de Dados por Estágio de Empresa
Os dados de uma empresa contam a história do seu crescimento. Startup, PME em crescimento e enterprise têm dados radicalmente diferentes — não apenas em volume, mas em estrutura, qualidade e complexidade. A abordagem de engenharia precisa mudar em cada estágio.
Startup — Simplicidade máxima
1-50 funcionáriosCaracterísticas dos dados
- • Google Sheets como banco de dados
- • CSVs exportados manualmente
- • Sem schema definido
- • Colunas crescem conforme a necessidade
Abordagem correta
- • Scripts Python rápidos
- • DuckDB para análise
- • Criar o data dictionary primeiro
- • Não over-engineer
PME com funding — Caos do crescimento
50-500 funcionáriosCaracterísticas dos dados
- • Cresceu de 100 para 1000 funcionários
- • Dados refletem o caos: 5 sistemas, 3 CRMs
- • IDs duplicados entre sistemas
- • "Cliente ativo" tem 4 definições diferentes
Abordagem correta
- • Auditoria extensa antes de qualquer análise
- • Definir um "sistema de verdade" único
- • Data dictionary como primeiro entregável
- • Pipeline de limpeza antes de qualquer modelo
Enterprise — Processos e compliance
500+ funcionáriosCaracterísticas dos dados
- • Oracle, SAP, sistemas proprietários
- • Times de TI e Data Engineering dedicados
- • Dados regulatórios e de compliance
- • Data dictionary geralmente existe
Abordagem correta
- • Seguir os processos existentes
- • Entender o ecosistema antes de propor mudanças
- • Compliance é não-negociável
- • Qualidade dos dados é geralmente melhor
🏚️ Sistemas Legados: Oracle, SAP e Migrações
Migrações de sistemas legados são os projetos mais complexos e arriscados de dados. Oracle e SAP têm esquemas proprietários com décadas de customizações, dados que refletem regras de negócio não escritas em lugar nenhum, e integrações que "apenas funcionam" sem que ninguém saiba exatamente como.
Os 3 pesadelos de uma migração enterprise
1. Regras de negócio implícitas nos dados
Um campo "status" com valores A, B, C, D, E. Ninguém lembra o que B significa — o engenheiro que criou saiu há 5 anos. A documentação existe mas está errada. Você vai descobrir o que B significa quando o cliente reclamar que algo quebrou na migração.
2. Customizações do SAP/Oracle
O SAP standard tem 1000 tabelas. A customização desta empresa tem mais 300 tabelas Z* criadas ao longo de 20 anos. Cada uma resolve um problema de negócio específico, com lógica que não existe em nenhum manual.
3. "Não pode parar"
O sistema legado processa R$50M/mês em transações. Não existe janela de manutenção longa o suficiente para fazer uma migração big-bang. Tudo tem que ser feito em shadow mode: os dois sistemas rodando em paralelo, comparando resultados, por meses.
💡 A abordagem correta para migrações
Shadow mode + migração incremental. Nunca big-bang em sistemas críticos:
- 1. Mapear 100% do schema de origem com data dictionary
- 2. Rodar os dois sistemas em paralelo (shadow mode) por 30-90 dias
- 3. Comparar outputs automaticamente a cada ciclo
- 4. Migrar módulos menores primeiro — aprender com o low-risk
- 5. Ter rollback plan testado antes de cada fase
🔒 SOC 2 Compliance e Engenharia de Dados
SOC 2 é um framework de certificação de segurança que certifica como uma organização gerencia dados de clientes. Para o engenheiro de dados, SOC 2 não é apenas segurança — é uma mudança completa na forma como dados são processados, armazenados e auditados.
O que muda com SOC 2
Audit Trail obrigatório
Cada acesso a dados sensíveis precisa ser registrado: quem acessou, quando, o que foi feito. Logs imutáveis, por no mínimo 1 ano.
Access Control rigoroso
Principle of least privilege: cada pessoa acessa apenas o que precisa para seu trabalho. Nenhum acesso "só por precaução".
Dados pessoais isolados
PII (Personally Identifiable Information) precisa ser isolado, criptografado, com acesso controlado e auditado separadamente.
Mudanças versionadas
Toda mudança em schema, pipeline ou configuração de dados precisa passar por change management com aprovação e reversão documentada.
O sinal dos dados: antes e depois do SOC 2
Empresas que foram de não-compliance para SOC 2 terão dados drasticamente diferentes antes e depois. Essa transição aparece nos dados de formas claras:
- • Campos de PII passam a ter hash ou pseudonymização
- • Tabelas de acesso e log aparecem nos schemas
- • Campos de audit (created_by, updated_by, timestamp) tornam-se obrigatórios
- • Dados históricos pré-SOC2 podem ter qualidade diferente
Se você está auditando dados de uma empresa que passou por essa transição, esteja preparado para tratar os dois períodos separadamente.
🌊 Big Data Real: Apache Spark
Apache Spark é intimidador, finicky, e caro de operar. Para a maioria dos projetos, DuckDB é suficiente — e muito mais simples. Mas quando o volume real exige, Spark é a única ferramenta adequada.
Quando Spark é realmente necessário
Indicadores de que você precisa de Spark:
- •Dataset não cabe em memória de uma única máquina (>32GB)
- •Processamento em tempo real de streams de alta frequência
- •Joins de múltiplos datasets de bilhões de linhas
- •ML em escala com feature engineering pesado
Quando DuckDB resolve (a maioria):
- •Análise de arquivos CSV/Parquet de até centenas de GB
- •Queries ad-hoc e dashboards
- •Text-to-SQL em datasets do mundo real
- •Auditoria de dados e validação de qualidade
Caso real: Coca-Cola e 10 bilhões de linhas
Foi a primeira vez na minha vida que tive que lidar com esse volume. Intimidador. Cada query demorava minutos. DuckDB não funcionaria — não teria memória suficiente nem na máquina mais potente. Spark distribuído em cluster foi a única opção viável. Mas esse projeto foi exceção — 99% dos projetos em que trabalhei não chegaram nem perto desse volume.
A lição: não aprenda Spark "por precaução". Aprenda quando o problema real exigir. O overhead de configuração e manutenção não vale o custo se DuckDB resolve.
⚠️ O custo real do Spark
Mergulhe em Apache Spark apenas se o volume exigir. É intimidador, finicky, e caro de operar. Um cluster Spark bem configurado para produção custa facilmente R$20-100k/mês em infraestrutura. Mais o tempo de um engenheiro dedicado para mantê-lo. Para a maioria dos projetos, DuckDB é suficiente — e custa a infraestrutura de uma única máquina.
🗄️ NoSQL vs SQL — Quando Cada Um Faz Sentido
NoSQL surgiu quando aplicações web precisavam de schemas que evoluíam sem planejamento. É o YOLO de dados — cresce conforme os dados crescem, sem migration, sem schema fixo. SQL domina quando você precisa de consistência, joins e transações. A maioria dos projetos analíticos usa SQL.
NoSQL — quando faz sentido
- ✓Schema evolui frequentemente (features de produto em desenvolvimento)
- ✓Dados hierárquicos ou aninhados (JSON nativo)
- ✓Escala horizontal massiva com escrita intensiva
- ✓Cache e sessões (Redis)
- ✓Busca full-text (Elasticsearch)
SQL — quando faz sentido
- ✓Analytics e relatórios com joins complexos
- ✓Dados financeiros com integridade transacional
- ✓Schema estável e bem definido
- ✓Text-to-SQL (o agente gera SQL, não queries NoSQL)
- ✓Compliance e auditoria (registros imutáveis)
O padrão híbrido mais comum em enterprise
A maioria das empresas médias e grandes usa os dois:
- → NoSQL (MongoDB/DynamoDB): Para a aplicação transacional — registros de usuário, sessões, configurações
- → SQL (PostgreSQL/Redshift): Para analytics — dados normalizados, agregações, relatórios
- → ETL entre os dois: Pipeline que migra dados do NoSQL para SQL periodicamente para análise
O engenheiro de dados geralmente está nos dois pontos — e no ETL entre eles.
🎯 O que Esperar ao Entrar em um Projeto Enterprise
O choque cultural de quem vem de startups é real. Processos que parecem burocracia excessiva existem por razões legítimas. Entender isso antes de entrar acelera a adaptação e evita atritos desnecessários com times que simplesmente estão seguindo regras que protegem a empresa.
O que vai acontecer na primeira semana
Reuniões de alinhamento antes de tocar em qualquer dado
Você não vai abrir um terminal na primeira semana. Vai entender quem são os stakeholders, qual o escopo, quais dados estão no scope.
Acesso controlado por tickets
Para acessar qualquer dado, você abre um ticket. O ticket vai para aprovação do data owner, que vai para o time de segurança, que vai para o CISO. Pode levar 2-3 semanas. Planeje.
Documentação obrigatória de tudo
Cada análise que você faz precisa ser documentada. Cada script precisa de comentários. Cada pipeline precisa de runbook. Isso não é burocracia — é o que permite que outra pessoa mantenha seu trabalho quando você sair.
Dados de qualidade muito melhor
A compensação: enterprise tem times dedicados que garantem qualidade. Você vai encontrar o data dictionary pronto. O schema vai estar documentado. Os dados vão estar mais limpos do que qualquer PME que você trabalhou.
Aprovações em múltiplos níveis para mudanças
Quer alterar uma query em produção? Tem que passar por code review, QA, staging, change advisory board. O que levaria 10 minutos em startup pode levar 2 semanas. Ajuste as expectativas do cliente.
💡 A mentalidade correta para projetos enterprise
Não tente mudar a cultura. Entenda por que ela existe e trabalhe dentro dela. Os processos lentos protegem sistemas que processam bilhões de reais. Cada aprovação que parece desnecessária é o resultado de um incidente real que aconteceu antes de você chegar. Respeite o processo — e entregue valor dentro dele.
✅ Resumo do Módulo
🎓 Você completou a Trilha 3 — Visão Avançada!
Nesta trilha você aprendeu: