Por Que a Arquitetura do Snowflake Parece Diferente
Plataformas de dados tradicionais normalmente conectam armazenamento e processamento no mesmo lugar.
Precisa de mais performance? Você escala todo o sistema (e paga por isso), enquanto vários times acabam competindo pelos mesmos recursos.
-
escalabilidade independente entre storage e compute
-
isolamento de workloads (clusters separados para times ou pipelines diferentes)
-
elasticidade com redimensionamento e multi-cluster scaling
-
otimização gerenciada com base em metadata e pruning
-
controle de custos
-
concorrência
-
elocidade de consultas
-
forma como você estrutura seus dados
1) Storage no Snowflake: O Que Acontece Quando Você Carrega Dados?
O Snowflake armazena dados em object storage na nuvem:
- AWS S3
- Azure Blob Storage
- Google Cloud Storage
Em vez disso, o Snowflake organiza tudo em estruturas internas e usa fortemente metadados para acelerar consultas. Micro-partitions: A Unidade Central de Armazenamento
Quando os dados são carregados em tabelas Snowflake, eles são automaticamente reorganizados em micro-partitions. Essas micro-partitions possuem:
- formato colunar (ideal para analytics)
- imutabilidade após gravação (updates criam novas versões)
- metadata como valores mínimo/máximo por coluna e outras estatísticas
Por Que as Micro-partitions Importam Como cada micro-partition possui metadata, o Snowflake consegue evitar escanear partes desnecessárias da tabela.
Micro-partition Pruning
Se sua tabela possui uma coluna event_date e sua query filtra um intervalo pequeno de datas, o Snowflake pode ignorar micro-partitions cuja metadata mostra que aquelas datas não existem ali.
- menos bytes escaneados
- consultas mais rápidas
- menor custo computacional
Metadata: O “Segredo” da Performance
- quais micro-partitions escanear
- estratégias e ordem de joins
- abordagens de agregação
- se resultados em cache podem ser reutilizados
Dica importante
Se sua query escaneia quase toda uma tabela gigante mesmo com filtros, o problema normalmente não é o tamanho do warehouse.
- organização dos dados
- padrão de filtros
- modelagem inadequada
Às vezes clustering ajuda.
- dicionar uma coluna de data realmente usada
- mudar o padrão de acesso aos dados
Time Travel e Fail-safe O Snowflake oferece recursos que permitem acessar versões históricas dos dados por um período de retenção. Isso é útil para:
- recuperar deletes acidentais
- recuperar updates incorretos
- auditoria
- reprocessamento de pipelines antigos Existe também uma camada adicional de recuperação além da retenção normal. Importante Defina retenção com intenção.
→ maior o uso de storage → maior o custo 2) Compute no Snowflake: Virtual Warehouses e Execução de Queries
e outras operações DML
O Que é um Virtual Warehouse?
Um Virtual Warehouse é um mecanismo MPP (Massively Parallel Processing) gerenciado com:
- tamanho configurável (X-Small até 6X-Large, dependendo da conta)
- possibilidade de scale up (maior warehouse)
- possibilidade de scale out (multi-cluster)
- auto-suspend e auto-resume para controle de custos
Principal Vantagem: Isolamento de Workloads Em vez de um único cluster sobrecarregado, você pode ter:
- dashboards de BI em um warehouse
- pipelines ETL/ELT em outro
- workloads de Data Science em um terceiro Isso reduz o famoso problema de:
“Noisy Neighbor”
Como as Queries Realmente Funcionam
O Snowflake compila e otimiza o SQL e depois executa um plano distribuído entre os nós do warehouse.
- quantidade de dados escaneados
- eficiência do pruning
- tipos de join e distribuição dos dados
- concorrência entre queries
- tamanho do warehouse
- configurações de scaling
O Que Ver no Query Profile Quando uma query está lenta, abra o Query Profile e observe:
Bytes scanned vs rows returned
Join nodes com spill ou repartitioning pesado Isso indica:
- movimentação excessiva de dados
- memória insuficiente
Queue time / compilation time Isso indica:
- pressão de concorrência
- planos excessivamente complexos
Spill para storage local/remoto
- warehouse subdimensionado
- joins/agregações pesadas demais
Auto-Suspend e Auto-Resume: Controle de Custos Essencial Dois dos mecanismos com maior ROI:
Heurística prática Warehouses analíticos / ad-hoc
60–300 segundos de auto-suspend
Dashboards de BI com uso constante Use janelas maiores para preservar cache e reduzir variações de latência.
não pagar por idle time sem transformar seu warehouse em uma máquina de “cold start”
3) Escalabilidade no Snowflake: Scale Up vs Scale Out
Escalar errado pode aumentar custo sem resolver o problema.
Scale Up: Aumentar o Tamanho do Warehouse Isso ajuda quando:
- queries são pesadas
- há joins grandes
- agregações são complexas
- jobs batch precisam rodar mais rápido
→ scale up costuma ser a melhor solução inicial
Scale Out: Multi-Cluster para Concorrência
Aqui você adiciona múltiplos clusters sob o mesmo warehouse.
-
muitos usuários simultâneos
-
dashboards de BI
-
picos de uso ao longo do dia
-
fila
-
demora
-
refresh inconsistente → scale out é o caminho certo
Como Escolher
→ multi-cluster (scale out)
→ scale up
→ melhorar pruning primeiro
→ isolamento de workloads + auto-suspend + right-sizing
4) Como o Snowflake Evita o “Grande Caos”: Cache e Otimização
Grande parte da performance vem de comportamentos gerenciados automaticamente.
Se a mesma query roda novamente e os dados não mudaram, o Snowflake pode reutilizar resultados anteriores.
Local / Compute Cache Warehouses também mantêm cache temporário.
Para dashboards sensíveis à latência, uma janela maior de suspensão pode melhorar bastante a estabilidade.
5) Organização dos Dados: Clustering na Prática
O Snowflake automatiza muita coisa, mas a performance ainda depende de:
- como os dados entram
- como você consulta esses dados
Natural Clustering vs Clustering Keys Se os dados são carregados de forma ordenada (por exemplo, por data), o pruning naturalmente funciona melhor.
Clustering Keys
- Quando Clustering Ajuda
- grandes fact tables
- filtros frequentes em colunas específicas
- pruning fraco
- queries escaneando dados demais
event_date tenant_id region
Quando Clustering Talvez Não Valha a Pena
- tabelas pequenas ou médias
- padrões de acesso muito aleatórios
- filtros principais mudando o tempo todo
O Tradeoff de Custo Clustering não é gratuito.
mais manutenção e reorganização em background
por menos bytes escaneados e queries mais rápidas Na prática, clustering vale quando reduz significativamente o custo de queries frequentes.
6) Padrões de Arquitetura que Funcionam Bem Padrão A: Warehouses Separados por Tipo de Workload
- INGEST_WH
- TRANSFORM_WH
- BI_WH
- DS_WH Benefícios
- melhor controle de custos
- governança mais limpa
- menos conflitos de performance
Padrão B: Multi-Cluster para BI + Scale-Up para ETL BI melhor com multi-cluster
ETL melhor com scale-up Esse modelo híbrido costuma ser muito mais eficiente do que usar um único warehouse para tudo.
-
Dev
-
Test
-
Prod
-
evitar impacto em produção
-
controlar custos
-
melhorar governança e acessos
7) Checklist Prático de Tuning
Reduza scans desnecessários
- selecione apenas colunas necessárias
- filtre cedo
- valide pruning no Query Profile
Faça right-size do warehouse comece com: Small ou Medium e aumente apenas se necessário.
Use scaling com intenção Scale up para transformações pesadas
para alta concorrência e BI
Faça controle de custos virar padrão
- ative auto-suspend
- ative auto-resume
- agende jobs pesados fora do horário de pico
Conclusão: O Que Fazer Segunda de Manhã
Se você quer melhorias de alto impacto sem refatorações enormes:
1. Escolha uma query cara ou lenta 2. Analise bytes scanned, spill e queue time **3. **Se o problema for scan → melhore pruning 4. Se o problema for fila → isole BI e considere multi-cluster 5. Configure auto-suspend onde for seguro
performance previsível com custo previsível.
