Output Snowflake

Aplica as mensagens em tabelas do Snowflake, mantendo a tabela de destino igual à tabela de origem: inserções, atualizações e exclusões acontecem no destino conforme chegam. É o Output usado para data warehouse.

O lote não vai direto para a tabela: ele é enviado antes a um stage do Snowflake — uma área de passagem de arquivos dentro do próprio Snowflake — e de lá é aplicado na tabela.

Duas fases

O trabalho acontece em duas fases, automaticamente, e a virada de uma para a outra não exige nada de você:

1. Carga inicial — o conteúdo atual das tabelas é gravado de uma vez, depois de a tabela de destino ser esvaziada.
2. Fluxo contínuo — a partir daí, só as mudanças trafegam: inserções, atualizações e exclusões.

Pré-requisitos no Snowflake

• As tabelas de destino já devem existir, com as colunas correspondentes.
• Um stage disponível para receber os lotes.
• Uma role com leitura e escrita nas tabelas e no stage, e permissão de criar formato de arquivo no schema.

O que este Output precisa ler

Diferente da maioria dos Outputs, este exige um formato específico de mensagem:

Parte	Como é usada
Headers	op diz o que fazer; schema e table dizem de qual tabela de origem a linha veio. Os três são obrigatórios — sem eles a mensagem é recusada.
Value	A linha em JSON plano. Usado quando op é r, c ou u.
Key	As colunas da chave em JSON. Usada quando op é d.

op	O que o Output faz
r	Insere a linha (carga inicial)
c	Insere a linha
u	Atualiza a linha correspondente à chave
d	Apaga a linha correspondente à chave

De onde vêm essas mensagens

O Input SQL Server CDC produz exatamente esse formato. Qualquer outro Input precisa de um Transform que monte os headers op, schema e table.

Exemplo — inserção ou atualização

Key:     {"ID":42}
Value:   {"ID":42,"CLIENTE":"ACME","TOTAL":249.90,"ATUALIZADO_EM":"2026-07-26T11:02:31Z"}
Headers: op=u  schema=dbo  table=pedidos

A linha de ID=42 na tabela de destino fica com os valores novos. Se ela não existisse, seria inserida.

Exemplo — exclusão

Key:     {"ID":42}
Value:   (vazio)
Headers: op=d  schema=dbo  table=pedidos

A linha ID=42 é apagada. Repare que o Value vem vazio — a identificação da linha está na Key.

Campos

Conexão

Campo	O que é	Padrão
Conta (account)	Identificador da conta Snowflake, no formato minha-org-minha-conta.	—
Usuário	Usuário de acesso.	—
Senha (secret)	O Secret com a senha.	—
Database	Banco de destino.	—
Schema	Schema das tabelas de destino. O conector cria nele um formato de arquivo chamado GO_CONNECTOR_JSON, necessário para ler os lotes enviados ao stage.	PUBLIC
Warehouse	Warehouse usado para executar as gravações.	—
Role (opcional)	Papel usado na conexão.	vazio

Mapeamento de tabelas

Cada tabela de origem precisa de uma linha no mapeamento apontando para a tabela de destino:

Campo	O que é
Schema de origem	O schema como vem no header schema da mensagem — ex.: dbo.
Tabela de origem	A tabela como vem no header table — ex.: orders.
Chave primária	Colunas que identificam a linha, separadas por vírgula. São elas que o Output usa para decidir entre inserir e atualizar.
Tabela de destino	Nome da tabela no Snowflake — ex.: SALES_ORDERS.
Stage	Nome do stage usado como área de passagem dos lotes.
Prefixo no stage	Pasta dentro do stage onde os arquivos são colocados. Ex.: go-connector.

Numa chave composta, o campo Chave primária recebe as colunas separadas por vírgula — ex.: PEDIDO_ID, ITEM_ID para uma mensagem cuja Key é {"PEDIDO_ID":1234,"ITEM_ID":3}.

Lote e desempenho

O Output acumula linhas antes de gravar, e o lote fecha pelo que vier primeiro:

Campo	O que é	Padrão
Linhas por lote	Quantas linhas são acumuladas antes de uma gravação.	100000
Segundos por lote (flush)	Tempo máximo de espera antes de enviar um lote incompleto.	10
Timeout de query (segundos)	Tempo máximo de uma gravação antes de ser abortada.	300

Por que o lote é tão maior que o do PostgreSQL

O Snowflake reescreve um bloco inteiro de armazenamento para aplicar uma única linha. O custo de uma gravação vem de quantos blocos ela toca, não de quantas linhas carrega. Um lote grande toca praticamente os mesmos blocos e divide esse custo por dez vezes mais linhas.

Recomeçar do zero

Campo	O que é
Sufixo do Group ID	A parte do marcador de leitura que você controla. O nome base é gerado a partir da pipeline e do node e não pode ser alterado. Permitido: letras, números, hífen e underline.

Trocar o sufixo e publicar de novo é o único botão de recomeçar que existe. O Output esquece até onde tinha lido, relê o tópico desde o começo, esvazia a tabela de destino e refaz a carga completa.

Apagar a tabela no braço não recomeça nada — o controle de "já carreguei esta tabela" fica do lado da plataforma, não do banco.

Cuidados de operação

Rode uma cópia só. Duas cópias no mesmo grupo de consumo podem esvaziar a tabela uma da outra durante a carga inicial.

A validação acontece na subida. O Output confere as tabelas e colunas mapeadas quando o node sobe. Um mapeamento errado falha na hora, com a mensagem do que está errado — e não silenciosamente na primeira leva de dados.

A carga inicial pode duplicar linhas se o node cair no meio

A confirmação de leitura acontece depois da gravação. Um node que morre entre uma coisa e outra reenvia aquele lote ao voltar, e na carga inicial as linhas do reenvio entram de novo. O fluxo contínuo não tem esse problema; a saída é refazer a carga com um sufixo de Group ID novo.

Nomes de coluna precisam bater exatamente

Cada coluna é lida do lote pelo nome exato, respeitando maiúsculas e minúsculas. Uma coluna cujo nome no destino não confere com o nome que vem na origem é lida como nula — não dá erro, apenas grava vazio.

Na prática: se a origem manda IDT_PES, a coluna no Snowflake precisa se chamar IDT_PES. Ao criar as tabelas de destino, mantenha a mesma grafia da origem.

Este é o oposto do PostgreSQL, que compara nomes ignorando maiúsculas e minúsculas.