Amazon EMR 给 Spark 4.1 开出 36 个月 LTS；Kinesis 用服务端托管分区键换掉客户端分片路由；火山引擎 LAS 用 ZoneMap 逻辑分区撑住十亿级多模态湖；S&P Global 把一整个数据资产切成一组 Genie Agent 再合并成 MCP 端点

本期四条分属托管 Spark 的发布策略、流摄入的分区机制、多模态湖的维护闭环与企业数据的对外供给方式，动作却落在同一个位置上：把原本由使用者自己分配的决策收进系统。EMR 把「什么时候升级」从一个跟随上游的判断题变成一条 36 个月的时间窗；Kinesis 把「记录写到哪个分片」从客户端的分区键约定改成服务端按预热容量分派；火山引擎 LAS 把「哪些数据要跳过、哪些 Fragment 该合并」交给 ZoneMap 与一段增量闭环；S&P Global Energy 把「哪张表对谁开放」交给懂业务的专家，工程侧只留一层薄代理。四处收拢都换走了一些东西——LTS 只覆盖三类修复且要看可用性，Kinesis 让出的是顺序保证，ZoneMap 是保守过滤器，复合 MCP 端点的路由正确性靠命名前缀兜底。

Amazon EMR 引入 LTS：Spark 4.1 拿到 36 个月支持，Iceberg v3 与按名引用 catalog 一起落地

事件概述

9 月 22 日，AWS 宣布 Amazon EMR 引入长期支持（Long Term Support）发布通道，首个 LTS 版本是 emr-spark-8.1.0，对应 Apache Spark 4.1。按官方表述，被指定为 LTS 的 AWS Runtime for Apache Spark 版本获得 36 个月支持，期间提供针对 critical 与 high 级别的安全、缺陷和数据损坏问题的修复，且不额外收费。该版本在 Amazon EMR 可用的全部区域上线，覆盖 EMR on EC2、EMR on EKS 与 EMR Serverless 三种部署形态；迁移现有应用可以用 Apache Spark Upgrade Agent for Amazon EMR。

对以季度为单位规划集群升级的团队来说，这条通道改变的是升级的触发条件：过去 Spark 版本跟着上游与 EMR 版本节奏走，现在可以在一个版本上停留更久，按自己的排期决定何时动。

技术解析

• Iceberg v3 完整支持：emr-spark-8.1.0 补齐 Apache Iceberg v3，带来 geospatial 类型、高精度 timestamp 与增强的 schema evolution 能力。
• 按名引用 catalog：Spark SQL 可以直接按名字引用 catalog，包括跨账号 catalog 与 Amazon S3 Tables catalog；引擎自动识别 Apache Iceberg、Delta Lake、Apache Hudi 三种表格式，不再需要在 Spark 配置里逐个注册 catalog。
• 细粒度权限扩面：列级与行级权限覆盖到更多 Apache Iceberg 操作，以及 Delta Lake 的 VACUUM 操作。
• 同批发布的 EMR 7.14：Spark 升至 3.5.8、Iceberg 升至 1.10.1；Iceberg 物化视图在含 update 与 delete 的表上刷新更快，改用 change data capture 只读取受变更影响的数据文件；EMR Serverless 上 Spark 作业的存储上限从 200 GiB 提到 1 TiB，给 shuffle 数据留出空间；EMR on EKS 支持带 token 认证的 Spark Connect endpoint，并可在 IPv6 的 EKS 集群上运行。
• 支持范围的表述：官方措辞是「subject to availability」，即修复的提供并非无条件承诺。

行业影响

托管 Spark 过去最主要的运维成本之一是版本跟随：上游一发新版，平台侧很快提供，用户就得在自己的发布节奏与上游节奏之间做取舍。LTS 把这条链路切开，让生产负载停留在一个被明确标注支持期限的版本上，功能演进继续发生在非 LTS 通道。

代价也很清楚：36 个月覆盖的是 critical 与 high 三类问题，不是全部缺陷，更不是功能回移；「subject to availability」这一句意味着个别修复是否提供仍需逐案确认。另一层变化在 catalog 侧——按名引用加上三种格式自动识别，把格式差异从 Spark 配置里挪到 catalog 层处理，格式的边界没有消失，只是换了个地方声明。

相关链接

• Amazon EMR introduces Long Term Support with Apache Spark 4.1
• Amazon EMR 7.14 is now available
• emr-spark-8.1.0 release notes

---

Amazon Kinesis Data Streams 的 Service-Managed Partition Keys：不再由客户端决定分片

事件概述

9 月 23 日，Amazon Kinesis Data Streams 宣布支持 service-managed partition keys，适用于 On-Demand Standard 与 On-Demand Advantage 两种流。开启之后，客户在发布记录时不再需要指定 partition key，服务端按当前可用的预热容量（warm capacity）自动把记录分布到各分片上。该能力在所有 AWS 商业区域上线，不额外收费，升级到最新版 AWS SDK 或 Kinesis Producer Library（KPL）即可使用。

官方给出的目标场景是日志聚合、指标采集与 IoT 遥测这类不需要顺序保证、希望直接吃到预热容量以实现即时扩缩的负载。

技术解析

• 此前做法：客户通常生成随机分区键（例如 UUID）来打散数据。随机分区并不能保证均匀——分片之间仍会出现吞吐不均，某些分区键被限流，而此时流本身的聚合容量是够用的。
• 服务端路由：改为按可用 warm capacity 分布记录，客户不必再维护分布逻辑，也不必为了打散而额外加盐。
• 适用边界：官方明确把它定位在「record ordering is not required」的工作负载上；需要按 key 保序的场景仍要自己指定分区键。
• 覆盖范围：仅 on-demand 模式（Standard 与 Advantage），公告未涉及 provisioned 模式。

行业影响

热分区是流摄入里最古老的故障之一，过去的解法几乎都在客户端：改分区键的构成、加随机后缀、或者在写入侧做一层打散。Kinesis 这次把这件事收进服务端，等于把「如何打散」从一套客户端约定变成一项服务能力，客户端代码随之变薄。

交换出去的是控制粒度。分区键不再由业务语义决定，也就无法再用它来保证同一实体的顺序写入；按 key 保序与按容量均衡在这里是互斥的两种选择，选型时得先回答顺序到底需不需要。另外，服务端按 warm capacity 分布意味着吞吐表现与流的扩缩状态绑定，容量行为的观测重点从「我的分区键分布是否均匀」转到「流的预热容量是否跟得上」。

相关链接

• Amazon Kinesis Data Streams announces Service-Managed Partition Keys
• Amazon Kinesis Data Streams 产品页

---

火山引擎 LAS：用 ZoneMap 做逻辑分区，把 Lance 多模态数据湖的维护做成增量闭环

事件概述

9 月 24 日，字节跳动数据平台发布了《从三套系统到统一数据底座：火山引擎多模态数据湖的规模化实践》，内容摘自火山引擎数智平台技术工程师马进、孙鑫在 9 月 12 日 Lance 开发者沙龙（Lance Meetup）上海站的演讲实录。文章处理的是多模态数据进入十亿乃至千亿级之后的维护问题，给出了逻辑分区、增量维护与批量检索三处的具体做法，并附了实测数字。

文章列出的起点是「三类负载、三套系统」：数据预处理由 Spark、Ray 与传统湖格式承担；索引与检索要支持标量、全文、向量三类索引，用于样本回捞、语义去重与正负样本生产；训练侧需要高效的随机采样与高吞吐读取。三类要求不同，过去对应三套技术栈，同一批数据要在格式与系统之间反复搬运。Lance 的切入点是把结构化字段、图像、视频、音频、文本与向量放进同一个底座，上层接 Spark、Ray、LanceDB 与 ByteHouse。

技术解析

• ZoneMap 逻辑分区：传统物理分区按时间、地域等字段把文件放进不同目录，查询时跳过无关分区；一张表很难套用多套分区规则，微批写入与数据倾斜又容易产出小文件。Lance 侧更复杂——BTree、全文索引与 IVF 类向量索引各有组织方式，没有一种 Partition Spec 能一并适配数据文件与所有索引。LAS 的做法是基于 ZoneMap 构建逻辑分区：把 Fragment 中的数据划分为连续 Zone，记录指定字段的最小值、最大值与空值数量；查询时先判断谓词与值域是否相交，不可能命中的区域直接跳过，剩余候选再做精确过滤。同一份数据可以针对来源、入湖时间等字段分别建立 ZoneMap。千亿级案例中，Spark Driver 一并加载 Source 与 Ingest Time 两组 ZoneMap，对候选集求交，把 Candidate Fragments 从 12 个裁剪到 4 个，之后才把扫描任务交给 Executor。
• 增量维护闭环：数据持续入湖新增 Fragment，质量审核与打标模型迭代又会在同一 Fragment 内新增或更新列产生更多 Data File；横向列碎片与纵向行碎片叠加推高 Manifest 规模，增加数据集打开、内存占用与提交压力。数据与索引独立存储却并非无关——数据文件被重写或合并后，索引覆盖需同步恢复，因此 compaction 与索引优化不能各自独立运行。LAS 把维护组织成四步：状态感知（记录文件、索引、版本等可观测指标）、增量规划（判断是否需要 compaction、版本清理或索引优化并梳理任务依赖）、分段提交（把超大任务拆成小任务逐段提交）、故障恢复（单个任务失败不影响已提交结果，恢复后继续推进后续依赖）。
• ZoneMap-aware Compaction：不只追求减少文件数量，还保护数据局部性——值域相同的 Fragment 可以合并，值域不同的数据避免强行拼接；compaction 完成后由独立索引任务恢复新 Fragment 的索引覆盖。进度、成本、覆盖率与失败状态进入统一的可观测体系。
• 批量检索优化：面对 20 亿条已治理存量与单批 1500 万条 Query，存量索引被拆成 20 个 Segment，每个 Segment 约承载 1 亿条；Ray 中的 Segment Actor 与分片固定绑定，每个 Worker 只加载并反复复用自己的热索引，各 Actor 计算 Local Top-K，再由 Driver 对 20 路结果做增量归并得到全局 Top-K。Lance Core 内部进一步把「Query 到 Partition」的映射反转为「Partition 到 Queries」：一个 Partition 只加载、准备一次，再为不同 Query 保留独立的计算缓冲区与 Top-K Heap，检索语义不变，减少的是重复调度与数据准备。在相同数据、参数与预热索引条件下，IVF_RQ、1 亿条、768 维、Batch Size 16 的测试显示：单并发 QPS 从 1317.5 提升到 2050.0（+55.6%），八并发从 3372.8 提升到 3888.7（+15.3%）。
• ByteHouse 在线侧：ByteHouse 直接读取 TOS 对象存储上的 Lance 湖表，为向量检索、全文检索与标量过滤提供统一 SQL 入口。Coordinator 负责 SQL 解析、固定数据版本、加载 Manifest 与索引信息并结合节点拓扑生成执行计划；Worker 与索引 Segment 绑定，通过内存缓存复用 Lance Index，再用磁盘缓存减少对象存储读取。
• 自陈的边界：官方写明 ZoneMap 是保守过滤器，剪枝效果取决于数据局部性；若相关字段在文件中分布过于离散，能跳过的数据有限。Liquid Clustering、增量 Embedding、特征工程以及 UDF、AI Function 纳入管理流程被明确列为规划方向。

行业影响

多模态数据湖的讨论过去集中在「格式能不能装下图像和向量」，这篇文章把问题推进了一步：格式统一只是起点，真正的难点是数据在持续写入、补列、建索引与被查询的过程中如何保持可管理。它给出的路径是把分区从物理目录改成值域统计，把维护从一次性大任务改成可分段提交、可断点续跑的闭环，把批量检索的优化点从并行度挪到「重复准备工作」。

这三条都附带了可核对的代价：ZoneMap 是保守过滤器，剪枝收益依赖数据局部性；compaction 与索引优化被迫协同调度，维护链路上多出一层依赖管理；批量检索的收益在八并发下从 55.6% 收敛到 15.3%，说明共享准备工作的收益会随并行度摊薄。对正在评估 Lance 或类似格式的团队来说，这些数字比「统一底座」这个结论更值得先读。

相关链接

• 从三套系统到统一数据底座：火山引擎多模态数据湖的规模化实践

---

S&P Global Energy：把结构化数据资产切成一组 Genie Agent，再用 MCP 代理合并成端点

事件概述

9 月 25 日，Databricks 博客刊出由 Debaprasad Satapathy 与 Eric Henderson 撰写的《From Data to Dialogue: How S&P Global Energy Made Its Structured Data Estate Conversational》。S&P Global Energy 的数据横跨 Chemicals、Crude Oil、Refined Products、Gas & Power、LNG 等多个大宗品类，单是 LNG 就包含设施规格、货轮、检修停运、供需基本面、净回值、历史与预测价格、合约等一族数据集，其中一部分并不在 Databricks 上。目标是把整个结构化数据资产通过 Model Context Protocol（MCP）开放给外部客户的 agent 用自然语言查询。

他们评估过几种方案后选的架构是三层：领域专家按数据集组各建一个 Genie Agent；每个 Genie Agent 自动成为一个受治理的 MCP server；再用一层 FastMCP 代理把多个 Genie MCP server 组合成跨域复合端点。

技术解析

• 窄粒度切分：不是每个品类一个大 Agent，而是每个子类别一个。LNG 被拆成七个 Agent——Assets & Contracts、Cargo、Tenders、Outages、Supply & Demand、Netbacks、Prices，各自只覆盖一组表。
• 非 Databricks 数据源走联邦：数据不在 Databricks 上时，通过 Lakehouse Federation 连接器接入，联邦表与原生表并列，继承同一套治理；官方称这一层让他们没有新增任何 ETL 作业就做到了可对话。
• 治理内建：每个问题都经过 Unity Catalog 权限，作用在原生表或联邦表上，带完整审计；不需要另建一套安全栈。
• 五条实践建议：Agent 要窄而精——覆盖一个具体数据域、配清晰的指令与示例查询，跨域组合放在 MCP 层做，不要做一个「统管一切」的 Agent；上管道之前先试联邦，热路径可以之后再物化；在语义层上投入——列描述、业务定义与可信示例查询是区分演示与产品的东西；复合工具要清晰命名空间，例如 cargo_、outages_ 前缀，帮助 LLM 把问题路由到正确的 Agent；度量信任而不只是延迟——他们记录的是领域专家在策展阶段对 Genie 生成 SQL 的认同率。
• 效果表述：官方给出的收益是「新数据集组上线以天计，而非以开发周期计」，以及工程投入从构建定制接入层转向维护一层薄代理。

行业影响

这条的价值不在 Genie 本身，而在它把数据发布的责任主体换掉了。过去把一批表开放给外部消费，要经历需求、API 设计、text-to-SQL 工程、测试、部署这样一个完整开发周期；现在的流程是懂 LNG 货轮或化学品供需平衡的人自己策展一个 Agent，端点随即存在。工程团队维护的对象从若干个定制接入层收缩为一层可复用的代理。

这条路径的未决之处同样清楚：文章没有给出吞吐或准确率基准，只说用「领域专家对生成 SQL 的认同率」作为领先指标；复合端点下 LLM 能否把问题路由正确，靠的是清晰的命名前缀与语义层质量，而不是某种确定性机制；FastMCP 代理是他们自建的薄层，跨 Agent 的组合语义仍由这层代理定义。换句话说，把发布权交给领域专家之后，正确性保障落在了策展质量上，而策展质量的度量方式目前还是人工抽查。

相关链接

• From Data to Dialogue: How S&P Global Energy Made Its Structured Data Estate Conversational with Databricks Genie Agents and MCP

---

编者评

四条动态放在一处看，是一次相当整齐的「分配权上移」：EMR 把升级时机的判断收进一条 36 个月的支持承诺，Kinesis 把分片路由的判断收进服务端的容量视图，LAS 把跳过哪些数据、合并哪些 Fragment 的判断收进 ZoneMap 与增量闭环，S&P Global 把哪批数据对外开放、开放给谁的编排收进一组由领域专家策展的 Agent。做出判断的一方都从「使用系统的团队」变成了「提供系统的一方」，客户端或用户侧留下的代码与流程随之变薄。

共同代价是控制粒度。LTS 只承诺 critical 与 high 级别的安全、缺陷、数据损坏三类修复，且带着「subject to availability」这一句，功能缺失不在覆盖范围内；Kinesis 换来的是放弃按分区键保序，顺序敏感的负载用不了；LAS 的 ZoneMap 是保守过滤器，剪枝收益随数据局部性浮动，批量检索的收益在八并发下从 55.6% 收敛到 15.3%；MCP 复合端点把路由正确性押在命名前缀与语义层质量上，基准数字一个都没给。四处收拢都不是免费的，只是把「自己权衡」换成了「接受对方定义的服务边界」。评估这类变化时，先读边界条款比先读收益倍数更省事——LTS 的支持范围、Kinesis 的模式限制、ZoneMap 的保守性、MCP 层的路由假设，都是可以逐条核对的，而「省下多少工作量」这类表述大多不可核对。

本期中文源落在火山引擎 LAS 这一篇：它是本窗口内唯一给出可复现方法、量化结果与自陈局限三条的中文材料。阿里云方面，云栖大会期间的 ODPS / MaxCompute 升级已在 Vol.76 随 OpenLake 与 ADA 一并报道，本期不重复展开。另有几条线索按「优先技术内容」原则未单列：Databricks 于 9 月 25 日宣布收购电子表格产品 Row Zero，方向是把受治理的电子表格界面接到 Genie 与 Unity Catalog 上，属界面与接入层，官方新闻稿页面未取得可核验链接，待有正式发布页再展开；DuckDB 9 月 25 日的《DuckDB and Hugging Face》讲的是 hf:// 协议用法，该能力自 v0.10.3（2024 年 5 月）起就有，属教程而非新特性；AWS Glue Data Quality 于 9 月 22 日上线基于生成式 AI 的 Advanced 模式规则推荐，覆盖 15 个区域，可作为质量规则冷启动的线索继续观察。Iceberg 1.12.0 截至发稿仍停在 1.12.0-rc1，官方 releases 页最新为 1.11.0；LanceDB 停留在 v0.40.0-beta.11 预发布，DuckDB、Delta Lake、Daft、Ray、Arrow、Trino、Flink 在本窗口均无正式新版；GCP、Azure、Snowflake、dbt、Dremio、Anyscale、The New Stack 与 Data Engineering Weekly 在 9 月 23 至 26 日没有够分量的数据基建类新稿。