数据仓库把业务数据按统一规则整理起来，并保存分析需要的历史记录，提供业务分析和决策能力。例如，我们可以用它对比不同时间、产品和客户的表现。 当分析需要关联几个系统的数据，或者比较过去和现在，数仓可以提供整理好的数据。它有面向主题、集成、时变和非易失这四个特点。理解这些特点后，还要弄清数据怎样接入、清洗、建模和汇总，才能判断最后的分析结果是否可信。

从业务问题理解数据仓库

假设一家电商公司要回答几个经营问题：上个月各类商品卖得怎样？哪些客户一直在买？促销之后销量有变化，是否值得继续投入？

要回答上面这些问题，来看看需数仓需要解决哪些问题。 从数据采集和需求分析的角度来说，下单信息在订单系统里，支付结果在支付系统里，商品分类又由商品系统维护。分析人员把它们分别导出，再合到一起，还得确认：同一商品在不同系统是否用了不同编号？支付成功能否算订单完成？销售金额是否要扣退款？这些定义不同，最后算出来的结果也会不同。

从指标口径的角度来看，把数据放进同一个数据仓库，也可能得到不同结果。例如，一个团队按下单时间统计，另一个按支付时间统计，两份销售报表就会有差异。数仓要把统计规则写清楚。销售额这类用来衡量业务的数值叫指标；需要同一指标的人，应能共用相同定义和计算结果。

从数据处理的角度来看，工程师能把数据搬过来，但字段名并不能告诉他哪些订单算有效。业务人员也要参与设计：先确认想分析什么，再看原来的系统能提供哪些信息，最后一起定下业务规则。

从使用的角度看，数仓提供的数据可以保留每笔业务的记录，这类数据叫明细；也可以把记录按日期、商品等归类计算，形成汇总。使用者还可以通过数据服务来查询。报表是其中一种用途，分析人员也可能筛选客户、比较地区，或者在汇总数值异常时查看具体记录。

数据仓库的定义与四个特点

Bill Inmon 的经典定义用四个特点说明数据仓库：面向主题、集成、随时间变化、非易失，并且这些数据用于支持管理决策。

特点 具体含义 电商例子
面向主题 围绕需要长期分析的业务对象与活动组织信息 围绕客户、商品和销售分析，而非照搬每个应用的菜单
集成 整合来自不同系统的数据，比如标识、格式与业务含义 关联订单与支付记录，统一商品标识、金额单位和指标定义
时变 数据带有时间背景，能够支持历史比较 用户的收货地址发生变化，需要保留历史地址
非易失 数据进入数仓后一般不进行修改或者删除操作，而是有需要时定期进行覆盖，避免像oltp中的交易状态一样随操作反复覆盖 一个订单入库后一般不会变化，如过用户退货，订单状态才会修改

下面详细介绍一下这四个特点： 面向主题，就是围绕要分析的客户、商品、销售等对象和活动整理信息。这不要求把所有内容塞进一张大表。客户资料、订单事件、商品信息可以分别保存，再通过明确关系联系起来。主题告诉我们围绕什么分析，表之间的关系还要另行表达清楚。

来看看集成性，两个系统都写客户编号，不代表编号能直接对应：它们可能使用不同的账户体系。两个字段都叫金额，也可能一个是标价，另一个是实际支付金额。把这种差别弄清楚，统一后再分析，才叫集成。数仓团队要建立对应关系，并说明每个指标统计哪些记录。确实对应不上的数据，不能猜它属于谁。

时变是说数据要带有明确的时间背景，才能比较历史。支付发生在月底，数据却在下月初才同步进来，选哪一个时间统计，就决定它属于哪个月。如果商品后来换了分类，过去的销售按当时分类还是现在分类展示，也需要定规则。仅仅把旧数据存下来，不能替我们决定这些规则。

非易失强调的是怎样维护数据：数仓数据不应随着日常交易操作反复覆盖。这并不禁止一切更新或删除。发现错误、调整规则，或者按要求保留数据，都可能需要修改。数仓团队要按既定流程处理，并告诉使用者数字为什么变了。如果把非易失理解成永远不能修改，错误也就没法修正。

这些特点要一起发挥作用。只有旧数据、没有统一含义，过去的数字可能没法互相比较；只统一现在的数据，却不保存分析所需的过去状态，同样回答不了历史问题。

数仓、业务数据库有什么区别

业务数据库通常负责处理正在发生的业务，例如创建订单、改收货信息、更新支付状态。数仓侧重分析已经记录的业务，例如比较销售表现、了解客户购买行为和时间变化。数据库是存储与处理数据的技术基础，数仓说明的是数据用途和组织方式。因此，不能把它们当作同一类别中互相排斥的产品。

处理一笔订单、修改一个状态，这类日常业务操作通常叫联机事务处理，缩写是 OLTP。读取、组合许多记录，再归类计算，用来回答分析问题，这类工作叫联机分析处理，缩写是 OLAP。

比较角度 业务数据库的常见需要 数据仓库的常见需要
主要问题 这笔订单是否成功处理 不同客户与商品的业务表现如何
读写方式 对特定记录进行事务读写 扫描、关联和汇总较多记录
数据组织 方便执行业务操作、维护事务一致性 方便理解、整合和分析
时间信息 当前状态很重要，也可能另存事件历史 保留分析需要的历史与时间背景
修改方式 随业务进展更新状态，增删改查 按加工与修正流程维护分析数据，查询和统计

为了减少分析查询扫描大量数据时对交易处理的影响，团队常把数仓查询和交易服务分开部署。这是一种工程选择。把业务库复制到另一个服务器，并不会自动让统计规则统一，也不会自动形成适合分析的数据组织。这里的统计规则，就是经常说的数据口径。

哪些场景值得建设数仓

如果需要长期比较历史、连接几个系统，还希望不同分析共用计算结果，就可以评估数仓建设。例如，经营分析看不同月份、地区和商品的销售；客户分析把购买记录与客户信息关连起来；供应链分析比较订货、到货和库存。

数据时效，决定了使用场景。每月复盘经营情况，可以定期处理；监控活动进展，可能需要更快看见新事件。定期集中处理常称为离线加工，更及时处理新数据常称为实时加工。数仓可以采用这两种方式，具体更新频率要按需求决定。

建好数仓后还要维护。原系统字段变了，同步和计算程序可能要调整；指标定义变了，要判断过去的数据是否重新计算；有新团队使用数据，要解释含义并决定访问权限。

数据怎样进入数仓并用于分析

业务系统先产生记录。数据采集程序把需要的数据读取过来，加工程序进行数据整合、连接相关记录，处理数据问题、统一数据单位、并执行约定的业务规则。整理好的分析表供人查询，也可以供报表和数据服务使用。数据源、接入加工、分析数据组织和使用端，组成一条常见链路。

Mermaid 图 1

图中画的是主要加工路径，并没有要求每次查询都先做汇总。使用者可以直接分析明细，一个应用也可能读取不同层次的数据。字段说明、质量检查、访问权限和任务运行管理，需要覆盖整个过程，不能等报表出错才补。

从源系统取数据，按规则转换，再放进目标，这组工作常叫提取、转换、加载，缩写是 ETL。实际系统可以把计算安排在不同位置。

字段是什么意思、什么时候更新、数据怎样一步步加工出来，这些描述数据的信息叫元数据。顺着加工关系，能找到一个销售数字用了哪些记录和步骤，这种关系叫数据血缘。质量检查可以发现订单编号重复、商品对应不上等问题。不过，检查通过只代表满足了已设置的规则，还要确认这些规则是否覆盖业务要求。

数仓实践里，不同加工职责有不同层次名称。负责接入操作数据的层叫 ODS，形成业务明细的层叫 DWD，提供汇总的层叫 DWS，为应用准备结果的层叫 ADS。正式名称分别是操作数据层、明细数据层、汇总数据层和应用数据层。维度属于公共维度模型层 DIM。表中DWD的粒度一致，指每行记录表达同一种细节层次，后面的订单例子会具体说明。这些名称是一种的实践方式，并非所有企业必须遵守的标准。

层次 主要职责 本文电商示例
ODS 接入源数据、按设计保留历史 保存接入的订单与支付记录
DWD 形成含义明确、粒度一致的业务明细 组织已支付订单明细
DWS 复用公共统计结果 按支付日期、商品分类汇总支付金额
ADS 组装特定应用需要的数据 为经营看板准备展示结果

Mermaid 图 2

分层是为了说明各类数据负责什么、哪些结果可以共用。整理好的支付明细能支持不同分析，公共汇总让同一个指标不用每次重算。某个应用有特殊需要，可以在应用层组装结果，无须把特殊逻辑放进所有公共表。

每多一层，也会增加很多表、前后依赖和维护工作。有些中间表没人复用，只会让系统更复杂。设计时应当说得清：这一层为什么要有，谁读取它，出了问题由谁处理。

建模路线也有选择。一种做法先把企业数据按统一的实体关系整理，再提供适合分析的结构。把数据按实体关系拆开、控制重复信息，叫规范化。Kimball 的总线架构则按业务过程逐步建立维度模型，用共用的一致性维度联系不同过程；一致性维度要求同一属性在不同过程里含义和取值一致。这两种路线都能让数仓提供数据分析和决策能力，这里主要介绍的是维度建模。

用一个订单例子认识粒度、事实和维度

设计表之前，先说清每一行是什么。这种细节层次叫粒度。一行如果是一笔已支付订单，金额就要属于这笔订单；一行如果是订单里的一种商品，金额就要分到这份商品明细上。把订单总额放在多份商品明细里一起求和，会重复计算。

支付金额这样的业务度量，叫事实。日期、客户、商品这样的背景信息，可以用来描述、筛选和分组，叫维度。事实表保存业务活动及度量，维度表提供分析属性。以事实表为中心连着维度表，结构像下图中这样，就叫星型模型。

设计顺序是：先选要记录的业务过程，再声明每行代表什么，随后识别维度和事实。先知道记录哪种事件，才能决定用什么属性分析、记录哪些度量。销售、支付和退款可能属于不同业务过程，不能因为都有金额，就不加区分地记成同一种数据。

Mermaid 图 3

图表示事实和维度怎么联系。假设每笔订单只含一种商品，一行记录一笔订单。真实订单如果有多种商品，要么改成商品明细粒度，要么另行设计订单金额如何分配，不能直接照搬这个例子。

看一下下面的 SQL样例，这段sql要做的是按支付日期和商品类别两个组合维度来计算总支付金额。

WITH paid_orders(order_id, paid_date, product_id, paid_amount) AS (
    VALUES
        ('O-A', '2026-09-01', 'P-A', 100),
        ('O-B', '2026-09-01', 'P-B', 80),
        ('O-C', '2026-09-02', 'P-A', 120)
),
products(product_id, category) AS (
    VALUES
        ('P-A', '图书'),
        ('P-B', '文具')
)
SELECT
    o.paid_date,
    p.category,
    SUM(o.paid_amount) AS paid_amount
FROM paid_orders AS o
JOIN products AS p
    ON o.product_id = p.product_id
GROUP BY o.paid_date, p.category
ORDER BY o.paid_date, p.category;

日期与商品分类决定把哪些记录放进一组，然后把组内的支付金额相加。查询结果如下。

支付日期 商品分类 支付金额
2026-09-01 图书 100
2026-09-01 文具 80
2026-09-02 图书 120

能运行，并不代表真实业务结果一定正确。如果商品表里同一个商品编号出现多次，连接后的金额可能变大；如果订单找不到商品，代码中的内连接就会排除它。真实加工需要检查这些情况，并决定怎样处理缺失记录。还要确认业务需求：看板若要净收入，这段只算支付金额的例子即使输出上表结果，也没有满足要求。

如何判断数仓计算结果是否可信

要相信一个结果，至少要能解释它。使用者需要知道每行代表什么，指标包括哪些记录，按哪个时间统计，数据更新到了什么时候。工程师也要能检查接入、加工、发布的过程，并找出异常影响了哪些后续使用者。

要核对的内容 应能回答的问题
业务含义 支付金额是否扣除退款，按什么状态选择订单
粒度与关联 每行代表什么，关联是否导致记录丢失或重复
时间与历史 按发生时间还是入仓时间，分类变化如何影响历史
质量与运行 哪些规则执行了，数据是否按时更新
权限与责任 是否有权限访问需要的所有数据，谁负责处理问题

如果这些问题没人能回答，查询方便反而会让错误数字传得更快。数仓可以帮助团队共用定义、执行检查，但不能自动保证每个指标正确。是否可用，还需要在平时的使用和维护中确认。

常见问题

存的数据很多，就算数据仓库吗？

要看数据是否为分析而整理、不同数据的含义是否统一、分析需要的过去信息是否保留。原始记录再多，也不能证明这些工作已经完成。

数仓只存汇总数据吗？

可以同时保存每笔明细和归类计算后的汇总。只有汇总时，新问题可能无法从已有数值中回答。明细保留了合适的粒度，使用者才能按不同方式分组，继续分析。

数仓必须每天更新一次吗？

不必固定一种更新频率。离线与实时数仓都能用于分析，具体多久更新，要看需求和实现；数仓这个名称本身没有承诺固定延迟。

建好数仓，所有团队的数字就会一致吗？

要看大家是否用了同一指标定义、同样的数据范围和加工结果。不同统计规则也可能各有合理用途，但应该分别命名、解释差别。把数据集中保存，不会自动让数字一致。

刚开始学习，先学分层还是先学业务？

先选一个想回答的业务问题，找出涉及的客户、商品、订单等对象，再说明记录的事件和粒度，最后决定怎样整理和共用数据。分层名称能说明加工职责，却不能替我们判断业务含义。