为什么 sum(UV) 对不上总 UV：去重指标非可加性的三种解法与取舍

作者许砚舟

指标体系数据仓库RoaringBitmapHyperLogLog去重指标

一、现象与背景

去年接手一个 App 数据团队，DAU 约 480 万，投放渠道 12 个。接手第一周，产品给我看一张看板："全渠道 UV 之和"是 820 万，但"当日总 UV"只有 470 万，两个数差了 74%。产品问我哪个对。我答：都对，但它们量的是不同的东西——去重指标是非可加的，子集去重值之和天然不等于全集去重值。

这不是个例。我们一个季度里，涉及 UV、去重设备数、新增用户这三个指标的看板，至少 60% 的"对不上"投诉根因都在这条上。更糟的是，有两次产品拿"渠道 UV 之和"当北极星指标去汇报，被老板问"为什么比总用户数还多"，当场下不来台。问题不在谁算错了，而在团队从来没把"可加性"当成指标设计的一等公民。

二、原理或根因分析

先把指标分两类：

可加指标（additive）：对同一实体的不同维度切片做 sum 仍然成立。GMV、订单数、点击量都是——用户在 3 个渠道下了 3 单，sum 起来就是 3 单，没毛病。
非可加指标（non-additive）：UV、去重设备数、独立访客、转化率。它们的本质是集合基数：对 12 个渠道用户集合 C₁…C₁₂，sum |Cᵢ| ≥ |C₁∪…∪C₁₂|，等号只在集合两两不相交时成立。一个用户当天从 3 个渠道进来，就在 3 个 Cᵢ 里各被计 1 次，于是 sum 比总 UV 虚高。

转化率更麻烦，是双重非可加：分子（转化用户数）和分母（曝光用户数）都是去重集合，且分母不能跨维度直接 sum。所以你不能把"渠道 A 转化率 + 渠道 B 转化率"相加，也不能把"渠道转化率之和"当总转化率——总转化率 = 总转化用户 / 总曝光用户，必须回到最细粒度重算。

根因一句话：去重是一个"集合运算"，而 sum 是"代数运算"，两者不可交换。

三、具体做法

我对比了三套方案，按"精确度 / 存储 / 聚合速度"取舍：

方案 A：RoaringBitmap 精确去重（推荐主用）

把每个用户映射成一个连续整数 id，每个"维度值 × 日期"存一个 RoaringBitmap，聚合时用位或（OR）合并再取基数。StarRocks 3.1 / Doris 2.0 都有内建函数：

-- 建表（StarRocks，bitmap 列）
CREATE TABLE uv_bitmap (
    dt        DATE,
    channel   VARCHAR(64),
    uv_bitmap BITMAP
) DISTRIBUTED BY HASH(channel);

-- 按渠道看当日 UV（精确）
SELECT channel, bitmap_union_count(uv_bitmap) AS uv
FROM uv_bitmap WHERE dt = '2026-10-01' GROUP BY channel;

-- 看当日总 UV（跨渠道精确去重，一次位或）
SELECT bitmap_union_count(uv_bitmap) AS total_uv
FROM uv_bitmap WHERE dt = '2026-10-01';

我们的量级：480 万用户，单渠道 bitmap 压缩后 3~6 MB，12 个渠道一天 50 MB 左右，一个月约 1.5 GB，聚合 bitmap_union_count 在 12 个 bitmap 上 <50 ms。误差为 0，这是它最大的价值。

方案 B：HyperLogLog 近似去重（大盘趋势用）

HLL 用固定大小寄存器估计基数，误差不随数据量增长，这是它相对精确方案的核心优势。StarRocks 用 hll_union / hll_count。误差率约为 1/sqrt(2^b)：12 bit 约 3.3%，14 bit 约 1.6%。存储极小——480 万用户一个 HLL 才几百字节到 1 KB 量级，比 bitmap 小 3~4 个数量级。适合"我要看一年 UV 趋势、不在乎 ±2%"的场景。

方案 C：保留最细粒度明细，查询时实时 distinct

SELECT count(distinct user_id) FROM raw_log GROUP BY ...，最准但最贵，明细表动辄几十 GB，跨天 distinct 一跑就是分钟级。只适合低频、高价值的一次性取数。

我的取舍：日常看板用方案 A（精确、够快、成本可接受）；一年跨度的趋势图用方案 B 省存储；临时对账用方案 C。三者并存，按"这个数要进哪个决策"来选。

四、踩过的坑与反直觉之处

坑 1：HLL 算不了"新增 UV"。 新增 = 今天有、昨天没有的用户数，需要差集（A - B）。HLL 只能做并集和基数估计，没有精确的成员判断，所以"今天 HLL - 昨天 HLL"是错的。新增/流失必须用 bitmap 的 bitmap_andnot：bitmap_count(bitmap_andnot(today, yesterday))。
坑 2：id 不连续会让 bitmap 膨胀。 RoaringBitmap 对连续小整数压缩最好；如果直接用 64 位雪花 id 或 UUID 哈希值（稀疏、跨度极大），压缩率会掉得很厉害，单渠道 bitmap 能从 5 MB 涨到 40 MB+。正确做法是先在用户维表里把 id 映射成连续自增整数，再建 bitmap。
坑 3：HLL 相加的误差会累积。 单独一个 HLL 误差约 1.6%，但把 12 个渠道 HLL 并集再估，误差约按 sqrt(n) 放大，12 个并起来实际偏差可能到 3~4%。所以总 UV 要单独建一个 HLL 存，不能由渠道 HLL 相加得到。
反直觉：HLL 误差不随数据量涨（100 万和 1 亿的估计误差差不多），这点反直觉但恰恰是它适合大盘的原因。

五、结论与可复用清单

建指标先判可加性：sum 有语义的是可加指标；UV / 去重数 / 转化率是非可加，必须为它们单独设计存储方案，不能套用"子集相加"的直觉。
精确优先用 RoaringBitmap，误差 0、聚合亚秒级；大盘趋势用 HLL，误差 1~3% 可控、存储极小；临时取数用明细 distinct。
用户 id 必须先映射成连续整数再进 bitmap，否则压缩率崩。
转化率分子分母分别存去重数，永远不要存"比率"再试图聚合。
新增 / 流失用 bitmap 差集（bitmap_andnot），HLL 做不了。
看板文案上把"渠道 UV 之和"和"总 UV"分开命名，别让业务方误以为是同一个数。

赞 0 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。