描述一次你调试 Spark/SQL/ML 性能问题的经历。

考察要点

这道题旨在考察候选人系统性解决问题的能力和技术深度。对于 Amazon，它直接映射到 Dive Deep 和 Ownership 这两条 Leadership Principles (LP)。面试官希望看到你不仅能发现表面问题，更能深挖到底层，找到根本原因，并主动负责到底，直至问题解决。

高分示范答案（STAR）

Situation（背景） 我在上一家电商公司担任高级机器学习工程师，负责“猜你喜欢”推荐系统的模型迭代。我们的团队有 5 名工程师。核心业务之一是每天凌晨运行一个大型 Spark 任务，处理前一天的用户行为数据（点击、加购、购买），生成用于模型训练的特征。这个任务通常需要 3 小时完成。但在去年 Q3 的某一天，我发现这个任务跑了超过 10 个小时还未结束，直接阻塞了下游的模型训练和部署流程，导致当天推荐给用户的内容是前天的旧数据。

Task（任务） 我的任务是立即介入，诊断出性能瓶颈的根本原因，并尽快将任务执行时间恢复到正常的 4 小时内，确保当天模型能按时更新上线。长期目标是建立机制，防止此类问题再次发生。

Action（行动） 整个过程就像一个侦探探案，我采取了以下几个关键步骤：

1. 初步排查与假设建立：我首先排除了最常见的几个原因。通过 Grafana 监控，我看到 EMR 集群的 CPU 和内存资源是充足的。通过检查 Git 历史，确认最近 48 小时内没有相关的代码变更。因此，我排除了资源瓶颈和代码 bug 的可能性。我的初步假设是：数据分布发生了变化，出现了严重的数据倾斜（Data Skew）。

2. 深入 Spark UI 定位瓶颈：我立刻进入了正在运行的 Spark Job 的 UI 界面。在 Stages 标签页，我发现有一个 join 操作的 Stage 耗时特别长，并且该 Stage 下的某个 Task 处理的数据量远超其他 Task（几 GB vs. 几十 MB），执行时间也长了几个数量级。这几乎证实了我的数据倾斜假设。这个 join 操作是将用户行为日志和用户画像表通过 user_id 进行关联。

3. 用 SQL 验证根本原因：为了精准定位倾斜的 key，我立刻新开了一个 Spark-SQL 客户端，针对当天的用户行为日志表执行了一个简单的分组计数查询：SELECT user_id, COUNT(1) as event_count FROM user_events_log WHERE dt='YYYY-MM-DD' GROUP BY user_id ORDER BY event_count DESC LIMIT 10;。结果发现，有几个 user_id 的行为记录数达到了千万级别，而 99% 的普通用户只有几百条。这些 ID 并非真实用户，而是用于压测的机器人账号或爬虫账号，它们的数据被 Hash 到同一个 Executor 上，导致该 Executor 内存溢出，频繁进行磁盘 Spill，拖慢了整个 Job。

4. 实施并验证解决方案：定位问题后，我决定采用“加盐（Salting）”的方式来解决。具体来说，我对倾斜的 user_id key 进行了改造：

   • 在 join 的左表（行为日志表），我将 user_id 拼接上一个 0 到 9 的随机数，形成如 user_id_salt_5 的新 key，并将数据量扩大 10 倍。
   • 在右表（用户画像表），我将每一行复制 10 遍，分别拼接上 0 到 9 的后缀。
   • 这样，原本集中在一个 key 上的数据就被打散到了 10 个不同的 key 上，从而被分配到不同的 Executor 处理，解决了单点瓶颈。我先在一个小规模数据集上验证了该逻辑的正确性，然后应用到了全量任务中。

Result（结果） 应用“加盐”策略后，我重新运行了当天的 Spark 任务。

• 任务执行时间从 10+ 小时骤降至 2.5 小时，比历史平均水平还快了 15%，成功保证了当天推荐模型的按时更新。
• 作为后续改进，我将这几个异常的机器人账号 user_id 加入了数据清洗的全局黑名单，并增加了一个数据质量监控告警：每天任务执行前，自动检查关键 key 的倾斜度，当最大 key 的记录数超过平均值 1000 倍时，自动发送告警。此后半年内，再未发生过类似的严重性能问题。

低分陷阱（常见扣分点）

1. 行动归功于团队：错误示范：“我们发现 Spark UI 有问题，我们觉得是数据倾斜，我们决定用加盐来解决。” —— 面试官会追问：“具体是你做的，还是你的同事做的？”
2. 结果没有量化：错误示范：“最后任务快了很多，问题解决了。” —— 这太空洞了。必须说清楚“从 10 小时降到 2.5 小时”，这种对比才具备冲击力。
3. Action 像流水账，缺乏思考：错误示范：“我先看了日志，又看了代码，然后问了同事，最后找到了问题。” —— 这没有体现你的分析和决策过程。要说清楚你每一步的判断依据（为什么看 Spark UI？看到了什么现象？这个现象指向什么结论？）。
4. 问题不够复杂：错误示范：“我发现一个 SQL 查询没加索引，加上就好了。” —— 这种问题太简单，无法体现你在复杂系统（Spark/ML）中的调试能力，更谈不上 Dive Deep。
5. 解决方案治标不治本：只解决了当下的问题，但没有思考如何从机制上避免重蹈覆辙。在 Result 部分补充“建立了监控告警”会是很大的加分项，体现了 Ownership。

高概率追问（3 个 + 示范回答要点）

1. 追问：在采用“加盐”方案之前，你还考虑过其他方案吗？为什么最终选择了这个？

   • 要点 1（备选方案）: 是的，我考虑过两种替代方案。第一种是两阶段聚合。先对 key 进行一次局部聚合，打上随机前缀，然后再进行全局聚合。这能减轻数据倾斜，但实现相对复杂。
   • 要点 2（另一备选方案）: 第二种是过滤异常 key。直接在任务开始时把那几个机器人账号 user_id 过滤掉。这个方案最简单，但我和产品经理快速沟通后，认为虽然它们是机器人，但其行为模式可能在未来被用于模拟真实用户的大流量冲击，有分析价值，不应粗暴丢弃。
   • 要点 3（决策依据）: 最终选择“加盐”，是因为它在**效果（能彻底打散数据）和实现成本（改动较小，只需修改 join 逻辑）**之间取得了最佳平衡，并且保留了原始数据，符合业务长期需求。

2. 追问：你说你增加了一个数据质量监控，能具体讲讲是怎么实现的吗？

   • 要点 1（技术实现）: 我在主任务执行前，增加了一个前置的 Spark SQL 脚本。这个脚本会对当天的数据源执行一个 GROUP BY key COUNT(*) 的查询，然后计算出最大计数值（max_count）和平均计数值（avg_count）。
   • 要点 2（衡量与告警）: 当 max_count / avg_count 的比值超过我们设定的阈值（比如 1000）时，脚本会通过公司的监控 API 发送一个 PagerDuty 告警给 on-call 工程师，并可以选择性地中断主任务的执行，防止浪费计算资源。
   • 要点 3（价值）: 这样做将问题从“事后救火”变为了“事前预警”，体现了从被动响应到主动防御的思维转变。

3. 追问：如果让你重新做一次，有什么地方可以做得更好？

   • 要点 1（更早介入）: 我会推动建立更早期的“数据契约”。在数据产生的源头（比如日志采集端），就应该对压测流量和真实用户流量打上不同的标签。这样在下游处理时，就可以直接分离，而不是在海量数据中做复杂的清洗和倾斜处理。
   • 要点 2（方案优化）: 对于“加盐”方案，随机盐可能会导致新的轻微倾斜。更优化的方式是先对数据进行采样，精确地识别出具体是哪几个 key 倾斜，然后只对这几个大 key 进行加盐处理，小 key 保持原样。这样可以避免不必要的数据膨胀，效率更高。这体现了我对技术方案的深度思考和持续优化的意愿。

故事复用建议

这个故事非常扎实，除了回答“解决性能问题”，还可以根据面试官的提问侧重点，进行微调后复用于以下问题：

• Dive Deep (Amazon): 核心就是这个故事，强调从现象到本质的挖掘过程。
• Ownership (Amazon): 强调你主动发现问题，并负责到底，甚至建立了长期机制。
• Deliver Results (Amazon): 强调最终的量化成果（10h -> 2.5h）和业务影响。
• Are Right, A Lot (Amazon): 强调你基于数据和逻辑（Spark UI 分析、SQL 验证）做出正确判断，而不是凭感觉。
• Bias for Action (Amazon): 强调你发现问题后“立即”介入，快速行动。
• Tell me about a time you solved a difficult technical problem. (通用)
• Describe a time you used data to make a decision. (通用)