datainfra前沿动态 · Vol.3

Unity AI Gateway为AI代理装上治理刹车；Valkey 9.1将搜索并入核心并砍掉10%内存；Redshift RG用Graviton消灭数据湖扫描费

第三期聚焦DataInfra四条动态：Databricks Unity AI Gateway四大扩展将AI代理治理从理论推向工程实践——Service Policies用SQL定义MCP调用规则、Payload Logging在Unity Catalog中记录每一次代理行为、LLM Guardrails用模型守模型、Cost Controls用预算硬顶防止AI账单失控；Valkey 9.1 GA将搜索能力并入核心引擎并实现10%内存优化和2.1M RPS；Amazon Redshift RG实例基于Graviton内置向量化数据湖查询引擎，Iceberg查询2.4x加速且消除Spectrum扫描费用；Pulumi全面押注Agent基础设施时代，用临时云账号和Neo集成目录让AI代理成为IaC的一等公民

DataInfra Databricks Unity AI Gateway AI代理治理 MCP Valkey 搜索 内存优化 Redshift Graviton 数据湖查询 Pulumi IaC Agent

第三期追踪到DataInfra领域四条重要动态：Databricks在5月19日集中发布Unity AI Gateway四大扩展——Service Policies用SQL定义MCP工具调用规则实现”代理行为白名单”，Payload Logging在Unity Catalog的Delta表中记录每一次代理调用的输入输出，LLM Guardrails用LLM评判LLM实现PII脱敏和越狱检测，Cost Controls提供四级预算硬顶防止AI账单失控——这四项能力共同将”AI代理治理”从原则讨论推向工程实践；Valkey 9.1同日GA，将Search 1.2并入核心引擎实现全文+向量混合搜索一体化，通过字符串和有序集合内存优化砍掉10%内存占用，并达到2.1M RPS的单节点吞吐纪录；Amazon Redshift RG实例基于Graviton处理器内置向量化数据湖查询引擎，Iceberg查询2.4x加速且彻底消除Spectrum $5/TB扫描费用；Pulumi宣布全面进入Agent基础设施时代，用临时云账号和Neo集成目录让AI代理成为IaC的一等公民。

Unity AI Gateway四大扩展：AI代理治理从原则走向工程

事件概述

5月19日，Databricks集中发布Unity AI Gateway的四项重大扩展：Service Policies（服务策略）、Payload Logging（载荷日志）、LLM Guardrails（大模型护栏）和Cost Controls（成本控制）。这四项能力共同构成了AI代理从实验到生产的治理闭环——在代理调用MCP工具前拦截、在代理与模型交互时审查、在代理行为发生后审计、在成本失控前硬顶。

其中Service Policies和Payload Logging作为Gated Beta发布，LLM Guardrails和Cost Controls作为Beta发布。四项能力均深度集成Unity Catalog，将AI代理的治理数据与数据治理数据统一在同一目录下。

技术解析

  • Service Policies——用SQL定义代理行为边界：管理员在Unity Catalog中用SQL函数定义MCP工具调用规则，评估每个工具调用的参数、调用者身份和上下文属性，决定允许/拒绝/需用户确认。策略由Unity AI Gateway实时执行，无需修改代理或MCP服务器代码。例如：阻止所有文件删除操作，限制PR合并仅允许指定工程师。这本质上是将数据库领域成熟的RBAC策略引擎搬到了AI代理领域。
  • Payload Logging——代理行为的Delta表审计：自动将每次MCP调用和模型推理的请求/响应捕获到Unity Catalog管理的系统表中，记录工具名称、参数、结果、用户身份和允许/拒绝状态。通过request_id关联推理表和评估表，可实现端到端追踪。这让代理系统从”黑箱”变为”可审计工作流”——用SQL即可查询”过去24小时哪个代理删除了哪些数据”。
  • LLM Guardrails——用模型守模型：预置PII检测与脱敏、越狱/提示注入检测、不安全内容过滤三类护栏，另支持自定义护栏。关键设计是用一个小型LLM（如databricks-gpt-5-nano）实时评判输入/输出是否违规——相比传统正则或关键词匹配，LLM护栏能理解语义上下文，误报率更低。高级模式支持”日志模式”先观察后拦截，避免新护栏误杀正常流量。
  • Cost Controls——四级预算硬顶：提供用户级、用例级、工作空间级、账户级四级预算配置。支持按用户设置月度Token限额和邮件告警，超限时自动阻断——这对”批量作业失败触发10倍重试循环”和”多代理实验烧掉月度预算”的失控场景至关重要。成本数据通过Unity Catalog系统表提供，支持按用户、模型、提供商、成本中心等维度归因分析。

行业影响

Unity AI Gateway四项扩展的集中发布，标志着AI代理治理从”原则讨论”进入”工程实践”阶段。此前业界对AI代理安全的讨论多停留在框架和原则层面（如NIST AI RMF、OWASP Top 10 for LLM），缺乏可直接部署的工程能力。Databricks将数据库治理领域成熟的”策略-审计-监控-预算”四层模型移植到AI代理领域，关键创新点在于：Service Policies用SQL而非DSL定义规则（降低学习成本），Payload Logging写入Delta表而非专用日志系统（与数据治理统一），Guardrails用LLM而非正则评判（理解语义），Cost Controls硬顶而非软告警（真正防止失控）。

对DataInfra团队而言，这意味着：如果你的平台正在或即将承载AI代理工作负载，治理架构应从”事后监控”设计为”事前拦截+事中审查+事后审计”三层。Unity AI Gateway的模式值得参考——尤其是Payload Logging将代理行为数据写入可查询的结构化表这一设计，让安全团队可以用熟悉的SQL完成审计而非学习新工具。

相关链接

Valkey 9.1 GA：搜索并入核心，内存砍10%，单节点2.1M RPS

事件概述

5月19日，Valkey 9.1在Open Source Summit North America上正式GA。这是Valkey从Redis fork出来后的又一个重要版本，贡献者超过80人。9.1的核心叙事是”从缓存进化为数据基础设施”——将Valkey Search 1.2并入核心引擎，实现了全文搜索+向量搜索+KV缓存的一体化；通过字符串和有序集合的内存布局优化砍掉10%内存占用；新增数据库级ACL、CLUSTERSCAN集群扫描、HGETDEL原子操作等关键命令；单节点吞吐达到2.1M RPS（512字节载荷、9 IO线程、pipeline深度10）。

技术解析

  • 搜索并入核心：Valkey Search 1.2（全文搜索、数值过滤、标签查找、向量搜索）不再作为独立模块，而是内置到核心引擎中。这意味着部署Valkey即可获得混合搜索能力——确定性全文检索+近似向量检索——无需额外部署Elasticsearch或专用向量数据库。对AI代理场景尤为关键：代理需要同时做精确关键词匹配和语义向量搜索，单引擎覆盖两种模式大幅简化架构。
  • 内存优化：128字节以下字符串内存减少20%，有序集合跳表内存减少10%，整体常见负载内存降低约10%。无需任何配置变更，升级即生效。加上哈希表rehash延迟优化和批量删除期间暂停内部resize，运行时稳定性同步提升。
  • 数据库级ACL：此前Valkey的ACL只能在全局级别限制用户命令执行，9.1新增按数据库编号限制（如db=0,1），让多租户场景下的权限隔离从”分实例”变为”分库”——单实例即可隔离不同租户，节省运维成本。
  • CLUSTERSCAN：此前客户端需逐节点SCAN后手动合并结果，9.1新增CLUSTERSCAN命令提供集群级统一扫描接口，支持MATCH模式匹配和TYPE类型过滤，消除跨节点扫描的应用层复杂度。
  • 新IO线程模型：带来17%吞吐提升，流操作（XRANGE/XREVRANGE）快30%，字符串GET命令吞吐提升30%。

行业影响

Valkey 9.1将搜索能力并入核心这一决策，对数据基建格局有深远影响。此前”缓存+搜索”的组合通常需要Valkey/Redis + Elasticsearch/OpenSearch两套系统，9.1让Valkey在单进程内覆盖缓存、会话存储、实时搜索和向量检索四种场景。特别是在AI代理和RAG架构中，代理需要同时访问缓存（上下文）、结构化数据（工具结果）和向量索引（知识库），Valkey正在成为”AI代理的统一数据层”候选。

但需注意：Valkey Search目前的规模能力（TB级数据、微秒延迟、百万RPS）主要面向实时场景，还无法替代Elasticsearch在日志分析、大规模文档检索等批处理场景的地位。对于”缓存+轻量搜索”的团队，9.1可以大幅减少组件数量；对于”重度搜索”的团队，仍需双引擎策略。

相关链接

Amazon Redshift RG实例：Graviton内置数据湖引擎，消灭Spectrum扫描费

事件概述

5月19日，AWS博客正式宣布Amazon Redshift RG实例GA。RG实例基于AWS Graviton处理器，内置向量化数据湖查询引擎，直接在集群内执行Iceberg和Parquet数据湖查询，不再需要将查询卸载到独立的Spectrum fleet。实测数据：Iceberg数据湖查询最高2.4x加速，Parquet查询1.5x加速，数据仓库工作负载2.2x加速，同时每vCPU成本降低30%。更关键的是——RG实例彻底消除了Spectrum $5/TB的扫描费用，数据湖查询成本从”按扫描量计费”变为”按集群容量计费”。

技术解析

  • 内置向量化引擎：RG实例在Redshift集群内集成了专用的向量化数据湖扫描引擎，包含优化扫描层（最新数据裁剪技术）和专用IO子系统（利用Graviton的内存带宽优势）。此前RA3架构的数据湖查询走Spectrum——独立的Presto-based联邦查询引擎，查询需要跨网络从S3拉取数据到Spectrum节点再返回结果，Spectrum按$5/TB扫描量计费。RG将这一流程内化到集群内，查询路径更短、延迟更低、成本更可预测。
  • JIT ANALYZE：新引擎内置即时统计信息收集功能，在查询执行期间自动识别需要统计信息的场景并透明收集，使用轻量级sketch数据结构维护表级和列级统计。消除了手动ANALYZE的需求——这是此前Redshift用户最常见的运维痛点之一。
  • Graviton架构优势：更多计算核心、更高内存带宽、更低进程间通信延迟。Southwest Airlines实测：数据仓库工作负载50-60%加速，数据湖分析45%加速。Tombola实测：写入1.8-2x加速，读取2.2x加速，40%更多处理量，30%计算支出缩减。
  • 迁移路径：支持Elastic Resize（推荐，10-15分钟停机）、Snapshot & Restore（可并行测试）、Classic Resize三种方式。从RA3或DC2均可迁移，24+区域可用。

行业影响

Redshift RG实例代表了云数仓的一个架构方向性转变：数据湖查询从”联邦计算”回归”本地计算”。Spectrum的设计哲学是”计算与存储分离，按需弹性”——但在实践中，$5/TB的扫描费用让频繁查询数据湖的团队不堪重负。RG将数据湖查询引擎”拉回”集群内部，用固定的集群容量成本替代弹性的扫描计费，这本质上是用”预付费”换”可预测”——对数据湖查询量大且稳定的团队是绝对的利好。

结合Vol.1报道的Iceberg v3生态闭环，RG实例的Iceberg 2.4x加速并非偶然——当开放格式成为标准，数仓引擎的竞争焦点从”格式兼容性”转向”开放格式查询性能”。Redshift选择在集群内内置向量化引擎而非依赖外部Spectrum，说明数据湖查询性能正在成为云数仓的核心竞争力指标。

相关链接

Pulumi押注Agent基础设施时代：IaC的一等公民从人类变成AI代理

事件概述

5月19日，The New Stack报道Pulumi全面押注”Agentic Infrastructure Era”。CEO Joe Duffy透露AI代理已驱动Pulumi平台20%的操作——一年前这个数字几乎为零。Pulumi同步发布一系列面向AI代理的产品能力：临时云账号（Ephemeral Cloud Accounts，代理可自主创建72小时免费账户）、pulumi do命令（单资源命令式创建，无需项目脚手架）、Neo集成目录（通过MCP服务器连接Datadog/PagerDuty/Supabase等外部服务）、以及CLI的30+项增强（JSON输出、结构化错误消息、变更历史/漂移检测/审计日志等）。Duffy更预测未来AI代理驱动的操作比例可能达到100%。

技术解析

  • 临时云账号：AI代理可自主创建免费的Pulumi Cloud账户，无需人工注册流程。账户72小时过期，但人类可在过期前认领转为永久账户。这解决了”代理需要云身份才能操作但创建账户需要人类介入”的鸡生蛋问题——让代理零摩擦启动，人类事后审核。
  • pulumi do命令：pulumi do create eks:Cluster即可创建EKS集群，跳过传统Pulumi项目初始化（pulumi new→写代码→pulumi up）的全流程。这本质上是声明式IaC向命令式IaC的回归——但对AI代理而言，命令式比声明式更自然：代理不需要”描述期望状态”，它需要”执行一个动作”。
  • Neo集成目录：通过远程MCP服务器连接Atlassian、Datadog、Honeycomb、Linear、PagerDuty、Supabase等外部服务，加上kubectl CLI集成。代理不再只是”创建资源”，而是可以跨开发工具链执行操作——创建资源、配置监控、设置告警、更新工单，全在同一个代理会话中完成。
  • 语言优势：Duffy强调Pulumi使用Python/TypeScript/Go而非HCL的关键优势——LLM在通用编程语言上的训练数据远比HCL丰富（HCL示例多来自教程而非生产代码），这使Pulumi在AI代理场景下天然比Terraform更适合。已有客户用Neo代理1小时内迁移500个Terraform工作空间到Pulumi。

行业影响

Pulumi的”Agent基础设施”叙事与前三期的趋势形成完整闭环：Vol.1 Anyscale Agent Skills让AI代理掌握Ray分布式计算，Vol.2 OpenSearch Agent Skills让AI代理掌握搜索与可观测性——这些都是在具体基础设施领域内让代理”会操作”。Pulumi则是在基础设施管理元层让代理成为一等公民：不只是操作某个具体系统，而是定义、创建、管理整个基础设施。

更深层的影响是：IaC的范式可能正在从”人类编写声明式配置”转向”AI代理执行命令式操作”。pulumi do命令的出现是一个信号——当操作者从人类变为AI代理时，声明式（描述期望状态）不如命令式（执行动作）高效，因为代理不需要”描述”意图，它直接”执行”意图。如果这一趋势持续，IaC工具的竞争焦点将从”语言表达力”转向”代理可操作性”。

相关链接

编者评

第三期的四条动态，与前两期的主线形成了清晰的递进关系。创刊号提出”AI原生基础设施”趋势，第二期看到Anyscale和OpenSearch跨厂商验证”基础设施AI代理化”，本期则看到这一趋势进入了更深层的治理和管理维度：Databricks用四层治理架构解决了”AI代理失控怎么办”的问题，Pulumi解决了”AI代理如何自主管理基础设施”的问题——从”代理能操作”到”代理被治理”再到”代理自主运维”，AI代理在基础设施中的角色正在从”工具使用者”进化为”自主运营者”。

Valkey 9.1和Redshift RG则从另一个维度呼应了Vol.2提出的”数据基建边界消融”趋势：Valkey将搜索并入缓存引擎消除了缓存与搜索的边界，Redshift将数据湖引擎并入数仓集群消除了联邦查询与本地查询的边界。引擎一体化和代理自治化是同一枚硬币的两面——当AI代理需要一站式访问数据时，多引擎架构成为摩擦而非优势；当引擎一体化消除了代理的跨系统协调负担，代理才能真正实现端到端自主操作。

下一期将继续追踪Data + AI Summit 2026（6月15-18日）前后的密集发布期，以及LanceDB/Daft等新兴数据基建的版本动态。