datainfra前沿动态 · Vol.12

Databricks Iceberg v3 GA让湖仓格式竞争从格式层转向目录层；AWS重构OpenSearch Serverless为AI代理从零设计搜索基础设施；LanceDB走出beta发布首个稳定版

Iceberg v3 GA让湖仓竞争从格式层转向目录层；AWS重构OpenSearch Serverless为AI代理设计搜索基础设施；LanceDB走出beta发布首个稳定版

DataInfra Databricks Apache Iceberg Iceberg v3 Unity Catalog 删除向量 行追踪 VARIANT 开放湖仓 目录联邦 ABAC DeltaSharing 零拷贝共享 AWS OpenSearch Serverless 存储计算解耦 scale-to-zero AI代理 Vercel Kiro Agent Skills LanceDB 稳定版 多模态湖仓 命名空间 流式摄取 LSM

第十二期追踪到DataInfra领域三条重要动态：Databricks 5月28日宣布Apache Iceberg v3在Unity Catalog上正式GA——删除向量让行级删除无需重写数据文件（MERGE语句更新速度最高10倍提升）、行追踪为每行分配唯一ID实现行级并发冲突检测、VARIANT数据类型让半结构化数据在Delta和Iceberg表上无需shredding即可高效查询，三者组合让开放湖仓表格式在功能层面首次达到与Delta Lake同等的行级操作能力，同日发布Unity Catalog五大差异化能力将竞争焦点从”谁的格式更好”推向”谁的目录更开放”——开放API+凭证分发让任何兼容引擎安全接入、目录联邦将异构目录统一视图管理、跨引擎ABAC让Spark/Trino/Flink执行同一属性级权限策略、零拷贝安全共享基于DeltaSharing协议覆盖外部系统管理的表、AI驱动性能优化在Managed模式下自动维护查询性能；AWS同日发布下一代Amazon OpenSearch Serverless——97%代码由托管服务工程师从零重写，核心架构变更是存储与计算完全解耦：计算资源可缩至零（空闲时$0），需要时秒级拉起，自动扩缩速度提升20倍，相比峰值预留集群节省60%成本，AWS OpenSearch总经理Tia White直言此前”OpenSearch曾试图做瑞士军刀什么都想做甚至转向SIEM但走不通”，现在围绕AI代理工作负载重新定位，原生集成Vercel/Kiro和OpenSearch Agent Skills让开发者在Claude Code/Cursor中直接构建搜索后端——TechCrunch评价此为”互联网正在为机器重建”的标志性事件，Cloudflare数据显示机器人流量已占HTTP总流量的31%，预计2027年上半年非人类流量将超越人类流量；LanceDB同日发布v0.30.0（Node/Rust）和v0.33.0（Python）首个稳定版——此前Vol.2至Vol.11多次提及LanceDB”仍为beta未入选”，此次稳定版发布标志着AI原生多模态湖仓正式达到生产就绪，命名空间管理（Connection级命名空间操作）、流式摄取（Scannable原语支持Table.add进度追踪）、非强制主键（unenforced primary key概念）、LSM写入规范（table级配置）、嵌套字段路径原生索引创建和读一致性新鲜度头（read freshness headers）随稳定版一同落地——这三条动态共同指向DataInfra的又一个维度跃迁：基础设施的竞争维度从”功能对等”走向”治理开放”（Iceberg v3 GA让格式不再是选择障碍，目录层成为差异化战场），从”为人设计”走向”为代理设计”（OpenSearch Serverless 97%代码重写只为适应代理的爆发式流量模式），从”技术预览”走向”生产就绪”（LanceDB稳定版让多模态湖仓从实验技术变为可部署的基础设施）。

Databricks Iceberg v3 GA与Unity Catalog五大差异化能力：湖仓竞争从格式层转向目录层

事件概述

5月28日，Databricks发布博客宣布Apache Iceberg v3在Unity Catalog上正式GA（Generally Available）。Iceberg v3的三项核心能力——删除向量（Deletion Vectors）、行追踪（Row Lineage）和VARIANT数据类型——现在在Unity Catalog的托管Delta表（通过UniForm）、托管Iceberg表和外部Iceberg表上全面可用。删除向量允许在不重写Parquet数据文件的情况下执行行级删除和更新，相比传统MERGE语句更新速度最高10倍提升；行追踪为每行分配唯一ID，结合删除向量实现行级并发（row-level concurrency）冲突检测——Databricks声称这是唯一在开放表格式上提供行级并发能力的湖仓引擎；VARIANT数据类型让半结构化数据直接存储于lakehouse表中，支持shredding将公共字段提取为独立列以获得列式查询性能。同日，Databricks发布Unity Catalog五大差异化能力，将开放湖仓竞争叙事从”格式选择”推向”目录治理”：开放API与凭证分发、目录联邦、跨引擎基于属性的访问控制（ABAC）、零拷贝安全共享、AI驱动性能优化与格式创新。

技术解析

  • 删除向量——行级操作的性能跃迁：传统Iceberg v2的行级删除需要通过position delete或equality delete实现，两者都需要重写数据文件或在读取时合并多个删除文件。删除向量将删除标记存储在独立文件中，读取时与基础数据文件Merge，避免数据重写。Geodis首席架构师Delio Amato评价：“Iceberg有了Deletion Vectors后，我们可以在Unity Catalog中集中管理Iceberg数据资产，同时使用想要的引擎并保持最佳性能。“删除向量在托管Delta表（通过UniForm启用delta.enableIcebergCompatV3）和托管Iceberg表（设置iceberg.enableDeletionVectors）上都可启用，默认在新v3表上开启。
  • 行追踪——行级并发：每行分配唯一ID，跨快照追踪行的变更历史。结合删除向量，Databricks实现了行级并发（row-level concurrency）——在行级检测写冲突，无需设计复杂的数据布局或调整工作负载来保证并发性。这是开放表格式上的首个行级并发实现。
  • VARIANT数据类型——半结构化数据的统一处理：日志、事件、应用数据常以JSON格式摄入。VARIANT允许将原始数据直接存储在lakehouse表中，支持摄入函数（JSON/CSV/XML），并通过shredding将公共字段提取为独立列获得类列式查询性能。VARIANT在Delta和Iceberg表上都可使用，不同引擎的团队无需数据复制即可查询同一VARIANT列。Panther首席架构师Russell Leighton评价：“Unity Catalog和Iceberg v3通过VARIANT让我们能利用半结构化数据的力量，实现互操作和成本高效的PB级日志摄入。”
  • Unity Catalog五大差异化能力：①开放API与凭证分发——任何兼容Iceberg REST Catalog API格式的引擎或工具通过标准化接口安全接入，无需复杂密钥管理；②目录联邦——企业此前使用的任何外部目录（AWS Glue/Hive Metastore/Snowflake Horizon等）可在统一视图中注册、查看和管理；③跨引擎ABAC——Spark/Trino/Flink等不同计算引擎在同一份数据上执行统一的属性级权限策略；④零拷贝安全共享——基于DeltaSharing开放协议，以零拷贝方式将实时数据安全共享给外部合作方，覆盖由外部系统管理的表（公开预览）；⑤AI驱动性能优化——Managed模式下预测性优化和Liquid Clustering自动维护查询性能，v3格式原生支持删除向量/行追踪/VARIANT。
  • 从格式选择到目录选择：Iceberg v3的核心意义不是”Iceberg变强了”，而是格式层面的功能差距被弥合——此前Delta Lake在行级操作（CDF+Deletion Vectors）和半结构化处理（VARIANT）上的优势让企业在选择格式时面临”功能vs开放”的取舍。v3让Iceberg在功能上与Delta对等，格式不再是选择的障碍，真正的差异化转移到目录层：谁能提供更开放的API、更广泛的引擎兼容、更完善的治理、更高效的共享。

行业影响

Databricks Iceberg v3 GA的深层意义不是”又一种格式支持了新特性”，而是开放湖仓的竞争焦点从表格式层正式转向目录/治理层。此前的湖仓竞争是”Delta vs Iceberg vs Hudi”——三种格式各有优劣，企业的选择本质上是功能取舍。v3让Iceberg在删除向量、行追踪、VARIANT三项核心能力上与Delta对等，格式层的功能差距被弥合。

当格式不再是差异化因素时，竞争自然转移到目录层——谁能更好地管理、治理和共享这些格式开放的数据。Unity Catalog五大差异化能力的设计恰好回应了这个问题：开放API解决”谁能接入”的问题（引擎兼容性），目录联邦解决”谁的数据”的问题（多目录统一视图），跨引擎ABAC解决”谁能访问”的问题（治理一致性），零拷贝共享解决”谁能共享”的问题（跨组织数据流通），AI优化解决”谁更省心”的问题（自动化运维）。

值得注意的是，Snowflake也在5月初将Iceberg v3 GA推向Horizon Catalog——删除向量、新数据类型（geography/geometry/nanosecond timestamp/variant）、默认值均已支持。两大湖仓平台几乎同时将Iceberg v3推至GA，标志着Iceberg v3已从”社区规范”变为”行业生产标准”——这与Vol.7报道的Apache Iceberg 1.11.0发布（格式层实现）形成完整闭环：规范制定→引擎实现→平台GA→生产采用。

相关链接

AWS下一代OpenSearch Serverless：搜索基础设施为AI代理从零重建

事件概述

5月28日，AWS发布下一代Amazon OpenSearch Serverless——一款完全托管的搜索与向量数据库，专为构建AI代理应用而设计。AWS OpenSearch总经理Tia White透露，约97%的代码由托管服务工程师从零重写，原有架构在AI代理的爆发式访问模式下已无法胜任。新一代的核心架构变更是存储与计算完全解耦：计算资源可缩至零（空闲时$0成本），需要时秒级拉起，自动扩缩速度比前代提升20倍，相比为峰值容量预留的OpenSearch Service集群节省高达60%成本。原生集成Vercel和Kiro等AI开发平台，OpenSearch Agent Skills让开发者在Claude Code/Cursor等工具中直接构建搜索后端。TechCrunch在同日发表评论文章《互联网正在为机器重建》，指出Cloudflare数据显示过去六个月机器人流量占HTTP总流量的31%，Cloudflare预测2027年上半年非人类流量将超越人类流量。Autodesk、Freshworks和Sumo Logic成为首批公开客户。

技术解析

  • 97%代码重写——为什么不能在原架构上修补：原版OpenSearch Serverless的存储与计算是耦合的——即使没有请求，也必须保持至少一个实例运行，因为存储依赖计算节点。这意味着客户始终在为空闲计算付费。AWS OpenSearch总经理Tia White直言：“此前即使在我们的Serverless版本中，你也必须至少有一个实例在运行，因为存储和计算是耦合的。你无法以需要的速率自动拉起计算，所以总是有空闲计算预留——无论是否在使用。“97%重写的决定表明，存储计算耦合不是能通过增量修补解决的问题，而是需要架构层面的根本重构。
  • 存储计算解耦——Scale-to-Zero的技术基础：全新私有存储层让OpenSearch完全坐在独立存储上，计算资源可以毫无保留地缩至零。不活跃时不收费，需要时秒级重新拉起。White特别强调：“我们不想有冷启动问题，因为工作负载是爆发性的。“新存储层还提供压缩功能，进一步降低存储成本。
  • 20倍自动扩缩速度——被代理工作负载逼出来的：AI代理的流量模式是”突发+空闲”——几秒内启动多个子代理查询数百个数据库，随后完全消失。这种模式直接击溃了原架构的自动扩缩假设。即使流量骤降，新一代自动扩缩器也能在秒级释放容量，这也是节省60%成本的关键之一。
  • 从瑞士军刀到代理专用——产品定位的根本转向：White毫不避讳：“以前OpenSearch就是一把瑞士军刀，什么都想做的大杂烩。去年甚至试着转向SIEM，那条弯路没走通。“新一代把传统搜索和日志分析打包，但全部围绕代理工作负载重做。发布即支持搜索（SEARCH）和向量（VECTORSEARCH）两种集合类型，未来路线图包括agent记忆、日志分析强化和搜索负载专用推理模型。
  • 原生集成AI开发平台：Vercel控制台内可创建OpenSearch集合或连接已有集合，Kiro IDE通过Kiro Powers提供OpenSearch Launchpad加速搜索应用开发。OpenSearch Agent Skills为Claude Code/Cursor等Agent IDE提供内置OpenSearch智能——每个Skill封装领域知识、最佳实践和多步执行逻辑。
  • 按计算单位付费：索引、搜索、GPU加速均按OpenSearch Compute Units（OCUs）付费，存储按GB-month单独计费。CLI和SDK支持创建集合组（Collection Group）配置最小/最大索引和搜索容量。

行业影响

下一代OpenSearch Serverless的深层意义不是”OpenSearch变便宜了”，而是搜索基础设施首次为AI代理的流量模式从零重新设计。此前的搜索基础设施假设流量来自人类——相对稳定、可预测、有高峰低谷但不会在几秒内从零到数千QPS再回到零。AI代理的流量模式完全不同——一个代理任务触发时可能同时启动多个子代理，每个子代理并行查询数据库、检索文档、调用API，完成后立即释放资源。这种”抽搐式”流量模式让”为人类设计”的搜索基础设施要么过度配置（为峰值付费），要么响应迟缓（代理等不及扩缩容）。

TechCrunch的评价切中要害——“互联网正在为机器重建”。Cloudflare的数据量化了这一趋势：机器人流量已占HTTP总流量的31%，其中AI爬虫、搜索引擎和助手约占所有机器人请求的25%。当非人类流量在2027年上半年超越人类流量时，基础设施从”为人优化”到”为代理优化”不再是前瞻性布局，而是生存需要。

这与Databricks/ClickHouse/阿里云正在做的事情形成行业共振——Databricks让Unity Catalog支持代理治理（跨引擎ABAC/MCP接入），ClickHouse让分析数据库成为代理原生平台（Agents+MCP+Agentic Data Stack），阿里云让数据仓库成为Agent-Ready操作对象（Hologres CLI六层安全）。AWS的切入点不同：不是让数据平台适应代理，而是让搜索基础设施本身为代理的流量模式从零构建。

相关链接

LanceDB v0.30.0/v0.33.0稳定版：AI原生多模态湖仓从beta走向生产

事件概述

5月28日，LanceDB同步发布Node/Rust v0.30.0和Python v0.33.0稳定版——这是LanceDB自项目启动以来首个非beta稳定版本发布。此前从Vol.2（5月19日）至Vol.11（5月28日），本专栏多次追踪LanceDB版本发布但均因”仍为beta”而未详细报道，此次稳定版发布标志着LanceDB的AI原生多模态湖仓正式达到生产就绪。稳定版包含13项新功能、14项bug修复和1项破坏性变更（原生索引创建支持嵌套字段路径）。关键新功能包括命名空间管理（Connection级命名空间创建/连接/删除）、流式摄取（Scannable原语支持Table.add进度追踪）、非强制主键（unenforced primary key概念引入schema）、LSM写入规范（table级配置写入策略）、读一致性新鲜度头（remote table read freshness headers）等。LanceDB定位为”AI原生多模态湖仓”——单一表存储原始字节/特征/元数据/嵌入，支持向量/全文/混合搜索，水平扩展至100K QPS，声称在训练数据加载中达到70% MFU（Model FLOPS Utilization），Midjourney/Runway/Character.AI等AI公司已在生产环境使用。

技术解析

  • 从beta到稳定版——为什么这个里程碑重要：LanceDB此前所有版本都标记为beta（v0.30.0-beta.x, v0.33.0-beta.x），这意味着API可能有破坏性变更、功能可能不完整、生产部署有风险。稳定版发布意味着API接口承诺稳定性、功能经过充分测试、可以安全用于生产环境。对于企业用户而言，这是从”试用”到”采用”的分水岭。
  • 命名空间管理：Connection级命名空间操作——connectNamespace创建命名空间连接、createNamespace/dropNamespace管理命名空间生命周期。命名空间在多租户场景下提供数据隔离，也为LanceDB的企业级部署提供组织层抽象。此前LanceDB的连接模型是”一个数据库一个连接”，命名空间让一个连接下可以有多个逻辑隔离空间。
  • 流式摄取（Scannable原语）：Scannable原语支持流式数据摄入到LanceDB表中，Table.add新增进度追踪（progress callback）。这对AI训练场景尤为关键——训练数据集通常需要从多个源持续摄入，流式摄取避免了一次性加载大量数据的内存压力，进度追踪让长时间运行的摄入任务可监控。
  • 非强制主键（Unenforced Primary Key）：在schema中引入主键概念但不强制唯一性约束。这是务实的设计选择——AI训练数据集通常有重复行（不同版本的同一训练样本），传统数据库的严格主键约束会拒绝这些数据。非强制主键让应用可以选择何时强制唯一性，何时容忍重复。
  • LSM写入规范：支持为单个表配置LSM（Log-Structured Merge）写入策略。LanceDB底层使用Lance格式（基于列存的版本化数据格式），LSM写入规范让用户在写入模式和读取模式之间做trade-off——频繁写入用LSM模式减少写放大，批量写入用直接模式减少合并开销。
  • 嵌套字段路径原生索引：破坏性变更——原生索引创建现在支持嵌套字段路径（如struct_col.field）。此前创建索引只能引用顶层列，嵌套字段需要先展平。这个变更让LanceDB的数据模型更自然地支持半结构化数据——AI训练数据集的元数据常常是嵌套JSON结构。
  • 读一致性新鲜度头：远程表（LanceDB Cloud）查询时发送read freshness headers，确保客户端读到最新写入的数据。这在多客户端并发写入+读取的AI训练场景中至关重要——训练节点需要确保读到最新的特征数据。

行业影响

LanceDB稳定版的深层意义不是”又一个数据库发了正式版”，而是AI原生多模态湖仓从实验性项目走向生产级基础设施。LanceDB的定位与传统数据湖仓（Delta Lake/Iceberg/Hudi）有本质不同——传统湖仓假设数据是结构化表格，AI原生湖仓假设数据是”原始字节+嵌入+元数据”的多模态混合体。当训练数据集需要同时存储图像/视频原始字节、文本嵌入向量、结构化元数据标签，并在其上执行向量搜索+SQL过滤+特征工程时，传统湖仓需要拼凑对象存储+向量数据库+特征存储三个系统，LanceDB用一个表统一解决。

这与Vol.5报道的DuckDB Lance扩展形成互补——DuckDB让分析查询能读取Lance格式数据，LanceDB让AI训练工作负载原生运行在Lance格式上。两者共同指向一个趋势：Lance格式正在成为AI训练数据基础设施的统一数据格式——就像Parquet成为分析数据的统一格式一样。

Midjourney/Runway/Character.AI等AI公司在生产环境使用LanceDB也验证了一个判断：AI训练数据管理的核心痛点不是”存储不够大”或”查询不够快”，而是”数据散落在五个互不通信的系统中”——原始数据在对象存储、嵌入在向量数据库、元数据在关系数据库、特征在特征存储、版本在Git。LanceDB用”一张表存所有”的激进设计试图解决这个碎片化问题。

相关链接

编者评

第十二期的三条动态，与前十一期的主线形成了又一个维度的跃迁。Vol.1-2确立了”AI原生基础设施”和”基础设施AI代理化”两条主线，Vol.3-4追踪到AI代理趋势渗透到治理层和存储/芯片层，Vol.5看到横切面基础设施为AI代理重新定义角色，Vol.6见证了AI推理基础设施的精细化，Vol.7看到湖仓格式插件化和AI代理成为基础设施原生操作者，Vol.8看到AI基础设施的系统性构建和湖仓事务模型的架构性重构，Vol.9看到AI Agent记忆/安全/可观测性的基础设施化，Vol.10看到数据基础设施从”为人设计”走向”为代理设计”，Vol.11看到分析数据库从”被人查询”走向”被代理查询”。本期则看到了三个不同层面的”从X到Y”跃迁同时发生。

第一个跃迁是竞争维度的转移：从”功能对等”到”治理开放”。 Databricks Iceberg v3 GA让Iceberg在删除向量、行追踪、VARIANT三项核心能力上与Delta Lake对等——格式层的功能差距被弥合。当格式不再是选择障碍时，竞争自然转移到目录/治理层：Unity Catalog五大差异化能力（开放API/目录联邦/跨引擎ABAC/零拷贝共享/AI优化）回答的是”谁的目录更开放”而非”谁的格式更好”。这与Vol.7报道的Iceberg File Format API的”插件模型”vs”Iceberg统一目录”的架构选择一脉相承——当格式成为插件，目录成为平台，竞争自然从插件层上升到平台层。Snowflake与Databricks几乎同时将Iceberg v3推至GA也印证了这一点——两家在格式层已无差异，差异化都集中在Horizon Catalog vs Unity Catalog的治理能力上。

第二个跃迁是设计假设的根本变更：从”为人设计”到”为代理设计”。 AWS OpenSearch Serverless 97%代码重写不是技术债务清理，而是设计假设的根本变更——从”流量来自人类，相对稳定可预测”到”流量来自代理，爆发式且不可预测”。当Tia White说”以前OpenSearch是瑞士军刀”时，她承认的是：为人类设计的搜索基础设施在代理流量模式下不是”不够好”，而是”假设就错了”。TechCrunch的”互联网正在为机器重建”和Cloudflare的”2027年H1非人类流量超越人类”数据则将这个变更从技术决策提升为行业趋势——当机器流量超过人类流量时，为人类优化的基础设施不是”不够高效”，而是”设计在错误的前提下”。

第三个跃迁是技术成熟度的里程碑：从”技术预览”到”生产就绪”。 LanceDB从beta到稳定版是AI原生多模态湖仓从实验室走向生产环境的标志。Vol.2至Vol.11，本专栏持续追踪LanceDB每次版本发布但均因”仍为beta”而未深入报道——这个”持续观察但未采纳”的状态本身就是技术成熟度评估的缩影。当Midjourney/Runway/Character.AI已在生产环境使用LanceDB，当稳定版API承诺不再有破坏性变更，当命名空间/流式摄取/LSM写入规范等企业级特性随稳定版一同落地时，“AI原生多模态湖仓”从概念验证变为可部署的基础设施。

将十二期主线串联，一个完整的演进图景浮现：DataInfra正在经历三线并行的范式迁移。 第一线是竞争维度的上移——从存储格式（Vol.7 Iceberg File Format API）到表格式（Vol.7 Iceberg 1.11.0）到目录治理（Vol.12 Unity Catalog五大能力），数据基础设施的竞争焦点持续上移，每一层的功能对等都推动差异化转移到更高层。第二线是设计假设的重置——从为人设计（Vol.1-9）到为人+代理协同设计（Vol.10-11）到为代理从零设计（Vol.12 OpenSearch Serverless），基础设施的设计假设正在从”人类是主要用户”翻转为”代理是主要用户”。第三线是技术成熟度的阶梯——从概念验证到beta预览到生产GA，每个技术方向都在经历”Vol.1-2概念→Vol.5-8 beta→Vol.10-12 GA”的三年成熟周期。当格式不再是选择障碍（v3对等）、当代理成为主要用户（OpenSearch为代理重建）、当AI原生湖仓达到生产就绪（LanceDB稳定版）时，DataInfra的下一个竞争维度不再是”谁的功能更多”或”谁更快”，而是”谁的治理更开放”和”谁更适应代理流量模式”——这两个维度将定义2026年下半年乃至2027年的数据基础设施竞争格局。