企业官网建设流程全解析

简介：面向数据仓库工程师面试准备的知识梳理文档，适合求职者、初中级数仓开发及转岗人员用于系统复习与查漏补缺。压缩包内共1个docx文件，约31KB，以文字笔记形式集中整理高频概念与面试问答要点。内容围绕数据仓库定义、主题性/集成性/稳定性/时变性四大特点展开，并延伸到ETL抽取转换加载、ETL日志分类与告警发送、STG/ODS/DW/Presentation四层模型及各层作用、开发步骤、数据清洗与规范化、维度表和事实表提交等模块，便于读者按知识链路串联复习。已有1712人学习下载，可作为面试前快速过知识点、梳理答题框架和补充数仓分层实践认知的参考资料。

1. 数据仓库到底是什么：从“多个账本对不上”说起

月底开会，销售说订单涨了，财务说回款没涨，运营说活跃用户少了。三个系统各有一套账本，谁也不服谁。数据仓库就是把这些账本按同一套口径收拢到一个地方，专门回答“到底发生了什么、为什么发生”。数据仓库知识听起来像一堆术语，其实核心就三件事：把数据搬进来、把口径统一、把历史留下来。搞懂它，你再看 ETL、分层、维度建模，就不会把它们当成孤立的背诵点，而会知道每一步在替谁解决麻烦。

2. 为什么需要数据仓库：业务库到分析库之间隔着一道口径墙

2.1 业务库擅长记账，不擅长回答“为什么”

业务系统像便利店里的收银台，最重要的事情是快、准、别把当前这笔交易弄丢。用户下一单，订单表立刻写一行；库存减一件，库存表立刻改数；支付成功，支付状态马上更新。这类系统每天处理大量“正在发生”的动作，它关心的是流程能不能走通，而不是三年后的人怎么从这些记录里看出趋势。

问题在于，分析问题往往不是“这一单怎么样”，而是“过去半年哪个区域退货率高”“哪类客户复购快”“促销活动到底有没有拉动毛利”。业务库当然也能查，但它有两个天然短板：一是数据分散，订单、支付、库存、客服工单常常在不同系统里，字段命名和取值规则还不一样；二是业务库背着线上交易压力，不适合跑长时间、大范围的聚合查询。硬跑一次，轻则慢，重则影响正常业务，这就是很多团队踩过的坑。

数据仓库站在另一个位置。它不负责收银，也不负责改库存，它负责把多个来源的数据按分析主题重新组织。举个例子，同一个客户在订单系统叫“客户编号”，在客服系统叫“会员ID”，在支付系统又可能叫“钱包账号”。数据仓库要把这些不同叫法映射到同一个主体上，再保留历史变化，让分析人员能沿着时间线看明白。这个动作不是简单复制表，而是建立一套可解释、可追溯的数据口径。

所以数据仓库的第一个价值不是“存得多”，而是“说得清”。它把散落在各处的数据变成一套共同语言。业务方问“上个月新增客户有多少”，分析人员不用再挨个系统对数，而是从已经统一过口径的数据层里取数。也正因为如此，数据仓库工程师面试题里经常追问“为什么要分层”“为什么要做 ETL”，本质是在确认你是否理解：分析型数据和交易型数据，服务的目标不一样。

2.2 四个特点把数据仓库和普通数据库拉开距离

数据仓库有四个常被提到的特点：主题性、集成性、稳定性、时变性。光背四个词不难，难的是知道它们在真实工作里意味着什么。可以用一个生活化类比：普通业务库像小区门口的小超市，每个货架按供应商摆放；数据仓库像连锁超市的中央仓，按“早餐区、清洁区、母婴区”重新组织，方便不同门店按需求取货。

主题性是最容易被低估的一点。业务库按业务流程建表，订单表、支付表、物流表各管一段；数据仓库按分析问题建主题，比如“客户主题”可能同时吸拉订单、支付、客服、会员等级等信息。这样做的好处是，分析人员不需要每次从十几个系统里拼图，而是直接面对一个已经围绕主题整理过的数据集合。主题不等于部门，也不等于某张表，它更像一个分析视角。

集成性说的是“把不同来源的数据合成一套可信口径”。同一个性别字段，有的系统用 0 和 1，有的用 man 和 woman，有的干脆空着。数据仓库要通过映射规则统一成 m 和 f，或者统一成“男/女/未知”。同一个供应商，在结算系统一个编码，在客户系统另一个编码，也要在仓库里对齐。这个过程就是 ETL 里的抽取、清洗、转换。没有集成，数据仓库只是另一个更大的杂物间。

稳定性常被误解成“数据不能改”。更准确的说法是：数据仓库保存的是一系列历史快照，面向分析查询，不承担线上交易那种频繁更新。分析人员查到的是某个时间点已经沉淀下来的状态，而不是正在被业务系统反复修改的当前值。这样复盘才有意义。时变性则说明仓库不是一次性快照，它会定期接收新数据，反映最新变化。历史快照和定期更新同时存在，所以这两个特点并不打架。

2.3 ETL 是数据仓库的后台流水线

ETL 是 Extract、Transform、Load 的缩写，拆开看很朴素：抽取、转换、加载。它在数据仓库里扮演的是后台流水线：从源系统把数据取出来，清洗掉明显不合规的内容，把不同口径转换成统一格式，再加载到目标层。很多人把 ETL 理解成“写几条 SQL 搬数据”，这只看到了最表面的一层。真正麻烦的是规则、顺序、异常处理和可追溯性。

抽取阶段要先搞清楚数据从哪里来。源系统是关系型数据库、文本文件、表格文件，还是接口推送？数据量多大？有没有手工数据？有没有非结构化内容？这些问题不搞清楚，后面很容易翻车。对于同类型数据库，通常可以建立连接后直接读取；对于不同类型的数据库，可能需要通用连接方式，或者先把源数据导出成文本、表格文件再导入；文件类数据源还要约定由谁整理、放到哪里、什么时候到位。抽取不是“能连上就行”，而是要设计稳定、可重跑的路径。

转换阶段承担了最重的业务理解。不同系统的编码要统一，数据粒度要转换，业务指标要计算。比如结算系统里的供应商编码和客户系统里的编码不一致，就要在转换时映射成统一编码；业务系统存的是每一笔明细，仓库里可能要按天、按区域聚合；毛利率、复购率这类指标不一定是简单加减，需要按业务规则算好再存入。清洗则负责处理不完整数据、错误数据和重复数据。缺失供应商名称、分公司信息不全、主表和明细表匹配不上，都属于不完整数据；数值里混入全角字符、前后有不可见字符，属于错误数据；同一对象被多个源系统重复维护，则要做去重和保留规则。

加载阶段要把处理后的数据放进目标层，并保证可追踪。ETL 日志一般分三类：执行过程日志记录每一步的起止时间、影响行数，像流水账；错误日志记录出错时间、出错模块和错误信息；总体日志只记录开始时间、结束时间和是否成功。出错时还要向系统管理员发送警告，常见方式是邮件附带错误信息，方便排查。这里的关键不是日志多漂亮，而是出问题时能不能快速定位、能不能安全重跑。没有日志的 ETL 就像没有黑匣子的车，平时看不出差别，一旦出事就只能靠猜。

3. 数据仓库怎么分层：STG、ODS、DW、DM 各管哪一段路

3.1 四层模型不是套娃：每层解决一个具体麻烦

很多初学者第一次看到 STG、ODS、DW、DM，会觉得这是不是把同一份数据抄了四遍。表面上确实像层层搬运，但每一层都在解决不同麻烦。可以把数据链路想成一条物流线路：STG 是收货暂存区，ODS 是历史底账库，DW 是加工车间，DM 是面向门店的成品陈列区。每层都有明确职责，混在一起就会把开发、维护和排错成本推高。

传统数据仓库常见四层模型，作用不是摆样子，而是划分 ETL 阶段的工作重心。STG 层贴近源系统，主要负责抽取和缓冲；ODS 层保存源系统的全量历史，做逻辑删除标识和增量时间戳；DW 层做清洗、规范化和一致化维度、事实；DM 层根据业务需求做聚合或宽表，直接服务报表和分析。层与层之间不是越复杂越好，而是让变化被隔离。源系统改字段，先在 STG 和 ODS 处理；业务口径变化，尽量在 DW 和 DM 消化。这样一处变化不会把整条链路推倒重来。

这张表只能帮助建立轮廓，真正要理解的是“为什么这样分”。比如 STG 层一般不做数据转换，因为它的任务是先把源数据稳定接进来，减少对源系统的压力，同时保留一份可重跑的数据。ODS 层要保留源系统的全量数据，还要标识逻辑删除和增量时间戳，因为很多源系统会做物理删除，如果仓库不额外记录，历史就断了。DW 层才适合做清洗和规范化，因为这时已经有多源数据可以对比。DM 层再按业务需求聚合，避免让报表直接跑在明细层上。

3.2 STG 与 ODS：缓冲区和历史底账

STG 层常被叫作 staging，意思是暂存、缓冲。它根据 CDC 策略把各个源系统的数据抽取到仓库中，主要面向批处理。如果源系统通过日志实时同步，有时可以跳过 STG 直接进入 ODS。STG 的价值有四层：减轻源系统压力，做数据备份并支持重跑，便于数据问题跟踪，做数据质量检查。它不追求漂亮，追求的是“原始、可追溯、能重来”。

开发 STG 时，第一步是确定 CDC 策略，也就是变更数据捕获策略。源系统数据量、更新频率、有没有时间戳、能不能读日志，都会影响选择。第二步是设计 mapping 文档，把源字段和目标字段的对应关系写清楚。第三步是设计物理模型。STG 的物理模型一般包括源系统的所有字段和审计字段，比如源系统名称、源表名称、加载时间、加载方式。可以去掉主键、索引、默认值等约束，减少加载负担。如果源表和目标表数据库类型不同，字段长度最好扩充，目标表数据类型选几种常用类型，长度选几个固定值，避免今天一个长度、明天一个长度。

抽取数据时，STG 面向异构数据源，最好使用支持多种数据源的 ETL 工具。STG 层不做数据转换，这一点很关键。很多团队一开始图方便，在 STG 里做了一堆清洗，结果源系统一出问题，既不知道是抽取错了还是清洗错了。加载数据时，STG 一般保留 7 天或一个月的数据，具体看重跑窗口和存储成本。它不是永久历史库，而是给 ODS 和后续排查留出缓冲。

ODS 层是把 STG 数据做历史存档，保留源系统的所有历史数据。如果是流式同步，可以跳过 STG，直接同步到 ODS。ODS 的作用包括全量存储源系统数据、支持下游系统实时查询服务、做数据质量检查。它和源系统最大的区别，是增加了逻辑删除标记和增量时间戳。很多源系统会做物理删除，即使有逻辑删除标记，也可能在后台人工删数据。ODS 在加载时要进行数据比较，判断是否有物理删除，如果有就打上删除标记，保住全量历史。

这里有一个容易混淆的点：STG 和 ODS 都“像源系统”，但目标不同。STG 像收货暂存区，重点是接得住、能重跑、保留时间短；ODS 像历史底账库，重点是全量、可追溯、能支持下游查询。把 STG 当 ODS 用，重跑窗口一过就没法回溯；把 ODS 当 STG 用，又会让缓冲层背太多历史包袱。分层不是形式主义，而是把“接数据”和“存历史”分开。

3.3 DW 与 DM：清洗建模和面向分析的宽表

DW 层是清洗、规范化、提交一致化维度和事实的工作区，核心任务是建立反规范化的维度模型。它要处理数据清洗、规范化、维度表和事实表提交。数据清洗是发现数据质量问题并纠正数据的过程，常见做法是定义数据质量要求，制定测量类型，提交测量结果表。异常数据处理策略通常有几类：中断处理；把拒绝记录放到错误事件表；只做标记，数据继续处理；纠正数据。哪些必须在 ETL 处理，哪些最好在 ETL 处理，哪些最好在源头处理，哪些必须源头处理，要分清楚。能源头修的，不要全压到仓库里，否则仓库会变成垃圾回收站。

规范化则针对多源系统的命名和取值差异。每个业务系统相对封闭，命名、取值、计算规则都有自己的习惯。规范化要经过标准化、去重、合并、拆分、整合，把不同系统的相同描述对象统一成企业标准版本。比如性别字段，有的系统用 0 和 1，有的用 man 和 woman，通过映射表统一成 m 和 f。删除重复数据时，要根据保留规则只留唯一一条。数据共存时，同一个客户号在两个源系统都有联系方式，要按业务规则选择保留哪个源系统的值。规范化不是把数据变漂亮，而是让后续分析不会因为口径不同得出相反结论。

提交维度表有几个固定动作。先确认粒度，维度表的粒度就是表的业务主键，根据业务主键判断记录唯一性。再选择代理键生成器，ETL 工具和数据库通常都有字段自增长功能。然后选择维度表类型，常见的是缓慢变化维类型 1 和类型 2。增量加载维度数据时，维度表每个字段都要设置默认值，不能为空。首次加载要有一条代理键为 -1 的默认记录，防止事实表查找不到代理键。最后生成代理键管道，一般建一个查找维度，保存业务主键和代理键的映射关系。

提交事实表则要选择事实表类型，用代理键替换主键，增量加载事实数据，提交错误事实表，做事实表合并和归档。事实表合并和归档不是多余动作，它们处理的是延迟事实、错误事实和历史修正。DM 层再根据业务需求把 DW 数据聚合或生成宽表。创建聚合事实表有几种方式：增量加载聚合表；聚合导航，根据用户请求把基础事实表自动生成聚合数据；物化视图，定时刷新聚合表。由于聚合事实表粒度和基础事实表不同，还要创建相同粒度的缩小维度表。DM 层不是简单“再抄一层”，而是把分析常用口径提前算好，减少重复计算。

3.4 日志、告警与重跑：数据链路的黑匣子

数据仓库链路一长，排错就变成日常。ETL 日志和告警不是附属功能，而是数据链路的黑匣子。执行过程日志记录每一步的起止时间、影响行数，像流水账；错误日志记录出错时间、出错模块和错误信息；总体日志记录开始时间、结束时间和是否成功。使用 ETL 工具时，工具会自动产生一些日志，这类日志也可以作为整体日志的一部分。日志的关键不是“有”，而是“能对应到一次运行、一个任务、一张表、一批数据”。

告警则解决“出错后谁来看”的问题。ETL 出错不仅要写错误日志，还要向系统管理员发送警告。常见方式是邮件附带错误信息，方便排查。更成熟的做法会给告警分级：数据量异常、主键重复、空值率突增、任务超时，不同级别对应不同处理方式。没有分级的告警容易变成噪音，最后大家都不看。日志和告警配合重跑机制，才有实际价值。重跑前要确认幂等性：同一批数据跑一次和跑三次，结果应该一致；否则重跑就是新的灾难。

注意：ETL 日志要能回答三个问题——哪次运行、哪一步、影响了多少数据。缺一个，排错时就要靠猜。

4. 维度建模的关键词：事实表、维度表、粒度与缓慢变化维

4.1 事实表和维度表：一个记“发生了什么”，一个记“谁在哪”

事实表和维度表是维度建模的两个基本角色。事实表记录业务过程里发生的事情，通常包含大量行，存放数字或标志位，用来统计收益、数量、支出等。维度表是分析数据的窗口，包含事实记录的特性，有些提供描述信息，有些指定如何汇总事实数据，还包含帮助汇总数据的层次结构。通俗地说，事实表记“发生了什么”，维度表记“谁、在哪、什么时候、什么商品”。

事实表常见类型有粒度事实表、周期快照事实表、聚合快照事实表、非事实事实表。粒度事实表表示特定时间、空间点上的一次瞬间测量，和粒度同层次的事实字段可以直接做 Sum、Count 等聚合。设计时一定要注意，一个事实表只能有一个粒度，不能把不同粒度的事实放在同一张表里。交易粒度事实表伴随交易事件产生，比如销售单，在 ETL 过程中以原子粒度直接迁移。周期快照事实表表现一个时间段或规律性重复，适合跟踪长期过程，比如账户余额、财务报表，常用月粒度，数据必须符合该粒度。聚合快照事实表描述有明确开始和结束的过程，比如合同履行、保单受理、工作流，粒度是一个实体从创建到当前状态的完整历史，随着业务步骤逐步完善。非事实事实表描述事件发生，但没有具体测量值。

维度表类型也不少。缓慢变化维处理会变化但变化不快的维度，比如雇员升职、客户改地址。快速变化维处理变化非常快的维度，比如产品价格、地产价格，甚至搜索关键词。大维是记录数很大的维度，比如客户、产品，可能需要高效率设计、正确索引和特殊处理。迷你维是把常用大维度中的少数字段提出来形成小维度，提高查询效率。退化维通常指那些没有独立维度表、直接放在事实表里的维度字段，比如订单号。普通维基于一个维表，雪花维基于多个维表并通过外键关联，父子维基于两个维表列定义成员隶属关系，常见于组织结构。

这些名词不需要一口气背完，关键是理解它们解决什么问题。事实表围绕“业务过程”组织，维度表围绕“分析视角”组织。事实表里的数字要能被聚合，维度表里的描述要能支持筛选、分组和层级浏览。设计时先问“这一行代表什么业务动作”，再问“分析人员会按哪些角度切”，答案自然就出来了。

4.2 粒度与层次：先定一行代表什么

粒度是数据仓库中保存数据的细化或综合程度。细化程度越高，粒度级越小；细化程度越低，粒度级越大。设计粒度是设计数据仓库的重要前提。很多建模问题不是 SQL 写错，而是一开始没定清楚“一行代表什么”。一行代表一笔订单明细，还是一张订单，还是一天的汇总？不同选择会直接影响事实表结构、聚合方式和查询结果。

层次则是描述明细数据的层次。比如商品有品类、品牌、单品；地区有省、市、区；组织有公司、部门、小组。维度表可以包含层次结构，帮助分析人员逐层汇总。粒度和层次经常一起出现，但不是一个东西。粒度回答“最细记录是什么”，层次回答“这些记录按什么路径汇总”。先定粒度，再定层次，顺序反了就容易把不同粒度的数据混在一张表里。

注意：事实表设计时，一个事实表只能有一个粒度。把订单头和订单明细塞进同一张事实表，后面做聚合时很容易重复计算。

4.3 缓慢变化维与拉链表：历史状态怎么留

缓慢变化维是面试里经常被追问的点。维度内容会变化，比如雇员升职、客户改地址、产品改描述。处理方式常见三种。类型 1 是直接覆盖，用新值代替旧值，简单但丢历史。类型 2 是增加新行，把当前行状态设为 off，设置 endtime 时间戳，同时新增一行状态为 on，begin_time 设为上一条记录 endtime 加一。类型 3 是增加新列，给表加一个新列存储新值，同时保留原来的值。三种方式没有绝对好坏，取决于业务要不要查历史、存储成本能不能接受、查询复杂度高不高。

拉链表是保留历史状态的一种表设计手法，常用于数据量大、部分字段会更新、又需要查看某个时间点或时间段历史快照的场景。比如用户表有十亿条记录、五十个字段，即使压缩后单表存储也很大；每天新增和变化的比例不高，但业务需要看某个订单在历史时间点的状态。全量每天存一份太浪费，只存当前值又查不到历史，拉链表就在两者之间取平衡。

拉链表通常有 start_date 和 end_date 两个字段。实现时，在 ODS 层创建一个变化数据表，存储当天的 insert 和 update 数据；源表和拉链表按主键取交集做封链操作，把旧记录的 end_date 改成当前日期；变化数据插入拉链表，新记录的 start_date 为当前日期，end_date 为 9999-12-31。查询某个时间点的状态时，用业务日期落在 start_date 和 end_date 之间来过滤。

-- 封链：把发生变化的历史记录关链 UPDATE dw_order_his AS h SET end_date = CURRENT_DATE WHERE EXISTS ( SELECT 1 FROM ods_order_update AS u WHERE u.order_id = h.order_id AND h.end_date = '9999-12-31' ); -- 开链：把当天变化数据作为新链插入 INSERT INTO dw_order_his (order_id, order_status, start_date, end_date) SELECT order_id, order_status, CURRENT_DATE, '9999-12-31' FROM ods_order_update;

这段 SQL 里，dw_order_his是拉链表，ods_order_update是当天变化数据，order_id是业务主键，start_date和end_date标记一条状态的生命周期。封链只处理当前仍然有效的旧链，避免重复关链；开链把变化数据作为新状态插入。真实实现还要考虑同一天多次变化、删除、延迟数据、全字段比对等情况，但基本思路就是“旧链关闭、新链打开”。

拉链表也会遇到查询性能问题。存放五年拉链数据，表会很大，查询自然变慢。常见优化思路有两个：在查询引擎中给 start_date 和 end_date 做索引；保留部分历史数据，对外暴露近三个月拉链表，全量数据另外存放。拉链表不是万能后悔药，它适合变化比例不高、需要历史快照的场景，不适合高频全字段变化。

4.4 星型模型与雪花模型：冗余和关联的取舍

星型模型里，事实表被维度表包围，维度表直接连接到事实表，不再继续被新表连接。整个图形像星星，所以叫星型。星型模型是一种非正规化结构，维度直接与事实表相连，数据有一定冗余。因为有冗余，很多统计不需要做外部关联查询，效率通常更高。雪花模型里，事实表被多个维表或一个或多个层次包围，部分维度没有直接连到事实表，而是通过其他维度表连接，图形像雪花。雪花模型减少数据冗余，但查询往往需要关联更多表。

两者区别不在于谁更高级，而在于冗余和关联的取舍。冗余可接受、查询性能优先，星型模型更常见。维度层次复杂、需要减少冗余，雪花模型可以考虑。很多实际仓库会混用：核心总线用星型，个别大维度或静态层次做雪花处理。面试时如果只背“星型像星星、雪花像雪花”，很容易被追问“为什么星型效率高”“雪花什么时候用”。回答要落到数据冗余、关联次数、查询模式和维护成本上。

5. 常见误区与易混区别：别把数据仓库当大号数据库

5.1 数据仓库和数据库：不是容量大小之分

易混点：很多人把数据仓库理解成“更大的数据库”，觉得只是数据量从几百 GB 变成几 TB。为什么混：两者都存表、都能写 SQL、都有 Schema，表面看起来很像。怎么区分：业务数据库服务交易流程，强调增删改查、事务和响应速度；数据仓库服务分析决策，强调历史留存、统一口径、批量查询和聚合。数据仓库的数据来自多个业务系统，经过 ETL 集成；业务库的数据主要服务当前业务动作。用容量区分会跑偏，用“服务谁、回答什么问题”区分才准确。

5.2 数据湖和数据仓库：存原始数据不等于有分析体系

易混点：数据湖听起来能存一切，数据仓库听起来也能存很多，于是有人觉得两者只是叫法不同。为什么混：它们都涉及多源数据汇聚，都强调集中存储。怎么区分：数据湖更偏向保存原始或半原始数据，保留很大的灵活性；数据仓库更强调经过清洗、建模、统一口径后的分析数据。数据湖不是把文件一丢就完事，数据仓库也不是必须拒绝原始数据。关键看有没有治理、建模和口径管理。没有治理的湖容易变成数据沼泽，没有分层的仓库容易变成大号副本库。

5.3 ETL 和 ELT：顺序变了，责任边界也变了

易混点：ETL 是抽取、转换、加载，ELT 是抽取、加载、转换，看起来只是字母顺序不同。为什么混：两者都要搬数据，也都会做清洗和转换。怎么区分：ETL 通常在加载到目标之前完成较多转换，适合目标端计算资源有限或口径需要提前固定的场景；ELT 先把数据加载到目标端，再利用目标端能力做转换，适合目标端计算能力较强、需要保留更多原始数据的场景。顺序变化会影响数据落地形态、重跑方式和治理边界，不只是换一个缩写。

5.4 拉链表和缓慢变化维：一个是表设计手法，一个是维度变化策略

易混点：拉链表和缓慢变化维都跟“历史变化”有关，面试里经常被混着问。为什么混：两者都涉及 start_date、end_date、状态变化、历史快照。怎么区分：缓慢变化维是处理维度变化的一种策略，类型 1、2、3 讲的是“旧值怎么处理”；拉链表是一种具体表设计手法，用起止日期保留一条记录的生命周期。缓慢变化维可以用拉链方式实现，但拉链表不只用于维度表，也可以用于订单等业务实体。一个偏策略，一个偏实现。

5.5 事实表粒度混用：最容易被面试追问的坑

易混点：一张事实表里同时放订单头金额和订单明细金额，觉得反正都是订单数据。为什么混：订单头和订单明细都围绕订单，字段看起来相关，业务人员也常一起看。怎么区分：订单头一行代表一张订单，订单明细一行代表一个商品行，两者粒度不同。混在一张事实表里，做金额汇总时会把订单头金额按明细行重复计算。正确做法是拆成不同事实表，或者明确一张表只保留一个粒度。粒度是事实表设计的底线，不是可选项。

6. 什么时候用数据仓库、什么时候别用：三个判断和一个虚构例子

6.1 适合上的信号

出现这些信号，数据仓库值得认真做：多个业务系统都要参与分析，口径经常对不上；分析查询开始影响线上业务；历史状态必须保留，业务要看某个时间点的快照；报表和分析需求重复出现，每次都从源系统临时拼 SQL。此时分层、ETL、维度建模能带来长期收益，数据仓库知识也不再是面试背诵，而是解决口径混乱的工具。

6.2 不适合硬上的信号

如果数据量很小、只有一个源系统、分析需求简单且变化不大，先做好源系统查询和轻量报表可能更划算。团队没有稳定的数据负责人，口径规则没人维护，硬上四层模型只会增加搬运成本。实时性要求极高、但业务只需要单条记录查询的场景，也未必需要完整仓库。数据仓库不是万能钥匙，它解决的是多源、历史、口径和分析负载问题。

6.3 一个虚构的订单分析小例子

模拟项目X里，订单、支付、客服三套系统各有一套客户编号。最初报表直接连业务库，订单金额按明细汇总，支付金额按订单头汇总，结果同一张订单被重复计算，月底对账翻车。后来把数据先接进 STG 做缓冲，ODS 保留全量历史并标识删除，DW 统一客户和订单粒度，DM 生成按天、按区域的聚合宽表。报表不再直接碰业务库，口径也写进了 mapping 文档。

我在一次模拟项目X里吃过粒度混用的亏：为了省事，把订单头和明细放进同一张事实表，测试时数据量小没发现，上线后区域汇总直接翻倍。从那以后，我每次设计事实表都先写一句“这一行代表什么”，再让同事按这句话反推聚合逻辑。希望帮到你。如果你正在准备数据仓库岗位，这份《数据仓库工程师面试题》资料可以把分层、ETL、维度建模和常见追问串成一条线，适合拿来对照梳理自己的知识缺口。

本文还有配套的精品资源，点击获取