datainfra前沿动态 · Vol.42

AWS 发布 Spark 故障排查 Agent 覆盖全 EMR 矩阵十零额外费用；AWS MSK Agent Skills 上线实现 Kafka 运维 AI 化；Spotify RAP 外部索引让数据湖支持 PB 级在线点查询

本期聚焦 DataInfra 三条 Agent-First 运维动态：AWS 在同日密集发布 Spark Troubleshooting Agent（覆盖 EMR on EKS/EC2/Serverless/Glue 全矩阵，MTTR 从数天缩至数分钟，零额外费用）和 MSK Agent Skills（Kafka 运维与迁移的结构化 Agent 工作流）；Spotify 发布 RAP 确定性外部索引技术，使 PB 级数据湖无需独立 KV 存储即可支持毫秒级在线点查询。三条动态从计算引擎运维、流平台运维到存储层索引，共同指向 Agent-First DataInfra 的纵深推进。

DataInfra AWS Amazon EMR EMR on EKS Apache Spark MCP Agent 故障排查 MTTR Amazon MSK Apache Kafka Agent Skills 流处理 Spotify RAP Random Access Parquet 数据湖索引 Iceberg Apache Hudi Apache Pinot 点查询 OLTP Parquet AI运维

本期追踪到三条 DataInfra 动态，共同指向 Agent-First DataInfra 运维范式的纵深推进——从单个服务的单点 Agent 增强，到跨计算引擎、流平台、存储层的全矩阵覆盖。2026 年 8 月 3 日，AWS 在一个自然日内密集发布了两项 Agent 驱动的 DataInfra 运维能力：Apache Spark Troubleshooting Agent 全线覆盖 EMR on EKS——使 Spark 故障排查 Agent 完成了对 EMR on EC2、EMR Serverless、AWS Glue 和 EMR on EKS 的全矩阵统一；以及 Agent Skills for Amazon MSK——将结构化 Kafka 运维专业知识和迁移规划编码为可直接在开发环境中调用的 AI 技能。同日，Data Engineering Weekly #281 重点推荐了 Spotify 的 Random Access Parquet (RAP) 技术——一种确定性外部索引方案，使 PB/EB 级数据湖无需维护独立 KV 存储副本即可支持毫秒级在线点查询，将”湖仓一体”从”分析+事务”两象限推向了”分析+事务+在线点查”三象限。三条动态分别从计算引擎运维工具层、流平台运维工具层和存储索引层，锚定了 DataInfra 正在经历的 Agent-First 纵深演进。

AWS 发布 Apache Spark Troubleshooting Agent 全线覆盖 EMR on EKS：MTTR 从数天缩至数分钟，零额外费用

事件概述

2026 年 8 月 3 日，AWS 九人工程团队——Vara Bonthu、Andrew Kim、Maheedhar Reddy Chappidi、Jeremy Samuel、Siddharth Kumar、Layth Yassin、Kartik Panjabi、Shawn Huang 和 Weijing Cai——在 AWS Big Data Blog 上正式发布了 Apache Spark Troubleshooting Agent for Amazon EMR on EKS。该 Agent 此前已支持 EMR on EC2、EMR Serverless 和 AWS Glue，本次发布将其扩展至 EMR on EKS，完成了对 AWS 全 Spark 计算矩阵的统一覆盖。

核心能力可以直接用一句话概括：用自然语言描述一个失败的 Spark 作业，Agent 自动跨 S3、CloudWatch 和 Spark History Server 关联多源信号，返回根因分析和代码级修复建议——MTTR 从数天缩至数分钟，零额外费用。

技术解析

  • 全托管 MCP 架构，零部署：Troubleshooting Agent 以完全托管的 MCP 服务器形式运行——用户不需要部署或维护任何本地 MCP 服务器。Agent 通过两个 MCP 工具暴露能力：analyze_spark_workload（工作负载分析和根因定位）和 spark_code_recommendation（代码修复建议，支持 PySpark）。MCP 客户端方面目前支持 Claude Code、Kiro CLI 和 Kiro IDE。设计上采用单租户隔离（确保应用数据和代码隔离）、只读操作（受 IAM 权限控制）和自动审计（工具调用记录到 AWS CloudTrail）三重保障。

  • EMR on EKS 特有的自动日志发现：与 EMR on EC2 和 Serverless 不同，EMR on EKS 的日志分布在 S3 和 CloudWatch 两个平面上——Spark Event Logs 和 stderr/stdout 容器日志存储在 S3 中，Driver 和 Executor 容器日志流在 CloudWatch 中。Agent 自动发现并关联这两组日志源，同时接入 Spark History Server 获取查询计划、Stage 指标和配置信息。传统调试中工程师需要手动交叉引用这些分散信号——一个 OOM 故障在 Kubernetes 层面只表现为 exit code 137，无法直接关联到导致问题的代码行或配置项——Agent 将这个过程完全自动化。

  • RAG 驱动的智能诊断：推理层使用 Amazon Bedrock 上的 LLM，通过检索增强生成（RAG）技术，基于 AWS 多年运行数百万 Spark 应用程序的经验知识库进行诊断。这解决了通用 LLM 在 Spark 调试场景中的核心问题：训练数据可能缺少特定版本的行为细节、特定配置的交互效应、以及特定 EMR/EKS 集成场景的已知问题。支持四大故障类别：内存溢出和资源耗尽（含 Kubernetes pod 退出码的自动解释）、数据倾斜和 Shuffle 问题、配置错误、以及代码级问题（含 before/after 修复建议）。

  • 零额外费用的经济学：使用 Agent（包括底层 Amazon Bedrock LLM 推理）不收取额外费用，用户仅需为运行 Spark 作业和验证建议修改所使用的 AWS 资源付费。这在 Agent 驱动的运维工具中是一个有意义的定价信号——AWS 将其定位为平台的基础设施能力而非附加产品，类似于 CloudWatch Logs 或 EMR 控制台，是”使用 EMR 就自带”的运维基座。

行业影响

Spark Troubleshooting Agent 全线覆盖 EMR on EKS 的意义不仅在于”又一个 EMR 服务支持了 Agent 调试”。它完成了 AWS 在 Spark 计算矩阵上的 Agent-First 运维拼图：从 EMR on EC2（传统集群模式）到 EMR Serverless（无服务器模式）到 AWS Glue（全托管 ETL）到 EMR on EKS（容器化模式），四种部署形态现在共享同一套 Agent 驱动的故障排查接口。

这种”统一诊断接口”的设计模式值得关注。它意味着无论 Spark 工作负载跑在什么底层基础设施上——裸金属 EC2、Serverless 自动伸缩集群、Kubernetes Pod、还是 Glue 托管环境——运维人员面对的都是相同的自然语言交互体验和相同的 RAG 推理引擎。这降低了跨 EMR 服务迁移的运维学习成本，也为”在多个 EMR 服务之间根据工作负载特征灵活切换”提供了运维基础。

更宏观地看，AWS 在同一天发布 Spark Agent 和 MSK Agent Skills（见下一个主题），不是偶然。它标志着 AWS 在 DataInfra 运维层的 Agent 化策略正在从”单点试点”走向”全矩阵推广”。结合此前 Vol.37-41 持续追踪的 Google Cloud Agent-First DataInfra（Conversational Analytics、Borderless Lakehouse、OKF v0.2）、阿里云 MaxAgent GA、以及 AWS 自身的 Spark Upgrade Agent——Agent 正在成为 DataInfra 产品的默认运维界面。

相关链接

AWS MSK Agent Skills 上线：Kafka 运维与迁移的结构化 Agent 工作流

事件概述

同日（2026 年 8 月 3 日），AWS 作者 Huyam Hasan 和 Ashley Millette 发布了 Agent Skills for Amazon MSK，将结构化的 Kafka 运维专业知识和迁移规划编码为两个可在开发环境中直接调用的 AI Agent 技能：managing-amazon-msk（集群运维管理）和 migrate-to-msk（从自管理 Kafka 迁移到 MSK）。这两个技能解决了通用 LLM 在 MSK 场景中的一个关键问题：训练数据可能过时且缺乏特定上下文，容易混淆 MSK Provisioned 的 Standard 和 Express 两种 broker 类型，给出错误建议。Agent Skills 通过编码正确的 broker 类型感知上下文来解决这一幻觉问题。

技术解析

  • managing-amazon-msk：六维运维工作流：该技能内置六个结构化的诊断和规划工作流——性能故障排除（结构化决策树：CPU 饱和分析→批量大小分析→EBS 吞吐量配额→Express broker 配额）、消费者延迟诊断（判断延迟是 broker 端、分区级还是客户端问题）、存储管理（EBS 扩展、自动扩缩、保留策略规划、分层存储）、集群容量规划和定价（程序化对比所有 Standard 和 Express 实例类型并输出成本细分）、监控和告警设置（broker 类型感知的 CloudWatch 告警阈值），以及维护操作（滚动重启影响分析、版本升级规划、瞬态故障与真实问题的区分）。每个工作流的决策路径都考虑了 broker 类型差异，这是通用 LLM 最容易出错的维度。

  • migrate-to-msk：三阶段迁移流水线：该技能将 Kafka 迁移分解为发现（Discovery）→评估（Assessment）→模拟（Simulation）三个阶段。发现阶段支持从 IaC 文件（Terraform/CDK/CloudFormation/Docker Compose/Kubernetes manifests）、Kafka CLI 输出和手动输入三种来源清点源集群配置，输出标准化的 cluster-config.json。评估阶段对拓扑结构、Kafka 版本、Broker/Topic 配置、认证机制和配额进行五支柱兼容性检查，每个检查输出 INFO/ADVISORY/ACTION_REQUIRED 三级判定。模拟阶段（可选）在实际迁移前部署临时 MSK 集群和 EC2 负载生成器进行端到端延迟和 broker 负载下重启测试，测试完成后可帮助拆除资源、停止计费。

  • Agent DevOps 范式：这两个技能代表了 DataInfra 运维工具的一个新范式：将专业知识从文档和人类经验中提取为可执行的 Agent 工作流。与传统依赖 Web 控制台和仪表板的运维方式不同，Agent Skills 直接集成到开发环境和 CI/CD 流程中——开发者不需要手动搜索文档来判断某个 CloudWatch 指标对 Standard 还是 Express broker 有意义，Agent 根据集群的实际配置自动路由到正确的诊断路径。技能源码托管在 Agent Toolkit for AWS GitHub 仓库的 skills/specialized-skills/analytics-skills 路径下，社区可贡献和改进。

行业影响

MSK Agent Skills 与同日发布的 Spark Troubleshooting Agent 形成了 AWS DataInfra Agent 生态的”双子星”——前者覆盖流平台（Kafka），后者覆盖批处理/交互式分析引擎（Spark）。两者共享相同的 Agent Skills 架构范式（托管 MCP 服务器、RAG 推理、结构化工作流、零额外费用），标志着 AWS 正在系统性地将 Agent 从”辅助问答”提升为”DataInfra 的默认运维方式”。

从行业视角看，MSK Agent Skills 的三阶段迁移流水线（发现→评估→模拟）是一个特别值得关注的设计模式。它将一个传统上需要数周手动规划和验证的 Kafka 迁移项目，编码为一个可复用的、结构化的、部分可自动化的 Agent 工作流。这与 Atlassian 在 DEW #281 中分享的从 Kinesis 到 Kafka 的 1450 亿日事件量迁移经验形成了呼应——当流平台迁移的规模和频率增加时，Agent 驱动的迁移工具将从”锦上添花”变为”必备基础设施”。

相关链接

Spotify RAP：用确定性外部索引让数据湖支持 PB 级在线点查询

事件概述

Spotify 工程团队近期发布了一篇深度技术文章，详细介绍了 Random Access Parquet (RAP)——一种在现有 Parquet 数据湖之上构建确定性外部索引的技术，使 PB 级数据湖无需维护独立的 KV 存储副本（如 Bigtable 或 DynamoDB），即可支持毫秒级在线点查询。Data Engineering Weekly #281（2026 年 8 月 3 日）将此文件为重点推荐。Ananth Packkildurai 的编者评特别指出：“索引不可避免地要进入湖仓——Iceberg v4 spec 已经在讨论构建 Secondary Indexes，Apache Hudi 的 RLI (Record Level Indexing) 正在向次级索引扩展，Apache Pinot 将其索引支持扩展到 Iceberg 表以实现快速查询。Spotify 的故事强调了湖仓中对更多点查询的索引支持需求。”

技术解析

  • 确定性外部索引 vs. 概率性内部索引：RAP 的核心创新在于选择了”确定性外部索引”路径，而非依赖 Parquet 内置的 PageIndex 或 Bloom Filter。传统的分布式 SQL 引擎（Trino、BigQuery）进行单行查找时，需要经历分区裁剪→Bloom Filter 过滤→读取文件→解析尾部→扫描行组元数据→扫描键列→使用列/页索引定位数据的依赖读取链——每个环节在云存储上增加数十毫秒延迟。RAP 用预计算的外部多映射（multimap）替代整个读取链：Key → (文件位置, 行号)，查找复杂度 O(1)，每个索引条目可精确到文件内的行号。索引规模大约是原始数据的 1/1000（TB 级数据→GB 级索引）。

  • 三层文件优化技术栈：RAP 提供了一套渐进式文件优化技术。第一层”集中键数据”——按键排序使同键所有行在文件中连续、共组（co-grouping）使每个键一行、更粗粒度分区减少键跨越的文件数——这些优化对分析工作负载零代价。第二层”减少读取字节数”——每键边界刷新 Parquet 页面、ZSTD 帧重置使每个键的行压缩为独立帧并存储精确偏移量和大小、存储对齐填充适配云存储块边界——适度增加文件大小以换取点查询的 I/O 精度。第三层”减少读取操作数”——被称为”最大的单次胜利”：Blobs/Variants 将随机访问所需字段存储为单列（每次每文件只需一次读取）、列交织将多个列的键数据物理相邻写入、覆盖索引将小值直接提升到索引条目中完全消除存储读取。综合这些优化，一次点查询可以被缩减为一次数千字节的单个范围读取——或完全消除存储读取。

  • AI Agent 驱动的需求觉醒：Spotify 文章中一个意味深长的用例是 AI Agent：“AI 代理回答’我去年夏天听了什么？‘时需要快速检索用户数据，以便进行推理——过滤、聚合甚至本地运行 SQL——为 LLM 提示构建上下文。“这揭示了数据湖索引的一个新的需求驱动力：传统的数据湖以”分析型工作负载”（大规模扫描、聚合）为优化目标，但 AI Agent 的数据消费模式是”交互式点查+小范围分析”混合——Agent 需要快速检索特定实体的上下文，而不是扫描全部数据。RAP 使同一套 Parquet 文件同时服务两种访问模式，无需维护独立副本。

  • 与开放表格式的关系：RAP 不要求数据必须使用 Iceberg 格式——它可以操作任何现有 Parquet 文件——但与 Iceberg 的生态互补性很强。RAP 利用 Iceberg 的分区规范和 bucket transforms 作为减少候选文件集的标准方法。文章中明确提到：Iceberg v4 spec 的 Secondary Indexes、Apache Hudi 的 RLI 扩展、以及 Apache Pinot 对 Iceberg 的索引支持，共同指向一个正在成形的趋势——开放表格式正在从”元数据管理”向”元数据+索引管理”演进。

行业影响

Spotify RAP 的发布时机意味深长——它出现在 Iceberg v4 开始讨论 Secondary Indexes、Hudi RLI 持续演进、Pinot 扩展 Iceberg 索引支持的同一时间窗口。这不是巧合，而是”湖仓需要索引”这一行业共识的集体表达。

从架构演进的角度看，数据湖的发展经历了三个阶段：第一阶段是”格式标准化”（以 Iceberg/Delta/Hudi 的开放表格式为代表，解决的是 ACID、Time Travel、Schema Evolution 等元数据层问题）；第二阶段是”性能统一化”（以原生引擎集成、Rust/Python 多语言支持、Catalog Federation 为代表，解决的是跨引擎性能一致性问题）；第三阶段正在到来——“访问模式多样化”（从纯分析型扫描扩展为分析+交互式点查+Agent 上下文检索的混合访问）。RAP 和 Iceberg v4 Secondary Indexes 代表了这第三阶段的早期探索。

有三个值得长期关注的后续问题。第一，索引维护成本——RAP 声称索引构建可以增量进行，但大规模数据湖中持续维护多个次级索引的 TCO 尚未被充分验证。第二，索引格式标准化——目前 RAP、Iceberg Secondary Indexes、Hudi RLI 各有自己的索引格式和 API，是否会走向类似 Parquet 那样的开放索引格式标准？第三，AI Agent 对数据湖访问模式的改变究竟有多大——如果 Agent 驱动的点查询量级在未来 2-3 年内增长 10-100×，“索引即基础设施”的命题将从”可选优化”变为”必备条件”。

相关链接

编者评

本期三条动态共享一个深层叙事：Agent 正在从 DataInfra 的”用户界面”变为”运维基座”。AWS 在 Spark 和 Kafka 两条主线上同日发布 Agent 驱动的运维工具不是偶然——它是”Agent-First DataInfra”从战略叙事走向产品落地的信号。而 Spotify RAP 则从存储层揭示了一个互补趋势：Agent 不仅改变了”人如何运维 DataInfra”，更在改变”DataInfra 需要支持什么样的数据访问模式”——当 AI Agent 成为数据的主要消费者之一时，数据湖必须具备低延迟点查询能力。这三条动态合在一起，勾勒出一幅正在加速成形的图景：“运维 Agent 化”（Spark/MSK Troubleshooting Agent）+ “存储索引化”（RAP/Iceberg Secondary Indexes）+ “消费 Agent 化”（AI Agent 需要点查+分析混合访问）= Agent-First DataInfra 的完整拼图。我们正在见证 DataInfra 从”为人设计”到”为人+Agent 共同设计”的范式转换——而 2026 年 8 月的第一个工作日，AWS 用两弹连发宣告了这个转换的加速。