一张表，41.8 GB/秒：455 个 1-vCPU 容器的线性扩展

41.8 GB/秒。1.335 亿行/秒。一张 Snowflake 原生表。

Snowflake 发布了一组 Snowpipe Streaming Elastic Channels 的基准测试（完整报告）。在 AWS us-west-2 的 EKS 集群上，455 个 Kubernetes worker 同时向同一张表写数据，未压缩吞吐稳定在 41.8 GB/秒，行速率 1.335 亿行/秒。从 15 个 worker 扩到 455 个，吞吐量线性增长，没有平台期。

Elastic Channels 是 Snowpipe Streaming 的新能力，今年进入 GA。Snowpipe Streaming 是 Snowflake 的流式数据接入服务：应用把事件数据直接发给 Snowflake 表。上一代要求客户端管理通道名、记录 offset、协调 schema。Elastic Channels 把这部分挪到服务端，应用只调 client.get_elastic_channel()，拿到自动池化的通道，直接 append。

代价是语义从 exactly-once 降为 at-least-once。CDC、金融交易这类要严格语义的场景继续用老接口。遥测、日志、IoT 设备流量，用 Elastic Channels 更合适。

测试负载是合成的：42 个虚拟滑雪度假村的 POS 流水，每行约 277 字节 NDJSON。数据生成和序列化在 Rust 里完成，绕开 Python 逐行构造 dict 的开销和 SDK 的二次编码。每个 worker 只有 1 vCPU / 1 GiB 内存，31 个 pod 挤在一台 Graviton 节点上。

结果的核心数字：

扩展是线性的。 每个 worker 稳定贡献约 92 MB/秒、293K 行/秒，不随集群规模衰减。

延迟没有跟着吞吐涨。 Batch ack 全程在 570-611 ms 之间，客户端从不等待 Snowflake 消化数据。ingest-to-visible 始终落在 12-29 秒。行速率涨了 30 倍，这个延迟几乎没变。

资源效率很夸张。 行业里常见的千兆级单表摄入基准是 2,048 个 worker、3,072 核、4,096 GiB 内存，跑出约 12 GB/秒。Snowflake 用 455 核、455 GiB、455 个进程，跑出 41.8 GB/秒——七分之一的核心数、九分之一的内存，字节吞吐 3 倍，行速率 10 倍。

有意思的是瓶颈位置。客户端开销——序列化、通道管理、offset 追踪——往往比服务端更容易拖后腿。Elastic Channels 把这些剥离后，1-vCPU 的小容器就能推满单表吞吐。

整套工具在 GitHub 开源：snowflake-labs/snowflake-elastic-channels，包含 EKS 部署脚本、Python SDK 封装、Rust 原生编码器、Streamlit 监控面板。复现不需要 455 个 worker，跑一个单 worker 的 60 秒 smoke test 就能验证全链路。

一个工程细节值得留意：Rust 编码器没有重写业务逻辑。加权表和价格字符串从 Python 代码生成，Rust 只做查表和格式化。UNIT_PRICE 和 AMOUNT 在代码生成阶段固化成 decimal 字符串，两个语言的 float 处理永远不会产生分歧。unit test 验证两条路径输出字节级相同的 NDJSON。

这是有边界的测试：单区域、单账户、单表、单一行形状。要跑到这个量级，得先联系 Snowflake 提升账户容量。对比对象是 2024 年 Summit 的旧架构演示，不是受控的 side-by-side。

但方向清晰：摄入管道的瓶颈在客户端，且可以消除。做日志和遥测管道的话，代码是开源的，跑一遍就知道适不适合。

Snowflake 还发布了 Elastic Channels 在 IoT 场景的演示视频：观看视频。