1. 这套题我是怎么攒出来的以及数仓面试到底在考什么先说下背景。某段时间我去帮团队做数据仓库工程师的招聘前前后后看了上百份简历也面了不少候选人。面完最大的感受是很多人技术栈很全Hive、Spark、Flink都写得上去简历上项目也做了三四个可一聊到分层思路、维度建模、数据质量这些基础问题反而答得支支吾吾。后来我自己复盘面试记录把高频问题和踩过的“答非所问”整理成了这份题目清单一直保持着不定期更新。这不是什么官方题库就是实打实从面试现场捞出来的东西。这份清单适合三类人准备跳槽的数仓开发、刚转行想做数据方向的新人、还有需要设计面试题的团队主管。对候选人来说它帮你把考点摸清对面试官来说它可以当一份查漏补缺的提问大纲。数据仓库工程师的面试和普通后端开发面试有个很明显的区别后端面试喜欢考源码、考框架原理数仓面试更偏工程落地和业务理解。你光知道某个组件怎么用不够还得说清楚为什么这么设计、数据从哪来到哪去、出问题了怎么排查。我按考察维度把题目分成了几大块基本覆盖了从初级到高级的常见考点后面的章节就按这个逻辑展开。2. 分层架构题ODS到ADS别只会背“四层架构”2.1 ODS层为什么要和源系统做隔离直接同步给下游不行吗这道题我几乎每轮面试都会问。有些候选人上来就背“ODS是贴源层DWD是明细层DWS是汇总层ADS是应用层。”背得挺熟但我一追问就露馅了。我通常的追问方式是“既然ODS只是原样同步那让业务系统的表直接给下游用不就行了中间加一层不是多此一举”这个问题能答到点子上的人确实不多。好的回答会讲到三个原因第一业务系统的表结构是OLTP设计的第三范式拆得很细直接对接下游会让每个需求方都去理解源系统复杂的表关系第二源系统会变字段改名、表结构调整、甚至整个系统替换如果不做隔离下游作业会跟着频繁改动第三ODS层是数据回放和排查问题的关键数据出错了要在ODS找原始快照如果下游直接连业务库根本说不清某天的数据到底是什么时候同步过来的。我比较认可的回答还会补一句ODS层最好保留完整的生命周期管理比如按天分区、保留N天、支持数据比对不要一上来就做清洗转换这一层“脏”一点没关系关键是完整和可回溯。2.2 DWD层做明细整合时最容易翻车的几个细节DWD层的核心是把分散在多个系统的数据整合成统一的、干净的明细数据。面试里我常让候选人说说做整合时遇到过哪些坑。比较有经验的候选人会提到这几个点一是字段类型和编码不统一比如A系统用户ID是数字B系统用户ID是字符串关联的时候必须统一口径二是时区问题特别是涉及订单、支付这类跨时区业务存的是UTC还是本地时间必须讲清楚三是同一业务在不同系统里的状态定义不一致比如订单状态交易系统可能叫“已完成”物流系统叫“已签收”到了DWD层必须映射成一套标准枚举。这里有一个实用的建议DWD层不是越细越好而是要按业务过程组织。一个业务过程一张表比如“订单下单”“订单支付”“订单退款”分开建模这样后续做DWS汇总时维度组合更灵活。很多新人喜欢把能拿到的字段全塞进一张大宽表结果导致表极度膨胀产出时间越来越长后面查数也费劲。当然宽表有它的场景但至少你要能说清楚什么场景该用宽表、什么场景该用明细事实表。2.3 DWS和ADS到底差在哪很多人其实没想明白有相当一部分候选人能解释ODS和DWD但问DWS和ADS的区别就含糊了。有一个比较直观的理解方式DWS是面向主题的汇总ADS是面向应用的汇总。DWS沉淀的是公共指标比如“用户订单汇总”“商品销售汇总”它是按照分析主题组织的粒度一般是维度统计周期目的是让多个应用共享同一份汇总数据避免每个报表都自己算一遍。ADS则更贴近前台应用可能是某个运营活动专门做的宽表是指标经过二次加工、针对特定场景输出的结果。面试时我喜欢用一道实际场景题来考这个点假设一个电商平台要做“大促实时看板”需要展示每分钟的GMV、订单量、支付成功率你怎么设计分层这个题目能拉开差距。只答“ODS同步、DWD清洗、DWS汇总、ADS输出”肯定不够。真正会设计的人会补充实时看板不能全走离线链路ODS层要有实时接入的通道比如KafkaDWD层做实时清洗和关联DWS层做窗口聚合ADS层直接对接看板查询。而且为了降低延迟DWS层的聚合结果会写入存储比如ClickHouse或Doris不会直接靠Hive支撑分钟级刷新。2.4 一道分层设计题的参考答题逻辑面试最后我一般会让候选人现场设计一套简单数仓题目是这样的某电商平台有订单系统、用户系统、商品系统老板要看每个类目每天的销售额和订单量你从零开始怎么建仓。完整的答法大致是先规划命名规范库名、表名、字段名都按统一规则来再确定数据来源ODS层把三套系统的核心表全量增量同步过来DWD层按业务过程拆订单事实表关联用户维度和商品维度把冗余字段都补进去DWS层按类目日期做汇总生成销售汇总表最后ADS层直接输出报表要用的结果。说到这里如果候选人还能主动提出用星型模型组织维度表顺便说清楚维度表用拉链表处理用户信息变更那我基本可以确认这人是有实战经验的。3. 维度建模三连问事实表、星型模型、缓慢变化维3.1 事实表类型这道题能看出候选人到底做没做过真实业务维度建模是数仓面试的必考区而事实表类型是这里的第一个高分值考点。事实表分为事务事实表、周期快照事实表、累积快照事实表很多人能说出名字但问“什么时候用哪种”就慌了。事务事实表记录的是每个业务事件比如一笔订单、一次支付、一次退款每行代表一个事件它会不断增长适合做过程分析。周期快照事实表记录的是固定时间点的状态比如每天记录一次库存快照适合做状态分析。累积快照事实表则跟踪一个业务过程的完整生命周期比如订单从下单、支付到发货、完成多个阶段的状态都放在同一行里更新适合做时长分析。实际项目中新人最常见的错误是不管什么需求都用事务事实表硬扛。比如要分析“当前在途订单金额”如果只有事务事实表你得写复杂SQL去关联多张表再算状态性能很差。正确做法是设计一张周期快照事实表每天记录每个订单的最新状态统计时直接查这张表就行。面试时我会引导候选人给出这样的回答如果你能主动提到“用快照表换查询性能、用事务表保过程分析”这道题基本就稳了。3.2 星型和雪花不是选择题而是取舍题星型模型和雪花模型的对比几乎是数仓面试绕不开的题。很多候选人只会说“星型模型有冗余雪花模型规范化程度高”但说不清取舍逻辑。我的理解是这样星型模型把维度表设计成单层把一些层级关系直接冗余进一张表里比如商品维度表里同时放类目ID和类目名称查询快但表会大一点。雪花模型把类目拆成单独一张维度表商品表通过类目ID关联过去节省存储但查询要多一次关联。真实数仓环境里绝大多数场景选星型因为OLAP查询的核心诉求是减少关联、降低查询延迟存储成本早已不是主要矛盾。还有一个面试官爱埋的点提问时会故意说“那既然雪花模型规范化更好为什么不用雪花模型”。这时候你一定要抓住核心——数仓是面向分析的不是面向事务的分析场景下冗余换速度是划算的。而且星型模型对上层BI工具更友好很多BI工具在星型模型下能自动做聚合下钻模型一复杂工具就傻了。3.3 SCD缓慢变化维的四种策略别只会背“拉链表”缓慢变化维一般问的是SCD1、SCD2、SCD3和SCD4。SCD1是直接覆盖不保留历史适用于不需要追溯的属性SCD2是拉链表保留多条记录用开始时间、结束时间、当前标记来管理历史版本SCD3是用额外字段保留上一次的值只能追溯一步用的比较少SCD4是把历史存到单独的历史表里。面试里我一般会出一道具体场景题用户表里有收货地址用户改地址了数仓里的用户维度怎么处理答得好的会说如果只是分析当前地址分布SCD1就够了如果要做“用户在不同地址下的下单行为”分析就必须用SCD2拉链表保留每次地址变更的历史版本。这里值得展开讲一下拉链表的实现细节因为很多候选人知道概念但写不出来。实现拉链表通常要三步先把当天新增和变更的数据取出来加上开始日期把开始日期设为当天再更新历史表里这些用户的旧记录把结束日期设为昨天、当前标记置为失效最后把新记录插入历史表。Hive里的典型写法是把原表和增量表按业务主键做全外连接用条件判断哪些是旧记录、哪些是新记录再union到一起。我建议候选人面试时主动说出这个实现思路会比只背定义强很多。3.4 维度属性冗余和退化维度的辨析还有一类维度建模的题容易被忽视就是维度属性冗余和退化维度。所谓退化维度就是维度属性本来在事实表里就有比如订单号它既是事实表的字段也是一个维度。很多团队习惯把订单号做成一个单独的订单维度表这其实是没必要的直接把订单号冗余在事实表里就行这就是退化维度。面试时遇到过候选人把“退化维度”和“维度退化”说反了。我通常会追问“订单号和用户手机号哪个更适合做退化维度”答案是订单号因为订单号在事实表里天然存在而且它的取值基本只和这张事实表有关不需要额外维护一张维度表。用户手机号虽然也可以冗余但它本身是用户维度的属性如果手机号还有号码归属地等衍生属性最好是放用户维度表里。这类题目看起来偏理论实际上很考察建模功底。能主动区分“可以冗余”和“应该冗余”的人通常对维度建模有过真实的思考和取舍。4. 数据倾斜题不会排查这个Hive和Spark再多工具也白搭4.1 数据倾斜的现象和根因先会判断再谈解决数据倾斜是数仓笔试和面试的高频题基本没有哪次面试能躲过。很多候选人有印象“数据倾斜会产生小文件、跑得慢”但让他具体描述现象就说不上来了。数据倾斜最常见的表现是某个reduce或task长时间不结束其他task早就跑完了整个作业卡在这里。典型场景包括大表关联小表时key分布不均、group by的字段某个值占比极高、count distinct在超大维度上计算时压力集中。判断根因时我习惯先让候选人说说自己之前遇到的实际案例。答得好的会按位置分类Map端倾斜一般是输入文件大小不均匀Reduce端倾斜一般是key分布或计算逻辑导致的。比如用户维表和订单大表关联关联键是用户ID如果某个渠道的用户量特别大比如有一个爬虫用户产生了百万级订单关联时这个用户的处理压力就全压在一个reduce上这就是典型的join倾斜。4.2 解决倾斜的思路加盐、广播、两阶段聚合数据倾斜的解决方案里有几个是必须能脱口而出的。第一是加盐。对倾斜的key加上随机前缀把一个key拆成多个子key分散到不同reduce。加盐要注意“两阶段聚合”第一阶段加盐做局部聚合第二阶段去掉前缀再做一次全局聚合。这套方案适用于group by和聚合场景。第二是map join。大表关联小表时把小表分发到每个map节点让关联直接在map端完成不走reduce。Hive里用mapjoin hintSpark里靠broadcast join自动优化。这个方案要求小表足够小能装进内存。第三是拆分倾斜key单独处理。把数据分成正常数据和倾斜数据两条路正常数据走常规join倾斜数据加随机前缀后和膨胀N倍的小表做join最后合并结果。这个方法适用于倾斜key特别集中的场景比如“某个城市的订单占了一半”。我在面试中会更看重候选人是否能根据场景选方案。如果一上来就说加盐但说不出加盐会改变聚合维度、需要二次聚合那说明大概率是背的套路。另外需要提醒一下加盐方案里随机前缀不能加到需要精确统计的维度上比如按用户ID做精确去重时随便加前缀会污染结果这种场景要用别的办法。4.3 小文件问题为什么跑得慢怎么治理小文件问题和数据倾斜经常一起出现也经常被追问。Hive里一个小文件对应一个或多个block文件越多namenode的压力越大Spark/Hive拉起task的损耗越高整个作业的性能会被大量元数据开销拖垮。面试里我会问候选人“你的数仓里每天有100万个小文件怎么处理”比较完整的回答包括通过distribute by对分区字段做随机分发把数据重分布到更少的文件在Spark里调大spark.sql.shuffle.partitions或使用coalesce在写入阶段控制动态分区数量定期合并历史小文件比如用insert overwrite重写一遍表。这里有个容易忽视的点小文件不只产生在sql shuffle阶段动态分区插入时如果分区特别多也会产生大量小文件。面试时如果能主动提到“动态分区要设置非严格模式并且控制每个分区的文件大小”说明你在写生产SQL时不只是调接口确实考虑过资源问题。4.4 Hive和Spark的执行原理对比题怎么答不空洞Hive和Spark的对比是数仓面试的常客但很多人答得太虚。比较靠谱的答法是Hive把SQL转成MapReduce或Tez任务特点是稳、适合超大批量离线计算但中间结果反复落盘导致延迟较高。Spark基于内存计算RDD或DataFrame的变换在DAG里执行中间结果尽量驻留内存迭代计算速度快很多。面试官最想听到的其实是“你知道Hive on MR和Spark的shuffle机制差异”。Hive的shuffle是Map端写磁盘、Reduce端拉取整个过程有大量IOSpark的shuffle虽然也要落盘但会尽量用内存缓冲并且有sort-based shuffle的优化。答完原理之后如果能补充一个真实场景对比比如在相同集群上跑一个10亿条记录的joinHive可能要几十分钟Spark能在几分钟内完成但Spark对内存设置更敏感、OOM风险更高那这道题就非常完整了。我见过一个比较讨巧的回答“我们公司小文件太多资源又紧张所以用Hive更稳后来换成Spark第一次跑直接OOM调了executor内存和并行度才稳定下来。”这种回答有细节、有对比、有踩坑明显比背概念强。5. 数据质量与治理题数仓值不值钱就看这块你慌不慌5.1 数据质量规则怎么定不能只说“要校验”数据质量是数仓工程师被高频考察但经常答不好的领域。很多候选人知道要“做数据质量监控”但具体监控什么就说不出来了。数据质量的考察点可以拆成四类完整性、准确性、一致性和及时性。完整性看关键字段有没有大量为空准确性通过抽样比对或汇总指标比对来验证一致性看同一指标在不同报表里口径是否统一及时性关注数据产出时间是否满足业务SLA。面试时我喜欢出这么一道场景题发现某天DWS层订单金额汇总比前一天少了20%你怎么排查这不是一道SQL题而是排查思路题。好的回答会从几个方向展开先确认ODS层当天数据是否完整同步比如业务系统是不是漏数据了再看DWD层清洗逻辑有没有问题比如是不是过滤条件误伤了正常数据接着看DWS层汇总逻辑比如是不是新增了某些维度的过滤条件最后比对明细定位是某个分区、某个来源渠道的数据异常。5.2 数据血缘和元数据管理为什么越来越重要数据血缘和元数据管理近两年面试频率明显上升。原因也很直接数仓规模一大表成千上万张口径混乱、找不到数据源头、改了一张表不知道影响哪些下游都是成本。面试时关于血缘的题目一般从两个角度切入一是技术实现二是业务价值。技术实现方面可以回答通过解析SQL的AST语法树来提取表级血缘和字段级血缘或者通过调度系统的作业依赖关系绘制DAG。业务价值方面可以回答影响分析比如要下线一张表通过血缘看有多少下游依赖还有数据溯源报表数据对不上时通过血缘快速定位是哪个环节出了问题。元数据管理则更偏落地。候选人能主动提到把表结构、字段说明、ETL负责人、调度频率、产出SLA这些信息统一收口到一个元数据平台配合数据字典给分析师用就已经很加分了。如果再能补充一句“元数据平台不只是存储信息更要做成开发流程的一部分建表时自动采集元数据”那就说明真的推动过治理项目。5.3 指标口径一致性为什么数仓工程师要背这个锅指标口径问题在面试里也很常见。我经常问“运营说你报表里的GMV是1000万财务说他们那边的GMV是1200万两边吵起来了你作为数仓工程师怎么处理。”不少候选人第一反应是“我们数据没问题是他们口径不同”。这其实是推卸责任的回答。更有建设性的答法是找到口径差异的根因比如报表里GMV是否过滤了退款订单、是否包含未支付订单、是否包含取消订单财务那边是不是用了不同的统计时点然后推动建立指标字典把每个指标的定义、来源表、计算公式、统计维度标准化让所有人在同一个口径下说话。指标口径问题的本质是管理问题但数仓工程师必须承担技术兜底的职责。面试时能主动提到“指标字典”“口径评审”“指标分层管理”——比如原子指标、派生指标、复合指标的思路会让面试官觉得你具备高级工程师的思维。6. 开放场景题当面试官让你“从零设计一套数仓”时6.1 没有标准答案但绝对不能没思路开放场景题在数仓面试里越来越常见尤其是面高级岗位时。这类题没有标准答案考的是你面对不完整需求时能否梳理出清晰的思路。我常用的开放题是“假设公司刚拿到一笔巨额融资业务明年预计翻十倍技术团队要从0搭建数仓你是负责人第一件事做什么”这道题很有意思因为它没有固定答案但很能暴露一个人的工程素养。初级候选人会说“选技术栈用Hive还是Spark、用CDH还是Doris”关注点全在工具上。高级候选人会先问业务场景、团队规模、数据量级、实时性要求、现有IT基础设施然后再给出建议。我比较认可的回答框架是先确定技术路线和选型依据再设计数仓规范包括命名、分层、模型设计规范然后规划调度和运维体系最后考虑团队分工。选型依据是这道题的重点。不能只说“我们用Hive”要说明为什么。数据量不大、并发不高直接用MySQL或PostgreSQL做轻度汇总就够了数据量上来了离线选Hive数仓加Spark优化实时选Flink加Kafka汇总层可以用ClickHouse或Doris支撑查询。选型永远跟着场景走。6.2 烟囱式开发的坑高级面试必考烟囱式开发指的是每个需求方各自从ODS甚至业务源系统直接取数开发一套自己的数据链路和表不做复用。短期看快长期看就是灾难。这个问题的面试形式通常是“业务方说很急三天必须出数据你作为数仓工程师怎么办”很多初级候选人会说“那就加班加点先做”。有经验的人会先说“需求的本质是什么能不能复用已有模型”然后给出方案如果现有DWS层有对应的指标直接出报表如果没有评估是否需要在DWS层新增维度组合但流程必须走公共层开发。这个问题背后考察的是对“数据资产复用”的理解。面试时能主动提到烟囱式开发会导致口径混乱同一个指标不同人算出不同数最终业务方不再信任数据还让运维压力剧增——这比单纯答“要做好规范”深刻得多。6.3 实时数仓和离线数仓怎么讲清楚自己的定位随着实时数仓的普及面试里经常问“你做过实时吗怎么理解实时数仓和离线数仓的关系”。这个问题的坑在于只回答“实时用Flink离线用Hive”太浅了。更完整的表达是离线数仓解决的是T1的高吞吐计算问题数据经过批处理落到分层表里适合大规模、复杂逻辑的分析实时数仓解决的是分钟级甚至秒级的数据新鲜度问题通常用Flink消费Kafka数据做实时清洗和聚合结果落到支持实时查询的存储里。面试官真正想看的是你对“实时数仓的分层”有没有概念。实时数仓同样有ODS、DWD、DWS、ADS的逻辑只是实现完全不同。比如实时ODS就是Kafka中的原始消息流实时DWD通过Flink做流式join和清洗实时DWS是窗口聚合结果ADS层则是供前端直接查询的物化视图或宽表。能把这个链路讲清楚说明你不只是用过Flink的API而是真的理解实时数仓的架构设计。7. 除了技术题这些“软题”我建议你也准备一下7.1 “你遇到过最难的数仓问题是什么”这道题其实在考什么这道题我几乎每次面试最后都会问而且我发现它是区分度很高的一道题。它看似在问技术实际上在考三件事一是你的问题定位能力二是你的排查思路三是你是否具备“复盘”意识。比较失败的答案是“当时就加了几个参数跑通了”或者“问了一下别人就好了”。比较成功的答案会描述一个完整的问题闭环遇到什么现象、怎么定位、假设有哪些、如何排除、最终根因是什么、怎么修复、后续怎么预防。比如某位候选人讲过一个案例某个例行任务每周固定慢一次后来通过监控发现是每周日晚上的全量备份任务和数仓的拉链表任务挤在一起导致资源竞争。“这个问题的价值不在于找到了一个参数而在于下次做资源规划时会主动预留缓冲。”这句话我记得很清楚。这道题也提醒候选人一个事实数仓工程师的大部分日常工作是排查数据问题面试官需要确认你真的做过这些事而不仅仅是会写SQL。7.2 当面试官问“你不了解的技术”时及时沟通比硬撑重要这类问题在数仓面试里也很常见比如面试官突然问一个你没用过的组件或框架比如“你有了解过DataLakehouse吗”“Iceberg和Hudi的区别你知道吗”如果没接触过直接硬答很容易露馅。我比较建议的作答方式是把话题引到自己熟悉的方向同时展示学习能力。比如“Iceberg的具体实现我没在生产环境用过但我理解数据湖的核心诉求是解决数仓无法处理非结构化数据的问题而且我觉得湖仓一体的关键是在元数据层做统一管理。如果让我去落地我会先去对比Iceberg和Hudi在ACID、时间旅行、upsert能力上的差异。”这样既承认了未知又展示了自己的框架感。面试官听到这种回答不会扣分反而会觉得这个人有自知之明而且有学习路径。最怕的是不懂装懂被深挖两轮之后就陷入沉默整个面试氛围都会变僵。7.3 如何介绍自己的项目经历才不像流水账项目经历介绍是面试开场的第一个环节但很多候选人讲得平淡无奇。流水账式的讲法是“我负责订单数仓的开发每天写SQL用Spark跑任务”这种描述没有任何信息量。我建议按照STAR法则来组织但不要死板地背。核心是讲清三件事项目的业务背景是什么、你在其中的角色是什么、你做的关键动作带来了什么结果。比如一位候选人介绍过一个“数仓性能优化”的项目他说“这个项目背景是报表查询时延超过1分钟业务方频繁投诉。我负责排查性能瓶颈最终定位到问题是DWS层表设计不合理维度过宽导致扫描数据量太大。我通过拆分维度、重构汇总粒度和优化查询SQL把查询时延从1分钟降到10秒以内。”这段话信息密度高而且有量化结果明显比流水账强。面试官通常会在候选人介绍项目时挑选一个细节深挖所以在准备项目介绍时一定要确保自己项目里的每个技术点都能讲透比如用了拉链表就要能说出拉链表的维护逻辑用了窗口函数就要能解释为什么选窗口函数而不是group by。8. 一些实用的刷题和复盘建议以及这份题未来的更新方向刷题这件事我的建议是不要死记硬背答案。数仓面试和算法面试不一样算法题有标准答案数仓题更多是开放式的。你可以把每一道题当成一次小型的系统设计来思考先自己想一遍再去看别人的解法最后落到自己的项目里验证。我自己的复盘习惯是每次面试结束后都写面试复盘文档记录哪些问题答得好、哪些问题卡壳了、卡壳的原因是知识盲区还是表达问题。卡壳的地方就是下一轮刷题的重点。比如我有一段时间总在“指标一致性”这类题上回答不好后来花了一周时间专门梳理指标字典的设计逻辑再面试时遇到同类题就从容多了。另外数仓技术栈更新很快早期面试还问CDH、Hive的优化参数这两年已经开始问数据湖、湖仓一体化、实时数仓、指标平台了。所以我这份题目清单会一直保持更新看到有价值的真实问题就加进来看到已经过时的旧题就调整或删除。比如最近有几个面试官朋友已经开始问“数据治理和数据平台如何联动”“AI大模型对数据工程师工作的影响”这类前瞻性题目了这类题目我后续也会单独整理一篇。最后说一点个人体会面试是双向的候选人通过回答问题展示能力面试官也通过问题传递团队的技术风格和业务方向。刷题的目的不完全是为了通过面试而是借这个机会把过去一段时间的工作经验做一次系统化梳理。我自己在整理这份题目时有几个知识点也是重新翻资料才彻底搞清楚的。如果你在准备面试建议把每一道题都当成一次知识的查漏补缺。祝大家都能在面试中遇到靠谱的、能让你有收获的团队。