Snowflake en 2026: arquitectura, SQL y preguntas de entrevista para ingenieros de datos

Las preguntas de entrevista sobre Snowflake evalúan si una persona ingeniera de datos comprende la arquitectura desacoplada de la plataforma, no solo su sintaxis SQL. El diseño multi-cluster de datos compartidos que Snowflake fue pionero en implementar separa el almacenamiento, el cómputo y los servicios en tres capas independientes, y esa separación explica casi cada decisión de rendimiento y costo que un equipo toma en la plataforma. Esta guía cubre la arquitectura de Snowflake, los patrones SQL que mantienen las consultas rápidas y económicas en 2026, y las preguntas de entrevista que revelan experiencia real en producción.

Arquitectura de Snowflake: almacenamiento, cómputo y cloud services

El rasgo que define la arquitectura de Snowflake es que el almacenamiento y el cómputo están físicamente separados. Los datos residen una sola vez en una capa de almacenamiento centralizada respaldada por object stores en la nube como Amazon S3 o Azure Blob Storage. Cualquier cantidad de clusters de cómputo puede leer esos mismos datos de forma concurrente sin copiarlos, un enfoque que el equipo de ingeniería original bautizó como multi-cluster shared data en el paper de SIGMOD de 2016 que presentó el diseño.

La capa de almacenamiento mantiene los datos en archivos inmutables, comprimidos y columnares llamados micro-partitions. Nadie gestiona estos archivos de forma directa. Snowflake los escribe, rastrea sus metadatos y los recupera. La capa de cómputo está formada por virtual warehouses, cada uno un cluster de servidores que Snowflake aprovisiona bajo demanda. La capa de cloud services se sitúa por encima de ambas y coordina todo: parsea el SQL, planifica las consultas, aplica el control de acceso, gestiona las transacciones y almacena los metadatos que hacen posibles funciones como Time Travel y zero-copy cloning.

Como estas capas son independientes, un warehouse puede redimensionarse o eliminarse sin tocar un solo byte de datos, y el almacenamiento puede crecer hasta petabytes sin aprovisionar cómputo alguno.

-- setup_warehouse.sql
-- Create an isolated compute cluster and a database.
CREATE WAREHOUSE analytics_wh
  WAREHOUSE_SIZE = 'MEDIUM'      -- 4 credits/hour, doubles each size step
  AUTO_SUSPEND = 60             -- suspend after 60s idle to stop billing
  AUTO_RESUME = TRUE            -- resume automatically on the next query
  INITIALLY_SUSPENDED = TRUE;

CREATE DATABASE sales_analytics;
USE WAREHOUSE analytics_wh;
USE DATABASE sales_analytics;

-- Storage and compute are independent: dropping the warehouse
-- leaves every table in sales_analytics untouched.

Eliminar analytics_wh después de ejecutar ese script detendría toda la facturación de cómputo mientras cada tabla sigue siendo consultable en el momento en que se cree un nuevo warehouse. Ese desacoplamiento es la idea más importante que se debe articular en una entrevista.

Cómo los virtual warehouses escalan el cómputo de Snowflake

Un virtual warehouse es un cluster de cómputo con nombre, dimensionado en unidades tipo talla de camiseta: X-Small, Small, Medium, Large y superiores. Cada paso hacia arriba duplica tanto el número de servidores como el consumo de créditos por hora, de modo que un warehouse Large cuesta cuatro veces más que uno Small, pero también termina una consulta con muchos escaneos aproximadamente cuatro veces más rápido. Este compromiso lineal de precio por rendimiento implica que la opción más barata suele ser un warehouse más grande que se ejecuta durante menos tiempo.

Existen dos dimensiones de escalado, y confundirlas es una trampa habitual en las entrevistas. El escalado vertical redimensiona un único warehouse para hacer una consulta más rápida. El escalado horizontal agrega clusters a un multi-cluster warehouse para atender más consultas concurrentes. Un dashboard al que acceden 200 analistas a las 9 de la mañana necesita más clusters, no uno más grande; un backfill nocturno de un billón de filas necesita uno más grande, no más clusters.

-- scale_compute.sql
-- Multi-cluster warehouse: add clusters when concurrency rises and
-- remove them when demand falls. Each cluster is a separate MEDIUM engine.
ALTER WAREHOUSE analytics_wh SET
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 4          -- up to 4 clusters during peak load
  SCALING_POLICY = 'STANDARD';   -- favor performance over credit savings

-- Resize vertically for one heavy job, then shrink back afterward.
ALTER WAREHOUSE analytics_wh SET WAREHOUSE_SIZE = 'XLARGE';
-- ... run the heavy backfill ...
ALTER WAREHOUSE analytics_wh SET WAREHOUSE_SIZE = 'MEDIUM';

AUTO_SUSPEND y AUTO_RESUME son lo que hace que esto sea económico. Un warehouse suspendido no cuesta nada, y Snowflake factura por segundo con un mínimo de 60 segundos. Configurar un auto-suspend corto en los warehouses interactivos evita que los clusters inactivos quemen créditos entre consultas.

Micro-partitions y clustering keys para un SQL rápido

Snowflake almacena cada tabla como un conjunto de micro-partitions, cada una con entre 50 y 500 MB de datos sin comprimir en formato columnar. Para cada micro-partition, Snowflake registra en sus metadatos el valor mínimo y máximo de cada columna. Cuando una consulta filtra por una columna, el optimizador lee esos metadatos y descarta cualquier partición cuyo rango de valores no pueda coincidir, un proceso llamado partition pruning. Por eso Snowflake no necesita índices manuales: el pruning ocurre de forma automática en cada columna.

El pruning funciona mejor cuando la columna del filtro se correlaciona con el orden en que se cargaron los datos. Una tabla ingerida por fecha realiza un pruning eficiente de consultas por rango de fechas. Cuando una tabla grande se filtra con frecuencia por una columna no relacionada con el orden de carga, un clustering key co-localiza filas relacionadas entre micro-partitions para que el pruning se mantenga efectivo a medida que la tabla crece.

-- clustering.sql
-- Filters on naturally ordered columns prune partitions with no index.
SELECT order_date, SUM(amount_usd) AS revenue
FROM orders
WHERE order_date BETWEEN '2026-01-01' AND '2026-03-31'
GROUP BY order_date;

-- For a multi-terabyte table queried by a non-load-order column,
-- a clustering key co-locates related rows to keep pruning effective.
ALTER TABLE orders CLUSTER BY (customer_region, order_date);

-- Inspect clustering depth before committing to a key.
SELECT SYSTEM$CLUSTERING_INFORMATION('orders', '(customer_region, order_date)');

Los clustering keys no son gratuitos: Snowflake ejecuta un servicio automático en segundo plano para mantenerlos, y ese servicio consume créditos. La regla práctica es agregar un clustering key solo a tablas del rango de terabytes donde los perfiles de consulta muestren un pruning deficiente. Las tablas más pequeñas realizan un buen pruning por sí solas, y un clustering key prematuro malgasta dinero. Explicar ese compromiso suele ser la diferencia entre una respuesta de nivel junior y una de nivel senior.

Carga y transformación de datos: Snowpipe, Streams y Dynamic Tables

Tres patrones de ingesta cubren la mayoría de las cargas de trabajo. El COPY INTO masivo carga archivos en staging con un único comando y encaja con trabajos batch programados. Snowpipe carga archivos de forma continua en micro-batches serverless, activados por eventos de cloud storage, para una llegada casi en tiempo real. Snowpipe Streaming envía filas individuales a través de una API de baja latencia cuando importa una frescura por debajo del segundo. Elegir entre ellos según los requisitos de latencia y tamaño de archivo es una pregunta frecuente en las entrevistas, y la respuesta correcta empieza con "depende de la frescura que realmente necesite el consumidor downstream".

La transformación dentro del warehouse dependió históricamente de Streams y Tasks. Un Stream captura los cambios a nivel de fila en una tabla (change data capture), y un Task ejecuta SQL de forma programada para consumir esos cambios y fusionarlos downstream.

-- incremental_pipeline.sql
-- A stream tracks row-level changes (CDC) on the raw landing table.
CREATE STREAM orders_stream ON TABLE raw_orders;

-- A task consumes the stream on a schedule and merges changes downstream.
CREATE TASK refresh_orders
  WAREHOUSE = analytics_wh
  SCHEDULE = '5 MINUTE'
  WHEN SYSTEM$STREAM_HAS_DATA('orders_stream')
AS
  MERGE INTO orders t
  USING orders_stream s ON t.order_id = s.order_id
  WHEN MATCHED THEN UPDATE SET t.amount_usd = s.amount_usd
  WHEN NOT MATCHED THEN INSERT (order_id, amount_usd)
    VALUES (s.order_id, s.amount_usd);

En 2026, las Dynamic Tables se han convertido en la forma preferida de expresar transformaciones incrementales. En lugar de conectar un Stream a un Task y escribir el merge a mano, una Dynamic Table declara un target lag y una consulta, y Snowflake resuelve el refresh incremental de forma automática. Elimina la mayor parte del código repetitivo de orquestación mientras mantiene los resultados frescos.

-- dynamic_table.sql
-- Dynamic Tables replace the stream + task pattern with a declarative
-- target lag. Snowflake computes the incremental refresh automatically.
CREATE DYNAMIC TABLE daily_revenue
  TARGET_LAG = '5 minutes'
  WAREHOUSE = analytics_wh
AS
  SELECT order_date, SUM(amount_usd) AS revenue
  FROM orders
  GROUP BY order_date;

Para los equipos que construyen sobre formatos abiertos, las tablas Iceberg de Snowflake permiten que el warehouse lea y escriba datos de Apache Iceberg almacenados en el propio bucket en la nube del cliente, lo que evita el lock-in mientras se conserva el motor de consultas y el gobierno de datos de Snowflake. Muchos equipos combinan Snowflake con dbt para transformaciones versionadas y testeadas, un flujo de trabajo que se cubre en la guía de transformaciones y testing de datos con dbt.

Preguntas de entrevista sobre Snowflake para ingenieros de datos

Las preguntas que siguen aparecen una y otra vez en las entrevistas de ingeniería de datos con Snowflake. Las respuestas sólidas conectan una función con la separación de almacenamiento y cómputo en lugar de recitar sintaxis.

¿Qué problema resuelve separar el almacenamiento del cómputo? Elimina la contención. Los analistas que ejecutan dashboards, un equipo de data science que entrena features y un trabajo ELT que carga datos pueden ejecutarse cada uno en su propio warehouse contra las mismas tablas sin competir por recursos ni copiar datos. El cómputo escala hacia arriba para un trabajo pesado y se suspende cuando está inactivo, mientras que el costo de almacenamiento se mantiene plano sin importar cuánto cómputo esté conectado.

¿Cómo funcionan Time Travel y zero-copy cloning? Ambos se apoyan en la inmutabilidad de las micro-partitions. Como Snowflake nunca sobrescribe una micro-partition, las versiones más antiguas permanecen en disco durante la ventana de retención (hasta 90 días en Enterprise). Time Travel consulta una tabla en un timestamp pasado apuntando a esas particiones más antiguas, y CLONE crea una nueva tabla que referencia las mismas particiones sin duplicar el almacenamiento hasta que uno de los lados se modifica. El copy-on-write es lo que hace que clonar una tabla de un petabyte sea instantáneo y casi gratuito.

¿Cuándo se debe definir un clustering key? Solo en tablas grandes (aproximadamente un terabyte o más) que se filtran o unen con frecuencia por una columna no relacionada con su orden de carga, y solo después de que un query profile confirme un pruning deficiente. El clustering conlleva un costo continuo de créditos por mantenimiento, así que es una optimización deliberada, no una opción por defecto.

¿Cómo se controla el costo en Snowflake? Mediante el dimensionamiento de los warehouses, un auto-suspend agresivo, ajustar el número de clusters a la concurrencia real y resource monitors que limitan el gasto de créditos. Un resource monitor puede notificar o suspender warehouses de forma automática una vez que se alcanza una cuota.

-- cost_control.sql
-- A resource monitor caps credit spend and suspends warehouses
-- automatically when the monthly quota is reached.
CREATE RESOURCE MONITOR monthly_cap
  WITH CREDIT_QUOTA = 1000
  FREQUENCY = MONTHLY
  START_TIMESTAMP = IMMEDIATELY
  TRIGGERS
    ON 80 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND;

ALTER WAREHOUSE analytics_wh SET RESOURCE_MONITOR = monthly_cap;

¿Streams y Tasks o Dynamic Tables? Las Dynamic Tables encajan con pipelines declarativos donde el requisito es una frescura objetivo y Snowflake puede gestionar el refresh. Los Streams y Tasks siguen siendo la herramienta adecuada cuando la transformación necesita control imperativo, efectos secundarios o una lógica que una sola consulta no puede expresar. Saber dónde encaja cada uno, en lugar de recurrir siempre al mismo, indica experiencia en producción.

¿En qué se diferencia el ELT en Snowflake del ETL tradicional? El almacenamiento económico y el cómputo elástico de Snowflake hacen práctico cargar primero los datos crudos y transformarlos in situ, el patrón que se explora en la guía de arquitectura ETL vs ELT. Quienes se preparan para el ciclo completo pueden practicar con el módulo de patrones ETL y ELT junto con el track más amplio de data engineering.

Conclusión

• La arquitectura de Snowflake separa el almacenamiento, el cómputo y los cloud services en tres capas independientes, y casi cada respuesta de diseño se remonta a esa separación
• Los virtual warehouses escalan verticalmente para consultas individuales más pesadas y horizontalmente para mayor concurrencia; el auto-suspend y la facturación por segundo mantienen el cómputo inactivo sin costo
• Las micro-partitions con metadatos de mínimo/máximo por columna dan un partition pruning automático, razón por la cual Snowflake no necesita índices manuales
• Agregar clustering keys solo a tablas a escala de terabytes con un pruning deficiente comprobado, ya que el mantenimiento consume créditos
• Ajustar el patrón de ingesta a la frescura requerida: COPY masivo para batch, Snowpipe para micro-batches continuos, Snowpipe Streaming para latencia por debajo del segundo
• Preferir las Dynamic Tables para transformaciones incrementales declarativas en 2026, y reservar los Streams y Tasks para lógica imperativa
• Time Travel y zero-copy cloning explotan la inmutabilidad de las micro-partitions y el copy-on-write, lo que hace económicas las consultas puntuales en el tiempo y los clones instantáneos
• Controlar el costo con warehouses bien dimensionados, un auto-suspend agresivo, clusters ajustados a la concurrencia y resource monitors