O Motor do Data Cloud: Como a Salesforce Resolve o Caos de 1 Quatrilhão de Registros em Modelos Customizados

O que 1 quatrilhão de registros ensina sobre arquitetura de dados

O time de engenharia da Salesforce abriu o capô do Data 360 — o motor de segmentação por trás do Data Cloud. Os números são expressivos: 1 quatrilhão de registros processados mensalmente, distribuídos em cerca de 3 milhões de jobs do Apache Spark. Mas a revelação mais honesta desse post técnico não é o volume. É o seguinte diagnóstico, que qualquer arquiteto experiente reconhece imediatamente: o maior desafio não é a escala dos dados em si — é a liberdade total que a plataforma oferece e como clientes e consultorias escolhem modelar e ingerir esses dados.

A armadilha da flexibilidade sem governança

Diferente de plataformas tradicionais que impõem um schema rígido e pré-otimizado, o Data Cloud permite que os clientes tragam estruturas arbitrárias. Com a adoção do Zero Copy Framework — conectando bases diretamente de Snowflake, Databricks, Google BigQuery e Microsoft Fabric — a complexidade dos ambientes explodiu.

O time de engenharia reportou casos reais de ambientes operando com:

• Até 6.000 tabelas ativas simultaneamente
• Milhares de relacionamentos entre objetos
• Payloads de metadados superiores a 500 MB

O efeito prático disso era duplo e crítico: a interface de segmentação ficava pesada para o usuário final e, mais grave, o query planning quebrava. O motor tentava calcular bilhões de rotas de execução possíveis antes de rodar um único job. O sistema não chegava nem a processar — travava no planejamento.

As soluções aplicadas e os tradeoffs que vêm com elas

Para evitar o colapso, a Salesforce implementou um conjunto de intervenções técnicas. A principal foi a introdução do phased query planning — planejamento de consulta em fases.

Em vez de calcular uma rota globalmente ótima para uma consulta complexa, o motor agora divide o plano em blocos menores e os executa progressivamente. A própria Salesforce admite o tradeoff dessa decisão:

A execução resultante pode não ser a mais otimizada no contexto global da query, mas é a estratégia que garante que o processamento não trave por esgotamento de memória.

Além disso, dois padrões problemáticos foram mapeados como causas recorrentes de degradação severa:

• Cartesian explosion: multiplicação descontrolada de linhas causada por chaves de join mal definidas ou ausentes
• Data skew: distribuições distorcidas de dados que sobrecarregam partições específicas do Spark enquanto outras ficam ociosas

Ambos os problemas têm a mesma origem: dados sujos ou mal particionados despejados no sistema sem critério. O custo de performance é alto e, dependendo do volume, irrecuperável dentro de uma janela de processamento razoável.

Por que isso importa para quem projeta soluções

Esse nível de detalhe sobre infraestrutura merece atenção porque remove o verniz do marketing e expõe os limites físicos e arquiteturais da plataforma. Quando desenhamos soluções envolvendo Data Cloud — especialmente com ativação de audiências para alimentar ferramentas como o Agentforce — tudo costuma parecer simples e imediato no papel.

A necessidade da Salesforce de criar guardrails nos relacionamentos de objetos prova que a ausência de governança tem um preço mensurável. Um modelo excessivamente normalizado, com conexões redundantes ou chaves de integração frágeis, não é apenas um problema estético de modelagem — é um vetor direto de degradação de performance em escala.

A responsabilidade que não se terceiriza para o Spark

A infraestrutura da Salesforce está, de fato, cada vez mais resiliente: alocação dinâmica de recursos, retentativas baseadas em SLA e uma camada de otimização progressiva que absorve cargas brutais. Isso é real e relevante.

Mas a responsabilidade arquitetural permanece inteiramente com quem projeta a solução. Um modelo enxuto, com chaves de integração sólidas, qualidade de dados garantida na origem e relacionamentos bem dimensionados não é um diferencial de projeto — é o requisito mínimo para que o Data Cloud funcione dentro dos limites que a própria Salesforce documentou.

Confiar no poder de fogo do Apache Spark por baixo da plataforma como justificativa para uma arquitetura negligente não é estratégia. É ingenuidade técnica com prazo de validade curto.