数仓指标分类实战：可累加、半累加与不可累加指标的设计与优化

最新推荐文章于 2026-06-22 14:35:54 发布

原创

最新推荐文章于 2026-06-22 14:35:54 发布 · 967 阅读

1. 数仓指标分类：从“能不能直接加”说起

刚接触数据仓库那会儿，我最头疼的就是算数。不是不会算，而是不知道该怎么算。比如，老板让我算一下上个月全国的销售额，这简单，把每天的数据加起来就行。但当他问“那上个月每天的平均库存是多少”时，我就懵了——是把每天的库存数加起来除以天数吗？结果一算，完全不对味。后来我才明白，数据仓库里的指标，不是所有都能像小学生做加法那样直接“1+1=2”的。这里面门道很深，直接关系到你设计的报表准不准、算得快不快，甚至整个数仓的架构合不合理。

简单来说，我们可以把指标分成三大类：可累加指标、半累加指标和不可累加指标。这个分类的核心，就是看这个指标在时间和空间维度上，能不能直接进行加法运算。听起来有点抽象？别急，我打个比方。可累加指标就像你钱包里的零钱，今天挣了100，昨天挣了50，那你这两天的总收入就是150，直接加就行。半累加指标有点像你银行账户的余额，你可以查今天、昨天各自的余额，但你不能把今天和昨天的余额加起来说这是你“两天的总余额”，这没意义。不可累加指标就更特别了，比如平均身高，你不能把A班的平均身高和B班的平均身高直接相加再除以2，就说这是总平均身高，这肯定是错的。

理解这三类指标，是数仓建模和性能优化的基石。如果设计错了，轻则查询结果错误，误导业务决策；重则导致查询慢如蜗牛，拖垮整个系统。接下来，我就结合电商、物流这些大家熟悉的场景，带你彻底搞懂它们，并分享一些我踩过坑才总结出来的实战设计和优化技巧。

2. 可累加指标：最“听话”的数据

2.1 定义与核心特征

可累加指标，也叫可加性事实，是数据仓库里最“友好”的一类指标。它的定义非常直白：在任何维度上，都可以直接通过求和（SUM）来获得有意义的汇总结果。这里的“任何维度”通常包括时间维度（天到月到年）、地域维度（城市到省到国家）、产品维度等等。

它的核心特征就是具备加法性质。这意味着，部分之和等于整体。比如，北京分公司销售额 + 上海分公司销售额 = 公司总销售额；1号销售额 + 2号销售额 = 两天的总销售额。这种特性让它的处理变得极其简单。

2.2 典型业务场景举例

在实际业务中，可累加指标非常常见，几乎都是那些描述“事件发生量”或“资源消耗量”的度量。

电商场景：
- 销售额/成交金额 (GMV)：这是最经典的例子。今天卖了100万，明天卖了150万，那么这两天的总销售额就是250万。从商品小类汇总到大类，从城市汇总到全国，都直接相加即可。
- 订单数量：处理了多少个订单，可以直接跨时间和地域汇总。
- 商品销售件数：卖出了多少件商品。
- 用户访问次数 (PV)：网站或页面被浏览的总次数。
- 优惠券核销数量：被使用掉的优惠券总数。
物流场景：
- 包裹出库量/入库量：仓库每天处理了多少个包裹的出入。
- 运输里程数：所有运输路线的总里程。
- 运费成本：所有订单产生的运费总和。
内容平台：
- 视频播放量、文章阅读数、点赞数、评论数。

2.3 存储与查询设计：简单直接是王道

对于可累加指标，我们的设计哲学就是：怎么简单怎么来，别搞复杂了。

存储模型选择：通常，我们会使用事务事实表来存储这类指标。每发生一笔业务（如一笔订单支付成功），就在事实表中插入一条记录，记录下当时的各种维度（时间、商品、用户、地区）和度量值（金额、数量）。

-- 一个简化的销售事实表 DDL 示例
CREATE TABLE fact_sales (
    sale_date DATE,          -- 日期维度
    product_id INT,          -- 产品维度
    city_id INT,             -- 城市维度
    user_id INT,             -- 用户维度
    sales_amount DECIMAL(10, 2), -- 销售额（可累加指标）
    quantity INT,                   -- 销售件数（可累加指标）
    -- ... 其他维度键
    PRIMARY KEY (...),
    INDEX idx_date (sale_date),
    INDEX idx_product (product_id)
);

数据就老老实实地按最细粒度存，不需要做预聚合，因为汇总计算非常廉价。

查询

标签