华勤数据开发面经：数仓分层、Hive 与 Spark SQL 细节追问

《面试题目》

1. 请先简单做个自我介绍。
2. 你现在是在校状态吗？学校在哪个城市？你是哪里人？考虑发展的城市有哪些？
3. 上一段实习有半年，为什么干了这么久？为什么没有留下来？
4. 看板主要是用的什么工具？
5. 你能简单介绍一下完成需求时的数据链路吗？比如从哪里拿的数据、做了哪些加工，最后报表端如何呈现、交付给报表使用方。
6. 这边用的也是 Hive 吗？
7. 它底层的引擎是什么？
8. 你从上游数据来源接入到 ODS 层，接触过程中有碰到什么问题吗？
9. 你这半年做的项目，是很多临时小需求，还是参与一整个完整项目？
10. 这个项目主要是为了实现什么？
11. 你讲一下你对数仓的理解。
12. 你讲一下 Hive 和 MySQL 有什么区别？
13. 你交付到 MySQL，他们后续会怎么使用？
14. 也就是说看板这块不是你负责，由其他岗位完成是吗？
15. 你用了这么多大数据组件，你对这些组件的基本原理熟悉多少？
16. Spark 底层有了解吗？比如 Spark 的内存管理是如何进行的？
17. 你用的是 Spark SQL 还是什么？
18. 你上面提到的水印，Flink 用了吗？
19. 你主要用的就是 Spark SQL 是吧？Hive 接触多不多？有没有实际使用场景？
20. 有没有使用一些 AI 工具做相关研究？有没有尝试过自己写一些实用性的工具？
21. 你是广东人吗？期望的工作城市只有广东，还是其他城市都可以？
22. 我看你做过学生会主席，是院系还是校学生会？平时会组织什么样的活动？
23. 你这边有什么需要咨询的吗？

《参考解析》

数仓分层要答出「收益与代价」，而不是背层级名字：ODS、DWD、DWS、ADS 这套划分的意义在于把「原始数据」和「口径」解耦。不分层、直接从原始数据一次算到指标层，短期看少了几次落表、跑得更快，但指标一改就要动全链路，出了问题只能在「原始数据」和「成品」之间二分查找，中间没有任何可对比的痕迹；分层之后，改口径落在 ADS、改聚合维度落在 DWS，改动的爆炸半径被限制在一层，并且每层的表可以复用给别的业务线——这一点在面经里格外值得说，因为复用是分层最实际的收益。代价同样要说：链路变长会带来额外的计算与存储开销、调度依赖变复杂、每一层都要做治理（分区裁剪、生命周期、小文件合并、资源与耗时监控）。被追问「什么时候可以不分层」时，可以答数据量小、需求稳定、只有一两个固定报表的场景，多一层的收益抵不上维护成本。

Hive 与 MySQL 的区别要落到「各自的活」上：Hive 是面向离线批处理的 SQL 引擎，表本质上是 HDFS 上的目录加元数据，SQL 最终编译成分布式作业在集群上跑，擅长全表扫描、大规模聚合，延迟以分钟计，而且不擅长高并发的点查与行级更新。MySQL 是行存的 OLTP 数据库，有索引和事务，适合低延迟查询与结果存储。所以两者常常串起来用：Hive 侧产出宽表与指标，再把结果同步到 MySQL 供 BI 或业务系统查询。这里有一个高频追问点——「同步过去之后他们怎么用」：是报表工具直连、还是业务系统读、是全量覆盖还是增量更新、失败了怎么补数、口径以哪边为准。回答里把这几个问题说清楚，比背 Hive 与 MySQL 的技术参数更像做过链路。顺带要能答 Hive 底层引擎：常见是 MapReduce、Tez 或 Spark，同一句 SQL 换引擎会明显改变执行计划与耗时；被问「你们底层引擎是什么」时，结合自己集群里的实际配置答，不要含糊。

「介绍你的数据链路」是这场面试的主线，要能按数据流讲一遍：稳妥的讲法是一条线走到底：上游有哪些来源（业务库、日志、埋点、接口），怎么接进 ODS（全量快照还是增量抽取、按天分区还是按小时），在 DWD 做了哪些清洗与规范化（去重、空值、单位与字典统一、拉链表或快照处理），DWS 怎么聚合、ADS 怎么出指标，最后交付形式是什么（看板、报表、接口、给下游团队的表），以及调度依赖、产出时间、失败重试与数据质量校验挂在哪一步。面试官问「接上游碰到什么问题」，考的其实是真实经历，常见答案有：上游字段变更或延迟导致任务空跑、主键不唯一带来的重复数据、编码与时区不一致、业务口径临时变化、历史数据补数。答的时候要说清「怎么发现的、怎么定位的、最后怎么修的」，只说「沟通解决了」会显得没做过。

Spark 内存管理与「水印」这类概念题，答之前先分清自己用没用过：Spark 的执行内存与存储内存由统一内存管理器分配，两块默认各占一半且可以互相借用，执行内存不足时会 spill 到磁盘，这也是为什么「加大 executor 内存」不总能解决 OOM——更常见的原因是分区数据倾斜、单分区过大或缓存过多。Spark SQL 走的还是 Catalyst 优化器加代码生成这套，join 策略、分区数、是否有 shuffle 都会显著影响耗时。数据倾斜的典型表现是少数 task 长时间不结束、shuffle 读写量远高于平均、频繁 spill；处理手段包括加盐打散热点 key、把大表带小表的 join 转成广播、过滤空 key、调并行度。关于水印：它是流处理里的概念，表示「晚于这个时间到达的数据按迟到处理」，配合窗口与允许迟到时长使用，Spark Structured Streaming 和 Flink 都有对应机制。原帖面试官正是抓住候选人自己提过的「水印」去问 Flink 用没用——这类追问的用意是分辨「背过概念」还是「真在项目里用过」，所以最稳的答法是明确区分：哪些组件是自己写 SQL 天天用的，哪些只是了解原理、看过文档，别把了解说成实战。

AI 工具与个人问题：给具体做法，别给态度：被问有没有用 AI 做数研、有没有自己写过实用工具时，回答要落在「用它做了什么、怎么保证结果可用」。例如用模型辅助写 Hive SQL 与 DDL、根据报错日志定位问题、把重复的口径说明整理成文档模板，同时说明验证方式（小样本对账、先跑 limit、与既有指标比对）。自己写的小工具可以是调度告警聚合、表血缘导出、字段说明生成这类贴身的东西，说清解决了自己什么痛点就够了。至于实习时长、为什么没留用、期望城市、学生会经历这些，考的是稳定性和表达的一致性，答法是一是一、二是二，给确定的范围而不是含糊的「都可以」，同一件事在 HR 面和业务面说法要能对上。最后的反问环节是加分项：问团队承担的活儿、数据团队规模、AI 在团队里的落地程度，比问薪资更能得到有效信息。