datainfra前沿动态 · Vol.111

Lakebase Postgres 登陆 Google Cloud 正式 GA；BigQuery 跨云联邦查询扩到 AWS Glue 与 Snowflake Horizon 并整体 GA；AWS 给出 BigQuery 迁往 Iceberg 开放湖仓的完整路径；clickhousectl v0.5.0 把本地、云与 Postgres 收进一个 CLI

本期聚焦 11 月 2 日的三方同日动作：Databricks 把 Lakebase Postgres 带进 Google Cloud 并 GA，Google 把 BigQuery 的跨云联邦扩到四家目录并补上 Iceberg 变更历史，AWS 教用户把 BigQuery 工作负载整体迁往 S3 上的开放湖仓——开放之争的焦点从互操作升级为可移植；开源侧 clickhousectl v0.5.0 把本地、云与托管 Postgres 收进同一个命令面，并为 Agent 的泛化使用做了标准化。

DataInfra Lakebase PostgreSQL BigQuery Apache Iceberg AWS Databricks ClickHouse CLI 跨云 开放湖仓

11 月 2 日，三家云厂商在同一天把「跨系统边界」写进了产品：Databricks 的 Lakebase Postgres 在 Google Cloud 转正，事务数据库长到了另一朵云的地盘上；Google 把 BigQuery 的跨云联邦查询扩到 AWS Glue 与 Snowflake Horizon 目录并整体 GA，还给 Lakehouse 内的 Iceberg 托管表补上变更历史与连续查询；AWS 发文给出把 BigQuery 工作负载迁往 S3 上 Iceberg 开放湖仓的完整迁移指南，把「可搬走」做成了架构属性。开源侧，ClickHouse 的 clickhousectl v0.5.0 把本地、云与托管 Postgres 的管理收进一个 CLI，并明确为 Agent 的泛化使用做了命令面标准化。四条动作指向同一个词：portability（可移植性）——数据、引擎与控制面，都在从「锁在哪儿」变成「随时可以走」。

Lakebase Postgres 登陆 Google Cloud：LTAP 故事讲到第二朵云

事件概述

Databricks 宣布 Lakebase Postgres 在 Google Cloud 正式 GA。这是一个全托管、serverless 的 Postgres：计算随流量伸缩、闲置时缩到零，秒级创建生产数据的零拷贝分支，支持时间点恢复（PITR），带 pgvector 兼容的内建搜索引擎。发布重点不在单个功能，在位置——Lakebase 首次以 GA 产品进入 Google Cloud，Databricks 的 LTAP（Lake Transactional/Analytical Processing，湖上事务与分析处理）架构随之覆盖第二朵云。

从工程视角看，Lakebase 的核心主张是把事务数据和分析数据放到同一个存储基座上：计算与存储分离消除资源冲突，运营数据不再需要 ETL 管道搬进湖仓，Unity Catalog 对事务表与分析表施加同一套治理（访问控制、血缘、审计）。AI agent 实时读写数据的负载被当作这个统一的第一推动力——KaBuM! 把它选为 agent 默认记忆层，理由是会话式 AI 需要的低延迟读写。

技术解析

  • 可用性与网络：多可用区高可用端点带自动故障切换，SLA 99.99%；单可用区端点 99.9%。企业客户可用 Private Service Connect（Beta）把 VPC 内应用直连 Lakebase，数据库流量不走公网。
  • 搜索一体化：Lakebase Search 在 Postgres 内组合向量与全文检索，官方口径是吞吐为 pgvector 的 2 倍、成本低 4 倍——不需要第二个搜索系统，也没有同步管道。
  • 写入路径：direct writes 允许把湖仓里加工好的数据直接推进 Lakebase Postgres 而不拖慢应用，官方测试数据是 1TB 装载低于 5 分钟。
  • GA 区域与身份：asia-southeast1、europe-west3、us-central1、us-east4、us-west1 共 5 个区域。身份走 Databricks OAuth 或原生 Postgres 凭证，权限在 Unity Catalog 集中管理。

行业影响

Lakebase 的看点在它对「数据库厂商边界」的改写：一家以 Spark 起家的公司，先做了湖仓，再把 Postgres 作为一个 workload 类别收编进平台，如今把这棵树种到了 Google 的地里。对用户来说，评估对象从「选哪个数据库」变成「要不要把事务负载也交给数据平台」——换来的省心（无管道、统一治理）与付出的绑定（存储基座、治理模型都长在 Databricks 里）都摆在明面上。

Vol.109 报过 Snorkel AI 用 Lakebase 分支跑 100 个 PR 数据库的 CI/CD 实测（AWS 侧），本次 GA 让同一套能力对 GCP 客户可用。多区域、多云的铺开节奏是判断这条产品线是「战略级」还是「补位型」的观察指标——5 个首发区域、PSC 还在 Beta，说明仍处早期扩张期。

相关链接

BigQuery 跨云联邦 GA：从 Databricks 一家到四家目录，Iceberg 托管表补上变更历史

事件概述

Google 在 11 月 2 日的 BigQuery release notes 里把 Lakehouse 跨云数据访问整体转正：联邦目录支持的远端 provider 扩到 Databricks Unity Catalog（AWS/Azure/GCP）、AWS Glue Data Catalog（AWS）、Snowflake Horizon Catalog（AWS/Azure/GCP）与 Workday Data Lake（AWS/GCP）。BigQuery、Managed Service for Apache Spark 与自管 Spark 可以不迁数据、不建 ETL，直接查询远端目录里的 Iceberg 表；元数据同步与查询可走公网，也可走 Cross-Cloud Interconnect 私有链路，VPC Service Controls 服务边界照常生效。

同批 GA 的还有 BigQuery 对 Lakehouse 内 Iceberg 托管表的变更历史与连续查询：APPENDS 表值函数追踪指定时间范围内追加的行，连续查询可以直接读写 Iceberg 托管表。Lakehouse 缓存（跨云访问时把远端文件缓存到本区域以压 egress 成本）一并 GA，默认关闭、按目录或跨云连接开启。

技术解析

  • Vol.107 之后的增量：10 月 29 日 borderless Lakehouse 首发只打通 Databricks Unity Catalog 一条路，元数据刷新最快 5 分钟；本次 GA 把 provider 扩到四家，覆盖 AWS 与 Snowflake 的目录，并加上缓存层压跨云流量成本。对 Databricks Unity Catalog 还支持用户身份联邦，终端用户身份可在查询时透传，用于权限执行与审计。
  • 流读开放表：连续查询读写 Iceberg 托管表 + APPENDS TVF，意味着 BigQuery 的流式管道可以直接把开放表当源、当汇。此前这类「跟踪 Iceberg 变更」要靠引擎自己扫 manifest 或接 Kafka，现在进了 BigQuery 的函数面。
  • 配套小件：同日 GA 的还有 data agent 的性能/采纳/延迟/成本监控（接 Google Cloud Observability）与 AI.PARSE_DOCUMENT 文档结构化解析；SECURE_CONTEXT（视图按请求级上下文参数动态过滤行）进入 Preview；10 月 30 日 Arrow 格式查询结果进入 Preview，10 月 27 日 BigQuery Studio Git 仓库 GA。

行业影响

把 11 月 2 日的三条新闻并排放着看最有意思：Google 让 BigQuery 能直查 Databricks、Snowflake、AWS Glue 的目录；Databricks 把 Lakebase 种进 Google Cloud；AWS 教用户把 BigQuery 数据搬去 S3 上的 Iceberg。三家对「开放」的用法各不相同——Google 用它把自己变成别人的查询引擎，Databricks 用它把自己的数据库种进别人的云，AWS 用它证明数据可以离开任何一家。Iceberg REST Catalog 规范在这里扮演通用插座：谁的目录实现了它，谁就既是数据的生产者，也是被查询者。

对使用者，联邦查询省掉的是复制管道，换来的是刷新延迟与跨云 egress——Google 用缓存缓解后者、用分钟级元数据刷新界定前者，这些上界在采用前都该进容量规划。

相关链接

AWS 的 BigQuery 迁移指南：把「可搬走」做成架构属性

事件概述

AWS Big Data Blog 发布长文《Migrate Google BigQuery to an open lakehouse on AWS with Apache Iceberg》，给出从 BigQuery 迁往 AWS 开放湖仓的完整路径：工作负载评估、schema 与查询转换、数据搬运策略、迁移后优化。文章把动机讲得直白：生成式 AI、多引擎分析与跨团队共享成为常态后，「存储格式、目录、查询引擎焊死在一家运行时里」的代价在上升。

文章对「开放」做了一个值得记住的二分：interoperability（互操作性，多引擎够得着同一份数据）与 portability（可移植性，数据、引擎、模型可以整体换地方而不重构）。前者正在变成 table stakes——连专有仓库都在联邦查询开放格式、就地查询数据；后者才是开放湖仓要给的持久属性。

技术解析

  • 搬运路径：初始批量迁移用 BigQuery EXPORT DATA 导出 Parquet 到 GCS，再由 AWS DataSync 搬进 S3；SaaS 与运营源（Google Analytics、Salesforce、SAP、ServiceNow、HubSpot）走 Zero-ETL 直落湖仓；CDC 用 MSK Connect 上的 Debezium 连接器持续同步；实时源接 Kinesis Data Streams 或 MSK。
  • 存储与目录：数据以 Iceberg 表格式落在 S3，可选 S3 Tables 换取全自动的 compaction、快照管理与优化；AWS Glue Data Catalog 暴露实现 Iceberg REST Catalog 开放规范的端点；Lake Formation 提供库/表/列/行/单元格五级细粒度权限，对 Athena、Redshift、EMR、SageMaker AI 一致生效。
  • 分层与消费：medallion 分层——bronze 落原始 Iceberg 表，silver 由 Glue/EMR Spark 加工为可信层，gold 由 Redshift Serverless 服务 BI（Redshift 本身是能管理 Iceberg 表全生命周期的引擎）；消费侧 BI 工具直连，AI agent 侧点名支持 MCP 客户端、Kiro、Claude 与 Bedrock AgentCore。

行业影响

迁移指南是厂商竞争里的低成本武器：不需要发新产品，只需要证明「离开别人是可行的」。这篇文章的出现本身就是信号——AWS 把 BigQuery 客户当成明确的争夺对象，路径图细到查询转换与迁移后优化。与 Google 同日把 BigQuery 做成「查询别人的引擎」对照看：防守方在把出口做宽（联邦、缓存、身份透传），进攻方在把门修得更好走（开放格式、五级治理、迁移手册）。

真正该按自己的账本算的是切换成本：查询方言转换、双云并存的验证期费用、迁移窗口里的双份存储。指南给了路径，路径上的每一步都要人天。

相关链接

clickhousectl v0.5.0：一个 CLI 罩住本地、云与托管 Postgres，命令面为 Agent 标准化

事件概述

ClickHouse 发布 clickhousectl（chctl）v0.5.0。这个 CLI 的覆盖面在持续扩大：本地装版本、起项目级 ClickHouse 服务、跑 Docker 支撑的 Postgres；云端管 ClickHouse、Managed Postgres、ClickPipes、ClickStack、备份、密钥与成员的完整生命周期。v0.5.0 的三个重点：UDF 从本地到云的端到端工作流、Managed Postgres 的可观测性与网络管理、一次明确面向自动化的命令面标准化——官方原话是「这对人重要，对能从一个命令泛化到下一个命令的 Agent 更重要」。

技术解析

  • UDF 端到端：local udf init 脚手架（udf.json 定义 + Python 脚本或原生 amd64/arm64 二进制）→ local udf deploy 装进本地服务器用纯 SQL 验证 → cloud udf deploy 打包目录、创建 UDF 与版本、挂到服务并唤醒，一条命令完成上线。
  • Postgres 运维进终端：postgres metrics 输出紧凑指标序列，postgres logs 按严重度或正文过滤日志，postgres slow-queries 列出规范化查询模式（按总时长/均值/p95/p99、CPU、行数、WAL 排序）；cloud postgres query 用 OAuth 登录走 HTTP 跑只读 SQL，不需要 psql、网络路径与密码。配置写入新增 29 个 Postgres 参数（autovacuum 阈值、checkpoint_timeout、wal_buffers、io_method 等），枚举值先校验再发送。网络侧支持 --ip-allow 规则与 --block-public-access；restore 会显式复制源服务的 IP 规则，否则恢复出的服务对全网开放。
  • ClickPipes 与查询面：新增 clickpipe update（含 CDC 暂停→更新→恢复流）；BigQuery CDC 从只支持快照升级为 --replication-mode cdc，可选 query_based（按表指定水位列）或 events_based（按表指定 eventsFunction），同步按间隔或 cron 调度；saved queries 转 GA，query-api-endpoint 把保存的查询暴露为 HTTP 端点直接服务仪表盘与应用。每个云命令的帮助里列出所需的 API-key 权限——对要自主判断能力边界的 Agent，这是机器可读的能力声明。
  • 破坏性变更：--name 在 update 语义里改为选择目标、改名走 --new-name；org 命令改用 --org-id/--org-name；ClickPipe schema-discover 参数顺序调整；GCP Postgres 机型名对齐 API（-lssd- 后缀）；旧形式一律以 usage error（exit 2）显式失败，不做静默重解释。

行业影响

CLI 这一层正在重新变得重要——不是给人敲的，是给 Agent 敲的。一致的子命令结构、JSON 错误、--file 输入、帮助里的权限清单，每一项都在降低「让模型操作系统」的摩擦。clickhousectl 把 ClickHouse、托管 Postgres、可观测性栈与数据管道收进同一个控制面，配合 BigQuery CDC 这样的入口，勾勒的是「一个终端工具 + 一堆托管服务」的极简数据栈形态。

代价是绑定的另一面：控制面越统一，换引擎时要重写的自动化就越多。对已在 ClickHouse 生态里的团队，这是运营效率；对在选型的团队，这是又一个要计入的切换成本。

相关链接

编者评

把这期四条放回一个月的尺度看，11 月 2 日像是开放格式之争的一个分水岭时刻：防守方 Google 把 BigQuery 变成查询对手数据的引擎，并补齐缓存与身份透传；进攻方 AWS 用迁移手册宣示数据可以整体离场；Databricks 两头下注——既让 Lakebase 落地 Google Cloud，又让自己的目录被 BigQuery 联邦查询。interoperability 与 portability 的二分值得收进工具箱：前者各家都在给，后者才是真正的竞争差异。开源侧同日动态：Lance v15.0.0-beta.8 把小删除向量直接存进 manifest、复用 RaBitQ LUT 与 IVF 查询状态，v14 线出 v14.0.3-rc.1 修 blob 旧页解码；LanceDB 版本跳到 v0.42.0-beta.0；Apache Pinot 1.6.0 已于 10 月 29 日转 GA（SQL DDL 与 IVF 后端 Vol.93 报过 RC0，GA 新增 Lucene 回滚恢复）；Snowflake CLI v3.32.1、MatrixOne v4.2.7（11-01）、Dagster 1.13.28 为常规迭代。中文源本期无可用条目：阿里云博客首页本轮既抓不到日期文本也抓不到文章 slug（上一期尚可用 slug 清单定位），火山引擎文档站日期停在 10 月 26 日，观察窗口顺延。