面试官问'你们数据架构怎么设计的'——怎么讲才能展示全局视野？

// 面试时的架构讲述（约2分钟）
 
// 第1步：一句话概括
"我们的数据平台是一个标准的Lambda架构，
  离线用Databricks+Spark做批处理，实时部分用Kafka+简单的流处理。
  整体数据量20TB，基于Delta Lake做存储。"
 
// 第2步：分层讲解
"数据分为五层：
  - 数据接入层：埋点SDK → Kafka → S3原始区
  - ODS层：原始数据落地，不做任何加工，按天分区
  - DWD层：明细数据清洗，统一字段名、处理NULL、去重
  - DWS层：按主题域聚合，如设备激活日报、用户行为汇总
  - ADS层：直接给BI报表用的应用层数据"
 
// 第3步：关键技术选择
"存储统一用Delta Lake格式，因为需要ACID和MERGE INTO。
  ETL用Spark SQL，因为团队最熟悉。
  调度用Databricks自带的Workflow。
  BI层用Tableau直连DWS/ADS层。"

怎么讲清楚'数据流转'

很多人讲架构只讲静态的分层，不讲动态的数据流转。但面试官最想听的其实是数据怎么从上游一步步变成报表的。

// 以设备激活报表为例讲数据流转
 
// ① 数据接入
"设备激活事件通过SDK埋点上报到Kafka，
  Kafka Consumer把数据写到S3的原始区。"
 
// ② ODS → DWD
"每天凌晨2点，Spark作业把S3原始数据加载到ODS层（按天分区），
  然后做DWD清洗：解析JSON、统一字段名、过滤测试设备、
  对同一设备的重复激活事件去重。"
 
// ③ DWD → DWS
"DWD清洗完成后，触发DWS层的聚合作业：
  按国家、渠道、设备型号三个维度聚合，
  计算日激活数、累计激活数、新增用户数等指标。"
 
// ④ DWS → ADS → 报表
"DWS的数据直接被Tableau连接，
  渠道经理每天早上9点在看板上看到昨天的激活数据。"
 
// 整个链路：事件发生 → T+1凌晨3:30报表就绪

面试官常问的架构追问和怎么应对

讲完架构后，面试官通常会追问一些关键决策和细节。这些追问是区分'用过'和'设计过'的关键。

追问一：ODS层有必要吗？为什么不直接清洗？

这是经典追问。ODS层的核心价值是'原始数据备份'和'可回溯性'。我在某出海硬件品牌就遇到过一次DWD层的清洗逻辑写错了（把某个国家的数据误过滤了），因为有ODS层，我们回溯ODS原始数据重跑了DWD就修复了。如果没有ODS层，原始数据被清洗覆盖了就没法恢复。ODS层的存储成本很低（压缩后的Parquet），但出问题时价值巨大。

追问二：DWD和DWS的边界怎么划分？

这考的是你的建模能力。我的原则是：DWD是'明细级别的干净数据'——每条记录对应一个业务事件，只做清洗不做聚合。DWS是'按主题域的聚合数据'——把明细数据按分析维度聚合好，预计算常用指标。判断标准很简单：如果一个需求可以直接从DWS查到结果就不需要扫DWD。DWS覆盖了80%以上的查询需求，剩下的特殊分析才需要回到DWD层。

追问三：你们数据延迟是多少？怎么保证报表按时出？

这考的是你对整个链路的掌控能力。'我们的核心报表SLA是每天早上9点出数。整个ETL链路的执行窗口是凌晨2点到3:30，一共90分钟。其中ODS加载20分钟，DWD清洗30分钟，DWS聚合25分钟，ADS刷新15分钟。每个环节完成后会触发下一个环节的调度，同时设置了超时告警——如果某个环节超过预期时间的1.5倍就告警。迁移到Databricks后ETL时间减少了40%，给SLA留出了更多余量。'

不同规模的架构怎么讲

不是每个人都在大公司做过复杂架构。面试时要根据你的实际经历选择合适的讲法：

公司规模	典型架构	怎么讲	加分点
小公司/初创	MySQL + Python脚本 + 简单报表	讲清楚为什么这个简单架构就够了，你怎么用最少的资源解决问题	务实、成本意识、不过度设计
中型公司	标准数仓分层 + Spark/Hive + BI工具	讲清楚分层设计和ETL链路，重点讲你在建设过程中做的优化	分层思维、性能优化、数据质量
大公司	Lambda/Kappa + 多引擎 + 平台化	讲清楚你负责的模块在整体架构中的位置，重点讲跨团队协作	全局视野、模块化设计、稳定性保障

关键是：不要虚报架构复杂度。小公司的简单架构讲好了一样加分，面试官看重的是你在当前场景下的思考和决策，不是架构本身有多宏大。

实战踩坑

我在某元宇宙社交应用从0搭建Flink+Doris实时数据平台时，犯过一个架构设计的错误。当时为了'一步到位'，我把所有数据都设计成实时流处理——包括用户注册信息这种低频更新的维度数据。

结果发现，Flink处理这种低频维度数据非常浪费资源。一个用户注册后维度信息几乎不变，但Flink的流任务要一直占用资源等着更新。而且维度表的查询场景本来就是离线报表用的，根本不需要实时。

// 架构设计错误：所有数据都走实时流
 
// ❌ 错误做法：用Flink处理所有数据
// 事实数据（礼物交易、在线状态）→ Flink → Doris（合理）
// 维度数据（用户信息、房间配置）→ Flink → Doris（浪费资源）
 
// ✅ 修正后：按数据特性选择处理方式
// 高频事实数据 → Flink实时处理 → Doris
// 低频维度数据 → 定时批量同步 → Doris
// 效果：Flink任务减少40%，资源节省明显
 
// 教训：不是所有数据都需要实时处理
// 架构设计的核心是'按需分配'，不是'全部上最新最强的技术'

教训：架构设计要'按需分配'，不是所有数据都上实时。面试时讲这个踩坑经历反而加分，因为它展示了你从'过度设计'到'务实设计'的成长过程。

总结

讲架构用自顶向下法：一句话概括 → 分层讲解 → 数据流转。每层都要说用了什么、为什么选、数据怎么变。架构要和业务关联——'因为需要T+1报表所以选离线批处理'比'我们用了Spark'有价值得多。不要虚报架构复杂度，小架构讲好了一样拿高分。面试时能说清楚'为什么这么分层'和'数据怎么流转'，就已经超过80%的候选人了。

下一篇聊一个越来越重要的面试话题：面试官问'你们怎么保证数据质量'——数据治理不是空话，要讲具体方案

你们的数据架构是什么样的？踩过什么架构设计的坑？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长