---
name: data-engineering
description: 数据工程出题：数仓分层与维度建模、离线与实时链路、调度与数据质量、存储格式与湖仓、成本与性能。岗位或简历涉及数据开发、数仓、大数据开发、ETL 时加载。
keywords: [数据开发, 数仓, 大数据开发, etl, data engineer, hive, spark, flink, 维度建模, 实时数仓, 湖仓, iceberg, paimon, dolphinscheduler, 数据质量]
layer: domain
---

## 岗位职责与考察重点

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

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

## 主题

### 数仓分层与建模落地
- 阶梯：ODS/DWD/DWS/ADS 各层解决什么问题 → 为什么分层能减少重复计算、隔离变化，分层过多的代价 → 业务方直接查 ODS 绕过数仓、DWS 表爆炸式增长怎么治理 → 宽表 vs 星型模型、一致性维度与"每个业务线自建一套"的取舍
- 好题：你接手一个有 3000 张 DWS 表、一半没人用的数仓，怎么判断哪些能下线、下线过程怎么保证不影响下游？
- 危险信号：只会背分层名字；说不出自己负责过的表在哪一层、上下游是谁；认为"多建宽表就是好"
- 期望信号：能用血缘和访问日志判断表价值；理解公共层复用率指标；知道分层是为了口径统一，而不是为了分层本身

### 维度建模与事实表设计
- 阶梯：事实表与维度表的区别，粒度怎么定 → 事务事实表、周期快照、累积快照各自适用场景 → 订单状态频繁变更导致事实表重复、指标口径不一致怎么排查 → 缓慢变化维（SCD2 / 拉链表）的存储与查询代价，什么时候干脆存快照
- 好题：电商订单从下单到签收有 6 个状态，业务既要看每日各状态数量又要看每笔订单的完整流转时长，你怎么设计事实表？拉链表在这里合适吗？
- 危险信号：粒度说不清；把所有字段堆进一张表；不知道拉链表回溯查询怎么写
- 期望信号：先定粒度再定字段；累积快照处理多阶段流程；理解退化维度与代理键；知道 SCD2 对下游 join 的影响

### 离线链路与 SQL 优化
- 阶梯：一条 Hive/Spark SQL 的执行流程 → 分区、分桶、小文件对性能的影响 → 任务从 30 分钟涨到 3 小时怎么定位（数据倾斜、笛卡尔积、分区裁剪失效）→ 加资源、改 SQL、改模型三种手段的优先级
- 好题：一个每天凌晨跑的 DWS 任务最近经常超时影响下游 SLA，你按什么顺序排查？如果是数据倾斜，你会用哪些手段、各有什么副作用？
- 危险信号：直接说"加 executor"；不看执行计划；不知道倾斜表现为什么是少数 task 跑很久
- 期望信号：先看执行计划与 stage 耗时分布；分区裁剪、谓词下推是否生效；倾斜 key 的定位与拆分；小文件合并策略

### 实时链路与流处理
- 阶梯：实时和离线各自解决什么，Lambda 与 Kappa 差异 → Flink 的 checkpoint、状态、watermark 分别做什么 → 实时指标与离线对不上、迟到数据、乱序、状态膨胀怎么处理 → 端到端 exactly-once 的代价，什么场景 at-least-once + 幂等就够
- 好题：实时大屏 GMV 与 T+1 离线报表差了 2%，业务问哪个对，你怎么定位差异来源？最终你会怎么向业务解释两套数的关系？
- 危险信号：认为实时数据一定准；不知道 watermark 与迟到数据的关系；exactly-once 只会说"Flink 支持"
- 期望信号：能列出差异来源（迟到、去重口径、维表更新时机、时区）；理解状态 TTL；知道下游 sink 的幂等或事务写入才是端到端一致的关键

### 调度与任务治理
- 阶梯：为什么需要调度系统而不是 crontab → DAG 依赖、重跑、补数、幂等分别怎么保证 → 上游延迟引发下游连锁失败、任务重跑导致重复写入怎么处理 → SLA 分级与基线告警的设计，资源队列的优先级怎么定
- 好题：凌晨核心表上游延迟 2 小时，下游 200 个任务排队，你怎么设计调度策略让最重要的报表按时出？事后怎么避免同类问题？
- 危险信号：不知道任务是否幂等；补数靠手工改日期跑；没有基线或 SLA 概念
- 期望信号：任务写入按分区覆盖保证幂等；核心链路基线告警；依赖检查用分区就绪而不是固定时间

### 数据质量与可观测
- 阶梯：数据质量看哪几个维度（完整性、准确性、一致性、及时性、唯一性）→ 规则校验放在链路哪个位置，阻断还是告警 → 指标突然掉 30% 是数据问题还是业务问题怎么快速判断 → 全量校验的成本与抽样、分层校验的取舍
- 好题：某天 DAU 报表比前一日掉 30%，业务半小时后要答复，你在这半小时里查什么？怎么区分是埋点丢失、任务跑错还是真实下跌？
- 危险信号：只有"跑完了"没有"跑对了"的检查；出问题从上游一张张表人肉看
- 期望信号：从源头波动率、分区记录数、主键唯一性逐层排查；有血缘辅助定位；核心表配置阻断规则

### 存储格式与湖仓
- 阶梯：Parquet/ORC 为什么适合分析 → 列式存储、压缩、谓词下推的原理 → 湖仓表（Iceberg/Hudi/Paimon）解决 Hive 表哪些痛点（ACID、schema 演进、小文件、时间旅行）→ 从 Hive 迁到湖仓的收益、成本与风险
- 好题：团队想把实时写入的 Hive 表迁到 Iceberg 或 Paimon，你会怎么评估收益？迁移中最怕什么问题？
- 危险信号：说不出行存和列存的区别；把湖仓当成"新名词"而不知道它解决的具体痛点
- 期望信号：理解快照、元数据文件与小文件治理的关系；schema 演进对下游影响；流式 upsert 场景的适配性

### 指标口径与数据资产管理
- 阶梯：同一个"活跃用户"为什么各部门数字不一样 → 指标定义（原子指标、派生指标、修饰词）与统一口径 → 口径变更后历史数据要不要回溯、怎么通知下游 → 指标平台 vs 靠文档约定的投入产出
- 好题：产品、运营、财务对"订单数"各有一套口径，你怎么推动统一？统一后历史报表怎么处理？
- 危险信号：认为口径是业务的事与数仓无关；口径改了没有变更记录
- 期望信号：区分原子指标与派生指标；口径变更有版本与生效时间；血缘能找到所有受影响的下游

### 成本与性能优化
- 阶梯：数据平台成本花在哪（存储、计算、调度空转）→ 冷热分层、生命周期、压缩、任务合并各省什么 → 集群账单月涨 40% 怎么归因到具体任务和负责人 → 降本与 SLA、开发效率的冲突怎么协调
- 好题：给你一个月的任务运行日志和存储清单，你怎么在两周内把成本降 20%？先动什么、怎么保证不影响业务？
- 危险信号：只想到删表；不知道自己任务的资源消耗
- 期望信号：按任务/表归因成本；识别无人访问的表与重复计算；生命周期策略；把降本量化并跟踪

### 数据采集与埋点
- 阶梯：日志、binlog（CDC）、接口拉取各适用什么 → CDC 的顺序、删除、schema 变更怎么处理 → 埋点丢数、重复上报怎么发现和补 → 采集侧治理（埋点规范、上线校验）投入与下游清洗成本的关系
- 好题：一个新版本 App 上线后某事件量翻倍，你怎么判断是埋点重复还是真实增长？采集侧要加什么机制避免下次再猜？
- 危险信号：认为数据来了就是对的；不知道 binlog 里 update 会怎么表现
- 期望信号：埋点校验与灰度对比；CDC 处理 delete 与主键变更；采集侧带版本号

### SQL 现场题与执行原理
- 阶梯：去重、topN、连续登录、留存这类题怎么写 → 窗口函数、多表 join 的行数放大、null 参与比较与聚合的语义 → 同一段 SQL 在 Hive 与 Spark 结果不一致、count(distinct) 跑不动怎么处理 → 一条复杂 SQL 拆成多步中间表的可维护性与性能权衡
- 好题：写 SQL 求每个用户最近连续登录天数，并说明 join 日期维表和用窗口函数两种写法在数据量很大时各自的性能问题；如果登录表有重复记录，结果会怎样错？
- 危险信号：只会 group by 不会窗口；join 后行数翻倍没意识到；count(distinct) 在大表上直接跑不知道会倾斜
- 期望信号：先确认口径再写；用 row_number 与日期差做连续分组；大基数去重用两阶段聚合或近似算法；对结果做总量对账

## 好题 / 坏题对比

- 坏：数仓为什么要分层？分几层？
- 好：你负责的 DWS 层有一张核心宽表被 50 个下游引用，现在要加一个字段并改一个字段口径，你怎么做才能不影响下游、不重跑全部历史？

- 坏：说说 Flink 的 exactly-once 原理。
- 好：实时大屏的 GMV 与离线 T+1 报表差 2%，你怎么定位差异来源？哪些差异是可以接受的、哪些必须修？

- 坏：数据倾斜怎么解决？
- 好：一个 join 任务 200 个 task 里 3 个跑了两小时其他都秒完，你先看什么确认是倾斜、怎么找到倾斜 key、拆 key 加盐会带来什么副作用？

## 项目结合钩子

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

## 出题原则

- 所有题目都要挂在"数据准确性"或"链路事故"上：不问"什么是拉链表"，问"这个场景用不用拉链表、不用的话怎么回溯"。
- 必须结合候选人的数据规模：日增 GB 级与 PB 级的最优方案完全不同，先问清规模再评判方案对错。
- 不要考组件版本与参数名，考执行原理与排查顺序；候选人说"调参数"要追它改变了执行的哪一步。
- 建模题要给出具体业务场景（订单、日志、用户）与冲突需求，让候选人现场定粒度、说取舍。