中邮消费金融数据开发面经：数据倾斜、Iceberg 小文件与事务、数仓如何配合 AI

《面试题目》

1. 请用 2 分钟做一个自我介绍。
2. 你做过 Hive 优化，怎么定位数据倾斜？
3. 你们使用 Iceberg，版本是哪一个？
4. 你们如何解决 Iceberg 的小文件问题？
5. Iceberg 是否支持事务？
6. 建表使用的是 Iceberg V1、V2 还是 V3 版本？
7. 你的项目是你一个人搭建的，还是团队有负责人一起搭建？
8. 你和团队成员分工是怎样的？传统数仓和 AI 是怎么配合、怎么借助 AI 提升链路效能？
9. 你对我们公司有什么想要了解的？你清楚我们公司业务吗？

《参考解析》

数据倾斜怎么定位。 先看现象再找原因：Spark 里看 stage 的 task 耗时分布和 shuffle read size 的极值，Hive 看 job 的 map/reduce 进度卡在 99% 且少数 reduce 长时间不结束。定位手段是采样 key（count(*) group by key order by 2 desc limit）确认热点 key，或直接看执行计划里的 join 策略。常见成因与处置：join 大表遇热点 key（map 端 join、给热点 key 加随机后缀两阶段聚合）、group by 维度过少（先局部聚合再全局）、空值/null 集中（先过滤或给 null 打散）。答题时按「现象 → 定位 → 归因 → 处置」讲一次真实经历最稳。

Iceberg 小文件。 流式写入和频繁小批提交是主因。手段是控制提交间隔（微批攒大）、写入端做文件大小目标（target file size）、定期跑 rewrite_data_files 合并、配合 rewrite_manifests 收敛元数据，delete 文件多时做 rewrite_position_delete_files。回答时补一句权衡：合并太频繁会放大写放大，通常按分区和时效分层调度。

Iceberg 的事务与版本。 Iceberg 提供的是表级原子提交与快照隔离：每次 commit 生成新的 metadata 快照，读者基于快照读，不会看到半成品，冲突靠乐观并发（提交时校验 base snapshot）解决——所以「支持事务」严格说是支持原子提交与隔离，不是关系库那种跨表多语句事务。V1 只支持追加与全量覆盖，V2 增加了行级删除（position/equality delete）与更完善的演进能力，V3 进一步引入删除向量等能力；建表版本要和引擎支持度对齐，升版本是不可逆的，生产上一般先确认引擎版本再定。

项目与分工题。 面试官想确认你的角色边界：是「一个人从头搭」还是「在团队里负责一段」。诚实说清自己负责的模块、上下游依赖谁、遇到分歧怎么定，比夸大成全栈更有说服力。被问到 AI 配合，可以讲具体链路：用 LLM 做需求转 SQL 的草稿、指标口径问答、异常任务的日志归因、数据质量规则生成——并说明人工复核的边界在哪，避免把 AI 说成万能。

反问。 面试官在这个环节透露的信息量很大：数据管理团队四五十人、分数据基础平台（组件维护、数据治理、资源治理与性能优化）与数据开发（已把 AI 融进需求分析、代码开发、测试），同时在做智能问答、智能报表、智能检索，一条面向业务、一条面向 AI（DataFor 方向为 AI 提供高质量数据）。这类信息可以直接用来判断岗位真实内容与你是否匹配——比如关心「AI 落地深度」就问具体环节的覆盖率与人工介入比例。