荣耀数据开发工程师面经：数仓分层、数据倾斜与学习能力追问

《面试题目》

1. 请你谈谈对数据开发岗位的理解。
2. 工作中遇到不熟悉的业务或者技术，你会采用哪些方式进行学习？
3. 介绍一下你的专业。
4. 你觉得本科课程和业界之间存在差距吗？可以举例说明。
5. 大学期间哪一门课程你觉得学习难度最高，为什么？
6. 你平时学习新技术有什么学习方法？
7. 项目推进过程中，如果业务方对你提出的方案存在质疑，你会如何处理？
8. 如果对接的业务人员无法理解方案、不能做决策，你会怎么处理？
9. 能否结合一段实习经历，讲讲你跨业务对接、处理业务需求的场景？
10. 介绍小米自研数据平台，以及你在平台上完成的项目工作。
11. 谈一谈你对数仓分层的理解，分层的优缺点是什么？
12. 什么是数据倾斜？产生的原因以及对应的优化方式有哪些？
13. 你有什么想要向面试官提问的问题吗？

《参考解析》

数仓分层：价值在「变更的爆炸半径」，代价在链路长度：分层的本质是把加工过程切成可独立替换的几段，让「口径」「明细」「聚合」各归其位。最直接的收益是定位与变更：不分层一次算到底，指标异常时只能在原始数据和成品之间二分查找，指标一改就得重跑整条链路；分层后改口径落在应用层、改聚合维度落在汇总层，影响面可控，中间每一层还能留下可对比的中间结果。第二个收益是复用：明细层和汇总层的表能被别的业务线直接取用，省下重复开发，这在多业务共享的公司里比性能收益更值钱。代价同样明确：链路变长意味着多次落盘，计算与存储成本上升，调度依赖变复杂，每一层都要配套治理（分区裁剪、生命周期管理、小文件合并、任务耗时与资源水位监控），治理跟不上就会出现「层数很多但没人敢改」的状态。被追问「既然分层更慢为什么还要分」时，可以补一句判断标准：数据量小、需求稳定、只有一两张固定报表时，少分一两层反而更划算，分层的层数应当由复用需求和变更频率决定，而不是照搬教科书。至于具体层次的答法，ODS 贴源、DWD 做清洗与规范化、DWS 做主题聚合、ADS 面向应用，各层职责讲清即可，面试官更在意你是否理解每层的边界。

数据倾斜：先说现象，再说成因，最后落到可验证的手段：数据倾斜指作业中少数 task 处理的数据量远超其他 task，表现为整个 stage 卡在最后几个 task 上、shuffle 读写量严重不均、频繁 spill 甚至 OOM。成因主要有几类：join 的 key 分布不均（有个别超热 key，或者大量记录 key 为空）、group by 维度基数极低、count distinct 这类需要把明细拉到一起计算的操作、以及分区键选得不好导致单个分区过大。优化手段要和成因对上：热点 key 可以用加盐打散再两阶段聚合，空 key 先过滤或统一打散；大表 join 小表改成广播（map join），避免 shuffle；开启自适应执行里的倾斜 join 优化；提高并行度只能缓解不能治本，因为热点本身没变。答的时候最好带一次真实经历：怎么发现的（看 Spark UI 里 task 耗时分布与 shuffle 大小）、试了什么、最后哪个生效、效果怎么衡量——这比罗列十条优化技巧更可信。

学习类问题：考的是方法和自知，不是热情：被问「遇到不熟悉的技术怎么学」「学习方法是什么」时，笼统答「看文档、多实践」等于没答。可以给一条有结构的路径：先判断卡点属于哪一类（是业务规则不清楚，还是技术工具不会用，还是数据本身有问题），再选来源（官方文档与源码优先、内部文档与上下游同事次之、社区与模型辅助最后），然后做小范围验证（造最小样例跑通、拿一小段真实数据对账），最后沉淀成可复用的东西（一段模板 SQL、一份字段说明、一条排查清单）。「本科课程和业界有差距吗」这道题可以举具体的例子而不是发牢骚：学校讲得清的偏原理与算法，业界更在意工程约束——数据规模、成本、交付时间、口径责任、上下游依赖；也可以说学校训练的是「为什么会这样」，业界要求的是「出了问题多快能定位」。同理，被问「哪门课最难」时，重点不是课程名字，而是你面对难内容时用了什么办法、最后拿到什么结果。

方案被质疑、对方决策不了：把它当协作问题而不是说服问题：业务方质疑方案时，先分清他质疑的是数据口径、实现成本、上线时间还是风险承担，四者的应对完全不同。口径问题拿对账结果说话（同一个指标两条链路跑出来差在哪、以哪边为准）；成本问题给出量化对比（存储涨幅、任务耗时、资源占用）；时间问题给最小可用版本和后续迭代点；风险问题给出回滚方案和影响范围。争论中最有效的一步是把分歧写成可验证的一两个具体问题，用小样本先跑出答案，而不是在会上互相说服。对接人理解不了、又不敢拍板时，别停在原地等：把他的处境复述清楚（他担心的是影响别的业务、还是权限不够），同时向上找到能决策的人，并提供带影响面的选项（方案 A 快但影响面大、方案 B 慢但可回退），让决策变成一个二选一而不是开放式讨论。这类题通常还会顺着追问「如果两边都是你的领导怎么办」「如果最后按不是你建议的方案做了怎么办」，准备好的立场是：把差异和后果书面留痕、执行时按最终决定做，并说明你保留的观察点。

讲实习经历要落到「你的动作」上：被要求结合实习讲跨业务对接时，用四段式说：对方要什么（业务目标与验收口径）、你把它翻译成了什么（指标定义、数据范围、产出形式、更新频率）、过程中怎么对齐（评审、样例确认、口径文档、变化如何通知）、最终怎么验收（对账、口径复核、使用方确认）。跨部门场景里最容易出彩的细节是「需求反复变更怎么办」——比如把口径写成可配置项而不是硬编码、把版本与变更记录留痕、在交付前让使用方确认样例数据。至于介绍数据平台与项目，一条经验是别按平台功能讲，按你负责的那条数据链路讲：从哪张表取、怎么加工、产出给谁、踩过什么坑。最后的反问同样值得准备，问岗位在公司的定位、数据团队规模、AI 在业务里的落地程度，这类问题能拿到真实信息，也比问薪资更得体。