数据工程与大数据架构 - 架构师面试题库

Phaedrus

2026-06-17

API设计, 数据库, 消息队列

数据是现代系统的核心资产。架构师需要理解从数据采集、存储、处理到分析的完整链路。本模块覆盖数据仓库架构、实时计算、数据湖、数据治理等核心主题。

难度标记

🔵 高级（Senior）：8-10年经验应该能答好
🔴 专家（Expert）：需要深入的实战经验和思考
⚫ 大师（Master）：开放性设计题，考察架构哲学和权衡能力

一、数据架构范式（1-8题）

1. 🔵 Lambda架构和Kappa架构的区别？

答：Lambda有批处理层+速度层两套代码，准确但维护复杂。Kappa只有流处理一套逻辑，通过Kafka重放实现历史重算，简单但对存储要求高。新项目推荐Kappa + Flink流批一体。

2. 🔴 数据湖、数据仓库、Lakehouse的区别？

答：数据仓库（结构化、贵、快），数据湖（任意格式、便宜、慢），Lakehouse = 数据湖低成本 + 仓库高性能 + ACID事务。代表：Iceberg/Hudi/Delta Lake。

3. 🔴 Flink和Spark Streaming如何选型？

答：

维度	Flink	Spark Streaming
处理模型	真正的流（事件驱动）	微批（Mini-batch）
延迟	毫秒级	秒级
状态管理	内置（RocksDB State）	有限
Exactly-Once	原生支持（Checkpoint）	需要配合
适合场景	实时计算、CEP	批处理为主+简单流

选型：需要毫秒级延迟或复杂事件处理选Flink，已有Spark生态且对延迟要求不高选Spark Structured Streaming。

4. 🔴 Flink的Checkpoint机制原理？如何保证Exactly-Once？

答：基于Chandy-Lamport分布式快照算法。Barrier从Source注入，算子收到所有输入的Barrier后做快照。两阶段提交（2PC Sink）配合Checkpoint实现端到端Exactly-Once。关键参数：checkpoint间隔、超时时间、最小间隔、并行checkpoint数。

5. 🔵 什么是CDC（Change Data Capture）？有哪些实现方式？

答：CDC捕获数据库的增量变更，实现数据实时同步。

实现方式：

基于日志：解析Binlog/WAL（Canal/Debezium），低延迟、不影响源库
基于查询：定时轮询变更（简单但延迟高，有遗漏风险）
基于触发器：数据库触发器记录变更（侵入性强，性能差）

生产推荐：Debezium + Kafka Connect（开源标准方案）或 Canal（阿里开源，MySQL专用）。

二、实时数据处理（6-12题）

6. 🔴 如何设计一个实时数仓？和离线数仓有什么区别？

答：

离线数仓（T+1）：

1	数据源 → ETL（Hive/Spark）→ ODS → DWD → DWS → ADS → BI报表

实时数仓：

数据源 → CDC/日志采集 → Kafka → Flink实时处理 → 
  → 实时明细层（Kafka Topic / Doris）
  → 实时汇总层（Flink窗口聚合 → Redis/Doris）
  → 应用层（实时大屏、实时推荐）

关键差异：

存储：Kafka替代Hive作为中间层
计算：Flink替代Spark做实时聚合
服务：OLAP引擎（Doris/ClickHouse/StarRocks）替代Hive查询
维表关联：Flink Async IO + Redis/HBase维表

7. 🔴 ClickHouse和Doris(StarRocks)如何选型？

答：

维度	ClickHouse	Doris/StarRocks
架构	Share-Nothing，无MPP	MPP架构
Join性能	较弱（大表Join慢）	优秀（分布式Join）
实时写入	适合批量写入	支持实时单条写入
并发查询	低（单查询用满资源）	高（MPP资源隔离好）
运维	复杂（手动分片、无自动均衡）	简单（自动均衡、在线扩缩容）
适合场景	日志分析、宽表查询	多维分析、实时报表、联邦查询

选型建议：日志类/宽表聚合选ClickHouse，多表Join/高并发BI查询选Doris/StarRocks。

8. 🔵 数据倾斜如何处理？Flink/Spark中分别怎么解决？

答：数据倾斜是大数据处理的经典问题——少数Key的数据量远大于其他Key。

通用方案：

加盐打散：给热点Key加随机前缀，分散到多个Task，再二次聚合
预聚合：Map端Combine减少Shuffle数据量
广播小表：大表Join小表时广播小表避免Shuffle
调整并行度：增加并发，但不能根本解决

Flink特有：LocalKeyBy本地预聚合、MiniBatch攒批。Spark特有：AQE自适应倾斜处理。

三、数据治理（13-20题）

9. 🔴 什么是数据质量？如何建设数据质量体系？

答：数据质量六维度：完整性、准确性、一致性、及时性、唯一性、有效性。

治理体系：

规则定义：每个表/字段的质量规则（非空、范围、格式、关联）
自动化检测：数据产出后自动运行质量检查（Great Expectations/Deequ）
阻断机制：核心数据质量不达标时阻止下游任务运行
报告通知：质量报告 + 异常告警
根因分析：质量问题溯源到上游环节

10. 🔴 什么是数据血缘（Data Lineage）？如何实现？

答：数据血缘追踪数据从源头到消费的完整流转路径。

价值：

影响分析：修改一个表会影响哪些下游报表？
根因分析：一个数据异常来源于哪个上游环节？
合规审计：敏感数据流向了哪里？

实现方案：

解析SQL AST：分析SQL的输入输出表关系
执行计划分析：从Spark/Flink的执行计划中提取
Catalog集成：Apache Atlas/DataHub/OpenLineage
埋点上报：任务执行时主动上报血缘信息

11. 🔵 数据仓库的分层模型？ODS/DWD/DWS/ADS各自的职责？

答：

层	名称	职责	示例
ODS	操作数据层	原始数据1:1同步	原始订单表
DWD	明细数据层	清洗、标准化、关联维表	订单明细宽表
DWS	汇总数据层	按主题聚合	每日用户消费汇总
ADS	应用数据层	面向具体应用	报表/接口/推荐
DIM	维度层	维度数据	用户维表、商品维表

设计原则：

越往上层越聚合，查询越快
下层变更不影响上层（通过中间层解耦）
复用：DWS层指标可被多个ADS复用

12. 🔴 如何设计一个高效的ETL/ELT数据管道？

答：

ETL vs ELT：

ETL：抽取→转换→加载（传统模式，转换在中间层）
ELT：抽取→加载→转换（现代模式，先加载到数据湖/仓库，再用SQL转换）

设计原则：

幂等性：任务重复执行结果一致（INSERT OVERWRITE而非INSERT）
增量处理：只处理新增/变更数据（基于时间戳或CDC）
可回溯：保留历史数据，支持重跑
监控告警：数据延迟、任务失败、数据质量告警
依赖管理：DAG调度（Airflow/DolphinScheduler），上游完成才触发下游

工具选型：

调度：Airflow（Python生态）、DolphinScheduler（国产，可视化强）
转换：dbt（SQL优先的ELT工具，配合数据仓库）
同步：DataX（阿里批量同步）、Airbyte（开源EL工具）

四、数据平台设计（13-20题）

13. ⚫ 如何从零设计一个企业级数据平台？

答：

核心能力分层：

应用层：BI报表 / 数据API / ML特征 / 实时大屏
  ↑
服务层：即席查询引擎 / 指标服务 / 标签服务
  ↑
计算层：批计算（Spark）/ 流计算（Flink）/ OLAP（Doris）
  ↑
存储层：数据湖（Iceberg on S3）/ 消息队列（Kafka）
  ↑
采集层：CDC（Debezium）/ 日志（Filebeat）/ 埋点（SDK）
  ↑
治理层（横切）：元数据 / 数据血缘 / 数据质量 / 权限

关键设计决策：

存储与计算分离：存储用对象存储（S3/OSS），计算按需弹性伸缩
统一元数据：所有表、字段、血缘信息在一个Catalog中管理
自助化：业务分析师能自助查询和建报表，不依赖数据工程师
成本控制：冷热分层、按需计算、自动清理过期数据

14. 🔴 实时特征工程如何设计？如何支撑在线推荐和风控？

答：

离线特征：T+1批计算，存入特征存储（Hive→特征库）
实时特征：Flink窗口聚合（如最近5分钟的点击次数），写入Redis
在线服务：模型推理时从特征存储拉取组合特征

关键挑战：特征一致性（训练和推理用同一份特征）、存储选型（Redis/HBase）、特征版本管理。

15. 🔵 大数据技术栈选型指南？

答：

需求	推荐方案
批处理	Spark（通用）/ Hive（SQL为主）
流处理	Flink（首选）/ Kafka Streams（轻量）
OLAP查询	Doris/StarRocks（多维）/ ClickHouse（日志）
数据湖	Iceberg（通用）/ Hudi（CDC场景）
消息队列	Kafka（吞吐优先）/ Pulsar（多租户）
调度编排	Airflow / DolphinScheduler
元数据管理	DataHub / Apache Atlas
数据质量	Great Expectations / Deequ