datainfra前沿动态 · Vol.47

Databricks 收购 Electric 为每个 AI Agent 配备 WASM Postgres 数据库；Google Looker 语义层桥接 Gemini Enterprise 终结 NL2SQL 幻觉；AWS OpenSearch GPU 加速实现十亿级向量索引小时级构建

本期聚焦三条 DataInfra 动态：Databricks 宣布收购 Electric，将 PGlite（WASM Postgres，周下载 1300 万次）与实时同步引擎纳入 Lakebase 体系，实现'每个 AI Agent 一个 Postgres 数据库'——平均数据库存续时间不足 10 秒；Google Cloud 将 Looker 语义层通过 A2A 协议原生集成 Gemini Enterprise，用版本控制的业务逻辑替代 NL2SQL 猜测，终结 AI 查询结构化数据的幻觉问题；AWS OpenSearch Service 推出 GPU 加速向量索引构建，基于 NVIDIA cuVS 的 CAGRA 算法将十亿级 1024 维向量索引构建从'数天至数周'压缩至 274 分钟。

DataInfra Databricks Electric PGlite WASM Postgres Neon Lakebase AI Agent Sync Engine 实时同步 Google Cloud Looker Gemini Enterprise Semantic Layer A2A NL2SQL Agent-to-Agent AWS OpenSearch GPU Vector Index CAGRA HNSW NVIDIA cuVS 十亿级向量

本期追踪到三条 DataInfra 动态，从数据库架构哲学、语义层治理到向量索引加速，共同指向同一个正在加速的趋势：AI Agent 正在重塑数据基础设施的每一个层次——从最底层的存储引擎到最上层的语义治理面，没有一层可以按传统应用的模式继续运转。2026 年 8 月 11 日，Databricks 宣布收购 Electric——这家背后有 PGlite（WASM Postgres，周下载从 100 万飙升至 1300 万）和实时同步引擎的初创公司——将 Postgres 从 Lakehouse 一直推到 Agent 沙箱的边缘端：AI Agent 在沙箱中运行一个完整的 Postgres 数据库，存续平均不到 10 秒，完成后要么丢弃要么同步回 Lakebase。同日，Google Cloud 将 Looker 语义层通过 A2A 协议原生集成到 Gemini Enterprise，用版本控制的业务逻辑替代 NL2SQL 的”猜测式查询”，从根本上终结 AI 查询企业数据时”同样的问题、不同的答案”的幻觉困境。AWS 也在同日发布 OpenSearch Service 的 GPU 加速向量索引构建，基于 NVIDIA cuVS 的 CAGRA 算法，将十亿级 1024 维向量索引构建时间从数天/周压缩至 274 分钟，且通过 CAGRA→HNSW 转换实现 GPU 构建、CPU 搜索的解耦架构。三条动态从数据库存续模式的根本重构、语义治理的 Agent 化、到向量基础设施的 GPU 化，分别触及了 DataInfra 在 Agentic AI 时代必须回答的三个底层问题：数据库的最小生存单位是什么？语义的权威来源在哪里？索引的速度能否跟上模型的生成速度？

Databricks 收购 Electric：WASM Postgres 进入 AI Agent 沙箱，“10 秒数据库”成为 Agentic 应用新常态

事件概述

2026 年 8 月 11 日，Databricks 联合创始人 Reynold Xin、Neon 联合创始人 Nikita Shamgunov 与 Stas Kelvich 等联名宣布收购 Electric——这家由 James Arthur 和 Valter Balegas 创立的公司，其核心资产是 PGlite（一个可在浏览器、Node.js 进程或 Agent 沙箱中运行的完整 WASM Postgres 数据库）和 Electric Sync Engine（实时同步引擎）。Electric 团队将并入 Databricks 去年以约 10 亿美元收购的 Neon（现已更名 Lakebase）。

这次收购的核心叙事与”Agent 不是传统应用”这一洞察直接相关。传统应用有一个已知的形态：查询是预先编写的、数据访问模式是可预测的、运行位置是架构师选定的——一个托管 Postgres 数据库就服务得好好的。但 AI Agent 完全不同：它们在运行时决定需要什么数据（内部循环每秒更新数次上下文）、在沙箱化的隔离环境中运行（网络连接不可靠）、以及在群体中协作（需要共享的、最新的世界视图以避免重复工作或冲突决策）。

Databricks 披露了一个揭示性的数据：在 Lakebase 上，Agent 创建的数据库数量已是人类用户的 4 倍，平均每个项目拥有约 10 个数据库分支，部分项目运行超过 500 次分支迭代。更重要的是——某些类型应用的数据库计算平均存续时间不足 10 秒。Agent 像分支代码一样分支数据库：在沙箱中实例化 PGlite、构建并测试、然后将结果同步回 Lakebase 或直接丢弃。

技术解析

  • PGlite：从 Neon 实验到 1300 万周下载的 WASM Postgres：PGlite 的技术血统值得关注——它最初是 Neon 联合创始人 Stas Kelvich 的一个实验：将 Postgres 编译到 WebAssembly 以验证其能否在客户端运行。Electric 接手后将其转化为生产级项目，周下载量在 12 个月内从 100 万飙升至 1300 万。PGlite 支持动态扩展加载（包括 pgvector——最主流的 Postgres 向量扩展），可在 Agent 沙箱中提供完整的 SQL 能力和向量搜索。Databricks 的公告将这次收购描述为”重新统一了一个想法的两个部分”——Neon 的 WASM Postgres 种子和 Electric 的生产化果实。

  • Electric Sync Engine：从 Figma/Google Docs 模式到 Agent 群体协作：如果说 PGlite 解决了”每个 Agent 的本地数据库”问题，那么 Sync Engine 解决的是”Agent 群体如何共享状态”的问题。Sync Engine 维持一个中央 Postgres 数据库（在 Databricks 语境中是 Lakebase），然后将数据近乎实时地同步到浏览器标签、移动应用或 Agent 沙箱。这正是 Figma、Google Docs、Notion 等协作应用背后的”多人模式”架构——应用到 Postgres 和 Agent 场景中。Neon 团队在公告中指出：“冲突解决、部分复制和重连逻辑等复杂问题使得从零构建实时同步极其困难”——这正是 Databricks 选择收购而非自建的原因。

  • Lakebase 的分支模型与 PGlite 的沙箱执行的互补闭环：这一组合的技术逻辑非常清晰。Lakebase（原 Neon）已经实现了存储计算分离——数据以 Postgres page 格式存储在廉价的对象存储上，创建分支是廉价的 Copy-on-Write 元数据操作。编码 Agent 在沙箱中启动 PGlite、运行测试、产生结果，然后将有意义的结果同步回 Lakebase 分支，或者丢弃整个沙箱状态。这种”用后即焚”的数据生命周期与传统 OLTP 数据库的设计假设截然相反——传统数据库设计时假设数据库是堆栈中最持久的组件。Neon 团队的判断很直接：“当编码 Agent 将创作成本降为零，应用数量会爆炸式增长，而且大多数是小型应用。如果每个应用都需要固定的最小计算量，就不可能迎来丰裕时代。”

  • Databricks 的数据库收购版图：从 Neon（Lakebase Postgres，约 10 亿美元）到 Electric（PGlite + Sync），再到 Mooncake（事务处理），Databricks 构建了一个从边缘到湖仓的完整 Postgres 光谱：边缘侧用 PGlite 在每个 Agent 内部运行轻量级数据库，同步层用 Electric Sync 保持状态一致，持久层用 Lakebase 提供生产级 Postgres 并存储在廉价对象存储上。Electric Cloud 托管服务将关停，但所有开源项目（Sync Engine、PGlite、Durable Streams、TanStack DB）将继续保持开源。

行业影响

这次收购标志着数据基础设施哲学的根本性转变——从”数据库是系统中最持久的组件”到”数据库可以是只活 10 秒的临时沙箱”。这场转变由 Agent 驱动：当数以万计的 Agent 同时工作、每个都需要隔离的数据环境、其中绝大多数结果最终被丢弃时，传统 RDS/托管 Postgres 的经济模型在根本上不再成立。数据库的原子单位从”实例”缩小为”分支”甚至”沙箱会话”，计费模型必须相应地从按月/按小时演进为按秒/按次。

更深一层看，Databricks 正在做一件与 Snowflake、Google BigQuery 截然不同的战略选择：不是让数据平台通过语义层或 MCP Server 去”服务”Agent，而是直接让数据库嵌入 Agent 内部。这是一种”数据库 as a library”而非”database as a service”的思路——PGlite 是一个 npm/pip 包，不是一个连接字符串。当 Agent 的数据库调用从”跨网络 RPC”变为”同进程函数调用”，延迟从毫秒级降为微秒级，Agent 内部循环（Decision → Tool Call → Verification → Repeat）的吞吐量将出现数量级提升。

但同步挑战不容低估：Figma 的多人协作架构经过多年打磨才成熟，Agent 群体的状态同步——包含冲突解决、事务边界、因果关系排序——在一个 Agent 同时操作数十个数据库分支的场景中，复杂性将呈指数级增长。Databricks 在公告中并未披露 Sync Engine 与 Lakebase 的具体集成时间表，但 Electric 创始人承诺”一切已开源的保持开源”，这至少为社区提供了观测和参与的窗口。

相关链接

Google Looker 语义层通过 A2A 协议原生集成 Gemini Enterprise：从”猜测式 NL2SQL”到”确定性企业查询”

事件概述

2026 年 8 月 12 日（今天），Google Cloud 的 Tarunima Tripathi 发布公告，宣布 Looker 的治理语义层正式通过 Agent-to-Agent (A2A) 协议原生集成到 Gemini Enterprise。这一集成使 Looker 分析师和管理员可以直接将对话式分析 Agent 发布到 Gemini Enterprise 环境中，让所有 Gemini Enterprise 用户都能用自然语言查询结构化和非结构化数据——但关键区别在于：查询不再是模型”猜测”SQL，而是由 Looker 语义层基于版本控制的业务逻辑生成确定性的 SQL。

公告明确指出，标准 NL2SQL（自然语言转 SQL）模型在面对企业数据仓库时有一个根本缺陷——它们必须”猜测”哪些表需要 JOIN、哪些过滤器需要应用、哪些时间戳值得信任。结果是：不同的人问同一个问题，得到完全不同的答案。对于”Revenue”（收入）这样一个看似简单的指标，标准 NL2SQL 可能用 gross_revenue、net_revenue、recognized_revenue 中的任意一个——而 Looker 语义层确保每次查询都使用经业务团队审批的唯一定义。

技术解析

  • A2A 协议实现零风险透传架构：当 Gemini Enterprise 用户发出自然语言查询时，请求通过 A2A 协议路由到 Looker Agent。Looker 的语义层基于版本控制的业务逻辑（LookML）生成确定性的 SQL，直接在底层数据源（BigQuery、AlloyDB、Spanner 等）上执行。关键安全设计：Gemini Enterprise 不会摄入、复制或存储底层数据库记录——所有查询都是实时的透传查询。用户需要通过一次性 OAuth 授权将其 Gemini 会话绑定到 Looker 凭据，在查询过程中严格执行 Looker 已有的行级和列级访问控制。如果用户在 Looker 中没有查看特定区域薪资或财务行的权限，Looker Agent 会在 Gemini 环境中主动限制该数据——即使在 Agent Gallery 中发布的公开 Agent 也不会绕过已建立的安全控制。

  • 跨 Agent 互操作性与富交互可视化：Looker Agent 在 Gemini Enterprise 中不仅提供文本回答，还提供原生的交互式数据图表——用户询问月度销售趋势或区域分布时，Agent 直接在对话界面中呈现可交互的可视化图表，而非纯文本解释。更重要的是，通过 A2A 协议，Looker Agent 可以与 Google 第一方 Agent（如 Deep Research Agent）或外部第三方 Agent 安全地共享结构化的治理洞察，实现复杂的多 Agent 编排——例如一个企业运营 Agent 从 Looker Agent 拉取数据，再喂入一个独立的生产力或供应链工作流。

  • 与 Databricks+Electric 思路的对照：Google 这条路径与 Databricks 构成了一种有趣的镜像关系。Databricks 的选择是”让数据库进入 Agent”——PGlite 将完整的 Postgres 塞进沙箱，数据物理上靠近 Agent 以减少延迟。Google 的选择是”让语义层桥接 Agent”——Looker 将业务定义注入 Gemini Enterprise，数据虽然物理上远离 Agent，但语义上完全对齐。两条路径解答的是同一个核心问题的不同维度：当 AI Agent 查询企业数据时，“正确性”的来源应该是什么？ Databricks 的回答是”数据的物理位置”（数据越近、延迟越低、Agent 跑得越快），Google 的回答是”语义的权威定义”（LookML 作为唯一的真相来源）。在理想状态下，两者并非互斥——Agent 可能需要同时具备本地数据缓存（PGlite 模式）和企业语义锚点（Looker 模式）。

行业影响

这条公告标志着语义层正在经历一个角色升维——从”人类分析师用来统一指标定义的工具”变为”AI Agent 用来建立信任的治理基础设施”。传统语义层解决的问题是”如何让所有人类分析师对’收入’有相同定义”；新一代语义层解决的问题是”如何让 AI Agent 在零人类监督的情况下对企业数据做出可信决策”。这是一个完全不同的安全要求级别。

此外，A2A 协议在 Looker-Gemini 集成中的实战应用值得关注。Google 在 2026 年 6 月推出 A2A 协议后，这是首次在数据基础设施领域展示其如何实现跨 Agent 的治理查询编排。如果 A2A 能够在 Looker Agent、Deep Research Agent 和第三方供应链 Agent 之间安全地传递结构化洞察，那么 Agentic Analytics 的闭环将从”问答”升级为”问答 → 分析 → 行动”。

但也需要指出：Looker 的语义层虽然解决了 NL2SQL 的确定性问题和访问控制问题，但它要求企业在 LookML 中预先定义所有业务指标和关系——这本身就是一笔巨大的治理投资。在 Agent 需要探索全新数据组合和临时性业务问题的场景中，Looker 的预定义模型可能反而限制灵活性。公告似乎意识到了这一点，特别强调 Looker Agent 可以与非结构化数据查询（文档、PDF、邮件）“在同一界面中”协同工作——这或许暗示 Gemini Enterprise 内部会有一个智能路由层：预定义的 KPI 查询走 Looker 语义层，探索性的临时查询走 LLM 原生推理。

相关链接

AWS OpenSearch Service GPU 加速向量索引：从”数周”到 274 分钟，十亿级 1024 维向量索引构建进入小时时代

事件概述

2026 年 8 月 11 日，AWS 六位作者——Navneet Verma、Corey Nolet、Gowri Balasubramanian、Kshitiz Gupta、Rajeshwari Devaramani 和 Vamshi Vijay Nakkirtha——在 AWS Big Data Blog 上发布深度技术文章，详细介绍 Amazon OpenSearch Service 和 OpenSearch Serverless 的 GPU 加速向量索引 (k-NN) 构建功能。核心数据：在 24 个 r8g.4xlarge 数据节点加 10 个 GPU 工作节点的配置下，10 亿个 1024 维向量的索引构建仅需 274 分钟，Recall@100 和 Recall@1 均达到 0.93，P50 搜索延迟 26.47ms、P99 延迟 66.6ms。AWS 明确表示传统 CPU 构建在十亿级别可能需要”数天或数周”。

向量索引构建速度一直是向量数据库最痛苦的运维瓶颈——每当数据更新、模型升级或索引策略变更，都需要重建索引。在 GPU 加速之前，十亿级向量索引的完整重建时间长达数日，直接影响了企业向量搜索系统的敏捷性和可用性。

技术解析

  • 解耦 GPU 架构：GPU 构建、CPU 搜索、S3 作为中间存储：AWS 的设计亮点是 GPU 节点与数据节点的彻底解耦。工作流程如下：向量文档首先被摄取到 CPU 数据节点上的段中；当段的数据量达到阈值（默认 50MB），数据节点将原始向量上传到 S3 并向 GPU 工作节点提交构建请求；GPU 节点从 S3 加载向量、使用 NVIDIA cuVS 库的 CAGRA 算法构建图索引，然后将其转换为 HNSW 图；完成的 HNSW 索引被写回 S3，供 CPU 数据节点下载提供搜索服务。这种架构实现了按需付费的 GPU 使用（无空闲 GPU 基础设施成本），且支持自动扩缩容和自动实例选择。

  • CAGRA→HNSW 转换：GPU 构建质量 = CPU 构建质量：这是文章中最值得关注的技术细节。传统上，GPU 加速向量索引的最大挑战是：GPU 构建的索引格式（如 CAGRA 图）与 CPU 搜索的索引格式（如 HNSW 图）不完全兼容。AWS 的解决方案是将 CAGRA 图直接用作 HNSW 的底层（第 0 层），在搜索时不使用 HNSW 的上层结构，而是从随机节点集合开始沿最近邻链接进行贪婪搜索。AWS 明确声明这种转换没有质量折衷——此前基准测试已证实 GPU 构建的索引与 CPU 构建的 HNSW 索引达到相同的召回率。

  • 生产最佳实践：禁用刷新最大化并行度：AWS 提供了一系列关键运维建议。将 index.refresh_interval 设为 -1 在大批量摄取期间禁用刷新，防止产生大量小段从而触发大量小规模的 GPU 构建任务——让 GPU 在更大、更紧凑的段上一次性构建，极大提升吞吐量。使用 160 个批量客户端饱和 24 个数据节点的摄取管道。系统内置自动回退机制：如果 GPU 构建失败，自动回退到 CPU，确保数据始终能被索引。

  • 线性扩展验证：AWS 将此基准与之前的 10 亿个 128 维向量基准（35.5 分钟）做了对比——维度从 128 增至 1024（数据量增加 8 倍），构建时间从 35.5 分钟增至 274 分钟（约 7.7 倍），大致与数据量成线性比例。这种可预测的扩展行为对于容量规划至关重要。

行业影响

GPU 加速向量索引的意义不仅在于”更快”，更在于它从根本上改变了向量搜索系统的运维模式。当索引重建从”数天”变为”数小时”，以下场景从”不可能”变为”日常”：每日模型微调后全量重建索引（此前需要周末窗口）；A/B 测试不同的嵌入模型和索引参数（此前时间成本太高）；突发流量时的应急扩容重建（此前时效性根本达不到）。

从生态角度看，AWS 选择 NVIDIA cuVS + Faiss GPU 后端的技术栈而非自研方案，反映了向量索引基础设施正在朝标准化方向演进——cuVS 在 Nvidia 和 AWS 双巨头的推动下，正在成为 GPU 加速向量搜索的事实标准库。这也意味着，Google 的 ScaNN 和 Meta 的 FAISS CPU 路径在十亿级规模上将面临 GPU 路径的竞争压力。

但需要指出，274 分钟（约 4.5 小时）虽然远优于 CPU 的数天，但仍然不是一个真正的”实时”级别——对于高频更新的向量库（例如实时新闻嵌入），4.5 小时的索引延迟仍然太高。AWS 当前的设计主要面向批量重建场景，增量更新的实时索引优化可能是下一步的重点。

相关链接

编者评

本期三条动态看似分属三个不同领域——数据库收购、语义层集成和硬件加速——但它们在底层共享一条清晰的叙事弧线：DataInfra 正在从”服务人类”转向”服务 Agent”，而这一转向迫使基础设施在每个层次上都重新校准设计假设。

在存储层，Databricks 通过 Electric 告诉业界：Agent 需要的不再是”一个长期存活的数据库实例”，而是”成千上万个只活 10 秒的数据库沙箱”——数据库的原子单位从”实例”坍缩为”会话”，这将对定价模型、资源调度和高可用设计产生连锁影响。在语义层，Google 通过 Looker-Gemini 集成告诉业界：Agent 查询企业数据时不能靠 LLM “猜 SQL”——语义层必须从”分析师的生产力工具”升级为”Agent 的信任锚点”，这意味着语义建模的覆盖率、版本控制和安全审计将面临前所未有的严格标准。在索引层，AWS 通过 GPU 加速向量索引告诉业界：当 Agent 以秒为单位更新向量嵌入时，索引构建不能再以天为单位——274 分钟是一个重要里程碑，但距离真正的”实时重建”仍有距离。

过去一年，DataInfra 行业的叙事焦点经历了从”湖仓一体”到”AI 原生”再到”Agent 原生”的三次跃迁。本期 Databricks 的”10 秒数据库”和 Google 的”语义驱动的确定性查询”可以被视作”Agent 原生 DataInfra”的两个标志性时刻——不是让数据平台调用 LLM API（那是 2025 年的叙事），而是让数据平台的设计哲学从根本上为 Agent 的运作模式重构。这种重构的速度和深度，将直接决定谁能在 Agentic AI 时代的基础设施层占据卡位优势。