24 ago 2026/9 min de lecturaData Engineering
Snowpipe Streaming: transmite datos de forma sencilla a Apache Iceberg
Evaluación de streaming a gran escala sin la carga de gestionar infraestructura
Si tu equipo quiere comprobar si Snowpipe Streaming mantiene el rendimiento por encima de 1 millón de transacciones por segundo (TPS), necesitas el camino más corto para obtener una respuesta real. Streaming a gran escala se ha ganado cierta reputación. Es el workload que los equipos dejan para más adelante, porque ponerlo en marcha exige buckets S3, un clúster de EKS, topics Kafka, políticas de gestión de identidad y acceso (IAM), una revisión de seguridad y la aprobación de tres equipos de plataforma, cada uno con su propia lista de tareas pendientes. Esta configuración puede requerir aprovisionamiento de infraestructura y coordinación adicionales antes de comenzar las pruebas. Demostrar que estos pipelines funcionan a esa escala y pueden gestionar volúmenes de producción suele ser un proyecto en sí mismo.
En nuestro entorno de demostración, pudimos configurar y ejecutar esta evaluación en una tarde. Puedes usar nuestra arquitectura de alto rendimiento de Snowpipe Streaming para transmitir datos al formato Apache Iceberg™ a más de 1 millón de TPS, íntegramente en la infraestructura de Snowflake. Un contenedor que se ejecuta en Snowpark Container Services (SPCS) genera la carga, la transmite a través del SDK y la deposita en una tabla de Iceberg gestionada por Snowflake. Así, los datos se pueden consultar de inmediato en Snowflake, con el control de acceso basado en roles (RBAC), el linaje y el enmascaramiento aplicados a medida que llegan. En nuestro entorno de prueba, montamos la demostración, la probamos de extremo a extremo, medimos el rendimiento y la desmontamos en una tarde.
En este artículo te explicamos paso a paso cómo crear una demostración de streaming a Iceberg de extremo a extremo mediante este repositorio de GitHub. Este ejemplo está escrito en Python, pero puedes probar las distintas opciones del SDK (Java, Python, Node y REST) para poder recomendar con argumentos esta solución a tu empresa y mostrar resultados reales.
Diagrama de la arquitectura: el patrón
Queríamos crear una demostración en la que todo se ejecutara dentro de la infraestructura de Snowflake. Varios contenedores de Docker que se ejecutan en Snowpark Container Services (SPCS) generan datos sintéticos de prueba a la tasa de transacciones por segundo deseada y los transmiten en tiempo real mediante el SDK de Snowpipe Streaming. Los datos se cargan en una tabla de Iceberg gestionada por Snowflake: un formato abierto que permite consultarlos pocos segundos después de su llegada y aplicarles la gobernanza en Snowflake. La autenticación es sencilla: SPCS inyecta en el contenedor un token OAuth de corta duración e indica al SDK de Streaming que lo utilice. No necesitas gestionar ningún secreto.
¿Por qué usar SPCS para generar la carga?
Para que quede claro, Snowpipe Streaming no necesita SPCS. El SDK se ejecuta en cualquier lugar: tu portátil, una instancia EC2 o un pod de Kubernetes.
Al ejecutarlo en SPCS, puedes empezar la prueba más rápido, ya que el servicio se ejecuta íntegramente en infraestructura que Snowflake ya gestiona, sin tener que aprovisionar nada nuevo ni gestionar aprobaciones adicionales para la propia prueba.
Carga directa en Iceberg
La tabla de destino es una tabla de Iceberg gestionada por Snowflake. Las filas se transmiten a través del SDK y se cargan en formato Parquet con metadatos de Iceberg, todo ello gestionado por Snowflake. Más adelante, si quieres, puedes configurarla para que use tu propio volumen externo de S3 o dejarla gestionada por Snowflake tras la evaluación. El código no cambia en ninguno de los dos casos.
Para la evaluación, esto reduce la configuración necesaria. Con una tabla en el almacenamiento gestionado por Snowflake, puedes prescindir del volumen externo, la integración de almacenamiento y los permisos de almacenamiento en la nube que, de lo contrario, tendrías que configurar primero.
Cuando quieras llevar la solución a producción, dispones de tres vías claras:
- Iceberg gestionado por Snowflake con un volumen externo: Los archivos Parquet se almacenan en tu bucket S3. Un motor externo lee los archivos Parquet directamente desde S3 y utiliza Horizon REST Catalog para los metadatos.
- Iceberg gestionado por Snowflake en el almacenamiento de Snowflake: Los archivos se encuentran en el almacenamiento interno de Snowflake. Esta opción evita tener que configurar un volumen externo y el almacenamiento en la nube asociado. Aprovecha las funciones de Iceberg para favorecer la compatibilidad de cara al futuro.
- Tabla nativa de Snowflake: Esta configuración no requiere infraestructura de almacenamiento externo gestionada por separado.
Demostración: observa cómo funciona
Al ejecutar el script de la demostración, puedes ver cómo se inicia el servicio de SPCS, el productor comienza a generar la carga y el consumidor transmite los datos a la tabla de Iceberg.
Puedes pasar a Snowsight y ver cómo aumenta también aquí el número de filas: millones de filas que se pueden consultar a medida que llegan.
El código: cómo crearlo por tu cuenta
Para ayudarte a entender cómo funciona todo, aquí tienes pseudocódigo ilustrativo. El código completo está en el repositorio y, más abajo, encontrarás enlaces a varias demostraciones alternativas.
Comienza con una tabla de Iceberg gestionada por Snowflake y un pipe:
-- 1. The target table
CREATE OR REPLACE ICEBERG TABLE events (
event_id STRING,
event_ts TIMESTAMP_NTZ,
payload VARIANT
)
CATALOG = 'SNOWFLAKE'
BASE_LOCATION = 'events/'
ICEBERG_VERSION = 3;
-- 2. The streaming pipe (extracts typed fields from the SDK's VARIANT payload)
CREATE OR REPLACE PIPE events_pipe
AS COPY INTO events (event_id, event_ts, payload)
FROM (
SELECT $1:event_id::STRING,
$1:event_ts::TIMESTAMP_NTZ,
$1:payload::VARIANT
FROM TABLE(DATA_SOURCE(TYPE => 'STREAMING'))
);
La arquitectura de alto rendimiento de Snowpipe Streaming es compatible con las versiones v2 y v3, pero, si se omite el parámetro, la tabla utiliza la versión v2 de forma predeterminada.
A continuación, el consumidor:
from snowflake.ingest.streaming import StreamingIngestClient
# SPCS injects credentials automatically - no keys, no secrets
props = {
"account": "YOUR_ACCOUNT",
"user": "YOUR_USER",
"role": "STREAMING_SERVICE_ROLE",
"url": "https://YOUR_ACCOUNT.snowflakecomputing.com",
"authorization_type": "SPCS",
"spcs_token_path": "/snowflake/session/token",
}
# Connect to the pipe
client = StreamingIngestClient(
client_name="my_consumer",
db_name="STREAMING_DEMO",
schema_name="PUBLIC",
pipe_name="events_pipe",
properties=props,
)
# Open a channel and stream rows
channel, status = client.open_channel("ch_1")
for i, row in enumerate(generate_load()):
channel.append_row(row, offset_token=str(i))
# Close cleanly
channel.close()
client.close()
Después, despliega el consumidor en SPCS con una breve especificación del servicio. Y observa cómo llegan los datos:
SELECT
COUNT(*) AS rows_landed,
MAX(event_ts) AS latest_event
FROM
streaming_demo.public.events;Java, Node y la interfaz REST siguen el mismo patrón: abrir un canal, insertar filas y vaciar el búfer. En el repositorio encontrarás un ejemplo funcional para cada uno, por lo que puedes probar el que mejor se adapte a tu stack.
Para probarlo por tu cuenta, puedes consultar el repositorio.
Pero ten en cuenta que el SDK de Streaming utiliza un punto de conexión de ingesta independiente a través de HTTPS. Por tanto, aunque ejecutes el proceso dentro de Snowflake, debes conceder una integración de acceso externo que permita el tráfico saliente de vuelta a *.snowflakecomputing.com.
Prácticas recomendadas
Snowpipe Streaming se encarga de agrupar los datos por lotes
Snowpipe Streaming no escribe un archivo por cada fila. El SDK envía las filas en cuanto llamas a appendRows, pero una capa de almacenamiento en búfer del lado del servidor las absorbe y determina el momento de confirmación de forma autónoma. Las agrupa internamente en lotes para que nunca envíes un archivo por cada fila.
Además, Snowflake ejecuta la compactación automática en segundo plano para las tablas de Iceberg gestionadas por Snowflake en las que Snowflake es el único sistema que escribe: los archivos Parquet pequeños se fusionan en otros más grandes y los manifiestos pequeños también se compactan. No tienes que programarla ni ejecutarla: forma parte del funcionamiento normal.
Lo que puedes hacer:
- Agrupa las filas en lotes en el cliente antes de llamar a
appendRows: Enviar las filas de una en una sigue suponiendo un viaje de ida y vuelta por fila; agruparlas en una sola llamada permite amortizar esa sobrecarga, el mismo principio que subyace en las propias recomendaciones de Snowflake de comprimir y enviar más datos por solicitud. - Mantén los canales activos durante toda la ejecución: Abre un canal una sola vez por cada partición de origen y déjalo abierto durante toda la ejecución del trabajo, en lugar de abrirlo y cerrarlo con cada microlote. Es la práctica recomendada para Snowpipe Streaming que Snowflake documenta, y reduce la sobrecarga sin interferir con el procesamiento por lotes que ya tiene lugar en segundo plano.
- Configura
TARGET_FILE_SIZEen la tabla: Esta propiedad a nivel de tabla, independiente del SDK, indica a Snowflake el tamaño objetivo tanto para las nuevas escrituras como para la compactación en segundo plano, con independencia de cómo hayan llegado los datos. - Deja que la capacidad de procesamiento haga el trabajo: Cuanto mayor sea la tasa sostenida de TPS, más rápido se llenará y vaciará el búfer del lado del servidor de forma autónoma, lo que, en la práctica, supone un equilibrio entre la capacidad de procesamiento y la latencia para un tamaño de archivo determinado.
Próximamente: Iceberg v4
Snowpipe Streaming y la compactación automática solucionan el problema físico de los archivos pequeños, pero las confirmaciones frecuentes aún pueden generar sobrecarga en el árbol de metadatos de Iceberg. Actualmente, cada confirmación genera un nuevo archivo JSON de metadatos, una lista de manifiestos y un manifiesto, incluso cuando solo contiene un archivo pequeño. En el caso de los workloads que realizan una confirmación cada pocos segundos, ese trabajo repetido con los metadatos puede convertirse en un cuello de botella.
La propuesta de Iceberg v4 introduce un árbol de metadatos adaptativo (Adaptive Metadata Tree) para reducir esa amplificación de escritura. En lugar de crear un nuevo manifiesto para cada confirmación pequeña, el manifiesto raíz puede incorporar en línea esas confirmaciones. Una única escritura en Parquet y un intercambio atómico de puntero sustituyen la cadena actual, lo que mantiene constantes las operaciones de entrada y salida de metadatos por confirmación, en lugar de escalar con el número de manifiestos. En los workloads de streaming de alta frecuencia, esto puede mejorar de forma significativa la latencia de streaming.
Streaming es uno de los casos de uso estrella de Iceberg v4: los workloads con confirmaciones cada pocos segundos exponen directamente la amplificación de escritura de metadatos, lo que hace que las ventajas del Adaptive Metadata Tree sean especialmente relevantes. La especificación v4 sigue evolucionando, pero merece la pena seguirla de cerca si el streaming de Iceberg forma parte de tu hoja de ruta. Snowflake se enorgullece de participar activamente en la definición del futuro del formato.
Qué significa esto para tu arquitectura
En este artículo, hemos demostrado lo eficaz que puede ser Snowpipe Streaming para transmitir datos a Iceberg. Con niveles de carga propios de una plataforma de medios o telecomunicaciones de gran envergadura, y sin que esta configuración de prueba requiriese ningún bucket S3, clúster de EKS, topic Kafka ni rol de IAM, el workload se ejecutó dentro de Snowflake y pudo desmantelarse tras la evaluación.
La infraestructura que suele interponerse entre un equipo y una prueba de streaming (los buckets, los clústeres, la autenticación y las aprobaciones) no es un requisito previo. Puedes responder a la pregunta: “¿cumple esto nuestros requisitos con rapidez?”.
Si trabajas en el ámbito de la ingeniería de fiabilidad de sitios (SRE) o la ingeniería de datos en una gran plataforma de medios o telecomunicaciones, y el streaming de Iceberg forma parte de tu hoja de ruta, empieza por la prueba, no por el ciclo de adquisición. Te invitamos a clonar el repositorio, desplegarlo en SPCS y verlo en funcionamiento.
- Pruébalo ahora con el repositorio de GitHub.
- Profundiza en tus conocimientos y consulta la documentación sobre la arquitectura de alto rendimiento de Snowpipe Streaming.
