datainfra前沿动态 · Vol.57

BigQuery 连续查询进入有状态时代，流式 JOIN 与窗口聚合直接写进 SQL；Dataflow 把流式作业升级拆成 stop-and-replace 与并行双跑两条路径，drain 超时可触发自动取消；Databricks 把 AI Certification 作为可查询评分卡写进 Unity Catalog，schema 一变即刻失效；Moovit 用 EMR Spark SQL 接走 Redshift 重聚合负载，管道成本降 33%、预置集群容量砍半

本期聚焦 DataInfra 四条动态，共同指向一条主线：过去依赖工程师临场判断的环节——流状态怎么存、何时切流、资产能不能信、哪类负载该交给哪个引擎——正在变成平台上可声明、可查询、可配置的对象。

DataInfra BigQuery Dataflow Unity Catalog Amazon EMR 流处理 数据治理 成本优化

9 月 3 日，Google Cloud 的 Data Cloud 周报一口气给出两条流计算更新：BigQuery 连续查询开始支持 JOIN 与窗口聚合这类有状态操作，Dataflow 把流式作业的升级拆成 stop-and-replace 与并行双跑两条路径，drain 超时可由参数触发自动取消。Databricks 把 AI Certification 做成可查询的评分卡写进 Unity Catalog，schema 一变即刻失效。AWS 侧 Moovit 交出一份多引擎 lakehouse 的迁移账单：重聚合从 Redshift 挪到 EMR Spark SQL 后，整体管道成本下降 33%，预置 Redshift 容量砍到初始的一半。四件事落在同一天，指向同一个变化——那些过去靠工程师临场拿捏的环节，正在被搬进平台，变成可声明、可查询、可配置的对象。

BigQuery 连续查询支持有状态操作，流式 JOIN 与窗口聚合直接写进 SQL

事件概述

Google Cloud 在 9 月 3 日发布的 Data Cloud 周报（覆盖 8 月 31 日至 9 月 4 日）中宣布，BigQuery 连续查询开始支持有状态操作（stateful operations），目前为 Preview。按官方文档的定义，有状态操作指”跨多行或多个时间间隔保留信息”的计算，本轮开放的是两类：连续查询 JOIN 与窗口聚合（windowing aggregations）。官方给的例子很具体——计算每 5 分钟、每个街区维度的打车需求量与乘客-车辆距离分布，这类以前必须落到 Flink 或 Dataflow 作业里的指标，现在是一条 INSERT INTO ... SELECT 就能持续跑出来的结果。

这不是连续查询第一次放宽能力边界。此前连续查询只处理单行级别的变换，JOIN 与聚合这类需要维护状态的操作不在支持列表里，用户遇到跨流关联或时间窗口聚合时只能绕到独立的流处理引擎。这次补齐后，一条连续查询可以覆盖”两路流按地理围栏关联 + 按 5 分钟翻滚窗口聚合”的完整链路，中间不再需要额外的作业与存储。

技术解析

  • 有状态操作的两个落点：JOIN 负责多路时间导向数据流之间的实时关联，窗口聚合负责把流数据切成固定时间间隔后做聚合。二者可以组合使用，官方示例用 CTE 先 JOIN 再 TUMBLE，最后 GROUP BY window_end, geohash。
  • 语法骨架：FROM 子句必须使用 APPENDS(TABLE t, start_timestamp) 表值函数指定处理起点（导出到 Pub/Sub 时用 CHANGES）。窗口用 TUMBLE(TABLE t, "timestamp_column", INTERVAL 5 MINUTE)，产生 window_end 列供 GROUP BY 使用。JOIN 侧通过伪列 _CHANGE_TIMESTAMP 的时间区间条件限定关联范围，例如 taxis._CHANGE_TIMESTAMP BETWEEN (requests._CHANGE_TIMESTAMP - INTERVAL 5 MINUTE) AND requests._CHANGE_TIMESTAMP。
  • 状态边界由 start_timestamp 划定：该值必须落在源表的时间旅行窗口内（标准表默认 7 天）；传 NULL 会退化为表创建时间，若表创建早于时间旅行窗口则直接报错。连续查询中不能给 APPENDS 传 end_timestamp。
  • 运行期限制：连续查询作业运行期间不能修改 SQL。改了 JOIN 或聚合逻辑只能取消原作业、改 SQL，再用原作业的 end_time 作为新作业的 start_timestamp 接续——有状态查询的”改一次重放一次”成本依然要自己承担。
  • 资源与时长上限：需要 Enterprise 或 Enterprise Plus 版本的 reservation，且 assignment 的 job type 为 CONTINUOUS。用用户账号运行时连续查询最长跑 2 天，用服务账号最长 150 天（导出到 Pub/Sub 必须用服务账号）。
  • CHANGES 仍是 Preview：与 APPENDS 在连续查询中已 GA 不同，处理变更行（含 DELETE）的 CHANGES 函数仍处预发布阶段，适用 Pre-GA 条款。

行业影响

把有状态流处理塞进 SQL，改变的是”谁来做流计算”这道选择题的默认答案。此前一个团队要算 5 分钟窗口的实时指标，需要先回答一堆工程问题：用哪套流引擎、状态存哪里、checkpoint 怎么配、作业挂了怎么恢复。现在这些问题被 BigQuery 收走，用户只需写 SQL。代价也很清楚——Preview 阶段的限制（不可热改 SQL、7 天时间旅行窗口、2 天/150 天的运行上限）意味着它适合稳态运行的指标管道，不适合需要频繁迭代逻辑的探索性场景。

更深一层看，连续查询与 BigQuery 近期连续放出的 TabFM、Graph 能力是同一条路线的不同切面：让”数据不动、能力下沉”覆盖到越来越多的计算形态。这条路线能否成立，取决于这些 SQL 级能力的成本是否真的低于自建流作业——Preview 阶段还没有公开的定价对比，这是观望者最应该盯的指标。

相关链接

Dataflow 流式作业升级进入参数化时代：stop-and-replace 与并行双跑两条自动化路径 GA

事件概述

同一份周报里的第二条 Dataflow 更新：流式管道升级（pipeline update）能力扩容，新增 stop-and-replace 模式，并为已有的 in-place update 与并行双跑（parallel pipeline update）补上 drain 超时与自动取消开关，整体已 GA。这是本期工程价值最高的一条——流式作业的发布流程第一次从”运维经验”变成了”几行 service options”。

升级一个已经跑了数周的流式管道，本质上是一次状态迁移：会话窗口开在那里、去重集合攒在那里、定时器挂在那里。Dataflow 原有答案只有 in-place update 一条，而这条路有个硬前提——新图必须通过兼容性检查。改动一旦触及 step 的 side inputs 之类，检查直接失败，此时过去只剩手工 cancel 或手工起并行管道两条路，前者丢在途数据，后者要自己算好重叠窗口。这次新增的 stop-and-replace 与自动化并行更新，把这两条手工路径变成了声明式的服务选项。

技术解析

  • 三条路径的分工：in-place update（update_strategy_in_place_update）保留 job name、换 Job ID，中途会有停机窗口；automated stop-and-replace 在新作业资源就绪后才给旧作业发 drain 信号，适合”不能容忍重复数据与部分聚合、但能接受 drain 期间短暂停顿”的管道；automated parallel pipeline update 让新旧作业真正并发跑一段指定时长后再 drain 旧作业，适合 ETL 这类能容忍重复与部分聚合的管道。
  • 决定走哪条的是一个参数：只设 parallel_replace_job_max_stop_duration 且不设 parallel_replace_job_min_parallel_pipelines_duration，走 stop-and-replace；设了 min_parallel_pipelines_duration（取值范围 0s～744h，0s 表示零重叠）则走并行双跑。
  • drain 超时与自动取消：parallel_replace_job_max_stop_duration 定义新作业等待旧作业 drain 的最长时间，格式如 30m、1h；parallel_replace_job_cancel_on_drain_timeout 默认在设置了前者时为 true，超时后自动取消旧作业。显式设为 false 且旧作业卡在 draining 时，新旧两个作业会一直并行跑下去——这是成本失控的一条明路，也是这次新能力最该加监控的地方。
  • 两种调用方式：同名更新需要 --update + update_strategy_parallel_job_update，且新作业必须在旧作业启动满 2 分钟后才能启动（防客户端重试导致的重复并行更新）；异名更新不加 --update，改用 parallel_replace_job_name 或 parallel_replace_job_id 指向旧作业，但 Terraform 与 Config Connector 不支持异名更新。
  • 仍需自己扛的部分：并行双跑要求新作业必须是 Streaming Engine 作业；两个管道读同一个 Pub/Sub subscription 官方明确不推荐；drain 会立即关闭在途窗口并触发所有 trigger，可能产生部分聚合结果；并行期间的重复数据、部分聚合、写入顺序问题需要下游系统自己消化。
  • 资源预分配：parallel_replace_job_preallocate_compute_resources 默认 true，在旧作业 drain 期间就为新作业备好 worker；设为 false 时新作业会一直 pending 到旧作业 drain 完成。

行业影响

这条更新的意义不在”多了个功能”，而在把发布风险定价了。过去评估一次流式作业升级的风险，靠的是工程师对业务与状态的了解：这个窗口能不能丢、drain 大概要多久、旧作业卡住了谁半夜起来处理。现在这些判断被翻译成 min_parallel_pipelines_duration、max_stop_duration、cancel_on_drain_timeout 三个可写进 IaC 模板的参数，评审的对象从”这次发布怎么搞”变成”这三个值该设多少”。

值得留意的是官方对两种路径的取舍描述相当坦诚：stop-and-replace 换来的是数据正确性，代价是处理停顿；并行双跑换来的是零停顿，代价是重复数据与部分聚合。这种把取舍明写在文档里的做法，比给一个”零停机升级”的营销说法有用得多——真正的成本只是换了个地方，从停机窗口挪到了下游的去重逻辑。

相关链接

Databricks 把 AI Certification 写进 Unity Catalog，认证从人工盖章变为会过期的可查询评分卡

事件概述

Databricks 在 9 月 3 日发布《Governance beyond security: knowledge, context & ontology on the lakehouse》，以医疗健康场景切入，给出了它对企业数据治理的完整框架：治理不只是安全控制，而是知识（knowledge）、上下文（context）与本体（ontology）三件事，承载这三件事的地方是 Unity Catalog。文章最有工程含量的部分，是提出了一个名为 AI Certification 的机制——它作为可查询的评分卡直接记录在 Unity Catalog 里，取代传统意义上一次性的人工合规证明。

文章的前提判断值得单独拎出来：多数团队把治理当作合规开销来应付的那些产物——分类标签、脱敏策略、数据契约、模型卡片、血缘链接——换个读法就是企业数据语义的原材料。每个分类标签是一个概念，每张模型卡片是一段上下文，每份数据契约是一个共享定义，每条血缘是一个关系。按这个角度重读，已经在跑的安全栈就是本体的初稿，而 catalog 是它该待的地方。

技术解析

  • 五个支柱、同一副透镜：Databricks 的 Data Empowerment Program 把治理拆成数据治理、知识（AI/ML）治理、数据素养、数据管理、本体五根支柱。本体一栏的终点是 AI 语义层，涵盖 LLM 上下文、RAG grounding 与问答就绪度。
  • AI Certification 的四个维度：Governance、Quality、Semantics 三个分数由可查询的系统表、流水线结果与评测运行自动算出；Ownership 分数与最终部署签章需要数据管家（steward）显式签字。
  • 认证会自动过期：这是与普通评分卡最大的区别。schema 变更、契约更新或评测套件失败，都会立刻撤销已有认证，直到检查重跑并通过为止。信任从”某个时点盖章”变成了”一个持续成立的状态”。
  • 执行落在数据层而非应用层：访问控制通过 ABAC（Attribute-Based Access Control）在数据层生效。如果某个用户在 SQL 里查不到某一行，任何 agent 也无法通过向量检索或 embedding 拿到它——同一条策略同时约束人类查询与 agent 检索，绕不过去。
  • 环境隔离用合成数据兜底：SIT、回归、模型测试等非生产环境只消费合成或已脱敏数据，生产 PHI 不越出受治理边界。
  • 成本论点：文章给出的理由是——语义与上下文存在 catalog 里而不是塞进更贵的 LLM token，多数需求用更便宜的模型就能满足，且可信度更高。

行业影响

治理类发布很容易写成愿景文档，这条不一样的地方在于 AI Certification 是个有明确数据结构和失效条件的东西：四个维度、谁自动算谁要签字、什么事件触发失效、在数据层而非应用层执行。这些细节决定了它能不能真的被自动化系统消费——一个写在 wiki 里的合规结论无法被查询，一个存在 Unity Catalog 里的评分卡可以。

对 DataInfra 从业者来说，“认证会自动过期”这一条比五支柱框架更有参考价值。它把数据资产的可信度从静态属性改成动态状态，副作用是治理开销的位置变了：过去花在定期评审会上的时间，会转移到”让检查足够快，快到失效后能在业务可接受的时间内重跑通过”这件事上。评测套件的运行时间，由此变成治理体系的一个关键路径指标。

相关链接

Moovit 把重聚合从 Redshift 卸到 EMR Spark SQL，管道成本降 33%、预置集群容量砍半

事件概述

AWS Big Data Blog 在 9 月 3 日刊出 Moovit 的数据平台现代化案例。这家服务 17 亿用户、覆盖 3,500 座城市与 112 个国家的出行应用，把原先几乎全部压在 Amazon Redshift 上的负载，改造成以 S3 为数据湖、EMR 做重计算、Redshift 预置集群做持续处理与 BI、Redshift Serverless 承接即席与数据科学的多引擎结构。结果是整体数据管道成本下降 33%，预置 Redshift 集群容量缩减到初始的 50%。

真正有参考价值的是它的迁移过程，而不是结论数字。POC 阶段用 EMR Serverless 跑同一批聚合作业时，100 个 executor 跑出约 4 小时，而 Redshift 上的基线是 30–40 分钟——换引擎的第一次尝试是彻底失败的。团队随后做的优化并不神秘：审查 Spark 执行计划发现 shuffle 过多，把大型单体逻辑拆成分阶段转换，重写开销大的 DISTINCT 操作。最终执行时间从 4 小时降到约 10 分钟，executor 数量降到 50 个以下，生产环境关键聚合作业的 p90 执行时间减少 50%。

技术解析

  • 负载到引擎的映射表：重 ETL 与大规模聚合交给 EMR（Spark SQL），理由是在 S3 上直接做分布式处理、不需要先加载进数仓；持续处理与 BI 报表留在预置 Redshift（7×24 运行进程）；即席查询与数据科学交给 Redshift Serverless（突发容量 + 负载隔离）。
  • 隔离靠 data sharing 实现：预置集群与 Redshift Serverless 之间通过 data sharing 共享统一数据视图，即席负载被隔离到 Serverless 而不需要新增预置容量。
  • 被迁移的负载清单：每日用户聚合（3 天回看窗口）、每周聚合（10 天回看窗口）、数据预处理阶段、周末批处理窗口。保留在 Redshift 的是每 20 分钟跑一次的近实时监控查询与 Tableau 看板。
  • 容量收缩是渐进的：用 elastic resize 每次减 2 个节点，逐步验证性能后再继续，最终降到初始容量的 50%。历史路径是 DC2 节点 → RA3 节点 → 多次扩容 → 反向收缩。
  • WLM 优先级跟着重排：重聚合迁走后，从 S3 加载原始数据的 ETL 队列不再是瓶颈，优先级被下调；Tableau 服务负载优先级被上调。
  • 验收标准定得很死：POC 达标线是 Redshift RA3 计算成本降低 >30%、所选管道转换部分运行时间减少 ≥40%，且需连续 5 次以上运行达标；parity 校验要求在冻结窗口内，Spark 与 Redshift 输出在行数、去重用户数以及所有已发布指标上完全一致，另加日趋势比对与行级抽查。
  • 部署形态切换零代码：POC 用 EMR Serverless，生产切换到 EMR on EC2 以复用既有计算预留，官方明确”两种部署选项之间切换应用代码零改动”。
  • 尚未落地的下一步：正在评估由 AWS Graviton 驱动的 Redshift RG 实例，官方称性价比最高可达 RA3 的 2.2 倍、价格低 30%。文章未披露数据量级、表格式与成本绝对金额——这些缺失应当在引用该案例时一并说明。

行业影响

这个案例最值得抄的不是”用 Spark 替掉数仓”，而是它把”哪类负载该放哪个引擎”这件事做成了显式表格，并给每类负载配上了一句理由。多数团队的成本问题不出在引擎选错，而出在负载归属从来没有被显式讨论过——一切默认落在最先建起来的那个系统上，直到账单失控才开始迁移。Moovit 的路径反过来：先列负载、再定归属、逐个迁移并验证 parity、最后下线旧作业。

另一个容易被忽略的点是 POC 的失败过程。4 小时对 30–40 分钟，换引擎在第一轮几乎必然输给调优过的数仓；真正的收益来自拆分与去重重写这类 Spark 侧的优化。把这段写进公开案例，比只给 33% 这个结论对读者更有用——它提示了一个常被低估的事实：多引擎架构的成本收益不来自引擎替换本身，而来自替换之后针对新引擎做的那轮优化。

相关链接

编者评

把这四件事摆在一起看，会发现它们的共同动作不是”加功能”，而是”把判断搬出人脑”。

流式 JOIN 与窗口聚合过去需要工程师判断状态存哪、checkpoint 怎么配，现在写进 SQL 由引擎接管；流式作业升级过去需要运维判断何时切、drain 卡住怎么办，现在换成三个可配置的 service options；数据资产能不能上线过去靠评审会人工盖章，现在是 Unity Catalog 里会自动过期的评分卡；哪类负载该跑在哪个引擎上过去靠默认与惯性，现在是一张带理由的映射表。四处的判断都被搬到了平台上，变成了可声明、可查询、可配置的对象。

这种搬运有个稳定的代价结构：成本不会消失，只会换个位置。BigQuery 收走了状态管理，但收走了也带走了热改 SQL 的能力；Dataflow 把切换风险参数化了，但重复数据与部分聚合的处理责任落到了下游；AI Certification 把治理变成持续状态，代价是评测套件的运行时间成了关键路径；Moovit 拿到 33% 的成本下降，前提是有人在 4 小时那个版本上做了拆分与去重重写。

对从业者而言，判断这类更新的价值，可以问一个简单的问题：这次被搬走的判断，原来值多少小时的人工？搬走之后的代价落在了哪里、由谁承担？官方文档往往把第一部分写得很清楚，把第二部分写在 Limitations 小节里——本期四条，第二部分的答案分别藏在”运行期不可改 SQL""cancel_on_drain_timeout 设为 false 后新旧作业并行""认证撤销后需重跑检查通过”与”POC 首轮 4 小时”四处。读文档时先翻 Limitations，通常比先读特性列表更省时间。