欣旺达数据开发一面：数仓分层与实时数仓设计

《面试题目》

1. 请先做个自我介绍。
2. 介绍一下你在部门里面具体负责的项目和你承担的角色。
3. 数据的规模是什么样子的？
4. 你们这边的数据是实时的还是离线的？
5. 说说数仓分层架构。
6. 你有没有处理过数据倾斜？
7. 如果让你来设计一套系统的数据治理方案，会从哪些方面考虑？
8. 数仓出现脏数据之后，一般排查思路是什么？
9. 怎么理解数据血缘关系？
10. 假设现在要搭建一套实时数仓，你会怎么设计架构？
11. 这部分你实际操作过吗？
12. 实时数仓如果出现数据缺失，怎么排查和补数？
13. 数仓开发也会涉及团队规范，你怎么看？
14. 中间件选型和团队技术专家的意见产生冲突，你怎么处理？
15. 你日常工作里，AI 主要用在哪些地方？
16. 使用 AI 时，AI 生成的代码和系统规范冲突，怎么规避？
17. 数据治理和数仓开发免不了和业务沟通，遇到沟通不畅的情况，你怎么解决？
18. 你这边有没有什么要提问的？

（作者反问：面试大概分几轮、数据开发团队有多少人。面试官回答：目前两轮，第一轮技术面，后面可能还有其他部门面试；集团有专门数仓团队，本人所在的是事业部，承接事业部内部需求，后续考虑建设事业部数仓并与集团协同。）

《参考解析》

数仓分层架构：经典四层是 ODS（贴源层，原样落地业务库/binlog 数据，不做清洗，只做分区和压缩，保留可回溯性）、DWD（明细层，做清洗、去重、维度退化、统一编码，一般按主题域和事实表组织，粒度最细）、DWS（汇总层，按维度做轻度聚合，比如用户日粒度、商品日粒度宽表，供上层复用）、ADS（应用层，直接对接报表、看板、接口的指标结果表）。中间还会有 DIM（维度层，缓慢变化维用拉链表处理）和 DWT（主题宽表）。分层的目的有三个：一是解耦，底层口径变了只改一层，不用动所有报表；二是复用，DWS 的聚合结果能被多个 ADS 复用，避免重复计算；三是可控，每层可以做质量校验和血缘追踪。回答时要补一句规范：表命名要有层级前缀和更新周期标识（比如 dwd_order_di、dws_user_1d），分区字段统一用 dt，避免各部门各叫各的。

数据倾斜：先给现象——某个 reduce/task 处理的数据量远大于其他，表现为任务卡在 99%、某个 key 处理时间异常长、OOM。常见成因：join 的 key 分布不均（少数热点 key 占大部分数据，比如大客户 ID、null 值、默认值）、group by 维度基数过小、count distinct 全局去重。定位手段是看 Spark UI / Hive 任务的分区数据量分布，或先对 key 做 count 排行找出热点。解法按类型给：join 倾斜用 map join（小表广播）、热点 key 加随机前缀打散后两阶段聚合、SMB join（分桶表按桶 join）；null 或默认值导致的倾斜先把无效 key 过滤或单独处理；group by 倾斜用两阶段聚合（先加随机前缀局部聚合，再去掉前缀全局聚合）；count distinct 改成先 group by 去重再 count。要补一句根治思路：能从建模层解决就别只在 SQL 层打补丁，比如把热点维度单独拆表、在写入侧做预聚合。

数据治理方案：按六个域给框架。元数据管理（采集表/字段/任务/血缘，形成资产目录，是其他一切的基础）；数据质量（定义规则：非空率、唯一性、值域、及时性、一致性，配 DQC 校验任务 + 分级告警 + 阻断机制，问题数据要有隔离区）；数据安全与权限（分级分类、脱敏、行列级权限、审计日志）；成本治理（存储生命周期、冷热分层、无用任务下线、计算资源配额与慢任务治理）；标准规范（命名规范、指标口径唯一化、开发规范、上线评审流程）；以及组织机制（Owner 制度、SLA、问题复盘）。落地要强调「先量化再治理」：先出一份体检报告（表数量、僵尸表占比、任务失败率、重复指标数），按影响面排优先级，一个季度解决一类问题，而不是一次性上全部规则。

脏数据排查：标准流程是「定位范围 → 判断类型 → 追溯来源 → 修复 → 加防线」。先确认影响面：哪些表、哪些分区、影响多少下游报表和指标，先止血（暂停下游任务或标记数据不可用，避免污染扩散）。再判断类型：是格式错误、重复、缺失、值域越界，还是口径不一致。然后沿血缘往上追：对比源表数据、检查 ETL 逻辑最近是否有变更、看任务日志和调度记录（是否有补数、重跑导致重复写入），常见根因是上游改字段类型、上游直接改库不通知、任务重跑没做幂等导致数据翻倍。修复上按幂等重算覆盖目标分区，而不是手工改数；同时保留问题数据快照便于回溯。最后加防线：给这张表补 DQC 规则、给上游变更加通知机制、把这次事故写成案例。

数据血缘关系：血缘描述数据「从哪来、到哪去」，分表级和字段级。表级血缘回答「改这张表会影响哪些下游」，字段级血缘回答「这个指标的口径由哪些字段计算而来」。它的价值有四个：影响分析（下线表/改字段前评估影响面）、问题溯源（报表数据不对时快速往上定位到出问题的任务）、口径治理（同一个指标多处计算时能发现重复定义）、以及合规审计（敏感字段流向哪里）。实现上通常靠解析 SQL（AST 解析出输入输出表与字段）、结合调度平台的依赖关系，以及运行时的执行日志采集，落到图数据库里供查询。工程上难在动态 SQL、临时表、UDF 和跨引擎链路的解析覆盖度。

实时数仓架构设计：标准分层是 ODS（binlog/日志经 Kafka 落地）→ DWD（Flink 做清洗、去重、维度关联，写回 Kafka 或湖表）→ DWS（Flink 窗口聚合或 ClickHouse/Doris 物化视图）→ ADS（OLAP 引擎对外服务），整体是 Lambda（离线保准确 + 实时保时效）或 Kappa（统一流处理）两种范式。要讲清几个关键技术选择：数据接入用 CDC（Canal/Flink CDC）而不是业务库直连查询，避免影响线上；维表关联用维表变化流（lookup join + 状态缓存）或广播维表，并处理维度迟到的场景；一致性上，用 Flink checkpoint + 两阶段提交保证端到端精确一次，或者接受至少一次 + 下游幂等；存储上明细放 Kafka/湖（Iceberg/Hudi/Paimon 支持 upsert 和增量读），聚合结果放 OLAP 引擎；服务层要能支撑高并发点查和看板查询。工程上必须配的三件事：指标口径与离线对齐（同一指标实时和离线要能对账）、数据延迟监控（端到端延迟 SLI）、以及回刷历史的能力。

数据缺失排查与补数：排查按链路从下游往上游倒推：先看目标表的分区是否存在、是否有数据；再看任务实例状态（有没有失败、是不是被上游阻塞、调度是否因资源不足延迟）；然后看 Kafka 消费位点（是否 lag 或 offset 重置）、Flink 作业是否重启且从错误 checkpoint 恢复、source 端（binlog 位点是否被清理、上游是否没产出）；再往上确认业务侧是否真的没产生数据（比如大促停了某类业务、上游系统故障），避免把「业务无数据」误判成「链路丢数」。补数方案按场景选：离线分区直接重跑任务覆盖写入（前提是逻辑幂等）；Kafka 丢数用源端 binlog 按时间区间重放（Kafka 保留期内的 offset 重放，或从离线 ODS 回灌）；Flink 状态丢失需要从上游重新消费并处理下游重复（配合幂等写入/主键 upsert）。补完必须做两件事：跑数据量对比（与前一天同口径、与离线结果对账）并记录补数操作到变更台账，同时在监控上把「数据量环比波动超阈值」做成自动告警，下次能在小时级发现而不是等到业务投诉。

团队规范与沟通类问题：规范类问题（第 13、14 题）要用「先对齐目标、再谈方案」的结构回答：规范的价值是降低协作成本和事故率，但规范本身要可执行、有 Owner、能随场景演进；与专家意见冲突时不要上升到对人的对抗，先摆数据（压测结果、成本、维护成本、团队熟悉度），把分歧收敛到可验证的指标上，如果仍然无法一致，按影响面升级给决策人，并明确记录「谁决策、依据是什么、什么条件下重新评估」。与业务沟通不畅时，先确认是需求不清楚还是期望不一致：把口径书面化（指标定义、数据范围、更新时间）、给出原型或样例数据让对方确认，建立固定的对接人和变更通知机制；对反复变更的需求用需求评审和冻结期约束，而不是靠加班补。

AI 在日常工作里的用法与规范冲突：数据开发里 AI 主要用在写 SQL 与调优（给出改写建议、explain 解读）、写调度脚本与 Python 处理逻辑、生成文档和数据字典、解释陌生表和字段、以及生成测试数据与用例。规避「AI 代码与系统规范冲突」的做法是三层：一是把规范前置成可执行的约束（SQL 模板、lint 规则、命名检查、CI 里的格式与口径校验），让 AI 的产物先过机器检查；二是把团队规范做成提示词上下文（让 AI 按我们的命名和分层规范产出），而不是事后人工返工；三是高风险改动（涉及资金、核心指标的 SQL）必须人工复核并走评审，AI 只作为初稿工具。核心口径是「规范要靠工具强制，不能靠自觉」。

反问：这场面试里作者问的是轮次和团队规模，得到的信息很关键——两轮技术面、事业部与集团数仓团队的分工关系、后续要建事业部数仓。这类信息比「团队氛围怎么样」有用得多，因为它直接决定你入职后的职责边界。可以继续追问的：实时链路的覆盖范围、数据量级与集群规模、团队内离线与实时的分工比例。