datainfra前沿动态 · Vol.29

Databricks Omnigent上下文策略实现会话态AI代理治理；AWS OpenSearch Service可写温存储消除热温迁移周期成本降低48%；Databricks _object_metadata列Public Preview将云对象元数据暴露为DataFrame列

第二十九期聚焦DataInfra三条动态：7月7日Databricks发布Omnigent上下文策略（Contextual Policies）深度技术博客，Matei Zaharia等五位作者阐述基于会话状态的AI代理治理新范式——Google Drive Policy实现Bell-LaPadula安全模型、Risk Score Policy动态累积风险评分、Cost Policy按会话管理预算、Intent-Based Authorization基于初始意图最小权限；7月8日AWS OpenSearch Service推出可写温存储（writable warm storage），OI2实例替代UltraWarm只读限制消除130分钟/100GB的热温迁移周期，3年预留实例成本降低48%，搜索延迟与UltraWarm持平或更优；7月8日Databricks Runtime 18.1起_object_metadata列进入Public Preview，将MIME类型、ETag、用户自定义元数据、系统元数据、对象标签暴露为DataFrame STRUCT列，集成Auto Loader流式摄取和COPY INTO批量加载。

DataInfra Databricks Omnigent Contextual Policies AI Agent Governance Session State Bell-LaPadula Risk Score Cost Policy Intent-Based Authorization Matei Zaharia AWS OpenSearch Writable Warm Storage OI2 UltraWarm Tiered Storage Cost Optimization Object Metadata Public Preview Cloud Storage DataFrame Auto Loader COPY INTO 数据基础设施 DataInfra前沿动态 Vol.29

第二十九期追踪到DataInfra领域三条动态：7月7日Databricks发布Omnigent上下文策略（Contextual Policies）深度技术博客——由Matei Zaharia、David Nasi、Xiangrui Meng、Kecheng Cao、Tomu Hirata五位作者联合发表，阐述基于会话状态（session state）的AI代理治理新范式。Omnigent作为一个开源meta-harness，允许策略跨Claude Code、Codex、Antigravity、Pi、OpenCode、Hermes等编码代理统一执行。四大内置策略：Google Drive Policy实现Bell-LaPadula”no write-down”安全模型——写操作被限制在代理当前会话创建的文档内，一旦读取机密文档即刻收紧写入范围；Risk Score Policy维护会话级动态风险评分——低风险时自动通过，一旦触及阈值则要求人工审批（如读取敏感材料后发邮件）；Cost Policy按会话设预算软硬上限——超过警告线暂停征询、超过硬上限自动切换廉价模型；Intent-Based Authorization基于用户初始提示实施最小权限——代理只需声明”更新Google Slides”则无法访问GitHub。核心理念：现有代理框架只有简单的allow-list/deny-list控制（检查单次操作），Omnigent的策略可以”记住会话中发生了什么”，用累积状态决定下一步操作的放行/询问/拒绝；7月8日AWS OpenSearch Service推出可写温存储（writable warm storage）——基于OI2（OpenSearch Optimized）实例家族，消除了UltraWarm只读限制导致的热→温→热迁移周期（每100GB索引约130分钟+强制合并+快照创建+分片重定位）。因为OI2与OR2热节点共享Amazon S3持久化存储，温层转换变为轻量级分片重定位而非资源密集型迁移。成本对比（2TB/天摄取+210天保留）：从UltraWarm方案（30天热+180天温，$74,427/月按需）到可写温存储方案（7天热+203天温，$69,297/月按需），3年预留实例下可降低48%（34,939vs34,939 vs 67,367）。搜索性能：writable warm在NYC_TAXIS基准测试7种查询类型的6种上匹配或优于UltraWarm；7月8日Databricks Runtime 18.1起_object_metadata列进入Public Preview——将云存储对象的MIME类型、ETag、用户自定义元数据（user_metadata）、系统定义元数据（system_metadata）、对象标签（tags）暴露为DataFrame中的STRUCT列。与_metadata列（文件路径、大小、修改时间）互补，适用于所有文件格式+Auto Loader流式摄取+COPY INTO批量加载。每个文件触发最多2次额外云API调用，适用于Amazon S3/Azure DFS/Azure Blob/GCP。应用场景：合规审计（追踪ETag证明文件未篡改）、数据目录自动化（user_metadata中的部门/项目标签驱动下游ETL路由）、多租户隔离（通过对象标签区分不同团队数据）。

Databricks Omnigent上下文策略：会话态AI代理治理从”单次操作allow-list”走向”累积状态驱动决策”

事件概述

7月7日，Databricks联合创始人兼CTO Matei Zaharia与David Nasi、Xiangrui Meng、Kecheng Cao、Tomu Hirata在Databricks博客联合发表《Contextual Policies in Omnigent: Using session state to better govern AI agents》深度技术文章（原文链接，2026-07-07）。这是继Vol.25报道Omnigent开源meta-harness（2026-07-04）和Vol.26报道Managed Omnigent on Databricks后，Omnigent安全治理能力的首次完整技术阐述。

Omnigent作为一个开源meta-harness（omnigent.ai，GitHub），核心定位是跨代理harness的统一治理层——它不替代Claude Code、Codex、Antigravity、Pi、OpenCode、Hermes等编码代理，而是在它们之上加一个共享的”协作+组合+策略”层。上下文策略（contextual policies）是这个治理层中最具创新性的能力——它改变了AI代理安全控制的根本范式：从”检查单个操作是否被允许”升级为”基于会话中已经发生的一切来决定下一步”。

核心洞察：AI代理引入的新型企业风险无法用传统的allow-list/deny-list解决。Zaharia等举了一个关键例子——Simon Willison的”Lethal Trifecta”（代理同时读取不可信内容+访问敏感数据+与外部通信）和Meta的”Agents Rule of Two”：一个编码代理推送到GitHub通常是安全的，但如果它之前下载了一个可能包含注入攻击的不可信网页，同一个GitHub推送就变成高风险操作。传统allow-list只能允许或禁止Git推送——无法区分”有上下文”和”无上下文”的安全判断。人工审批每个操作则导致审批疲劳。

Omnigent的上下文策略通过在策略处理函数中维护会话状态（state）——在Omnigent server端持久化的任意变量（仅对该策略可见）——实现了上下文感知的安全决策。策略可以监听代理执行的每个事件（工具调用、LLM输入/输出），更新状态（如”已读取文档A”、“已花费$X”、“风险评分+5”），并在每次事件时基于当前累积状态决定ALLOW/DENY/ASK/TRANSFORM。

技术解析

  • Google Drive Policy——Bell-LaPadula安全模型的工程实现：Google Drive策略实现了经典军事安全模型Bell-LaPadula的”no write-down”规则——代理只能写入当前会话创建的文档（防止污染已有文件），但一旦代理读取了标记为confidential的文档，即使是自己刚创建的文档也变为不可写——因为向非机密文件写入机密内容会造成数据泄露。策略通过跟踪会话中哪些文档被读取（作为state）和对写入目标的动态判断实现。这与传统allow-list的关键差异：同一个”写入文档”操作在会话初期可能ALLOW，在读取机密文件后同一操作变为DENY——策略的输出是state-dependent而非静态rule。

  • Risk Score Policy——从二进制安全走向连续风险谱：风险评分策略维护一个会话级的累积风险评分（单一数字）。管理员可以配置每个操作的评分增量——常规工具调用加1-2分，读取高机密文档加大量分。自动阈值机制：低分时所有操作自动通过（减少审批疲劳），一旦超过阈值，发邮件/分享文件等操作从ALLOW变为ASK（要求人工审批）。关键设计：同一个操作是否安全不是非黑即白，而取决于在此之前积累了多少风险——这是传统allow-list完全无法实现的能力。

  • Cost Policy——按会话而非按用户的精细预算管理：成本策略追踪会话模型调用累计花费。双层阈值：软上限——暂停并询问是否继续；硬上限——阻止继续调用昂贵模型但允许切换到廉价模型继续会话。跨会话叠加：平台团队可以在per-session预算之上叠加per-user每日预算上限，防止跨多个会话累计超支。策略判断的不是单个模型调用，而是运行总和。

  • Intent-Based Authorization——最小权限的工程化实现：这是最简洁但最具威力的策略——基于用户初始提示（initial prompt）实施最小权限。例如用户开始时说”帮我更新Google Slides演示文稿”，策略记住这个意图作为state，此后每次工具调用都检查是否与初始意图相关。代理试图访问GitHub时，即使GitHub工具在全局allow-list中，策略也会因为”与初始意图无关”而阻止。同一个GitHub推送在一个会话中是允许的（初始意图是”提交代码”），在另一个会话中却被阻止（初始意图是”做PPT”）。这是会话级动态权限下放的工程实现。

行业影响

Omnigent上下文策略的意义不仅在于四个内置策略，更在于它定义了AI代理治理的一个新的技术维度——“会话状态作为安全决策的输入”。这是与传统API网关/WAF/IAM等静态访问控制的根本区别。

将本期与Vol.25报道的LanceDB v0.31.0/v0.34.0稳定版（OAuth+单调读一致性+企业级多租户）对比：LanceDB在向量数据库存储层解决多租户隔离问题，Omnigent在代理编排层解决会话态治理问题。两者都是”AI代理生产化”基础设施的关键组件，但作用于不同层面——LanceDB确保代理只能读取被授权的向量数据，Omnigent确保代理在读取后的行为（是否将结果写入/发送/推送）符合安全策略。

将本期与Vol.3报道的Databricks Unity AI Gateway四大扩展（Service Policies/Payload Logging/LLM Guardrails/Cost Controls）和Vol.28报道的Unity AI Gateway Budgets GA对比：Unity AI Gateway的治理模型是请求级静态检查（检查单次API调用的参数/模型/成本），Omnigent上下文策略是会话级动态决策（追踪整个会话的所有操作后决定下一步）。两者互补但不在同一维度——Gateway负责”这次调用是否合规”，Omnigent负责”在做了这些事之后，下一步是否还安全”。

将本期与Vol.26报道的Databricks Genie App Builder三件套（App Spaces空间级治理+App Builder数据感知应用构建+Serverless Micro Apps scale-to-zero运行时）对比：Genie App Builder的治理在应用空间和数据访问层面，Omnigent的治理在代理执行过程的行为层面。两者结合形成了一个完整的”治理图谱”：空间治理（谁可以进入哪个数据空间）→ 数据治理（进入后可以访问哪些表/视图/模型）→ 行为治理（访问后可以做哪些操作，以及做了某些操作后是否还能继续做其他操作）。

相关链接

AWS OpenSearch Service可写温存储：消除热温迁移周期，3年预留实例成本降低48%

事件概述

7月8日，AWS Big Data Blog发布Bharav Patel的技术文章《Cut costs and simplify operations with writable warm storage in Amazon OpenSearch Service》（原文链接，2026-07-08），详细介绍可写温存储（writable warm storage）这一全新存储层能力。

背景：Amazon OpenSearch Service管理PB级搜索数据时，传统分层架构为Hot（热层，SSD，可读写）→ UltraWarm（温层，S3支持+本地缓存，只读）→ Cold（冷层，完全脱集群，不可直接读写）。对于不可变日志数据这个模型运作良好，但现实中的许多工作负载需要偶尔更新历史记录——延迟到达的数据、合规修正、数据回溯等。在UltraWarm只读限制下，更新单个文档需要：将索引从温层迁移回热层→执行写入→迁移回温层。这个”热→温→热”往返涉及强制合并（force merge）、快照创建（snapshot creation）、分片重定位（shard relocation）——约130分钟/100GB索引（基准测试环境：3×r6g.2xlarge热节点+3×ultrawarm1.large温节点+3专用主节点，US East N. Virginia，单分片+1副本）。这迫使企业过度配置热节点、构建复杂迁移管道、或将数据在热层保留比必要更长的时间。

可写温存储的核心创新：基于OI2（OpenSearch Optimized）实例家族——与OR2热节点使用相同的Amazon S3持久化存储架构。因为数据已经在S3上持久化，温层转换变为轻量级分片重定位而非资源密集型迁移。Lucene引擎（OpenSearch底层搜索库）在两层上操作相同——可写温节点支持主动写入、后台合并、周期性刷新，与热节点无异。

技术解析

  • 成本优势——RI定价首次覆盖温存储：UltraWarm仅支持按需定价，而OI2实例支持预留实例（RI）（承诺1年或3年）。对于可预测的长期运行工作负载，1年AURI比UltraWarm按需节省36%、3年AURI节省48%。新推出的Database Savings Plan for OpenSearch Service比UltraWarm约节省22%。两者都使用S3持久化存储——节点故障只导致暂时不可用而非数据丢失。对于容忍短暂停机的成本敏感型工作负载，可在温索引上配置零副本降低进一步成本。实际成本对比（2TB/天摄取+210天总保留，更新可能随时到达）：UltraWarm方案（30天热层+180天温层）按需月费$74,427，3年AURI $67,367；可写温存储方案（仅需7天热层+203天温层）按需月费$69,297，1年AURI $43,918（36%↓），3年AURI $34,939（48%↓）。关键节省来自热层保留从30天缩短到7天——因为更新可以直接在温层完成，无需为了可能的更新而将数据在热层保留更久。

  • 运维简化——回收热节点容量：可写温存储消除了热节点过度配置的两个常见原因：（1）为强制合并操作保留35%磁盘空间；（2）为临时迁回数据维护额外容量。热层可以利用更高利用率运行，减少热节点数量。迁移简化：UltraWarm迁移是多步骤操作（强制合并→快照→分片重定位），需要低流量窗口期调度，且排队上限10个。可写温存储将其简化为轻量级分片重定位，ISM策略更简单，无调度约束。

  • 实例灵活性——从2种到全梯度：UltraWarm仅提供2种实例大小（ultrawarm1.medium 1.5 TiB / ultrawarm1.large 20 TiB）。OI2实例家族提供从oi2.large到oi2.16xlarge全梯度——每个大小支持最多5倍本地缓存容量，可精确匹配工作负载。

  • 搜索性能——匹配或优于UltraWarm：在NYC_TAXIS基准测试的7种查询类型中，可写温存储在6种类型上匹配或优于UltraWarm（P90延迟）。默认查询：21.29ms vs 23.86ms（12%改善）；范围查询和聚合查询接近持平。对于大多数实际搜索模式，可写温存储提供了与UltraWarm相当或更优的性能，额外具备直接写入能力。

  • 限制条件：需要OpenSearch Service 3.3+、OI2实例家族、最少5秒刷新间隔。不支持冷存储层（cold tier）——需要冷层支持的工作负载仍使用UltraWarm。每个文件触发最多2次额外云API调用（获取元数据），大量小文件场景有延迟影响。对象标签（tags）仅S3和Azure Blob（非HNS）支持，其他provider返回{}；S3需要s3:GetObjectTagging权限。

行业影响

AWS OpenSearch Service可写温存储的发布意义不是”又一个存储层选项”，而是搜索与分析存储分层架构的根本性反思——它质疑了一个长期以来被视为理所当然的假设：“温层必须是只读的”。这个假设源于传统温存储基于低成本但只适合读取的基础设施（S3+缓存的被动读模型），但OI2实例通过S3直写架构打破了这一约束。

将本期与Vol.24报道的AWS OpenSearch Service新日志分析引擎GA（97%代码从零重写、Parquet列存+Apache Calcite SQL优化+DataFusion向量化执行+Lucene倒排索引四层架构，P50查询延迟降至1/10、存储成本降至1/20）对比：新日志分析引擎解决”查询速度”问题（专用分析引擎），可写温存储解决”存储经济学”问题（温层可写消除迁移成本）。两者是OpenSearch Service在”引擎专用化”（日志引擎）和”存储分层化”（温层可写）两个维度上的同步演进。

将本期与Vol.22报道的Databricks Liquid Clustering 8大误区（Arctic Wolf 3.8PB表7.7倍加速+OPTIMIZE规划12h→23min+行级并发替代文件级）对比：Liquid Clustering解决”热数据的物理组织”问题（分区替代方案），可写温存储解决”冷热数据的经济学”问题（温层访问模式）。两者从不同角度优化数据湖/搜索平台的总成本——前者减少查询时扫描的不必要数据，后者减少迁移时不必要的数据移动。

将本期与Vol.27报道的Apache Paimon 1.4.2（BLOB类型+Lumina向量索引+Data Evolution行级部分列更新+PyPaimon Python SDK）对比：Paimon的Data Evolution解决”湖仓表的部分列更新”（变更数据如何高效写入湖仓），可写温存储解决”搜索索引的延迟更新”（历史索引如何低成本修改）。两者都是”数据更新不应该总是全量重写”这一理念在不同存储系统中的体现。

相关链接

Databricks _object_metadata列Public Preview：云对象元数据变为DataFrame一等公民

事件概述

7月8日，Databricks文档更新宣布**_object_metadata列进入Public Preview**（文档链接，2026-07-08，自Databricks Runtime 18.1起可用）。_object_metadata是一个隐藏元数据列（hidden metadata column），将云存储对象的丰富属性——MIME类型、ETag、用户自定义元数据、系统定义元数据、对象标签——暴露为DataFrame中的STRUCT列。

与_metadata列的关系：Spark长期以来支持_metadata列（包含文件路径、大小、修改时间等文件系统层信息），但_object_metadata提供的是存储层（cloud API）的属性——这些属性不是文件系统的固有属性，而是需要通过云API（S3 GetObject/HeadObject、Azure Blob Get Properties）获取的对象级附加信息。

技术解析

  • Schema设计：_object_metadata列是一个STRUCT类型，包含5个字段（全部nullable）：mime_type（STRING，如application/parquet、text/csv）、etag（STRING，用于检测变更或版本控制，如"abc123def456"）、user_metadata（VARIANT，用户自定义的键值对，如{"my_key":"my_value"}）、system_metadata（VARIANT，云存储服务商设置的系统键值对）、tags（VARIANT，用户自定义对象标签键值对）。VARIANT类型的user_metadata、system_metadata、tags可使用::cast操作符或VARIANT函数提取具体值。

  • 集成方式——与Auto Loader和COPY INTO深度集成：_object_metadata列不仅可用于批读取（spark.read.format("csv").load(path).select("*", "_metadata", "_object_metadata")），还支持Auto Loader流式摄取——将对象元数据连同文件内容一起写入Delta表，以及COPY INTO——在SELECT *, _object_metadata FROM子句中捕获元数据。提取VARIANT字段值的示例：_object_metadata.user_metadata:my_key::string as my_key、_object_metadata.tags:environment::string as env_tag。

  • 云平台兼容性：支持Amazon S3、Azure DFS、Azure Blob、GCP。对象标签（tags）支持S3和Azure Blob Storage（非HNS），其他provider（Azure DFS、WASB、GCP）返回{}。S3需要s3:GetObjectTagging权限，获取失败返回null。Databricks托管存储的system_metadata/user_metadata/tags均返回null。

  • 性能考虑：选择任意_object_metadata字段会触发每个文件最多2次额外云API调用——大量小文件的查询可能有一定延迟增加。为避免未来schema变更导致的错误，建议在查询中选择具体字段（如_object_metadata.user_metadata）而非整列。如果数据源已有名为_object_metadata的列，可通过双下划线前缀__object_metadata访问云对象元数据列。

  • 应用场景：（1）合规审计——通过ETag追踪文件是否被篡改（同一文件内容不同→ETag不同）；（2）数据目录自动化——通过user_metadata中的部门/项目/环境标签驱动下游ETL路由（如department=finance的文件进入财务数据管道）；（3）多租户数据隔离——通过对象标签区分不同团队的数据，在摄取层做租户路由；（4）内容类型感知处理——通过MIME类型自动选择解析器（如application/parquet→Parquet读取器，text/csv→CSV读取器）；（5）数据质量监控——通过系统元数据（如Content-Length）与文件系统层面的大小对比检测不完整上传。

行业影响

_object_metadata列看似只是一个新增的元数据列，但它在数据工程工作流中代表了一个重要范式转变：云对象存储的附加属性从”运维人员手工管理的外部标签”变为”数据管道内部可编程消费的一等公民”。

在传统数据工程实践中，云对象的tags和metadata通常在基础设施层（Terraform/CloudFormation/S3 API）管理，数据管道（Spark/Auto Loader）完全不感知。这意味着：（1）数据分类/归属信息需要通过外部元数据服务（如Glue Catalog/Unity Catalog）同步；（2）数据管道路由决策只能基于文件路径/大小/修改时间（_metadata列提供的有限属性）；（3）合规审计需要单独调用云API查询对象属性。_object_metadata列将这三个操作统一到同一个DataFrame查询平面——数据内容和对象元数据在同一个操作中可用。

将本期与Vol.28报道的Databricks Managed Iceberg Materialized Views Public Preview（与外部Iceberg reader兼容的物化视图）对比：Managed Iceberg MV解决”表格式互操作”（不同引擎读取同一张表），_object_metadata列解决”存储层互操作”（不同云存储服务商的元数据统一为DataFrame列）。两者共同推动数据基础设施的跨层标准化——表格式层和存储层各自向标准化方向演进。

将本期与Vol.22报道的Delta Lake 4.3（Delta REST Catalog统一API+服务端提交验证+意图式元数据更新+Row Tracking读取）对比：Delta Lake 4.3的元数据管理在表级别（schema evolution、row tracking、column lineage），_object_metadata列的元数据管理在文件/对象级别（MIME type、ETag、tags、user metadata）。两者形成”表级元数据→文件级元数据”的完整元数据谱系——Delta Lake负责”表中的数据如何被组织和管理”，_object_metadata负责”文件本身携带了哪些附加信息”。

相关链接

编者评

本期三条动态表面上看分别属于AI代理治理、搜索存储架构和数据工程元数据三个不同领域，但它们共同指向一个深层次的趋势：数据基础设施的”上下文化”（contextualization）——Omnigent上下文策略把”会话中发生了什么”注入代理治理决策、OpenSearch可写温存储把”数据是否还需要被修改”注入存储分层决策、_object_metadata列把”文件携带了哪些附加属性”注入数据管道处理逻辑。这不是简单的功能叠加，而是一种架构哲学转变：数据基础设施不再是”被动响应”（你发一个请求，我执行一个操作），而是”主动感知”（我知道上下文，我基于上下文决策）。Omnigent的上下文策略把这个转变推到极致——同一个工具调用可以在会话初期被ALLOW、在会话中期被ASK、在会话晚期被DENY，因为策略不是在检查操作本身，而是在评估操作在当前会话状态下的意义。这种”上下文感知基础设施”的范式与Vol.28报道的Snowflake Cortex Sense（agent的context runtime，自动从5层上下文组装语义信息）和Vol.27报道的阿里云EMR Serverless Spark混合检索（标量+向量检索在同一个SQL中完成）是一脉相承的——基础设施不再只是”更快更便宜地执行”，而是”更聪明地理解它正在处理什么”。这是AI时代数据基础设施演进中一条隐蔽但至关重要的主线。