半亩花田数据开发面经 从数仓同步问到 AI 写 SQL

《面试题目》

1. 请先简单做一下自我介绍。
2. 刚才你讲了数据采集相关的工作，你能展开讲其中一个具体场景吗？
3. 业务系统内部的数据，怎么同步到数仓？
4. 你们现在的数据采集入湖方式是什么？
5. 你大部分工作是在已有原始数据基础上做数据开发吗？
6. 你简单讲其中一项工作。
7. 这是你的业务场景，你说下用到的技术手段。
8. 从底层数据到应用层数据，这就是你的开发工作模式？
9. 是在湖仓一体平台上做的吗？
10. 平台集成数据开发和调度能力？
11. 在这个数据开发过程中，你觉得哪部分比较复杂？
12. 写 SQL 的时候是手动写，还是用平台工具？
13. 给 AI 指令，它能理解表结构吗？
14. 开发里常用窗口函数吗？
15. 除使用的这套技术栈，你还了解其他数仓相关技术吗？
16. 你意向工作城市是哪些？
17. 在校成绩怎么样？
18. 作为数据开发工程师，你觉得自己擅长哪些部分，短板是什么？
19. 你的职业发展方向是什么？
20. 你目前有没有投递其他公司，拿到 OC？
21. 其他岗位是什么行业？
22. 城市方面没有特殊要求对吧？
23. 期望薪资大概是什么范围？
24. 方便了解家庭情况吗，父母，有没有兄弟姐妹？
25. 如果之后不在本地工作，父母可以理解接受吗？
26. 你有没有什么问题想了解岗位和业务？

《参考解析》

业务系统数据怎么同步到数仓：先按场景选方式，而不是一套方案打天下。能碰 binlog 的 OLTP 库优先走 CDC（Canal、Debezium、Flink CDC）做增量，好处是不用扫业务库、延迟低；没有 CDC 条件或数据量小的维表用 DataX、Sqoop 之类批量抽，靠 update_time 或自增 id 做水位线增量，但必须处理两个经典漏数场景——更新不改时间戳（业务代码只改状态没更新时间）和物理删除（源库 delete 了，数仓不知道），常见兜底是要求软删除、或定期做全量对账。落地上要讲清分层：ODS 贴源、只做字段规范与按天分区，DWD 做清洗去重与维度关联，DWS/ADS 做聚合和应用层表。工程要求四件事：同步任务可重跑（幂等写、按分区覆盖）、有数据质量校验（条数、主键唯一、枚举值合法、与源端对账）、有延迟与失败告警、有血缘和口径文档——面试官问「哪部分最复杂」，答「口径对齐和数据质量」比答「SQL 难写」真实得多。

湖仓一体平台与调度：湖仓一体的价值是一份存储、多种引擎都能读（Spark、Flink、Trino、Hive 都能查同一张表），靠 Iceberg、Hudi、Paimon 这类表格式提供 ACID、时间旅行、schema 演进和小文件合并，避免传统 Lambda 架构里离线与实时两套链路算出口径不一致的两份数据。平台通常把开发（SQL 编辑器、版本管理、调试）、调度（DAG 依赖、补数、重跑、优先级）、元数据与权限集成在一起。调度这块要能讲细节：任务之间靠依赖而非时间硬编，失败重试要有上限和告警，补历史数据时按分区串行并限流，避免把下游集群或业务库打爆；上游表延迟时要能判断是等还是跳过。

窗口函数常用场景：三类最常用。排名去重，row_number() over (partition by id order by update_time desc) 取每个 id 的最新一条，这是数仓里最高频的用法；同环比与累计，用 lag/lead 取上一期，用 sum(x) over (order by dt rows between unbounded preceding and current row) 做累计；分组占比，sum(x) over (partition by dim) 做分母再与明细相除。两个必须知道的边界：窗口函数在 where、group by 之后、order by 之前执行，所以想过滤窗口计算结果必须套一层子查询；数据量大时 partition by 的 key 倾斜会让单个 task 长尾，需要两阶段聚合或加盐打散。

AI 辅助写 SQL 的边界：模型「能理解表结构」是有前提的——你得把建表语句、字段名、类型、注释和少量样例数据放进上下文，而且业务口径必须由你告诉它：只给字段名，它很容易把「订单金额」当成含税或不含税、把状态码猜错、把该排除的测试单算进来。实践上：把 DDL 和注释维护干净本身就有复利；让模型生成的是骨架（join 关系、分组、窗口），过滤条件和口径自己确认；产出先在 limit 小样本上验证行数与金额合计、跟现有报表对数，再上生产；任何情况下别把生产库真实数据贴给外部模型，只给 DDL 和脱敏样例。最后把它写对的 SQL 沉淀成模板或指标定义，而不是每次重新生成——AI 在这里省的是打字时间，不是口径判断。