@fx-data/ai-diagnostics 0.1.20261111030608 → 0.1.20261111112203

package/AGENT_SETUP.md

@@ -1,6 +1,6 @@
 # FX 数据诊断：Agent 安装与管理
 
-本文供执行安装与管理的 Agent 读取，不作为日常诊断的前置上下文。包版本为 `0.1.20261111030608`，需要 Node.js `>=22` 及 npm。用户只需表达安装、使用、更新或卸载意图，环境准备和客户端登记由 Agent 完成。
+本文供执行安装与管理的 Agent 读取，不作为日常诊断的前置上下文。包版本为 `0.1.20261111112203`，需要 Node.js `>=22` 及 npm。用户只需表达安装、使用、更新或卸载意图，环境准备和客户端登记由 Agent 完成。
 
 用户明确要求安装、更新、回退、卸载或检查 FX 数据诊断时，也会触发薄 Skill，并直接执行对应管理命令，不先运行 `context` 或读取诊断规则；只有开始诊断时才按薄 Skill 加载内容。普通聊天不主动加载。
 

package/README.md

@@ -20,6 +20,8 @@
 
 也可以提供更新的 dagId，询问这次更新为什么慢；或附上 Metric 文件，分析耗时和内存。描述问题时带上“用 FX 数据诊断”，也可以在技能列表中选择“FX 数据诊断”。
 
+要一份单租户更新报告，可以说「用 FX 数据诊断分析 corp-xxx 租户近 3 天的更新情况，生成 HTML 报告」。
+
 ## 更新
 
 每次开始新诊断时，工具会在后台检查更新，不等待更新即可排查。更新成功后，各 Agent 的下一次新诊断使用新版；当前调查保持原版本，更新失败也不影响排查。Agent 会随后续使用提示更新状态，没有新版时不打扰你。
@@ -38,4 +40,4 @@
 
 ---
 
-**给 Agent：** 按 [Agent 执行说明](https://unpkg.com/@fx-data/ai-diagnostics@0.1.20261111030608/AGENT_SETUP.md) 完成安装与管理。已有本地包时，优先读取包内 `AGENT_SETUP.md`；本地 `.tgz` 只需读取 `package/AGENT_SETUP.md`。按命令结果简短反馈，成功即结束；只有失败或结果不完整时才排错。
+**给 Agent：** 按 [Agent 执行说明](https://unpkg.com/@fx-data/ai-diagnostics@0.1.20261111112203/AGENT_SETUP.md) 完成安装与管理。已有本地包时，优先读取包内 `AGENT_SETUP.md`；本地 `.tgz` 只需读取 `package/AGENT_SETUP.md`。按命令结果简短反馈，成功即结束；只有失败或结果不完整时才排错。

package/content/AGENTS.md

@@ -27,9 +27,10 @@
 
 | 用户目标 | 起点 |
 |---|---|
+| 明确要求把单租户一段时间内的更新情况做成报告或 HTML | [更新知识 · 企业更新分析](knowledge/update/workflow.md#企业更新分析) |
 | 慢、超时、卡顿、内存超限、OOM、`MemoryLimitExceeded`、资源消耗异常、性能退化或回归 | [性能排查入口](knowledge/common/workflow.md)，再按场景进入对应知识域 |
 | 只想拿到或看懂一份 engine metric | [引擎知识](knowledge/engine/workflow.md) |
-| 只想弄清更新来源、request、chain/DAG、node attempt、requeue、load、listener、engine task，或核对更新计数 | [更新知识 · 解释更新记录](knowledge/update/workflow.md#解释更新记录) |
+| 询问或分析租户近期更新情况，或解释更新来源、request、chain/DAG、node attempt、requeue、load、listener、engine task 和计数 | [更新知识 · 解释更新记录](knowledge/update/workflow.md#解释更新记录) |
 | 自动化有没有跑、为什么没触发、通知没收到、回填失败，或给了 workflowId 查执行情况 | [自动化知识](knowledge/automation/workflow.md) |
 | 只想配置诊断环境，或实时查询被工具、连接问题挡住 | [配置 SigNoZ MCP](knowledge/common/topics/setup-signoz-mcp.md)，弄好后回到原问题 |
 | 其他问题：非性能报错、结果异常、稳定性问题 | 有报错原文就先查[信号索引 · 常见报错](knowledge/signal-index.md#常见报错)；没有专门入口，先说明这块覆盖有限，再按[问题定位方法](docs/architecture.md)结合已有材料分析 |

package/content/README.md

@@ -10,6 +10,7 @@
 | 组件或仪表板加载慢 | 查询条件、筛选、参数、联动与组件取数 |
 | 更新慢、超时、内存超限 | 调度等待、依赖、计算、写入与重试 |
 | 更新来源或数量不清楚 | 触发来源、更新链路、节点与尝试次数 |
+| 生成单租户更新报告 | 小时峰值、`UpdateScene`、执行规模和耗时，交付 HTML |
 | 自动化没触发、通知没收到或回填失败 | 按 workflowId 核对每次执行、跳过原因、动作结果与回填进度 |
 | 其他报错、结果异常或偶发不可用 | 核对现象与执行记录，整理已确认事实和待验证问题 |
 
@@ -33,6 +34,8 @@ npm 安装：对 Agent 说“帮我安装并启用 FX 数据诊断，npm 包是
 
 > 企业 corp-xxx，帮我看一下最近的更新情况。
 
+> 分析 corp-xxx 租户近 3 天的更新情况，生成更新报告。
+
 > 客户怀疑重复更新，请根据这些日志区分更新请求、节点和重试次数。
 
 > 帮我看下 workflowId=xxx 这个自动化最近的执行情况，客户说昨晚没收到通知。

package/content/docs/architecture.md

@@ -33,6 +33,8 @@
 
 ## 沿实际操作还原过程
 
+用户明确要求生成单租户更新报告或 HTML 时，按[企业更新分析](../knowledge/update/workflow.md#企业更新分析)聚合窗口、按需下钻并生成文件。一般的更新情况分析按[解释更新记录](../knowledge/update/workflow.md#解释更新记录)在对话中交付。
+
 先说清这次算了什么，再解释哪里慢、为什么失败。按[场景排查](scenario-guide.md)核对：读了哪些表和数据范围；哪些筛选、参数、聚合、联动、权限参与了计算；慢在等待、计算、写入还是返回；有没有失败重试，多了多少工作。
 
 页面配置说明可能怎么算，请求和执行记录说明实际怎么算，两者对得上同一对象、同一次操作才能合起来解释。组件取数慢和更新慢同时出现时，要确认这次组件请求是不是在等或读这次更新的结果，共享底层计算只是线索。仪表板内组件异常先按[组件取数对照](../knowledge/dashboard/workflow.md#组件取数先做对照)看单独预览，没有对照也继续分析。

package/content/docs/index.md

@@ -42,6 +42,9 @@
 | 仪表板配置影响范围与“绑定下移”核对 | [仪表板 · 核对配置影响范围](../knowledge/dashboard/conclusions.md#核对配置影响范围) |
 | 企业更新与 dagId 的检索窗口、降级和时间扩展 | [更新发现指引 · 检索时间](../knowledge/update/topics/discover-executions.md#检索时间) |
 | 按输入选择更新取证配方 | [更新 · 选哪个配方](../knowledge/update/queries.md#选哪个配方) |
+| 企业更新负载的首批统计、租户归属、多日同期对比与画像总结 | [企业更新负载分析](../knowledge/update/topics/enterprise-analysis.md) |
+| 企业更新报告的 JSON 格式和 HTML 渲染 | [企业更新报告交付](../knowledge/update/topics/enterprise-report.md) |
+| 定时同步组释放与回调归并的判读 | [定时同步与回调更新模式](../knowledge/update/topics/datasource-update-patterns.md) |
 | 更新的计数单位 / 允许的关联边 | [更新 · 计数单位与身份](../knowledge/update/concepts.md#计数单位与身份)、[关联边](../knowledge/update/topics/correlations.md#关联边) |
 | 更新记录的计数对账、判断矩阵与停止规则 | [更新 · 能下什么结论](../knowledge/update/conclusions.md) |
 | 按 workflowId 查自动化执行情况 | [自动化 · 按 workflowId 查](../knowledge/automation/queries.md#按-workflowid-查) |

package/content/knowledge/signal-index.md

@@ -53,12 +53,17 @@
 | `dispatch_get_ancestors`、`dispatch_get_descendants` | 查祖先、查下游 | [logical-dependency-expansion](update/topics/events-intake.md#logical-dependency-expansion) |
 | `node-task-queue receive` | 主队列投递一次，就是一次消费尝试 | [attempt-consumed](update/topics/events-execution.md#attempt-consumed) |
 | `update` | 消费一次投递的根 span，另开独立 trace；节点结果属性写在它上面 | [attempt-consumed](update/topics/events-execution.md#attempt-consumed)、[primary-node-result](update/topics/events-outcome.md#primary-node-result) |
-| `slow-node-task-queue receive` | 租户并发超限，消息转到慢队列 | [capacity-deferred](update/topics/events-execution.md#capacity-deferred) |
+| `slow-node-task-queue receive`、`receive executeInfo at slow queue` | 慢队列消费 span 与日志 | [capacity-deferred](update/topics/events-execution.md#capacity-deferred) |
 | `dispatch_node_task_exec` | 节点真正执行的区间，加载日志的 `span_id` 指向它 | [一次执行的 span 结构](update/topics/lifecycle.md#一次执行的-span-结构) |
 | `trigger_listener_<监听器名>` | 监听器回调，一个节点里同名出现 3 次 | [listener-invocation](update/topics/events-outcome.md#listener-invocation) |
 | `dispatch_callback_children`、`evaluator_child` | 释放子节点、判断子节点能否执行 | [child-release](update/topics/events-outcome.md#child-release) |
 | `DataFlowExecutor` | 引擎写入（更新的物理写入），其下是 `execute` | [engine-handoff](update/topics/events-outcome.md#engine-handoff) |
+| `write.metric.received`、`write.metric.persisted`、`write.metric.output_data_mb` | 引擎写入接收行数、实际写入行数和输出量 | [写入指标](update/topics/events-outcome.md#写入指标) |
+| `ResourceGroupQueueTimeoutException` | 引擎资源组排队超时 | [engine-handoff](update/topics/events-outcome.md#engine-handoff) |
 | `dagId` | 更新链 ID | [先记住的几个概念](update/topics/lifecycle.md#先记住的几个概念) |
+| `bundleId`、`groupId` | 同步组与同步任务的标识，按出现的服务和消息区分 | [同步组与任务标识](update/topics/datasource-update-patterns.md#同步组与任务标识) |
+| `executeByConnection`、`syncGroupInterval`、`sync record sent`、`merge sync to engine` | 定时触发、表同步终态与合批提交信号 | [定时同步取证](update/topics/datasource-update-patterns.md#定时同步取证) |
+| `push to push-back mongo success`、`call back ids` | 回调待派发记录与更新提交信号 | [回调取证](update/topics/datasource-update-patterns.md#回调取证) |
 | `loadData`、`loadDataSkipReason`、`dataModify`、`execution.mode` | 这次有没有加载、为什么没加载、数据是否变化、写入方式 | [load-decision](update/topics/events-outcome.md#load-decision) |
 | `rowCount`、`updateType`、`rootErrorId`、`dispatchConsumed`、`businessConsumed` | 节点结果属性（行数、更新场景、失败根表、两段耗时） | [primary-node-result](update/topics/events-outcome.md#primary-node-result) |
 | `merge_count`、`wait_merge_time` | 合并了多条明细时才有 | [merge-decision](update/topics/events-execution.md#merge-decision) |

package/content/knowledge/update/README.md

@@ -30,6 +30,9 @@
 | [topics/events-execution.md](topics/events-execution.md) | 查消费尝试、限流与锁超时重排队、恢复、合并判断的信号时 | 消费、重排队与合并阶段的 7 个事件 |
 | [topics/events-outcome.md](topics/events-outcome.md) | 查 load、引擎交接、节点主结果、监听器、子节点释放的信号时 | load、引擎与结果阶段的 7 个事件 |
 | [topics/discover-executions.md](topics/discover-executions.md) | 只有企业 ID 或 dagId、还没定位到更新执行，或要确定企业、dagId 的检索时间窗时 | 从企业或 DAG 定位更新执行；检索时间 |
+| [topics/enterprise-analysis.md](topics/enterprise-analysis.md) | 要总结租户的更新节奏、来源和负载时 | 指标口径、峰值来源、典型表与 Polars 取样、调度与引擎排队 |
+| [topics/enterprise-report.md](topics/enterprise-report.md) | 要交付单租户更新分析报告时 | 固定 JSON 字段、缺失值和 HTML 渲染 |
+| [topics/datasource-update-patterns.md](topics/datasource-update-patterns.md) | 要解释同步相关峰值或判断全量、增量时 | 同步组释放、回调归并和单次同步方式取证 |
 | [topics/correlations.md](topics/correlations.md) | 核对异步关联或拆分耗时时 | 允许的关联边与 12 个性能片段 |
 
 ## 关联

package/content/knowledge/update/queries.md

@@ -24,12 +24,12 @@
 | 一条链的受理和各节点执行 | `name = 'dispatch_submit' AND dagId = '<链 ID>'`；`name = 'update' AND dagId = '<链 ID>'` | `dagId` 只在 `dispatch_submit` 和已执行的 `update` 上有 |
 | 某张表的消费尝试 | `name = 'node-task-queue receive' AND tableId = '<表 ID>'` | 队列 span 总带 `tableId`、`corpId`，包括限流转发和拿锁失败的投递 |
 | 某张表的节点执行结果 | `name = 'update' AND tableId = '<表 ID>'`，看 `updateType`、`loadData`、`rowCount`、`rootErrorId` | 没有这些属性的 `update` 没走到节点执行 |
-| 某个企业的更新 | 先用 `corpId` 查队列 span 或 `dispatch_submit`，再按 `linked` 找 `update` | `update` 上的 `corpId` 只有执行过的才有，不能用来排除企业 |
+| 某个企业的更新 | 先用 `corpId` 查主队列消费 span，再用显式关联找提交或 `update` | `dispatch_submit` 上的 `corpId` 覆盖须核对，见[提交归属](topics/enterprise-analysis.md#核对提交归属与窗口覆盖) |
 | 从发布方找到执行方（或反过来） | `name = 'update' AND linked = '<发布方 trace ID>'` | `linked` 保存的是发布方 trace ID |
 | 某次加载的起止与耗时 | 日志 `body CONTAINS 'table load success'`（或 `table load start`、`table load fail`），带 `trace_id` | 日志的 `span_id` 等于 `dispatch_node_task_exec` |
 | 某个节点的失败原因 | 日志 `body CONTAINS 'execute task error'`，带 `exception.type`、`exception.message` | 同一次失败还有一条不带堆栈的 `task exec error` |
 | 某张表有没有引用已有结果、tag 和旧版本释放 | `update` 上 `execution.mode = 'REF'`；日志 `body CONTAINS '<表 ID>'` 加 `[ResultBinding]`、`[Snapshot tag`、`[ResultRetention]` | 见 [result-publish](topics/events-outcome.md#result-publish) |
-| 限流和重排队 | 日志 `body CONTAINS 'Tenant limit exceeded'`、`resend execute info` | 慢队列每转一圈打一行，条数不等于节点数 |
+| 限流和重排队 | 日志 `Tenant limit exceeded`、`receive executeInfo at slow queue`、`resend execute info` | 转发、慢队列消费和锁超时重发分别取证。见[限流转发](topics/events-execution.md#capacity-deferred)和[等锁重发](topics/events-execution.md#lock-requeued) |
 
 按已有输入选一个配方，只补当前缺的那一项。配方只限定参考范围，不证明每个分支都发生，也不要求跑完全部步骤。事件见[事件索引](signals.md#事件索引)，边与片段见[关联边与性能片段](topics/correlations.md)。
 

package/content/knowledge/update/topics/datasource-update-patterns.md

@@ -0,0 +1,49 @@
+# 定时同步与回调更新模式
+
+在企业更新趋势中看到 `SCHEDU` 或 `CALL_BACK` 峰值，或需要解释某张表反复被这些来源更新时读这里。先按[企业更新负载分析](enterprise-analysis.md)确定窗口和目标链。以下机制与信号已按源码核对，实际配置、字段覆盖和阶段关联以对应执行记录为准。 [知识适用性](../../common/conclusions.md#知识适用性)
+
+## 同步组与任务标识
+
+| 标识 | 在什么范围内使用 |
+|---|---|
+| `bundleId` | 定时同步组 ID。一轮到期计划产生一个批次，可跨连接 |
+| `taskId`、sync 的 `groupId` | server 消息里的 `id`，同步记录里的 `taskId`，同步器代码和 `group task start/complete` 日志里的 `groupId`。标识一次同步任务，可以包含同连接的多张来源表 |
+| DM 通知里的 `groupId` | server 将它作为 `bundleId`，再按连接生成发送给 sync 的任务 ID |
+| `dagId` | 一次分析表更新提交对应的更新链。一个同步组可以分批提交，扫描器也可以把多个组的就绪表合到一条链 |
+
+## 定时同步如何释放
+
+1. 计划时刻先按租户的同步分组间隔对齐，读不到租户配置记录时默认 60 分钟。每轮挑已启用且已到期的计划，分配一个 `bundleId`，再按连接归集表清单。支持表级同步的路径会在组内记录各表的同步结果。同一连接的一份同步任务可以拆成多张来源表分别执行。
+2. 旧版定时路径等待整组结束再提交成功项。表级扫描在整组结束，或有一条已结束、未派发的表记录等满阈值时选中组。这里的结束包括成功和失败。仓库默认扫描间隔为 10 分钟，等待阈值为 20 分钟，实际以部署配置为准。
+3. 组一旦被选中，扫描器取该组所有已成功、需要更新且尚未派发的表，可以包含刚成功的表。尚在同步的表留待后续。扫描器按同租户、同场景合并多个就绪组，按连接和来源表找到分析表候选后提交。提前提交后保留已派发标记，整组完成回调补齐剩余符合条件的表并清理记录。
+
+## 定时同步取证
+
+| 要区分的现象 | 按需取的证据 |
+|---|---|
+| 配置时刻本身集中，或不同配置时刻对齐后才集中 | 核对客户计划时刻、频率和时区。按 `bundleId` 查 `executeByConnection` 的 `storeId`、`dataSourceType`、`syncGroupInterval`，以及 `begin sync datasource` 的企业、连接、任务和触发时间。`syncGroupInterval` 表示这轮读到的值，实际定时节奏看连续轮次。`begin to execute datasource schedule jobs` 中 `tenantId` 占位符填的是连接 ID，归属用其他明确记录核对 |
+| 表同步集中结束，或结束分散但集中释放 | 用 `sync record sent` 取企业、连接、来源表、`taskId`、`bundleId` 和终态时间。用 `merge sync to engine, dagId = {}, bundleIds = {}` 或其他明确关联找到对应 `dispatch_submit`。扫描日志中的组列表是本轮候选组，逐组贡献需核对实际派发成员 |
+
+比较计划、实际触发、同步结束和提交时间。旧路径等待整组时可能以 `bundleId` 作返回占位，以真实提交记录确认 `dagId`。同表反复作为下游节点出现时，沿实际链路找触发它的来源表。DM 的同步完成通知保留定时或非定时语义，分别可能落到 `SCHEDU` 或 `MANUAL_UPDATE`。简道云系统数据的部分定时路径走 `CDC_SCHEDULE`，API 数据源定时同步完成也可以走 `CALL_BACK`。 [场景入口](scene-producers.md)
+
+## 回调如何归并与派发
+
+简道云 webhook 或 CDC、数知鸟、API 数据源同步完成和本地宝自动更新都可以进入回调派发路径。sync 按回调标识归并待派发项，到达可派发时间后按租户打包。全量 CDC 可以立即标为可派发，由后台扫描发送。server 将回调标识映射到分析表，检查更新状态和来源容量，将符合条件的目标提交成一条 `CALL_BACK` 链。单条回调入口也有更新状态和限频检查。上游通知归并与调度侧节点合并各自判断，`CALL_BACK` 的默认调度合并规则见[更新场景](../concepts.md#更新场景updatescene)。
+
+## 回调取证
+
+对照已确认来源的事件或同步完成时间、`push to push-back mongo success` 上的企业与来源表，以及 server 的 `call back ids {}, chainId {}` 和对应 `dispatch_submit`。这样可区分来源通知集中和待派发项归并后集中送出。来源事件、待派发项、已提交更新链分别计数。
+
+`call back ids` 在这条 server 日志里是映射后的分析表 ID。确认回调来自哪张来源表需要明确的映射或同次调用记录。回调成功响应也可能没有对应的更新提交，按实际 `dagId` 与受理记录确认。只有场景和时间分布时，报告看到的集中现象，客户习惯的解释由当期配置或来源事件补证。
+
+## 判断单次同步是全量还是增量
+
+从已确认的更新链回查同步批次，再按连接、来源表和任务核对实际执行。确认到批次时给批次结论，确认了来源与分析表的血缘再给表级结论。来源抽取范围、同步目标覆盖或追加、下游分析表写入规模分别取证。`SCHEDU`、`CALL_BACK` 描述更新来源，`isAllTables` 描述本次选表范围，均不能直接判定行级同步方式。
+
+| 来源执行 | 可以核对的信号 |
+|---|---|
+| 云端 JDBC | 将 `CloudJdbcDataReceiver` 的 `jdbc sourceTableId: …, receive finish …` 与同表、同任务的成功 `sync record sent` 对账。此路径每次读取配置 SQL 的结果并覆盖同步目标。日志行数是本次抽取结果，源库扫描范围要看当期 SQL 或源端指标 |
+| DM 数据湖写入 | 有对应 `flushData` 时取 `destinationSyncMode`，结合已关联的覆盖或追加完成日志判定该次目标写入方式。来源抽取范围另看来源执行记录 |
+| 本地宝 JDBC CDC | 以实际执行的变更写入和游标推进确认增量。缺初始 CDC 参数或收到 DDL 时可发起全量同步，需另对到该次同步完成记录 |
+
+观察到反复覆盖时，再核对变化行数与抽取行数的比例、来源支持的水位或 CDC、更新删除语义以及全量初始化或回退场景。满足前提后才给增量方案，复核抽取量、下游写入负载和数据一致性。实际模式证据不足时，将这项检查列为待确认。

package/content/knowledge/update/topics/enterprise-analysis.md

@@ -0,0 +1,67 @@
+# 企业更新负载分析
+
+用同一个租户和时间窗看更新链提交、队列消费和节点执行的趋势，再按实际贡献峰值的场景补证。各查询的租户字段、关联和覆盖先用目标环境的小范围记录核对。 [企业更新发现](discover-executions.md#企业入口)
+
+## 输入与时间范围
+
+- 用已确认的企业 ID 精确过滤 `corpId`。已有 ID、环境或时间范围直接复用。只有企业名称且无法唯一定位时，追问企业 ID。环境与服务按[环境选择规则](../../common/concepts.md)确定。
+- 用户指定的时间范围优先。缺省按[企业更新检索时间](discover-executions.md#检索时间)查看最近 1 天，也就是滚动 24 小时。如果用户希望判断峰值是否在多天的同一时段重复，可以询问是否扩到最近 3 天或 7 天，确认后再查询。
+- 开始查询时固定绝对时间窗 `[start, end)`。优先使用用户指定或已确认的租户时区，缺省用北京时间并注明。首批按小时聚合，多天对比按相同本地时段对齐。解释选定峰值时再缩小时间粒度。 [公共查询规则](../../common/queries.md#查询约束)
+
+## 首批查询与统计口径
+
+趋势优先用服务端聚合。需要对账或跨 span 关联时，用 Query Builder 点名字段，保留原始时间和 trace/span ID。只有分页和覆盖已核对的原始记录才用于总体统计。 [查询例子](../../common/topics/query-example.md) · [更新计数口径](../conclusions.md#计数对账)
+
+| 报告指标 | 首批信号与字段 | 统计口径 |
+|---|---|---|
+| 观测到的更新链 | `dispatch_submit` 的 `dagId`、`updateScene`、`totalSize`、`corpId` | 按提交开始时间分桶，桶内及全窗总量各自按 `dagId` 去重。分场景用原始 `updateScene`。`totalSize` 是链涉及的表规模 |
+| 主队列消费次数 | 主队列 `node-task-queue receive` 的 `corpId`、`tableId` | 按消费开始时间数 span。一次消费计一次，同一明细重新投递后再次消费也计入 |
+| 表更新执行次数 | 归属已核对的 `dispatch_node_task_exec` | 按节点开始时间数 span。每次进入业务执行计一次，同一表可以多次执行 |
+| 表更新业务耗时、执行场景、表结果行数 | 外层 `update` 的 `businessConsumed`、`updateType`、`rowCount`、`tableId`、`tableName`、`dagId` | 有业务耗时值的记录计入分位数和表级频次。按原始 `updateType` 分组统计全窗和峰值，并分别给出该口径的分母。表结果行数取对应更新的有效值 |
+| 写入任务接收行数、引擎上报输出量 | 经核对的更新写入 `execute` 上的 `write.metric.*` | 按写入尝试开始时间分桶，汇总有效指标。过滤条件见[写入规模](#写入规模) |
+
+主队列 span 名可能带部署前缀。短名精确查空时，在同一环境、服务和短时间窗内用 `name CONTAINS 'node-task-queue receive'` 按名称聚合，再选实际的主队列名称。慢队列的消费另计。节点执行 span 能按 `corpId` 归属且与短窗明细对账时，可直接聚合数量。节点 span 和外层 `update` 的耗时字段、起点及覆盖分别核对。
+
+### 写入规模
+
+在目标服务和短窗内，先用实际父子 span 核对 `dispatch_node_task_exec → DataFlowExecutor → execute`，并检查 `corpId` 在写入 span 上的覆盖。条件对账后，在同一服务按租户筛 `name = 'execute' AND write.metric.parsed = true AND write.metric.skipped = false AND write.metric.received > 0`。按需取 `count()`、`sum(write.metric.received)` 和 P50、P95、P99。输出量仅汇总有有效 `write.metric.output_data_mb` 的记录，单列覆盖。`execute` 无法确认属于更新时，只报告可确认的写入范围。 [写入指标字段](events-outcome.md#写入指标)
+
+接收行数会累计重复处理。落盘行数单看有覆盖的 `write.metric.persisted`，报告其有效记录数。无有效值时标明缺少落盘量覆盖。`update.rowCount` 用来描述表结果大小，Polars 样本的扫描与写出行数用来描述该次任务做了多少工作。取 `rowCount` 前确认目标环境的字段类型和存在性，字段未返回时保留未知。 [更新结果字段](events-outcome.md#primary-node-result) · [Polars 读写指标](../../engine/topics/metric-fields.md#读表输出和写表)
+
+## 核对提交归属与窗口覆盖
+
+主队列消费明确写入 `corpId`、`tableId`。`dispatch_submit` 显式写入 `dagId`、`totalSize` 和 `updateScene`，企业标签依赖通用 trace 逻辑补写。先用当前环境样本确认按 `corpId` 直接过滤提交的覆盖，再用已确认的消费、执行或来源记录对账。通过实际父子关系、原生 span link、明细 ID 或明确的 `dagId` 关联。一个 `linked` trace 下有多个候选时，用业务标识消歧。 [关联规则](correlations.md#关联边) · [独立 Trace 的显式链接](../../common/topics/linked-traces.md#独立-trace-的显式链接)
+
+从消费端回查只能发现已观察到消费的链，窗口末尾尚未消费的提交会漏掉，窗口内也可能消费更早提交的链。提交、消费和执行分别按自己的事件时间入桶。归属或覆盖不足时用「已观察到的更新链」，队列消费趋势按自身口径保留。查询限额、分页、保留期和字段缺失分别记录，只有已核对覆盖的空桶才按零值呈现。 [判断覆盖范围](../conclusions.md#选择运行与阶段测量)
+
+## 按现象补查
+
+1. **追峰值来源。** 先比较同一小时的提交链量、场景占比和表更新执行量，再按 `dagId` 或实际关联下钻对峰值贡献大的链。提交用 `updateScene`，执行用外层 `updateType`，各报自己的分母。场景缺失时找同次执行的来源记录，仍缺则保留「场景未知」。没有明确高峰时看整个已覆盖窗口。 [场景入口](scene-producers.md)
+2. **查同步批次。** `SCHEDU` 或 `CALL_BACK` 成批出现时，可核对配置触发、同步结束、释放和提交的时间。区分同一表作为触发来源或依赖链下游。想判断全量或增量时按来源表、连接及执行记录确认实际模式；只能对到批次时，报告到批次。 [同步组与同步方式](datasource-update-patterns.md)
+3. **选典型表。** 分别从单次写入规模、执行频次和慢执行中选少量可核对的代表。写入样本从 `execute` 沿父子链回到外层 `update`，补表名、ID、场景和对应结果行数。高频按同口径记录数比较；慢表尽量选同表、同场景的较快执行对照。报告候选来自全窗聚合还是峰值抽样，写清入选理由。
+4. **拆耗时。** 在相同口径下并列样本数和业务耗时 P50、P95、P99；中位数相近时继续看长尾。对选定样本按精确 task 取少量 Polars Metric，比较读了多少行、做了什么、写出多少、排队和执行耗时。按同一更新对齐重试，逐次记录失败原因、重试间隔及最后一次执行。并行线程的等待只做可比指标，不能相加成任务耗时。 [引擎任务查询](../../engine/queries.md#metric-链接与任务日志)
+
+### 排队发生在哪
+
+| 要区分的环节 | 判断依据 |
+|---|---|
+| 调度侧主队列等待 | 对齐同一投递的发布和主队列开始消费时间。主队列消费量反映处理次数，等待时长另算 |
+| 调度侧租户限流转慢队列 | 按租户精确匹配 `Tenant limit exceeded` 日志统计转发次数。选少量执行明细，用 `executeId` 对到慢队列消费和返回主队列。慢队列消费缺租户属性，只有明确归属的记录才能用于租户结论。 [限流转发](events-execution.md#capacity-deferred) |
+| 引擎侧资源组排队或重试 | 对到同一次更新内的引擎尝试，再用引擎任务阶段耗时或同次错误日志确认。 [引擎交接](events-outcome.md#engine-handoff) |
+
+消费次数明显抬升而执行量接近时，先比较同一时段的租户限流转发次数，必要时再查锁与合并。引擎排队和调度侧慢队列可以在同一窗口同时出现，分别报告各自范围。 [更新性能片段](correlations.md#性能片段)
+
+## 画像总结
+
+画像以企业为单位。先用一句话概括窗口里最突出的更新特征，再按下表挑有证据支持的事实。每条结论写出它对应的时段、数量或对照。涉及个人操作时，使用明确的发起人或来源事件记录。
+
+| 画像维度 | 怎样从统计结果归纳 |
+|---|---|
+| 更新规模与节奏 | 写出观察到的链量、最集中的时段和对应数量。单日描述当日分布。多日比较相同本地时段，写明峰值在几个可比日期出现过，按实际覆盖区分反复出现和偶发峰值 |
+| 主导来源 | 比较全窗口和峰值时段的场景。并列实际增加的链数、执行数及其分母，保留场景未知的数量 |
+| 任务规模与耗时 | 用有覆盖的结果行数、写入规模和耗时分布描述任务。抽样解释计算或耗时差异时，写出样本日期、场景和对应表 |
+| 关注表与耗时问题 | 分开列值得关注的表和已观察到的耗时问题。表给名称、ID、频次、规模和入选理由。问题给发生位置、时段、表或企业范围、对照证据。样本中未发现明确瓶颈时交代已观察的范围 |
+
+例如「5 个可比日期里有 4 天在 10:00–11:00 出现峰值，增加的链主要是 `SCHEDU`」。要区分计划集中和同步组集中释放，再看对应的计划和释放记录。
+
+最后按影响和证据给建议，写明适用前提及复核指标。比如确认计划配置集中后，可以评估错峰，复核峰时链量、队列等待和数据更新时间。关联或覆盖有缺口时，先交付已确认的画像，说明哪条解释仍待确认。 [诊断结果交付](../../../docs/diagnostic-report.md)

package/content/knowledge/update/topics/enterprise-report.md

@@ -0,0 +1,63 @@
+# 企业更新报告交付
+
+按[企业更新负载分析](enterprise-analysis.md)取得单租户证据后，将可复核的统计、简短结论和覆盖写成版本 1 JSON，再渲染成单文件 HTML。页面标题为「企业更新负载报告」。按小时的柱子对齐比较日期，点选峰值查看场景和占比。全窗口分别用饼图展示提交链和执行记录的场景构成，按各自覆盖计算占比。完整明细保留原始 `UpdateScene`。报告包含单日画像、高峰来源、任务执行、关注表与耗时问题四块，以及指标口径。
+
+## 固定 JSON 格式
+
+所有字段都要写出，数值用原始单位。未取得的数据用 `null`，覆盖已确认的零值用 `0`。列表无可列项目时用 `[]`。文中已有脱敏规则同样适用于 JSON 和 HTML。范围和摘要使用业务语言，覆盖说明写清统计对象、缺失或仅抽样的范围。
+
+| 根字段 | 内容 |
+|---|---|
+| `schemaVersion` | 整数 `1` |
+| `scope` | `tenant` 为可交付的租户标识，`environment` 为环境名，`start`、`end` 为绝对窗口，`timezone` 为展示时区 |
+| `summary`、`coverage` | 一段简短结论、一个覆盖说明字符串数组 |
+| `totals`、`hours` | 全窗统计、按小时的分桶列表 |
+| `sources` | 全窗场景构成和有证据的峰值明细 |
+| `execution` | 执行摘要、分位数和少量关联到同次更新的 Polars 样本 |
+| `attention` | 典型表、耗时问题、可观察范围和下一步核对 |
+
+### 时间桶和场景
+
+- 所有时间写 `YYYY-MM-DDTHH:mm:ss+08:00` 这样的带偏移时间，偏移取展示时区在该时点的实际值。范围是 `[start, end)`。`hours` 按实际时间顺序列连续的本地整点桶，覆盖整个窗口。边界只覆盖部分小时用 `partial`，完整小时用 `complete`，无观测的桶用 `missing`。整个趋势均缺时 `hours` 可用 `[]`。
+- `totals` 含 `chains`、`executions`、`queueConsumes`、`receivedRows`、`slowQueueTransfers` 和 `outputMiB`。`hours` 每项是 `{start, coverage, metrics}`，`metrics` 含同样的键，省去 `outputMiB`。前五项是非负整数或 `null`，`outputMiB` 是非负数或 `null`。`missing` 桶的各指标均用 `null`。整窗与分桶按各自覆盖核对，更新链总量按全窗去重。
+- 场景列表的每项是 `{scene, count}`，`scene` 为原始值或 `null`（场景未知），`count` 为非负整数。一份列表里同一场景合并成一项。整组场景统计缺失时，整份列表用 `null`。
+- `sources` 含 `summary`、`chainsByScene`、`executionsByScene`、`peaks`。前两组是全窗聚合，分别按提交和执行口径计算；在饼图展示各自的前五个场景和其余场景，展开可查全量明细。一整组统计未取得时填 `null`，报告在组级说明缺口。峰值每项是 `{label, summary, hours}`，其中 `hours` 每项是 `{start, chainsByScene, executionsByScene}`。`start` 精确引用上面的时间桶。需要对比多日同期时把同一时段的各天整点放入一个峰值。没有明确峰值或缺少峰值来源时 `peaks` 可用 `[]`，渲染时展示全窗场景。
+
+### 执行和明细
+
+- `execution` 含 `summary`、`distributions`、`polarsSamples`。分位数每项是 `{metric, scope, sampleCount, p50, p95, p99}`，`metric` 用 `businessMs` 或 `receivedRows`，单位为毫秒或行。`scope` 给本次统计范围，`sampleCount` 给有效记录数。小样本的未展示分位数用 `null`。
+- `polarsSamples` 每项是 `{at, tableName, tableId, scene, calculation, scannedRows, writtenRows, resultRows, businessMs, outputMiB}`。`at` 为样本执行开始时间，`tableName` 或 `tableId` 至少一项有值。能确认什么就填什么。`resultRows` 取对应表结果，扫描和写出取同次 Polars 统计。
+- `attention` 含 `tables`、`latencySummary`、`latency`。关注表每项是 `{name, id, scenes, executionCount, resultRows, resultAt, reason, evidence, nextCheck}`。表名或 ID 至少一项有值，场景沿用场景列表格式。`resultAt` 是该结果观测时间，`reason`、`evidence` 写可核对的入选理由和记录。
+- 耗时问题每项是 `{stage, scope, finding, evidence, limits, timeline}`。`stage` 用 `mainQueue`、`slowQueue`、`engineResourceGroup`、`engineWrite` 或 `other`，对应实际发生位置。`scope` 交代时间和对象。`timeline` 每项是 `{kind, label, durationMs}`，`kind` 用 `failed`、`wait`、`succeeded` 或 `other`，仅在时间线已核对时填。缺少可关联证据时保留聚合，在 `coverage` 或 `limits` 写明范围。只有覆盖支持时才在 `latencySummary` 写「观察范围内未见明确瓶颈」。
+
+以下是缺少小时和关联明细时仍可交付的完整输入。`summary` 及各说明填本次真实观察。
+
+```json
+{
+  "schemaVersion": 1,
+  "scope": {
+    "tenant": "示例租户", "environment": "work", "timezone": "Asia/Shanghai",
+    "start": "2026-11-01T09:00:00+08:00", "end": "2026-11-02T09:00:00+08:00"
+  },
+  "summary": "观察到 2 条更新链。小时分布及执行关联待核对。",
+  "coverage": ["仅有可归属的提交汇总。"],
+  "totals": {
+    "chains": 2, "executions": null, "queueConsumes": null,
+    "receivedRows": null, "slowQueueTransfers": null, "outputMiB": null
+  },
+  "hours": [],
+  "sources": {"summary": null, "chainsByScene": [{"scene": "SCHEDU", "count": 2}], "executionsByScene": null, "peaks": []},
+  "execution": {"summary": null, "distributions": [], "polarsSamples": []},
+  "attention": {"tables": [], "latencySummary": null, "latency": []}
+}
+```
+
+## 渲染和交付
+
+将 JSON 保存为 `enterprise-update-report.json`。源码目录从仓库根目录运行以下命令，输出目录默认是 JSON 所在目录，也可显式传 `--output-dir`。
+
+```sh
+python3 scripts/render_enterprise_update_report.py /path/to/enterprise-update-report.json
+```
+
+安装副本用 [固定版本的 Python 入口](../../../AGENTS.md#安装副本的助手规则)，把 `python3` 替换为 `<node> <pinned_cli> python`，脚本路径以 `content_root` 为准。调查文件和报告写到会话目录。渲染器只用 Python 标准库。脚本输出 `enterprise-update-report.html` 的路径，同一份 JSON 生成相同 HTML。数据、样式和交互脚本内联，静态预览可离线显示默认柱图、饼图和明细，支持脚本的浏览器可切换指标和日期。格式错误时按报出的字段修正输入。交付时给 HTML 链接和简短结论，交代证据缺口。

package/content/knowledge/update/topics/events-execution.md

@@ -53,7 +53,7 @@
   - 慢队列只有一个消费者，每收到一条打 `receive executeInfo at slow queue`；额度可用就发回主队列，仍不可用就再发回慢队列，如此循环，所以一条消息在慢队列里可能出现很多次。
   - 慢队列消费不开 `update` trace，也没有 `corpId`、`tableId`。
 - 分支：收到关闭信号时把消息重新发回慢队列；其他异常只记 ERROR，不重发。
-- 不能说明：慢队列每转一圈是一次重排队，不是一次执行尝试；日志条数多只说明等得久，不说明有多少个不同节点。
+- 慢队列消费日志按每次收到消息计数。用 `executeId` 对齐转发、慢队列消费和后续主队列消费，才能观察同一明细的等待或重复投递。消息次数、等待时长和不同节点数量分别统计。
 
 ## lock-requeued
 

package/content/knowledge/update/topics/events-outcome.md

@@ -87,10 +87,24 @@ REF 不写数据，而是选定来源的一个版本，给它打保护 tag，再
   - 结果里的 `taskId` 会写进节点结果埋点。
 - 分支：
   - 可重试的引擎失败：服务端可以重试，每次重试产生新的引擎任务 ID，成功结果只暴露最后返回的那个。
+  - 同次更新日志的 `exception.type` 类名为 `ResourceGroupQueueTimeoutException` 时，可以确认该引擎尝试发生资源组排队超时。按 `execute` span 对齐各次尝试，重试间隔另算。
   - 数据源湖（MPP）写入遇到引擎任务内存不足：允许重试一次，并把流水线并行度降为 1，同时写 `compute.retry.pipeline_parallelism_reduced`。这只针对这一类写入，不是所有 OOM 的通用重试策略。
   - 引擎写入失败：事务回滚，服务端加载失败；要继续追查，需要具体的引擎任务或请求标识，否则停在服务端边界。
 - 不能说明：直通、不活跃、不需要加载等没有引擎任务；失败或重试过的任务不会都留下标识，引擎内部细节不在这里。
 
+### 写入指标
+
+`write.metric.*` 来自引擎返回的写入统计解析，随当前 `execute` span 记录。字段能否用于聚合取决于目标环境和写入路径的覆盖。原始回传在 `write_metric`。
+
+| 字段 | 含义 |
+|---|---|
+| `write.metric.parsed`、`write.metric.skipped` | 是否解析成功、引擎是否跳过写入 |
+| `write.metric.received` | 写入器收到的行数 |
+| `write.metric.persisted` | 引擎回报的实际写入行数。负值表示缺少有效计数 |
+| `write.metric.output_data_mb` | 引擎回报的输出大小，按 MiB 记录，负值表示缺少有效计数 |
+
+对照表结果时使用同次更新的 `rowCount`；需要确认引擎任务实际扫描与写出多少时取对应 Polars Metric。 [任务读写规模](../../engine/topics/metric-fields.md#读表输出和写表)
+
 ## primary-node-result
 
 节点执行得出的主结果：成功或失败。这一步之后才会通知监听器、释放子节点。

package/content/knowledge/update/topics/scene-producers.md

@@ -70,10 +70,9 @@
 
 ## SCHEDU
 
-- 定时任务：数据源计划创建一次带定时标记的同步任务。回调处理按表级 bundle 或旧同步任务条件放行，bundle 扫描器可能更早释放已成功的表，不必等全部 bundle 结束。
+- 数据源计划创建带定时标记的同步任务。表级路径可以提前释放已成功的表，旧路径等待整组结束。 [定时同步如何释放](datasource-update-patterns.md#定时同步如何释放)
 - 消息或回调：DM 完成回调只含定时结果时启动定时同步；只有不支持表级同步的 bundle 走这条旧回调。
 - 接口请求：DM 表级流状态通知。按 bundle 能力和状态决定是否更新一次：只调度已完成、非重复的工作，未完成的把分组标记为失败。定时标记决定是 SCHEDU 还是 MANUAL_UPDATE。
-- 定时任务：同步分组里有可增量释放的成功记录时，收集这些表及子表，按场景分组、跨 bundle 合并后调度；提交成功才删分组记录。扫描器释放和回调完成是两条路径，回调次数不等于更新次数。
 
 ## FOLDER_COPY
 
@@ -144,7 +143,7 @@
 
 ## CALL_BACK
 
-- 消息或回调：数据源 webhook 回调报告数据已就绪，把回调标识翻译成分析表的根并调度更新。
+- 来源通知进入回调派发后，按回调标识映射到分析表并提交更新。适用来源、归并和派发条件见[回调如何归并与派发](datasource-update-patterns.md#回调如何归并与派发)。
 
 ## ARCHIVE
 

package/content/knowledge/update/workflow.md

@@ -1,12 +1,19 @@
 # 更新 · 排查入口
 
-分析表更新的记录看不懂，或者更新慢、失败时，从这里下手。常见的目标有两种：
+分析租户更新、解释分析表更新记录，或者排查更新慢和失败时，从这里下手。
 
-- **解释更新记录**：企业最近的更新情况、更新从哪来、request、chain/DAG、节点尝试、requeue、load、listener、engine task，或者核对计数。把记录里看得到的阶段事实讲清楚就够了，不用下最终根因。
+- **企业更新分析**：用户明确要单租户更新报告或 HTML，例如「分析 corp-xxx 租户近 3 天的更新情况，生成更新报告」。
+- **解释更新记录**：在对话里看企业近期更新情况、更新从哪来、request、chain/DAG、节点尝试、requeue、load、listener、engine task，或者核对计数。按问题解释记录中可见的阶段和事实。
 - **更新性能排查**：一次更新慢、超时、内存超限、OOM、资源消耗异常或性能回归。这类问题一般从[性能排查入口](../common/workflow.md)进来，在解释更新记录的基础上找出瓶颈阶段。
 
+## 企业更新分析
+
+- 确认单个租户、环境、时区和时间窗。已有同一范围的分析结果直接复用。按[企业更新负载分析](topics/enterprise-analysis.md)补齐需要的窗口聚合，再对有依据的峰值、典型表和耗时问题做有限补查。
+- 用[固定 JSON 和 HTML 报告](topics/enterprise-report.md)交付画像、峰值来源、任务执行、关注表与耗时问题。关联缺失时保留已取得的统计，并说明覆盖。
+
 ## 解释更新记录
 
+- 「分析 corp-xxx 租户近 3 天的更新情况」这类分析请求在对话中交付。需要窗口聚合时复用[企业更新负载分析](topics/enterprise-analysis.md)的相关取证方法，按用户的问题决定补查深度。
 - 先定下要解释哪些记录、用什么计数单位。request、chain、distinct node、attempt、load、engine task 要分开数，见[计数单位与身份](concepts.md#计数单位与身份)。手上有精确的 trace、chain、task 就直接用，不用重新找。
 - 只有企业 ID 或 dagId、还没找到具体执行时，按[从企业或 DAG 定位更新执行](topics/discover-executions.md)找候选。企业命中消费 span 之后，顺着已有的显式链接去查关联的更新。
 - 看不懂字段、阶段或关联时，按 [README](README.md) 选槽位，只读用得上的部分。这次记录能证明什么、不能证明什么见[能下什么结论](conclusions.md)：每条关联边都要有它声明的原生关系或显式键，缺一条就停在最后证实的边界；同租户、同表名、时间挨着，只能用来筛候选。

package/content/scripts/enterprise_update_report.template.html

@@ -0,0 +1,178 @@
+<!doctype html>
+<html lang="zh-CN">
+<head>
+<meta charset="utf-8">
+<meta name="viewport" content="width=device-width, initial-scale=1">
+<meta http-equiv="Content-Security-Policy" content="default-src 'none'; script-src 'unsafe-inline'; style-src 'unsafe-inline'; base-uri 'none'; form-action 'none'">
+<title>企业更新负载报告</title>
+<style>
+:root{color-scheme:light;--bg:#f2f5f7;--ink:#152a35;--muted:#50656f;--line:#dbe6ea;--green:#007566;--tint:#eaf5f1;font-family:Inter,"PingFang SC","Microsoft YaHei",system-ui,sans-serif}
+*{box-sizing:border-box}
+body{margin:0;background:var(--bg);color:var(--ink);font-size:14px;line-height:1.55}
+main{max-width:1240px;margin:auto;padding:34px 28px 52px}
+h1,h2,h3,p{margin:0}
+h1{font-size:clamp(28px,4vw,46px);letter-spacing:-.04em;line-height:1.2;margin:8px 0 10px}
+h2{font-size:23px;letter-spacing:-.025em}h3{font-size:16px}
+small,.note{font-size:12px;color:var(--muted)}
+#scope{color:var(--muted);font-weight:650}
+#summary{font-size:16px;max-width:940px}
+nav,.controls,.legend{display:flex;align-items:center;gap:8px 12px;flex-wrap:wrap}
+nav{margin:13px 0}nav a{font-size:13px;color:#28515d;text-underline-offset:3px}
+.kpis{display:grid;grid-template-columns:repeat(4,minmax(0,1fr));gap:10px;margin:18px 0 12px}
+.kpi,.panel{background:#fff;border:1px solid var(--line);border-radius:12px}
+.kpi{padding:12px 14px}.kpi small,.kpi b{display:block}.kpi b{font-size:clamp(18px,3vw,28px);font-variant-numeric:tabular-nums}
+.panel{padding:17px 19px;margin-top:12px;scroll-margin-top:12px}
+.heading{display:flex;justify-content:space-between;align-items:start;gap:8px 16px;flex-wrap:wrap;margin-bottom:10px}
+button,select{font:inherit;font-size:13px;color:var(--ink);background:#fff;border:1px solid var(--line);border-radius:7px;padding:5px 8px}
+button,select,summary{cursor:pointer}
+button:focus-visible,select:focus-visible,a:focus-visible,summary:focus-visible,.bar:focus-visible{outline:2px solid var(--green);outline-offset:2px}
+[hidden]{display:none!important}
+.legend{color:var(--muted);font-size:12px;margin-bottom:8px}
+.legend i{display:inline-block;width:8px;height:8px;margin-right:5px;border-radius:2px}
+.chart-scroll,.table-wrap{overflow-x:auto}
+.chart-grid{display:grid;grid-template-columns:49px minmax(0,1fr);grid-template-rows:175px 23px;min-width:680px;padding:16px 0 0}
+.y-axis{grid-column:1;grid-row:1;display:flex;flex-direction:column;justify-content:space-between;text-align:right;padding-right:6px;color:var(--muted);font-size:11px;line-height:1}
+.plot{grid-column:2;grid-row:1;display:grid;border-bottom:1px solid #bacdd5;background:repeating-linear-gradient(to top,transparent 0,transparent calc(25% - 1px),#e9eff2 calc(25% - 1px),#e9eff2 25%)}
+.hour-labels{grid-column:2;grid-row:2;display:grid;text-align:center;color:var(--muted);font-size:10px;padding-top:4px}
+.hour-slot{position:relative;display:flex;align-items:end;justify-content:center;gap:1px;padding:0 3px;min-width:0}
+.hour-slot.peak{background:#e7f4ef99}
+.hour-labels .peak{color:#006658;font-weight:750}
+.bar{width:100%;min-width:0;max-width:24px;padding:0;border:0;border-radius:2px 2px 0 0;background:var(--bar);height:var(--height);flex:1;position:relative}
+.bar.partial{opacity:.64;background:repeating-linear-gradient(135deg,var(--bar) 0 3px,#fff 3px 4px)}
+.bar.zero{height:2px}.bar.missing{height:2px;background:transparent;outline:1px dotted #9eb2ba}
+.peak-value{position:absolute;left:50%;transform:translateX(-50%);bottom:calc(var(--peak-height) + 2px);font-size:10px;font-weight:700;color:#005d50;white-space:nowrap;pointer-events:none}
+.chart-readout{margin:6px 0;min-height:1.5em}
+.chips{display:flex;flex-wrap:wrap;gap:5px 7px;align-items:center;margin-top:6px}
+.chip{background:#edf3f6;color:#314b58;padding:2px 8px;border-radius:20px;font-size:12px}
+.table-wrap{margin-top:8px}
+table{width:100%;border-collapse:collapse;text-align:left;font-variant-numeric:tabular-nums}
+th,td{padding:7px 9px;vertical-align:top;border-bottom:1px solid var(--line)}
+th{color:var(--muted);background:#f3f7f8;white-space:nowrap;font-size:12px;font-weight:660}
+td{font-size:13px}tr:last-child td{border-bottom:0}
+.numeric{white-space:nowrap}
+.table-id{display:block;color:var(--muted);font-size:11px;overflow-wrap:anywhere;margin-top:2px}
+.peak-links a{color:#006254;text-underline-offset:3px}.source-detail{margin-top:8px;border-top:1px solid var(--line);padding-top:8px;scroll-margin-top:12px}
+.source-row{display:grid;grid-template-columns:1fr 1.55fr;gap:14px;align-items:start}
+.scene-distributions{display:grid;grid-template-columns:repeat(2,minmax(0,1fr));gap:12px;margin-top:10px}
+.scene-distribution{border:1px solid var(--line);border-radius:9px;padding:11px 13px}
+.scene-pie-layout{display:flex;align-items:center;gap:14px;margin-top:10px;flex-wrap:wrap}
+.scene-pie{width:124px;height:124px;border-radius:50%;flex:none}
+.scene-pie-legend{list-style:none;margin:0;padding:0;flex:1;min-width:160px}
+.scene-pie-legend li{display:grid;grid-template-columns:9px minmax(0,1fr) auto;gap:6px;align-items:center;font-size:12px;margin:3px 0}
+.scene-pie-legend i{width:8px;height:8px;border-radius:2px}.scene-pie-legend code{overflow-wrap:anywhere}
+.scene-pie-legend span{font-variant-numeric:tabular-nums;white-space:nowrap}.scene-total{margin-top:6px}
+.readout{background:#f0f7f5;border:1px solid #dbeae6;border-radius:8px;padding:8px 10px;margin:9px 0}
+.after{margin-top:15px}
+.scope-table td:first-child{min-width:135px}
+#attention-tables td:first-child{min-width:175px}
+details summary{font-weight:650}
+.timeline{min-width:160px;margin:6px 0;display:flex;height:8px;border-radius:4px;overflow:hidden;gap:2px}
+.timeline span{background:#8d9aa1}.timeline .failed{background:#b34e35}.timeline .wait{background:#b2bdc4}.timeline .succeeded{background:#148073}
+.timeline-labels{min-width:180px}
+ul{padding-left:20px;margin:6px 0}
+@media(max-width:740px){main{padding:20px 12px 38px}.panel{padding:13px}.kpis{grid-template-columns:repeat(2,minmax(0,1fr))}.source-row,.scene-distributions{grid-template-columns:1fr}.chart-grid{grid-template-rows:143px 22px}}
+</style>
+</head>
+<body>
+<main>
+<header>
+<p id="scope">__REPORT_SCOPE__</p>
+<h1>企业更新负载报告</h1>
+<p id="summary">__REPORT_SUMMARY__</p>
+<nav aria-label="报告板块">
+<a href="#overview">单日更新画像</a><a href="#origins">高峰更新来源</a><a href="#execution">任务执行情况</a><a href="#attention">关注表与耗时问题</a><a href="#definitions">指标口径</a>
+</nav>
+</header>
+<div class="kpis" id="kpis" aria-label="窗口内指标">__REPORT_KPIS__</div>
+<section id="overview" class="panel">
+<div class="heading">
+<div><h2>单日更新画像</h2><p class="note">同一小时并排比较。斜纹为部分覆盖，点线表示缺少该指标。</p></div>
+__REPORT_CONTROLS__
+</div>
+<div id="chart" role="group" aria-label="按小时分组柱状图">__REPORT_CHART__</div>
+<p id="chart-readout" class="note chart-readout" aria-live="polite">悬停柱子可查看小时数值。</p>
+<div id="peak-links" class="controls peak-links">__REPORT_PEAK_LINKS__</div>
+<div id="overview-scenes" class="chips"><span class="note">全窗更新链场景</span>__REPORT_SCENES__</div>
+</section>
+<section id="origins" class="panel">
+<div class="heading"><h2>高峰更新来源</h2></div>
+__REPORT_SOURCES__
+</section>
+<section id="execution" class="panel">
+<div class="heading"><h2>任务执行情况</h2></div>
+__REPORT_EXECUTION_SUMMARY__
+<div class="table-wrap">
+<table><thead><tr><th>指标</th><th>范围</th><th>有效记录</th><th>P50</th><th>P95</th><th>P99</th></tr></thead><tbody id="distributions">__REPORT_DISTRIBUTIONS__</tbody></table>
+</div>
+<h3 class="after">抽查的 Polars 执行</h3>
+<div class="table-wrap">
+<table><thead><tr><th>分析表与执行时间</th><th>任务做了什么</th><th>扫描行数</th><th>写出行数</th><th>分析表结果行数</th><th>表更新业务耗时</th></tr></thead><tbody id="samples">__REPORT_SAMPLES__</tbody></table>
+</div>
+</section>
+<section id="attention" class="panel">
+<div class="heading"><h2>关注表与耗时问题</h2></div>
+<h3>值得关注的表</h3>
+<div class="table-wrap">
+<table><thead><tr><th>表名与 ID</th><th>场景与执行次数</th><th>最近可见结果</th><th>关注原因与证据</th><th>可继续核对</th></tr></thead><tbody id="attention-tables">__REPORT_TABLES__</tbody></table>
+</div>
+<h3 class="after">观察到的耗时问题</h3>
+__REPORT_LATENCY_SUMMARY__
+<div class="table-wrap">
+<table><thead><tr><th>发生位置</th><th>时段与范围</th><th>问题</th><th>证据</th><th>结论范围</th></tr></thead><tbody id="latency">__REPORT_LATENCY__</tbody></table>
+</div>
+</section>
+<section id="definitions" class="panel">
+<div class="heading"><h2>指标口径与数据来源</h2></div>
+<ul id="coverage" class="note">__REPORT_COVERAGE__</ul>
+<div class="table-wrap scope-table">
+<table><thead><tr><th>报告指标</th><th>数据来源</th><th>统计方式</th></tr></thead><tbody>
+<tr><td>观测到的更新链</td><td><code>dispatch_submit</code> 的 <code>dagId</code>、<code>updateScene</code></td><td>在可归属的提交中按链 ID 去重。场景保留原始值。</td></tr>
+<tr><td>表更新执行次数</td><td><code>dispatch_node_task_exec</code></td><td>一个表更新节点进入业务执行计一次。按场景分组用外层 <code>update.updateType</code>，覆盖可能与执行总数不同。</td></tr>
+<tr><td>主队列消费次数</td><td>主队列的 <code>node-task-queue receive</code></td><td>主队列每处理一条投递计一次。同一明细再次消费会再计。</td></tr>
+<tr><td>调度侧转入 slow node queue</td><td><code>Tenant limit exceeded</code>、<code>receive executeInfo at slow queue</code></td><td>按租户统计并发额度不足时的转发，按执行明细核对慢队列消费和回主队列。慢队列消费次数单独取证。</td></tr>
+<tr><td>引擎资源组排队</td><td>同一次更新的引擎任务与日志，如 <code>ResourceGroupQueueTimeoutException</code></td><td>按该次任务阶段耗时或同次错误日志确认，逐次记录重试和等待。</td></tr>
+<tr><td>写入任务接收行数与输出量</td><td><code>write.metric.received</code>、<code>write.metric.output_data_mb</code></td><td>汇总已解析、未跳过且接收行数为正的写入。输出量按有效上报的 MiB 换算。实际落盘量另看对应字段的覆盖。</td></tr>
+<tr><td>表更新业务耗时与结果行数</td><td><code>update.businessConsumed</code>、<code>update.rowCount</code></td><td>耗时分位数只使用有值的记录。结果行数取对应更新时点。</td></tr>
+<tr><td>Polars 扫描与写出行数</td><td>同一次任务的 <code>scanned_rows_num</code>、<code>writtenRows</code></td><td>记录抽样任务读入和写出的规模。</td></tr>
+</tbody></table>
+</div>
+</section>
+</main>
+<script type="application/json" id="report-data">__REPORT_DATA__</script>
+<script>
+"use strict";
+const controls = document.getElementById("chart-controls");
+if (controls) {
+  const day = document.getElementById("day");
+  const measure = document.getElementById("measure");
+  const readout = document.getElementById("chart-readout");
+  const charts = document.querySelectorAll("#chart [data-metric]");
+  const dated = document.querySelectorAll("#chart [data-day]");
+  function selectChart() {
+    for (const chart of charts) chart.hidden = chart.dataset.metric !== measure.value;
+    for (const item of dated) {
+      item.hidden = item.classList.contains("peak-value")
+        ? item.dataset.day !== day.value
+        : Boolean(day.value && item.dataset.day !== day.value);
+    }
+    readout.textContent = "悬停或聚焦柱子查看这一小时的数值。";
+  }
+  for (const bar of document.querySelectorAll("#chart .bar[title]")) {
+    const announce = () => { readout.textContent = bar.title; };
+    bar.addEventListener("focus", announce);
+    bar.addEventListener("pointerenter", announce);
+  }
+  day.addEventListener("change", selectChart);
+  measure.addEventListener("change", selectChart);
+  selectChart();
+  controls.hidden = false;
+}
+for (const link of document.querySelectorAll('a[href^="#peak-"]')) {
+  link.addEventListener("click", () => {
+    const details = document.getElementById(link.hash.slice(1));
+    if (details) details.open = true;
+  });
+}
+</script>
+</body>
+</html>