我的数据空间

主题

AI 智能诊断 ​

场景　作业跑挂了,靠人工翻日志、猜 Spark/Flink 报错原因,费时又费经验,新同事更是无从下手。智能诊断把这套排查动作交给一个 agentic 工具循环:模型自己决定去查哪些证据、查几次,最后给出结构化的"分类 + 根因 + 建议",而不是简单地把日志转发给大模型润色一遍。

能干什么

你想做的事用智能诊断长这样
失败作业不知道从哪查起实例详情点「智能诊断」,给出分类、根因、修复建议
想确认结论有证据支撑,不是模型现编的展开「诊断过程」,能看到每一步调了哪个采集工具、拿到了什么证据
作业不是失败,而是迟迟不结束、卡住了对"运行中/长时间未完成"的实例也能诊断,判断卡在依赖等待、资源排队还是 pod 未就绪
怀疑是数据本身的问题(脏数据/倾斜)模型能点名具体表、具体字段做采样分析(空值占比/高频值),用数据坐实或排除猜测
容器已被引擎回收,日志找不到了平台采集层留了底:已删除容器的日志、pod 被杀死因照样查得到
跑一条即席 SQL、跑一个 Notebook cell 失败了不止调度作业——查询页和 Notebook 里失败也能一键诊断
在对话里问"实例 #xxx 为什么失败"AI 助手「工小数」自动转深度诊断,取证过程边跑边看
引擎日志动辄上万行,根因容易被淹没平台先自动提炼出关键异常段,再喂给模型,不会把整份日志的噪声也交给它
没配大模型密钥,或者模型这次调用失败了自动降级为规则诊断,基于同一批真实证据做模式匹配,诊断始终有结果可看

亮点 ​

  • 真连引擎取证,查不到也不编——19 种采集动作直连 Spark/Flink REST、k8s、日志采集层、血缘与元数据
  • Agentic 且会"深挖":模型不但自己决定查什么、查几次,还能带参数点名查哪张表的哪个字段、哪个 stage、哪个 checkpoint
  • 证据覆盖"已消失的现场":容器被引擎回收后,日志和死因仍有采集层留底
  • 结论如实归因:AI 徽标就是 AI 给的,规则徽标就是规则给的;证据不足会明说,不臆造

诊断结果长什么样 ​

点「智能诊断」后,平台会先自动采集这次失败相关的证据(日志、运行信息、引擎状态、血缘等,配了大模型的话由模型自主决定查哪些、查几次),再给出一张结果卡:分类标签 + 一句话结论 + 引擎徽标(AI/规则) + 根因 + 修复建议,连同可展开的「关键错误」「诊断过程」(每一步查了什么、拿到什么证据,供审计)一起呈现。下面两个例子分别来自 Spark 和 Flink 的真实触发失败。

示例一:Spark SQL 数据倾斜引发的 OOM ​

按 user_id 把每个用户的行为事件拼成一条摘要字符串(常见于风控/画像类报表),但 user_bot_9527 是异常刷量账号,事件数是普通用户的百万倍——拼接这条摘要时,负责这个 key 的 executor(申请了 512MB 内存)被真实打爆:

智能诊断结果卡(Spark SQL 作业 user_activity_digest_skew_demo 失败):分类"资源(OOM)",AI(DeepSeek) 给出结论"512MB内存不足导致聚合操作OOM,7次重试全部失败",根因说明是聚合运算需求远超申请内存、GC耗时占运行总时长32%、单partition单task处理全部数据导致堆内存耗尽,给出三条建议(调大executor内存、调大shuffle分区数避免单partition承载全部数据、检查GROUP BY字段基数),展开的关键错误显示OutOfMemoryError堆栈

展开「诊断过程」能看到模型一共查了 6 步:运行信息、Spark pod 状态(已回收,如实报告查不到)、血缘写入表,以及两次 Spark REST 取失败 stage 详情——从中拿到「失败任务数=7」「executor 共 4 个(其中 1 个还活跃)、总 GC 耗时 29183ms」这些具体指标,这些数字后面被模型换算成"GC 耗时占运行总时长 32%",直接支撑了它的根因判断:

诊断过程展开:2. get_run_info 显示申请内存=512MB 3. get_spark_pod_status 显示"未找到driver pod,作业结束后pod已被回收" 4. get_lineage_tables 显示写入表 5. get_spark_stage_failures 显示失败任务=7、完整的OutOfMemoryError堆栈(UTF8String.concat处抛出)

flink_checkpoint_fail_demo 是一个 datagen → Iceberg 的流作业,checkpoint 超时被故意设得比实际所需时间短得多,同时把"容忍失败次数"调到了接近无穷——数据流本身完全正常,但每一次 checkpoint 都会超时失败,是那种不崩溃、不重启、却在悄悄丢失容错能力的典型隐患:

智能诊断结果卡(Flink 流作业 flink_checkpoint_fail_demo):分类"反压/Checkpoint",AI(DeepSeek) 给出结论"所有Checkpoint超时失败",根因是Checkpoint expired before completing、可能因存储写入慢或网络延迟导致超时,给出三条建议(增大checkpoint间隔如从10s改为30s、检查Iceberg表写入性能优化存储或网络、考虑增加并行度以加速算子处理),展开的关键错误显示CheckpointException

展开「诊断过程」能看到模型查了 5 步,用的是和 Spark 完全不同的一套工具:先查 get_flink_exception 确认部署状态=RUNNING、JobManager 没报告 root-exception(数据流没崩,不臆造一个不存在的崩溃);再查 get_flink_runtime 拿到「checkpoint 完成=0 失败=16」「反压:各算子正常」这组关键指标;最后两次 engine-pod-logs 分别去拉 JobManager 和 TaskManager 的原始 pod 日志,从里面摘出了真实的 Checkpoint 14/15 has been notified as aborted 这类证据:

诊断过程展开:1. get_flink_exception 显示部署状态=RUNNING、state=RUNNING、JobManager未报告root-exception 2. get_flink_runtime 显示checkpoint完成=0失败=16、最近失败原因Checkpoint expired before completing、反压各算子正常 3. get_job_config 显示并行度=1、checkpoint间隔=10s 4-5. engine-pod-logs 分别取JobManager和TaskManager原始日志,摘出Checkpoint 14/15 has been notified as aborted

示例三:模型自己"点名查数",用采样坐实根因 ​

有一类失败,光看报错猜不透:SQL 里的数据校验断言炸了,到底是数据真有问题,还是断言本身写错了?下面这个作业用 assert_true(amount > 1000000) 做入库前校验,运行期抛了异常。诊断过程中,模型在读完报错和 SQL 源码后,自己决定带参数去查这张表的这个字段——先调表采样分析拿到 amount 的实际取值(154.02、68.92,均远低于 100 万),再调表结构确认 amount decimal(10,2) 类型正常——于是结论不是含糊的"数据校验失败",而是明确的"断言阈值与真实数据不匹配,先探查取值范围再修阈值":

诊断过程展开:诊断·get_table_data_distribution 带参数 table=iceberg_lake.site_demo_ws10.daily_sim_orders、fields=[amount],返回"字段 amount: null占比=0.0%, 高频值Top2=[154.02(1次), 68.92(1次)]";诊断·get_table_schema 返回分区键[dt]与字段列表 order_id long/amount decimal(10,2)/dt date;上方还有失败 stage 的 shuffle 堆栈与 executor GC 占比等证据

这是"能深挖"的典型形态:采集工具不只是固定清单,模型可以指定表名和字段做采样分析、指定 stage 编号取全量 task 明细、指定 checkpoint 编号看逐算子耗时细分——像一个会顺着线索追问的工程师,而不是跑完固定检查单就交差。

证据面有多宽 ​

按作业类型精准暴露(Spark 作业不会去调 Flink 的工具,反之亦然;没有容器的作业不会白查一轮容器):

  • 通用:日志关键异常段(自动提炼,不喂噪声)、运行信息(申请资源/起止/退出码)、容器死因(含 OOMKilled;容器重启过也能翻出"上一世"的死因)、资源趋势(逐 pod 实测轨迹,判"渐进泄漏还是单点打爆")
  • Spark 专属:失败 stage 与数据倾斜/磁盘溢写判定、SQL 执行计划(AQE 是否改写)、executor 内存分区峰值(定位 OOM 属于哪块内存)、指定 stage 的 task 级深挖
  • Flink 专属:异常按种类归并(把"真因"从重启循环的症状和次生错误里拎出来)、checkpoint 细分耗时(瓶颈算子+同步/异步/对齐)、反压方向归因(被下游压还是正压上游)、异常历史时间线、RocksDB 状态后端指标
  • 数据与代码:血缘(读了哪些表/写哪张表)、表结构、表数据采样分析、SQL/脚本源码与作业参数原文、Notebook 出错 cell 定位
  • "已消失的现场":引擎删掉的 executor/TaskManager 容器,其日志仍能从平台采集层查到;pod 被回收前死因已先落库

不只调度作业:即席查询和 Notebook 也能诊断 ​

日常点得最多的"跑一条 SQL"失败了,同样不用自己啃报错——结果区直接点「AI 诊断此错误」。下面这条查询把列名 amount 拼成了 amout,诊断不但把报错翻译成了人话,还给出可直接粘贴的修正 SQL:

数据查询页:SQL 用了拼错的列名 amout,结果区显示"执行出错",AI 诊断结果卡给出分类 SQL、结论"SQL中字段amout拼写错误,应为amount(deepseek)",根因指出表中实际列名为 amount(另有 dt、order_id)、Spark 分析阶段报 UNRESOLVED_COLUMN,建议一栏给出改好列名的完整 SQL 可直接粘贴,下方关键错误显示 UNRESOLVED_COLUMN.WITH_SUGGESTION 原文

Notebook 里交互式跑挂的 cell 也一样:平台能定位到出错的是哪个 cell、连同那段源码和内核日志一起诊断。

在对话里诊断,过程边跑边看 ​

诊断也被 AI 助手「工小数」收编成对话里的一个工具:贴一个失败实例号就能触发。取证要跑十几秒到几十秒,这段时间不是白屏等待——气泡顶部的「回答过程实况」会把每一步边执行边展开:哪个工具正在跑、上一步拿到了什么证据,全程可见;答案生成后自动滚到开头:

运维监控页右侧的工小数对话:问"实例 #991571 为什么失败了?",最终答案尚未生成,气泡顶部"回答过程实况"区已展开——diagnose_instance 显示执行中,下方"诊断·get_error_log"已完成并显示 exitCode=1、日志关键段与三层异常链,"诊断·get_run_info"的结果正在流出

对话中断也不浪费已完成的工作:如果诊断已经跑完、只是对话模型这一环出了问题,已完成的诊断结果会原样呈现并如实标注来源,不会重跑一遍昂贵的取证,更不会把 AI 的结论错标成"规则"。

稳当:兜底、去重、熔断 ​

  • 规则兜底,始终有结果:没配大模型密钥、或模型这次调用失败,自动切到规则诊断——同样采集全部证据,按预置规则匹配分类。深层归因还是模型强,但"有没有结果""结果对不对得上证据"这两条底线始终守得住。
  • 重复点击秒回:短时间内对同一实例反复发起诊断,直接复用刚出炉的结果,不重复烧模型调用。
  • 故障自动熔断:模型服务持续出错时自动熔断、直接走规则,恢复后自动探测切回;并发也有上限,多人同时用不会相互拖垮。
  • 准确率有人管:内置一套取自真实失败案例的评测集,按轮次度量诊断准确率,改动回归跑评测,防止越改越差。

数据安全 ​

诊断证据要送给大模型,送出去之前平台先做两件事:基础设施凭证(如对象存储密钥)一律脱敏;日志原文、SQL 报错这类"外部数据"打上显式边界标记,防止里面混入的指令文本被模型当真(提示注入防护)。合规要求更严的场景,还可以打开业务字面量掩码,把 SQL/日志里的字符串与长数字值遮掉、只留结构。

前端呈现 ​

结果卡是一个可收起的组件,展开时依次是分类标签、一句话结论、根因、建议列表、可折叠的关键错误与诊断过程。入口有四处:运维监控的实例钻取右栏和流作业详情页(失败/运行中的实例显示按钮)、数据查询页的失败结果区、Notebook 的失败 cell、以及工小数对话。重新进入页面时会自动回显上次的诊断结果。

想看失败实例诊断在完整产品动线里长什么样,去产品巡览；在对话里触发诊断的完整体验,见智能问答。

回到核心能力总览 →