简介这是一份数据仓库工程师面试题及知识点汇编以 docx 文档形式呈现面向准备数据仓库岗位面试的开发者、数据工程师及需要系统梳理 ETL 与数仓分层知识的从业者。文档从数据仓库的定位和四大特点讲起明确主题性、集成性、稳定性、时变性各代表的含义接着梳理 ETL 全流程包括抽取、转换、加载以及执行过程日志、错误日志、总体日志的分类和出错时的警告发送方式。针对 STG、ODS、DW、Presentation 四层模型内容逐一说明每层与源系统的关系、增量或全量策略、审计列设计并展开 CDC 策略、mapping 文档、物理模型、数据清洗、规范化、维度表提交等实操要点能够帮助读者快速搭建面试答题框架。资源仅 1 个 docx 文件整体约 31KB内容精炼却覆盖核心考点便于随时查阅。目前已有 1709 人学习下载适合作为面试前集中复习和查漏补缺的实用资料。1. 数据仓库到底是什么一间只进不出的“历史档案馆”如果你第一次听到“数据仓库工程师”这个职位脑子里大概率会冒出一个问题数据不都放在数据库里吗为什么还要专门建一个仓库这个疑问很正常因为“数据仓库”这个名字本身就有点误导——它不像一个存放货物的仓库更像一个只进不出的“历史档案馆”。通俗地说数据仓库Data Warehouse缩写是 DW就是一座专门用来“存历史、做分析”的数据集合。它把企业里散落在各个业务系统订单系统、用户系统、物流系统等的数据统一抽取进来清洗干净、整理好然后长期保存下来供业务方做数据分析、数据挖掘和数据报表。业务数据库解决的是“当下这笔交易怎么记”数据仓库解决的是“过去半年我们的生意到底怎么样”。这是两种完全不同的事也是你理解后面所有概念的地基。如果你正在准备数据仓库相关的面试先把这一层想清楚后面才不容易被 ETL、分层模型这些术语绕晕。2. 为什么业务数据库不够用收银台和档案馆的区别2.1 业务系统要“快”数据仓库要“全”你可以把业务系统想象成超市的收银台它每天处理的是“扫码、结账、打印小票”这类高频率操作每一笔都要快、要准不能出错也不允许系统因为要统计历史而变慢。这种面向日常交易的数据库在数据仓库领域有个对应的说法——它服务的是“当下”。但问题是当老板说“把去年所有门店的退货率按季度拉出来看看”时收银台就傻眼了。业务库里数据是有的但分散在几十张表里字段口径还不统一更关键的是很多历史数据可能已经被覆盖或者删除。如果直接在业务库上跑复杂的统计查询轻则慢得离谱重则影响前台交易——这在线上系统里是不可接受的。数据仓库存在的价值就是把这些“算账的活儿”从业务系统里彻底剥离出来。它把散落在各个源系统里的数据汇集到一处按照分析的需要重新组织专门为“读”服务。业务库担心写入性能数据仓库关心查询分析能力业务库只要当前状态数据仓库要保存历史快照。这就是数据仓库存在的第一个理由。2.2 ETL把数据搬进仓库的“搬家流水线”数据仓库里的数据不是凭空出现的。从各个业务系统到数据仓库要经过一条固定的流水线这就是 ETL。ETL 是 Extract-Transform-Load 的缩写对应三步Extract数据抽取从各个数据源把数据读出来。数据源可能是不同类型的数据库也可能是 Excel 文件甚至是一份手工维护的表格。Transform数据转换把原始数据转换成你想要的格式和维度。比如性别字段A 系统存的是 0 和 1B 系统存的是 man 和 woman得统一成 m 和 f再比如把缺了供应商名称的脏数据过滤掉、把重复记录去掉都属于转换环节。Load数据加载把处理好的数据加载到目标位置也就是数据仓库里。打个比方ETL 就像搬家先把旧家里所有东西搬出来Extract然后按照新家的布局分门别类整理好、该扔的扔、该重新打包的打包Transform最后再一件件搬进新家摆好Load。数据仓库里的数据质量好不好很大程度上取决于 ETL 写得好不好这也是数据仓库工程师日常最主要的工作之一。2.3 数据仓库的四个性格主题性、集成性、稳定性、时变性理解了 ETL再看数据仓库的四个核心特点就会顺很多。这四个特点基本是所有面试题里“数据仓库是什么”的标准答案第一主题性。传统业务数据库通常是按项目或功能来组织的比如订单库管订单、库存库管库存。数据仓库不一样它围绕业务主题来组织数据。比如“客户”是一个主题那数据仓库就会把客户的基本信息、订单记录、售后记录、投诉记录全部整合在一起形成一个围绕“客户”的完整视角——这是传统业务库做不到的因为数据散落在各系统里。第二集成性。数据仓库里的数据来自多个数据源来源五花八门必须经过抽取、清洗、转换也就是 ETL才能整合成一套统一的数据集合。这一步解决的是“不同系统对同一个事物的叫法不一致”的问题。比如同一个供应商在结算系统里叫 XX0001在另一个系统里叫 YY0001集成性就是要把这些统一成一个编码。第三稳定性。数据仓库里保存的数据是一系列历史快照一旦入库不允许被修改。用户只能通过分析工具来做查询和分析不能在仓库里改来改去。想想档案馆的规则档案入库之后你只能查阅不能拿笔在上面改字。第四时变性。数据仓库会定期接收新的集成数据反映出最新的数据变化。也就是说仓库里的数据会随时间推移不断追加新内容——比如每天晚上定时同步昨天的订单数据。注意“稳定”和“时变”并不矛盾稳定说的是已入库的历史不能改时变说的是仓库会持续接收新数据一个是管存量一个是管增量这个点面试里经常有人答不清楚。3. 数据仓库里的四层楼STG、ODS、DW、DM3.1 STG 层源系统数据的“临时卸货区”传统数据仓库一般分为四层模型从下往上数第一层叫 STGStaging层你可以把它理解成快递分拣中心的“卸货区”。所有从外面运来的包裹源系统数据先堆在这里不拆包、不分类只是先落地。STG 层有几个典型特征它的表结构和源系统保持一致支持增量抽取或全量抽取不做数据转换只添加审计列。什么叫审计列就是额外加上的一些管理字段比如源系统名称、源表名称、加载时间、加载方式方便之后排查数据问题。因为 STG 层只是临时存放物理模型可以去掉主键、索引、默认值这些约束字段长度也可以统一扩宽避免源系统和目标系统的数据库类型不同导致长度不够。STG 层的作用主要有四个一是减轻源系统的压力——数据先抽到 STG后续处理不再反复读源库二是数据备份支持重跑——万一某次任务失败可以从 STG 恢复三是便于数据问题跟踪——出了问题知道数据是什么时候、从哪个源表进来的四是做数据质量检查。开发 STG 层的步骤大致是先确定 CDC 策略也就是增量变更捕获策略根据源系统的数据变化情况选择合适的方式然后设计 mapping 文档字段映射关系再设计物理模型、抽取数据、加载数据。STG 层一般只保留 7 天或一个月的数据因为它是临时区不需要永久保存。下面是一个简单的 STG 表设计示例-- STG层订单表结构与源系统一致只加审计列 CREATE TABLE stg_order ( order_id VARCHAR(32), -- 源系统订单号 customer_id VARCHAR(32), -- 客户编号 order_amount DECIMAL(10,2), -- 订单金额 order_status VARCHAR(10), -- 订单状态 create_time TIMESTAMP, -- 源系统创建时间 src_system VARCHAR(50), -- 审计列来源系统 src_table VARCHAR(50), -- 审计列来源表名 load_time TIMESTAMP, -- 审计列加载时间 load_type VARCHAR(10) -- 审计列加载方式(增量/全量) );注意看这张表除了订单本身的业务字段还多了四个审计列。后续如果数据出了问题可以直接通过src_system和load_time定位到“是哪套系统、什么时候送进来的”不用对着源库一个个查。这也是 STG 层“便于数据问题跟踪”这句话的实际落地。3.2 ODS 层源系统数据的“全量档案馆”STG 层是临时卸货区ODSOperational Data Store层就是正式的“全量档案馆”了。ODS 层把 STG 层的数据做历史存档保留源系统的所有历史数据。注意是“所有”——只要有变化就追加不删不改。如果数据是流式的也可以跳过 STG 层直接实时同步到 ODS 层。ODS 层的物理模型同样包含源系统的所有字段和审计字段但和 STG 层最关键的区别是多了两个东西逻辑删除标记和增量时间戳。为什么要加这个因为很多源系统会物理删除数据哪怕有逻辑删除标记后台也可能人为清数据。ODS 层加删除标记后就能知道“这条记录在源系统已经被删了”但数据本身还留在档案里不会凭空消失。从 STG 抽取到 ODS 时还要做数据比较判断是否有物理删除的情况如果有就给对应的记录打上删除标记。ODS 层的作用可以总结为三句话全量存储源系统的数据、支持下游系统做实时查询服务、做数据质量检查。开发步骤和 STG 层类似设计 mapping 文档、设计物理模型加逻辑删除标记和增量时间戳、从 STG 层抽取数据、加载数据并做物理删除判断。3.3 DW 层真正“变成数据仓库样子”的地方前面 STG 和 ODS 层的数据都还是“源系统的模样”从 DWData Warehouse层开始数据才开始变成数据仓库自己的样子。DW 层是一个清洗、规范化、提交一致化维度和事实的工作区建立的是反规范化的维度模型。先说数据清洗。数据清洗是发现数据质量问题并纠正的过程主要步骤包括定义数据质量要求、根据业务需求和数据剖析结果确定优先级、制定数据质量测量类型、提交数据质量测量结构表。异常数据的处理策略有四种中断处理把拒绝记录放到错误事件表里只做标记数据继续处理纠正数据。注意这里有个原则能中断处理就中断处理能 ETL 处理就不推到源头但有些问题最好在源头处理有些则必须在源头处理——具体看问题性质。再说规范化。数据仓库的数据来自各个业务系统每个系统相对封闭在命名、取值上都有自己的习惯。规范化就是经过标准化、去重、合并、拆分、整合等过程把各个业务系统的数据统一命名、统一取值建立起企业标准版本的数据。比如“性别”字段有的系统用 0 和 1有的用 man 和 woman通过映射表统一命名为 m 和 f。如果多个源系统都维护了相同对象的数据还需要根据保留规则删除重复数据只保留唯一的一条。DW 层最后是提交维度表和事实表。提交维度表的步骤包括确认粒度维度表的粒度就是表的业务主键根据业务主键判断记录唯一性、选择代理键生成器、选择维度表类型一般采用缓慢变化维类型 1 和类型 2、增量加载维度数据每个字段都要设置默认值首次加载要有一条代理键为 -1 的默认记录防止事实表查找不到代理键、生成代理键管道建一个包含业务主键和代理键映射关系的查找维度表。提交事实表的步骤包括选择事实表类型、用代理键替换主键、增量加载事实数据、提交错误事实表、事实表合并、事实表归档。这部分细节很多面试时能把这个顺序完整讲出来基本就过关了。3.4 DM 层给报表和分析准备好的“半成品”DMData Market层是四层模型里的最上层按业务需求把 DW 层的数据进行聚合或者生成宽表。你可以把它理解成“已经切好、配好料的净菜”——源数据在 DW 层已经清洗规范好了DM 层再做最后一道加工变成业务方能直接用的成品。DM 层主要做两件事。第一创建聚合事实表。方法有三种增量加载创建聚合表后增量加载数据聚合导航用户通过报表分析工具发起请求时根据用户请求把基础事实表自动生成聚合数据物化视图创建物化视图并定时刷新聚合表。第二创建缩小维度表。因为聚合事实表的粒度和基础事实表粒度不同需要创建和聚合表相同粒度的维度表这些维度表只是基础维度表的缩小版字段更少、粒度更粗。3.5 为什么非要分四层让每一层只干一件事很多人刚开始学数据仓库都会有疑问数据抽过来就抽过来了为什么非要搞四层直接一步到位不行吗从 ETL 的角度说分层的核心价值是“每层只干一件事出了问题知道去哪找”。STG 层管抽取负责把数据从源系统安全地搬出来ODS 层管存档负责把全量历史留住DW 层管质量负责清洗、规范化和维度建模DM 层管输出负责按业务需求聚合。每一层都有明确的输入输出和职责边界。这样做的好处是源头系统改了最多影响 STG 和 ODS 的映射不会直接冲击报表业务需求变了只需要改 DM 层不用动底层数据出错了能顺着层一层层定位问题出在哪一步。开发成本虽然高了但维护成本大幅降低——数据仓库是个长期工程后期维护的成本远比前期开发重要。4. 维度建模的核心事实表、维度表、星型和雪花4.1 事实表和维度表一本流水账和一本字典数据仓库的维度建模核心就两张表事实表Fact Table和维度表Dimension Table。事实表是什么你可以把它理解成一本流水账。每一个业务事件比如一笔订单、一次退款、一次登录都在事实表里占一行。事实表通常包含大量的行而且里面存放的主要是数字比如收益、数量、支出以及用来做统计的标记字段。一般事实表里不放描述性信息只放数值和外键。维度表是什么它是用来描述“这笔业务是谁、在什么时候、在哪里、什么东西”的字典。比如订单事实表旁边会有一个客户维表里面存放客户编号、客户姓名、会员等级、所在城市还有一个时间维表里面存放年、季、月、日、是否是节假日等时间属性。你在分析“北京地区的白金会员今年第一季度贡献了多少销售额”时事实表提供销售额这个数字维表提供“北京”“白金会员”“第一季度”这些筛选条件——两者配合才能回答业务问题。打个比方事实表像一本只记数字的账本每一行是“某天某客户在某门店买了某商品”维度表像一本配套的编码字典告诉你“客户 10086 叫什么名字、住在哪个城市、是什么等级”。分析的时候拿着事实表里的外键去查字典就能给每个数字配上具体的描述然后按你想看的维度去汇总。4.2 事实表的四种类型加性、半加性、非加性、无事实事实表看起来简单但细究起来有四种类型每种适合不同场景。第一种是粒度事实表也叫加性事实表。它记录的是在特定时间、空间点上一次瞬间的测量比如一笔销售订单。这种表可以跨所有维度直接做求和、计数等聚合操作——把金额加起来、把数量加起来都有业务含义。但有一个铁律一个事实表只能有一个粒度不能把不同粒度的事实建在同一张表里否则求和结果就会变得不可解释。第二种是周期快照事实表也叫半加性事实表。它表现的是一个时间段、或者规律性重复的状态比如银行账户余额、月度财务报表。账户余额这种数字按月维度可以求“月末余额”但一般不能把 12 个月的余额直接相加——相加没有业务含义。所以叫“半加性”部分维度比如时间之外的其他维度可以聚合时间维度上不能随便加。第三种是聚合快照事实表也叫非加性事实表。它描述有明确开始和结束的过程比如合同履行、保单受理、工作流处理。它的粒度是一个实体从创建到当前状态的完整历史随着业务处理步骤逐步完善记录。这种表不适合长期连续的过程比如跟踪银行账户。第四种是无事实事实表。每个事实表的粒度是一个事件测量但有些事件发生了就是没有具体的测量值。比如“学生参加了哪门课程”这个事件没有金额、数量只有事实本身。无事实事实表就是用来记录这些事件发生与否的。4.3 星型模型和雪花模型一张图能看懂的区别维度表和事实表的连接方式决定了模型长什么样。最常见的是星型模型和雪花模型。星型模型Star Schema是所有维度表都直接连接到事实表上整个结构从上面看像一个星星中间是事实表周围一圈维度表。它的特点是维度表不再往下连接其他表存在一定的数据冗余。比如“门店维度”里的“区域”字段在星型模型里直接冗余在门店维表里。好处是查询时不需要做太多关联很多统计直接查事实表加维度表就行所以效率一般比较高。雪花模型Snowflake Schema是部分维度表没有直接连接到事实表上而是通过其他维度表连接过去的结构像雪花一样往外分叉。比如门店维表不直接连事实表而是先连一个区域维表再通过区域表连事实表。它减少了数据冗余但查询时往往需要多关联一层表开发复杂度和查询成本会高一些。两者的选择原则用这张表可以概括对比维度星型模型雪花模型维度表连接方式维度表直接连事实表部分维度表通过其他维度表连接数据冗余较高较低查询效率一般较高关联少一般较低关联多维护复杂度较低较高适用场景大多数常规分析维度较大且相对静态的层次通俗地说冗余可接受的前提下优先用星型模型如果维度表很大、层次关系复杂而且数据相对静态才考虑雪花模型。面试里经常有“星型模型是不是一定比雪花模型好”的题目答案是不一定得看维度表的大小和变化频率但大多数场景下星型模型是更务实的折中选择。4.4 缓慢变化维SCD的三种处理覆盖、加行、加列维度表里的数据不是一成不变的。客户的地址会变、员工的部门会调、产品的描述会改。怎么处理这些变化就是缓慢变化维Slowly Changing DimensionSCD要解决的问题。面试里这个问题几乎必考标准答案就是三种类型。Type 1直接覆盖。用新值直接替换旧值历史信息不保留。比如客户改了手机号就把原字段改成新号。这种方式最简单适合“不需要看历史”的场景——但代价是历史没了如果之后要分析“客户改手机号之前的订单归属”就查不到了。Type 2增加新行。不改旧数据而是把当前行的状态标记为关闭off设置一个 end_time 时间戳同时新增一行把状态标记为开启on设置 begin_time 为上一个记录的 end_time 加 1。这样就保留了完整的历史轨迹适合需要看“某个时间点上这条数据长什么样”的场景代价是表的数据量会随着变化次数增长。Type 3增加新列。给表新增一个列来存储新值原来的列保留旧值。比如“当前地址”和“原地址”并存。这种方式只保留最近一次变化适合“只需要对比当前和上一个版本”的场景。三种方式不是互斥的一个维度表可以不同类型字段用不同策略重要属性用 Type 2次要属性用 Type 1需要对比的属性用 Type 3。关键是想清楚每个字段的“历史价值”。4.5 拉链表想看历史快照又怕费空间的折中方案拉链表是缓慢变化维 Type 2 在实践中最常用的一种实现方式。它的核心思路是给每张表维护start_date和end_date两个字段一条记录在某个时间段内是“有效”的到了end_date就封链不再参与查询。表结构大致是这样的-- 拉链表dw_order_his记录订单的历史状态 CREATE TABLE dw_order_his ( order_id VARCHAR(32), -- 订单编号 order_status VARCHAR(10), -- 订单状态 start_date DATE, -- 该状态生效日期 end_date DATE -- 该状态失效日期当前生效记录为9999-12-31 );更新时的操作逻辑是在 ODS 层创建一张表存放当天发生变化的数据包括新增和更新然后把 ODS 变化表和拉链表做关联先对旧记录执行“封链”操作也就是把end_date改成当前日期再把变化数据插入拉链表新记录的end_date设为9999-12-31start_date设为当天。这样想查“某个订单在某个历史时间点是什么状态”只需要按时间条件过滤start_date和end_date就能查出来。拉链表的使用场景非常明确一是表的数据量很大比如一张用户表有上亿条记录、几十个字段全量快照存储成本太高二是表中部分字段会被更新三是需要查看某一个时间点的历史快照四是每天记录变化的比例不大比如 10 亿用户里每天新增和变化的大约 200 万条。满足这四条拉链表就是比“每天全量快照”省钱得多、又比“只保留当前值”有历史可查的方案。拉链表查询性能的优化有两个思路一是给start_date和end_date做索引能明显提升按时间过滤的查询速度二是做数据分级全量拉链表放一份另外暴露一张只提供近 3 个月数据的拉链表给高频查询用——既保住了完整历史又不让日常查询被巨大的表拖垮。5. 这些概念最容易搞混的四个误区为什么总在面试里翻车5.1 STG 层和 ODS 层到底差在哪这是新手最容易混淆的一对概念因为两者的表结构都“和源系统模型一致”都包含审计列名字听起来也都像“存储层”。为什么混STG 和 ODS 在物理模型上确实很像而且很多小公司的数据量小干脆把两层合并导致不少人对它们的定位是模糊的。怎么区分STG 是临时卸货区只保留 7 天或一个月主要目的是减轻源系统压力、支持任务重跑基本不做数据转换ODS 是永久档案馆全量保存源系统的所有历史数据而且要加逻辑删除标记和增量时间戳目的是保留完整历史、支撑下游查询。记住一句话STG 的数据是“过客”ODS 的数据是“永久居民”。另外如果是流式数据同步可以跳过 STG 层直接进 ODS 层——STG 层面向的是批处理场景。5.2 数据仓库的“稳定”和“时变”是不是矛盾面到“数据仓库特点”时经常有人把“稳定性”和“时变性”理解成互相打架——一个说不允许修改一个说会定期反映最新变化这不矛盾吗为什么混两个特点都和时间有关字面上一个指向“不变”一个指向“在变”。怎么区分稳定性说的是数据一旦进入数据仓库用户只能查询和分析不能修改删除——它约束的是“已入库的数据”时变性说的是数据仓库会定期接收新的集成数据从而反映出最新的变化——它约束的是“新数据的进入”。一个管存量一个管增量各自管一段完全不冲突。可以类比档案馆已经归档的档案不能改稳定但档案馆每天都会接收新的档案进来时变。5.3 ETL 日志是不是只有出错时才需要记很多人觉得 ETL 日志就是“出错了才记一笔”这其实是运维视角的误解。为什么混因为一旦 ETL 跑挂了大家第一反应都是“看日志”久而久之就觉得日志是排错工具。怎么区分ETL 日志分三类。执行过程日志是流水账记录 ETL 执行过程中每一步的起始时间、影响了多少行数据错误日志是出问题时专门记录的包含出错时间、出错模块、出错信息总体日志是概要记录只记 ETL 的开始时间、结束时间、是否成功。三者的角色是过程日志帮你定位“跑得慢在哪一步”错误日志告诉你“挂了挂在哪”总体日志用来做日常监控。而且如果 ETL 出错了不仅要有错误日志还要向系统管理员发送警告最常用的就是发邮件附上出错信息让管理员能快速排查。日志要记全警告要主动这才是合格的数据仓库运维习惯。5.4 星型模型是不是一定比雪花模型快网上很多资料说“星型模型查询效率高所以一般用星型”这话本身没错但有人把它理解成了“星型模型在所有场景下都比雪花模型好”这就过头了。为什么混星型模型确实在大多数情况下关联更少、冗余更高、查询更快加上很多 BI 工具默认支持星型建模容易让人形成“星型优于雪花”的印象。怎么区分星型模型快的前提是“维度表直接连事实表、不需要额外关联”一旦维度表本身很大、字段多、层次深直接冗余会造成维护困难和存储膨胀。雪花模型虽然要多关联一层但它在处理大的、相对静态的层次时有优势比如组织架构、产品类目这种层级固定、变化不频繁的维度。所以选择的原则是在冗余可接受的前提下用星型在维度大且相对静态的场景下用雪花。真正决定查询快慢的是数据量、索引、查询语句和计算引擎模型只是其中一个因素。5.5 一个事实表只能有一个粒度这是事实表设计里最容易被忽略的约束。“粒度”指的是表中一行数据代表什么级别的对象——是一笔订单还是一天的订单汇总还是一个月度累计。为什么混因为很多业务口径相近比如“订单明细”和“订单汇总”都跟订单有关有的人就把它们放在一张表里用字段区分。怎么区分一个事实表只能有一个粒度不能将不同粒度的事实建在同一张表中。为什么假设一张表里既有每笔订单的数据又有每天按门店汇总的数据当你对金额做求和时汇总行的金额会被重复计算结果毫无意义。设计事实表时第一步就是确认粒度每一行到底代表一次交易、一个周期快照、还是一个完整过程。粒度定清楚了才知道该用什么事实类型、该按什么方式加载、聚合结果是否可解释——这是整个维度建模里最不能含糊的一件事。6. 什么时候用数据仓库什么时候别用先想清楚再动手数据仓库不是万能的它适合的场景和不适用的场景都很明确。适合用数据仓库的时候通常满足几个特征第一有多个业务系统需要跨系统整合数据来做分析——比如把订单、库存、售后、物流数据拉通起来看“全链路经营状况”第二需要看历史快照——比如查某个订单在某个时间点是什么状态或者复盘“上季度这个客户的消费轨迹”第三源系统承担不了复杂查询——在业务库上跑大范围统计会影响日常交易性能第四需要统一指标口径——不同部门对“销售额”的定义不一样数据仓库可以把它规范成唯一的版本。满足其中两三条就值得做数据仓库。别用数据仓库的场合也很多。团队没有专职的数据开发人员报表直接查业务库就能跑数据量在百万级以内这时候搭一套四层模型是给自己找麻烦业务需要毫秒级的实时响应比如风控接口、实时推荐这种场景该用流式计算或者实时数仓而不是离线数仓数据源头都还没稳定、口径天天变的时候建仓也只是建了个“数据的坟场”。另外如果公司决策层并不真用数据做决策只是“觉得得有数仓”那这个项目大概率会烂尾。我自己就踩过这个坑。刚转行那年接到一个数据分析任务我嫌麻烦没有梳理业务口径直接把源库的数据抽出来拼了一张大宽表给业务方用。结果业务方拿着“销售额”对不上财务的数追查了三天发现是两个系统对“已退款的订单”处理方式不同。从那以后我每次动手前都强制自己先回答三个问题数据给谁看看多细历史要不要回溯把这三个问题想清楚再决定要不要上数据仓库、该上哪几层。这条路没有捷径但每一步都走得踏实就不会翻车。希望帮到你。本文还有配套的精品资源点击获取
