24 agosto 2026/Lettura: 8 minData engineering
Semplifica lo streaming su Apache Iceberg con Snowpipe Streaming
Valutare lo streaming su larga scala senza oneri infrastrutturali
Se il tuo team vuole capire se Snowpipe Streaming regge oltre 1 milione di TPS, serve la via più breve per una risposta concreta. Lo streaming su larga scala ha una certa fama. È il workload che i team rimandano sempre, perché metterlo in piedi significa bucket S3, un cluster EKS, topic Kafka, policy IAM, una revisione di sicurezza e l’approvazione di tre team di piattaforma, ognuno con il proprio backlog. Questa configurazione può richiedere provisioning infrastrutturale aggiuntivo e attività di coordinamento prima ancora di iniziare i test. Dimostrare che queste pipeline funzionano su larga scala e gestiscono i volumi di produzione è di solito un progetto a sé.
Nel nostro ambiente demo abbiamo configurato ed eseguito questa valutazione in un pomeriggio. Puoi usare la nostra architettura ad alte prestazioni di Snowpipe Streaming per inviare dati in streaming nel formato Apache Iceberg™ a oltre 1 milione di TPS, interamente all’interno dell’infrastruttura Snowflake. Un container in esecuzione in Snowpark Container Services (SPCS) genera il carico, lo invia in streaming attraverso l’SDK e lo scrive in una Iceberg Table gestita da Snowflake. Così i dati sono immediatamente pronti per l’esecuzione di query in Snowflake, con controllo degli accessi basato sui ruoli (RBAC), lineage e masking applicati già in fase di arrivo. Nel nostro ambiente di test abbiamo allestito la demo, l’abbiamo testata end to end, misurato il throughput e smantellato tutto in un pomeriggio, come è avvenuto nel nostro test.
Questo post ti guida passo per passo nello sviluppo di una demo di streaming end to end verso Iceberg, usando questo repository GitHub. Questo esempio è in Python, ma puoi testare tutte le opzioni SDK (Java, Python, Node, REST), così da poter proporre la soluzione al business con risultati concreti alla mano.
Diagramma dell’architettura: il pattern
Volevamo sviluppare una demo in cui tutto gira all’interno dell’infrastruttura Snowflake. Più container Docker in esecuzione in Snowpark Container Services (SPCS) generano dati di test sintetici al numero di transazioni al secondo desiderato e li inviano in streaming tramite l’SDK Snowpipe Streaming. I dati arrivano in una Iceberg Table gestita da Snowflake: formato open, interrogabile pochi secondi dopo l’arrivo, governato in Snowflake. L’autenticazione è semplice: SPCS inserisce nel container un token OAuth di breve durata e indica allo Streaming SDK di utilizzarlo. Non devi gestire alcun secret.
Perché usare SPCS per generare il carico?
Chiariamo subito: Snowpipe Streaming non ha bisogno di SPCS. L’SDK gira ovunque: il tuo laptop, un’istanza EC2, un pod Kubernetes.
Metterlo in SPCS ti porta al test più rapidamente, perché il servizio gira interamente su un’infrastruttura già gestita da Snowflake, senza nulla di nuovo da provisionare né approvazioni aggiuntive da gestire per il test stesso.
Scrivere direttamente in Iceberg
Il target è una Iceberg Table gestita da Snowflake. Le righe arrivano in streaming attraverso l’SDK e si materializzano come file Parquet con metadati Iceberg, gestiti da Snowflake. Se vuoi, più avanti puoi puntarla a un tuo volume esterno S3, oppure lasciarla gestita da Snowflake dopo la valutazione. Il codice resta lo stesso in entrambi i casi.
Per la valutazione significa meno configurazione. Una tabella su storage gestito da Snowflake ti evita il volume esterno, l’integrazione dello storage e i permessi di cloud storage che altrimenti dovresti configurare prima.
Quando sei pronto per il passaggio in produzione, hai tre strade chiare:
- Iceberg gestito da Snowflake con volume esterno: i file Parquet sono archiviati nel tuo bucket S3. Un motore esterno legge i file Parquet direttamente da S3, usando l’Horizon REST Catalog per i metadati.
- Iceberg gestito da Snowflake su storage Snowflake: i file risiedono nello storage interno Snowflake. Questa opzione evita di configurare un volume esterno e il cloud storage associato. Sfrutta le funzionalità Iceberg per garantire la compatibilità in futuro.
- Tabella Snowflake nativa: per questa configurazione non serve alcuna infrastruttura di storage esterno gestita separatamente.
Demo: vediamola in funzione
Quando esegui lo script della demo, vedi il servizio SPCS che si avvia, il producer che inizia a generare il carico e il consumer che lo invia in streaming nella Iceberg Table.
Puoi passare a Snowsight e vedere anche qui il conteggio delle righe che sale: milioni di righe, interrogabili appena arrivano.
Il codice: svilupparlo da zero
Per capire meglio come funziona il tutto, ecco un po’ di pseudocodice che aiuta a visualizzarne il funzionamento. Il codice completo è nel repository e qui sotto trovi i link a diverse demo alternative.
Si parte da una Iceberg Table gestita da Snowflake e da una 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'))
);
L’architettura ad alte prestazioni di Snowpipe Streaming supporta sia la v2 sia la v3, ma se ometti il parametro la tabella viene impostata per default sulla v2.
Passiamo al consumer:
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()
Poi distribuisci il consumer su SPCS con una breve service spec. E osservi i dati arrivare:
SELECT
COUNT(*) AS rows_landed,
MAX(event_ts) AS latest_event
FROM
streaming_demo.public.events;Java, Node e l’interfaccia REST seguono lo stesso schema: apri un canale, inserisci le righe, esegui il flush. Nel repository c’è un esempio funzionante per ciascuno, così puoi testare quello adatto al tuo stack.
Per provare tutto questo, dai un’occhiata al repository.
Tieni presente però che lo Streaming SDK utilizza un endpoint di ingest separato su HTTPS: quindi, anche se esegui il codice all’interno di Snowflake, devi concedere un’integrazione di accesso esterno che consenta l’egress verso *.snowflakecomputing.com.
Best practice
Il batching lo fa Snowpipe Streaming
Snowpipe Streaming non scrive un file per ogni riga. L’SDK invia le righe appena chiami appendRows, ma un livello di buffering lato server le assorbe e decide autonomamente il momento del commit, raggruppandole dietro le quinte così non spedisci mai un file per riga.
Non solo: Snowflake esegue in background la compattazione automatica delle Iceberg Tables gestite da Snowflake in cui è l’unico writer: i file Parquet di piccole dimensioni vengono uniti in file più grandi e anche i manifest piccoli vengono compattati. Non devi pianificarla né eseguirla: fa parte del normale funzionamento.
Cosa puoi fare:
- Raggruppa le righe in batch lato client prima di chiamare
appendRows: inviare le righe una alla volta comporta comunque un roundtrip per riga; raggrupparle in un’unica chiamata ammortizza questo overhead operativo, secondo lo stesso principio delle indicazioni Snowflake sulla compressione e sull’invio di più dati per richiesta. - Mantieni i canali attivi a lungo: apri un canale una volta per ogni partizione di origine e lascialo aperto per tutta la durata del processo, invece di aprirlo e chiuderlo a ogni micro-batch. È la best practice documentata da Snowflake per Snowpipe Streaming e riduce l’overhead operativo senza ostacolare il batching che avviene già a livello sottostante.
- Imposta
TARGET_FILE_SIZEsulla tabella: si tratta di una proprietà a livello di tabella, indipendente dall’SDK, che indica a Snowflake quale dimensione target usare sia per le nuove scritture sia per la compattazione in background, indipendentemente da come i dati sono arrivati. - Lascia lavorare il throughput: più alto è il TPS sostenuto, più rapidamente il buffer lato server si riempie e si svuota da solo, il che si traduce di fatto in un compromesso tra throughput e latenza per una data dimensione dei file.
Cosa aspettarsi: Iceberg v4
Snowpipe Streaming e la compattazione automatica risolvono il problema fisico dei file di piccole dimensioni, ma i commit frequenti possono comunque generare overhead operativo nell’albero dei metadati di Iceberg. Oggi ogni commit scrive un nuovo file JSON di metadati, una manifest list e un manifest, anche quando contiene un solo file di piccole dimensioni. Per i workload che eseguono commit ogni pochi secondi, questo lavoro ripetuto sui metadati può diventare un collo di bottiglia.
La proposta Iceberg v4 introduce un Adaptive Metadata Tree per ridurre questa amplificazione delle scritture. Invece di creare un nuovo manifest per ogni piccolo commit, il manifest root può includerli inline. Una singola scrittura Parquet e uno scambio atomico di puntatori sostituiscono l’attuale catena, mantenendo costante l’I/O sui metadati per commit invece di farlo crescere con il numero di manifest. Per i workload di streaming ad alta frequenza, questo può migliorare drasticamente la latenza dello streaming.
Lo streaming è uno degli scenari di punta per Iceberg v4: i workload che eseguono commit ogni pochi secondi mettono in evidenza l’amplificazione delle scritture di metadati, e questo rende i vantaggi dell’Adaptive Metadata Tree particolarmente rilevanti. Le specifiche della v4 sono ancora in evoluzione, ma vale la pena seguirle se lo streaming Iceberg è nella tua roadmap. Snowflake è orgogliosa di partecipare attivamente alla definizione del futuro di questo formato.
Cosa significa per la tua architettura
In questo post abbiamo dimostrato quanto può essere efficace Snowpipe Streaming verso Iceberg. Con il tipo di carico su cui gira una vera piattaforma media o telco e senza bucket S3, cluster EKS, topic Kafka o ruoli IAM per questo setup di test, il workload è stato eseguito all’interno di Snowflake e si è potuto smantellare dopo la valutazione.
L’infrastruttura che normalmente si frappone tra un team e un test di streaming, ossia bucket, cluster, autenticazione e approvazioni, non è un prerequisito. Puoi rispondere rapidamente: “Soddisfa i nostri requisiti?”.
Se lavori nel Site Reliability Engineering (SRE) o nel data engineering di una grande piattaforma media o telco e lo streaming Iceberg è nella roadmap, parti dal test, non dal ciclo di approvvigionamento. Ti invitiamo a clonare il repository, distribuirlo su SPCS e vederlo in azione.
- Provalo subito con il repository GitHub
- Approfondisci con la documentazione dell’architettura ad alte prestazioni di Snowpipe Streaming
