tee / insights
LEARNING / SNOWFLAKEInício

Snowflake / Operações de dados

Guia de estudo de operações de dados no Snowflake

Aprenda escopo de acesso, alterações de dados, recuperação, carga, automação e validação como um único fluxo. O objetivo não é decorar sintaxe, mas saber o que verificar antes de alterar dados, como recuperar e o que validar depois de uma nova execução.

Este é um material de estudo independente. Ele não reproduz o escopo nem as questões de nenhuma certificação oficial do Snowflake.

Especificações verificadas em 2026-10-08

Enxergue as cinco áreas como uma operação

As cinco áreas se conectam. Defina quem pode alterar qual objeto, controle o limite da mudança, carregue ou reprocesse e valide os dados resultantes.

A

Acesso e estrutura

Confira roles, databases, schemas, tables, views e o contexto da sessão.

B

Alterações de dados

Raciocine sobre INSERT, UPDATE, DELETE, MERGE, escopo, duplicações e reexecução.

C

Transações e recuperação

Separe BEGIN / COMMIT / ROLLBACK de Time Travel e UNDROP.

D

Carga e automação

Conecte Stage, File Format, COPY INTO, Task e Stored Procedure.

E

Validação e operação

Confira granularidade de JOIN, NULL, dados atrasados, contagens, chaves, valores e reprocessamento.

Cinco verificações antes de executar

Leia operações que alteram dados nesta ordem.

StepCheck
1. ContextConfira CURRENT_ROLE(), CURRENT_DATABASE() e CURRENT_SCHEMA().
2. ScopeUse um nome totalmente qualificado e um WHERE preciso.
3. BoundarySe vários DML precisam ter sucesso ou falhar juntos, defina o limite da transação.
4. Re-runConfira se uma segunda execução cria duplicações ou alterações repetidas.
5. ValidateNão pare no status de sucesso; valide contagens, chaves e valores.

A. Confirmar permissões e escopo

Usuários do Snowflake operam por roles, e os privilégios concedidos a esses roles autorizam o acesso aos objetos. SQL correto ainda pode falhar por falta de permissão. Conferir primeiro role, database e schema atuais também reduz o risco de alterar outro ambiente ou uma tabela de mesmo nome.

SELECT
  CURRENT_ROLE(),
  CURRENT_DATABASE(),
  CURRENT_SCHEMA();

Objetos de schema podem ser referenciados como database.schema.object. Em SQL que altera dados, usar SALES_DB.CORE.ORDERS reduz a dependência do database e schema atuais da sessão.

SELECT *
FROM SALES_DB.CORE.ORDERS;

Em leitura, o princípio de menor privilégio concede apenas o necessário, como USAGE no database e schema e SELECT na table. Confira a operação exigida antes de trocar para um role mais forte.

B. Alterar dados com segurança

INSERT adiciona linhas, UPDATE altera linhas existentes e DELETE remove linhas. UPDATE e DELETE sem WHERE atingem todas as linhas, então vale testar o mesmo predicado com SELECT e conferir contagem e chaves.

SELECT ORDER_ID, CUSTOMER_ID, STATUS
FROM SALES_DB.CORE.ORDERS
WHERE CUSTOMER_ID = 1001;

UPDATE SALES_DB.CORE.ORDERS
SET STATUS = 'CANCELLED'
WHERE CUSTOMER_ID = 1001;
StatementPurposeSafety question
INSERTAdicionar linhasA mesma entrada pode ser inserida duas vezes?
UPDATEAlterar linhas correspondentesO WHERE está mais amplo do que deveria?
DELETERemover linhas correspondentesÉ possível pré-visualizar exatamente as linhas com SELECT?
MERGEAtualizar, inserir ou excluir por correspondênciaA chave ON e a unicidade do source estão claras?

MERGE pode combinar UPDATE, INSERT e DELETE conforme correspondências entre source e target. Ele não torna um source duplicado único por si só. Defina a Business Key e confira a unicidade do source antes do MERGE.

MERGE INTO SALES_DB.CORE.ORDERS AS t
USING LANDING_DB.RAW.ORDERS_STAGE AS s
  ON t.ORDER_ID = s.ORDER_ID
WHEN MATCHED THEN
  UPDATE SET t.STATUS = s.STATUS, t.AMOUNT = s.AMOUNT
WHEN NOT MATCHED THEN
  INSERT (ORDER_ID, CUSTOMER_ID, AMOUNT, STATUS)
  VALUES (s.ORDER_ID, s.CUSTOMER_ID, s.AMOUNT, s.STATUS);

NULL é diferente de zero e de string vazia. Use IS NULL / IS NOT NULL. Em reexecuções, confira a idempotência para evitar duplicações ou alterações extras não desejadas.

C. Separar transações e recuperação

BEGIN inicia uma transação explícita, COMMIT confirma e ROLLBACK cancela as alterações dessa transação. Use quando vários DML fazem parte de uma única unidade de sucesso ou falha.

BEGIN TRANSACTION;

UPDATE SALES_DB.CORE.ORDERS
SET STATUS = 'CLOSED'
WHERE ORDER_DATE < '2026-01-01';

COMMIT;

No Snowflake, executar DDL confirma implicitamente uma transação ativa, e o DDL roda em uma transação própria. DDL não pode ser revertido com ROLLBACK. Não misture DML e DDL supondo que um ROLLBACK final vai desfazer tudo.

ROLLBACK trata a transação atual ainda não confirmada. Recuperar alterações já confirmadas ou objetos removidos é diferente. Dentro do período de retenção aplicável, Time Travel permite consultar dados históricos e UNDROP pode restaurar objetos compatíveis.

MechanismTargetUse
ROLLBACKTransação explícita atual não confirmadaCancelar a unidade de trabalho atual.
Time TravelDados históricos dentro da retençãoConsultar ou usar um estado anterior para recuperação.
UNDROPObjetos compatíveis removidos dentro da retençãoRestaurar o objeto removido mais recente quando permitido.

D. Conectar carga de arquivos e automação

Um bom modelo de carga é Stage → File Format → COPY INTO → Table. Stage identifica a localização do arquivo, File Format define como interpretar CSV, JSON e outros formatos, e COPY INTO carrega a Table.

StageFile FormatCOPY INTOTableTask / Stored Procedure
COPY INTO SALES_DB.CORE.ORDERS
FROM @LANDING_DB.RAW.ORDER_STAGE
FILE_FORMAT = (
  FORMAT_NAME = 'LANDING_DB.RAW.ORDER_CSV'
);

Na automação, Task responde quando executar, enquanto Stored Procedure pode agrupar o que fazer e como. Um Task pode chamar um Stored Procedure que executa MERGE e validações.

E. Validar contagens, chaves e valores

Mais linhas depois de um JOIN não significam erro automaticamente. Se ORDERS tem uma linha por pedido e ORDER_ITEMS uma por item, um JOIN 1:N repetirá o pedido. Primeiro confirme o que uma linha representa em cada tabela.

COUNT(*) conta linhas, enquanto COUNT(column) exclui linhas em que a coluna é NULL. Contagens iguais em source e target ainda não bastam, pois chaves ou valores podem ser diferentes.

SELECT COUNT(*) AS row_count,
       COUNT(AMOUNT) AS amount_count
FROM SALES_DB.CORE.ORDERS;

SELECT ORDER_ID, COUNT(*) AS duplicate_count
FROM SALES_DB.CORE.ORDERS
GROUP BY ORDER_ID
HAVING COUNT(*) > 1;

Para dados atrasados, separe o horário de negócio ou evento do horário de ingestão. Se houver sobreposição de janelas para capturar registros atrasados, combine isso com deduplicação ou MERGE seguros para reexecução.

LevelWhat to check
1. ContagemUse COUNT(*) para detectar grandes faltas ou excessos.
2. ChaveConfira Business Keys ausentes, extras e duplicadas.
3. ValorCompare colunas importantes e agregados como SUM, MIN e MAX.

Verificação de conhecimento

Antes de abrir a resposta, pense em escopo, limite da transação, reexecução e validação.

01Você quer cancelar apenas os pedidos do cliente 1001, mas o UPDATE não tem WHERE. Qual é o problema?

Todas as linhas viram alvo. Pré-visualize o predicado com SELECT e limite o UPDATE com um WHERE preciso.

02COUNT(AMOUNT) é 95 e COUNT(*) é 100. O que conferir primeiro?

Pode haver cinco linhas com AMOUNT = NULL. COUNT(column) exclui NULL.

03Você reprocessa a mesma entrada do Stage. INSERT SELECT sozinho é seguro?

Não necessariamente. As mesmas linhas podem ser inseridas novamente. Defina a Business Key e use deduplicação ou um MERGE adequado.

04Você executa BEGIN, UPDATE, CREATE TABLE e ROLLBACK. O UPDATE sempre volta?

Não. DDL no Snowflake confirma implicitamente uma transação ativa.

05MERGE corresponde por ORDER_ID, mas o source repete ORDER_ID. O que verificar?

Torne o source único na granularidade da Business Key para que uma linha target não dependa de várias linhas source concorrentes.

06Source e target têm 10.000 linhas. Isso basta para declarar sucesso?

Não. Confira também chaves ausentes ou duplicadas e os valores importantes associados.

Lista final de revisão

Em cada cenário, confira objeto, privilégio, escopo de linhas, limite da transação, reexecução e validação. Conhecer a sintaxe não basta se o alvo não estiver limitado.

OBJECTPRIVILEGEWHERETRANSACTIONRE-RUNVALIDATE

Referências oficiais

O comportamento descrito foi conferido na documentação do Snowflake. Valores que dependem da conta, como retenção e permissões, também precisam ser verificados no ambiente real.