Spark 4.3.0 正式发布并开启季度发布节奏,流式 shuffle 三部件进主线、AQE 与归档读取一并落地;Flink Agents 0.4.0 定位 1.0 前最后一个预览版,补齐子代理、决策模型与模型路由并主动清偿 API 债;Databricks 与 SAP 把 Genie、Lakeflow、Unity Gateway、Lakebase 规划整体搬进 SAP Databricks,ERP 数据经 Application Data Foundation 零拷贝直连湖仓;AWS 给 SageMaker Unified Studio 上线 Cedar 支撑的 designations,项目内最小权限成为一等原语
本期聚焦 10 月 30 日一天之内的四条动作,两开源两商业,各自动的是同一个部位:交付单元。Spark 用季度化版本节奏把流式 shuffle 基建开进开源主线;Flink Agents 在承诺 API 兼容之前先清债;Databricks 与 SAP 把抽取管道换成零拷贝的语义数据供给;AWS 把权限定义从项目边界下沉到项目内部。
本期四条动态全部落在 10 月 30 日这一天,两条来自 Apache 开源社区,两条来自商业平台,改的都是各自栈里的交付单元。Spark 4.3.0 正式发布,距 7 月 14 日的 4.2.0 约三个半月,是版本策略改为季度 feature release 后走完的第一个版本,流式 shuffle 的线协议、管理器与调度器改动以三个部件进主线,代价是这一版只承诺增量特性、不升第三方依赖;Flink Agents 0.4.0 发布,官方明确这是 1.0 前最后一个计划版本,子代理、决策模型、模型路由、多模态输入一并补齐,代价是 0.3 到 0.4 带来历来最大一批破坏性变更,Action State Store 数据直接不兼容;Databricks 与 SAP 在 SAP TechEd 期间宣布扩大合作,新发布的 SAP Application Data Foundation 让云上与本地的 SAP 应用数据零拷贝进入 SAP Databricks,Genie、Lakeflow、Unity Gateway、Lakebase 规划整体带入,代价是这条路绑定在 SAP Business Data Cloud 的产品形态上;AWS 给 SageMaker Unified Studio 上线 designations,用 Cedar 策略语言把项目内的权限差异化做成可复用、可自动化的原语,代价是治理模型要跟着 Cedar 的表达能力走。四个组件,四个层面,各自换轴。
Spark 4.3.0 发布:季度节奏的第一个版本,流式 shuffle 基建开进开源主线
事件概述
Apache Spark 官网 news 页在 10 月 30 日挂出 Spark 4.3.0 released。4.3.0 是一个 feature release,按项目 2026 年上半年确立的版本策略,x.y.0(y >= 1)类 feature release 每季度一次;4.2.0 在 7 月 14 日 GA 时被社区称为「季度节奏前最后一个大型功能发布」,本版是那次承诺的第一次兑现——三个半月,一个版本。JIRA 上 fixVersion 为 4.3.0 的 resolved issue 共 1186 条,其中 New Feature 与 Improvement 合计 284 条。
同一周还有一条容易被忽略的配套动作:10 月 27 日,维护线 4.2.1、4.1.4、4.0.5 三个版本同日发布。4.3.0 走特性、三条维护线并行收 bug,「一年一个 x.0.0 大版本、中间按季度送特性、老线按窗口维护」的节奏整体跑起来了。
技术解析
- 流式 shuffle 三部件进主线:这是本版最值得盯的一条线。
SPARK-56674加入流式 shuffle 的 wire protocol(Part 1);SPARK-57141加入 StreamingShuffleManager 与 MultiShuffleManager(part 3);SPARK-58263让 DAGScheduler 并发调度流水线式的 shuffle stage 组(Part 3)。三个 JIRA 都是 New Feature 类型。与 4.1 里已合并的实时读取接口合起来看,开源 Spark 在为连续执行、低延迟这条路径铺基础设施。本版还有SPARK-58386恢复SupportsRealTimeRead.nextWithTimeout的向后兼容——实时读取这条 API 线在被认真维护。 - AQE 与物理计划继续收紧:
SPARK-58084支持在 AQE 物理计划里把 sort merge join 转换为 shuffled hash join;SPARK-58004给 AQE shuffle 合并加了硬性的 reducer 分区扇入上界;SPARK-56903把 NULL 外连接键摊到多个 shuffle 分区,避免倾斜;SPARK-58233在 stage 内下推本地排序消除冗余排序;SPARK-43317支持合并相邻聚合。 - Python 链路换传输方式:
SPARK-56642引入 JVM 与 Python UDF 之间的流水线式数据传输,SPARK-58119抽出 PythonWorkerHandle 抽象收敛 worker 路径,SPARK-58234让 NumPy 的反双曲 ufunc 走原生函数。 - 数据源与函数面:归档读取成一条完整线——tar 包内 JSON、XML、Avro 的读取与模式推断(
SPARK-57419、SPARK-57479、SPARK-57481),7z 归档支持(SPARK-58246),binaryFile 的 wholeFile 选项(SPARK-58382);SPARK-56820新增counter_diff窗口函数,把累计计数器转成增量格式,监控与可观测场景的典型痛点;SPARK-57194给 Optimizer 加了 earlyOperatorOptimizationRules 扩展点。 - 运维与安全:
SPARK-58468让 Spark History Server 支持按需加载单个事件日志,大集群历史页的加载压力有了解法;SPARK-57261允许用配置关闭 HashAggregateExec;SPARK-59329给 Avro 的 schemaUrl 选项加了 URI scheme 白名单,堵住一类注入面。
行业影响
版本策略里写明的承诺值得引用原文:feature release 默认不升级第三方依赖(Parquet、Arrow、ORC、Hadoop、Netty),需要安全修复时才例外。对下游发行版与自建平台来说,这条承诺把季度升级的风险面从「依赖树全动」压到「Spark 自身增量」,是季度节奏能被接受的前提。
流式 shuffle 进主线的信号意义大于即时可用性。Databricks 前一天刚把 Real-Time Mode 在声明式管道上 GA,其连续执行路径依赖的那类 shuffle 基建,正以线协议、管理器、调度器三个部件的粒度在开源主线落地。商业平台先行验证、开源主线按季度跟进,这个时间差本身就是 Spark 生态当下的分工方式。对用户侧,4.4.0 按节奏应落在明年 1 月底到 2 月初,升级窗口的规划可以按这个预期做。
相关链接
- Spark 4.3.0 released(Apache Spark News, 2026-10-30)
- Spark Release 4.3.0 官方发布页
- JIRA: Spark 4.3.0 修复问题列表
- Apache Spark Versioning Policy
- Spark 4.3.0 文档
- Spark 下载页
- GitHub Release: v4.3.0
Flink Agents 0.4.0:1.0 前最后一个预览版,赶在承诺兼容之前把 API 债清掉
事件概述
Apache Flink 社区在 10 月 30 日发布 Flink Agents 0.4.0。这个子项目要做的事一句话能说清:把 AI agent 带进 Flink 流水线——应用持续响应实时事件,把 AI 处理与业务逻辑组合起来,执行、容错与恢复交给 Flink 的分布式运行时。0.4 的定位官方写得很直白:这是 1.0 之前最后一个计划版本,目标是让流式 agent 应用达到生产可用;本版仍是 preview,API 与配置仍在演进。
这一版最受早期生产用户与社区评审推动的改动,是赶在 1.0 开始保证 API 兼容之前,把该破的接口一次破完。升级 0.3 的用户要面对历来最大一批破坏性变更:Action 与跨语言声明更新、消息与模型响应及工具结果的表示方式变化、重试与并发默认值调整、更严格的参数校验;0.3 的 Action State Store 数据与 0.4 不兼容;Skill 下载与 shell 命令的限制也收紧了。
技术解析
- 子代理与委托:sub-agents 允许一个 agent 把任务委托给同作业内的其他 agent 或集成的外部 agent 服务,拿到结果后继续处理。委托可以显式写在代码里,也可以交给模型选择;调用支持 durable execution,录制的结果在恢复期可复用。
- 决策模型进流式场景:Decision Models 用 TypeSafe 的 Jev 这类模型,按定义好的业务准则评估应用上下文,返回类型化决策——概率、选择或打分。0.4 的统一 Decision Model API 支持 TypeSafe、OpenAI 与阿里云 Model Studio 三家,官方给的用例是内容分类、满意度打分、风险评估。
- 模型路由与多模态:Model Routing 按请求动态选模型,规则匹配、LLLM judge 或自定义逻辑皆可——常规请求走轻量模型,复杂任务走能力更强的模型,目前只在 Java 编程 API 提供。多模态消息把文本、图像、音频、文档合进单条消息,结构化输出扩展到主流模型提供商。
- 执行模型细化:新的
ctx.chatAPI 把模型调用与后续业务逻辑收进单个 Action,不再把请求与响应处理拆到两个 Action;框架代为执行模型请求的工具,支持重试与结构化输出。条件触发允许按事件字段选择处理步骤(交易超阈值才做额外检查,严重告警才升级);工具参数注入让应用直接供给已知参数,模型只生成需要推理的那部分。Java 异步执行从 JDK 21 扩展到 JDK 11 与 17。 - 可观测性成体系:Trace Log 扩展 0.3 的 Event Log,记录执行步骤、模型调用、工具调用、子代理调用及其血缘,配套工具可把事件血缘可视化为树;内置指标覆盖输入处理成败、积压、排队与执行延迟、对模型与工具的调用量,接入既有 Flink 监控。
- 生态动作:新增 flink-agents-dev Skill,给编码 agent 提供 Flink Agents 的构建、修改与校验指引(
npx skills add 'apache/flink-agents#release-0.4@flink-agents-dev');模型集成新增 Gemini(Java)、vLLM 与 IBM watsonx.ai(Java 与 Python)、OpenAI embeddings(Java)。
行业影响
流处理引擎做 agent 运行时,Flink Agents 是目前走得最深的一个样本。它把 agent 工程里最难的三件事——durable execution、行为可观测、模型治理——直接映射到 Flink 已有的 checkpoint 恢复、指标体系与运行时管理上,而不是另起一套。0.4 的清债动作说明 1.0 之后社区要对 API 兼容性负责,现在是用一次大破坏换后面的稳定承诺,节奏判断是对的。
另一个值得注意的细节是那个给编码 agent 用的 Skill。agent 框架自带「教编码 agent 使用自己」的物料,工具与框架的边界正在被 agent 生态自己的习惯重塑——这比任何一份路线图都更直白地说明了消费这些框架的主力人群正在换成谁。
相关链接
- Apache Flink Agents 0.4.0 Release Announcement(2026-10-30)
- Flink Agents 文档
- apache/flink-agents(GitHub)
Databricks 与 SAP 扩大合作:ERP 数据经 Application Data Foundation 零拷贝进湖仓,Databricks 全家桶搬进 SAP Business Data Cloud
事件概述
Databricks 在 10 月 30 日发文宣布与 SAP 扩大合作,时机在 SAP TechEd 期间。核心是新发布的 SAP Application Data Foundation:SAP 应用数据(云上与本地)以云原生方式提供给 SAP Business Data Cloud 的各引擎,包括嵌在其中的 SAP Databricks。去年双方发布的 SAP Databricks 把 Databricks 平台原生嵌入 SAP Business Data Cloud,GA 以来 Adidas、Zalando、Mondi、CAF 等客户已经在用零拷贝、双向的 OpenSharing 分析并治理活的 SAP 数据产品;这一步把「进来之后能干什么」的答案从数据仓库扩展到了整个 Databricks 平台。
文章给的问题定义很清楚:今天的模型能力已经够强,缺的是业务上下文,而企业的业务上下文大部分活在 SAP 系统里——官方引用的数据是超过 90% 的 Fortune 500 公司用 SAP 管理核心业务流程。过去访问 SAP 应用数据要自建并维护定制抽取管道,拷贝数据、丢失业务语义、治理被切碎,这正是这次要拿掉的东西。
技术解析
- 抽取管道的替代方案:SAP 数据产品通过 SAP BDC Connect 零拷贝共享给 SAP Databricks,不建额外管道、不做数据复制、不产生新孤岛。数据工程师直接在 SAP 业务语义上构建分析——模型反映的是业务真实的运转方式,而不是抽取后的残影。
- 平台能力规划整体进入:Genie(自带企业上下文的 AI 同事,计划与 SAP 的 Joule 做双向集成)、Lakeflow(统一数据工程,把 SAP 数据与 IoT、CRM、第三方源组合建管道)、Unity Gateway(跨 agent、工具、模型与 MCP 的多 AI 治理与成本控制)、Lakebase,规划以完整形态进入 SAP Databricks。
- 本地 ECC 场景:文章给了一个具体例子——制造商在本地 SAP ECC 上跑财务与供应链,用 Application Data Foundation 把多年订单历史带进 SAP Databricks,数据工程师叠加第三方数据建需求预测模型,业务上云之后这些工作原样保留。
行业影响
ERP 数据是「语义密度」最高的一块企业数据,也是 AI 落地最卡的那一块——卡点从来不在模型,在上下文获取的管道成本。零拷贝加语义数据产品这条路,把管道的长期维护成本换成了平台绑定:SAP 数据的入口收窄到 SAP Business Data Cloud 这一个产品形态,Databricks 的能力以嵌入方式进入,两家各让渡了一部分边界。Unity Gateway 进 SAP BDC 这条值得单独记一笔:agent 治理(工具、模型、MCP 的权限与花费控制)开始被当作数据治理的自然延伸,而不是一个独立的安全品类。
相关链接
AWS 给 SageMaker Unified Studio 上线 designations:项目内的最小权限,Cedar 支撑,随自动化走
事件概述
AWS 大数据博客在 10 月 30 日发文讲 SageMaker Unified Studio 的 designations 能力怎么用。问题定义同样直白:一个 Unified Studio 项目里往往聚着数据工程师、数据 steward、分析师与 ML 工程师,访问需求天差地别——steward 不该动生产管道,分析师不该起高成本计算,跑定时 ETL 的服务账号不该与做探索实验的人共享权限。过去的两个常见解法都有代价:给所有人同一个宽泛项目角色,权限失控;按角色拆成多个项目,数据被项目边界切碎,成员管理开销随团队规模膨胀。
designations 的做法是把权限定义与成员分配拆开。域管理员一次定义一个 designation——从细粒度权限里勾选,比如发布资产、创建数据产品、批准订阅,权限按 Catalog、Project、Subscriptions、Connections、Notebooks 分类,底层由 Cedar 策略语言支撑;项目所有者在项目内给每个成员分配一个 designation,成员也可以通过 SSO 组成员身份继承。
技术解析
- 三类典型场景:notebook 三档访问(完全、只读、无)把高成本的交互式计算限制到该负责的角色,直接对应成本控制;探索用户拿读与浏览权限、生产服务账号跑定时工作流,两类人共存于同一项目,数据不用为权限让路;数据 steward 的订阅审批与元数据管理职责由指定 persona 承担,其余成员绕不开审查流程。
- 自动化闭环:文中引了 Swiss Life Germany 云平台架构师 Tim Kopacz 的用法——项目创建、成员从目录同步、数据源注册全自动化之后,唯一不能自动化的曾是「每个人进来之后能做什么」;designations 把每个用户类型的权限定义并进创建项目的同一套自动化,权限从第一天起就到位。
行业影响
数据平台的权限粒度正在从「谁能进这个项目」细化到「进来之后每个动作能不能做」。Cedar 作为可编程的策略语言撑在底下,意味着这套权限模型可以版本化、可以进 Git、可以随基础设施代码一起评审——这与数据产品架构里生产者、消费者、steward 的角色分工正好对齐。当 agent 开始以服务账号身份跑管道、调工具,项目内动作级别的最小权限就不再只是合规要求,而是成本与爆炸半径控制的实际手段。
相关链接
- Implement least-privilege access with designations in Amazon SageMaker Unified Studio(AWS Big Data Blog, 2026-10-30)
- cedar-policy/cedar(GitHub)
编者评
四条动态同日落地,指向同一个问题:AI 负载成为数据基础设施的第一等公民之后,各栈在重新划定自己的交付单元。Spark 的回答是节奏——季度化版本把流式 shuffle 这类底层基建按固定节拍送进开源主线,商业平台先验证、开源跟进的时间差成了生态分工本身;Flink 的回答是承诺——赶在 1.0 保证 API 兼容之前把债一次清完,agent 运行时被建模为流处理问题而不是独立品类;Databricks 与 SAP 的回答是数据面——AI 最缺的业务上下文从自建管道去取,换成平台原生供给,管道维护成本换了平台绑定;AWS 的回答是治理面——权限从项目边界下沉到项目内部的动作级别,随自动化走。执行层、运行时、数据面、治理面,四个层面各自换轴,共同的前提只有一个:基础设施的每个组件都在重新回答「为谁服务、以什么节奏交付、边界画在哪里」。观察下一期的坐标也在这里——Spark 4.4.0 是否按季度承诺落地、Flink Agents 1.0 何时定型,将检验这两套新节奏的可信度。