Orçamento de Infraestrutura | Data Lake Costal
costal arquitetura dados orcamento infraestrutura
Para que serve este documento: dar ao Igor uma estimativa de custo mensal do Data Lake Costal (a infraestrutura de dados onde os 26 agentes IA, o BI e os modelos preditivos vão rodar), em formato pronto para entrar no orçamento Costal 2026.
Origem do número: orçamento técnico do Lucas Andrade (Costal Infra), coordenado por Blaschek a pedido do Igor — entregue em 26/04/2026 (PDF original).
O que este documento adiciona ao PDF do Lucas: sumário executivo, recomendação de faseamento, sensibilidade dos custos, gatilhos para subir de cenário e glossário dos termos técnicos.
TL;DR — O que reservar no orçamento
| Cenário | Quando usar | USD/mês (prd+hml) | USD/ano |
|---|---|---|---|
| 1 — Entrada | Mês 1-6 do data lake em operação | 15.858 | 190.296 |
| 2 — Consolidação | Mês 7-12 (após primeira onda de agentes IA) | 24.355 | 292.260 |
| 3 — Escala | Mês 13+ (operação plena com todos os agentes) | 33.121 | 397.452 |
Recomendação para o orçamento 2026 (12 meses): reservar entre US 290 mil/ano — assumindo 6 meses no Cenário 1 + 6 meses no Cenário 2 (= **US 290 mil para acomodar uma migração antecipada para o Cenário 2 ou ajustes nas premissas. Detalhe do faseamento na §4.
Importante: os números acima cobrem apenas o Data Lake (Databricks + AWS S3). Os demais sistemas da Costal (Sienge ERP, RH/folha, gestão de obras, comercial, contratos) são SaaS — o custo de infraestrutura desses sistemas já está embutido no preço da assinatura e não entra aqui.
1. O que é o Data Lake Costal
O Data Lake Costal é a fundação de dados da arquitetura empresarial — onde todos os dados gerados pelos sistemas da Costal (Sienge, RH, comercial, obras) e os dados externos (mercado, governo, parceiros) são consolidados, limpos e disponibilizados para:
- BI e dashboards executivos — relatórios, indicadores, painéis de gestão
- 26 agentes IA Costal — automações que precisam ler e cruzar dados de múltiplos sistemas
- Modelos preditivos — projeção de vendas, alertas de desvio de obra, previsão de caixa
- Inteligência de Mercado Colliers — primeiro caso de uso já em discovery
Por que precisa? O Sienge sozinho não comporta esse papel. O ERP foi desenhado para registrar transações, não para unificar dados não-estruturados (documentos, fotos, e-mails, sensores) nem para servir de base de treinamento de IA. O Data Lake faz isso. Ver Data Lakehouse — Arquitetura para o desenho técnico completo.
A tecnologia escolhida é Databricks rodando sobre AWS (Amazon Web Services) — o padrão de mercado para data lakes corporativos e a plataforma compatível com o restante da arquitetura definida pelo Blaschek (arquitetura empresarial Costal).
2. O que está incluído neste orçamento
| Componente | O que é | Custo nos 3 cenários |
|---|---|---|
| Lakeflow Jobs | Processamento batch — pipelines que lêem dados dos sistemas-fonte (Sienge etc.), limpam e gravam no lake | US$ 540 → 2.430/mês |
| SQL Warehouse | ”Motor de consulta” — o que o BI, os agentes IA e os dashboards usam para ler dados do lake em tempo real | US$ 15.206 → 30.413/mês |
| AWS S3 | Armazenamento dos dados em si (storage), tráfego de saída e operações de leitura/escrita | US$ 112 → 278/mês |
| TOTAL | Infraestrutura completa do Data Lake (prd + hml) | US$ 15.858 → 33.121/mês |
Insight crítico: ~95% do custo é o SQL Warehouse, porque ele fica ligado 24h por dia, 7 dias por semana, atendendo consultas. O processamento batch (Lakeflow) e o storage (S3) são quase irrelevantes em comparação. Qualquer otimização de custo passa por revisar o dimensionamento do SQL Warehouse — ver §6 (sensibilidade).
3. O que NÃO está incluído
Para evitar dupla contagem no orçamento Costal, deixa-se explícito o que NÃO está neste número:
- Sienge ERP — SaaS contratado da Softplan; infraestrutura embutida na mensalidade
- Sistemas SaaS de obras, finanças, compras, RH, comercial, gestão de contratos — infraestrutura embutida no preço de cada SaaS
- Internet, links corporativos, redes — infra de TI tradicional, escopo do Michael (TI Colliers) e do head de TI Costal a definir
- Estações de trabalho, notebooks, licenças de office — escopo do head de TI Costal
- Componentes opcionais Databricks ainda não decididos:
- Machine Learning (treinamento de modelos preditivos próprios) — incluir só quando definirmos quais modelos vamos treinar internamente
- Interactive Workloads / Notebooks (análise ad-hoc de cientistas de dados) — incluir só quando tivermos um time de data science Costal
- Migração inicial de dados (one-time, não recorrente) — orçar à parte
4. Recomendação faseada (12-18 meses)
A volumetria que justifica cada cenário não existe hoje — a Costal está em implantação do Sienge desde 08/04/2026, os agentes IA chegam em 3 ondas e o primeiro caso de uso Lakehouse (Inteligência de Mercado Colliers) ainda está em discovery. Faz sentido começar pequeno e escalar conforme a demanda real apareça.
Linha do tempo proposta
| Período | Cenário | Custo mensal | Justificativa |
|---|---|---|---|
| Mês 1-6 (mai-out/2026) | Cenário 1 | US$ 15.858 | Setup do data lake. Carga inicial Sienge. IM Colliers em desenvolvimento. Primeiros agentes IA da Onda 1 entrando em produção. Volumetria baixa. |
| Mês 7-12 (nov/2026-abr/2027) | Cenário 2 | US$ 24.355 | Onda 1 IA em produção plena. IM Colliers em produção. Onda 2 começa. Mais usuários consultando dashboards. Volumetria média. |
| Mês 13+ (mai/2027 em diante) | Cenário 3 | US$ 33.121 | Onda 2 e Onda 3 IA em produção. Operação plena. Múltiplos heads consultando BI simultaneamente. Volumetria alta. |
Custo total reservado nos 12 primeiros meses
6 × US$ 15.858 = US$ 95.148 (Cenário 1)
6 × US$ 24.355 = US$ 146.130 (Cenário 2)
TOTAL 12 meses = US$ 241.278
Recomendação de provisão orçamentária 2026: US 290 mil/ano — o intervalo cobre o cenário-base + folga para migração antecipada para C2 caso a Onda 1 IA entre antes do esperado.
Gatilhos para mudar de cenário
Em vez de mudar por calendário, é mais saudável mudar por gatilho operacional. Recomenda-se subir de cenário quando dois ou mais dos sinais abaixo aparecerem:
Gatilhos C1 → C2:
- Filas de consulta no SQL Warehouse (usuário espera mais de 30 segundos para o dashboard carregar) recorrentes
- Mais de 50 usuários simultâneos no BI
- Pipelines Lakeflow não fecham na janela noturna de 8 horas
- Volume armazenado ultrapassa 2 TB
Gatilhos C2 → C3:
- Latência de consulta degrada novamente após 30 dias no C2
- Mais de 100 usuários simultâneos
- Pipelines Lakeflow precisam de mais de 10 horas/dia
- Volume armazenado ultrapassa 3 TB
- Início da Onda 3 de agentes IA
Quem monitora os gatilhos? O head de TI Costal (a contratar — papel duplo provável com Michael Sousa Colliers no curto prazo). Recomenda-se review trimestral do Igor com Pedro/Blaschek/head de TI para decidir mudanças de cenário.
5. Detalhamento dos componentes
5.1 Lakeflow Jobs (processamento batch)
O que faz: todo dia, em janelas programadas (tipicamente de madrugada), um pipeline pega dados novos do Sienge e demais fontes, limpa, valida e grava no Data Lake. É o “carregamento noturno” — sem isso, o lake fica desatualizado.
| Cenário | Instâncias EC2 | Horas/dia | USD/mês (1 ambiente) | USD/mês (prd+hml) |
|---|---|---|---|---|
| 1 | 10 | 8 | 270 | 540 |
| 2 | 20 | 10 | 675 | 1.350 |
| 3 | 30 | 12 | 1.215 | 2.430 |
Premissas técnicas: Plano Databricks Premium · Lakeflow Jobs Classic · Instância m5.xlarge (4 vCPUs, 16 GB RAM) · Região N. Virginia · USD 0,1125/hora (já inclui DBU + AWS).
Ordem de grandeza: o componente é proporcional ao volume de dados a processar e ao número de fontes de dados conectadas. Hoje a Costal tem essencialmente uma fonte ativa (Sienge em implantação). Conforme RH, comercial, obras e os 26 agentes IA forem entrando, a janela de processamento e o número de instâncias crescem.
Dimensionamento confortável: o cluster mínimo é 2 servidores (1 driver + 1 worker). Os números acima incluem folga para tarefas auxiliares de manutenção do Databricks (OPTIMIZE, VACUUM, COMPUTE STATISTICS) e otimização automática (cluster on write).
5.2 SQL Warehouse (consulta em tempo real)
O que faz: quando um usuário abre um dashboard de BI ou um agente IA pede dados ao Lakehouse, é o SQL Warehouse que responde a consulta. Diferente do Lakeflow, fica ligado 24/7 porque uma consulta pode chegar a qualquer hora.
| Cenário | Instâncias | USD/mês (1 ambiente) | USD/mês (prd+hml) |
|---|---|---|---|
| 1 | 2 | 7.603 | 15.206 |
| 2 | 3 | 11.405 | 22.810 |
| 3 | 4 | 15.206 | 30.413 |
Premissas técnicas: Plano Databricks Premium · SQL Compute · Configuração Medium · 24h/dia · 30 dias/mês · USD 5,28/hora.
Por que custa tanto: é o componente mais caro porque (a) fica ligado o tempo todo, (b) usa instâncias de máquina mais robustas que os jobs batch, (c) é multiplicado por 2 (prd + hml).
Maior alavanca de economia: se o ambiente de homologação não precisar ficar 24/7 ligado (cenário comum — testes acontecem em horário comercial), pode-se desligar o hml fora do horário comercial e cair de 24/7 (720h/mês) para ~10h × 22 dias úteis = 220h/mês. Economia potencial: ~70% sobre a parte hml = US$ 5.300 a 10.600/mês economizados. Decisão a discutir com o head de TI quando contratado.
5.3 AWS S3 (armazenamento de dados)
O que faz: é onde os dados do data lake ficam fisicamente armazenados. Três cobranças distintas:
5.3.1 Armazenamento
| Cenário | Volume armazenado | USD/mês |
|---|---|---|
| 1 | 2.000 GB (2 TB) | 40 |
| 2 | 3.000 GB (3 TB) | 60 |
| 3 | 4.000 GB (4 TB) | 80 |
USD 0,02/GB · Classe Standard · N. Virginia
5.3.2 Transferência outbound
Dados que saem da AWS — para a internet ou para outras regiões (não cobra inbound).
| Cenário | Volume saída/mês | USD/mês |
|---|---|---|
| 1 | 200 GB | 18 |
| 2 | 300 GB | 27 |
| 3 | 400 GB | 36 |
USD 0,09/GB
5.3.3 Operações
Cada leitura ou escrita no S3 conta como uma “requisição” e tem custo unitário ínfimo:
| Cenário | PUT/COPY/POST/LIST | GET/SELECT | USD/mês |
|---|---|---|---|
| 1 | 10M | 10M | 54 |
| 2 | 20M | 20M | 108 |
| 3 | 30M | 30M | 162 |
USD 0,000005/req (PUT etc.) e USD 0,0000004/req (GET/SELECT)
5.3.4 Total S3
| Cenário | USD/mês |
|---|---|
| 1 | 112 |
| 2 | 195 |
| 3 | 278 |
Conclusão sobre o S3: ~1% do total. Não é alavanca de custo. Não preocupa.
6. Sensibilidade dos custos — onde mexer faz diferença
Os custos respondem a 4 alavancas. A tabela abaixo mostra qual mexe mais:
| Alavanca | Impacto | Difícil de mexer? |
|---|---|---|
| Manter SQL Warehouse 24/7 vs. business hours em hml | -20% a -30% no total | Médio — depende do head de TI definir janela operacional |
| Migrar para 1 único ambiente (sem hml separado) | -50% no total | Alto — afeta governança e segurança; em geral não recomendado |
| Reduzir tamanho do SQL Compute (Medium → Small) | -50% sobre SQL Warehouse | Alto — depende de teste de carga real, pode degradar latência |
| Ajustar tamanho/quantidade de EC2 do Lakeflow | ±5% no total | Baixo — dimensionar conforme medição real dos pipelines |
| Mudar região AWS (N. Virginia para São Paulo) | +20% a +30% (custo maior em SP) | Baixo — mas afeta latência para usuários BR; trade-off a discutir |
| Mudar de Databricks Premium para Standard | -15% sobre Databricks | Alto — perde features de governança/segurança importantes |
Recomendação: começar com as premissas do Lucas (Cenário 1, prd+hml, N. Virginia, Premium, Medium) e revisar apenas a janela de operação do hml após 90 dias de operação real. Não comprometer governança nem mudar região no MVP.
7. Premissas a revisar com Lucas
São pontos onde a estimativa pode mudar quando a Costal definir certas decisões:
- Há mesmo necessidade de 2 ambientes (prd + hml) desde o dia 1? — pode-se argumentar que nos primeiros 60 dias o hml pode ser intermitente. Economia: até 50% no curto prazo.
- Volumetria de armazenamento (2/3/4 TB) — Lucas estimou. Quando o Sienge começar a gerar dados reais (Q3/2026?), revisar.
- Operações S3 (10M/20M/30M req/mês) — depende do design dos pipelines. Pode ser revisto após desenho dos primeiros agentes em produção.
- Região N. Virginia — escolha padrão por preço. Avaliar latência de acesso a partir do Brasil (provavelmente OK para batch + dashboards corporativos; não-OK para apps de campo de obra com latência crítica). Decisão de arquitetura a revisar com Gabriel.
- Reservation pricing (compromisso de 1 ou 3 anos) — se a Costal aceitar comprometer-se com volume mínimo, a AWS oferece descontos de 20% a 60%. Não considerado nesta estimativa. Discutir após estabilizar volumetria real (mês 12+).
8. Próximos passos
Para Igor:
- Aprovar provisão de US$ 250-290 mil/ano no orçamento 2026 (banda ampla; refinar quando volumetria real aparecer)
- Endossar a abordagem faseada (C1 → C2 → C3 por gatilho, não por calendário fixo)
- Indicar o head de TI Costal para monitorar gatilhos e tomar decisões de mudança de cenário
- Validar com Lucas os 5 pontos da §7 quando houver volumetria real (Q3/2026 em diante)
Para Anouk (Pedro/Blaschek):
- ✅ Material entregue (este documento)
- Se Igor aprovar a provisão, registrar em decisoes como decisão D-XXX
- Quando Inteligência de Mercado Colliers entrar em produção (primeira carga real do lake), pedir para Lucas re-medir 1 e 2 da §7
- Após 90 dias de operação, revisar premissa da §7.1 (hml 24/7) com head de TI Costal
Glossário
Termos técnicos do PDF do Lucas, explicados no contexto Costal.
AWS (Amazon Web Services) — Provedor de nuvem da Amazon. É onde a infraestrutura roda fisicamente. Equivalente a “data center alugado”.
Databricks — Plataforma de processamento de dados que roda em cima da AWS (ou Azure ou GCP). É o que faz o “trabalho pesado” sobre os dados — limpeza, transformação, consulta, IA. Equivalente, em escala industrial, ao que o Excel faz numa planilha.
Data Lake / Lakehouse — Repositório central de dados. Recebe dados de todos os sistemas (Sienge, RH, obras, e-mails, sensores), padroniza e disponibiliza para BI, IA e relatórios. “Lakehouse” combina o melhor de Data Lake + Data Warehouse.
Lakeflow Jobs — Componente do Databricks que executa os “pipelines” — processos automatizados que rodam de tempos em tempos (ex: toda noite às 2h da manhã) para carregar dados novos no lake.
SQL Warehouse — Componente do Databricks que responde a consultas em tempo real. Quando um usuário abre um dashboard, é o SQL Warehouse que devolve os números. Fica ligado o tempo todo (24/7).
S3 (Simple Storage Service) — Serviço de armazenamento da AWS. É onde os arquivos do data lake ficam fisicamente guardados. Equivalente a um HD de 4 TB na nuvem, com a diferença de que se cobra por uso, não por compra.
EC2 (Elastic Compute Cloud) — Servidores virtuais da AWS, alugados por hora. O Databricks usa EC2 para executar processamento.
m5.xlarge — Tipo específico de servidor EC2: 4 vCPUs (núcleos de processamento) + 16 GB de memória RAM. Perfil “uso geral” — bom equilíbrio entre processamento, memória e custo.
DBU (Databricks Unit) — Unidade de cobrança proprietária do Databricks. Já está embutida no preço/hora do Lucas (US 5,28/h para SQL Warehouse Medium).
Plano Premium (Databricks) — Nível intermediário do Databricks (Standard / Premium / Enterprise). O Premium inclui governança, controle de acesso por papel (RBAC), auditoria e segurança — mínimo necessário para uso corporativo sério. Standard é mais barato mas perde features importantes.
Compute type — Tipo de “motor” Databricks. Lakeflow Jobs Classic é otimizado para processamento batch (jobs noturnos). SQL Compute é otimizado para consultas interativas em tempo real.
Compute configuration: Medium — Tamanho do SQL Warehouse: Small / Medium / Large / X-Large. Medium é uma escolha intermediária; Lucas dimensionou nesse nível para suportar consultas concorrentes razoáveis sem custo absurdo.
N. Virginia — Região AWS US-East-1, escolhida por ser a mais barata e de maior maturidade. Alternativa: São Paulo (latência menor para BR mas custo 20-30% maior).
Outbound — Tráfego de dados que sai da AWS (para a internet ou outra região). É o único tipo cobrado — entrada (inbound) é grátis.
prd / hml — Convenção universal: prd = produção (ambiente real, em uso); hml = homologação (ambiente espelho para testes antes de subir para produção). O Lucas multiplicou todos os custos por 2 para cobrir os dois ambientes.
OPTIMIZE / VACUUM / COMPUTE STATISTICS — Tarefas internas de manutenção do Databricks, equivalentes ao “desfragmentar disco” e “limpar cache” tradicionais. Mantêm a performance estável ao longo do tempo. Lucas incluiu folga no dimensionamento dos EC2 para essas tarefas.
SaaS (Software as a Service) — Modelo onde se contrata um software pronto, com infraestrutura, segurança e disponibilidade já incluídas no preço (ex: Sienge, Salesforce). Diferente do Data Lake, que é IaaS+PaaS — paga-se infraestrutura e plataforma separadas.
SINAPI — (referência citada no PDF, contexto Sienge) Sistema Nacional de Pesquisa de Custos e Índices da Construção Civil, fonte oficial brasileira de preços de insumos para orçamento de obra. Não tem relação com este orçamento Databricks.
Ver também
- Data Lakehouse — Arquitetura técnica completa
- 2026)
- Arquitetura Empresarial Costal (Blaschek)
- Modelo Global de Dados (12 domínios)
- Guia técnico do ERP Sienge
- Catálogo dos 26 agentes IA Costal — quem vai consumir o data lake
- Spec Inteligência de Mercado Colliers — primeiro caso de uso Lakehouse
- Missão Blaschek — Arquitetura Empresarial
Histórico
| Data | Mudança |
|---|---|
| 2026-04-26 | Lucas Andrade entrega PDF original com 3 cenários (coordenação Blaschek, solicitação Igor) |
| 2026-04-27 | Pedro/Anouk consolidam material para Igor — sumário executivo, faseamento C1→C2→C3, sensibilidade, 11 termos no glossário, próximos passos. Localização canônica: 03-arquitetura/orcamento-infraestrutura.md. PDF original preservado em 04-referencia/arquitetura/. |