datainfra前沿动态 · Vol.91

Apache Paimon 2.1.0 发布；EMR 内置 Glue 数据质量校验；BigQuery 上线 TimesFM 3.0 多变量预测；Kinesis 三账号全分离流式架构

本期聚焦四条把判断从过程代码挪进声明层的改动：湖格式延迟定 bucket 与放开可空主键、质量规则入驻 Catalog 并用 Iceberg 分支做原子发布、时序预测压缩成一句 SQL、跨账号流式边界落成三份策略。

DataInfra Apache Paimon Iceberg AWS Amazon EMR BigQuery 数据质量 Kinesis

本期四条动态来自四个互不相干的团队：Apache Paimon 社区发布 2.1.0，AWS 把 Glue 的数据质量引擎打进 EMR 的 Spark 运行时，Google Cloud 让 TimesFM 3.0 在 BigQuery 里以 SQL 函数形式提供多变量预测，AWS Big Data Blog 给出生产端、流、消费端分处三个账号的 Kinesis 走查。它们的方向是同一个——把原本必须写在过程代码里的判断，改写成一份能被系统读取的声明。

Apache Paimon 2.1.0：把「写入前必须定的东西」往后推

事件概述

Apache Paimon 社区于 10 月 12 日发布 2.1.0，这是 2.0.0 之后的第一个次版本更新。变更列表覆盖 core、flink、spark、python、format、rest、iceberg、lance、hive、vortex 等模块，规模在近期湖格式项目里属偏大的一档。

从变更方向看，这一版集中在两件事。第一件是把「写入前必须提前定下来的东西」尽量往后推：固定 bucket 表的 bucket 数不必在建表时钉死，主键列的非空约束被放开，全局索引从全量重建改成可增量刷新。第二件是收掉此前允许配置、实际只有一条正确路径的开关：manifest 格式不再可配，文件态权限体系被移除，Spark 侧的 upsert-key 支持被删掉。

国内团队的痕迹主要出现在文件系统与鉴权适配层：OSS 的 NOTICE 随 aliyun-sdk-oss 3.17.4 升级更新，Jindo FileIO 的目录时间戳与访问时间返回值修正，OBS 的 listFilesIterative 实现与鉴权项调整，PyPaimon 支持 DLF token 路径鉴权，dls:// 被写进受支持文件系统表。

技术解析

  • postpone 固定 bucket 写入：PR 8992 在 core、flink、spark 三侧引入 postpone fixed-bucket write builder，让写入方不必在写入开始前就把 bucket 数确定下来。配套改动包括 Spark 在 rescale 之前先落盘 postpone 批次、postpone overwrite 时重算 bucket 数、以及 postpone 写入的默认 bucket 数，Python 侧则把 postpone 批次写进固定 bucket。
  • 可空主键：PR 9094 在 core、flink、python 支持 nullable primary keys。此前主键列非空是一条隐含前提，上游 CDC 里可空的键要靠用户在写入前自行兜住。
  • 全局索引重构与增量刷新：PR 8818 重写全局索引构建流程并支持增量刷新，配套有 BTree 全局索引的 TopN 下推、向量索引与全文索引铺到带 deletion vector 的表上、主键表全文检索并行化。索引侧另有 file index 系统表、索引清单的投影扫描、以及按合并后的统计信息裁剪 data evolution 分组。
  • 被收掉的配置与破坏性变更：manifest 格式不再可配，配套落地了分块 Avro reader、统一的 reader 实现与 manifest Avro writer；文件态权限体系被移除，权限检查改由统一的分区与 consumer 操作校验承担；Spark 侧 upsert-key 支持被删除；版本化序列化抽象被移除。升级前这四条需要逐条比对。
  • Parquet 谓词下推的正确性问题：三条修补属于数据正确性级别——避免有损的 Parquet 谓词下推、修掉 Parquet 谓词过滤之后 DELETE 与 UPDATE 命中错误行、修声明 schema 与 Parquet 文件实际不一致时的读取与下推。此外还有 DELTA_BINARY_PACKED 累计读取计数与稀疏行区间边界 RLE 跳过的修正。
  • PyPaimon 转向 Rust 原生规划：扫描规划、data evolution 行区间规划、Blob 描述符读取陆续交给 pypaimon-rust；写入侧把行按分区与 bucket 在 Arrow 层分组，绕开逐行提取带来的 GIL 开销；新增 row-id 区间处理 API 供 Ray 侧使用。BLOB 读取还做了延迟化——payload 在过滤之后才读。
  • BLOB 与 data evolution 的其余改动：partial-update 表支持 BLOB 字段，相邻重叠的 blob range 在 compaction 时合并，Spark 的 compact procedure 尊重 blob-compaction.enabled；data evolution 支持 SQL DELETE、新增 merge-into 与 compaction 的并发冲突检测、优化 compaction 规划、冲突后重试，并在 compaction 之后重放 merge 更新。

行业影响

Paimon 与 Iceberg、Hudi 的竞争点正在从「谁支持的表格式特性更多」转到「谁能让写入方少做决定」。postpone bucket 与可空主键背后的取舍是一致的：把约束从建表时刻挪到系统能算出答案的时刻。代价是元数据结构与读写路径要跟着改，所以这一版的破坏性变更集中在 manifest 与权限两块，而不是散落在功能开关里。

对用户来说，这一版的升级清单比过去几版更需要逐条读。索引清单兼容性、file index 与 deletion vector 的交互、以及 manifest 相关配置项，都属于「升级当下不一定报错、跑一段时间才暴露」的那一类。

相关链接

Amazon EMR 内置数据质量：规则住进 Catalog，发布交给 Iceberg 分支

事件概述

AWS 在 10 月 12 日通过 what’s new 与 Big Data Blog 同步宣布 Amazon EMR Data Quality。Glue Data Quality 的规则引擎被直接打进 AWS runtime for Apache Spark（emr-spark-8.1.0）及之后版本，随发行版自带，不需要 bootstrap 动作或额外安装。

覆盖范围包括 EMR on EC2、EMR on EKS、EMR Serverless 三种部署模式，以及 Apache Iceberg、Apache Hudi、Delta Lake 三种表格式，不额外收费。规则沿用 Glue 的 Data Quality Definition Language（DQDL），与 Glue 侧的规则集和 API 保持一致。

官方博客给出两种落地形态：一种是作业内内联校验，适合探索性处理与管道局部检查；另一种是基于 Iceberg 分支的 Write-Audit-Publish（WAP），ETL 先把数据写到分支上，再从 Glue Data Catalog 取回受管规则集校验分支，只有过了质量线才合并进主表。

技术解析

  • 执行入口与返回结构：PySpark 侧从 awsdataquality.transforms 引入 EvaluateDataQuality，调用 apply(df, ruleset, publishing_opts, additional_opts, additional_sources) 后返回一个结果 DataFrame，逐行给出 Rule、Outcome、FailureReason、EvaluatedMetrics。官方示例里的失败输出会带上具体数值，例如 ColumnValues "net_amount" between 0.0 and 25000.0 失败原因是 Value: -2228.87 does not meet ...，配合 {Minimum -> -2228.87, Maximum -> 3394.51}。
  • 规则的两处来源：可以在作业里写成字符串，也可以存成 Glue Data Catalog 里的 managed ruleset，由治理团队拥有并版本化，作业运行时用 get_data_quality_ruleset 按名字拉取。改规则不需要动管道代码，规则与作业解耦。
  • ML 异常检测：DQDL 里的 DetectAnomalies 类规则跨运行学习数据的统计基线并自动标记偏离，适合日行数、营收总额这类写死阈值就要不断维护的指标。
  • WAP 的四个动作：取规则集 → ALTER TABLE ... CREATE BRANCH → 对分支数据跑 EvaluateDataQuality → 通过则 fast_forward 把 main 指到分支快照，失败则先 DROP BRANCH 再抛异常。示例里用了 CREATE BRANCH 而不是 CREATE OR REPLACE，理由是分支若已存在说明有并发或半完成的运行，静默替换会丢掉状态；分支名带 Spark applicationId，避免夜跑与重跑撞名。
  • 必需的 IAM 权限：作业执行角色需要 glue:AccessDataQualityRuntimeConfiguration、glue:CreateDataQualityRuleset、glue:GetDataQualityRuleset、glue:GetDataQualityResult、glue:PublishDataQuality、glue:GetDatabase、glue:GetTable，以及标准的 S3 读写权限。
  • 结果粒度与可选动作：结果生产到 dataset、rule、row 三个层级，管道据此让作业失败、过滤无效记录、把记录路由到隔离区，或把结果发布到 Catalog 用于后续查询。Analyzers 段可以把统计信息提交给 Glue 服务，用于辅助生成新规则。

行业影响

此前跑在 EMR 上的团队要在两条路里选一条。要么用 Deequ 之类的开源库自己写检查，灵活代价是自定义代码要自己维护、没有集中规则集、跨管道没有一致的质量目录；要么把数据过一遍 Glue 换取托管能力，代码少了，代价是质量校验变成独立一步、管道里多一个引擎。这次的做法是把规则引擎放进 Spark 运行时，把「规则放在哪儿」和「谁来执行规则」这两件事分开。

代价也清楚：新增一层对 Glue Data Catalog 的运行时依赖，以及七项 IAM 权限需要加到执行角色上；质量结果的发布与查询都落在 Glue 侧。WAP 示例里还提示了一个容易被忽略的点——分支本身是要回收的资源，失败路径必须先 DROP BRANCH 再抛异常，否则每个失败的夜晚都会在表上留下一个分支和它的数据文件。

相关链接

BigQuery TimesFM 3.0：多变量时序预测变成一个 SQL 函数

事件概述

Google Cloud 于 10 月 12 日宣布 TimesFM 3.0 在 BigQuery 进入 preview。这是 Google Research 的时序基础模型，参数量 3.3 亿，通过 BigQuery 的 AI.FORECAST 函数直接在 SQL 里调用。

相对此前 BigQuery 里的 TimesFM 2.0 与 2.5，核心变化是从只支持单变量预测扩展到原生多变量预测——此前模型只能从单条序列自身的历史预测未来，而现实里的预测问题大多是多变量的：相关目标与天气、促销、节假日等外部驱动共同决定结果。

官方给出的榜单位置是 GIFT-Eval、FEV-Bench、TIME 三个公开时序榜单的第一名，覆盖协变量预测与多变量预测两类任务的零样本精度。

技术解析

  • 三个新维度：TARGET_COLS 支持一次传入多个目标列联合预测，跨序列的相互影响由模型内部刻画，不必为每个指标单独跑模型；PAST_COVARIATE_COLS 收只有历史值的协变量；FUTURE_COVARIATE_COLS 收历史窗口与预测窗口都已知的协变量，例如是否周末、节假日、已排期的促销。
  • 输入表的形状：单表输入，历史观测行与预测窗口行拼在同一张表里。历史行的时间戳落在起始时间与预测切分点之间，目标、past 协变量、已知未来协变量都填满；未来行只填已知未来协变量，目标列与 past-only 协变量置 NULL。官方示例用 NYC Citi Bike 公共数据集预测 subscriber_trips 与 casual_trips 两个目标、7 天窗口，avg_duration_min 作 past 协变量、is_weekend 作 future 协变量。
  • 输出结构：每个目标列返回一个 struct，含点预测 value 与预测区间的上下界，外加 time_series_type、confidence_level、ai_forecast_status 三个字段。
  • drop-in 升级：已有单变量工作流把 MODEL => 'TimesFM 3.0' 换上即可受益于更高的榜单精度；AI.DETECT_ANOMALIES 做异常检测、AI.EVALUATE 做评估，也都可以指定这个模型。
  • 自然语言入口：BigQuery Conversational Analytics 可以把一句自然语言要求翻译成带 TimesFM 3.0 的 AI.FORECAST 查询，并返回带预测区间的交互图表与结论摘要。

行业影响

时序预测此前在数据平台里是一条独立流水线：取数、做特征工程、训模型、托管服务、再把结果回写。把它压成一句 SQL 之后，预测变成查询的一部分，数据不搬动、不需要额外的特征管道与模型托管设施。

边界在官方文稿里也说得很清楚。现在是 preview；调用方式是零样本，不提供微调；模型版本由 BigQuery 侧决定，MODEL => 后面填的是一个名字而不是一份被你管理的资产。对有强可解释性要求、或需要把模型版本纳入变更管理的场景，这条路暂时替代不了自有模型，但作为基线它足够便宜，值得先跑一遍再决定要不要自建。

相关链接

Kinesis 三账号全分离：跨账号流式的策略清单

事件概述

AWS Big Data Blog 在 10 月 12 日给出一套用 Kinesis Producer Library（KPL）与 Kinesis Client Library（KCL）构建跨账号流式管道的走查，覆盖四种部署排列里隔离度最高的一种：生产者、Kinesis 数据流、消费者各自位于一个独立的 AWS 账号。

文章面向的是跑自定义应用的企业负载。Kinesis Data Streams 与 Lambda、Data Firehose、Managed Service for Apache Flink 的集成通常通过资源策略授权即可，KPL 与 KCL 这类自建应用则需要自己把 IAM 策略、加密密钥与监控在账号之间打通。两个库都是 Java 实现，KCL 另有 MultiLangDaemon 支持其他语言。

KCL 侧以 3.5 为基线能力描述：自动发现分片、用 DynamoDB 协调 lease、checkpoint 记录进度以便失败 worker 从上次位置续跑、resharding 时优雅交接 lease、在 worker 之间均衡分片分配。

技术解析

  • 四种排列与选型：全在同一账号、消费者跨账号、生产者跨账号、生产-流-消费三账号全分离。四种各自需要不同的 IAM 配置，文中逐步实现的是全分离这一种，因为它覆盖了最复杂的场景。
  • 必须协调的三份策略：流上的资源型策略、生产者与消费者上的身份型策略、以及加密流的 KMS 密钥共享。三者缺一不可，其中密钥这一条是硬约束——用 AWS 托管密钥加密的流无法跨账号共享，必须使用客户托管密钥（CMK）。
  • 三个账号的职责：生产者账号在 EC2 上跑 KPL，担任流账号里的跨账号 IAM 角色写入；流账号持有 Kinesis 流、为生产者准备跨账号角色、为消费者准备资源型读策略，并预注册一个 Enhanced Fan-Out consumer 通过 consumer 资源策略共享给消费方；消费账号跑 KCL 3.5，lease 表与 checkpoint 落在自己账号的 DynamoDB 上。
  • KPL 的聚合与重试：多条用户记录聚合成单条 Kinesis 记录以提高分片利用率，失败记录按指数退避重试，并发布每实例的 CloudWatch 指标用于运维可见性。
  • 跨账号可观测性：生产端吞吐、流的利用率、消费端 lag 的 CloudWatch 指标分散在不同账号，需要单独设计跨账号的可观测方案，这是文中列出的四类挑战之一。

行业影响

多账号是隔离与成本归属的默认做法，代价是每条通路都要显式授权。这篇走查的价值在于把「跨账号流式到底要配哪些东西」列成了一份可对照的清单，而不是留给团队在实践中摸索。

其中最容易在后期返工的一条是密钥：托管密钥不能跨账号共享，CMK 是硬要求，而流一旦用托管密钥建好就只能在重建时改。这类约束通常出现在项目后期做安全评审的时刻，提前知道能省掉一次返工。

从趋势上看，流式的边界正在从「网络可达」上移到「策略声明」：谁读、谁写、谁持有密钥、谁能看到指标，各自是一份需要版本化和评审的对象。这与本期另外三条的方向是一致的。

相关链接

编者评

本期四条来自四个互不相干的团队，做的是同一件事：把原本写在过程里的判断，改写成一份能被系统读取的声明。Paimon 让 bucket 数不必在写入前定、主键列可以为空，是把「提前决定」改成「延后计算」；EMR Data Quality 让质量规则住进 Catalog，作业只问一句「过了没有」，发不发布交给 Iceberg 分支上的 fast_forward；TimesFM 3.0 把预测压成 AI.FORECAST 里的一组参数；Kinesis 的跨账号通路被拆成三份必须显式写出的策略。

共同点不止是「声明化」。四条都把声明的存放位置和声明的执行者分开了：规则在 Glue Data Catalog，模型在 BigQuery，策略在 IAM 与 KMS，bucket 数在 Paimon 的元数据里；执行者分别是 Spark 运行时、BigQuery 的执行层、Kinesis 服务端、Paimon 的写入路径。这个分离带来一个新的治理对象——声明本身的版本与归属。ruleset 改了谁批、模型版本升了谁验、策略改了谁审、bucket 数被系统重算之后谁来解释，这四问在今天的四条里都没有现成答案，而这恰恰是接下来一年数据基建要补上的部分。

需要说明的是本期中文官方源依旧没有可解析的更新：阿里云与火山引擎的公开页面返回 200 但抓不到文章条目，Doris（4.1.4.1，09-29）与 StarRocks（3.5.21，08-31）的仓库也无新版本。国内团队的痕迹只能从开源仓库里间接读到——Paimon 2.1.0 里的 OSS、Jindo、OBS、DLF 相关修补是这一周能看到的部分。