tee / insights
LEARNING / SNOWFLAKEInicio

Snowflake / Operaciones de datos

Guía de estudio de operaciones de datos en Snowflake

Aprende alcance de acceso, cambios de datos, recuperación, carga, automatización y validación como un solo flujo. El objetivo no es memorizar sintaxis, sino saber qué comprobar antes de cambiar datos, cómo recuperarse y qué validar tras una nueva ejecución.

Este es un recurso de aprendizaje independiente. No reproduce el temario ni las preguntas de ningún examen oficial de certificación de Snowflake.

Especificaciones revisadas 2026-10-08

Entender las cinco áreas como una operación

Las cinco áreas están conectadas. Define quién puede cambiar qué objeto, controla el límite del cambio, carga o reprocesa y valida los datos resultantes.

A

Acceso y estructura

Revisa roles, bases de datos, esquemas, tablas, vistas y contexto de sesión.

B

Cambios de datos

Razona sobre INSERT, UPDATE, DELETE, MERGE, alcance, duplicados y reejecución.

C

Transacciones y recuperación

Separa BEGIN / COMMIT / ROLLBACK de Time Travel y UNDROP.

D

Carga y automatización

Conecta Stage, File Format, COPY INTO, Task y Stored Procedure.

E

Validación y operación

Comprueba granularidad de JOIN, NULL, datos tardíos, recuentos, claves, valores y reprocesamiento.

Cinco comprobaciones antes de ejecutar

Lee cualquier cambio de datos en este orden.

StepCheck
1. ContextComprueba CURRENT_ROLE(), CURRENT_DATABASE() y CURRENT_SCHEMA().
2. ScopeUsa un nombre totalmente calificado y un WHERE preciso.
3. BoundarySi varios DML deben tener un único resultado de éxito o fallo, define la transacción.
4. Re-runComprueba que otra ejecución no produzca duplicados ni cambios repetidos.
5. ValidateNo te quedes con el estado de éxito; valida recuentos, claves y valores.

A. Confirmar permisos y alcance

Los usuarios de Snowflake operan mediante roles y los privilegios concedidos a esos roles autorizan el acceso a objetos. Un SQL correcto puede fallar por falta de permisos. Revisar primero el rol, la base y el esquema actuales también reduce el riesgo de modificar otro entorno o una tabla con el mismo nombre.

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

Los objetos de esquema pueden referenciarse como database.schema.object. En SQL que cambia datos, usar SALES_DB.CORE.ORDERS reduce la dependencia de la base y el esquema actuales de la sesión.

SELECT *
FROM SALES_DB.CORE.ORDERS;

Para lectura, el principio de mínimo privilegio concede solo lo necesario, por ejemplo USAGE en base y esquema y SELECT en la tabla. Comprueba la operación requerida antes de cambiar a un rol más potente.

B. Modificar datos con seguridad

INSERT añade filas, UPDATE cambia filas existentes y DELETE las elimina. UPDATE y DELETE sin WHERE afectan a todas las filas, por lo que conviene probar el mismo predicado con SELECT y revisar el recuento y las claves.

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
INSERTAñadir filas¿Puede insertarse dos veces la misma entrada?
UPDATECambiar filas coincidentes¿El WHERE es más amplio de lo previsto?
DELETEEliminar filas coincidentes¿Puedes previsualizar exactamente las filas con SELECT?
MERGEActualizar, insertar o eliminar por coincidencia¿Están claros la clave ON y la unicidad del source?

MERGE puede combinar UPDATE, INSERT y DELETE según coincidencias entre source y target. No convierte por sí solo un source duplicado en único. Define la Business Key y comprueba la unicidad del source antes de hacer 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 es distinto de cero y de una cadena vacía. Se comprueba con IS NULL / IS NOT NULL. En una reejecución, revisa la idempotencia para evitar duplicados o cambios adicionales no deseados.

C. Separar transacciones y recuperación

BEGIN inicia una transacción explícita, COMMIT confirma y ROLLBACK cancela los cambios de esa transacción. Úsala cuando varios DML formen una sola unidad de éxito o fallo.

BEGIN TRANSACTION;

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

COMMIT;

En Snowflake, ejecutar DDL confirma implícitamente una transacción activa y el DDL se ejecuta en una transacción propia. DDL no puede revertirse con ROLLBACK. No mezcles DML y DDL suponiendo que un ROLLBACK final deshará todo.

ROLLBACK sirve para la transacción actual no confirmada. Recuperar cambios ya confirmados u objetos eliminados es distinto. Dentro del periodo de retención aplicable, Time Travel permite consultar datos históricos y UNDROP puede restaurar objetos compatibles.

MechanismTargetUse
ROLLBACKTransacción explícita actual sin confirmarCancelar la unidad de trabajo actual.
Time TravelDatos históricos dentro de retenciónConsultar o utilizar un estado anterior para recuperar.
UNDROPObjetos compatibles eliminados dentro de retenciónRestaurar el objeto eliminado más reciente cuando se permita.

D. Conectar carga de archivos y automatización

Un modelo útil de carga es Stage → File Format → COPY INTO → Table. Stage identifica la ubicación del archivo, File Format define cómo interpretar CSV, JSON y otros formatos, y COPY INTO carga la tabla.

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'
);

En automatización, Task responde a cuándo ejecutar, mientras que Stored Procedure puede agrupar qué hacer y cómo. Un Task puede llamar a un Stored Procedure que realice MERGE y validaciones.

E. Validar recuentos, claves y valores

Que aumenten las filas tras un JOIN no implica necesariamente un error. Si ORDERS tiene una fila por pedido y ORDER_ITEMS una por artículo, un JOIN 1:N repetirá el pedido. Confirma primero qué representa una fila en cada tabla.

COUNT(*) cuenta filas, mientras que COUNT(column) excluye las filas donde esa columna es NULL. Que source y target tengan el mismo número de filas no basta, porque pueden diferir las claves o los valores.

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 datos tardíos, separa la hora de negocio o evento de la hora de ingestión. Si solapas ventanas para capturar registros tardíos, combínalo con deduplicación o MERGE seguros para reejecución.

LevelWhat to check
1. RecuentoUsa COUNT(*) para detectar grandes faltantes o excedentes.
2. ClaveComprueba Business Keys faltantes, extra y duplicadas.
3. ValorCompara columnas importantes y agregados como SUM, MIN y MAX.

Comprobación de conocimientos

Antes de abrir la respuesta, piensa en alcance, límite de transacción, reejecución y validación.

01Quieres cancelar solo pedidos del cliente 1001, pero el UPDATE no tiene WHERE. ¿Qué ocurre?

Todas las filas quedan como objetivo. Previsualiza el predicado con SELECT y limita el UPDATE con un WHERE preciso.

02COUNT(AMOUNT) es 95 y COUNT(*) es 100. ¿Qué compruebas primero?

Puede haber cinco filas con AMOUNT = NULL. COUNT(column) excluye NULL.

03Reprocesas la misma entrada del Stage. ¿INSERT SELECT por sí solo es seguro?

No necesariamente. Las mismas filas pueden insertarse otra vez. Define la Business Key y usa deduplicación o un MERGE adecuado.

04Ejecutas BEGIN, UPDATE, CREATE TABLE y ROLLBACK. ¿Se revierte siempre el UPDATE?

No. El DDL de Snowflake confirma implícitamente una transacción activa.

05MERGE coincide por ORDER_ID, pero el source repite ORDER_ID. ¿Qué verificas?

Haz único el source en la granularidad de Business Key para que una fila target no dependa de varias filas source competidoras.

06Source y target tienen 10.000 filas. ¿Basta para declarar éxito?

No. Comprueba también claves faltantes o duplicadas y los valores importantes asociados.

Lista final de revisión

En cada caso comprueba objeto, privilegio, alcance de filas, límite de transacción, reejecución y validación. Conocer la sintaxis no basta si no limitas el objetivo.

OBJECTPRIVILEGEWHERETRANSACTIONRE-RUNVALIDATE

Referencias oficiales

El comportamiento descrito se ha contrastado con la documentación de Snowflake. Los valores dependientes de la cuenta, como retención y permisos, deben verificarse también en el entorno real.