数据仓库面试高频考点：ETL分层、维度建模与拉链表-平芜编程栈

简介：《数据仓库工程师面试题.docx》面向数据仓库、ETL开发方向的求职者与初中级工程师，围绕面试常见考点组织知识梳理，适合用于面试前系统复盘和查漏补缺。压缩包内共1个docx文件，大小约31KB，内容以文字笔记为主，便于直接阅读和检索。文档从数据仓库的定义与主题性、集成性、稳定性、时变性切入，延伸到ETL抽取、转换、加载流程，ETL日志分类与告警发送，STG、ODS、DW、Presentation四层模型及各自作用，并涉及CDC策略、mapping文档、物理模型设计、数据清洗与规范化、维度表和事实表提交、代理键生成等实务环节。已有1711人学习，可作为梳理数据仓库知识框架、准备面试问答的参考材料。

1. 先答一句「不矛盾」，再准备被追问三层

「数据仓库的稳定性和时变性矛盾吗？」这道题在数据仓库工程师面试题里出现频率极高，很多人张口就是「不矛盾」，然后卡住。它真正考的是你能不能把数据仓库知识拆成四块讲明白：概念与特征、ETL 与分层、维度建模、加载与优化。按常见题量分布，概念题大概占两成、分层与 ETL 占三成、建模占四成、性能优化占一成，建模那块最容易拉开差距，也最容易翻车。适合三类人：应届和转行的，要把概念答到经得起三层追问；在职跳槽的，要把拉链表、缓慢变化维讲到能当场写 SQL；做报表想往数仓走的，要先把四层模型的职责边界说清。往下按「考什么—高频题—怎么答」推。

2. 概念题：四大特征与 ETL 三段，答到能被追问为止

概念题看着送分，实际是筛人题。面试官问「什么是数据仓库」，不是想听你把定义背一遍，而是想确认你脑子里有没有「面向分析」和「面向业务」这两套组织方式的差别。答这类题有个稳妥骨架：先给一句话定义，再说四个特征，最后主动补一句「这四个特征落到工程上就是 ETL」。主动补的那一句，往往就是面试官下一题的入口，你把入口握在自己手里，节奏就不会被打乱。

2.1 主题性、集成性、稳定性、时变性：一个特征配一个追问

主题性的答法不要停在「围绕主题组织」。要对比着说：业务库是按业务流程和应用组织的，订单表、库存表、支付表各自服务自己的系统；数据仓库是按分析主题组织的，客户、产品、销售、渠道，同一个主题下把多个源系统的数据在较高的抽象层次上整合到一处。面试官追问「主题怎么定」，你就答「由分析需求倒推，主题对应的是分析视角，不是某张源表」。这一句能立刻把你和背定义的人区分开。

集成性是四个特征里最容易被追问的。要点是：数据来自多个源系统，命名、编码、取值口径都不一样，必须经过抽取、清洗、转换才能形成统一的数据集合，这套动作就是 ETL。举原文里那个编码例子最有效：同一个供应商，在结算系统里编码是 xx0001，在客户系统里是 yy0001，进仓库前必须统一成一个编码，否则按供应商汇总就是两行。性别字段也一样，有的源系统存 0/1，有的存 man/woman，靠一张映射表统一成 m/f。这种小例子比任何定义都有说服力。

稳定性要答准：仓库里保存的是一系列历史快照，入库后的历史记录不允许被业务随意修改，用户只能通过分析工具查询和分析。这里必须提前准备追问——「那数据错了怎么办」。正确姿势是：不做原地 update 抹掉痕迹，而是按批次重跑或追加一条修正记录，把修正过程留在审计列和批次号里。数据仓库的可追溯性比「当前值好看」更重要，这句话说出来，面试官基本不会再追。

时变性紧跟着稳定性问，标准答法是：仓库会定期接收新的集成数据，反映最新变化；稳定性说的是「已入库的历史不被改写」，时变性说的是「按周期新增快照」，一个约束的是修改，一个描述的是追加，两者作用在不同动作上，所以不矛盾。这个「一个约束修改、一个描述追加」的表述建议原样背下来，它是这道题的标准答案骨架。

提示：四个特征别平铺直叙地背。每讲一个，主动接一句「落到工程上对应什么」，主题性对应一致性维度，集成性对应 ETL，稳定性对应审计列与批次重跑，时变性对应增量加载与分区。面试官听到这层映射，会默认你干过活。

2.2 ETL 三段的边界：抽取、清洗转换、加载各问什么

ETL 是 Extract、Transform、Load 的缩写。抽取是把数据从数据源读出来；转换是把原始数据转成期望的格式和维度，在仓库场景下还包括清洗掉噪音数据；加载是把处理后的数据写入目标，比如数据仓库。这三句是底线，但真正被问的是边界。

抽取这块，面试官爱问「源系统有哪几类，分别怎么抽」。按原文的思路答四类：与仓库同构的数据库，直接建连接写 select 抽；异构数据库，走通用数据接口建链接，建不了链接就导出成文本或表格文件再导入，或者走程序接口；纯文件类数据源，让业务方用工具导入指定库再抽，或直接借助工具；数据量大的系统必须考虑增量，业务系统一般会记录业务发生时间，每次抽取前先取目标表中最大的时间，再回源取大于这个时间的所有记录。

增量这里有个坑要主动交代：很多业务系统没有时间戳，或者只有部分表有时间戳。能拿到时间戳就用时间戳增量，拿不到就要靠全量比对或日志方式，这句话说出来，比背「用时间戳做增量」高一个档次。

转换这块，清洗和转换要分开讲。清洗是过滤不符合要求的数据，交给业务主管部门确认是过滤掉还是修好再抽；不符合要求的数据分三类：不完整的数据，比如供应商名称、分公司名称、客户区域信息缺失，主表和明细表匹配不上；错误的数据，比如数值里混进全角字符、字段前后有不可见字符，这类只能写 SQL 找出来，让业务系统修正后重抽；重复的数据。转换则是另一回事：不一致数据转换，把不同业务系统里同一对象的编码统一；数据粒度转换，业务系统存的是明细，仓库要按分析粒度聚合；商务规则计算，把那些不是简单加减能算出来的指标在 ETL 里算好存进仓库。

一句话把两者切开：清洗解决「这条数据能不能要」，转换解决「这条数据以什么形态进仓库」。这句话建议当成模板记住。

加载这块被问得少但答不好很掉分。要能说出三种基本策略：全量覆盖，适合小表和不带历史的小维度；增量追加，适合流水类事实；拉链加载，适合需要看历史状态的主表。加载顺序也有讲究，后面讲建模时再展开。

2.3 ETL 日志与告警：出错怎么被发现

这道题在真实面试里出现得比想象中多，因为它考的是「你有没有运维过」。ETL 日志分三类：执行过程日志，每执行一步记一条，记录每一步的起止时间、影响行数，是流水账；错误日志，某个模块出错时写，记录出错时间、出错模块、出错信息；总体日志，只记开始时间、结束时间和是否成功。如果用了 ETL 工具，工具自己会产出一部分日志，那部分也可以纳入日志体系。

告警是在日志之上的动作：出错不仅要写错误日志，还要通知到人，常见做法是给系统管理员发邮件，附上出错信息，方便排查。答题时可以再加一句工程习惯：日志表本身要落库，能按批次号、按模块、按日期查，光写文件在排查时等于没有。这句话属于加分项，不违背原意。

2.4 真题演练：五道概念题的标准骨架

第一题：什么是数据仓库，四个特征是什么。骨架是定义加四特征加一句「四特征落到工程就是 ETL」。定义里带出「用于分析性和决策目的」「对多样的数据筛选与整合」「输出用于数据分析、数据挖掘和数据报表」，这三句是原义，说全了显得扎实。

第二题：稳定性和时变性矛盾吗。骨架是「不矛盾，一个约束修改、一个描述追加」，再补一句「历史数据错了不做原地改，走批次重跑或追加修正记录」。这道题答完基本能拿满。

第三题：ETL 各阶段做什么，清洗和转换的区别。骨架是分别定义三段，再用「能不能要 / 以什么形态进」切开清洗和转换，最后补三类脏数据和不一致编码的例子。

第四题：ETL 出错了怎么知道。骨架是三类日志、告警邮件、日志落库可按批次查。别只答「看日志」，那太薄。

第五题：增量抽取怎么做。骨架是「优先时间戳，取目标表最大时间回源取大于该时间的记录；没有时间戳就全量比对或走日志；数据量大必须增量，全量会把源库压垮」。最后半句是面试官最想听的。

3. 分层考点：STG、ODS、DW、DM 四层的职责边界

分层题是数据仓库工程师面试题里性价比最高的一块，答得好能同时覆盖「你懂不懂规范」和「你干没干过活」。四层模型的作用是划分 ETL 各阶段的工作重心，便于管理。这句话一定要说，因为很多人一上来就讲每层存什么，却讲不出为什么要分层。记住一句总纲：分层不是为了好看，是为了把「贴源」「存档」「整合」「服务」四件事的责任分开，出错时能定位到层，重跑时能只重跑一层。

层次	模型口径	抽取方式	是否转换	关键字段	主要作用
STG	与源系统一致	增量或全量	不做转换	审计列	减轻源系统压力、支持重跑、便于问题跟踪
ODS	与源系统一致	全量	不做业务转换	审计列、逻辑删除标记、增量时间戳	全量存档、支撑实时查询、数据质量检查
DW	维度模型	增量	清洗、规范化	审计列、代理键	一致性维度与事实、便于数据问题跟踪
DM	聚合与宽表	增量	聚合	与聚合粒度对齐的维度	面向报表与分析，减少重复计算

3.1 STG 与 ODS 的差别：审计列、逻辑删除、时间戳加在哪层

STG 层的定位是贴源缓冲区。前提是在维度建模阶段已经确定了源系统并做过数据评估，STG 就是按 CDC 策略把各源系统的数据抽过来。它主要面向批处理；如果走日志信息实时同步，可以跳过 STG 直接进 ODS。STG 的四个作用是：减轻源系统压力、数据备份支持重跑、便于数据问题跟踪、做数据质量检查。第三个和第四个经常被合并着说，其实不一样，前者是排查定位，后者是校验拦截。

STG 的开发步骤建议按顺序背：确定 CDC 策略；设计 mapping 文档；设计物理模型；抽取数据；加载数据。物理模型这块有三个细节，答出来很显功底。第一，STG 的物理模型一般包括源系统所有字段加审计字段，审计字段常用四件套：源系统名称、源表名称、加载时间、加载方式。第二，可以去掉了源系统上的约束，主键、索引、默认值都不要带过来，因为 STG 是缓冲区，带约束会拖慢加载、还会在数据质量不合格时直接报错中断。第三，如果源表和目标表数据库类型不同，字段长度要扩充，目标表数据类型选几种常用的，长度选几个固定档位，别一个字段一个长度。抽取环节因为面向异构数据源，最好用支持多数据源的 ETL 工具，STG 层不做数据转换。加载后 STG 一般只保留 7 天到一个月的数据。

ODS 层的定位是全量历史存档。它把 STG 的数据存档下来，保留源系统的所有历史数据；如果是流式的，可以跳过 STG 直接同步到 ODS。三个作用是：全量存储源系统数据、支持下游系统实时查询服务、数据质量检查。开发步骤是：设计 mapping 文档；设计物理模型；抽取数据；加载数据。

物理模型这里就是 STG 和 ODS 最关键的区别：ODS 同样包括源系统所有字段和审计字段，但它比源系统多了两样东西——逻辑删除标记和增量时间戳。原因很实在：很多源系统会做物理删除，或者虽然有逻辑删除标记，后台还是被人手工删了数据。所以 ODS 加载时要拿源数据比对目标表，判断有没有物理删除，有就打上删除标记，保证 ODS 保留的是全量数据。抽取这块，ODS 一般从 STG 抽，同一个数据平台上可以用 ETL 工具也可以手写代码，灵活度高。

一句话对比：STG 是短期的、无约束的、不做转换的缓冲区；ODS 是长期的、带删除标记和时间戳的、全量的存档区。面试里问「STG 和 ODS 有什么区别」，把「保留周期、是否全量、有没有逻辑删除标记、有没有约束」这四点讲出来，就够了。

注意：别把 STG 说成「数据仓库的第一层存储」。STG 是可以被清空重建的临时区，重跑能力才是它存在的理由；说成存储层，等于承认你没分清缓冲和存档。

3.2 DW 层：清洗、规范化、提交维度与事实

DW 层是清洗、规范化、提交一致化维度和事实的工作区，最终建立反规范化的维度模型。三件事：数据清洗、数据规范化、提交维度表和事实表。这块是整场面试的重头，题目密度最高。

数据清洗是发现数据质量问题并纠正数据的过程，通用的方法论是质量环：计划、实施、监控、行动，循环推进。主要步骤是：定义数据质量要求，根据业务需求和数据剖析结果确定优先级；制定数据质量测量类型；提交数据质量测量结果表。异常数据处理有四种策略：中断处理；把拒绝记录放进错误事件表；只做标记、数据继续处理；纠正数据。这四种策略和「在哪处理」有常见的对应关系：必须在 ETL 处理的、最好在 ETL 处理的、最好在源头处理的、必须源头处理的。答题时可以这么收：能拦在源头的问题不要拖到 ETL，ETL 里做的是兜底和标记，不是替业务系统擦屁股。这句话是面试官爱听的态度。

数据规范化是因为仓库的数据来自各个业务系统，每个系统相对封闭，命名和取值都有自己的习惯。规范化的动作是标准化、去重、合并、拆分、整合，把各业务系统的数据统一命名、统一取值，建立企业标准版本数据。三个步骤：

第一，数据标准化。从内容、格式、命名、计算规则上输出唯一版本的数据，把各个源系统里相同描述对象但不同取值统一，比如性别字段用映射表统一成 m 和 f。

第二，删除重复数据。源系统内存在重复，或者多个源系统维护了同一对象的数据，按保留规则删除重复，只留唯一一条。

第三，数据共存。把各业务系统的数据经过拆分、合并、整合。典型例子：相同客户号，两个源系统都维护了这个客户的联系方式，按业务规则决定保留哪个源系统的值。这一步最容易被追问「业务规则谁定」，答「业务方定规则，ETL 落规则，规则要写进 mapping 文档」即可。

提交维度表分五步：确认粒度，维度表的粒度就是表的业务主键，用业务主键判断记录唯一性；选择代理键生成器，ETL 工具和数据库都要设置字段自增长；选择维度表类型，按业务实际情况选，一般采用缓慢变化维类型 1 和类型 2；增量加载维度数据，维度表每个字段都要设默认值不能为空，首次加载要有一条代理键为 -1 的默认记录，防止事实表查不到代理键；生成代理键管道，为了给事实表生成维度代理键，一般建一个查找维度，查找维表存业务主键到代理键的映射。

代理键为 -1 的那条默认记录是高频追问点，标准解释是：事实表加载时如果某个维度值在维度表里找不到，又不能丢这条事实，就落到 -1 上，保证事实不丢失、报表能对账。这句话说完，通常面试官会点头。

提交事实表分六步：选择事实表类型；用代理键替换业务主键；增量加载事实数据；提交错误事实表；事实表合并；事实表归档。维度与事实的修正包括：纠正事实；优化和更正事实表；处理延迟到达的事实；维度重建。延迟事实这块可以补一句：延迟事实在加载时要重新查当时的维度代理键，不能拿当前维度的代理键硬套，否则历史归属就错了。

3.3 DM 层：聚合表三种做法与优化六招

DM 层按业务需求把 DW 层的数据聚合或生成宽表。两件事：创建聚合事实表、创建缩小维度表。

创建聚合表有三种方法：增量加载，建聚合表后按增量往聚合表里灌；聚合导航，用户通过报表分析工具发起请求时，根据请求把基础事实表自动生成聚合数据；物化视图，建物化视图定时刷新聚合结果。三种做法的取舍要说清：增量加载可控、可追溯，是主流；聚合导航对工具依赖强、透明但难排查；物化视图省事，但刷新窗口和存储成本要算。

创建缩小维度表的原因：聚合事实表的粒度和基础事实表不同，所以要建和聚合表同粒度的维度表，这些维度表只是基础维度表的缩小版。这句话经常被追问「为什么不直接关联原维度表」，答案就是粒度不一致会导致聚合结果翻倍。

ETL 优化是这一层的加分题，六招要能脱口而出。第一，减少磁盘 I/O：关联查询时尽可能把无效数据提前过滤掉，只查出需要的列，大数据量尽量不要排序，加载数据时关闭日志。第二，分区和并行：大数据量做分区，查询和任务调度都可以并行。第三，增量加载。第四，增加索引。第五，大而化小，复杂查询拆成多个子任务执行。第六，重用结果集，多个查询任务的共用数据单独建临时表。

这六招里最容易被追问的是「关闭日志」——为什么能关。答：批量加载时逐行写日志会放大 I/O，加载阶段关掉、加载完再统计，是拿可观测性换吞吐，前提是这批数据可重跑。这个解释能体现你知道代价在哪。

4. 建模高频题：缓慢变化维、拉链表、星型与雪花

建模是这场面试的主战场，也是最容易问出深度的地方。四类题必须练到能画能写：缓慢变化维三种类型怎么选、拉链表怎么封链开链、星型与雪花的区别、事实表和维度表的类型与加载顺序。下面逐块拆，涉及 SQL 的地方给出可复现的写法。

4.1 缓慢变化维：三种类型的取舍与答法

缓慢变化维问的是「维度属性变了怎么存」。三种处理方式：

类型 1，直接覆盖。用新值代替旧值，表里只留最新状态。优点是表小、查询简单；缺点是没有历史，回答不了「去年这个客户属于哪个区域」。

类型 2，增加新行。把当前行状态置为失效，打上结束时间；同时新增一行，状态标为有效，开始时间接上。这样每一行代表一段时间内的状态，能回答任意时点的归属。缺点是行数膨胀，需要代理键区分同一业务主键的多条记录。

类型 3，增加新列。给表加一列存新值，同时保留原来的值，只保留「上一个值」和「当前值」两代。适合变化少、只关心前后对比的场景，历史超过两代就无能为力。

答题时说清选择逻辑：要问历史就用类型 2，只要最新就用类型 1，只看前后变化且不想让表变长就用类型 3。再补一句实战口径：多数维度表用类型 1 加类型 2 混搭，描述性属性用类型 1 覆盖，影响归属和统计口径的属性用类型 2 拉链。

注意：原文里类型 2 的写法是新行的开始时间取上一条记录结束时间加 1。实际脚本里也有人直接用同一批次日期，差别在于时间轴会不会留下空档。答题时把规则讲清比背死某个日期更重要，说得出「不留空档、不重叠」这两条约束，就是懂了。

拉链表就是类型 2 在超大表上的落地形态，下一节展开。这里先记住一个判断：维度表能不能用类型 2，取决于变化比例。原文那个例子里，10 亿用户每天新增和变化约 200 万，变化比例很小，这种表才适合拉链。如果一张表每天一半的行都在变，拉链会迅速膨胀，这时候要考虑维表分离。

4.2 拉链表：从建表到封链开链的完整写法

拉链表的使用场景很明确：需要查看历史某一时间点的状态，同时又要考虑存储空间。原文那个例子建议背下来——一张用户表大约 10 亿条记录、50 个字段，即使压缩，单表存储也会超过 100G，再算上多副本更大；表里部分字段会被更新，比如联系方式、产品描述、订单状态；业务需要查某个时间点或时间段的快照；记录变化的比例和频率不大，每天新增和变化 200 万左右，占比很小。四个条件同时成立，拉链表才是对的解。

实现方式分两步建表：目标表 dw_order_his 设 start_date 和 end_date 两个字段；在 ODS 层建一个 ods_order_update 表，只存当天的变化数据，包括新增和更新。加载时，用 ods_order_update 和 dw_order_his 的交集做封链操作，把旧链的 end_date 置为当前日期；再把 ods_order_update 的数据插入 his 表，新记录的 end_date 置为 9999-12-31，start_date 置为当前日期。

-- 步骤 1：封链。只关掉当前仍然有效的链（end_date = 9999-12-31），避免重复关链 UPDATE dw_order_his h SET end_date = DATE_SUB(CURRENT_DATE, 1) -- 关链日取变化日前一天，保证时间轴不断档、不重叠 FROM ods_order_update u -- 部分方言写作 UPDATE ... FROM，其他方言用 JOIN 改写 WHERE h.order_id = u.order_id AND h.end_date = '9999-12-31'; -- 步骤 2：开链。变化后的新状态作为新的当前有效记录插入 INSERT INTO dw_order_his (order_id, cust_name, phone, start_date, end_date) SELECT order_id, cust_name, phone, CURRENT_DATE, '9999-12-31' FROM ods_order_update; -- 步骤 3：首次初始化。全量数据一次性开链，end_date 全部给最大值 INSERT INTO dw_order_his (order_id, cust_name, phone, start_date, end_date) SELECT order_id, cust_name, phone, '2020-01-01', '9999-12-31' FROM ods_order;

这段代码有三个点要能讲出来。第一，封链条件里必须带end_date = '9999-12-31'，它保证只关当前有效的链，任务重跑时不会把已经关掉的链再关一次，这是幂等的关键。第二，顺序必须是先封后开，反过来会出现同一业务主键同时存在两条有效链的中间态，下游按end_date = '9999-12-31'取当前值时就会重复。第三，DATE_SUB(CURRENT_DATE, 1)的取值是口径问题，取变化日前一天表示「旧状态持续到昨天」，取当天则表示「旧状态到今天就结束」，两种口径都能用，但同一张表里必须统一，不然按日期范围查询就会漏行或重行。

如果 ods_order_update 里混着没变化的重复数据，还要先做真增量识别：把源表和目标表按业务主键关联，用全字段比对，比对时排除 start_date 和 end_date，剩下的才是真变化。这一步不做，拉链表会凭空多出一堆内容完全相同的链，查询变慢、存储暴涨，是很典型的踩坑。原文里全量主要数据表的加载策略也是这个思路：按主键把目标表和源表比对，先删掉目标表中在源表里的相关记录，再全量插入，脚本形态就是先 delete 后 insert。

拉链表的性能优化有两个思路：一是在查询引擎里对 start_date 和 end_date 建索引，能提高不少性能；二是保留部分历史数据，比如底层存全量拉链表，对外再暴露一张只提供近 3 个月数据的拉链表，热查询走小表，历史追溯再回大表。

4.3 星型模型与雪花模型：不是二选一，是拿冗余换 join

星型模型是事实被维度包围，维度不再往其他维度上连，整个图形状像星星。它是比较折中的建模方式，商业分析类应用里用得最多。雪花模型是事实表被多个维表或一个或多个层次包围，维度表还要再连维度表，形状像雪花，一般用在处理大的、相对静态的层次上。

区别只有一句话：维度表是直接连到事实表，还是通过其他维度表连过去。星型是反规范化的，维度直接挂事实，存在数据冗余，但很多统计不需要做外部关联查询，效率一般比雪花高；雪花减少了数据冗余，但查询要关联更多表。结论是：在冗余可接受的前提下用星型。

这里有个高频错误：把星型说成「没有冗余所以快」。恰恰相反，星型是靠冗余换掉了 join。这句话答反，面试官会认为你没建过模。

维度分类也常一起问：缓慢变化维、快速变化维、大维和迷你维、退化维。快速变化维的处理按三档说：维度字段不多、表也不大，用类型 2 加行就够；字段多、表大，用类型 2 会让行数爆炸、效率下降，改用类型 3 只留上一值；最糟的是字段多、表大、还有一部分字段频繁变化，这时候把相对稳定的字段和频繁变化的字段拆开，频繁变化的独立成新维度表，与事实表相连或形成新的雪花关系，也就是维表分离。大维要专门优化：填充、非限制维度浏览、多限制属性值浏览、涉及大维的事实查询效率，都要靠高效设计、正确索引和其他优化技术解决。迷你维是把常用大维度里的少数字段提出来单独成小维度，查询时先用迷你维过滤，效率明显提升。退化维是那些留在事实表里、不单独建维的字段，典型是订单号。

4.4 事实表与维度表：四种事实表、加载顺序、粒度与层次

事实表的概念：每个数据仓库都有一个或多个事实表，通常包含大量行，一般只存数字或用于统计的标记，比如收益、数量、支出。事实表分四类。

事务粒度事实表（可加事实表）：表示特定时间、空间点上的一次瞬间测量，与粒度同层次，事实字段可以直接做 sum、count 聚合。设计时一定要注意，一张事实表只能有一个粒度，不能把不同粒度的事实放在同一张表里。来源伴随交易事件产生，比如销售单，ETL 里以原子粒度直接迁移。

周期快照事实表（半可加事实表）：表现的是一段时间或规律性重复，适合跟踪长期过程，比如账户和其他形式的财务报表，最常用的周期是月。表里的数据必须符合同一个粒度，也就是量的都是同一时间段内的活动；好的周期快照表就是在粒度上有更多的事实。ETL 里以固定时间间隔生成累计数据。

聚合快照事实表（不可加事实表）：描述有明确开始和结束的过程，比如合同履行、受理流程、常见工作流；不适合长期连续跟踪，比如账户余额或连续生产过程。它的粒度是一个实体从创建到当前状态的完整历史，ETL 里随着业务步骤逐步完善记录。有些资料把它叫累积快照，答的时候把「有始有终、逐步补全」这个特征说出来即可。

无事实事实表：每个事实表的粒度是一个事件测量，用来描述数据或事件，事件发生了但没有具体测量值，典型的是一张只有维度键、没有度量值的表，用来记「发生过」。

维度表可以看作分析数据的窗口，包含事实表记录的特性：有些是描述性信息，有些指定如何汇总，还包含帮助汇总的层次结构。

加载顺序是必考题，标准答法：子维度表加载成功后，再加载维度表；维度表加载成功后，再加载桥接表；子维度表、维度和桥接表都加载成功后，再加载事实表。这个顺序由主外键关系决定，属于总线架构数据仓库的口径。桥接表用来处理多值维度或层级结构，子维度表对应雪花模型里的支架维度。

粒度与层次经常一起问。粒度是数据单位中保存数据的细化或综合程度：细化程度越高，粒度级越小；细化程度越低，粒度级越大。设计粒度是数据仓库设计的重要前提，这句话必须说，因为粒度定错了，后面所有聚合都对不上。层次是描述明细数据的层次，比如国家、省、市、区。

索引这块补一句：每个维度表都必须在主键上建索引；在其他列上，比如标识层次结构级别的列，索引对某些专用查询也有用；事实表必须在由维度表外键构成的主键上建索引。

5. 易错点：五个当场翻车的答法，逐个拆开

这一章全是血泪经验。下面五条是模拟面试里重复率最高的错法，每条按「错在哪、为什么错、怎么答对」拆开，练的时候对着自己的口述录音比对。

5.1 概念和分层类：三句话答错，后面全白搭

错误一：把稳定性和时变性答成互相矛盾。错在把「稳定」理解成「不更新」，于是觉得既然要定期接新数据，就不可能稳定。根子是没有区分「修改已入库的历史」和「追加新的快照」这两个动作。正确答法是：稳定约束的是修改，历史快照入库后不被业务改写；时变描述的是追加，按周期接收新的集成数据。用「一个约束修改、一个描述追加」收尾，再加一句「历史错了走批次重跑或追加修正记录，不做原地抹除」。

错误二：把清洗和转换混成一件事，或者把转换放到 ODS 做。错在分层职责不清。按常见做法，从业务系统到 ODS 做清洗，把脏数据和不完整数据过滤掉；从 ODS 到 DW 做转换，做业务规则的计算和聚合。为什么这么分：清洗是对数据能不能用的判断，越早拦越好，脏数据不该流进仓库内部；转换依赖业务规则，规则会变，放在 DW 层改起来影响面小。正确答法是先把「清洗解决能不能要、转换解决以什么形态进」这句话甩出来，再补分层落点。

错误三：把 STG 当 ODS 讲，说 STG 保留全量历史、要建主键索引。错在没分清缓冲和存档。STG 是短期缓冲区，一般只保留 7 天到一个月，物理模型要去掉主键、索引、默认值这些约束，字段长度在跨库时要扩充；ODS 才是全量存档，比源系统多出逻辑删除标记和增量时间戳。为什么错：STG 带约束会在脏数据进来时直接报错中断，重跑能力就没了；STG 存全量历史，存储成本和 ODS 重复，分层就失去意义。正确答法是把「保留周期、是否全量、有无逻辑删除标记、有无约束」四点列出来对比。

5.2 建模和 SQL 类：两处写错，代码题直接失分

错误四：拉链表封链不加end_date = '9999-12-31'条件，或者先开链后封链。错在哪：不加条件，任务重跑时会把历史链的结束时间全部改掉，历史全毁；顺序反了，会出现同一业务主键两条有效链的中间态，下游取当前值直接重复。为什么错：本质是把拉链表当成普通表在做 update，忘了它的核心不变量是「同一业务主键在任意时点只有一条有效链」。正确答法：先讲不变量，再讲两条 SQL 的顺序，最后补一句「封链和开链要放在同一批次里，中间态对外不可见」，这一句是加分项。

错误五：事实表混粒度，或者聚合表直接关联原始维度表。错在哪：一张事实表里塞了不同粒度的事实，比如订单粒度和订单明细粒度放一起，做 sum 就会重复计算；聚合事实表直接关联原始维度表，粒度不一致，聚合结果翻倍。为什么错：事实表的设计前提是「一张事实表只能有一个粒度」，这句话是硬约束；聚合表和基础表粒度不同，必须建同粒度的缩小维度表。正确答法：先声明粒度唯一，再说聚合表要配缩小维度表，最后补一句「不同粒度的事实拆表，用视图或 DM 层宽表在查询时拼」。

6. 答题技巧：把一场面试拆成三段节奏

面试答题和写文档不一样，面试官只有几十分钟，他判断你行不行，靠的是结构而不是信息量。我习惯把每道大题拆成三段：先给结论、再给分层或建表、最后主动补代价。结论要一句话，别铺垫；分层或建表要能画，嘴上说得出来结构；代价是主动交代这个方案在什么情况下不适用。第三段是分水岭，能说出代价的人，通常被认为真做过。

以拉链表为例，完整节奏是这样的。第一段结论：「拉链表解决的是大表、低变化率、要查历史时点状态这三个条件同时成立的场景，核心是 start_date 和 end_date 两列维护有效期。」第二段结构：「ODS 建变化表，和拉链表按业务主键取交集封链，再把变化数据开链插入，封链条件必须限定当前有效链保证幂等。」第三段代价：「变化率高的表不适合拉链，会膨胀，要考虑维表分离；历史数据太长要做冷热拆分，对外只暴露近三个月。」

时间分配上，不同题型给的时间不一样，可以按下面这个节奏练：

题型	建议用时	段落结构	常见追问
概念题	2 到 3 分钟	定义、四特征、工程映射	稳定性和时变性
分层题	4 到 5 分钟	四层职责、关键字段、开发步骤	STG 能不能省、删除标记干嘛
建模题	5 到 8 分钟	场景、类型选择、SQL 骨架、代价	代理键 -1、延迟事实、维表分离
优化题	3 到 4 分钟	六招、挑两招讲透	关日志的代价、分区键怎么选

还有两个现场习惯值得养成。第一，答建模题时先在纸上画两行数据，一行旧链、一行新链，把日期标出来。画完再讲，比空口描述清楚十倍，面试官也能顺着你的图追问，节奏就由你带着走。第二，遇到不会的题，别硬编，先说「这块我按 xx 思路理解，不确定的地方是 xx」，然后把能确定的部分讲清楚。面试官对「知道自己边界」的评价，通常高于硬撑。