---
name: data-engineering
description: 数据工程怎么面：数仓建模、离线与实时链路、调度、数据质量、湖仓。数据开发与数仓岗读。
keywords: [数据开发, 数仓, 大数据开发, etl, data engineer, hive, spark, flink, 维度建模, 实时数仓, 湖仓, iceberg, paimon, dolphinscheduler, 数据质量]
layer: domain
---

## 面试官在意什么

数据开发 / 数仓工程师负责把业务数据变成可信、可用、可持续交付的数据资产：建模分层、写离线和实时任务、维护调度依赖、保障数据质量与 SLA、控制存储与计算成本。真实面试里被问最多的是建模判断（这张表该怎么设计、口径谁定）、链路事故（数据晚了、错了、重了怎么查）、以及性能与成本（任务跑不完、集群费用涨了怎么办）。面试官最在意三件事：一是有没有真正对数据准确性负过责——出过事故、补过数、回溯过口径；二是建模能不能落到业务，而不是背 Kimball 四步；三是对链路全貌的理解：从埋点采集到报表，哪一环出问题会怎么表现。

校招侧重 SQL 功底（窗口函数、多表关联、去重与留存计算）、数仓分层与维度建模的基本概念、Hive/Spark 的执行原理；社招侧重实时数仓与湖仓选型、数据质量体系、任务治理与成本优化、跨团队口径协调。一线大厂近年明显更看重"数据资产化"与"降本"，外企则更关注 pipeline 的工程规范（测试、版本、幂等）。

怎么问才像这个方向的面试官：
- 所有题目都要挂在"数据准确性"或"链路事故"上：不问"什么是拉链表"，问"这个场景用不用拉链表、不用的话怎么回溯"。
- 必须结合候选人的数据规模：日增 GB 级与 PB 级的最优方案完全不同，先问清规模再评判方案对错。
- 不要考组件版本与参数名，考执行原理与排查顺序；候选人说"调参数"要追它改变了执行的哪一步。
- 建模题要给出具体业务场景（订单、日志、用户）与冲突需求，让候选人现场定粒度、说取舍。
- 2026 年数据工程的架构主线是批流一体的湖仓：开放表格式（Iceberg 一类）成了跨引擎的存储标准，实时链路靠 CDC 与流处理引擎直接写湖，AI 场景对数据新鲜度提出了新的 SLA。面试官会追候选人怎么统一批与流、表格式解决了什么、新鲜度怎么量。

## 项目 / 实习怎么深挖

简历上出现下面这类经历时从哪里切、追什么。追到候选人能说出机制、数字的来源与一次真实的故障或取舍才算实；只有框架名与结论、说不出自己那一段的，记为危险信号。通用的追问方法见 project-deep-dive。

- 简历出现"搭建数仓" → 追分了几层、粒度怎么定、公共层复用率、你自己建的表被多少下游用
- 简历出现实时数仓 / Flink → 追状态大小、checkpoint 间隔与耗时、迟到数据处理方式、出过什么事故
- 简历出现"数据质量体系" → 追规则数量、阻断率、误报率、最近一次靠它拦住的问题
- 简历出现"性能优化 X 倍" → 追优化前后耗时、怎么定位瓶颈、改了什么、数据量多大
- 简历出现 Iceberg / Hudi / Paimon → 追为什么迁、迁前痛点、小文件与元数据怎么治理
- 简历出现调度平台（Airflow / DolphinScheduler）→ 追任务规模、依赖设计、重跑与补数机制、SLA 达成率
- 简历出现"数据治理 / 指标体系" → 追口径冲突的具体案例、怎么推动统一、变更管理流程
- 简历出现 CDC / Debezium / Canal → 追 delete 与 schema 变更怎么处理、延迟多少、断点恢复怎么做

## 常见失守与危险信号

- 数仓分层与建模落地：只会背分层名字；说不出自己负责过的表在哪一层、上下游是谁；认为"多建宽表就是好"
- 维度建模与事实表设计：粒度说不清；把所有字段堆进一张表；不知道拉链表回溯查询怎么写
- 离线链路与 SQL 优化：直接说"加 executor"；不看执行计划；不知道倾斜表现为什么是少数 task 跑很久
- 调度与任务治理：不知道任务是否幂等；补数靠手工改日期跑；没有基线或 SLA 概念
- 数据质量与可观测：只有"跑完了"没有"跑对了"的检查；出问题从上游一张张表人肉看
- 指标口径与数据资产管理：认为口径是业务的事与数仓无关；口径改了没有变更记录
- 数据采集与埋点：认为数据来了就是对的；不知道 binlog 里 update 会怎么表现
- SQL 现场题与执行原理：只会 group by 不会窗口；join 后行数翻倍没意识到；count(distinct) 在大表上直接跑不知道会倾斜

## 常考主题清单

只列名字、阶梯与答实的标志，作"问到哪一层算实"的参考；问哪些、问几道由这份 JD 与这份简历定，不是配额。

### 数仓分层与建模落地
- 阶梯：ODS/DWD/DWS/ADS 各层解决什么问题 → 为什么分层能减少重复计算、隔离变化，分层过多的代价 → 业务方直接查 ODS 绕过数仓、DWS 表爆炸式增长怎么治理 → 宽表 vs 星型模型、一致性维度与"每个业务线自建一套"的取舍
- 答实的标志：能用血缘和访问日志判断表价值；理解公共层复用率指标；知道分层是为了口径统一，而不是为了分层本身

### 维度建模与事实表设计
- 阶梯：事实表与维度表的区别，粒度怎么定 → 事务事实表、周期快照、累积快照各自适用场景 → 订单状态频繁变更导致事实表重复、指标口径不一致怎么排查 → 缓慢变化维（SCD2 / 拉链表）的存储与查询代价，什么时候干脆存快照
- 答实的标志：先定粒度再定字段；累积快照处理多阶段流程；理解退化维度与代理键；知道 SCD2 对下游 join 的影响

### 离线链路与 SQL 优化
- 阶梯：一条 Hive/Spark SQL 的执行流程 → 分区、分桶、小文件对性能的影响 → 任务从 30 分钟涨到 3 小时怎么定位（数据倾斜、笛卡尔积、分区裁剪失效）→ 加资源、改 SQL、改模型三种手段的优先级
- 答实的标志：先看执行计划与 stage 耗时分布；分区裁剪、谓词下推是否生效；倾斜 key 的定位与拆分；小文件合并策略

### 调度与任务治理
- 阶梯：为什么需要调度系统而不是 crontab → DAG 依赖、重跑、补数、幂等分别怎么保证 → 上游延迟引发下游连锁失败、任务重跑导致重复写入怎么处理 → SLA 分级与基线告警的设计，资源队列的优先级怎么定
- 答实的标志：任务写入按分区覆盖保证幂等；核心链路基线告警；依赖检查用分区就绪而不是固定时间

### 数据质量与可观测
- 阶梯：数据质量看哪几个维度（完整性、准确性、一致性、及时性、唯一性）→ 规则校验放在链路哪个位置，阻断还是告警 → 指标突然掉 30% 是数据问题还是业务问题怎么快速判断 → 全量校验的成本与抽样、分层校验的取舍
- 答实的标志：从源头波动率、分区记录数、主键唯一性逐层排查；有血缘辅助定位；核心表配置阻断规则

### 指标口径与数据资产管理
- 阶梯：同一个"活跃用户"为什么各部门数字不一样 → 指标定义（原子指标、派生指标、修饰词）与统一口径 → 口径变更后历史数据要不要回溯、怎么通知下游 → 指标平台 vs 靠文档约定的投入产出
- 答实的标志：区分原子指标与派生指标；口径变更有版本与生效时间；血缘能找到所有受影响的下游

### 数据采集与埋点
- 阶梯：日志、binlog（CDC）、接口拉取各适用什么 → CDC 的顺序、删除、schema 变更怎么处理 → 埋点丢数、重复上报怎么发现和补 → 采集侧治理（埋点规范、上线校验）投入与下游清洗成本的关系
- 答实的标志：埋点校验与灰度对比；CDC 处理 delete 与主键变更；采集侧带版本号

### SQL 现场题与执行原理
- 阶梯：去重、topN、连续登录、留存这类题怎么写 → 窗口函数、多表 join 的行数放大、null 参与比较与聚合的语义 → 同一段 SQL 在 Hive 与 Spark 结果不一致、count(distinct) 跑不动怎么处理 → 一条复杂 SQL 拆成多步中间表的可维护性与性能权衡
- 答实的标志：先确认口径再写；用 row_number 与日期差做连续分组；大基数去重用两阶段聚合或近似算法；对结果做总量对账