datainfra前沿动态 · Vol.56

BigQuery 上线 identity columns，把主键生成从应用代码收进引擎；AWS 用三条 CREATE MATERIALIZED VIEW 重建 Medallion 架构，编排、增量与 CDC 一并折叠进表格式；Flink 2.3 + Iceberg 1.11 的 Dynamic Iceberg Sink 在记录级决定落表目标并自动演进 schema，新增事件类型无需重启作业；Databricks 为 Genie Agents 开放 Agent mode API 与 Unity Catalog volumes 非结构化接入，把文档上下文纳入既有治理边界

本期聚焦 DataInfra 四条动态，共同指向一条主线：把原本写在流水线外围的胶水代码折叠进引擎与表格式——主键不用应用生成、编排不用 DAG、新事件类型不用改代码重启、非结构化文档不用另建 RAG 管道。

DataInfra BigQuery Identity Columns GENERATED ALWAYS AS IDENTITY Apache Iceberg Materialized Views Medallion Architecture Amazon SageMaker Unified Studio Amazon S3 Tables AWS Glue Apache Flink Dynamic Iceberg Sink Per-Record Table Routing Schema Evolution AWS Glue Schema Registry Iceberg REST Catalog Databricks Genie Agents Agent Mode API Unity Catalog Volumes Server-Sent Events 数据基础设施

第五十六期追踪到 DataInfra 领域四条动态，日期集中在 9 月 2 日至 3 日：BigQuery 上线 identity columns——用 GENERATED ALWAYS AS IDENTITY 与 GENERATED BY DEFAULT AS IDENTITY 两种声明让引擎接管 64 位顺序主键的生成，应用层与 ETL 工具不必再预计算唯一键，INSERT 与 MERGE 都能直接吃到这份自动化；AWS 把 Medallion 架构压缩成三条 CREATE MATERIALIZED VIEW——在 SageMaker Unified Studio 上以 S3 Tables 为底座，由 Iceberg 行级变更跟踪（position-delete / equality-delete）驱动增量刷新，编排 DAG、高水位与 CDC 代码全部消失，只留 SQL 转换逻辑本身；Flink 2.3 与 Iceberg 1.11.0 的 Dynamic Iceberg Sink 把路由粒度下沉到单条记录——DynamicRecordGenerator 在运行时解析目标表并在表不存在时建表，新字段自动作为 optional column 加进去，作业不重启、表不重写；Databricks 扩展 Genie Agents——Agent mode 全量开放并配套 SSE 流式 API，单个 agent 可挂载最多 10 个 Unity Catalog volumes，PDF、文档、图片与受治理的表在同一轮对话里被一起分析。四条动态的厂商、层次与对象各不相同，方向却高度一致：把原本写在流水线外围的那段胶水代码，折叠进引擎和表格式里。

BigQuery identity columns：让引擎接管主键生成

事件概述

9 月 2 日至 3 日间，Google Cloud 在 Data Analytics 博客发布 identity columns 的正式上线公告。这个功能允许用户在建表时声明某一列由 BigQuery 自动生成 64 位顺序整数，用来做唯一标识符。产品负责人 Wawrzek Hyska 与软件工程师 Aayush Bhatnagar 在文中把落点放在数据摄取路径上：过去工程师需要在应用逻辑或 ETL 工具里预先算出唯一键，现在这段责任被移交给 BigQuery 自身。

对数据工程团队而言，这不是一个”多了一个函数”级别的更新。代理主键的生成看似琐碎，实际横跨多个环节：批量加载要防止重号，流式写入要保证单调，重试与回填要避免撞键，MERGE 语义下还要手工处理”目标表已有值”与”源端无值”的分支。BigQuery 把这些分支统一收进列定义里。

技术解析

  • 两种声明语义：GENERATED ALWAYS AS IDENTITY 由 BigQuery 全权管理并担保唯一性，用户无法写入该列；GENERATED BY DEFAULT AS IDENTITY 提供自动值但允许手工覆盖，适合需要回填历史数据或迁移既有主键的场景。
  • 建表语法：order_id INT64 GENERATED ALWAYS AS IDENTITY (START WITH 1 INCREMENT BY 1)，起始值与步长均可在列定义里指定。
  • 与 DML 的兼容：identity 列适配标准 DML 操作，INSERT 与 MERGE 都能自动为新行分配标识，无需在语句里显式处理该列。上文示例中的写入简化为 INSERT INTO orders (customer_name, order_date) VALUES (...)，order_id 不再出现在列清单里。
  • 收益三条：摄取路径不必预先计算键（streamlined ingestion）；SQL 代码里少掉键管理的样板（reduced boilerplate）；键管理与 DML 原生集成（integrated automation）。

行业影响

把身份生成下沉到引擎，本质上是把一段分布式一致性问题从应用侧搬进了存储层。应用侧算主键的代价不只在于代码量，更在于它要求每个写入方都遵守同一套约定——一旦某个作业绕开了约定，重复键就要靠下游去重来兜底，而下游去重的成本通常远高于在建表时声明一次。

这条更新也让 BigQuery 在与传统数据仓库的迁移对话中少了一个摩擦点：从 Teradata、Oracle、PostgreSQL 迁来的 schema 里，IDENTITY 与 SEQUENCE 是常见构造，此前往往需要改成 GENERATE_UUID() 或 ROW_NUMBER() 之类的替代写法。这类”语义对齐”型的小功能，对迁移项目的实际推进速度影响往往大于一两个大特性。

相关链接

三条 CREATE MATERIALIZED VIEW 重建 Medallion：编排、增量与 CDC 折叠进表格式

事件概述

9 月 2 日，AWS Big Data Blog 发布教程，展示如何在 Amazon SageMaker Unified Studio 中用 Iceberg materialized views 搭建 Bronze / Silver / Gold 三层架构。文章的核心主张是：一条 medallion 流水线可以用三条 SQL 语句表达，转换、编排与增量处理被折叠进每一层的定义里，没有 ETL 作业、没有编排器、也没有需要维护的变更数据捕获代码。

教程以网约车行程数据为例：Bronze 是 S3 Tables 上的 Iceberg 表 trips_bronze，Silver 是物化视图 mv_trips_silver（做时间戳转换、NULL 过滤并派生 revenue_per_mile 与 rating_category），Gold 则是在 Silver 之上再叠一层物化视图——mv_city_daily_metrics 与 mv_vehicle_performance。Gold 建立在 Silver 之上形成 MV on MV 的声明式依赖链，每层的定义指向其下层，系统按刷新配置自行决定每层重新处理哪些数据。

技术解析

  • 增量刷新的依据来自表格式：AWS Glue 用 Iceberg 的行级变更跟踪（position-delete 与 equality-delete 文件）识别自上次刷新以来变更的行，只处理这些行。教程中向 Bronze 插入 3 条记录后，Silver 刷新仅处理这 3 条——没有高水位、没有快照对比、没有变更流管道。

  • 调度语法与最小粒度：SCHEDULE REFRESH EVERY 1 DAY，也支持按小时；最小调度粒度为 1 小时，不支持亚小时级新鲜度。手动刷新用 REFRESH MATERIALIZED VIEW。

  • 依赖链示意：

    trips_bronze (table)
└── mv_trips_silver (materialized view)
    ├── mv_city_daily_metrics (MV on MV, daily schedule)
    └── mv_vehicle_performance (MV on MV, daily schedule)

  • 刷新以原子方式执行，由 Glue Data Catalog 用托管 Spark 计算完成，用户不写、不版本化、不部署作业制品。

  • 成本口径：物化视图自动刷新按 每 DPU-hour 0.44 美元计费（1 DPU = 4 vCPU + 16 GB 内存），按秒计费、1 分钟起收。教程规模（300 条记录）跑完全流程约消耗 0.5 DPU-hour 以内，折合约 0.22 美元 的 Glue 计算费；三层流水线的搭建耗时不到 2 分钟。

  • 六条限制必须写进设计文档：① 无亚小时级新鲜度；② 级联刷新不是自动的——刷新 Silver 不会在同一操作中触发 Gold，每层按各自调度或需按顺序手动触发；③ 增量 REFRESH 检测不到行删除，需要传播删除时必须用 REFRESH ... FULL；④ 仅支持 SQL 子集，部分窗口函数、UDF 与复杂表达式不受支持；⑤ 源 schema 以影响定义的方式变化时必须 drop 并重建物化视图；⑥ Iceberg materialized views 不属于开源 Apache Iceberg 规范，无法移植到非 AWS 环境。

  • 服务支持面：创建与刷新需使用 Amazon Athena Spark、AWS Glue 5.1 及以上、或 Amazon EMR 7.12 及以上；教程环境跑在 SageMaker Unified Studio 的 Notebook 上，运行时可选 Athena Spark 或 Glue Spark。

行业影响

这条动态最值得琢磨的不是”用 SQL 写流水线”——声明式转换早就有了——而是增量处理的凭据从”管道自己记的状态”换成了”表格式记的状态”。传统方案里，高水位、快照版本、变更流位点都由编排系统保存，一旦作业被改、被重跑、被回滚，这些状态就会与数据脱节，而排查这类脱节耗时且没有通用方法。Iceberg 把”哪些行变了”写进了自己的元数据，任何有权读表的引擎都能得出同一份答案，状态与数据不再分离。

限制清单里的第 ⑥ 条同样关键。物化视图是 AWS 的私有扩展，不在 Iceberg 规范内，这意味着选择它等于接受一层引擎绑定——这与 Vol.53 以来持续追踪的”开放表格式类型系统收敛”构成张力。工程上的判断很清楚：如果跨云可移植性是硬约束，这一层就不该放进架构；如果工作负载已经锁在 AWS 上，用私有扩展换掉一整套编排器是划算的。

相关链接

Dynamic Iceberg Sink：在记录级决定落表目标，schema 演进不再需要重启作业

事件概述

同日（9 月 2 日），AWS Big Data Blog 发布第二篇 Iceberg 相关教程，这次面向流侧。文章展示如何在 Amazon Managed Service for Apache Flink 上用 Apache Flink 2.3 + Apache Iceberg 1.11.0 的 Dynamic Iceberg Sink 构建”动态流式数据湖”：管道能在新事件类型出现、上游 schema 变化时自适应，不必停流。

核心机制是 DynamicRecordGenerator 与 DynamicRecord。每条输入记录经过生成器后，携带目标表标识、Iceberg schema、行数据与分区规范，由 sink 决定写往哪里。表不存在就创建，记录带了新字段就演进 schema，一个作业即可把 order_events、interaction_events、user_events 以及未来新增的类型分别写入各自的 Iceberg 表，无需为每种类型额外定义 sink。

技术解析

  • 路由粒度是单条记录，不是管道配置：默认路由字段是 event_type，表名来自显式 table-name 字段（若存在）或路由字段本身；schema 推断按 signature 缓存，PartitionSpec 按 schema 缓存，避免逐条重算。
  • schema 演进流程：写入每条记录前比较记录的 schema 与目标表的当前 schema，若记录含新字段，Iceberg 将其加为 optional column 并随下一个 data file 提交；已有文件保持有效，无需重写表，查询旧文件时新列返回 null。
  • 支持的非破坏性变更：加列、扩类型（int → long、float → double）、把 required 列放宽为 optional、删列。撰写本文时不支持重命名列。
  • 两种可互换的 schema 来源：
    • 运行时 JSON 推断（SchemaAgnosticRoutingGenerator）：方便，但推断天然有损——JSON 不带类型信息，整型统一加宽为 LongType、浮点为 DoubleType、ISO-8601 时间戳为 TimestampType（微秒）。没有契约意味着生产者可以静默改变字段的类型或含义。
    • AWS Glue Schema Registry + Avro（AvroToDynamicRecordGenerator）：提供精确类型（long 保持 long、timestamp-micros 保持微秒精度）、在注册时用兼容性规则（如 BACKWARD）强制治理演进、以及生产者与消费者共享的单一事实来源。不兼容的生产者变更在注册时被拒绝，而不是在写入时。
  • immediateTableUpdate 的两难：设为 true，看到新 schema 的 writer subtask 在发出记录前内联应用 create/alter，延迟最低，代价是对 catalog 的并发调用更多；设为 false，需要变更的记录绕行到一个按表名 keyBy 的 update operator，同一表的更新一次一个，稳态下不增加额外 shuffle，代价是变更记录多走一段路。两种取值的 schema 比较逻辑与最终表变更完全相同。
  • 分区规范由生成器决定：partition.candidates 是一个全局候选字段列表（不是每表独立），每张表只取自己 schema 里存在的字段；候选字段后来出现或消失时，sink 通过 Iceberg partition-spec evolution 增删分区字段，这是纯元数据更改，已写入的文件保留其写入时的规范。若某表没有任何候选字段，会被创建为未分区表——所以候选列表务必包含 event-time 字段，否则生产者换个字段名（比如从 event_time 改成 create_timestamp）就会静默产出未分区表。
  • 一致性保证：Flink checkpointing 的 exactly-once 叠加 Iceberg 两阶段提交，端到端无重复、无丢失。
  • 多流 fan-in 的账要算清：多个 Kinesis 流可以 union 后进入同一个 sink。union 不额外增加 shuffle 成本——sink 总是按内部的 per-table writer key 重新分发记录，单流与 N 条独立管道每条记录产生的 exchange 相同。但隔离性有代价：所有表共享一个 writer pool、一个 commit aggregator 与一个 committer，热流的背压与 checkpoint 对齐会耦合到其余所有流，且 writer parallelism 是作业级单值设置。文章给出的取舍是——大量中小体量事件类型适合合并池化，体量大到需要独立并行度与故障隔离的流应当拆成独立应用。

行业影响

流式数据湖最贵的一笔成本长期不在计算，而在变更的协调成本：上游加一个字段，下游要改作业、改表、安排重启窗口、确认在途数据不丢。Dynamic Iceberg Sink 把这件事降级为一次元数据提交——新列以 optional 形式出现，旧文件照旧可读，作业继续跑。

这篇教程的价值还在于它没有只讲好处。JSON 推断”有损且无契约”被明确写出来，partition.candidates 是全局而非每表、可能静默产出未分区表也被点名，union 后共享 writer pool 导致的背压耦合同样在列。对准备落地的团队来说，这几条比主干功能更能决定成败：选 GSR + Avro 而不是 JSON 推断，本质上是在为”上游不会静默改语义”这件事付费。

相关链接

Genie Agents 扩展：Agent mode 全量开放，非结构化文件走进 Unity Catalog 治理边界

事件概述

9 月 2 日，Databricks 发布 Genie Agents 的能力扩展公告，四项更新一并落地：Agent mode 面向所有 Genie Agents 开放并配套 API、Unity Catalog volumes 中的非结构化文件可被直接分析、Genie Code 用于 agent 的批量构建与调优、对话可分享给同事与 agent 管理者。这是自 Data + AI Summit 上 Genie Spaces 演进为 Genie Agents 之后的一次集中扩容。

前两项是这次更新的技术主干。Agent mode 是支撑多步分析的 agentic reasoning loop——它不再”查一次就回答”，而是制定并 refine 研究计划、跨多轮迭代查询探索数据、返回带结论、可视化与引用的报告。非结构化接入则让 PDF、文档、幻灯片与图片与受治理的表在同一轮对话中被一起分析。

技术解析

  • Agent mode 与 Chat mode 的分工：Chat mode 适合快速的事实性查询；Agent mode 面向需要推理的开放式问题。官网措辞是，对于那些过去需要一名数据分析师加上一份完整研究计划的问题，Agent mode 现在可以充当实时研究伙伴。
  • Agent mode APIs：开发者可以把多步推理带出 Databricks UI，集成进自定义应用、聊天机器人、定时报告与内部工具，响应通过 Server-Sent Events 流式下发。API 支持保持完整会话与追问，也能以编程方式取回 Agent mode 的会话与消息用于监控；可视化内容另有下载接口，可与文本回答一并返回。
  • UC volumes 接入的边界：单个 Genie Agent 最多挂载 10 个 volumes。非结构化分析跑在 Agent mode 下，用多步推理检索并分析最相关的文件内容；它遵守 Unity Catalog 权限——用户只能看到自己有权访问的文件。
  • content search 解决规模问题：面向较大的文档集合，content search 会预先准备并索引文件，提升 agent 的推理质量并降低回答延迟。
  • Genie Code 把调优也交给 agent：描述 agent 的用途、示例问题与数据源后，Genie Code 会创建 agent 并补上一组指令——它复用 Unity Catalog 中关于相关表的元数据，以及历史上针对这些表的查询。上线后，Genie Code 可分析具体失败的会话或 benchmark 运行来定位问题，并可汇总高频问题主题与反馈趋势来识别知识缺口。所有建议（指令、示例 SQL、knowledge store 配置）在保存前都需人工复核。

行业影响

把非结构化文件挂进 Unity Catalog volumes 而不是另建一套 RAG 管道，是这次更新里最值得注意的架构选择。企业里”文档问答”通常意味着第二条链路：独立的向量库、独立的摄取作业、独立的一套权限——两套权限模型长期漂移，是这类系统最难收拾的技术债。Databricks 的做法是让文件复用已经存在的治理边界：权限判定发生在 Unity Catalog，而不是在摄取时拷贝一份。代价也清楚——单个 agent 限挂 10 个 volumes，说明这条路目前面向的是”精选文档集”，而非”整个数据湖的语料”。

Agent mode API 走 SSE 流式返回，则暴露了另一层意图：多步分析的耗时以分钟计，同步接口在工程上不可用。把 Agent mode 做成可流式订阅的接口，意味着 Databricks 预期它被嵌进面向终端用户的产品（客户侧分析门户、内部 Slack bot、自定义看板），而不只是留在自己的 UI 里。

相关链接

编者评

四条动态的发布方、技术层次与作用对象全不相同，收拢起来却是同一件事：把一段原本必须自己写的代码删掉。BigQuery 删掉的是应用侧的键生成逻辑，AWS 的两篇删掉的是编排 DAG、高水位与 CDC 代码以及”新事件类型 → 改代码 → 重启”的循环，Databricks 删掉的是为非结构化文档另建一套 RAG 摄取管道的必要性。被删除的这些代码有个共同名字：胶水——它们不产生业务价值，存在的唯一理由是下游系统读不懂上游系统的状态。

而它们之所以现在能被删掉，是因为状态有了公认的存放位置。Iceberg 的 delete 文件回答了”哪些行变了”，Iceberg 的 schema 与 partition-spec 演进回答了”字段与分区怎么变”，Unity Catalog 的权限模型回答了”谁能看什么”，引擎的列定义回答了”主键从哪来”。胶水代码的本质是”一方不知道另一方知道什么”，当这些答案被写进表格式与目录、且任何有权限的引擎都能读到同一份时，胶水就失去了存在理由。

值得留意的是这套迁移并非没有代价，而代价的形态变了：过去是为每段胶水付运维成本——改作业、排重启窗口、排查状态脱节；现在是为每次折叠付约束成本——Iceberg 物化视图是 AWS 私有扩展、不可移植也不支持亚小时新鲜度；JSON 推断有损且无契约，要精确类型就得接受 Glue Schema Registry 的注册治理；UC volumes 限挂 10 个，意味着它服务精选文档集而非全量语料。成本从”分散的、不可预测的运维事件”变成了”集中的、写在文档里的能力边界”。对架构决策来说这是笔划算的交易——边界可以读、可以评估、可以写进设计评审，而凌晨三点的状态脱节不能。