大数据工具 → GPU 工具的概念映射
一句话定位：这是我的表达优势——Spark/Flink 的性能分析范式与 GPU 的性能分析范式在结构上完全同构，把映射关系讲清楚，就能证明既有经验可以直接迁移。
1. 核心映射表
| 大数据侧（Spark / Flink UI） | GPU 侧（Nsight / PyTorch Profiler） | 共同本质 |
|---|---|---|
| Stage / Task 耗时分布 | Kernel 时间线与耗时排序 | 按执行单元找耗时热点 |
| Shuffle 读写量 | 显存带宽 / H2D-D2H 拷贝量 | 数据搬运量是主要成本 |
| 长尾 Task（木桶效应） | 长尾 Kernel / 静态 Batching 木桶效应 | 整批完成时间受最慢单元支配 |
| Executor 内存溢出（OOM） | 显存 OOM | 单执行单元内存超限 |
| Stage 之间的同步屏障 | Kernel 同步点 / Stream 同步 | 同步破坏流水、造成空转 |
| 数据倾斜（key 分布不均） | batch 内序列长度不均 | 负载不均导致资源空闲 |
| 小文件过多 → 调度开销 | 大量极短 Kernel → 启动开销 | 单元过细，管理成本压倒计算 |
2. 逐条展开（面试可直接说）
- Stage/Task 耗时分布 ↔ Kernel 时间线：两边的第一动作都是”看执行单元的耗时排序找热点”，而不是凭经验猜。
- Shuffle 读写量 ↔ 显存带宽/拷贝量：Spark 优化的主线是减少 Shuffle 的数据量（列裁剪、map 端预聚合），GPU 优化的主线是减少 HBM 往返（算子融合、FlashAttention）——都是”访存/搬运”而非”算力”是瓶颈。
- 长尾 Task ↔ 木桶效应 batch：Spark 里一个倾斜 key 拖慢整个 Stage；LLM 推理里一个超长序列拖慢整个静态 batch。解法也同构：细化调度粒度（AQE 拆分倾斜分区 ↔ Continuous Batching 迭代级出队）。
- Executor OOM ↔ 显存 OOM：排查思路一致——先分清是”真的用满”还是”分配器/缓存占着不还”（Spark 统一内存的存储挤占执行 ↔ PyTorch caching allocator 的 reserved vs allocated，见 3.2）。
3. 方法论层面的同构
工具不同，但动作序列完全一样：量化基线 → 看分布找热点 → 提假设 → 单变量验证 → 留档对比（详见 5.5）。这也是为什么”从大数据转 GPU 性能优化”是一条成立的路径。
参考：Spark 官方文档 Web UI 章节；Flink 官方文档 Web UI 章节