阿里云 EMR Serverless Spark 落地多 Catalog：一条 Spark SQL 直读直写 MaxCompute、Hologres、StarRocks 与 Paimon；Athena 系统表把查询元数据存成你账户里的 Iceberg，成本分摊与错误归因一条 SQL 到位；dbt 语义层进 Redshift 修非加性指标、Polaris 1.8 给 Ossie 语义模型装上治理端点；AWS 开源 Agentic Data Ingestion：代理写 ETL、双审批门把关

11 月 9 日（周一）业界出现一轮密集发布：AWS 大数据博客五连发，Dremio 一次性放出四篇 Polaris 与 Ossie 深潜，阿里云大数据博客落地 EMR Serverless Spark 多 Catalog。本期选其中技术含量最高的四条。阿里云把 DLF、Hive Metastore、MaxCompute、Hologres、StarRocks、Paimon、Iceberg 七类 Catalog 接进同一个 Spark Session，跨系统读、join、写收敛成一条 SQL、一个 Spark 作业；Athena 的首张系统表 query_executions 把每条查询的执行元数据以 Apache Iceberg 落进用户自己账户的 S3 Tables 表桶，成本分摊、容量判断、错误归因从此是普通 SQL 问题；语义层一天两条——dbt Semantic Layer 用 ratio 定义修掉非加性指标的上卷错误（$550 与 $280 之差），Apache Polaris 1.8 用 beta REST 端点把 Ossie 语义模型纳进 catalog 治理，模型权限与 Iceberg 数据权限正交分离；AWS 开源 Agentic Data Ingestion 参考方案，基础模型提字段映射、写 PySpark 转换，两道 fail-closed 审批门加一个有界自愈代理兜底。四条放在一起是一句话：数据平台的元数据、指标定义与管道构建正在变成可编程、可审计的对象。

EMR Serverless Spark 多 Catalog：一条 SQL 吃掉跨系统加工

事件概述

阿里云大数据博客发布《One Spark SQL, Multiple Catalogs: Unified Data Processing with EMR Serverless Spark》（11 月 9 日）。EMR Serverless Spark 的多 Catalog 能力把 DLF、Hive Metastore、MaxCompute、Hologres、StarRocks、Paimon、Iceberg 以及自定义 Catalog 接进同一个 Spark Session，跨系统的读、join、写收敛进一条 Spark SQL，由一个 Spark 作业完成。

文章从一个真实场景开篇：数据团队每天要出一份用户运营报表，订单明细在数仓、会员等级在在线分析库，过去跨系统加工意味着多套连接配置、为搬数建中转表、再用几个相互依赖的任务把管道串起来——麻烦出现在 SQL 跑起来之前。多 Catalog 把这些数据空间带进同一个 Session，订单表、维表、结果表直接出现在同一条 SQL 里。

技术解析

• 表名格式：表引用统一为 <catalog>.<database>.<table>。新 Catalog 扩展的是 Spark 的数据面，既有业务 SQL 原样保留；一张 Session 里可以并列出现 odps.retail_dw.dwd_order_di、holo_realtime.public.dim_user_level、paimon_curated.ads.user_pay_detail 这样的三段名。
• 支持范围：DLF Catalog（含 Paimon、Iceberg 表）、Hive Metastore Catalog（保留原元数据体系）、MaxCompute Catalog（内置 MaxCompute DataSource V2）、Hologres Catalog（三段名直读直写）、StarRocks Catalog、Paimon Catalog（元数据托管 DLF/HMS/文件系统，一个 Session 可挂多个）、Iceberg Catalog（走 DLF 或 HMS，也可独立）、Custom Catalog（基于 Spark CatalogPlugin 机制扩展自有元数据系统）。
• 连接一次、全工作区复用：workspace 的 Data Catalog 是统一入口，连接地址、网络与认证信息由平台集中管理，业务代码只引用稳定的逻辑表名。Data Catalog 暂不支持的类型用 spark.sql.catalog 配置自行注入；Paimon、Iceberg 等湖格式能力内置，跳过找包、打包、上传 JAR 与解 ClassPath 冲突的流程。
• 统一执行计划：来自不同 Catalog 的表进入同一个 Spark 逻辑计划，由 Spark 统一安排数据扫描、谓词下推、分区裁剪、join 与 shuffle，结果直接写目标 Catalog。示例里 MaxCompute 订单表 LEFT JOIN Hologres 会员维表、结果写 Paimon 表，整条管道提交一个 Spark 作业，中间没有同步表与搬数脚本。
• 迁移弹性：维表迁去 StarRocks、HMS 或 DLF 时只换全限定表名，业务逻辑不动；目标表也可以换成 DLF 管理的 Paimon 或 Iceberg 表，读写算仍归 Spark。

行业影响

这是湖仓一体之后对「多引擎共存」现实的务实回答：不强迫数据搬家、不重写业务 SQL，把联邦计算下推给统一的 Spark 计算面。对阿里云生态内的用户，数仓（MaxCompute）、实时仓（Hologres）、OLAP（StarRocks）与湖格式（Paimon、Iceberg）的边界在计算层被抹平，DWD 到 ADS 的跨库管道从任务链变回一条 SQL。对行业，这条路线与各家「catalog 联邦 + 统一引擎」的做法互为印证——当 catalog 成为平台的标准供给物，引擎间的数据搬运就从用户的待办清单里消失了。

相关链接

• One Spark SQL, Multiple Catalogs: Unified Data Processing with EMR Serverless Spark

---

Athena 系统表：查询引擎把可观测性落成你账户里的 Iceberg

事件概述

AWS 大数据博客发布《Amazon Athena introduces system tables for query execution observability》（11 月 9 日）。Athena 推出系统表，首张表为 query_executions：每条完成的查询一行元数据，以 Apache Iceberg 表的形式存进用户自己账户的 S3 Tables 表桶，查询完成几分钟内即可查询，不需要自建任何 ETL 管道。

过去做 Athena 的使用分析要靠 CloudTrail 事件或自建日志管道，聚合指标也分不清失败查询里哪些是用户语法错误、哪些是系统问题。系统表把这些问题的答案变成普通 SQL：用量分析、成本分摊、性能趋势、审计与容量优化，一条查询一种。

技术解析

• 存储与所有权：数据落在账户内的服务托管 S3 表桶（仅 Athena 服务可写入），默认 SSE-S3，可换用户自己的 KMS 密钥；账户内任何 IAM 主体都无法修改或删除单条记录。schema 定义、分区、compaction、快照管理与数据过期由 S3 Tables 自动维护；保留期经 record expiration 配置，最短 1 天、无上限。表引用路径为 "s3tablescatalog/aws-athena"."metadata"."query_executions"。
• 字段面：查询标识（query_execution_id、query_string、submission_date_time）、上下文（work_group_name、catalog、database、tables_accessed）、身份（principal_arn）、性能（total_execution_duration、planning time、query_queue_time_duration）、资源（data_scanned_size、容量预留查询的 dpu_count）、结果（state_enum、error_category_enum、error_message）。
• 典型查询：按工作组或 principal_arn 汇总 data_scanned_size 做成本分摊；用 APPROX_PERCENTILE 看执行时长 p50/p95 与排队时长的周环比判断容量压力；CROSS JOIN UNNEST(tables_accessed) 做按表审计；COUNT(*) FILTER (WHERE state_enum = 'FAILED' AND error_category_enum = 1/2) 把系统错误与用户错误分开——这是聚合的 CloudWatch 指标做不到的。
• 容量预留判断：dpu_count 乘以执行时长折算 DPU-hours，用来判断预留容量是否偏大偏小、按需负载该不该转预留。
• 开放互操作与代理集成：Iceberg 格式意味着 Athena、DuckDB、Redshift、EMR、Spark、Trino 都能查这张表；它已在 AWS Glue Data Catalog 注册，QuickSight 等 BI 工具可直接接。配套路径有两条：经 AWS MCP Server 让 MCP 兼容的 AI 代理用自然语言查元数据；AWS Agent Toolkit 提供开源的 Athena system tables Agent Skill，内含 schema、示例查询库与最佳实践，建议给代理最小只读 IAM，API 调用全部进 CloudTrail。

行业影响

「元数据也是数据」这句话有了新的实例：查询引擎把自身的可观测性产物落成用户账户里的开放表格式，观测数据从专有 API 与日志管道里解放出来，进湖仓分析的常规工具链。这延续了 AWS 用 S3 Tables 承载 Iceberg 的路线——引擎的运行痕迹与业务数据同等待遇：可联邦、可加密、可审计。对正在给数据代理配权限的团队，这张表还自带一层价值：代理自己跑了多少查询、扫了多少数据、错了几次，都能用 SQL 回答。

相关链接

• Amazon Athena introduces system tables for query execution observability

---

语义层进治理面：dbt 语义层落 Redshift，Polaris 1.8 纳管 Ossie 模型

事件概述

11 月 9 日语义层出现两条动态。AWS 大数据博客发文《Define metrics once and keep them correct with the dbt Semantic Layer on Amazon Redshift》：Redshift 没有原生语义层，文章用非加性指标的经典错误演示开源 dbt Semantic Layer（MetricFlow）如何让指标定义一次、任意粒度正确。Dremio 发布《Governing Apache Ossie Semantic Models in Apache Polaris》：Apache Polaris 1.8 交付 beta 语义模型 REST 端点，把 Ossie 语义模型当作 catalog 资源纳管——存储与版本化之外，补上「谁能写、谁能审、谁能发」的细粒度控制。Ossie 是 ASF 孵化中的开源语义建模项目，面向 SQL 优先分析，跨引擎标准化业务指标、模型级血缘与可复用语义实体。

技术解析

• 非加性陷阱与表爆炸：预聚合表固定在一个粒度上，允许用户按 n 个维度任意切片就需要 2^n 张表（7 个维度即 128 张），现实中没人这么做，只能收到工单再建表。更隐蔽的是非加性指标：示例里周一 1 笔 $1,000 订单、周二 4 笔各 $100，日粒度 AOV 各自正确，BI 工具上卷到周直接平均得 $550（错），正确答案是 SUM(revenue) / COUNT(orders) = $1,400 / 5 = $280。错误值看起来合理，最难发现；转换率、利润率、CPA、distinct count 同病。
• MetricFlow 的做法：指标定义放进 dbt 项目的版本控制 YAML——average_order_value 定义为 ratio 类型（分子 total_revenue、分母 order_count），查询时按请求粒度重新生成正确的 SQL，而不是平均预聚合值。mf query --metrics average_order_value --group-by metric_time__week 从按天的 1000/100 换到按周只改一个词，结果仍是 280；mf query --explain 输出生成的 SQL，交给任意工具、调度器或物化回 Redshift 的 dbt 模型。环境用 dbt-redshift==1.9.5 与 dbt-metricflow==0.11.0，配套仓库 aws-samples/sample-dbt-semantic-layer-on-amazon-redshift 含 CDK 部署与端到端测试。开源 dbt Core 路线下，无原生连接器的工具（如 QuickSight）读 semantic_manifest.json 或读物化表；Tableau/Power BI 用的托管 Semantic Layer API 需要 dbt Cloud，YAML 定义两边相同。
• Polaris 1.8 治理端点：语义模型成为与 dataset、credentials、roles 并列的 catalog 资源类型，走 Polaris 既有 RBAC 框架，权限作用域收窄到最贴近团队的 catalog 或 namespace。端点默认关闭、显式 beta，客户端要容忍 API 演进。关键设计是权限正交：模型权限不授予数据访问——作者没有目标表的数据集级权限就发不了生产模型，语义模型权限与 Iceberg 数据面权限分离，减小爆炸半径。
• 三段发布工作流：author（草稿可引用数据集但不自动获得数据权限）→ review（校验 SQL 兼容性、引用数据集存在性、跑样例查询）→ publish（需要目标作用域的显式 publish 权限，发布前断言数据集 ACL）。推荐在 CI 里跑 create/read/update/delete 的兼容性测试，把 beta API 当契约管。

行业影响

上一期 GCP 把六种语义方言收进同一张上下文图，是索引层的统一；这一期两条动态是权限层的分离——指标的写作者、审核者、发布者与底层数据的读者被拆成不同权限面。语义层的竞争从「谁的定义语言赢」推进到「定义怎么被治理」：定义进版本控制、模型进 catalog RBAC、发布进审批流。落地时最先要做的两个决策也被点明：发布权集中还是下放，数据权限在 CI 里断言还是在发布时断言。Redshift 用户侧的信号同样直接——什么时候该上语义层有了明确触发条件：指标需要按无法预先枚举的维度组合切片，且包含非加性度量。

相关链接

• Define metrics once and keep them correct with the dbt Semantic Layer on Amazon Redshift
• aws-samples/sample-dbt-semantic-layer-on-amazon-redshift
• Governing Apache Ossie Semantic Models in Apache Polaris: APIs, Privileges, and Scope
• Apache Ossie
• Apache Polaris

---

Agentic Data Ingestion 开源：代理写 ETL，fail-closed 审批门把关

事件概述

AWS 大数据博客发布《Automate ETL pipeline creation with Amazon Bedrock AgentCore and AWS Glue》（11 月 9 日），开源参考方案 Agentic Data Ingestion。对准一个文件或数据库表，基础模型提出字段映射、生成 PySpark 转换代码，代码先在 Spark 上测试，通过后部署成 AWS Glue 作业；映射与代码测试两步设人工审批门。

方案瞄准的是小到不值得立项的数据源：仪器导出、合作方 CSV、零散库表——过去每个源都要工程师花数天映射、编码、测试、开通，schema 一变推倒重来。官方给出的运行成本：样例规模一次 run 约 $0.10–0.25，闲置部署约 $15–20/月。

技术解析

• 十步工作流：文件校验 → schema 提取 → schema 比对（漂移检测）→ schema 映射（基础模型打置信度分，审批门）→ 代码生成（PySpark 转换 + 数据质量规则）→ 代码测试（Spark 上实跑，审批门，测试连续失败强制转人审）→ 基础设施开通 → Glue 作业创建 → 质量规则登记 → 运行。上传经 EventBridge 与 SQS 触发 Lambda，Step Functions 编排十步；代理用开源 Strands Agents SDK 构建、跑在 Bedrock AgentCore 上，模型是 Bedrock 的 Claude Sonnet 4.6，整套用 CDK 部署。
• 审批门 fail-closed：判断不了是否需要审核就等人来批；在门上等 72 小时自动失败；批准与拒绝都记录审核人身份。映射免审的条件是每个字段对都高置信且被名字匹配佐证，复用过的映射默认送审。
• 两个辅助代理：映射置信度低时，complex-mapping agent 往审核界面补样例值与具体问题；Glue 作业失败时，self-healing agent 最多启一次新 run——schema 或类型错误重新生成代码，内存溢出换更大 worker。重试有明确的不重试条件：失败作业已经写过数据、重试会重复写入，或者错误出在权限等重试解决不了的问题，则保持失败并把诊断留在详情页。
• 源与目标：源支持 CSV（含 TSV、管道分隔）、JSON、Parquet、Avro、ORC、Excel，以及 JDBC（PostgreSQL、Aurora、MySQL、MariaDB、Oracle、SQL Server），增量按时间戳或数字水位列只读新行；目标支持 S3 Tables（Iceberg，append/overwrite/merge 三种写法，Athena/EMR/Redshift 可直接查）、JDBC 库（凭据运行时走 Secrets Manager）、自管桶里的分区 Parquet。数据质量规则来自获批的映射、在作业内执行，失败行先隔离再写，对 S3 Tables 目标默认开启。

行业影响

agent 写 ETL 的争议一直在于对错难辨，这个方案把答案落在流程而不是模型上：映射假设与生成的代码都在审批门上暴露给人，重试有明确的不重试条件防重复写入。AWS 自述模型会挑出「技术上合理、业务上错」的映射——这正是人审存在的理由，也是这份方案里最值得抄走的设计。对做数据平台的团队，借鉴对象不是代理本身，而是「fail-closed 审批 + 有界自愈 + 审核留痕」这套治理壳：它不绑定 AgentCore，迁移到自家编排引擎上并不难。

相关链接

• Automate ETL pipeline creation with Amazon Bedrock AgentCore and AWS Glue

---

编者评

四条动态分布在数据链路的不同位置，指向同一件事：数据基础设施正在把控制面开放成可编程对象。阿里云把联邦计算的元数据面统一进 workspace 的 Data Catalog；Athena 把引擎自身的观测元数据落成用户账户里的开放表格式；语义层的两条动态把指标定义从应用层收进治理面——版本控制 YAML 与 catalog RBAC；Agentic Data Ingestion 把管道构建的每个判断点交给人审门。上一期 GCP 的动作是把 AI 能力铺进 pandas 与聊天界面，这一期 AWS、Dremio、阿里云的动作是把权限、审计、观测这些「基础设施的基础设施」做成开放格式与标准 API——当数据代理越来越多地直接读写数据平台，平台竞争的重心正从吞吐与压缩率挪向三个问题：元数据是不是开放格式、权限是不是正交可组、代理的操作是不是可审计。周一这轮密集发布里还有几条收进注脚：Workday Data Cloud 与 AWS 做双向零拷贝集成，治理过的人事与财务数据直接进 SageMaker Unified Studio 与 Glue；CUDOS 5.10 面板新增 Redshift RA3 到 RG 的现代化追踪；Dremio 同日发布的其余三篇 Polaris 运维深潜（Admin Tool、MongoDB 持久化、Iceberg 原子 CTAS/RTAS）覆盖了 Polaris 落地的运维缝隙；Anyscale 发了 Lila Sciences 用 Ray 把 GLM-5.3-Flash 训练扩到 1M tokens 上下文的复盘，训练侧的规模故事继续推进。数据基建这边的叙事则越来越清楚：下一轮拼的是治理与观测的可编程性。