datainfra前沿动态 · Vol.68

BigQuery 把分析方法拆成六个可串联的 SQL 函数；Flink Operator 把扩缩容决策拆成三个插件点；Glue 用一根资源链接把 Redshift 接到 Unity Catalog；Redis 8.10 让结构相同的哈希共用一份字段名

本期聚焦四条跨 9 月 14 至 15 日的进展：BigQuery 把变点检测、归因与因果推断封装成可组合的表值函数，Flink Kubernetes Operator 把自动扩缩容的三个决策环节开放为可插拔 SPI，AWS Glue 用资源链接把 Redshift 的查询接到 Databricks 管理的 Iceberg 数据上，Redis 8.10 用哈希模板把逐条重复的字段名改成共享引用。

DataInfra BigQuery Google Cloud Apache Flink Kubernetes Autoscaler AWS Glue Redshift Unity Catalog Redis 存储编码

这四件事落在分析层、编排层、元数据层与存储编码层，互不相干，动作却是同一个：把一件原本藏在系统内部、只能整体携带或整体重复的东西，拎出来做成一个可以单独命名、单独调用、单独授权的对象。BigQuery 把一次洞察背后的三步推理拆成六个表值函数，每一步的输出都能直接喂给下一步。Flink Kubernetes Operator 把自动扩缩容的评估、执行与对齐三段拆成三个插件接口，并顺手改了默认策略——宁可扩，不再因为对齐不上而否决。AWS 给「数据在别人家目录里」这件事造了一个一等对象：Glue 默认目录中的资源链接，它不复制数据也不复制元数据，只把 Redshift 的查询指过去，权限得分两段授予。Redis 8.10 则把哈希里逐条重复的字段名集合提出来，做成一份共享模板，正文不动，字段名只存一次。拎出来之后，每一处都留了新的东西要管：函数之间要自己拼参数，插件接口要自己兜住否决逻辑，资源链接上和目标表上要各授一次权，模板也变成了一个有生命周期的连接级状态。

BigQuery 增强分析表值函数：把「为什么变了」拆成六个可串联的函数

事件概述

Google Cloud 于 9 月 15 日宣布，BigQuery 新增一组增强分析表值函数（TVF），覆盖六类分析动作：定位指标何时发生结构性变化、找出变化由哪些维度驱动、估计某个动作的真实因果贡献，以及相关性、趋势与周期性三项常规统计。作者是 Google 的软件工程师 Jenny Ortiz 与 Haoming Chen。

此前要回答「上季度收入为什么涨了」，常见做法是分析师自己写查询、导出到外部工具做统计、再把结论贴回报表。这套流程里，每一步的中间产物都无法被下一个问题直接引用，也没法被 agent 调用。新函数把每一步都做成一个返回结构化结果集的 SQL 函数，运行在数据所在的位置，不必把数据搬出 BigQuery。

技术解析

  • 六个函数各管一类问题：AI.KEY_DRIVERS 找出两个时间段或两组之间指标涨落的主要驱动维度；AI.CAUSAL_EFFECT 用反事实基线估计某个动作或事件的实际贡献；ML.CORRELATION 评估两个数值指标的关系方向与强度；ML.DETECT_CHANGE_POINTS 识别指标发生结构性偏移的日期或区间；ML.TREND 把长期走势与短期波动分开；ML.SEASONALITY 发现按小时、日、周、月或季度重复出现的周期。
  • 输出结构化，因而可串联：官方用 bigquery-public-data.austin_bikeshare.bikeshare_trips 演示了三步链。第一步 ML.DETECT_CHANGE_POINTS（data_col => 'total_trips'、timestamp_col => 'trip_day'）跑出若干断点，其中 2018 年 2 月那次与奥斯汀市议会通过「无桩出行试点计划」的时间吻合；该函数官方称可扩展到数百万条独立时间序列。
  • 断点直接当下一步的参数：第二步 AI.KEY_DRIVERS 把 2018-02-11 作为切分点，取前后各约 30 天窗口，top_k => 10，在 start_station_name、end_station_name、subscriber_type、bike_type 四个维度上归因，得出总行程数 +374.7%（+40,159 次），其中 UT 学生会员 +7,167.1%、终点为 21st & Speedway @PCL 站点的行程 +20,739.1%。
  • 因果一步建反事实：第三步 AI.CAUSAL_EFFECT 以 2017-08-11 至 2018-04-11 作为干预前基线，注入 intervention_timestamp => '2018-02-11 00:00:00'，用 ARIMA_PLUS 构造反事实，给出 +358% 的增量、约 89,775 次增量行程，并标注 99.9% 的因果效应概率。output_time_series => FALSE 时只返回汇总。
  • 接进会话式分析：六个函数已接入 Conversational Analytics，官方给的示例中，一句自然语言提问被拆成 ML.CORRELATION 加 AI.KEY_DRIVERS 两步执行；对应的技能已放到 Google 的 skills 仓库。

行业影响

把分析方法函数化，改变的是分析能力的复用粒度。过去一套归因逻辑写在某个 notebook 或某个外部工具里，换个问题就得重写一遍；现在它是一条 SQL，能进版本库、能被调度、能被 agent 当作一个技能调用。输出结构化这一点的分量不比函数本身小——只有结果是表，一步的输出才能机械地变成下一步的输入，多步调查才有自动编排的可能。

对数据平台方而言，这也是一次边界的重新划分：统计与因果推断过去属于 BI 工具和数据科学环境的地盘，如今被做成了数仓内置函数。BI 层要证明的不再是「能不能算」，而是「算完之后怎么解释」。需要注意的是，驱动归因与因果估计给出的是带概率的结论，README 式的数字很容易被当成确定事实引用，如何把不确定性一路带到报表上，仍是没解决的问题。

相关链接

Conversational Analytics 对 BigQuery AI/ML 的支持见官方文档，配套技能放在Google Skills 仓库。

事件概述

Apache Flink 社区于 9 月 15 日发布 Flink Kubernetes Operator 1.16.0，公告作者为 Dennis-Mircea Ciupitu。这个版本的主线是可扩展性：autoscaler 新增三个可插拔 SPI，并行度对齐的默认策略被换掉，TaskManager 与 JobManager 的 Pod 资源改为使用 Kubernetes 原生 ResourceRequirements 表达，并带了一批 Blue/Green、savepoint 与输入校验方面的修复。

Operator 兼容 Flink 2.3.x、2.2.x、2.1.x、2.0.x、1.20.x 与 1.19.x。文档站点同期做了重构，新增 Internals 部分，把 controller flow、autoscaler、admission webhook 与 operator 启动过程写了出来。

技术解析

  • 三个 SPI 各插一个环节（均按命名实例配置，各自拿到剥离前缀后的独立配置）：FLIP-514 的 Custom Evaluator 允许在决策前注入自定义的扩缩容指标评估逻辑；FLIP-575 的 Scaling Executor 挂在决策被执行的节点上，插件可以否决、把关或调整一次拟议的 rescale；FLIP-586 把并行度对齐策略本身做成可插拔，自定义模式与内置模式一起被发现。
  • 默认值从「否决」改为「执行」：新配置 job.autoscaler.scaling.parallelism-alignment.mode 默认为 BALANCED，取代旧键 job.autoscaler.scaling.key-group.partitions.adjust.mode（旧默认 EVENLY_SPREAD，已弃用但仍受支持）。旧默认在找不到能保持扩缩容方向的对齐并行度时，会维持当前并行度并发 ScalingLimited 事件；新默认回退到计算出的目标值，决策会被应用而不是被否决。
  • 对齐目标也从精确除数改为够用即可：EVENLY_SPREAD 对齐到 key group 或分区数的精确除数，BALANCED 取第一个能降低每 subtask 负载的并行度。官方给的例子是 128 个 key groups、计算目标 24：旧默认落到 32，新默认落到 26，后者容忍轻微倾斜以避免过度配置。OFF 可完全关闭对齐。
  • 配置挂载收敛到 config.yaml（FLINK-39791）：此前 Helm chart 会渲染出 config.yaml 与 flink-conf.yaml 两份文件，而 Flink 的 GlobalConfiguration 优先读后者，导致 values.yaml 里 defaultConfiguration.config.yaml 的内容被静默忽略。现在一律以 config.yaml 挂载；用 kubectl edit 或 kubectl patch 改动态配置也必须写在这个 key 下。
  • 读回运行中作业的真实配置：Operator 通过 JobManager configuration、job execution 与 checkpoint config 的 REST 端点取回有效配置，叠在由 spec 推导出的观察配置之上——作业的 main 方法可以以编程方式改配置且优先于 Operator 提交的，spec 只是请求而非最终记录。每个 job id 取一次并按资源缓存，全局终止状态的作业跳过。
  • 输入侧加固：FlinkSessionJob 的 jarURI 按 scheme 白名单校验，默认只允许 https（配置键 kubernetes.operator.user.artifacts.allowed-schemes），解析到内部地址的 host 会被拒绝；artifact 下载加了连接超时、总时间预算与体积上限；autoscaler state 解压缩有大小上限；memory tuning 只应用自己写入的 override 键；Kafka 与 Pulsar 的分区指标名不再用正则解析。
  • 其他修复：Blue/Green 在前一个 deployment 删除后立即完成转换；suspended 作业可从 savepoint 重新部署；FlinkStateSnapshot 遵循所引用 FlinkSessionJob 的 state.savepoints.dir，其 backoffLimit=-1 现在真的表示无限重试；source vertex 不再被扩到超过分区数。

行业影响

Operator 把扩缩容从一个闭环策略改成一条可装配的流水线，意味着「什么时候扩、扩到多少」这类判断权被部分移交给了使用方。有明确成本或合规约束的组织可以在执行环节插一道否决，把组织策略写进代码而不是写在值班手册里。

默认值的改动更值得注意。从 EVENLY_SPREAD 到 BALANCED，本质上是把「对齐不完美时该怎么办」的取向从保守翻成了务实：少几个 slot 的倾斜可以忍，因对齐不上而完全不扩容不能忍。升级时这条会静默改变线上行为，正在用默认配置的集群应当先评估再升。

相关链接

AWS Glue 目录联邦接进 Unity Catalog：用一个不复制元数据的资源链接给 Redshift 开查询通道

事件概述

AWS Big Data Blog 于 9 月 15 日刊出联合航空（United Airlines）的实践，讲 Redshift Serverless 如何经 AWS Glue Data Catalog 联邦查询由 Databricks Unity Catalog 管理、存放在 S3 上的 Iceberg 数据。文章由 Vaibhaw Agrawal、Ankit Aggarwal 与 Raja Kalluri 联合撰写。

联合航空每天处理数十亿事件，数据按 bronze-silver-gold 的 medallion 架构落在 S3 上，整体 PB 级，其中用户交互层是数十 TB 的近实时数据。这批 gold 表编目在 Unity Catalog 里，不在 Glue 中，Redshift 原本看不见，过去的办法是复制进 Redshift Managed Storage 并维护同步管道。

技术解析

  • 四层联邦链：Unity Catalog 通过 Iceberg REST API 暴露表（Delta 表需开启 UniForm 才能呈现为 Iceberg 兼容元数据）→ Glue 中的联邦目录（示例名 databricks-federated-catalog）→ 默认 Glue 目录中的资源链接数据库（示例名 databricks_federated_db_link，TargetDatabase 指向联邦目录里的 databricks_federated_db）→ Redshift Serverless 外部 schema。联邦只发生在元数据层。
  • 资源链接是这次的关键补丁：Redshift 的 CREATE EXTERNAL SCHEMA 只能对默认 Glue 目录解析，不能直接指向非默认的联邦目录。资源链接补上了这一段，它位于默认目录，CATALOG_ARN 也就用不上，由 Lake Formation 在查询时解析。它不复制数据也不复制元数据，只是一个指针。
  • 权限必须分两段授予：资源链接上只支持 DESCRIBE 与 DROP，真正的 SELECT 要授在联邦目录里的目标表上，这是 Lake Formation 的 grant-on-target 模式。官方点明了一个常见错误：只在资源链接上授 SELECT 无效，查询会失败。
  • 六步查询流：分析师提交 SQL → Redshift 经资源链接到联邦目录解析外部 schema → 联邦目录调用 Unity Catalog 的 Iceberg REST API 取当前表元数据 → Redshift 命名空间 IAM 角色调用 Lake Formation GetDataAccess → Lake Formation 评估细粒度策略并签发限定范围的临时 S3 凭证 → Redshift 直接读 S3 上的 Iceberg 文件。
  • 落地规模与收益：生产环境已联邦 30 张表，另有 70 张在上线，未来几个月计划扩展到数百张；第一阶段约 100 名分析师拿到了访问权，且没有新增任何管道。官方给出的成本项是每月减少约 $30K 的冗余 ETL 基础设施开销。Redshift Serverless 采用与 RG 实例族相同的 Graviton 查询引擎，官方称数据湖查询性能最高为前几代的 2 倍。
  • 容灾一并简化：此前跨区域 DR 依赖 Redshift 快照，RPO 为 3 小时或更长；改为利用 Delta Lake 上的 S3 跨区域复制后，DR 区域新建的 Redshift Serverless 工作组可以联邦到同一份 S3 数据，获得接近连续的 RPO。
  • 配套约定：所有联邦 schema 用 {domain}_iceberg 命名，显式提示数据不是 Redshift 原生存储；源表需保持良好分区并定期压缩，因为联邦查询的性能取决于写入时的数据组织。

行业影响

这条路径把跨平台的目录打通从「复制一份」改成了「指过去」。对 Databricks 与 Redshift 长期并用的组织来说，代价从存储与管道的重复，降到几个元数据对象和两处授权——文中 30 张表、100 名分析师、零新增管道的规模，说明这条路在当前形态下已经能承载生产查询。

更值得注意的是它把「数据不在本地」变成了一个显式的一等对象，连权限都被迫显式拆成两段。这比透明代理要笨一点，但也更难出错：谁在哪个目录上授了什么权，是可以逐条审计的。剩下的约束在源端——Delta 表必须开 UniForm，分区与压缩质量直接决定查询延迟，联邦并没有把数据工程的问题一并消掉。

相关链接

Redis 8.10：哈希模板让结构相同的键共用一份字段名

事件概述

Redis 于 9 月 14 日发布 Redis 8.10（Redis Open Source 正式可用），公告作者为 Bosmat Tuvel 与 Lior Kogan，墨天轮中文日报在次日跟进。这个版本的核心是 compact hash：把哈希里逐条重复的字段名集合提取成一份共享模板，配合新的 HIMPORT 命令做批量写入；同期还有增量备份与恢复、JSONPath 语法扩展、Stream 读取量控制、集合基数命令与 TimeSeries 增强。

典型场景是海量结构相同的哈希——数以百万计的用户画像，每条都带 name、email、country、last_login 四个字段名。传统编码下，这四个字段名在每个键里各存一份。

技术解析

  • 哈希模板：新的内部编码允许共享同一套字段名的哈希只保留一份字段名副本，取值各自独立，官方称内存占用最多降低 50%。现有哈希命令语义不变，也可以选择让符合条件的哈希自动转为模板编码，不必改应用。
  • HIMPORT 配套批量写入：客户端先用 HIMPORT PREPARE 声明一次字段集合，之后 HIMPORT SET 只传值、按位置对齐字段名。字段名不再逐条传输与解析，官方称哈希加载吞吐最高提升到 2 倍。宽表新哈希上的 HSET/HMSET 吞吐最高提升 104%。
  • Stream 侧：XREADGROUP 吞吐最高提升 28%（COUNT 100），深流（deep stream）的内存占用最多降低 26%。XREAD/XREADGROUP 新增 MAXCOUNT 与 MAXSIZE，分别限制跨所有 Stream 的返回总条数与总字节数——原有 COUNT 只对每个 Stream 单独生效，多流读取时总响应仍可能失控。
  • 增量备份与恢复：新增 BACKUP 命令族。备份以一个时间点 RDB 快照（BASE）开始，随后把增量写入记到 INCR AOF 文件中，各分片的快照可以错峰创建而仍构成一次协同备份；封存时不需要再 fork 一次，建快照时间错开的分片也能一起收尾。恢复侧用新的 preload-file 启动参数加载封存后的备份清单或独立 RDB 文件。
  • 其余能力：JSONPath 支持算术与比较运算符、in/nin、字符串与数组函数、以及 min()/max()/avg()/sum()/stddev() 等聚合；新增 SUNIONCARD 与 SDIFFCARD（SUNIONCARD 可用 APPROX 走 HyperLogLog 估算，标准误差 0.81%）；LMOVEM/BLMOVEM 支持原子搬移多个元素，COUNT 与 EXACTLY、OBO 与 BULK 可选；TS.NRANGE/TS.NREVRANGE 按时间戳而非按序列分组返回，TS.READ 支持阻塞等待新样本，TS.MRANGE 增加 EXCLUDEEMPTY。

行业影响

哈希模板是那种不引入新接口、只改内部编码的收益：应用不用改一行代码，内存账单直接下来。对把 Redis 当特征存储或会话存储用的团队，这类负载的字段名重复率极高，50% 的内存降幅在大规模部署上是实打实的成本项，内存单价往上走时这笔账更显眼。

把字段名集合提出来做成可命名对象之后，也带来了新的状态要管：模板本身成了需要观察和维护的东西（官方提供了相应的 INFO 与 MEMORY USAGE 观测口径），批量导入路径也从无状态变成了先声明后使用。这是一贯的取舍——共享带来节省，共享出来的那个对象则变成新的运维实体。

相关链接

编者评

四条进展指向同一个动作：把重复、隐式或只能整体对待的东西，提成一个可命名、可单独操作的实体。BigQuery 提取的是分析动作，一次「为什么」被拆成变点、驱动、因果三段，每段都能单独调用；Flink Operator 提取的是扩缩容决策环节，评估、执行、对齐各自成为一个插件接口；AWS 提取的是数据位置，一个不复制元数据的资源链接把「数据在别处」变成了目录里的一等对象；Redis 提取的是字段名集合，让结构相同的键从各存一份改成共享一份。

有意思的是代价的位置。每一处提取都把一部分原本由系统兜住的东西交回给使用者：函数之间要自己拼参数，插件要自己实现否决与兜底，权限要在链接上和目标表上各授一次，模板要自己观察和维护。抽象层每抬高一格，使用者就多一格要自己负责的地方——这四份发布说明都不约而同地在「现在你可以自己控制」后面跟了一段「以及你需要注意」。

关于本期来源：中文源这条线本期只捞到一条。阿里云与火山引擎在 9 月 15 至 16 日没有可核验的产品级发布；外滩大会上的 OceanBase 表述（Agent 正在成为新的数据用户、某银行引入语义层后智能问数准确率从 70% 升至 98%）属于会议观点而非产品变更；Singdata 的多云湖仓发布（9 月 15 日，覆盖八大云平台与三种 CPU 架构）是新闻稿，没有可核验的技术细节；KeewanoDB 的 GA 与 1200 万美元种子轮（9 月 15 日）技术信息同样不足。按「优先技术内容」的口径，这几条都没有提升为主题，Redis 8.10 是这批线索里唯一有一手英文发布说明、且被中文日报跟进的条目。