摘要：企业运营时间一长，大量老旧数据堆积在业务系统里，既没人查，也不能删，占空间、拖性能。于是人们想：能不能把这些“冷数据”挪到另一个专门的仓库里？这就成了数据仓库的第一个用途：“历史数据的安置房”。

数据仓库最早的出现，其实是为了解决某些现实问题：

企业运营时间一长，大量老旧数据堆积在业务系统里，既没人查，也不能删，占空间、拖性能。于是人们想：能不能把这些“冷数据”挪到另一个专门的仓库里？这就成了数据仓库的第一个用途：“历史数据的安置房”。

另外，有的企业不是没数据，而是“太多一模一样的报表，各说各话”，各部门自己从数据库里抽数，标准不统一、重复建设、还带来权限风险，于是需要有个统一的数据仓库，把底层数据打理干净、权限分开管、视图统一出，实现“一处建仓、多处复用”。

数仓定义

数据仓库之父比尔·恩门（BIll Inmon）在1991年出版的“Building the Data Warehouse”《建立数据仓库》一书中所提出的定义被广泛接受——数据仓库（Data Warehouse）

数据仓库是面向分析的、集成的、稳定的数据集合，用于支持企业决策。它从多个业务系统（如ERP、CRM）抽取数据，经过清洗、转换后，按分析需求重新组织，为报表、数据挖掘、BI等提供统一数据支持。

很多时候人们将数据仓引入生活场景来理解，将其比作大型超市的仓库，专门用来存放整理好的商品，这些商品不是随便乱堆的，而是分门别类（比如按时间、业务类型）、贴好标签（清洗过的数据），方便需要的时候快速找到和使用。同样的道理，企业每天用的数据看板、BI报表、趋势分析图，也都不是“凭空生成”的，它们背后也有个强大的数据仓库在默默支持。

数仓特点

1、主题化：数据仓库围绕特定主题组织数据，如客户、产品、销售等。与传统数据库基于业务功能组织数据不同，它将与同一主题相关的数据集中在一起，便于从不同角度对主题进行分析和理解。例如，在一个零售企业的数据仓库中，关于客户的所有信息，包括客户基本资料、购买行为、消费偏好等，都会被整合到 “客户” 这个主题下。

2、集成性：数据仓库中的数据来自多个不同的数据源，如各种业务系统、外部数据文件等。这些数据在进入数据仓库时，会经过清洗、转换和集成等处理过程，以消除数据中的不一致性和冗余，确保数据的一致性和准确性。例如，将不同业务系统中关于产品的编码、名称、规格等信息进行统一规范和整合，使数据仓库中的产品数据具有一致性。

3、稳定性：数据仓库主要用于数据分析和决策支持，而不是用于日常的事务处理。因此，数据一旦进入数据仓库，通常不会被频繁修改或删除，而是以只读的方式供分析人员查询和分析。这使得数据仓库中的数据相对稳定，能够为决策提供可靠的历史数据依据。

4、反映历史变化：数据仓库会保存大量的历史数据，通过记录数据随时间的变化情况，能够反映出业务的发展历程和趋势。例如，它可以存储多年的销售数据，分析人员可以通过这些数据观察到不同年份、季度、月份的销售变化情况，从而预测未来的销售趋势。

数据仓库的5层架构

数仓的分层架构

整个数据仓库的架构大致可以分为五个主要环节，每个环节都像一道车间工序，让数据从“杂乱的原材料”一步步变得有条理、有价值。

1、ODS（原始数据层）

这里汇聚了来自各个系统的数据，比如销售系统、客户管理系统、电商平台、甚至第三方外部数据。它们就像刚进厂的原材料，来源多、格式杂，直接用显然不现实。

如果没有 ODS 层，原始数据就不会被完整地存档，后续分析出现错误，想回头查问题时，就必须直接面对混乱不堪的源系统，像是在垃圾堆里翻找重要文件一样，既低效又风险高。

2、DWD（明细数据层）

这一层的任务，是用专门的工具（通常被称为ETL工具）把原始数据从源系统中“搬”出来，并进行清洗、转换，比如统一日期格式、处理缺失值、做字段映射。就像工厂里的粗加工，把原材料“洗干净、切好块”，才能进入下一步。

如果跳过 DWD 层，就不得不一边清洗数据、一边做聚合建模，结果是流程混乱、资源紧张，缺乏分工，流程效率大打折扣。

3、DWS（汇总数据层）

是整个系统中最重要的存储区，用来安放已经清洗好的数据，通常会用到结构化数据库，比如 MySQL、Oracle，或者支持大数据量的分布式存储。这里的数据已经“成型”，但还没被归类或按业务场景组织。

没有DWS，DM就无法复用已汇总的数据，各业务线就只能自己从明细表一遍一遍地重做汇总，不仅效率低，还容易各说各话，数据“统一视角”无法建立，分析结果自然也不统一。

4、DM（数据集市）

根据不同业务部门的需求（比如销售、财务、运营），从仓库中取出相关数据，按需加工，形成更贴近使用场景的数据子集。你可以把它理解为“部门专属小仓库”，大家不用去翻主仓库，只需从集市里挑自己需要的货。

缺少DM，ADS就得回头从 DWS 抽取数据再加工，导致响应变慢、负担变重。

5、ADS（应用层）

BI 工具、可视化系统、报表接口，就是从这里获取最终的“成品数据”。这一层的数据已经按报表格式准备好，直接可以交给领导、系统、用户端。它的目标只有一个：让数据“看得见、读得懂、信得过”。

如果 ADS 层缺失，业务部门就需要亲自从DM拉数、做分析、出图表，数据是用了，但用得累、用得慢、还可能用错。

对DM层而言，部分公司没有这一层，虽然会降低生产过程中的效率，但对整体而言并没有太大的影响；在生产环境中的实际项目，可根据数据规模选择。

例如小公司跳过DWS层，直接从DWD到DM即ODS+DWD+DM+ADS；初创公司可能只有ODS+DWD+ADS三层（数据不多，报表少）。

这套分层架构既是一种管理逻辑，也是一套工程体系。它让数据像工业流水线一样，从杂乱走向整齐，从原始走向价值。每一层之间相互独立、解决不同问题、职责清晰，既方便治理，又提升效率，更是整个企业数据资产可信可用的基础保障。层级越多，数据处理越规范、跨部门协作越高效、应对需求变化越灵、建设周期越长、维护成本越高。

数据仓库的搭建

我们总说“搭建数据仓库”，听起来像是在做什么特别高深的事，实则不然。如果你愿意用一种生活化的方式理解它，可以把数据仓库想象成一家为企业服务的“超级图书馆”。

这不是一家普通的图书馆，而是一家专门存放、整理、管理“数据图书”的图书馆，它收录的不再是文学名著或百科全书，而是企业日常运行中产生的所有数据记录——销售订单、客户信息、业务流程、会员行为、网站日志……只要是数据，都可以是“馆藏”。

这个图书馆的目标很明确：让管理层、业务部门、分析人员，能够快速找到他们需要的信息，并用它们做出正确的判断。

这座图书馆的搭建一共可以分为六个阶段，让我们来逐一拆解。

1、选址规划（需求分析）

建图书馆之前，首先得清楚要收哪些书。在数据仓库里，这相当于“明确数据需求”：是为了做销售分析？那销售记录、商品信息、门店数据就是重点；是为了做会员画像？那用户行为、注册信息、互动日志就是关键；

初级阶段的需求调研与分析，是整个数仓建设中最容易被低估但最重要的一步，设想如果连业务目标都不清楚，后面再多努力也只是“堆数据”。

2、设计书架（数据建模）

明确要存哪些数据后，接下来就是决定——这些书该怎么放？在图书馆中，我们通常会按分类（文学类、工具书、历史类）来放置书籍，在数据仓库中，也需要设计好“分区结构”与“字段模型”。

这一步称为数据建模。常见的方式有：

3、采购书籍（ETL 过程）

有了架子，自然要“进货”。但注意，很多“书”（也就是原始数据）是来自不同出版社、不同风格的——格式各异，命名不一，有的甚至缺页、印错。这时我们要做的，是用 ETL 工具进行：

Extract（提取）：从不同系统中抽取数据，比如从ERP拉销售表，从CRM拉客户档案；Transform（转换）：统一字段名、格式，清洗错误值，去重；Load（加载）：将数据分门别类地装进设计好的“书架”上。

4、建造图书馆（存储系统）

ETL 处理完后，数据就正式“上架”了，这个阶段叫做数据仓库存储搭建，主要选用合适的存储方式来放置这些“干净的数据图书”：

这一步就像把书籍按顺序摆进书架、设立防火防盗装置，并为日后访问做好性能准备。小型企业常用 MySQL、PostgreSQL；对大数据量要求高的公司会选 Redshift、Hive、ClickHouse 等列式存储；为了保障数据安全与扩展性，通常还会做数据备份与镜像机制。

5、安装检索系统（查询优化）

有了存储，图书馆还需要让“读者”能找到书，好比配好检索系统、自助借书机、前台咨询台，数仓中这一步就是搭建各种查询工具和服务接口：

管理员可以用 SQL 工具（如 DBeaver、Navicat）检索数据；业务人员可以通过 BI 工具（如 FineBI、Tableau）点一点鼠标就出图；系统可以通过 API 调用实时数据进行展示、推荐等。

6、日常维护（监控优化）

图书馆开馆之后，还需要有人维护，对应的就是数据仓库的运维与监控系统，通过定期检查数据质量、监测访问效率，保障这套系统始终“稳定、可靠、好找书”：

图书破损了（数据丢失）要及时补；摆错位置了（数据口径冲突）要调整；检索系统效率慢（查询性能差）要优化索引。

来源：正正杂说