简介面向数据仓库工程师面试准备的知识梳理文档适合求职者、初中级数仓开发及转岗人员用于系统复习与查漏补缺。压缩包内共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面向分析的聚合和宽表聚合事实表、缩小维度表、宽表提升报表和分析查询效率这张表只能帮助建立轮廓真正要理解的是“为什么这样分”。比如 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 时间戳同时新增一行状态为 onbegin_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、维度建模和常见追问串成一条线适合拿来对照梳理自己的知识缺口。本文还有配套的精品资源点击获取
