24 de ago. de 2026/Leitura: 9 minData Engineering
Snowpipe Streaming: a solução para transmitir dados com facilidade para o Apache Iceberg
Avaliação de streaming em escala real sem o peso da infraestrutura
Para uma equipe que quer saber se o Snowpipe Streaming continua funcionando a mais de 1 milhão de TPS, o caminho mais rápido é ir direto à resposta concreta. O streaming em escala é famoso por um motivo. É a carga de trabalho que as equipes deixam para depois, porque colocá-la em produção exige buckets S3, um cluster EKS, tópicos Kafka, políticas IAM, revisão de segurança e aprovação de três equipes de plataforma, cada uma com seu próprio backlog. Essa configuração pode exigir provisionamento adicional de infraestrutura e coordenação antes mesmo que os testes comecem. Por si só, comprovar que esses pipelines funcionam na escala necessária e dão suporte ao volume de produção já é um projeto.
Em nosso ambiente de demonstração, conseguimos configurar e executar essa avaliação em uma tarde. Você pode usar nossa Snowpipe Streaming High-Performance Architecture para fazer streaming de dados no formato Apache Iceberg™ a mais de 1 milhão de TPS, totalmente dentro da infraestrutura do Snowflake. Um container em execução no Snowpark Container Services (SPCS) gera a carga, transmite os dados via SDK e os grava em uma tabela Iceberg gerenciada pelo Snowflake. Isso deixa os dados prontos para consulta no Snowflake, de modo imediato, com controle de acesso baseado em função (RBAC), linhagem e mascaramento aplicados no momento em que chegam. Em nosso ambiente de teste, montamos a demonstração, testamos de ponta a ponta, medimos o throughput (taxa de transmissão) e desativamos tudo em uma tarde, como fizemos em nosso teste.
O artigo tem como objetivo mostrar como criar, de fato, uma demonstração de streaming de ponta a ponta para o Iceberg, usando este repositório do GitHub. Este exemplo está em Python, mas você pode testar as opções do SDK (Java, Python, Node, REST), para que possa recomendar essa solução à sua empresa com resultados reais para mostrar.
Diagrama de arquitetura: o padrão
Nossa intenção foi criar uma demonstração onde tudo fosse executado dentro da infraestrutura do Snowflake. Vários containers Docker em execução no Snowpark Container Services (SPCS) geram dados de teste sintéticos na taxa de transações por segundo desejada e os transmitem usando o SDK do Snowpipe Streaming. Eles chegam a uma tabela Iceberg gerenciada pelo Snowflake: formato aberto, consultável poucos segundos depois da chegada e governado no Snowflake. A autenticação é simples: o SPCS injeta um token OAuth de curta duração no container, informando ao SDK de streaming para usá-lo. Você não precisa gerenciar nenhum segredo.
Por que usar o SPCS para gerar a carga?
Para deixar claro, o Snowpipe Streaming não precisa do SPCS. O SDK é executado em qualquer lugar: no seu laptop, em uma instância EC2 ou em um pod do Kubernetes.
Usar o SPCS é o que permite o teste mais rápido, já que o serviço é executado totalmente em uma infraestrutura que o Snowflake já gerencia, sem nada novo para provisionar nem aprovações adicionais a gerenciar para o teste em si.
Gravando direto no Iceberg
O destino é uma tabela Iceberg gerenciada pelo Snowflake. As linhas chegam por streaming pelo SDK e são gravadas como Parquet com metadados Iceberg, gerenciados pelo Snowflake. Depois, se quiser, você pode direcioná-la para seu próprio volume externo do S3, ou deixá-la gerenciada após a avaliação. O código permanece o mesmo nos dois casos.
Para a avaliação, isso significa menos configuração. Uma tabela em armazenamento gerenciado pelo Snowflake elimina a necessidade do volume externo, da integração de armazenamento e das permissões de armazenamento na nuvem que, de outra forma, você teria que configurar antes.
Quando estiver pronto para colocar em produção, é possível seguir três caminhos claros:
- Iceberg gerenciado pelo Snowflake com volume externo: os arquivos Parquet são armazenados no seu bucket do S3. Um mecanismo externo lê os arquivos Parquet diretamente do S3, usando o Horizon REST Catalog para os metadados.
- Iceberg gerenciado pelo Snowflake em armazenamento do Snowflake: os arquivos ficam no armazenamento interno do Snowflake. Essa opção evita a configuração de um volume externo e do armazenamento na nuvem associado. Aproveita os recursos do Iceberg para garantir a compatibilidade no futuro.
- Tabela nativa do Snowflake: essa configuração não exige nenhuma infraestrutura de armazenamento externo gerenciada separadamente.
Demonstração: acompanhe o funcionamento
Quando você executa o script da demonstração, é possível ver o serviço do SPCS sendo iniciado, o produtor começando a gerar a carga e o consumidor transmitindo os dados para a tabela Iceberg.
Você também pode alternar para o Snowsight e ver a contagem de linhas aumentar ali: milhões de linhas, consultáveis assim que chegam.
O código: como criá-lo por conta própria
Para ajudar a entender como tudo isso funciona, aqui está um pseudocódigo que ajuda a visualizar o processo. O código completo está no repositório, e há várias demonstrações alternativas com links logo a seguir.
Comece com uma tabela Iceberg gerenciada pelo Snowflake e um 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'))
);
A arquitetura de alta performance do Snowpipe Streaming é compatível com as versões v2 e v3, mas, se o parâmetro for omitido, a tabela usa v2 por padrão.
Em seguida, o 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()
Depois, você implementa o consumidor no SPCS com uma especificação de serviço simples. E você observa os dados chegarem:
SELECT
COUNT(*) AS rows_landed,
MAX(event_ts) AS latest_event
FROM
streaming_demo.public.events;Java, Node e a interface REST seguem o mesmo padrão: abrir um canal, inserir linhas, fazer flush. No repositório, há um exemplo funcional para cada uma, então você pode testar o que combina com o seu stack (ou arquitetura).
Para testar você mesmo, confira o repositório.
Mas atenção: o SDK de streaming usa um endpoint de ingestão separado por HTTPS, então, mesmo executando dentro do Snowflake, é preciso conceder uma integração de acesso externo que permita a saída de volta para *.snowflakecomputing.com.
Práticas recomendadas
Snowpipe Streaming agrupa em lotes para você
O Snowpipe Streaming não grava um arquivo por linha. O SDK envia as linhas assim que você chama appendRows, mas uma camada de buffer no lado do servidor as absorve e decide por conta própria o momento do commit (confirmação), agrupando tudo internamente para que você nunca precise enviar um arquivo por linha.
Além disso, o Snowflake realiza a compactação automática em segundo plano para tabelas Iceberg gerenciadas pelo Snowflake nas quais o Snowflake é o único sistema que grava: arquivos Parquet pequenos são mesclados em arquivos maiores, e manifests pequenos também são compactados. Você não precisa agendar nem executar isso; está incluído na operação normal.
O que você pode fazer:
- Agrupar as linhas no lado do cliente antes de chamar
appendRows. Enviar as linhas uma a uma ainda significa um roundtrip por linha. Agrupá-las em uma única chamada amortiza essa sobrecarga, o mesmo princípio por trás da própria recomendação do Snowflake de compactar e enviar mais dados por requisição. - Manter os canais ativos por mais tempo. Abra um canal uma vez por partição de origem e mantenha-o aberto durante toda a execução do job, em vez de abrir e fechar a cada microlote. Essa é a prática recomendada documentada pela Snowflake para o Snowpipe Streaming. Ela reduz a sobrecarga sem entrar em conflito com o agrupamento em lotes que já ocorre internamente.
- Definir
TARGET_FILE_SIZEna tabela. Essa é uma propriedade no nível da tabela, independente do SDK, que informa ao Snowflake qual tamanho almejar tanto para novas gravações quanto para a compactação em segundo plano, independentemente de como os dados chegaram até lá. - Deixar o throughput fazer o trabalho. Quanto maior for o seu TPS sustentado, mais rápido o buffer no lado do servidor se enche e faz o flush por conta própria, o que, na prática, resulta em uma relação de compromisso entre o throughput e a latência para um determinado tamanho de arquivo.
O que vem a seguir: Iceberg v4
O Snowpipe Streaming e a compactação automática resolvem o problema físico dos arquivos pequenos, mas commits frequentes ainda podem gerar sobrecarga na árvore de metadados do Iceberg. Atualmente, cada commit grava um novo JSON de metadados, uma lista de manifests e um manifest, mesmo quando contém apenas um arquivo pequeno. Para cargas de trabalho que fazem commit a cada poucos segundos, esse trabalho repetido de metadados pode se tornar o gargalo.
A proposta do Iceberg v4 introduz uma Adaptive Metadata Tree para reduzir esse aumento do trabalho de gravação. Em vez de criar um novo manifest para cada commit pequeno, o manifest raiz pode incorporar esses commits diretamente. Uma única gravação Parquet e uma troca atômica de ponteiro substituem a cadeia atual, mantendo o I/O de metadados por commit constante, em vez de aumentar conforme o número de manifests. Para cargas de trabalho de streaming de alta frequência, isso pode melhorar drasticamente a latência do streaming.
O streaming é um dos principais cenários de uso do Iceberg v4: cargas de trabalho que fazem commit a cada poucos segundos expõem diretamente o aumento do trabalho de gravação de metadados, o que torna os benefícios da Adaptive Metadata Tree especialmente relevantes. A especificação v4 ainda está evoluindo, mas vale a pena acompanhá-la se o streaming com Iceberg estiver nos seus planos. A Snowflake tem orgulho de participar ativamente da construção do futuro deste formato.
O que isso significa para a arquitetura da sua empresa
Neste artigo, demonstramos o quanto eficaz o Snowpipe Streaming para o Iceberg pode ser. No tipo de carga em que uma forte plataforma de mídia ou telecomunicações opera, sem exigir bucket do S3, cluster EKS, tópico Kafka ou função IAM para essa configuração de teste, a carga de trabalho foi executada dentro do Snowflake e pôde ser desativada após a avaliação.
A infraestrutura que normalmente fica entre uma equipe e um teste de streaming (os buckets, os clusters, a autenticação e as aprovações) não é um pré-requisito. Você pode responder à pergunta: "Isso atende às nossas necessidades com rapidez?".
Se você atua na área de Site Reliability Engineering (SRE) ou engenharia de dados de uma grande plataforma de mídia ou telecomunicações e o streaming com Iceberg está no seu roteiro ou plano de ação, comece pelo teste, não pelo ciclo de aquisição. Convidamos você a clonar o repositório, implementá-lo no SPCS e a vê-lo em funcionamento.
- Teste agora no repositório do GitHub.
- Obtenha mais informações consultando a documentação Snowpipe Streaming High-Performance Architecture.
