datainfra前沿动态 · Vol.70

Snowflake 弹性通道把摄入上限提到单表 20 GB/s；SageMaker 用联邦把 Snowflake 纳进目录而不复制数据；阿里云 ApsaraLakebase 称新增数据库实例八成由 Agent 开通；GreptimeDB 修掉一处因统计信息错位而在压缩时静默丢数据的缺陷

本期聚焦四条跨 9 月 16 至 17 日的进展：Snowflake 的 Snowpipe Streaming 弹性通道 GA，让生产者直接写表而不必先落消息总线；AWS 用 Glue 连接把 Snowflake 联邦进 SageMaker Unified Studio，查询下推、数据不出仓；阿里云数据库团队披露 ApsaraLakebase 的六层重构，把 Agent 当作主要用户来设计；GreptimeDB v1.2.1 修复了 Parquet 统计信息错位导致读取时错误剪枝、进而在严格窗口压缩中丢数据的问题。

2026年9月18日 DataInfra Snowflake Snowpipe Streaming AWS SageMaker Unified Studio AWS Glue Apache Iceberg 阿里云 ApsaraLakebase GreptimeDB 时序数据库数据质量

这四件事分别落在摄入层、目录与治理层、底座架构层和存储引擎层，动作方向一致：把数据流动路径上那些「先复制一份再处理」的环节拆掉。Snowflake 让生产者直接写目标表，不再要求先建一条消息总线或暂存管道；AWS 让 SageMaker Unified Studio 通过联邦连接直接查 Snowflake，查询结果回来，数据留在原地；阿里云把 ApsaraLakebase 的存储统一到对象存储上，一次入湖供多个引擎取用。减少复制的代价是每少搬一次，就多一分依赖元数据的正确性——GreptimeDB 这周的修复给了最直接的注脚：Parquet 统计信息与投影错位时，剪枝不再只是「少读几个文件」，而是在压缩时把 JSON2 数据静默丢掉。省下来的读取量，最终要靠统计信息、目录条目和模式定义来偿还。

Snowpipe Streaming 弹性通道 GA：单表 20 GB/s，但「已确认」不等于「可查询」

事件概述

Snowflake 于 9 月 16 日宣布 Snowpipe Streaming 的 Elastic Channels（弹性通道）正式可用。这条通道面向的是一类很常见的尴尬：设备、应用和服务在持续产生事件，为了让这些事件落到表里，团队先搭一套消息总线或暂存管道，而这套管道本身的复杂度已经接近产生数据的应用本身。Yuvital 的首席架构师 Yaron Levi 在官方博客里直言，他们用 Confluent 只是为了把追加型事件送进 Snowflake，「对一个这么简单的目标来说太复杂也太贵」。

弹性通道的做法是把摄入路径压成三步：选一张目标表，用 SDK 或 REST 追加行或批次，等一个持久化确认。通道的分配、再平衡和扩缩容全部由服务端接管，生产者不用再自己协商「谁写哪条 channel」。

技术解析

吞吐与延迟：GA 时单表上限 20 GB/s，官方称数据最快 5 秒可查。内部测试中把单表推到 40 GB/s（厂商口径，官方表示后续会用单独一篇讲测量方法，第三篇讲架构设计）。
语义取舍：弹性通道提供的是「至少一次」投递，且不保证顺序。重试或重放会产生重复，需要去重的场景应使用稳定的事件 ID。要求按通道保序与精确一次的场景，继续用既有的 Named Channels。
确认的含义：生产者收到的确认只代表 Snowflake 已在摄入服务中持久化该批数据，不代表该批已完成下游处理、也不代表已可查询。文中的延迟数字测的是「摄入到可查」，不是确认时间。生产者必须自行保留未确认事件以便重试；SDK 的内存缓冲区不是持久化暂存区。
接口与目标：提供 Python、Java、Node.js SDK 与 REST API，REST 面向边缘、Serverless 函数和没有专用 SDK 的语言，客户端需自行处理 NDJSON 分批与压缩。写入目标支持 Snowflake 原生表与 Snowflake 托管的 Iceberg 表。
计费：弹性通道本身不额外收费，Snowpipe Streaming 按未压缩数据量计费，0.0037 credits/GB。

行业影响

把「先落一层管道再入库」改成「直接写表」，削掉的是一个完整的运维对象：没有 broker 要调、没有分区要再平衡、没有消费者组要监控。对于物联网和工业场景尤其明显——HighByte 的产品管理总监 Jeffrey Schroeder 提到，工业数据不允许丢失，持久化确认让他们可以在边缘缓冲、连通恢复后再投递。

代价是语义变薄了。至少一次加无序，意味着去重和排序的责任从平台侧移回应用侧，而「确认」与「可查」之间的这段间隙必须被显式建模：生产者要么接受短暂的不可见窗口，要么自己维护未确认事件的持久缓冲。Snowflake 把这条边界写进了文档，而不是留给使用者去猜。

相关链接

SageMaker Unified Studio 联邦 Snowflake：查询下推，数据不出仓，质量分数回写到目录

事件概述

AWS Big Data Blog 于 9 月 16 日给出一篇 Expert 400 级实操教程，讲如何把 Snowflake 的数据资产纳入 Amazon SageMaker Unified Studio 的统一目录与治理体系，全程不复制数据。作者是 Marco Duarte 和 Diego Ortiz。

流程分三段：在 Unified Studio 项目里建一条 Snowflake 的 AWS Glue 连接并勾选注册到 Glue Data Catalog；用 Athena 对联邦表做下推查询；再用 Glue Data Quality 跑规则，把质量分数回写到基于 Amazon DataZone 的 SageMaker Catalog 资产页上。官方给出的端到端时间是 5 到 15 分钟，对比传统抽取管道动辄数天。

技术解析

查询怎么执行：Unified Studio 的查询编辑器由 Athena 承接。Athena 从 Glue Data Catalog 读表定义，经 Glue 连接连到 Snowflake，把查询下推过去，Snowflake 就地计算，只有结果集经过连接返回。数据不会被复制到 S3 或任何中间存储。
连接的关键参数：建连接时需勾选「Register in AWS Glue Data Catalog」，并选择符合 Snowflake 命名语法的 Case conflict handling（大小写冲突处理），否则标识符大小写会出问题。连接建好后需要等几分钟联邦才生效。
质量结果如何回到目录：Glue Visual ETL 作业链是 Snowflake source → Evaluate Data Quality（用 DQDL 写规则）→ ruleOutcomes → Datazone DQ Result Sink。最后这个 sink 是自定义转换，其 Python 与 JSON 文件必须上传到 s3://aws-glue-assets-<account-id>-<region>/transforms，Glue Studio 只从这个固定路径读取 JSON 来注册可视化节点。作业还要加参数 --additional-python-modules = boto3>=1.34.105。
权限是主要摩擦点：SageMaker Catalog 基于 Amazon DataZone，相关 IAM 动作用 datazone: 前缀（SearchListings、GetListing、PostTimeSeriesDataPoints、GetAsset 等）。Glue 作业的执行角色还必须被加为 SageMaker domain user，并在项目成员里授予 Owner。

行业影响

「数据在别人的仓里」这件事正在被做成一个一等公民对象。上一期我们看到 Glue 用资源链接把 Redshift 接到 Databricks 管理的 Iceberg 上，这一期是同一个模式换到 Snowflake：目录里多一条条目，权限分两段授予，数据原地不动。对企业来说收益是编目和治理可以覆盖到仓外资产，消费者在订阅前就能看到质量分数（教程示例里总分 100、规则集 1/1 通过），而不必先申请访问权再自己跑一遍校验。

门槛则转移到了装配上：一个自定义转换要落到固定 S3 路径、作业要补 Python 模块参数、角色要一并具备 DataZone 权限与项目成员身份。这些不是概念问题，是实施清单上的具体条目。

相关链接

阿里云 ApsaraLakebase：把 Agent 当成主要用户来重做数据底座

事件概述

9 月 17 日，阿里云数据库产品事业部产品管理与技术架构部负责人王远（花名惊玄）在一次访谈中系统讲了 ApsaraLakebase 的定位与分层。此前这款产品在今年上半年公开亮相，8 月的 Agentic DB Day 上被进一步推到台前。

最值得记的一个数字是用户结构的变化：阿里云内部原本设定到 2026 年 9 月 30 日实现 25% 的数据库实例由 Agent 直接管理，实际已经超过 50%；只看新增实例，这一比例达到 80%。也就是说新开出的数据库实例里，Agent 已经占了大多数（厂商口径，来自访谈而非产品文档）。

技术解析

为什么要重做而不是加功能：团队最初走的是在成熟产品 PolarDB 之上迭代适配 Agent 场景的渐进路线，落地大半年后改了方向——在既有数据库上叠加能力无法释放 Agent 场景的潜力。转向的动因是成本：传统数据库在 Agent 场景下，存储与运维开销随实例数量快速抬升。
六层结构：存储层基于对象存储，只存一份，支持「一份数据、多索引适配」；缓存加速层补在线访问的性能短板；开放引擎层把 PolarDB、AnalyticDB、Lindorm、RDS、Tair、MongoDB 等既有引擎整体接入，降低存量资产的迁移成本；Agentic Schema 抽象层定义了从多模态原始数据到企业级标准 Schema、再到 Agent 上下文、记忆库与知识库的全链路转化规则；Agentic Query Language 是以自然语言为核心的 Agent 查询接口，配预置 Skills 与工具；最上层直接长出面向终端用户的 Data Agent。
与 AIDBS 的分工：AIDBS（AI 原生数据库服务）交付的是 Agent 形态的能力，不交付数据库实例，面向懂业务、不熟悉 SQL 的人；ApsaraLakebase 反过来，从数据库生态出发在其上长 Agent 能力，面向开发者与数据技术从业者。
行为差异驱动设计：人朝九晚五、操作谨慎，Agent 全年无休且会瞬间拉起成百上千个实例去试错；人改完一条数据隔几分钟再做分析，Agent 要求毫秒级响应。这些差异让 Serverless 与多租户隔离从可选项变成必选项。

行业影响

把「谁在用数据库」从人换成 Agent，改的是成本函数和接口形态，而不是查询能力。一旦一个企业级应用背后有几十个 Agent 一起跑，按实例计费的模型立刻失效——这正是 ApsaraLakebase 把共享底座与海量租户隔离挂载作为出发点的原因。Agentic Schema 与 Agentic Query Language 这两层则是在补另一件事：关系模型和 SQL 都是为习惯确定结构的人类开发者设计的，Agent 需要的是上下文、记忆与知识组织机制，这道认知鸿沟只能由新的一层来填。

需要说明的是，本条内容来自访谈而非产品文档，官方未给出任何性能基准数字，AQL 与 Agentic Schema 也仍是规划中的形态。按云栖大会的议程安排，数据层的完整故事会在会上展开。

相关链接

当 Agent 成为数据库的主要用户，数据底座该如何重写？（访谈全文）

GreptimeDB v1.2.1：统计信息错位导致错误剪枝，压缩时静默丢数据

事件概述

时序数据库 GreptimeDB 于 9 月 16 日发布 v1.2.1 维护版本，官方建议 v1.2.0 用户升级。这个版本最值得关注的不在特性列表，而在一条数据丢失缺陷：投影场景下 Parquet 统计信息错位，会让读取阶段错误地剪枝 JSON2 数据，进而在严格窗口压缩时造成数据丢失（PR #9129）。

这是一类典型的「优化反过来吃掉正确性」的故障——统计信息的作用是让引擎跳过不必要的文件，跳过的前提是统计信息与实际内容对齐；一旦错位，被跳过的就不是无关数据，而是真实数据。

技术解析

数据丢失链路：投影导致 Parquet 统计信息错位 → 读取时错误剪枝 → 严格窗口压缩下数据丢失（#9129）。配套修复了压缩过程中混合 JSON2 类型的保留问题（#9135），以及 gRPC 原生 JSON2 行插入对 SQL NULL 的处理（#9145，服务端修复，客户端 SDK 的支持仍在跟进）。
查询正确性：在线重分区或 SPLIT PARTITION 之后 count(*) 的准确性（#9154）；PromQL rate 窗口对计数器重置的累加（#9089）与对 NULL 采样的跳过顺序（#9118）；混合 MIN/MAX 聚合不再应用不完整的动态过滤器（#9102）。
协议兼容性：带前导注释的 SQL 语句改在联邦语句过滤之前处理，DataGrip 等会在语句前加注释的 JDBC 客户端才能正常内省与查询（#9156）。
稳定性：jemalloc 升到 0.7 系列并补了线程缓存初始化崩溃的修复（#9103、#9119），CPU profiling 改用 framehop unwinder 以解决 profiling 相关崩溃（#9125）。

行业影响

这一条正好给本期前三条打个补丁。减少复制、依赖元数据进行剪枝和跳过，是整个行业这几年的共同方向——Iceberg 靠 manifest 里的列界跳过文件，Snowflake 与 AWS 靠目录条目跳过抽取，ApsaraLakebase 靠一次入湖跳过多次搬家。它们的收益都建立在元数据与真实数据一致的假设上。GreptimeDB 的修复展示了假设破裂时的形态：故障不表现为变慢或报错，表现为数据在压缩后消失。

对使用方的实际含义是，升级策略要跟着数据正确性走而不是跟着特性列表走。v1.2.1 没有新功能，只有一处静默丢数据的修复和若干查询正确性问题，官方仍然明确建议 v1.2.0 用户升级。

相关链接

编者评

把四条放在一起看，本期讲的是同一笔账的两面。前三条都在削减数据流动路径上的复制环节：Snowflake 让生产者跳过消息总线直接写表，AWS 用联邦让 Snowflake 的数据不必复制就能被编目、查询和校验，阿里云把多份结构化与非结构化数据收敛到对象存储上的一份。每一次削减都换来实实在在的收益——少一套要运维的系统、少一次要等待的抽取、少一份要对齐的副本。

账的另一面是，省下的每一次读取都不是凭空消失的，而是被换成了一次对元数据的信任：通道的持久化确认、目录里的表定义、Parquet 里的列界统计、Agentic Schema 里的转化规则。GreptimeDB 这周修的那条缺陷就是这笔账的催缴单——统计信息一旦与内容错位，剪枝从性能优化变成静默的数据删除，故障形态从「慢」变成「错」，而后者在压缩完成后几乎无法回溯。

还有一个信号值得留意：用户结构正在被重新统计。阿里云说新增数据库实例里八成由 Agent 开通，MotherDuck 此前也给出过 Agent 查询量远超人类的观察。当主要使用者从人变成 Agent，成本函数、隔离模型和接口形态都要跟着改——Serverless 与多租户不再是锦上添花的配置项，而是能不能撑住「几十个 Agent 并发试错」的前提条件。这一点在本期的 ApsaraLakebase 身上体现得比任何一条性能数字都清楚。

本期另有几条线索未展开：Databricks 宣布未来三年在新加坡投资超 3.5 亿美元并扩建区域总部（属市场投入，无技术细节）；Snowflake CLI 3.27.0 修复了一个 CVSS 8.2 的 SQL 注入问题（CVE-2026-92903，安全公告）；新加坡网络安全局就 MongoDB Server 的 CVE-2026-82067 发布高危预警（配置校验缺陷可致授权子系统启动时失效）；Gartner 预测 2026 年全球 AI 支出达 2.67 万亿美元，其中 AI Data 板块从 8.26 亿美元增至 31.26 亿美元（市场报告）；LanceDB 发布 v0.40.0-beta.0，引入 zonemap index builder 与远程目录绑定（仍处 beta，等稳定版再评）。