DuckDB v1.5.3将Quack协议升为核心扩展并给Iceberg加上MERGE INTO；Daft v0.7.14用arrow-rs重写Parquet读取器；阿里云全栈AI升级面向代理时代重塑云基建
第四期聚焦DataInfra四条动态：DuckDB v1.5.3将Quack远程协议从实验特性升为核心扩展一键安装，同时Iceberg扩展迎来重大更新支持MERGE INTO、分区表操作和ALTER TABLE；Daft v0.7.14用arrow-rs公共解码器API重写Parquet读取器并引入Flotilla分布式Limit Counter与Shuffle文件优化；阿里云在云栖大会宣布全栈AI升级，Qwen3.7-Max支持35小时连续运行与1000+次工具调用，盘古AL128超级节点集成128个AI加速器提供PB/s级带宽；MinIO推出MemKV上下文内存存储，用800Gbps RDMA+原生闪存消除AI推理重计算税，实现95% GPU利用率提升和50%单token成本降低
第四期追踪到DataInfra领域四条重要动态：DuckDB v1.5.3于5月20日发布，将第二期报道的Quack远程协议从实验特性升为核心扩展——首次使用时自动安装加载，同时Iceberg扩展迎来重大升级，新增MERGE INTO、分区表INSERT/UPDATE、完整ALTER TABLE和GEOMETRY类型支持，这让DuckDB在开放湖仓格式上的操作能力从”只读查询”跨越到”读写全功能”；Daft同日发布v0.7.14，用arrow-rs公共解码器API重写Parquet读取器，引入Flotilla分布式Limit Counter和每任务单shuffle文件优化，加上v0.7.13的前向ASOF Join，分布式DataFrame引擎在生态兼容性和性能上同时跃进；阿里云在云栖大会宣布面向代理时代的全栈AI升级，Qwen3.7-Max支持35小时连续运行和1000+次工具调用，盘古AL128超级节点集成128个昭晖M890加速器提供PB/s级带宽，百炼平台新增Agentic RL和安全治理；MinIO推出MemKV上下文内存存储，用800Gbps RDMA + 原生闪存将AI推理中的”重计算税”从结构性痛点变为可解问题——95% GPU利用率提升和50%单token成本降低的核心在于将上下文从”临时缓存”重新定义为”持久化可寻址状态”。
DuckDB v1.5.3：Quack升为核心扩展，Iceberg扩展迎来MERGE INTO
事件概述
5月20日，DuckDB发布v1.5.3补丁版本。虽名义为补丁版，但通过扩展程序交付了大量新功能。最重要的两项变更：Quack远程协议从实验特性升为核心扩展，首次使用时自动安装加载；Iceberg扩展迎来发布以来最大规模的功能升级——新增MERGE INTO语句、分区表INSERT/UPDATE支持（含truncate和bucket转换）、完整ALTER TABLE操作、GEOMETRY类型支持，以及Schema属性管理函数。此外，AWS扩展新增IRSA和RDS/Aurora IAM认证，DuckLake支持Quack协议作为目录数据库，jemalloc成为Linux默认静态链接内存分配器。
技术解析
- Quack升为核心扩展：第二期报道的Quack远程协议（让DuckDB通过HTTP获得C/S架构能力）从需要手动安装的实验扩展变为v1.5.3的核心扩展——首次使用
quack_serve()或ATTACH 'quack:...'时自动安装加载，零配置即可使用。DuckDB团队同时明确：Quack仍为Beta状态，协议和函数名可能发生破坏性变更，生产就绪版本计划随DuckDB v2.0在2026年秋季发布。DuckLake也已支持使用Quack作为其目录数据库，实现远程数据湖操作。 - Iceberg扩展重大升级：这是DuckDB Iceberg扩展发布以来最全面的功能更新。MERGE INTO支持让DuckDB可以对Iceberg表执行upsert操作——此前DuckDB对Iceberg表的能力限于SELECT和INSERT，MERGE INTO的加入补上了湖仓场景中最关键的”写入后更新”能力。分区表操作：INSERT和UPDATE语句现在支持带有truncate或bucket转换的分区Iceberg表，这意味着DuckDB能正确处理Iceberg最常见的分区策略。完整ALTER TABLE：为Iceberg表添加了ADD COLUMN、DROP COLUMN、RENAME COLUMN等DDL操作。GEOMETRY类型：Iceberg表现在支持空间数据类型，打开了地理空间分析的大门。
- AWS扩展增强：新增IRSA（IAM Roles for Service Accounts）支持，通过web_identity链类型让EKS上的DuckDB工作负载自动获取AWS凭证；RDS/Aurora IAM认证支持让DuckDB可以用IAM身份而非密码连接AWS托管PostgreSQL。
- jemalloc静态链接：在Linux上将jemalloc内存分配器作为静态第三方库链接进DuckDB核心，改进打包方式，使其他DuckDB扩展可以动态加载。这对DuckDB的嵌入式部署场景（Python包、CLI二进制）是重要的内存管理基础设施。
行业影响
DuckDB v1.5.3的Iceberg扩展升级，让DuckDB在开放湖仓生态中的定位从”轻量级查询引擎”跃升为”全功能湖仓客户端”。MERGE INTO的加入尤其关键——当Iceberg v3的删除向量（创刊号报道）解决了频繁更新的读取性能问题后，DuckDB补上了写入侧的upsert能力，这让”用DuckDB直接操作Iceberg湖仓”从实验场景变为可行方案。结合Quack升为核心扩展，DuckDB正在构建一个完整的”湖仓操作端”叙事：本地或远程连接湖仓、查询和写入Iceberg表、通过Quack共享数据——全在一个进程内完成。
相关链接
Daft v0.7.14：arrow-rs重写Parquet读取器与Flotilla分布式优化
事件概述
5月20日，Daft发布v0.7.14，紧随5月14日的v0.7.13。两个版本合计带来三项重要变更：用arrow-rs公共解码器API重写Parquet读取器、引入Flotilla分布式Limit Counter与Shuffle文件优化、以及前向ASOF Join支持。Daft作为Python-native的分布式DataFrame引擎，正加速在PySpark兼容性和分布式执行引擎性能两个方向上推进。
技术解析
- Parquet读取器重写：v0.7.14用arrow-rs的公共解码器API重写了整个Parquet读取器。此前Daft使用自定义的Parquet解析实现，虽然功能完整但维护成本高且难以跟上Arrow生态的优化节奏。重写后，Daft的Parquet读取直接受益于arrow-rs社区的持续优化（如向化解码、列式裁剪），同时减少了Daft自身的维护负担。这对Daft用户而言是”透明升级”——无需修改代码即可获得更好的Parquet读取性能。
- Flotilla分布式Limit Counter：v0.7.14新增Flotilla分布式Limit Counter实现。在分布式DataFrame中，
limit(N)操作看起来简单——只需取前N行——但在分布式环境下，如何避免所有分区都发送完整数据到reduce节点？Limit Counter让各分区协同计算已收集的行数，在达到限制后尽早截断上游计算，减少不必要的数据传输和计算开销。 - Shuffle文件优化：从”每个任务写N个分区文件”改为”每个任务写1个shuffle文件”。此前每个任务为每个目标分区写一个独立文件，当分区数多时产生大量小文件，I/O效率低下。改为单文件后，大幅减少文件数量和元数据开销，同时为下游读取提供更好的顺序I/O模式。
- 前向ASOF Join（v0.7.13）：新增前向ASOF Join支持。ASOF Join（As-Of Join）是时间序列分析的核心操作——将左表的每行匹配到右表中”最接近但不晚于”左表时间戳的行。前向ASOF Join则是”最接近但不早于”，适用于”某事件发生后第一个触发的条件”等场景。Daft此前已支持后向ASOF Join，v0.7.13补上了前向支持，形成完整的时序关联能力。
- PySpark兼容性：v0.7.14新增
conv数学函数和Spark风格的时间别名，继续推进与PySpark API的兼容性。JSON函数方面新增json_array_length、json_object_keys、json_tuple三个函数。
行业影响
Daft连续两个版本的密集更新，展示了Python-native分布式DataFrame引擎的明确战略：以PySpark兼容性降低迁移门槛，以Rust内核（arrow-rs重写、Flotilla引擎）提供性能保证。Parquet读取器的arrow-rs重写是一个标志性决策——它表明Daft选择”站在Arrow生态的肩膀上”而非”重复造轮子”，这在大数据生态日趋标准化（Iceberg、Arrow、Parquet三件套）的背景下是明智的。
对DataInfra从业者而言，Daft的进展值得关注：如果你的团队使用PySpark但苦于JVM开销和冷启动延迟，Daft正在成为一个越来越可行的替代选项——Python-native的API兼容性+Rust内核的性能潜力。
相关链接
阿里云全栈AI升级：面向代理时代重塑云基础设施
事件概述
5月20日，阿里巴巴在杭州云栖大会上宣布面向代理时代的全栈AI升级，覆盖基础模型、云基础设施和AI芯片三层。基础模型层：Qwen3.7-Max支持35小时连续运行、1000+次工具调用无性能衰减，深度优化OpenClaw、Hermes Agent、Claude Code等主流代理框架。云基础设施层：盘古AL128超级节点服务器单机架集成128个昭晖M890 AI加速器，提供PB/s级内部带宽，专门优化代理工作负载的不可预测高频推理突发。芯片层：昭晖M890性能3倍于前代、144GB片上内存、800GB/s芯片间带宽，ICN Switch 1.0提供25.6Tbps聚合带宽。百炼平台新增Agentic RL（基于代理执行反馈的强化学习）和安全治理机制。
技术解析
- Qwen3.7-Max的代理能力：35小时连续运行和1000+次工具调用是两个极具工程挑战的指标。长时间连续运行意味着模型需要处理超长上下文窗口的累积——KV Cache管理、上下文压缩和递归摘要的技术难度远超单轮对话。1000+次工具调用无衰减则要求模型在极长的决策链中保持指令遵循能力，避免”中间步骤遗忘”和”指令漂移”。这两项指标的突破，标志着Qwen3.7-Max不是通用大模型加个工具调用接口，而是从底层为代理工作负载设计的专用模型。
- 盘古AL128超级节点：单机架128个AI加速器+PB/s级带宽，远超当前主流8-GPU或64-GPU节点规模。设计目标明确指向代理工作负载的特征——不可预测的高频推理突发。与训练工作负载的稳定大批次不同，代理推理呈现”大量并发、短时突发、不可预测”的模式，需要极高的互联带宽来处理突发时的全对全通信。AL128将这种通信压缩到单机架内，避免了跨机架网络成为瓶颈。
- 昭晖M890 + ICN Switch 1.0：M890的144GB片上内存（对比H100的80GB）让70B级别模型可以单卡加载，减少多卡推理的通信开销；FP32到FP4的多精度支持让同一芯片覆盖训练和推理两种场景。ICN Switch 1.0的25.6Tbps聚合带宽支持64个加速器的无拥塞全带宽互连，将多卡通信延迟压到最低。
- 百炼Agentic RL：基于代理实际执行任务的结果反馈持续优化模型，而非传统的离线RLHF。这意味着模型在生产环境中越用越好——代理执行任务失败时，失败信号直接回流到模型训练循环，形成”执行-反馈-优化”的闭环。
行业影响
阿里云此次全栈升级的核心叙事是”代理时代的云基础设施”。这与前三期追踪的”基础设施AI代理化”趋势形成镜像——海外是Databricks/Anyscale/OpenSearch让基础设施为AI代理服务，阿里云则是从芯片到模型为AI代理工作负载重新设计云基础设施。
盘古AL128超级节点的设计哲学尤其值得关注：当AI代理工作负载的请求模式从”可预测的大批次”变为”不可预测的小突发”时，云基础设施需要从”为训练优化”转向”为推理优化”——更大的片上内存、更高的互联带宽、更灵活的弹性扩展。阿里云的AL128和MinIO的MemKV（见下文）从不同角度回应了同一个问题：AI推理的数据路径效率。
相关链接
- Alibaba Announces Comprehensive Full-Stack AI Upgrade for the Agentic Era
- Alibaba Unveils New AI Chip, Flagship Model, and Rebuilt Cloud Stack AI for Agentic Era
MinIO MemKV：用持久化上下文存储终结AI推理的重计算税
事件概述
5月13日，The New Stack报道MinIO推出MemKV——一个专为AI推理数据路径设计的上下文内存存储。MemKV的核心命题是消除”重计算税”：当AI代理执行复杂多步推理时，如果靠近GPU的基础设施无法保存足够的上下文，已完成的计算会被重复执行——这就是”重计算税”。MemKV用800Gbps RDMA + 原生闪存提供PB级持久化上下文存储和微秒级检索，将上下文从”临时缓存”重新定义为”持久化可寻址状态”，实现95% GPU利用率提升和约50%单token成本降低。
技术解析
- 重计算税的本质：当AI代理执行长链推理时，上下文（KV Cache、中间结果、工具调用历史）随步骤增长。如果GPU本地内存无法容纳完整上下文，系统需要丢弃部分缓存，后续步骤访问已丢弃的上下文时必须重新计算。在多代理、长会话、RAG密集的场景下，这种重复计算可能占总推理成本的30-50%。
- 零中介数据路径：MemKV的设计消除了GPU与上下文之间的三层中介——无HTTP开销、无文件系统转换、无存储服务器中介。数据从NVMe闪存通过800Gbps RDMA直接到达AI数据路径。MinIO CTO Ugur Tigli将其与Redis/Redis Stack做区分：Redis是”缓存”——容量有限、可能被驱逐、不保证持久化；MemKV是”状态存储”——容量PB级、显式策略防止驱逐、持久化保证。
- 无状态服务层架构：MemKV使GPU推理服务层变为无状态。会话和代理状态存储在MemKV中，任何GPU副本可以在中途接管任何对话——调度器将请求路由到任何空闲GPU，GPU在微秒内从MemKV拉取缓存上下文。这消除了Kubernetes推理部署中的粘性会话、副本亲和性和Pod重启时的线程丢失问题。
- 显式状态管理：MemKV要求开发者显式指定哪些数据保留、哪些删除。为活跃会话的键设置固定策略防止在负载下被驱逐，分离缓存热点前缀（长系统提示、频繁检索的RAG段落）与用户状态，防止单个活跃用户将共享资产推出。
- 安全新维度：ArmorCode首席安全与信任官Karthik Swarnam指出，上下文内存层决定AI系统保留、回忆和作用的内容——攻击面扩展到上下文数据可能被篡改、污染或泄露，需要数据溯源、访问控制和保留策略。
行业影响
MinIO MemKV的推出，与阿里云盘古AL128从不同维度回应了同一个问题：AI推理的数据路径效率。AL128用超大互联带宽解决多卡间的数据移动问题，MemKV用持久化共享存储解决跨GPU的上下文保存问题——两者都在消除”数据到GPU”路径上的摩擦。
MemKV更深层的意义在于它重新定义了AI推理中”上下文”的角色。MinIO CTO Tigli的原话精准概括了这个转变：“上下文从临时缓存变为持久化可寻址状态——更接近数据库行或对象，而非缓存条目。“这与第三期Databricks Unity AI Gateway的Payload Logging（将代理行为数据写入Delta表）形成呼应——当AI代理的上下文和行为数据都被当作”结构化持久状态”而非”临时缓存”管理时，AI系统的运维模型从”管理计算”转向”管理状态”。
对DataInfra从业者而言，MemKV提出了一个架构决策问题：你的AI推理平台中，上下文存储是”缓存层”还是”状态层”？如果是前者，你正在为重计算税买单；如果是后者，你需要像管理数据库一样管理上下文的生命周期、一致性和安全性。
相关链接
编者评
第四期的四条动态，与前几期的主线形成了新的递进。创刊号提出”AI原生基础设施”，第二、三期追踪”基础设施AI代理化”和”代理治理”两条线，本期则看到了AI代理趋势向更深层基础设施的渗透——从应用层和平台层，下沉到存储层和芯片层。
DuckDB和Daft的更新代表了”工具层”的进化：DuckDB将Quack和Iceberg MERGE INTO这两项能力从实验推向核心，让轻量级湖仓客户端具备生产级读写能力；Daft用arrow-rs重写Parquet读取器选择”站在生态肩膀上”而非重复造轮子，Python-native DataFrame引擎的战略定位越来越清晰。这两个项目共同指向一个趋势：数据基建的客户端正在从”只读查询工具”进化为”全功能操作终端”。
阿里云和MinIO的动态则代表了”基础设施层”的重设计：阿里云从芯片到超级节点为代理工作负载重新设计云基础设施，MinIO从存储范式层面重新定义AI推理中的上下文管理。两者共同的洞察是：AI代理工作负载的特征（不可预测突发、超长上下文、跨GPU状态共享）与传统训练/推理工作负载截然不同，需要从底层重新设计基础设施。
将四期主线串联来看，一条清晰的脉络浮现：AI代理正在从”使用基础设施”变为”重塑基础设施”。Vol.1-2是基础设施为代理提供操作接口（Agent Skills），Vol.3是基础设施为代理提供治理框架（Unity AI Gateway），Vol.4则是基础设施为代理重新设计数据路径（MemKV、AL128）。当AI代理成为基础设施的主要工作负载时，基础设施不再是代理的”宿主”，而是代理的”定制化底座”——这个范式转变，可能是2026年DataInfra领域最重要的趋势。