如何用 APPROX_COUNT_DISTINCT / HLL_COUNT.MERGE 近似去重计数

appROX_count_DISTINCT 是 BigQuery 中基于 HLL 的快速去重估算函数，误差约±1.6%，仅适用于容忍偏差的场景；误用于计费、审计或等值判断将引发逻辑错误，且不支持 FLOAT64/Struct 类型及与普通 COUNT 混用 HAVING。

APPROX_COUNT_DISTINCT 在 BigQuery 中怎么用才不翻车

直接用 APPROX_COUNT_DISTINCT 比 COUNT(DISTINCT ...) 快得多，尤其在 TB 级表上——但它返回的是带误差的估算值（标准误差约 ±1.6%），不是精确结果。如果你的报表允许容忍少量偏差（比如用户活跃数、设备分布概览），它就是首选。

常见错误是把它当精确函数用：比如用于计费、合规审计或下游做等值比对（WHERE approx_count = 1000），这时会出逻辑漏洞。

• 只支持 String、INT64、BYTES 类型字段，传 FLOAT64 或 STRUCT 会报错 function cannot be used with argument type
• 聚合时不能和普通 COUNT 混在同一个 select 里再加 HAVING 过滤——BigQuery 不允许在 HAVING 中引用近似聚合别名（会报 Invalid alias reference），得用子查询或 CTE
• 空值（NULL）默认被忽略，行为和 COUNT(DISTINCT ...) 一致，无需额外处理

HLL_COUNT.INIT 和 HLL_COUNT.MERGE 的典型链路

当你需要分批计算再合并去重数（比如按天预聚合用户 ID，月底合并），就得用 HyperLogLog（HLL）底层接口：HLL_COUNT.INIT 生成 sketch，HLL_COUNT.MERGE 合并多个 sketch。这比全量重跑 APPROX_COUNT_DISTINCT 节省 90%+ 计算资源。

关键点在于 sketch 是二进制 blob，必须用 BYTES 类型存，且不能跨项目/region 直接 merge（HLL 实现细节有微小差异）。

• HLL_COUNT.INIT(user_id, 15) 第二个参数是精度，推荐 12–15；15 最准但占内存多，12 是 BigQuery 默认值
• 合并前确保所有 sketch 都来自同一精度设置，混用（如一个用 12、一个用 15）会导致结果不可信
• 如果中间表用了 Array 存多个 sketch，HLL_COUNT.MERGE 只接受 ARRAY，不能直接传单个 BYTES 字段
• 示例合并写法：

  SELECT HLL_COUNT.MERGE(sketches) AS approx_uv FROM (   SELECT ARRAY_AGG(sketch) AS sketches   FROM daily_hll_table )

APPROX_COUNT_DISTINCT 和 HLL_COUNT.MERGE 结果不一致？查这三处

两者理论误差范围一致（都是 HLL 算法），但实操中常出现数值差几个百分点——通常不是 bug，而是配置或流程偏差。

• 检查是否混用了不同精度：比如 APPROX_COUNT_DISTINCT 内部默认用 12，而你手动 HLL_COUNT.INIT(..., 15)，merge 后自然偏高
• 确认数据是否完全重叠：HLL_COUNT.MERGE 合并的是 sketch，如果某天数据漏处理（sketch 缺失），就无法回溯补救；而 APPROX_COUNT_DISTINCT 每次都扫原始数据
• 留意时间分区裁剪是否生效：用 HLL_COUNT.MERGE 时若没正确过滤分区（如 _PARTITIONTIME 条件写错），可能多 merge 了历史脏数据

什么时候坚决别用近似去重

误差本身可控，但业务语义一旦要求“确定性”，近似方案就得让位。最典型的三个硬门槛：

• 涉及金额、积分、库存类场景（哪怕只是展示“去重后商品数”，只要下游系统拿这个数做扣减逻辑，就必须精确）
• 做 A/B 实验的指标基线，尤其当组间差异本身就在 1–2% 区间时，±1.6% 误差会让结论失效
• 对接外部系统要求提供 COUNT(DISTINCT) 值（比如广告平台核对曝光去重用户），对方不认 sketch 或误差范围

真正麻烦的不是算法不准，而是误差被当成事实嵌入到下游逻辑里——比如用 HLL_COUNT.MERGE 结果驱动自动扩缩容，而实际流量波动刚好卡在误差边界附近，就会反复震荡。