📚 课程目录第1章数据仓库概述

1. 数据仓库概述：从数据源到应用层，我们到底在搭什么？

大家好，我是老张。做数据这行十几年了，每次带新人，第一个问题总是：「数据仓库到底是个啥？」

这个问题看似简单，但真要讲透，得从几个维度拆开看。今天咱们就聊聊数据仓库的本质，以及它和OLTP、数据湖、数据中台这些概念到底什么关系。

数据仓库，说白了就是一个面向分析的数据存储系统。它不是用来处理日常交易的，而是用来支撑决策分析的。

我记得刚入行那会儿，有个老前辈跟我说：「数据仓库就是企业的记忆体。」当时不太理解，后来做久了才明白——交易系统管的是「当下发生了什么」，数据仓库管的是「过去发生了什么，未来可能发生什么」。

核心定义：数据仓库是一个面向主题的、集成的、非易失的、随时间变化的数据集合，用于支持管理决策。

—— Bill Inmon, 数据仓库之父

你想想看，一个电商平台每天产生几千万条订单数据。交易系统（OLTP）要保证每笔订单能快速写入、实时查询。但如果你要分析「过去三个月哪个品类的复购率最高」，直接在交易库上跑查询？那交易系统就崩了。

这就是数据仓库存在的意义——把分散在各个业务系统的数据，清洗、整合、存储，然后提供给分析人员和决策者使用。

这两个概念是数据仓库的基石。我见过不少刚入行的同学，搞混了OLTP和OLAP，结果设计出来的模型四不像。

咱们直接看对比：

为什么会这样？因为两者的目标完全不同。

OLTP追求的是并发和一致性。你下单时，系统必须保证库存扣减和订单生成是原子操作，不能出现超卖。

OLAP追求的是查询和分析效率。你跑一个季度销售报表，可能需要扫描几亿行数据，这时候索引、分区、列式存储才是关键。

我的经验：曾经有个项目，业务方非要在交易库上直接跑分析查询。结果每次跑报表，前台订单就卡死。后来我们做了读写分离，把分析查询全部迁移到数据仓库，问题才解决。记住——别让OLTP干OLAP的活。

这四个特征，是判断一个系统是不是真正数据仓库的试金石。

数据仓库不是按「部门」或「系统」来组织数据的，而是按业务主题。比如「客户」、「产品」、「订单」、「销售」这些核心概念。

我习惯的做法是：先梳理业务域，再定义主题域。每个主题域对应一个或多个事实表和维度表。

这是最考验功力的地方。数据来自不同系统——订单系统的「客户ID」可能是数字，CRM系统的「客户编号」可能是字符串。到了数据仓库，必须统一编码、统一单位、统一含义。

我曾经处理过一个案例：A系统的「性别」存的是「男/女」，B系统存的是「M/F」，C系统存的是「1/0」。不集成直接拉过来用？分析结果全是错的。

数据仓库里的数据，一旦写入就不会被修改或删除。它只做两件事：加载和查询。

你想想看，如果今天跑出来的报表和明天跑出来的不一样，谁敢用？非易失性保证了数据的历史可追溯性。

数据仓库记录的是历史快照。交易系统里，客户的地址改了，旧地址就覆盖了。但在数据仓库里，我们会保留每个时间点的地址版本。

这就是为什么数据仓库能回答「去年这个时候的客户画像是什么样的」这类问题。

注意：很多初学者把「非易失」理解为「数据永远不变」。不对。非易失是指数据一旦进入仓库，不会被业务操作修改，但数据本身会随着时间不断追加新的快照。这是两个概念。

这三个概念经常被放在一起讨论，但它们的定位完全不同。我画了一张图，帮你理清关系：

这张图我用了很多次，每次都能帮团队对齐认知。咱们逐层拆解：

一句话总结：

我见过不少团队，一上来就喊「我们要建数据中台」。结果连数据仓库都没搭好，数据质量一塌糊涂。中台建在沙子上，风一吹就倒了。

我的建议：如果你的企业还在数据治理的初级阶段，先老老实实把数据仓库建好。数据中台是水到渠成的事，不是空中楼阁。

这一章我们聊了数据仓库的本质，以及它和OLTP、数据湖、数据中台的区别。核心就几点：