Snowpipe Streaming Elastic Channels 正式 GA：单表最高 20 GB/s，简化数据直连 Snowflake

这次发布到底是什么

2026 年 9 月 16 日，Snowflake 宣布 Snowpipe Streaming Elastic Channels 正式 GA。它由 Snowflake 开发，是一项闭源云服务功能，面向所有 AWS、GCP 和 Azure 商业区域开放。官方未说明具体定价。

它要做的事很直接：让应用、设备和服务的流式数据，不用先经过复杂的中间系统，就能直接写进 Snowflake 表或 Snowflake 管理的 Apache Iceberg 表。就像全班同学不用先交给小组长，而是直接把作业放进一个会自动扩容、还会回执确认的大文件柜。

为什么需要它

很多公司有大量设备、应用和服务在不停产生数据，比如点击事件、机器信号、日志和指标。过去为了把这些数据送进 Snowflake，常常要额外搭一套消息总线或中转管道，系统越搭越复杂，延迟和成本也跟着上升。

Elastic Channels 的目标就是减少这种“只为搬数据而存在”的系统。官方说，如果团队已经用 Kafka 做多消费者、共享重放或保留，可以继续保留，再用 Named Channels 把副本流入 Snowflake；如果只是想把数据直接落到表里，就可以用 Elastic Channels。

它怎么工作

使用方式很简单：先选一个目标表，然后通过 SDK 或 REST API 追加一行或一批行。Snowflake 会在服务端管理接入扩展和通道生命周期，生产者不需要自己分配、跟踪或重新平衡通道。

当 Snowflake 把数据持久保存后，生产者会收到一个持久确认。收到确认后，生产者可以释放自己保留的副本。官方特别说明，确认不等于所有行都已经完成下游处理，也不等于马上可以查询；查询可用时间另算。

性能和可用范围

正式 GA 时，Elastic Channels 支持单表最高 20 GB/s。数据最快约 5 秒可查询，具体取决于工作负载。官方还提到，内部测试中曾把吞吐推到单表 40 GB/s，后续文章会解释测试方法。

可用范围方面，Elastic Channels 和持久确认已在所有 AWS、GCP 和 Azure 商业区域正式可用。官方未说明不同区域之间是否存在性能差异，也未说明是否有额外限制。

适合哪些人和场景

它适合连接产品与 IoT 团队，用来监控大量设备健康、缩短遥测到产品洞察的路径；也适合工业运营团队，把机器和工厂信号送进 Snowflake 做异常检测、预测性维护和运营优化。

安全与可观测性团队可以用它把日志、指标、追踪和行为事件从分布式代理流入 Snowflake，加快威胁检测和事件响应。数字应用团队则可以用它捕获点击流和产品事件，支持个性化、实验和近实时客户分析。

限制和注意事项

Elastic Channels 提供至少一次投递，但不保证顺序。重试或重放可能产生重复数据，所以对去重有要求的场景应使用稳定的事件 ID。如果需要按通道顺序和恰好一次投递，应选择已有的 Named Channels。

生产者应保留未确认事件以便重试。发生故障时，可以暂停接收，或在必须继续采集时使用已有的发件箱或生产者本地持久缓冲。SDK 的内存缓冲不是持久化暂存，不能当作崩溃安全存储。

怎么开始核验

官方建议访问 Elastic Channels 文档了解入门方式。开发者可以选择 Python、Java 或 Node.js SDK，也可以使用 REST API。SDK 会自动按时间和大小阈值批量追加，并重试临时故障；REST API 更适合轻量服务、边缘应用、无服务器函数、Webhook 和没有专用 SDK 的语言。

目标表支持 Snowflake 表和 Snowflake 管理的 Iceberg 表。REST 客户端需要自行管理 NDJSON 批处理和压缩，成功响应代表持久接受。官方未说明具体定价和免费额度，实际使用前应向 Snowflake 确认成本与区域细节。