Hay un momento en cualquier pipeline de datos en el que el batch programado deja de tener sentido. No porque esté mal diseñado, sino porque el negocio empieza a pedir datos con una frescura que un job cada hora, o cada quince minutos, ya no puede darte. Y la respuesta obvia —bajar el intervalo del scheduler— tiene un límite: en algún punto estás pagando un warehouse encendido casi todo el rato para procesar cada vez menos datos por ejecución.
Snowpipe resuelve ese problema desde otro ángulo. En vez de preguntar «¿ya hay archivos nuevos?» cada X minutos, escucha. Cuando llega un archivo al stage, la carga se dispara sola. No hay warehouse que arrancar ni scheduler que mantener: el cómputo lo gestiona Snowflake por detrás, en un servicio serverless pensado justo para esto.
Cómo encaja en la arquitectura
Snowpipe no sustituye a un COPY INTO programado, lo complementa para el caso en que la latencia importa. La pieza central es el objeto pipe: una definición que envuelve un COPY INTO y lo asocia a un stage. Ese pipe se puede disparar de dos formas.
La primera es auto-ingest: configuras una notificación de eventos en el almacenamiento de la nube (Amazon S3 y SQS, Azure Blob Storage y Event Grid o Google Cloud Storage y Pub/Sub) para que avise a Snowflake cada vez que aparece un archivo nuevo. Snowflake recoge el evento, ejecuta el COPY INTO del pipe correspondiente y listo. No hay polling de ningún tipo; es notificación pura.
La segunda es vía API REST de Snowpipe: llamas al endpoint insertFiles de Snowpipe cuando tu propio proceso sabe que ha dejado un archivo listo. Es la opción cuando no quieres depender de la mensajería nativa del cloud provider, o cuando el archivo lo genera un sistema que ya tienes orquestado y prefieres controlar tú el disparo.
En ambos casos, lo que ejecuta el pipe no es un warehouse virtual normal. Es compute serverless, gestionado por Snowflake, que se factura por el uso real. No hay que dimensionar nada ni mantener un warehouse activo a la espera: el compute aparece cuando hace falta y desaparece cuando termina.
Lo que se gana
Latencia sin operar infraestructura. El tiempo típico entre que un archivo llega al stage y los datos están disponibles en la tabla ronda el minuto, a veces menos. Comparado con un batch cada hora, es un salto de categoría, y no hay que tocar Airflow, ADF ni ningún orquestador para conseguirlo.
Coste alineado con el uso real. No pagas por un warehouse encendido esperando archivos. Pagas por el compute que realmente consume cada carga. Para volúmenes de ingesta continua pero no masiva, esto suele salir bastante más barato que tener un warehouse XS corriendo cada cinco minutos «por si acaso». Puedes consultar los detalles del modelo de facturación en la documentación oficial sobre los costes de Snowpipe.
Desacoplo total del proceso que genera los datos. Al sistema que deja archivos en el stage no le importa si hay un Snowpipe escuchando o no. Simplemente escribe en S3, en Blob Storage o donde toque, con su cadencia habitual. La ingesta a Snowflake es un problema resuelto aparte, sin acoplar el pipeline origen con la lógica de carga.
Reintentos y tracking incorporados. Snowpipe lleva un registro de qué archivos ha cargado ya, así que si el mismo archivo aparece dos veces (reprocesos, reintentos del sistema origen) no lo duplica. Y si una carga falla, queda reflejado en el historial sin que tengas que instrumentar tú el control de errores desde cero.
Snowpipe Streaming: cuando ni siquiera quieres pasar por archivos
La evolución más reciente es Snowpipe Streaming, y cambia bastante el planteamiento. En lugar de escribir archivos en un stage y esperar a que Snowpipe los recoja, el SDK de Snowpipe Streaming permite insertar filas directamente, sin pasar por un archivo intermedio. Piensa en un consumer de Kafka que, en vez de volcar a disco y luego cargar, empuja las filas a Snowflake una a una (o en micro-lotes) según llegan.
Esto reduce la latencia todavía más —hablamos de segundos, no de minutos— y elimina un paso entero del proceso: ya no hay que generar, nombrar y gestionar archivos solo para que existan un rato antes de ser cargados. Para casos de uso con eventos de aplicación, IoT o CDC de bases de datos transaccionales, encaja de forma bastante natural.
La contrapartida es que Snowpipe Streaming vive a nivel de código: se integra desde una aplicación Java o vía Kafka Connect, no es algo que configures declarativamente como un pipe clásico. Es una herramienta distinta para un problema relacionado, no un simple «modo rápido» del Snowpipe de toda la vida.
Costes y observabilidad
Snowflake expone varias vistas para saber qué está pasando con tus pipes sin tener que adivinarlo. PIPE_USAGE_HISTORY te da el consumo de créditos por pipe y por franja horaria, así que cuando llega la factura sabes exactamente qué pipe está costando qué. COPY_HISTORY muestra el detalle de cada carga: cuántas filas, cuántos errores, qué archivo. Y SYSTEM$PIPE_STATUS te dice en tiempo real si un pipe está pausado, si tiene archivos pendientes en la cola de notificaciones o si algo se ha quedado atascado.
Vale la pena montar una alerta sobre esto último. Un pipe puede quedarse silenciosamente sin recibir notificaciones —por ejemplo, si alguien toca la configuración del bucket o rota las credenciales del rol— y en ese caso los datos simplemente dejan de llegar sin que salte ningún error visible en el flujo normal. Sin monitorización activa, es fácil no detectarlo hasta que alguien revisa el dashboard y ve que lleva días sin actualizarse.
¿Quieres optimizar tus pipelines de datos?
¿Estás buscando mejorar la ingesta de datos en tu organización y aprovechar todo el potencial de Snowflake? En Bravent te ayudamos a diseñar arquitecturas de datos más eficientes, adaptadas a las necesidades de tu negocio y preparadas para crecer. Escríbenos a info@bravent.net y descubre cómo optimizar tus pipelines de datos para llevar la información allí donde la necesitas, cuando la necesitas.
