Spark Checkpoint 和 Cache 有什么区别？
面试怎么回答
Cache/Persist 是性能优化，数据可以丢，丢失后按 lineage 重算；Checkpoint 会把结果写入可靠存储并截断血缘，适合长 DAG、迭代计算和稳定阶段边界。实践中可以先 Persist 再 Checkpoint，避免物化时重复计算，完成后及时 Unpersist。我还会区分批处理 Checkpoint 与 Structured Streaming 保存 Offset、状态和提交日志的 Checkpoint。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
Cache 丢了可以重算，Checkpoint 丢了可能无法从原来的血缘恢复。两者都把中间结果“存起来”，解决的问题却完全不同。
一个面向性能复用，一个面向截断血缘和可靠恢复。
Cache 是可丢失的性能优化，Checkpoint 是把数据物化到可靠存储并切断上游血缘。
Cache 服务重复计算
Cache/Persist 将分区保存在内存或磁盘，后续 Action 可以复用。分区丢失时，Spark 仍可根据 lineage 重新计算，因此它不改变逻辑依赖。
Checkpoint 截断血缘
Checkpoint 会触发物化并把结果写到配置的可靠存储，之后从检查点读取，原有长血缘被截断。它适合迭代算法、超长 DAG 或需要稳定中间边界的场景。
两者经常组合使用
直接 Checkpoint 可能先按完整血缘重算一次。常见做法是先 Persist，再 Checkpoint，让检查点物化复用缓存结果，完成后根据生命周期 Unpersist。
别和流式 Checkpoint 混淆
批处理 RDD/DataFrame 的 Checkpoint 主要处理血缘；Structured Streaming Checkpoint 还保存 Offset、状态和提交日志，用于流任务故障恢复，语义不能混为一谈。
为什么不能只回答概念？
“误区：Checkpoint 只是更可靠的 Cache”之所以常见，是因为它在理想数据和单次执行里往往说得通。但生产环境会加入数据规模、异常值、并发、版本、失败重试和下游口径，这些条件一变化，只记住术语就很容易给出错误结论。
所以我会把 Cache 服务重复计算、Checkpoint 截断血缘、两者经常组合使用、别和流式 Checkpoint 混淆 串成一条完整链路。最终判断标准不是某个函数或配置是否出现，而是能否稳定得到可解释、可验证、可恢复的业务结果。
落地时我会检查什么？
- 输入边界：确认数据范围、时间口径、主键和异常值是否符合假设。
- 执行过程：观察分区、并行度、状态、Shuffle 或资源变化，验证方案是否真正生效。
- 输出结果：用行数、唯一性、关键指标和样本明细证明结果正确，而不是只看任务成功。
- 失败恢复：说明重跑、回滚、版本兼容和责任人，避免一次成功后无人维护。
这些检查不一定全部写进一条 SQL 或一个任务，但面试时能主动补充，说明你回答的不是背诵题，而是在描述一套可上线的工程方案。
一个典型场景
一个迭代任务每轮都从上一轮 DataFrame 派生，DAG 越来越长。团队只加 Cache，内存压力上升后缓存频繁淘汰，故障重算仍要走完整血缘。改为在阶段边界 Persist 后 Checkpoint，并及时释放旧缓存，调度图和恢复路径才真正缩短。
Cache 减少重复算，Checkpoint 减少需要追溯的依赖。