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.
Acesso e estrutura
Confira roles, databases, schemas, tables, views e o contexto da sessão.
Alterações de dados
Raciocine sobre INSERT, UPDATE, DELETE, MERGE, escopo, duplicações e reexecução.
Transações e recuperação
Separe BEGIN / COMMIT / ROLLBACK de Time Travel e UNDROP.
Carga e automação
Conecte Stage, File Format, COPY INTO, Task e Stored Procedure.
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.
| Step | Check |
|---|---|
| 1. Context | Confira CURRENT_ROLE(), CURRENT_DATABASE() e CURRENT_SCHEMA(). |
| 2. Scope | Use um nome totalmente qualificado e um WHERE preciso. |
| 3. Boundary | Se vários DML precisam ter sucesso ou falhar juntos, defina o limite da transação. |
| 4. Re-run | Confira se uma segunda execução cria duplicações ou alterações repetidas. |
| 5. Validate | Nã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;| Statement | Purpose | Safety question |
|---|---|---|
| INSERT | Adicionar linhas | A mesma entrada pode ser inserida duas vezes? |
| UPDATE | Alterar linhas correspondentes | O WHERE está mais amplo do que deveria? |
| DELETE | Remover linhas correspondentes | É possível pré-visualizar exatamente as linhas com SELECT? |
| MERGE | Atualizar, inserir ou excluir por correspondência | A 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.
| Mechanism | Target | Use |
|---|---|---|
| ROLLBACK | Transação explícita atual não confirmada | Cancelar a unidade de trabalho atual. |
| Time Travel | Dados históricos dentro da retenção | Consultar ou usar um estado anterior para recuperação. |
| UNDROP | Objetos compatíveis removidos dentro da retenção | Restaurar 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.
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.
| Level | What to check |
|---|---|
| 1. Contagem | Use COUNT(*) para detectar grandes faltas ou excessos. |
| 2. Chave | Confira Business Keys ausentes, extras e duplicadas. |
| 3. Valor | Compare 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-RUNVALIDATEReferê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.