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 结果驱动自动扩缩容，而实际流量波动刚好卡在误差边界附近，就会反复震荡。
