真问-2 - gcd

1、rag 的一整条开发链路是什么样的？

先划清一个概念，否则第 1、2 题会混：

开发链路（本题）= 离线建库：把原始资料变成可检索的知识库。发生在用户提问之前，是批处理，慢一点没关系。
查询链路（第 2 题）= 在线问答：用户来一条 query，实时走检索 + 生成。发生在用户提问当时，对延迟敏感。

一句话总览：开发链路是一条 数据接入 → 解析 → 切分 → 向量化 → 写入向量库 + 建索引 的 ETL 流水线，本质和你熟的数仓 ETL 是一回事，只是「事实表」换成了「向量 + 原文分片」。

flowchart LR
    A[原始数据源<br/>PDF/网页/DB/工单] --> B[解析 Parse<br/>抽成纯文本+结构]
    B --> C[清洗 Clean<br/>去噪/去重/脱敏]
    C --> D[切分 Chunk<br/>切成检索单元]
    D --> E[向量化 Embed<br/>chunk→向量]
    E --> F[(向量库 + 元数据<br/>写入并建 ANN 索引)]
    D -.原文与元数据.-> F
    F --> G[评测 Eval<br/>召回率/覆盖度回归]
    G -.不达标就回去调切分/embedding.-> D

下面逐环讲「是什么 / 为什么要有它 / 调不好会怎样」。

第 1 环：数据接入（Ingestion）

干什么：把散落在 PDF、Confluence、网页、数据库、工单系统里的原始资料拉进来。
关键决策：增量还是全量。知识库不是建一次就完事——文档会更新。要么定时全量重建（简单但贵、且有窗口期旧数据），要么按文档 更新时间/版本号 做增量 upsert（复杂但省）。这和你数仓里「全量快照 vs 增量合并」是同一个权衡。
翻车场景：没做去重，同一份 SOP 被三个部门各传一次，检索时前 3 条全是重复内容，等于浪费了给 LLM 的上下文预算。

第 2 环：解析（Parsing）

干什么：把各种格式抽成「纯文本 + 结构信息」。PDF 要处理分栏、表格、页眉页脚；HTML 要剥标签；扫描件要过 OCR。
为什么它是最被低估、最容易毁掉整条链路的一环：后面所有环节都建立在解析结果上。表格被解析成一行乱码，切分和向量化再准也没用——垃圾进，垃圾出。
关键产出：不只是正文，还有结构元数据（标题层级、所属章节、页码、来源 URL）。这些元数据在查询链路里用于「过滤」和「给 LLM 标引用出处」。

第 3 环：切分（Chunking）

干什么：把长文档切成小片（chunk），每片是一个独立的「检索单元」，会被单独向量化、单独召回。
为什么必须切——两个硬约束：
1. embedding 模型有最大输入长度（如 512 / 8192 token），整篇文档喂不进去。
2. 检索精度：一篇 5000 字的文档整体只有一个向量，语义被平均掉，query 只问其中一句话时匹配不上。切小了，每片语义集中，才召得准。
代价 / 权衡（这是切分的核心矛盾）：
- 切太小 → 单片语义完整但上下文丢失（一个指代 "它" 找不到主语），召回的片段拼不成完整答案。
- 切太大 → 上下文全但噪声多，且挤占 LLM 上下文窗口、embedding 被稀释。
- 常见折中：按语义边界切（段落 / 标题）而非按固定字数硬切，再加 chunk overlap（相邻片重叠 10–20%），让跨边界的句子不被切断。
翻车场景：按固定 500 字硬切，把一张「配置项-默认值」的表格从中间劈开，检索到上半张表，答案缺了默认值那一列。

第 4 环：向量化（Embedding）

干什么：每个 chunk 过 embedding 模型，得到一个定长向量（如 1024 维 float）。
关键约束：建库用的 embedding 模型，必须和查询链路查询时用的是同一个模型（同一版本）。因为向量空间是模型定义的，换了模型两边向量不在一个空间，相似度完全无意义。这是升级 embedding 模型时必须全量重建库的原因。
附带产出：除了稠密向量，很多方案同时抽 稀疏表示 / 关键词（BM25 用），为查询链路的「混合检索」备料（见第 2、3 题）。

第 5 环：写入向量库 + 建索引（Indexing）

干什么：把 (向量, 原文 chunk, 元数据) 三元组写进向量库，并对向量建 ANN 索引（近似最近邻）。
为什么要 ANN 而不是精确检索——因果链：query 来时要在几百万个向量里找最近的 k 个。精确算法要和每个向量都算一次距离，是 O(N)，百万级向量单次查询几百毫秒起，扛不住 QPS。ANN（如 HNSW、IVF）用图 / 倒排结构把复杂度降到近似 O(log N)，牺牲一点点召回准确率换几个数量级的速度。这是「用精度换延迟」的典型权衡，第 3 题会讲它的可调参数。
元数据要建标量索引（如按 dept、doc_type、update_time）——查询链路的「元数据过滤」靠它。

第 6 环：评测（Evaluation）——最容易被跳过、但决定链路能不能迭代

干什么：建完库不是终点。要有一组「标准问题 + 期望命中的 chunk」，跑一遍检索，量化召回率（该召的召回了几个）、命中率、上下文覆盖度。
为什么必须有：切分策略、chunk 大小、embedding 模型、索引参数每改一个，效果都会变。没有离线评测集，你就无法判断一次调整是变好还是变坏，只能凭感觉，迭代会原地打转。这等于数仓里「改了 ETL 逻辑要跑数据质量校验」。

常见误区纠正：很多人以为 RAG 开发就是「调 prompt」。prompt 在查询链路末端，属于第 2 题。RAG 效果的天花板在开发链路——解析和切分。检索不到正确片段，prompt 写得再好，LLM 也是无米之炊（甚至被迫编，即幻觉，见第 7 题）。

2、rag 的一整条用户 query -> 最终输出的链路是什么样的？

这是在线查询链路，对延迟敏感。一句话总览：query 改写 → 检索（向量+关键词）→ 重排 rerank → 组装上下文 → LLM 生成 → 后处理。

flowchart TD
    Q[用户 Query] --> R1[Query 改写/扩展<br/>纠错·多轮补全·拆子问题]
    R1 --> H{混合检索}
    H --> V[向量检索<br/>ANN topK]
    H --> K[关键词检索<br/>BM25 topK]
    V --> M[结果合并<br/>RRF 融合]
    K --> M
    M --> RR[Rerank<br/>Cross-Encoder 精排 topN]
    RR --> C[组装 Context<br/>拼 prompt + 截断]
    C --> L[LLM 生成]
    L --> P[后处理<br/>引用标注·敏感过滤·校验]
    P --> O[最终输出]

逐环讲，重点讲为什么每一环都存在——每一环都是在补前一环的漏。

第 1 环：Query 改写 / 理解

干什么：用户输入的 query 往往「不适合直接检索」。改写解决三类问题：
1. 口语化 / 错别字：规范化，提高与规范文档的匹配度。
2. 多轮指代：用户问「那它的默认值呢？」——「它」指上一轮的某配置项。要用对话历史把 query 补全成自包含的独立问句，否则检索无从下手。
3. 复杂问题拆解：一个 query 含多个子问题，拆开分别检索再汇总（进阶 RAG 的做法）。
代价：多一次 LLM 调用（改写通常用小模型），增加延迟。所以简单场景可跳过。

第 2 环：检索（Retrieval）——为什么要「混合」

向量检索擅长语义匹配（问「怎么防止任务失败重跑丢数据」，能召回讲「exactly-once」的片段，尽管没有一个字相同）。但它对精确关键词弱（专有名词、错误码、型号，语义泛化反而召不准）。
关键词检索（BM25）擅长精确 term 命中（错误码 SQLSTATE 42000、函数名），但完全不懂语义。
两者是互补短板，所以生产 RAG 普遍做 混合检索（Hybrid Search）：两路各召 topK，再融合。融合常用 RRF（Reciprocal Rank Fusion，倒数排名融合）——不依赖两路分数的绝对量纲，只用「排第几名」加权，避免向量的 cosine 分和 BM25 分不可比的问题。
检索前还可以做元数据过滤：只在 dept='风控' AND doc_type='SOP' 范围里检索。这既提精度又是权限隔离的一环（对接第 5 题）。

第 3 环：Rerank（重排 / 精排）——为什么召回还不够，要再排一次

问题背景：第 2 环的向量检索用的是 Bi-Encoder（双塔）——query 和 doc 各自独立编码成向量再算距离。双塔快（doc 向量可离线算好），但因为编码时两者互相看不见，精度有上限。
Rerank 用 Cross-Encoder（交叉编码）——把 query + 每个候选 chunk 拼在一起送进模型，让它们在注意力层充分交互，直接输出相关性分。精度高得多，但必须在线现算、且 query×doc 对数越多越慢，所以不能拿来做第一层检索。
因果链：所以是「召回层用便宜的双塔捞一批（topK=50），精排层用贵的交叉编码精挑（topN=5）」的两级漏斗——用双塔的速度扛住全量，用交叉编码的精度保住最终喂给 LLM 的那几条。这是整条链路里性价比最高的一环。

第 4 环：组装上下文（Context Assembly）

干什么：把 rerank 后的 topN chunk 按模板拼进 prompt，通常还要拼：系统指令、对话历史、每个 chunk 的来源元数据（供 LLM 标引用）。
硬约束：LLM 上下文窗口有限 + 越长越慢越贵。所以要截断 / 控制 topN。这里还有个坑叫 "lost in the middle"——LLM 对放在上下文中间的信息利用率低于开头和结尾，所以有的实现会把最相关的 chunk 放在最前和最后。

第 5 环：LLM 生成

干什么：LLM 基于「query + 检索到的上下文」生成答案。
关键 prompt 约束（直接影响幻觉率，见第 7 题）：明确要求**「只依据提供的资料回答，资料里没有就说不知道，不要编」，并要求标注引用来源**。这是 RAG 相对纯 LLM 的核心价值——答案可溯源。

第 6 环：后处理（Post-processing）

引用标注核对（LLM 标的出处和实际 chunk 对得上吗）、敏感信息过滤、格式化、必要时做答案校验（如再过一次 LLM 判断「这个答案是否被上下文支撑」，即 groundedness 检查）。

两条链路的接缝：开发链路的 embedding 模型、切分粒度，直接决定查询链路能召回什么。排查线上问答不准，第一件事是分清是「检索没召到」还是「召到了但 LLM 没用好」——前者回到开发链路（切分/embedding）或检索参数，后者是 rerank / prompt 问题。第 7 题的幻觉排查完全依赖这个切分。

3、rag 调优相关的所有参数

把参数按它在链路里的位置分组，每个参数记住三件事：往哪调、副作用、什么时候动它。没有「万能默认值」——所有参数都是在召回率 ↔ 精度 ↔ 延迟 ↔ 成本四个量之间做权衡。

A. 切分阶段（离线，开发链路）

参数	作用	调大的后果	调小的后果
chunk_size（片大小）	每个检索单元多长	上下文更完整，但语义被稀释、噪声多、挤占 LLM 窗口	语义集中召得准，但易丢上下文、片数暴涨
chunk_overlap（重叠）	相邻片重叠多少	跨边界句子不被切断，召回更稳；但存储和向量数变多	省存储，但边界句易被切碎
切分策略	按固定字数 / 按语义边界 / 按结构	——	按语义/结构切质量最高，固定字数最省事但最易切坏

经验值仅供参考、非定律：chunk_size 常在 256–1024 token，overlap 取 10–20%。必须用评测集验证（第 1 题第 6 环），不能照搬。

B. 检索阶段（在线）

参数	作用	往哪调
top_k（召回数）	向量/关键词各召回几条	调大：召回率↑但噪声↑、rerank 变慢；调小：快但可能漏。常召回 k=20~50 给 rerank
相似度阈值	低于此分的候选直接丢	调高：精度↑但可能一条都召不到（宁缺毋滥）；调低：召回全但混入无关
混合检索权重 / RRF k	向量 vs 关键词的融合比重	专有名词/代码多的库偏 BM25；自然语言问答偏向量
元数据过滤	检索前按 dept/时间/类型缩范围	强过滤提精度、也是权限隔离；过滤太狠会漏
ANN 索引参数	见下方单列	精度 ↔ 延迟的旋钮

ANN 索引参数（以 HNSW 为例，向量库层）——这是「用精度换延迟」的直接旋钮：

ef_search（查询时探索广度）：调大 → 召回更准但更慢；调小 → 快但可能漏近邻。在线延迟不达标时第一个调它。
ef_construction / M（建库时图的连接度）：建库时定，调大 → 索引质量高、召回准，但建库慢、内存大。属开发链路。

C. Rerank 阶段（在线）

参数	作用	往哪调
rerank top_n	精排后保留几条喂 LLM	调大：上下文全但慢、贵、可能触发 lost-in-the-middle；调小：省 token 但可能丢关键片。常 n=3~8
是否启用 rerank	——	召回质量差、或候选多时收益大；候选本就很准时可省这一跳延迟

D. 生成阶段（在线）

参数	作用	往哪调
temperature	生成随机性	RAG 事实问答调到 0 或接近 0——要确定性、不要发散，越发散越容易脱离资料编造
max_tokens	输出上限	太小答案被截断；太大延迟↑
prompt 模板	约束「无依据不作答 + 标引用」	这是压幻觉的关键非数值参数，见第 7 题
上下文顺序	最相关片放首尾	缓解 lost-in-the-middle

4、spark 的几种 join 是什么？

Spark SQL 有 5 种物理 Join 策略（对应 5 个执行算子）。先给全景，再讲选择逻辑：

策略（算子类名）	一句话	触发条件	有无 Shuffle	主要代价 / 风险
Broadcast Hash Join `BroadcastHashJoinExec`	小表广播到每个 Executor，在内存建哈希表，大表流式探测	一侧估算大小 < `autoBroadcastJoinThreshold`（默认 10MB）	无 shuffle（只广播小表）	广播表过大 → Driver / Executor OOM
Shuffle Hash Join `ShuffledHashJoinExec`	两表都按 key shuffle，小的一侧在内存建哈希表	默认基本关闭（见下），需 `preferSortMergeJoin=false` 且一侧足够小	有	建哈希表的一侧放不下内存 → OOM
Sort Merge Join `SortMergeJoinExec`	两表都按 key shuffle 后各自排序，再归并	等值 join 的默认主力	有	排序开销；对数据倾斜敏感
Broadcast Nested Loop Join `BroadcastNestedLoopJoinExec`	广播一侧，双重循环	非等值 join 或无更好选择时的兜底	广播	O(n×m) 双重循环，可能 OOM / 极慢
Cartesian Product `CartesianProductExec`	笛卡尔积	无 join 条件的 cross join	有	结果爆炸，n×m 行

选择优先级（等值 join、无 hint）——这是源码里 createJoinWithoutHint() 的真实顺序，面试常问：

flowchart TD
    S[等值 Join, 无 hint] --> B{一侧 < 广播阈值 10MB?}
    B -->|是| BHJ[Broadcast Hash Join<br/>首选, 无 shuffle]
    B -->|否| SH{preferSortMergeJoin=false<br/>且一侧足够小?}
    SH -->|是| SHJ[Shuffle Hash Join]
    SH -->|否 默认| SMJ[Sort Merge Join<br/>等值 join 默认落点]
    SMJ -.无 join key.-> CP[Cartesian Product]
    CP -.都不行.-> BNLJ[Broadcast Nested Loop<br/>最终兜底, 可能 OOM]

优先级链：Broadcast Hash → Shuffle Hash → Sort Merge → Cartesian → Broadcast Nested Loop（兜底）。

几个必须讲清的「为什么」：

① 为什么 Broadcast Hash Join 最快？ 因为它没有 shuffle。普通 join 要把两表都按 key 重分区（shuffle，落盘+网络，见第 8 题的代价），而广播只把小表通过网络发一份到每个 Executor，大表原地不动。省掉大表的 shuffle 是数量级的差异。代价：小表必须能装进内存，超过 autoBroadcastJoinThreshold（默认 10MB，.version("1.1.0")，3.x/4.x 未变）就不敢广播，否则 OOM。

② 为什么 Shuffle Hash Join 默认几乎不用？ 因为 spark.sql.join.preferSortMergeJoin 默认 true（.version("2.0.0")，internal，3.x/4.x 未变）。源码里选 Shuffle Hash 的前提是 !preferSortMergeJoin。Spark 团队更偏爱 Sort Merge 的原因：Hash Join 要把一侧完整哈希表放进内存，数据大就 OOM；而 Sort Merge 排好序后只需流式归并，内存可控（排序阶段可溢写磁盘）。稳健性优先于速度。

③ 为什么 Sort Merge Join 是默认主力？ 它对大表 join 大表最稳：两侧 shuffle 后各自按 key 排序，然后像归并排序那样双指针扫一遍。不需要把任何一侧全量装内存，扛得住大数据量。代价是排序本身有开销，且对数据倾斜敏感——某个 key 数据特别多时，那个 reduce task 会拖长整个 stage（底层原理专题 讲过倾斜，这里是它的一个高发地）。

④ AQE 如何改变这一切（生产必答）：以上是静态规则，用的是优化器估算的表大小，估错就选错（最典型：以为大表其实 filter 后很小，却没敢广播，白白走了 Sort Merge）。AQE（Adaptive Query Execution） 在 shuffle 写完、拿到真实数据量后，能把已经计划成 Sort Merge 的 join 运行时降级为 Broadcast Hash Join（spark.sql.adaptive.autoBroadcastJoinThreshold，.version("3.2.0")，不设则回退到 10MB）。

版本坑（必核对）：spark.sql.adaptive.enabled 默认值 3.2.0 从 false 翻成 true。所以 3.2 之前的生产集群，AQE 默认是关的，静态选错就一直错。核实途径：git show v3.5.9:sql/catalyst/src/main/scala/org/apache/spark/sql/internal/SQLConf.scala | grep -A3 adaptive.enabled。

⑤ 怎么强制指定？ 用 hint：SELECT /*+ BROADCAST(small) */ ...，还有 MERGE、SHUFFLE_HASH、SHUFFLE_REPLICATE_NL。有 hint 时选择顺序不同（hint 优先）。慎用：你手动广播一张运行时其实很大的表，就是在给自己造 OOM。

5、rbac、abac 有什么关系，核心要素是什么？数据库表怎么设计？

RBAC（Role-Based Access Control，基于角色）：不把权限直接给用户，而是在用户和权限之间插一层「角色」。用户→角色→权限。加人只需给角色，权限随角色走。
ABAC（Attribute-Based Access Control，基于属性）：不预先绑角色，而是在请求发生时，根据一组属性动态判定。属性来自四方——主体（用户部门/职级）、资源（数据密级/归属）、操作（读/写）、环境（时间/IP）。
关系（面试高频）：不是替代，是递进 + 互补。
- RBAC 是 ABAC 的特例——「角色」可以看成主体的一个属性，RBAC 就是只用「角色」这一个属性来判定的 ABAC。
- RBAC 粗粒度、易管理、够用：权限只跟角色走，管理员看得懂。缺点是行列级、动态条件的细粒度控制会导致角色爆炸（「华东区+风控+只看脱敏手机号」这种组合，每加一个维度角色数翻倍）。
- ABAC 细粒度、灵活、支持动态：能表达「同部门且工作时间且非外包」这种规则，天然做行级/列级权限。缺点是规则复杂、难排查（为什么这个人能看这条数据，要把一堆属性和规则跑一遍才知道）、性能开销大。
- 生产常见做法：RBAC 打底 + ABAC 补细粒度。用角色管住 80% 的粗粒度菜单/功能权限，用属性策略管行列级数据权限。

核心要素对照：

	RBAC	ABAC
判定依据	用户被授予的角色	主体/资源/操作/环境四类属性 + 策略规则
核心概念	User、Role、Permission（=资源+操作）	Subject、Resource、Action、Environment 属性 + Policy
授权时机	事先绑定（静态）	请求时动态求值
粒度	功能/菜单级为主	行级、列级、字段级
典型规则	「运营角色能访问报表模块」	「用户.dept == 数据.dept 且环境.time∈工作时间」

RBAC 库表设计（经典 RBAC0，五张表；RBAC1 加角色继承，RBAC2 加职责分离约束）：

-- 用户
CREATE TABLE sys_user (
  id          BIGINT PRIMARY KEY,
  username    VARCHAR(64) NOT NULL UNIQUE,
  dept_id     BIGINT,                    -- 冗余部门，ABAC 会用到
  status      TINYINT DEFAULT 1
);
-- 角色
CREATE TABLE sys_role (
  id          BIGINT PRIMARY KEY,
  role_key    VARCHAR(64) NOT NULL UNIQUE,  -- 如 'risk_analyst'
  role_name   VARCHAR(128) NOT NULL
);
-- 权限（资源 + 操作，一条 = 一个可授权的原子动作）
CREATE TABLE sys_permission (
  id          BIGINT PRIMARY KEY,
  perm_key    VARCHAR(128) NOT NULL UNIQUE, -- 如 'report:export'
  resource    VARCHAR(128) NOT NULL,        -- 资源标识
  action      VARCHAR(32)  NOT NULL         -- read/write/export...
);
-- 用户-角色（多对多）
CREATE TABLE sys_user_role (
  user_id     BIGINT NOT NULL,
  role_id     BIGINT NOT NULL,
  PRIMARY KEY (user_id, role_id)            -- 联合主键即联合索引，查用户角色走它
);
-- 角色-权限（多对多）
CREATE TABLE sys_role_permission (
  role_id     BIGINT NOT NULL,
  perm_id     BIGINT NOT NULL,
  PRIMARY KEY (role_id, perm_id)
);

鉴权查询（判断用户有没有某权限）：user → user_role → role_permission → permission 一路 join，或启动时把用户权限集加载进缓存（Redis）避免每次查库。

ABAC 库表设计——核心是把「策略」变成可存储、可求值的数据，而非写死在代码里：

-- 策略表：一条策略 = 一条 if(条件) then 允许/拒绝 规则
CREATE TABLE abac_policy (
  id          BIGINT PRIMARY KEY,
  name        VARCHAR(128) NOT NULL,
  effect      TINYINT NOT NULL,        -- 1=allow 0=deny（deny 通常优先）
  resource_type VARCHAR(64) NOT NULL,  -- 作用于哪类资源，如 'order_table'
  action      VARCHAR(32) NOT NULL,    -- read/write
  -- 条件用结构化 JSON 存，运行时由策略引擎求值
  condition   JSON NOT NULL,
  priority    INT DEFAULT 100,         -- 多策略命中时的优先级
  status      TINYINT DEFAULT 1
);
-- 属性表：主体/资源的属性（也可直接从业务表取，这里是集中存法）
CREATE TABLE abac_attribute (
  id          BIGINT PRIMARY KEY,
  entity_type VARCHAR(32) NOT NULL,    -- 'subject' / 'resource'
  entity_id   BIGINT NOT NULL,
  attr_key    VARCHAR(64) NOT NULL,    -- 'dept' / 'level' / 'sensitivity'
  attr_value  VARCHAR(256) NOT NULL,
  KEY idx_entity (entity_type, entity_id)
);

condition JSON 示例（「主体部门 == 资源部门且主体非外包」）：

{ "and": [
    { "eq": ["subject.dept", "resource.dept"] },
    { "ne": ["subject.employee_type", "outsource"] }
] }

ABAC 求值流程 = 策略引擎（PDP）在做的事（这套 PEP/PDP/PIP/PAP 术语面试会加分）：

flowchart LR
    U[请求: 谁 对什么 做什么] --> PEP[PEP 策略执行点<br/>拦截请求]
    PEP --> PDP[PDP 策略决策点<br/>求值]
    PIP[PIP 属性信息点<br/>查主体/资源属性] --> PDP
    PAP[PAP 策略管理点<br/>存/管策略] --> PDP
    PDP -->|allow/deny| PEP
    PEP -->|放行/拦截| R[资源]

PEP（Enforcement，执行点）：拦在资源前，收集请求上下文。
PDP（Decision，决策点）：真正跑策略、出 allow/deny 的引擎。
PIP（Information，信息点）：给 PDP 供属性（查 abac_attribute 或业务库）。
PAP（Administration，管理点）：管理员增删改策略的地方（写 abac_policy）。
冲突规则：多条策略命中时，通常 deny 优先，或按 priority。

落到 RAG/数仓的接法（呼应第 2 题）：数据权限最终常常要下推到查询——ABAC 判定出「这个用户只能看华东区」后，翻译成 SQL 的 WHERE region='华东' 或行级安全策略（Row-Level Security），而不是查出全量再内存过滤。列级则映射到脱敏函数。这正是 RAG 里「检索前元数据过滤」做权限隔离的底层。

6、agent 响应速度慢怎么一步步排查？

核心方法论和第 3 题一样：先分层埋点定位瓶颈在哪一段，再对症下药。Agent 一次响应的耗时是链路上各段之和，盲目优化没埋点的段是浪费。

先把一次 Agent 响应拆成可计时的段（每段都该有耗时日志 / trace）：

flowchart TD
    A[入口: 收到请求] --> B[前置处理<br/>鉴权/query改写/意图识别]
    B --> C[检索/工具调用<br/>RAG检索 or Tool/MCP]
    C --> D[LLM 调用<br/>TTFT + 生成]
    D --> E{需要多步?<br/>ReAct 循环}
    E -->|再来一轮| C
    E -->|结束| F[后处理/流式输出]

逐段排查（从最可能到最不可能）：

① 先看是不是 LLM 段——它几乎总是大头

两个指标要分开看：TTFT（首 token 延迟）和总生成时间（≈ 输出 token 数 × TPOT）。
TTFT 高：模型排队 / 冷启动 / prompt 太长（prefill 阶段要处理的输入 token 多）。→ 缩短 prompt（RAG 的上下文塞太多？见第 2 题 top_n）、换更快的部署、开 prompt 缓存。
总生成时间高：输出太长。→ 限制 max_tokens、要求模型简洁、结构化输出。
首选武器：流式输出（streaming）。它不减少总耗时，但让用户在 TTFT 后就看到字，感知延迟骤降。Agent 场景这是性价比最高的一招。

② 看是不是「多步循环」段——Agent 特有的隐形杀手

Agent（ReAct 类）经常要多轮 LLM 调用：想 → 调工具 → 看结果 → 再想。5 轮串行 = 5 次 LLM 延迟叠加，这是 Agent 比单次问答慢的根本原因。
排查：数一次响应到底调了几次 LLM。轮数异常多 → prompt/工具设计有问题（模型在反复试错、纠结）。
优化：减少不必要的轮次（能一次给全的信息别分步）、并行化独立的工具调用（三个互不依赖的查询同时发，而非串行）、给模型更清晰的工具描述减少试错。

③ 看检索 / 工具调用段

RAG 检索慢：回到第 3 题——ANN ef_search 太大、rerank 候选太多、向量库无索引走了暴力检索。
外部工具 / API 慢：某个 Tool 打的下游接口就是慢，或没设超时被拖死。→ 加超时 + 降级、能缓存的结果缓存、独立工具并行。

④ 看前置和网络段

query 改写 / 意图识别如果也用 LLM，那是又一次 LLM 延迟，评估是否必要。
网络往返、序列化、鉴权查库——通常小，但排除法要走到。

排查顺序总结：加分层耗时日志 → 看哪段占比最大 → 若 LLM 段大，分 TTFT vs 生成，先上流式 → 若循环段大，减轮次 + 并行工具 → 若检索段大，调 ANN/rerank 参数。不埋点就调参 = 蒙。

7、agent 用户反馈回流应该怎么做改进，幻觉怎么一步步排查？

一句话：反馈回流 = 把线上用户的信号收集起来，变成能驱动系统改进的数据资产，形成「收集 → 归因 → 改进 → 验证」的闭环。这和数据平台里「埋点 → 分析 → 迭代」是同构的。

flowchart LR
    A[1 收集<br/>显式:赞踩/纠错<br/>隐式:复制/追问/放弃] --> B[2 归因分类<br/>检索错? 生成错? 意图错?]
    B --> C[3 改进<br/>对症下药]
    C --> D[4 验证<br/>评测集回归 + 灰度 AB]
    D -.效果回流.-> A

第 1 步：收集——分显式和隐式

显式：👍/👎、「答案有误」按钮、用户直接纠正的正确答案。信号强但量少（多数用户不点）。
隐式（往往更真实、量大）：用户是否复制了答案、是否立刻追问/重问（暗示没答好）、是否放弃会话、停留时长。这些是行为埋点，你数据背景的强项。
关键：收集时要带全上下文——原始 query、改写后 query、检索到的 chunk、最终 prompt、模型输出、用了哪些工具。否则拿到一个「👎」根本无法归因。

第 2 步：归因分类——这一步决定改进方向（呼应第 2 题的切分） 把 bad case 归到链路的具体环节：

检索错：正确资料压根没召回 → 回开发链路（切分/embedding）或检索参数（第 3 题）。
生成错：召回对了但 LLM 没用好 / 编了 → prompt / rerank / 幻觉问题（见 7.2）。
意图错：query 理解偏了 → 改写 / 意图识别。
知识缺失：库里根本没有 → 补数据源（回开发链路第 1 环）。

第 3 步：改进——按归因对症

检索错 → 调切分/参数、把用户纠正的「正确 chunk」加进评测集甚至语料。
生成错 → 改 prompt、加 few-shot、上更强模型或加校验。
高频未覆盖问题 → 补文档、甚至沉淀成 FAQ 直接命中。
重要：用户纠正的「query→正确答案」对，是金标注数据，攒起来既能做评测集，也能做微调语料。

第 4 步：验证——不能改完就上

先在离线评测集上回归，确认没把别的 case 改坏（回归测试思维）。
再灰度 / A-B：新策略放一部分流量，比对反馈指标（👎率、追问率）再全量。
这样闭环才闭上：改进的效果重新变成反馈数据。

先定义：幻觉 = 模型生成了「听起来合理但实际错误 / 无依据」的内容。RAG 场景要先分清两类，排查路径完全不同：

A 类：检索没给对料，模型硬编（RAG 最常见）。→ 病根在检索。
B 类：料给对了，模型没忠实使用 / 自行发挥。→ 病根在生成。

分步排查法：

第 1 步：定位是 A 还是 B——把「检索到的上下文」和「答案」摆一起看

这是排查幻觉的第一动作，也是最关键的一步。调出这次回答实际检索到的 chunk。
若正确信息不在检索结果里 → A 类，检索问题，跳第 2 步。
若正确信息在检索结果里，但答案和它不符 → B 类,生成问题，跳第 3 步。

第 2 步（A 类，检索）：为什么没召到正确资料 按第 2、3 题的链路逐个查：

库里有没有这条知识？没有 → 知识缺失，补数据源，不是幻觉是「不知道」。
有但没召回 → 切分把它切碎了？embedding 不匹配（问法和原文用词差太远）？→ 调切分、上混合检索补关键词、加 rerank。
召回了但排在很后面被 top_n 截掉 → 调大 top_k / 上 rerank。

第 3 步（B 类，生成）：为什么料对了还编

prompt 约束不足：没明确说「只依据资料、无依据就说不知道」。→ 加强约束（第 3 题）。
temperature 太高：发散。→ 事实问答调到 0。
上下文太长/关键信息在中间（lost in the middle）→ 精简、把关键 chunk 放首尾。
模型能力：小模型更容易不忠实。→ 换更强模型，或加校验环节：让模型/另一次调用判断「答案是否被上下文支撑」（groundedness 检查），不支撑就打回或标注「不确定」。

第 4 步：加护栏 + 回流

要求输出带引用出处，用户和系统都能核对（对不上就是幻觉信号）。
把发现的幻觉 case 走 7.1 的回流闭环，加进评测集,防止回归。

8、shuffle 一次的过程从底层文件的视角来看，是什么样的？

先立三个必须先懂的概念（否则后面文件名看不懂）：

Shuffle 的两端：上游 Stage 的 task 叫 map task（写数据），下游 Stage 的 task 叫 reduce task（读数据）。一次 shuffle = 上游所有 map 写出、下游所有 reduce 按 key 分区读回。
为什么必然落盘：map 和 reduce 通常不在同一台机器、不同时运行。map 的输出必须先落到本地磁盘，等 reduce 起来了再通过网络拉。这就是那笔「落盘代价」的物理来源——不是 Spark 想落盘，是分布式重分区绕不开。
partition（分区）：reduce 端有多少个 task，map 就要把自己的输出切成多少个 partition，第 i 个 partition 的数据将来给第 i 个 reduce task。

8.1 核心结论：每个 map task 只产出 2 个文件

这是现代 Spark（sort-based shuffle）最重要的事实，也是面试高频：

每个 map task 最终只写 2 个文件：一个 .data（数据）+ 一个 .index（索引）。

文件名格式（已核实 BlockId.scala）：

shuffle_<shuffleId>_<mapId>_0.data     # 如 shuffle_0_5_0.data
shuffle_<shuffleId>_<mapId>_0.index    # 如 shuffle_0_5_0.index

注意末尾那个 0——它是 reduceId 占位符，恒为 0（NOOP_REDUCE_ID）。这正是关键：一个 map task 不再为每个 reduce 单独出一个文件。

为什么这个「2 个文件」是重点？讲清历史因果：

早期 hash-based shuffle：每个 map task 为每个 reduce partition 单独开一个文件。M 个 map × R 个 reduce = M×R 个小文件。1000 map × 1000 reduce = 一百万个小文件，磁盘 inode 爆炸、随机 IO 打满。
sort-based shuffle（现在唯一保留的，hash shuffle 已在 Spark 2.0 彻底删除，spark.shuffle.manager 默认且只能是 "sort"）的解法：一个 map task 把所有 partition 的数据写进同一个 .data 文件（按 partition id 排好序连续存放），再用一个 .index 文件记录「第 i 个 partition 在 .data 里的起止偏移」。文件数从 M×R 降到 2×M。

flowchart TD
    subgraph 一个 map task 的输出
    D[".data 文件<br/>partition0 | partition1 | ... | partitionR-1<br/>(按分区连续排列)"]
    I[".index 文件<br/>offset0, offset1, ..., offsetR<br/>(每个分区的起止字节偏移)"]
    end
    R0[reduce task 0] -.读 index 第0段偏移.-> I
    I -.定位 .data 的 [offset0,offset1).-> D
    D -.只拉这一段.-> R0

reduce task i 要拿自己的数据：先读 .index 拿到第 i 段的 [起始偏移, 结束偏移)，再去 .data 文件 seek 到该偏移、只读这一段。一个 index 文件把「M×R 次找文件」变成「M 个文件里各定位一段」。

8.2 map 端写的完整过程（盯着文件看）

sort-based shuffle 有三种 writer，但产出都是那 2 个文件，区别在中间怎么攒数据。选择逻辑（SortShuffleManager.registerShuffle）：

flowchart TD
    S[map task 要写 shuffle] --> A{有 map 端预聚合<br/>mapSideCombine?}
    A -->|无 且 分区数≤200| BY[BypassMergeSortShuffleWriter<br/>绕过排序]
    A -->|无 且 序列化器支持重定位<br/>且分区≤1600万| UN[UnsafeShuffleWriter<br/>序列化排序]
    A -->|其他/需要聚合| SO[SortShuffleWriter<br/>标准排序, 可溢写]

① BypassMergeSortShuffleWriter（绕过排序）

触发：无 map 端聚合（不是 reduceByKey 这类）且 reduce 分区数 ≤ spark.shuffle.sort.bypassMergeThreshold（默认 200，.version("1.1.1")，3.x/4.x 未变）。
干法：分区少，干脆先给每个 partition 各开一个临时文件分别写，写完把这些临时文件按顺序拼接成一个 .data，同时生成 .index。
为什么它存在：分区数少时，排序纯属浪费，直接分桶再拼接更快。代价是过程中会短暂开 R 个临时文件（所以限制 200，多了又回到小文件问题）。

② UnsafeShuffleWriter（序列化排序 / Tungsten）

触发：无聚合、序列化器支持「序列化对象重定位」、分区数 ≤ 16,777,216（2^24）。
干法：把记录序列化成二进制后，只对「(partitionId, 指向数据的指针)」这个 8 字节打包指针排序，不反序列化对象本身。排序完溢写、合并成一个 .data + .index。
为什么快：排序时搬的是 8 字节指针不是完整对象，且省了反复序列化/反序列化——这是 底层原理专题 提过的 Tungsten「省序列化」在 shuffle 的落地。

③ SortShuffleWriter（标准，兜底）

触发：需要 map 端聚合（reduceByKey），或不满足上面两者。
干法：数据进内存的 map（需聚合）或 buffer（不需），按 (partitionId[, key]) 排序；内存不够就**溢写（spill）成多个磁盘临时文件；最后把内存剩余 + 所有溢写文件归并（merge）**成一个 .data + .index。
溢写就是 OOM 的替代品：内存放不下不报错,而是落盘,代价是多次磁盘 IO。溢写次数多是 shuffle 慢的常见信号。

三者殊途同归：中间过程不同，最终都通过 IndexShuffleBlockResolver 原子地提交那 2 个文件（先写 index 再写 data，原子 rename,防止 reduce 读到半成品)。

8.3 reduce 端读的过程

reduce task 启动，向 Driver 的 MapOutputTracker 问：「我是 partition i,数据在哪些 map 的输出里？」拿到一批 (节点, mapId)。
对每个 map 输出：连到那台机器的 External Shuffle Service（或 Executor），请求 shuffle_<sid>_<mapId>_i。
服务端读该 map 的 .index，seek 到第 i 段偏移,把 .data 里那一段通过网络传回——这就是「网络代价」。
reduce 把从各 map 拉来的同 partition 数据汇总(需要则聚合/排序),进入本 task 计算。

External Shuffle Service（ESS）是什么、为什么要它：一个常驻在每个节点的独立服务,专门负责把本节点上 map 写的 shuffle 文件伺服给 reduce。为什么不让 Executor 自己传?因为 Executor 可能因动态资源回收被杀掉,它一死,它写的 shuffle 文件就没人能传了,reduce 全部拉取失败 → FetchFailed → 整个 Stage 重算。ESS 独立于 Executor 生命周期,Executor 死了文件照样能被拉。这是生产开 spark.shuffle.service.enabled 的原因。

8.4 从文件视角看,shuffle 为什么是性能杀手（串起三笔代价）

落盘:map 输出必须落本地磁盘(§8.1),分区多/数据大时溢写多次,磁盘 IO 叠加。
网络:reduce 要从所有 map 节点拉自己那一份,是 M×R 的全连接拉取,网络放大。
序列化 + 排序:数据跨机必须序列化;sort shuffle 还要排序。UnsafeShuffleWriter 就是来省这两笔的。

排障信号:Spark UI 的 Stage 页看 Shuffle Write / Shuffle Read 的量、Spill (Memory/Disk) 的量。Spill 大 → 内存不够在狂落盘;某个 reduce task 的 Shuffle Read 远超别人 → 数据倾斜(某 key 全汇到一个 partition)。

面试怎么答（90 秒):现代 Spark 只有 sort-based shuffle,核心结论是每个 map task 只产出 2 个文件:一个 .data 一个 .index。.data 把所有 reduce 分区的数据按分区连续排放,.index 记每个分区的字节偏移;reduce 读 index 定位、seek .data 只拉自己那段。这是为了解决老 hash shuffle 的 M×R 小文件爆炸。写端有三种 writer(bypass 绕排序、unsafe 序列化排序、sort 标准可溢写),殊途同归产出那 2 个文件。三笔代价——落盘(map 必落本地)、网络(M×R 全连接拉取)、序列化排序,外加 External Shuffle Service 保证 Executor 死了文件还能被拉。

9、从底层文件、实例调度的视角讲一讲 flink 的 checkpoint。

先讲 checkpoint 是什么、解决什么(一句话地基):Flink 是有状态流计算——算子会累积状态(窗口聚合、去重表)。机器随时可能挂,挂了状态就没了。Checkpoint = 周期性给全局状态打一致性快照并存到可靠存储(HDFS/S3),挂了就从最近一次快照恢复,配合 source 回拨(如 Kafka offset 回退)实现 exactly-once。它是 Flink 容错的根基。

9.1 实例调度视角:谁触发、barrier 怎么流

触发者:JobManager 里的 CheckpointCoordinator(已核实 CheckpointCoordinator.java,类注释明确「triggers the checkpoint by sending messages to the relevant tasks and collects the acknowledgements」)。它是运行在 JM 上的一个协调组件,按配置的间隔周期性发起 checkpoint。

关键机制:它只 RPC 通知 source task,不直接往数据流里塞东西(已核实 DefaultCheckpointPlanCalculator「directly marks all the sources as tasks to trigger」)。这是经典 Chandy-Lamport 分布式快照算法的实现。

flowchart TD
    CC[JobManager: CheckpointCoordinator<br/>周期性触发] -->|1 RPC 只通知 source| SRC[Source Task]
    SRC -->|2 快照自身状态<br/>并向下游发 barrier n| OP1[中间算子 Task]
    OP1 -->|barrier n 随数据流| OP2[中间算子 Task]
    OP2 -->|barrier n| SINK[Sink Task]
    SRC -.3 存完 state 后 ack.-> CC
    OP1 -.ack.-> CC
    OP2 -.ack.-> CC
    SINK -.ack.-> CC
    CC -->|4 收齐所有 ack<br/>标记 checkpoint n 完成| DONE[(写 _metadata<br/>通知各 task commit)]

全过程(盯着「谁在动」):

CC 触发:CheckpointCoordinator 给所有 source task 发 RPC「开始 checkpoint n」。
source 打快照 + 发 barrier:source 记下自己的状态(如 Kafka 各分区 offset),然后向下游发一个特殊标记 checkpoint barrier(编号 n),它跟着正常数据一起在流里往下走。
barrier 逐级推进:每个算子收到 barrier n,就快照自己当前状态存到 DFS,再把 barrier n 转发给下游。
异步 ack:每个 task 状态存完,向 CC 发 ack(带状态文件句柄)。
CC 收齐 = 完成:所有 task 都 ack 了,CC 写一份全局 _metadata(记录这次 checkpoint 由哪些状态文件组成),标记 checkpoint n 成功,并通知各 task「可以 commit 了」(2PC 的第二阶段,见 §9.4)。

barrier alignment(对齐)——面试必问的难点:一个算子有多个上游输入通道(如 join 有两个输入),barrier n 会从各通道先后到达。

aligned(对齐,EXACTLY_ONCE 默认):某通道的 barrier n 先到,该算子暂停处理这个通道(数据缓存住),等所有通道的 barrier n 都到齐,才快照、才继续。为什么要等:保证快照的是「恰好处理完 barrier 之前所有数据」的一致状态,不多不少 → exactly-once。代价:对齐期间要等、要缓冲,反压严重时对齐时间长,checkpoint 变慢甚至超时(已核实 CheckpointBarrierTracker 注释:不阻塞通道就只能 at-least-once)。
unaligned(非对齐):不等对齐,barrier 一到就快照,把「还没处理的、卡在缓冲区的数据」也一起存进快照。好处:反压下 checkpoint 照样快;代价:快照更大(多存了 in-flight 数据)。
- 开关:execution.checkpointing.unaligned.enabled,默认 false(2.4 核实;1.17/1.18 里该项在 ExecutionCheckpointingOptions,key 是 execution.checkpointing.unaligned,默认同为 false)。只在 EXACTLY_ONCE 下可用。

排障接口:反压(backpressure)会直接拖垮对齐式 checkpoint——barrier 卡在拥堵的通道后面流不动,对齐时间暴涨 → checkpoint 超时失败。看到 checkpoint 频繁超时,先查是不是有反压(Flink UI 的 Backpressure 页 + Checkpoint 页的 alignment duration)。反压严重的链路是 unaligned 的主要适用场景。

9.2 底层文件视角:checkpoint 在 DFS 上长什么样

先分清两个正交的概念(1.x 起就常被混淆):

State Backend(状态后端)= 运行时状态存在哪、怎么存:
- HashMapStateBackend:状态存在 TaskManager 的 JVM 堆内存。快,但受堆大小限,状态大易 OOM。
- EmbeddedRocksDBStateBackend:状态存在 TaskManager 本地磁盘的 RocksDB(嵌入式 KV)。能放超过内存的大状态,支持增量 checkpoint,代价是读写要走序列化 + 磁盘,比堆慢。
- 默认 state.backend.type = hashmap(2.4 核实;1.17/1.18 的 key 是 state.backend,state.backend.type 是 1.19+/2.x 的新 key,老 key 仍作别名)。生产大状态基本都换 RocksDB。
Checkpoint Storage(检查点存储)= 快照往哪写:
- JobManagerCheckpointStorage:快照存 JM 内存——仅测试用,状态大直接把 JM 撑爆。
- FileSystemCheckpointStorage:快照写 HDFS/S3 等可靠 DFS——生产用这个。

DFS 上的目录布局(已核实 AbstractFsCheckpointStorageAccess.java 的常量与 FsCheckpointStorageAccess.java 的目录拼装):

<checkpoint 根目录>/
  └── <jobID>/                         # 每个作业一个子目录
        ├── chk-1/                     # 第 1 次 checkpoint 的专属目录
        │     └── _metadata            # 全局元数据:这次快照由哪些 state 文件组成
        ├── chk-2/
        │     └── _metadata
        ├── shared/                    # 跨 checkpoint 共享的状态(RocksDB 增量的 SST 文件)
        └── taskowned/                 # 由 TaskManager 拥有/释放的状态(非 JM 管理)

已核实的常量:CHECKPOINT_DIR_PREFIX = "chk-"、CHECKPOINT_SHARED_STATE_DIR = "shared"、CHECKPOINT_TASK_OWNED_STATE_DIR = "taskowned"、METADATA_FILE_NAME = "_metadata"。源码里给的真实例子:hdfs://namenode:port/flink-checkpoints/1b080b6e710aabbef8993ab18c6de98b/chk-17/。

三个目录为什么这么分——讲清因果:

chk-<id>/:一次 checkpoint 的**专属(exclusive)**状态 + _metadata。这次 checkpoint 被清理时,整个目录能直接删。
shared/:为增量 checkpoint服务。RocksDB 增量快照只上传「比上次新增的 SST 文件」,这些文件被多个 checkpoint 共同引用,所以不能放在某个 chk-<id> 里(否则删那次 checkpoint 会误删还被别人引用的文件)。放 shared/,靠引用计数管理生命周期。这是「增量」省流量的物理实现:没变的 SST 不重传,复用 shared/ 里已有的。
taskowned/:归 TaskManager 管理生命周期的状态(如某些 changelog),JM 不直接负责删。

_metadata 是核心:它不存状态数据本身,存的是「这次全局快照 = 哪些 state 文件句柄的集合」。恢复时 JM 先读 _metadata,知道每个算子该从哪个文件恢复,再调度 task 去加载。手动恢复 / savepoint 迁移时,指定的就是这个目录。

9.3 恢复视角:挂了怎么用文件 + 调度恢复回来

作业失败,JobManager 触发 restart。
JM 读最近一次成功 checkpoint 的 _metadata,拿到全局状态的文件清单。
JM 重新调度 task 到 TaskManager(可能是新的 slot / 新机器)。
每个 task 按 _metadata 里分配给它的状态句柄,从 DFS(chk-/shared/)下载并加载自己那份状态。
source 把 offset 回拨到快照记录的位置(如 Kafka seek 回 checkpoint 时的 offset)。
从该点重新消费——快照后、崩溃前已处理的数据会被重放。配合下游幂等 / 2PC,对外表现为 exactly-once。

调度要点:恢复不要求 task 回到原来的机器——状态在 DFS 上,新调度的 task 从 DFS 拉即可。这正是「状态存 DFS 而非本地」换来的调度自由;代价是恢复要走一遍 DFS 下载,大状态恢复慢(RocksDB 增量 + shared/ 复用能缓解)。

9.4 和 Iceberg/2PC 的接缝(呼应你 09-16 面试被问的题)

Flink 写 Iceberg 的 exactly-once,靠的正是把「提交」绑定到「checkpoint 完成」(已核实 TwoPhaseCommitSinkFunction,注意 2.x 已标 @Deprecated、迁到新 Sink V2 接口;1.17/1.18 该类在 ...functions.sink 包下,无 .legacy):

snapshotState 时 preCommit:checkpoint 打快照的那一刻,sink 把这批数据以「预提交」形式写好(Iceberg 侧:data file 已落地但还没 commit 到快照),但还不可见。
notifyCheckpointComplete 时 commit:等 CheckpointCoordinator 确认整个 checkpoint 成功(§9.1 第 5 步),才真正 commit(Iceberg 侧:切换 metadata 指针,数据变可见)。
因果:如果 checkpoint 失败,这批预提交不会 commit,重启后重做 → 不会出现「数据可见了但 checkpoint 没成功,恢复后重复写」。所以 Flink 写 Iceberg 的数据可见性,取决于 checkpoint 间隔——checkpoint 5 分钟一次,数据就最多 5 分钟才可见一批。这就是 09-16 面试官问「Flink 写 Iceberg 什么时候可见」的底层答案。

面试怎么答(90 秒):分两个视角。调度视角:JobManager 的 CheckpointCoordinator 周期触发,只 RPC 通知 source,source 打快照后往流里发 barrier,barrier 随数据逐级下推,每个算子见到 barrier 就快照自己的状态并异步 ack,CC 收齐所有 ack 才算完成——这是 Chandy-Lamport。难点是 barrier 对齐:aligned 要等所有输入通道的 barrier 到齐(保 exactly-once,但反压下易超时),unaligned 不等、把在途数据也存进去(默认关)。文件视角:状态后端(hashmap 堆 / RocksDB 磁盘)决定运行时状态在哪;checkpoint storage 决定快照写哪(生产写 HDFS/S3)。DFS 上按 <jobID>/chk-<id>/_metadata + shared/(增量复用的 SST)+ taskowned/ 组织,_metadata 记全局状态由哪些文件组成,恢复时 JM 读它、重调度 task、各 task 从 DFS 拉状态、source 回拨 offset 重放。最后点一句:Flink 写 Iceberg 靠 2PC 把 commit 绑到 checkpoint 完成,所以数据可见性取决于 checkpoint 间隔。