datainfra前沿动态 · Vol.102

Databricks 用 528 条 agent 管道给声明式标价：结构性错误从集群搬进 dry run；Lake Formation 让细粒度授权跨区跟着人走；OpenSearch 把 RAG 摄取折叠成一次托管调用并公开单价；Pinot 1.6.0 RC1 把近似结果写进响应字段并摊开混合版本限制

本期聚焦 10 月 23 日四条动作，形状一致：把一项原本藏在暗处、事后才结算的成本或风险，搬到一处看得见、能计价、可核对的位置，并把搬过去之后的代价逐条写出来。

DataInfra Apache Spark Spark Declarative Pipelines AI Agent 基准测试 Databricks AWS Lake Formation Trusted Identity Propagation IAM Identity Center 跨区域 Amazon OpenSearch RAG 托管摄取 向量索引 Apache Pinot 近似计算 Lucene 版本兼容

本期四条动态全部落在 10 月 23 日这一天，来自两个云厂商、一个平台方与一个开源项目，做的是同一件事：把一项原本藏在暗处、事后才结算的成本或风险，搬到一处看得见、能计价、可核对的位置，然后把搬过去之后的代价逐条写在明面上。Databricks 拿 528 条由 agent 写出的管道做基准，结论是声明式把结构性错误的代价从集群时间搬到 dry run，集群侧降到约 34 分之一，代价是 token 涨到约 2.3 倍；AWS 把 Lake Formation 细粒度授权的判定依据从共享 IAM 角色搬到用户本人的 IAM Identity Center 身份，并让身份对象跨区域复制，代价是生产方与消费方必须同组织、共用同一个组织实例，且 Redshift datashare 的查询引擎仍得与命名空间同区；Amazon OpenSearch 把 RAG 摄取管道折叠成一次托管调用，代价是把单价公开摊开——每 1,000 页 PDF 约 $0.40、每 1,000 张图约 $1.40，且只在六个区域可用；Apache Pinot 打出 1.6.0 RC1，把「这次结果是不是近似的」从隐性事实改成响应里一个显式字段，代价是 DataTable 与 StatMap 两侧的混合版本限制被逐条列出：broker 必须先升、任意 server canary 不安全、过渡期这个字段还不完整。四处动作的收益也都带各自的边界：dry run 抓不到逻辑错误、跨区授权要先把身份铺到每个区域、托管摄取的账单按页与按图走、近似上报在服务器升完之前只能当不完整信号读。

Databricks 用 528 条 agent 管道给声明式标价：集群时间降约 34 倍，token 涨约 2.3 倍

事件概述

10 月 23 日，Databricks 发布《Built for Agents: The Case for Spark Declarative Pipelines》，作者 Lisa Cao 与 Sudhanva Huruli。文章没有宣布新端点，而是一次带完整可复现材料的基准测试：同一个 agent、同一批任务，分别用过程式 PySpark 与 Spark Declarative Pipelines（SDP）写管道，然后把两种写法在「什么时候暴露错误」「花了多少计算」「代码有多少行」三个维度上放在一起比。

测试的规模是 528 次构建：22 个数据工程任务 × 12 份输入数据集 × 2 种写法。每个任务长得像一张真实的工单，描述问题并规定输出表的表名、列名与数据类型；每份数据集都掺了生产环境里那种脏值。模型统一用 Opus 4.8。构建失败的可以让 agent 修订重试，但次数有上限。判定输出的自动 grader 不知道结果来自哪种写法。

背景是 agent 已经写下了相当比例的生产管道——文章给出 Databricks 上超过 70% 的 SDP 管道现在由 agent 创建。这让两件事的权重陡然上升：agent 每一次尝试都要花计算和时间，迭代必须便宜；代码审查成为关键闸门，代码必须短、可读、正确。

技术解析

  • 过程式与声明式的分界线在「能不能先读一遍」：过程式代码告诉 Spark 每一步怎么建数据集，唯一能验证它的办法是跑一遍；声明式代码描述的是「要哪些数据集」，交给 Spark 决定怎么建，于是 Spark 可以在运行前回答三类问题——每个列引用都能对照它所读取的数据集的 schema 解析出来、每个数据集之间的依赖都能在图上找到生产者、整张图的完整性与执行顺序由引擎判定而不是听信模型碰巧写下的先后顺序。
  • 运行前验证换来的集群时间差：过程式没有任何执行前阶段，结构性错误只能靠把管道跑在集群上直到撞上出错那一步才发现。测得过程式运行用了 596 executor-seconds，声明式用了 17，比值约 34 倍。单次失败的过程式构建最多烧掉约 521 executor-seconds，被 dry run 拒掉的声明式构建约 0.5 executor-seconds。
  • 代码量减半，写法也更收敛：完成构建中声明式的中位行数是 64 行，过程式是 131 行，少约 51%；AST 小约 44%。过程式的实现分歧更大——同样的任务，有的用 Spark transformation，有的把数据装进内存逐行处理，后者在测试集上能过，数据一大就会失败，全基准里有 19 个过程式构建走了这条捷径，声明式一个都没有。
  • dry run 抓不到的事，两边打平：静默错误（跑得干净但答案错）过程式 73/264（27.7%），声明式 85/264（32.2%），差距在约 15% 以内，文章明确说小到不成为真实差异。声明式让结构性错误变便宜，对逻辑错误无能为力，那部分仍要靠测试和审查。
  • 代价写在账单的另一栏：声明式 agent 会在 dry run 上反复迭代，把思考提前花在 token 里，中位构建约 $0.50，过程式约 $0.26（Opus 4.8 牌价），约 2.3 倍。文章的论点是这两栏性质不同——token 是一次性的固定支出，不随数据量和运行次数变化；浪费掉的集群计算每次坏构建都会重来一遍，而且随数据量增长。
  • 验收门槛不在模型这一侧：FAQ 里写得很直接，声明式 agent 只写描述，检查这个描述的是 Spark 自己，属于平台的一部分，agent 本身既不执行代码也不读用户的数据。作者把这个形状的适用范围也一并划开：SQL 本身、基础设施即代码工具、schema-first API 都有同样的结构，SDP 只是他们实测的那一个。

行业影响

这份基准的价值不在「声明式更好」这个结论——那是行业里已经讲了十年的老话——而在于它把这条老话换算成了 agent 时代的一组可核对数字。过去选型时人们比的是表达力与学习曲线，现在多了一栏：一次失败尝试的单价。当写管道的主体从人换成 agent，迭代次数从几次变成几十次，「错误在哪一阶段被发现」直接从工程偏好变成成本项。

对平台方的启示更具体：谁能提供一个便宜的执行前检查，谁就能把 agent 的试错成本从集群侧挪到 token 侧，而 token 是价格下行、集群是价格刚性的一次性买断。这也解释了为什么近期几家厂商都在往「可校验的描述」上加码——dbt 的 manifest、Iceberg 的元数据层、SDP 的 dry run，是同一件事的不同切片。

需要守住的边界是那 27.7% 与 32.2%：dry run 只在结构性错误上有优势，逻辑错误两侧一致。把声明式当成正确性保证来用会翻车，它买到的是「不会为一个注定跑不通的管道付集群钱」，不是「跑通就对了」。

相关链接

AWS 让 Lake Formation 的细粒度授权跨区跟着人走：目录与数据留在生产区，只让查询跨过去

事件概述

10 月 23 日，AWS Big Data Blog 发布《Enable cross-Region fine-grained data access with AWS Lake Formation and Trusted Identity Propagation》，作者 Maneesh Sharma、Laura Reith、Sri Pooja Ravipati 与 Songzhi Liu，级别标为 Advanced (300)。这是三篇系列的第一篇，本篇覆盖 SageMaker Unified Studio（Athena 与 Redshift），第二篇讲 Quick，第三篇讲 EMR。

要解决的问题是两套需求叠在一起：一是细粒度访问控制，每个人只能看到他被授权的数据；二是可审计到人，每一条查询都要追到具体的人而不是一个共享的 IAM 角色。IAM Identity Center 的 Trusted Identity Propagation（TIP）原本只解决单区域内的这件事——用户一次登录，身份从客户端应用穿过查询引擎到 Lake Formation 与存储层，每个请求都以真实用户身份授权，每条查询在 CloudTrail 里留名。这次的扩展是：IAM Identity Center 把它的人物对象（用户、组、会话信息）复制到你选定的每一个区域，于是跨区域的各层服务也能认出同一个身份。

演示拓扑用了三个账号三个区域：生产方在 ap-southeast-2（悉尼）跑 S3、Glue Data Catalog、Lake Formation 与 Redshift Serverless；消费方在 sa-east-1（圣保罗）查询；IAM Identity Center 跑在管理账号的 us-east-1。

技术解析

  • 跨的是查询，不是数据：两个案例共用同一个区域切分——目录与数据始终留在生产区，客户端与查询从消费区发起。Case 1 是 S3 数据由 Lake Formation 治理、经 Athena 查询；Case 2 是 Redshift 数据以 datashare 注册进 Glue Data Catalog、经 Redshift Serverless 查询。文章把这一点单独拎出来讲：正是「目录和数据在一区、客户端和查询在另一区」这个切分才让它成为真正的跨区域，而不只是跨账号。
  • 两条引擎的落地路径不同：S3 路线下，跨账号的 Lake Formation 授权一律在生产区做，唯一的例外是资源链接（resource link）与它的 Describe 授权，要在消费区的查询区域创建；消费方拿到的是指向共享数据库的资源链接，查询起来像本地表。Redshift 路线下不需要资源链接，消费方改为在 Redshift 里建一个外部 schema，直接引用生产方区域的 Glue Data Catalog。
  • 同区域约束只压在 Redshift 这一侧：Athena 跨区域查询没有额外限制；Redshift datashare 则要求查询引擎必须与 Redshift namespace 处在同一区域。这是选引擎时要先算进去的一条。
  • 前置条件是这次发布真正的门槛：生产方与消费方账号必须在同一个组织内，且共用同一个组织实例（organization instance）的 IAM Identity Center——跨账号共享本身可以跨组织，TIP 集成不行。身份要事先复制到每一个用到的区域，生产方 Lake Formation 目录设置里的「Use only IAM access control」要清掉。
  • 注册角色的细节藏着坑：给 Lake Formation 用的注册角色必须自带 sts:SetContext，不能用 Lake Formation 的 service-linked role，后者不含这个权限。
  • 收益的具体形态：因为授权是拿用户的 IAM Identity Center 身份判定而不是拿他代入的 IAM 角色判定，得到的是最小权限访问、CloudTrail 里的逐用户审计，以及一个集中管理权限的地方。要加更多消费账号或查询区域，就把消费侧步骤重做一遍。

行业影响

把身份平面做成跨区域复制的基础设施，是把「数据不动」这件事往前推了一步。此前跨区域分析的主流做法要么复制一份数据、要么在消费侧重建一套权限模型，两者都会引入第二份真相。这次的切法是让目录、数据与授权判定全部留在生产区，只把查询放出去——代价是身份必须先铺到每个区域，且整个链路上的服务都得支持 TIP。

对有多区域数据驻留要求的组织，这条路的价值高于它的复杂度：数据驻留的合规性通常由存储位置决定，而治理的一致性由目录位置决定，两者都留在生产区意味着合规论证只需要做一次。真正的落地成本不在配置步骤，而在「同组织 + 同组织实例 + 全区域复制」这三项前置条件，以及逐服务核对 TIP 支持范围。

值得留意的是系列的后两篇覆盖 Quick 与 EMR，也就是把 BI 层与自建计算层也接进来。若这两篇如期发布，AWS 的这套组合会从「跨区域查询」长成「跨区域的数据访问平面」，与 Databricks 的 Unity Catalog、Google Cloud 的跨云湖仓在同一道题上给出不同解法。

相关链接

Amazon OpenSearch 把 RAG 摄取管道折叠成一次托管调用，并把单价摊在页面上

事件概述

10 月 23 日，AWS Big Data Blog 发布《Build RAG-ready indexes from Amazon S3 with Amazon OpenSearch intelligent ingestion》，作者 Hang Zuo 与 David Venable，宣布 Amazon OpenSearch intelligent ingestion 在 OpenSearch Serverless (NextGen) 集合上可用。产品定性是全托管、serverless 的摄取能力：从集合出发，指向 S3 上的数据，选好处理方式，剩下的由它做完——发现内容、解析文档、描述图片、切块、生成向量嵌入、写入索引。

它替代的是一条通常要搭数周的多段管道：先跑文档解析器抽取文本并保住版面、阅读顺序与表格，再解释文档里的图表、示意图与截图，然后切块、过嵌入模型、写进向量索引。每一段都有自己的基础设施、扩容决策与失败模式。

入口是 OpenSearch Serverless 控制台上新加的 Ingestion 标签页，指定源（S3 桶与前缀）和目标（集合里的索引）两项即可。支持 PDF、Word、Markdown 等 unstructured 数据，也支持 JSON、NDJSON、JSON array、CSV 等 structured 数据。

技术解析

  • 五步流水线全部托管：数据发现（扫描 S3 前缀；Ingestion Stream 走 SQS 通知感知新对象）、文档解析（PDF 与 Word 保留标题、阅读顺序与表格）、图像理解（视觉语言模型给图写详细文本描述，让只出现在图里的信息也能被检索到）、切块与嵌入（按检索粒度切块，用 OpenSearch Automatic Semantic Enrichment 生成向量）、写入索引（在集合组预设的 OCU 上限内自动扩缩）。
  • 两种运行形态、三种模式：Ingestion Job 用于一次性或周期性加载（迁移、回填、POC），跑完前缀下所有对象即结束并自动终止计费；Ingestion Stream 用于持续同步。配置模式是 One-time batch、Continuous streaming，以及先把存量灌进去再转持续的 Batch then stream；Backfill then stream 还允许回填桶与增量桶分开指定。
  • 跨账号要交出四样东西：同账号下可以直接浏览选择桶；跨账号则需要提供对方账号 ID、S3 桶、要代入的 IAM 角色 ARN，以及可选的该账号内的 SQS 队列。
  • 单价被拆成三栏写在文中：结构化数据按标准 OCU 计费，作业结束即停；非结构化数据要额外走一个 serverless indexing OCU，示例价 $0.24/小时（us-east-1），内部测试下一个额外 OCU 每小时处理 600 页 PDF，折合每 1,000 页约 $0.40；图像理解走 Bedrock 上的 Nova 2 Lite，按 Bedrock 公开价 $0.30/百万输入 token、$2.50/百万输出 token，内部测试下每 1,000 张图平均消耗 0.5M 输入与 0.5M 输出 token，折合约 $1.40。
  • 可用性边界明确：当前只有 Amazon S3 一个数据源，只在六个受支持的 AWS 区域可用。

行业影响

这条发布的意义是把 RAG 落地里最不具差异化、却最耗工程量的一段——文档摄取——变成按量购买的商品。过去一个团队要自建解析、版面保留、图表理解、切块、嵌入五段链路，其中「图表理解」这一段尤其难自己做，得接多模态模型并按页调度。现在它变成一次 API 调用，价格以每千页、每千图为刻度公开出来，团队可以直接把这个数字放进 TCO 里跟自建方案比。

把成本结构摊开这件事本身值得注意。$0.40/千页与 $1.40/千图这两个数让「知识库上线要花多少钱」第一次变成可预估的乘法题，而不是一句「取决于你的文档量」。对文档量小但种类杂的场景，这个价格几乎必然低于自建；对每天新增百万页的场景，自研解析加自管嵌入仍有成本空间，但要把运维人力算进去才公平。

另一个值得观察的点是 OpenSearch 把自己的位置从「检索引擎」前移到了「摄取 + 检索一体」。这与 BigQuery 的 ObjectRef、Databricks 的 Lakeflow 是同一类动作：各家都在争「非结构化数据进入可检索状态」这一段的入口，谁占住这段，后面的向量索引、混合检索与 agent 调用就都在自己的边界内发生。

相关链接

Apache Pinot 1.6.0 RC1：把「这次结果是不是近似的」写进响应字段，并摊开混合版本限制

事件概述

10 月 23 日 04:05 UTC，apache/pinot 打出 release-1.6.0-rc1 标签。距 rc0（10 月 17 日）六天，本版相对 RC0 只有四项改动，但四项都落在正确性与可观测面上，其中一项直接改了响应字段名。

四项分别是：Lucene 回滚恢复（在段加载期间从保留的原始前向索引值重建不兼容的 text 与 HNSW 索引）、遗留表配置弃用标注（为 16 个遗留属性记录弃用版本、替代指引与移除意图）、近似上报改名（把 RC0 的 approximateFunctionApplied 换成 approximatedResult）、条件聚合正确性（把多阶段近似重写挪到 CASE-to-FILTER 转换之后执行，以保住条件去重计数在配置近似参数时的 NULL 语义）。

发布说明里单独开了一节写 SMART 聚合的混合版本限制，逐条列出升级顺序、canary 与降级的边界，以及在服务器升完之前这个新字段只能当不完整信号读。

技术解析

  • Lucene 回滚恢复是给未来升级准备的：段加载时若发现 text 或 HNSW 索引不兼容，就从保留下来的原始前向索引值重建；兼容的索引直接复用；缺了恢复源则在替换索引之前就失败。Lucene 版本维持 9.12.0。用法有前提——要在回滚目标上先装这个恢复版本，并保留原始前向索引。重建会带来额外的 CPU、I/O 与加载时间。Backport #19976，上游 #19900。
  • 近似上报的语义被改准了：RC0 的 approximateFunctionApplied 报的是「有没有发生重写」，approximatedResult 报的是「SMART 聚合这次是否真的产出了近似结果」，包含查询里显式写出的 SMART 函数。配套的 broker meter 是 BROKER_RESPONSES_WITH_APPROXIMATED_RESULT，查询日志字段名同样是 approximatedResult。永远近似的函数不置这个标记。旧名字只出现在未正式发布的 1.6 周期内。#19972。
  • 条件去重计数的 NULL 语义修在顺序上：多阶段近似重写现在跑在 CASE-to-FILTER 转换之后，避免转换前的近似重写破坏条件去重计数对 NULL 的处理。自动近似重写默认仍然关闭。#19977，上游 #19974。
  • 遗留属性只加标注、不改行为：16 个遗留表配置属性现在带上弃用版本、替代方案与移除意图。Backport 只动注解与 Javadoc，运行时的接受行为与 JSON 兼容性不变。#19978，上游 #18411。
  • 混合版本限制是这次最需要读的一段：近似上报给 DataTable 加了元数据、给 StatMap 加了键，老读端无法安全跳过。风险发生在 SMART 聚合真的转为近似时，包括查询里显式写 SMART 函数的情况——把自动重写关掉并不能保护显式 SMART 查询。具体要求：DataTable 路径要先升 broker 再升 server，老 broker 收到新的最终结果元数据可能读错后续元数据或直接 BufferUnderflowException；只按 broker 优先的顺序升级不足以让任意 server canary 或降级变安全，多阶段路径上老的 StatMap 读端遇到新 ordinal 会丢掉这条查询的统计信息，含 numGroupsLimitReached；老 server 不产出新元数据，过渡期内新 broker 可能对一份由 sketch 得出的结果报 approximatedResult=false，该字段在相关服务器升完之前要当不完整的看。
  • 1.6.0 相对 1.5.1 的主线：SQL DDL（CREATE/DROP/SHOW TABLES、SHOW CREATE TABLE 经控制器的 /sql/ddl 端点；物化视图获得 DDL 与单阶段查询重写支持）、分析能力（GROUPING SETS、ROLLUP、CUBE 在两个引擎上都支持；多阶段新增流式去重执行与 lookup join 规划改进）、向量检索（在 HNSW 之外加 IVF_FLAT、IVF_PQ、IVF_ON_DISK，带 filter-aware 搜索、半径查询与后端调优开关）、数据形态（OPEN_STRUCT 应对演进中的嵌套数据、逻辑 UUID 类型、Arrow IPC 批量摄取、BSON 输入）、可靠性（NULL 感知过滤改进、失败或取消时的多阶段缓冲清理、Kafka offset 的事务化处理）。

行业影响

把一个内部状态提升成响应字段，看着是小改动，实际是在给「结果可信度」这件事一个可观测的接口。近似计算在 OLAP 引擎里用了很多年，问题是调用方拿到的结果里没有任何标记说明它是精确的还是从 sketch 估出来的，于是下游只能一律当精确值用。approximatedResult 把这个判断从「读的人自己知道查询是怎么写的」变成「响应里写着」， broker 侧还有对应的 meter 可以做聚合监控。

发布说明里那一节混合版本限制，是这轮更值得被别的团队抄走的部分。多数项目写兼容性只会写「建议先升 broker」这类单向指引，Pinot 这次把三种具体风险分别讲清：哪种组合会抛异常、哪种组合会静默丢统计、哪种组合会让新字段给出假阴性，并且明确说了「broker 优先升级不足以让任意 canary 或降级变安全」。对已经在用 SMART 聚合的集群，这等于一份升级前必须逐条核对的清单。

Lucene 回滚恢复那一项的思路也值得注意：它不是修一个 bug，而是为一次尚未发生的升级预先铺退路——保留原始前向索引值，让索引格式不兼容时能重建而不是丢弃。这是把「升级不可逆」改成「升级可逆且重建成本已知」。

相关链接

编者评

把本期四条放在一起看，指向的不是某项技术，而是一种定价方式的变化。过去做架构决策，人们比的是功能与性能；这四条动作共同的地方是，它们都在把一项此前无法计价的东西换算成可写进表格的数字，并把换算之后的代价主动摊出来。Databricks 给的是「一次失败尝试值多少钱」——596 executor-seconds 对 17，以及对应的 2.3 倍 token 溢价；AWS 给的是「一页 PDF、一张图进索引值多少钱」——$0.40 与 $1.40；Pinot 给的是「一次近似结果的判定由谁负责」——从调用方自己负责改成响应字段里写着，代价是三种混合版本风险要逐条验收；Lake Formation 那条给的是「跨区域但数据不复制」这条路的入场费——同组织、同组织实例、身份复制到每个区域，外加 Redshift datashare 必须同区。

对 DataInfra 从业者，这四条里有三条是可以立刻拿去用的判据。选型声明式框架时，把「有没有执行前检查」和「一次失败的单价」一起问；评估托管摄取时，用 $0.40/千页这个量级去核自建方案的机器时与人天；升级 Pinot 时，先按「broker 先于 server、不做任意 server canary、过渡期不把 approximatedResult=false 当精确读」这三条排顺序。第四条则更像一个方向信号：当身份平面可以跨区域复制，数据驻留与治理一致性就不再互相排斥，「数据不动、查询动」从一句原则变成可配置的架构。

需要说明的仍是中文源的状况。本轮继续扫描了阿里云国际站博客、阿里云开发者社区、火山引擎文档站与开发者社区四个入口，均返回 200，但 10 月 23 日至 24 日的时间戳命中数为 0，无法确认任何一条带日期的新发布。这是本专栏连续第二十一期遇到同一情况，已改以中国背景开源项目的版本号快照作间接观察：Doris 仍停在 4.1.5、Paimon 仍停在 2.1.0、Hudi 仍停在 1.1.2、Amoro 仍停在 0.8.1-incubating、Kyuubi 仍停在 1.12.0、Linkis 仍停在 1.8.0、InLong 仍停在 2.4.0-RC0，MatrixOne 最新为 v4.2.6-hotfix-20261021。

其余必扫源在 10 月 23 日至 24 日窗口内无新条目或无可确认日期：Databricks 另有《Real-time energy trading and analytics on Databricks》（10 月 23 日，行业解法，非技术发布）；GCP 数据分析博客最新仍为 10 月 22 日；AWS what’s new 部分无数据基建相关条目；Data Engineering Weekly 最新仍为 10 月 19 日；Flink 博客最新仍为 10 月 10 日的 CDC 3.7.0；Dremio 最新仍为 10 月 12 日；The New Stack 返回 403；Anyscale、Daft、Trino 博客、dbt 博客、Delta Lake 博客、a16z 无可确认的新条目。版本快照方面，Lance 仍为 v15.0.0-beta.1 与 v14.0.0-rc.2、LanceDB 仍为 v0.41.0-beta.13、DuckDB 仍为 v2.0.0、Qdrant 仍为 v1.20.0、Ray 仍为 2.58.1、Daft 仍为 0.7.26、Trino 仍为 484、Iceberg 仍为 1.12.0、Delta Lake 仍为 4.4.1、Milvus 仍为 3.0.3、Arrow 仍为 26.0.0、Beam 仍为 2.77.0、Superset 仍为 7.0.0rc2、dbt Core 仍为 v2.0.8 与 v1.12.6；ClickHouse 于 10 月 23 日发布 v26.3.60.2-lts，Weaviate 发布 v1.36.24，两者 release body 为空，留待有 changelog 材料时再展开。