datainfra前沿动态 · Vol.92

Redshift 把 Iceberg 写冲突的判断粒度从表版本细化到文件；Cloud Storage 给对象挂上可在 BigQuery 查询的富化元数据；Lakeflow Designer 四个月补齐去重与质量算子；Google 把跨云 Iceberg 目录接到对话式查询后面

本期聚焦四条把「谁可以动同一份数据」这件事重新划边界的改动：写冲突按操作、分区、文件逐级判定后自动 rebase，对象元数据升级成可 SQL 查询的一层，非专业用户经 no-code 算子进入同一份湖仓数据，跨云目录联邦补齐部署路径与消费端。

DataInfra Amazon Redshift Apache Iceberg Google Cloud Storage Object Contexts BigQuery Databricks Lakeflow Designer Unity Catalog Borderless Lakehouse 并发控制 数据湖仓

本期四条动态来自三个厂商、四个层次，问的是同一个问题：一份数据要允许多少个使用者在同一个时刻动它。Amazon Redshift 的做法是把冲突判定从表版本下放到文件；Google Cloud 的做法是让对象存储自己把理解结果写成一层可 SQL 查询的元数据；Databricks 的做法是给非专业用户发一张 no-code 画布，让他们不必写 SQL 也能进到同一份湖仓数据里；Google Cloud 的另一篇则把 Databricks、Snowflake、AWS Glue 三个目录接到了一句自然语言问题后面。四条都不是性能数字的堆叠，而是在重新划定「谁有资格改、改到哪一层算冲突」的边界。

Redshift 把 Iceberg 写冲突的判断粒度从表版本细化到文件

事件概述

10 月 13 日，AWS Big Data Blog 发布了 Iceberg 写支持系列的第三篇之后的新一篇，主题是并发写冲突。此前两篇讲的是怎样建 Iceberg 表、怎样用 INSERT 写入，以及怎样用 DELETE、UPDATE、MERGE 做行级修改，两篇都默认你的写操作独占这张表。生产环境里这个前提几乎不成立：流式作业、定时管道和一次性变换经常在同一窗口写同一张表。

Apache Iceberg 用乐观并发控制（OCC）保证一致性。每个写入者基于表的当前版本准备变更，提交时以「没有其他写入者先推进版本」为条件原子地推进表版本。条件不成立，整个写入作废。这个检查的问题是粒度：条件挂在表版本上，而不是挂在各自触及的行或分区上。两个写入者改的是完全不相交的分区，或者各自只是追加新数据，冲突的烈度和两个重写同一批行时一样。

文章举了一个零售分析平台的例子：customer_orders 表上，流式管道每分钟落地几百次插入，夜间合规作业删除七年前的旧记录、跑约一小时。两者从不触及同一份数据，但在基础乐观并发下这无关紧要——只要流的某次插入在这个小时内的任意时刻提交，合规作业就输掉竞争，一小时的工作被丢弃，下一次重试还要重新扫描 TB 级数据再进入同一场竞争。

技术解析

  • 不用丢弃而用 rebase：提交输掉竞争时，Redshift 先问一个更精确的问题——先提交的那些写入是否真的改动了与本次相同的分区、文件或行。答案是否，就把已经准备好的写操作在表的最新版本上重放一次再提交，类似 git rebase。不重扫、不重跑、应用侧不用写重试循环。
  • 逐级判定，从最便宜的一层开始：第一层按操作判定，只要有一方是纯追加，任何写都能 rebase——这条规则覆盖了「任意组合中至少一方只追加」的全部情形。第二层在双方都删除了数据时比较各自触及的分区。第三层在同分区时比较各自改动的文件，同文件才真正报冲突。协议还给「同一文件内不同行」留了一层余量。
  • 正确性优先于并发：判定全程只用表元数据，不重扫数据、不重新做查询计划。无法证明两个写相互独立时系统不猜，直接放弃消解、让写入重试。不必要的重试只花一点时间，错误的消解会丢数据，系统刻意偏向安全一侧。
  • 与隔离级别的关系：判定在快照隔离下工作，Spark、EMR、Athena 等引擎通过表的隔离级别属性遵循同一套语义。表属性 write.*.isolation-level 设为 serializable 时，Redshift 保留更严格的契约，把每个冲突都抛出来而不消解。这个属性与 ALTER DATABASE … ISOLATION LEVEL 设的数据库隔离级别无关，后者管的是 Redshift 自身事务。
  • 结果矩阵里的一条硬边界：追加与任何写相遇都能消解；DELETE/UPDATE/MERGE 之间按分区或文件判定；ALTER 与任何写相遇都必须重跑，没有例外。
  • 门槛与观测：不需要挑 clustering key、不需要重新分区、没有开关要打开，Redshift patch 203 及以上自动生效。每次 Iceberg 提交尝试都记录在 stl_iceberg_commit 系统表里，含结果、尝试次数、本次 rebase 跨过了哪些并发操作、rebase 耗时。
  • 实测数字：一张注册在 Glue Data Catalog 的无分区 Iceberg 表，1 到 16 个独立会话各发自动提交的 INSERT、跑 60 秒。基线失败率几乎精确等于 (N−1)/N——2 个写入者 50%、4 个 75%、16 个 94%；16 个写入者时吞吐掉到单写入者的 0.17 倍。开启自动消解后同一负载吞吐约 2 倍，所有配置下没有一次提交被拒，16 个写入者的同一窗口多完成 12 倍的提交。
  • 车队数据：在这项能力之前，并发写冲突是 Redshift 上 Iceberg 写失败的最大单一原因，约占每周失败 Iceberg 写查询的五分之一。第一阶段（操作级判定）在 2026 年 9 月初完成全车队部署后，来自并发写的冲突错误降到接近零，而车队上的 Iceberg 写量翻了一倍以上。残留的一个尖峰来自并发 UPDATE 的作业，属于后续分区级与文件级判定要覆盖的冲突类别。

行业影响

这条改动的价值在于它把一段过去必须由应用侧承担的逻辑收进了引擎。此前规避并发冲突只有三条路，而且每条都有代价：把写入者串行化，等于放弃并发；把一张逻辑表拆成几张物理表，等于用干净的数据模型和跨表查询能力换并行写入；给每次写套一层应用侧重试循环，等于为从未真正冲突过的语句付重跑的钱。三条路的力气都花在绕开提交协议上，而不是花在数据上。

更深一层的影响是开放表格式上的「多写者」终于在托管引擎里落地成默认行为。Iceberg 的规范一直允许多个引擎写同一张表，实践中却因为冲突判定太粗，团队往往退回「一个写者 + 一堆读者」的格局。Redshift 把判定粒度下放到文件之后，流式追加与批处理删除共存不再需要架构上的绕路。这也给其他引擎立了一个参照：同样的元数据完全够做分区级与文件级判定，缺的只是愿不愿意在提交路径上多问一个问题。

相关链接

Cloud Storage 给对象挂上可在 BigQuery 查询的富化元数据

事件概述

10 月 13 日的 Google Cloud 发布说明里，Cloud Storage 一次进了三项预览能力。第一项是 object enrichments：给 bucket 配置之后，Cloud Storage 会对其中符合条件的图片和 PDF 应用 Google 的预训练机器学习模型，把结果作为 object contexts 附加到对象上。第二项是带 extended data 的 object contexts：Google 服务在自动化分析（例如机器学习标注）期间把这类 context 挂到对象上。第三项是 Storage Insights 数据集新增了 Object Contexts Catalog 视图 object_contexts_catalog_view，可以在 BigQuery 里对这些 context 做规模化分析。

三步合起来构成了一条此前不存在的路径：非结构化对象进 bucket，存储层自己产出关于对象内容的结构化描述，描述就住在对象上，然后不需要建任何管道就能在 BigQuery 里被 SQL 查到。过去要做这件事，得自己起一条处理链路——下载对象、调模型、把结果写回某张表——并且要自己维护对象与表之间的对齐关系。

技术解析

  • context 的结构：每个 context 条目由 key（最长 256 字节）、value（最长 256 字节的字符串）、只读时间戳（createTime 与 updateTime）以及可选的 extended data 组成。extended data 是一份结构化 JSON，上限 128 KiB，装的是机器学习标签、自动标注这类明细。
  • 命名空间划分：以 google: 开头的 key 保留给 Google 生成的 context，例如 google:annotation:face-detector-v1，用户既不能创建也不能更新。要移除这类 context，只能在 rewrite 操作里用 dropContextGroups 参数丢弃。
  • 读取分两级：标准 get 与 list 请求只返回 key、value 和时间戳；如果 context 带 extended data，返回里会多一个 extendedDataTypeUrl 字段，值为 type.googleapis.com/google.protobuf.Struct。要拿到完整的 extended data 载荷，得调用 viewFullContext 方法（预览）。
  • 生命周期跟随对象：copy、rewrite、compose、move、restore 操作会自动把 context 带到目标对象上。想阻止它跟过去，可以在 copy、rewrite、compose 时用 dropContextGroups 查询参数选择性丢弃。
  • 批量与权限：context 的增删改用 IAM 权限控制，保证有审计线索；跨十亿级对象的批量管理走 storage batch operations。
  • 三类用法：分类与分组（例如给含个人信息的对象打 data_classification: PII，让合规策略能识别）、工作流状态跟踪（例如 processing_status: awaiting_review 或 processed_by: analytics_pipeline，避免自定义处理服务重复扫同一批文件）、业务语义与血缘（例如卫星影像的 capture_angle、文档的 document_type）。
  • 分析侧的落点：BigQuery 侧通过 Storage Insights 数据集里的 object_contexts_catalog_view 视图查询 context 与 extended data（标签、人脸检测、边界框等）。同日发布说明还提到 AI.AGG 函数转正式发布，可用自然语言指令对非结构化输入做语义聚合，两条能力在消费端是互补的。

行业影响

对象存储长期扮演的是「字节的终点」：结构化元数据住在元数据服务里，内容理解的结果住在另一套系统里，两边靠管道对齐。object contexts 把这个结构倒过来——理解结果和对象放在一起，随对象一起复制、一起归档、一起被权限控制。对齐问题消失了，因为不再有两份东西需要对齐。

对数据工程来说，更实际的影响是筛选下移。列出对象时按 context 的 key 与 value 过滤，意味着下游作业的输入集合可以在存储层就收敛，不必先列出全部对象再逐个判断。加上批量操作能覆盖十亿级对象，这一层从「给少量对象打标签」变成了「给整个数据湖做一次分类」。值得留意的是 extended data 仍在预览，且 google: 前缀的 context 不可由用户写入——这决定了这层元数据目前是「读与查」为主，自定义写入的范围被限定在用户自己的 key 空间内。

相关链接

Lakeflow Designer：四个月把去重、质量校验与物化视图补进 no-code 画布

事件概述

10 月 13 日，Databricks 发布了 Lakeflow Designer 的 10 月更新汇总。Lakeflow Designer 是 6 月转为正式发布的、构建在 Databricks 内部的 no-code 数据准备工具，面向分析师、领域专家和不太写代码的业务用户，通过拖拽画布和自然语言来准备与探查数据。官方给出的数字是：正式发布以来已有超过 3000 家客户在使用，转向 Designer 的客户在无代码工具上的支出平均下降了 90%。

这一轮更新覆盖过去四个月，分四块：新增 no-code 算子、既有算子增强、输出选项扩展、画布与协作改进。方向上很明确——早期客户反馈的是「去重、清洗、质量校验这类常见任务缺少不需要写代码的做法」，这次的 Prepare、Unique、Guardrails 三个算子就是对着这三类反馈补的。

技术解析

  • 三个新算子：Prepare 负责清洗与标准化，在单个算子内完成大小写转换、类型转换、值替换、套用公式等；Unique 负责去重，可以跨全量数据集去重，也可以只对选定的一组列去重，并且能指定排序规则来决定保留哪一条（例如每个客户保留最近更新的那条）；Guardrails 把数据质量检查直接放进工作流，可检查缺失值、重复值、意外值等，并让用户选择失败时如何处置——放行通过的行、拦下整个输出、还是直接停止执行。
  • Join 的三路输出：Join 算子默认分别输出 matched、left unmatched、right unmatched 三路结果，可以直接拿来分支工作流、对意外值触发告警。它也支持在单个算子里连接两张以上的表。
  • Filter 与 Select 的能力扩展：Filter 算子现在对匹配与不匹配的行各有输出，一次过滤就能分出两条处理路径。Select 支持按数据类型、名称模式或公式动态选列，例如保留所有以 sales_ 开头的列——后续新增的同名模式列会自动被纳入，工作流不必因为输入 schema 变化而改。
  • 参数化的输入与输出：Source 与 Output 算子的配置支持参数，改值不必重新配置算子；参数可以按各自的调度覆盖，测试环境与生产环境可以共用一份画布。
  • 三类新输出：结果可以写成 Unity Catalog 中的物化视图，供 AI/BI 仪表盘或其他可视化数据准备文件复用，视图随可视化数据准备的运行自动刷新；可以按指定键 merge 进已有表，匹配的更新、新的插入，也可以直接追加到表尾；还可以把结果写成 CSV、Excel 或 JSON 文件到 Unity Catalog volumes，写 Excel 时能动态写入不同的 worksheet。
  • 大画布的可用性：画布改版后对比度更高、连接目标更大、未配置算子与缺失输入的提示更清楚，上千个算子的画布滚动与平移性能做了优化。新增可搜索的目录，选中即跳到画布上的位置并能展开 Generated code 段查看底层代码。版本历史改成在画布上直接高亮新增、删除、修改过的算子。协作侧加了实时光标。
  • 后续路线：Databricks Apps 集成（让作者把工作流以简单 app 界面分享给非技术用户，对方只配置输入、运行、看结果）、对算子全量输出的数据剖析、Custom Report 算子、以及与 Lakebridge 配合的原生迁移工具。

行业影响

这一轮更新的信号密度比功能清单本身更高。Guardrails 把质量检查做成画布上的一个算子，意味着数据质量从「管道外挂的一套规则」变成了「管道里的一个节点」，失败处置的三种选择（放行、拦下、停止）也把过去只能靠人拍板的决策变成了画布上可勾选的一项。物化视图作为输出选项同理——下游的仪表盘不必再依赖一层独立的增量刷新逻辑，刷新时机由画布的运行决定。

更值得注意的是定价与人群的组合：按用量计费、没有按用户的授权费，加上 no-code 画布，这让「谁可以做数据准备」的范围从写 SQL 的人扩到了懂业务的人。Databricks 给出的 90% 支出下降，对准的是此前那批自助式数据准备工具的替代。风险也在这里——画布上的每个算子背后仍然是生成的代码，版本历史高亮改了哪些算子、Generated code 段可展开，都是在为「非专业用户也能被审计」这件事补基础设施。

相关链接

Google 把三朵云的 Iceberg 目录接到一句对话式查询后面

事件概述

10 月 13 日，Google Cloud 发布了一篇操作走查：怎样把 Databricks Unity Catalog 联邦进 BigQuery（AWS Glue 与 Snowflake 的配置放在附录），怎样在三个外部目录上跑一条 join 查询，以及怎样用 BigQuery 的对话式分析用自然语言探查合并后的数据。目录联邦这个能力本身在 7 月底已随 borderless Lakehouse 进入预览，本专栏此前有过报道；这一篇补的是此前缺口最大的两块——部署路径，以及数据联邦之后的消费端。

文章先摆出了传统做法的账：定时抽取管道把远端数据集复制到中央仓库，带来同步滞后、重复的存储成本、波动的网络出口费用，上游 schema 一变管道就断，团队还要花几小时去对齐不同步的仪表盘。borderless Lakehouse 的替代方案是把 Google Cloud 的计算与生成式 AI 带到数据所在的地方，就地在 Databricks、Snowflake 和 AWS Glue 上查询。

技术解析

  • 元数据与存储访问分离：Lakehouse runtime catalog 按你定义的刷新周期，从远端目录同步 schema、快照指针和表定义。真正跑查询时，兼容引擎用远端平台签发的临时凭证，直接读远端对象存储（例如 Amazon S3）里的 Parquet 文件。
  • 计算不跨云：所有查询处理都在 Google Cloud 侧完成，用的是 BigQuery 或 Managed Service for Apache Spark。执行过程中不调用远端的 Databricks 集群、Snowflake 虚拟仓或 AWS 计算实例。
  • 一套连接模式覆盖三家：Databricks Unity Catalog、Snowflake Horizon Catalog、AWS Glue Data Catalog 都支持开放的 Iceberg REST catalog 规范，所以三家可以用一致的连接模式接入，不必为每个平台写一套适配。
  • 三步部署路径：先在 Google Cloud 里创建联邦目录，再查看它的配置、取回自动生成的 service account，最后在远端平台上给这个 service account 授权。认证被显式拆成这三步，而不是塞进一个配置项。
  • 消费端是自然语言：联邦之后可以在 BigQuery 里用对话式分析（conversational analytics）探索合并后的数据。文章给的例子是跨三个外部 catalog 跑一条 join，再用自然语言继续追问。
  • 配套能力的现状：Lakehouse runtime catalog 已正式发布并由 Spanner 支撑，官方给出的可用性是最高 99.99%，事务可串行化；它与 Knowledge Catalog、Cloud IAM 打通，用全文检索加向量检索提供表级搜索与 lineage。Etsy 迁移后的官方数据是管道查询加速 60%。

行业影响

跨云目录联邦过去最缺的不是能力声明，而是可复制的部署路径。三步走（建目录、取 service account、远端授权）看起来平淡，但它把「两边管理员要怎么握手」写成了固定流程，这类细节往往决定一个预览能力能不能真正进生产。元数据同步与存储访问分离也值得注意：同步周期由用户定义，意味着远端目录的变更不是实时可见的，联邦查询读到的是最近一次同步的快照指针加上直读的数据文件——这是一个需要在设计里显式说明的一致性边界。

更大的背景是三家云厂商在目录层达成的临时均衡。Databricks Unity Catalog、Snowflake Horizon、AWS Glue 都实现了 Iceberg REST catalog 规范，Google 用同一套规范做联邦接入，结果是任何一家都能在不搬数据的前提下被另一家查询。这层互操作目前靠的是规范本身而不是任何一家的开放姿态，谁先把规范之外的能力（视图、行级策略、凭证签发规则）做成事实标准，谁就在下一轮拿到定义权。

相关链接

编者评

把四条摆在一起看，会发现它们在推同一件事的不同端：让「同一份数据」的边界往外扩，同时把「谁可以动它、动到哪一层算冲突」的判断往系统内部收。Redshift 那条最直接——冲突判定从表版本下放到文件之后，并发写入者不再需要在架构上互相避让，代价是引擎要在提交路径上多问一层问题，并且在不确定的时候选择保守。Cloud Storage 那条扩的是元数据边界：内容理解的结果住在对象上，靠对象自身的生命周期来同步，不再需要一条管道去维持两份东西的对齐。Lakeflow Designer 扩的是人群边界，质量校验与失败处置被做成画布上的选项，代价是审计责任随之下移到非专业用户身上，所以版本历史与生成代码的可见性必须补上。跨云联邦扩的是组织边界，代价是一致性边界变成了需要显式声明的同步周期。

一个值得记下的共同手法：四条都不是在「更快地搬数据」，而是在「减少必须搬的东西」。冲突消解减少的是被丢弃后重跑的数据，object contexts 减少的是为了对齐而复制的元数据，no-code 画布减少的是为了做一次清洗而在人与系统之间往返的需求，跨云联邦减少的是整段抽取管道。数据基础设施这一年最稳定的一条主线，就是把「先移动工件、再获得结论」逐步替换成「在工件原地声明一次」。

本期中文源仍然没有可解析的更新条目：阿里云帮助中心的 Hologres 与 MaxCompute 产品动态页均返回 404 框架页，阿里云开发者社区大数据页与火山引擎文档页返回 200 但内容由脚本渲染、无可抽取的条目与日期。作为间接观察点，火山引擎开发者社区的首页已整体改版为 Agent 开发者社区（豆包模型体验、动手实验室、评测集、案例广场），国内大厂的数据开发者入口正在向 Agent 方向收拢，这一点与本专栏近期跟踪的「目录与身份为 Agent 补接口」是同一条线。