一个让人又爱又恨的新函数
9 月 Power BI 更新后，Import 模式和 Direct Lake 模式的语义模型开始支持 ApproximateDistinctCount() 这个 DAX 函数。
我在一个 14 亿行的 Direct Lake 语义模型上做了测试，数据来自纽约出租车样本。结果不出所料：大多数场景下，它比常规去重计数快得多。
实测数据：快，但有代价
先看一组对比。
常规去重计数（按日期统计 Total Amount 的去重值）：
- 耗时约 6 秒
- CPU 时间约 82 秒
- 内存占用 206,294 KB
近似去重计数（同样的查询）：
- 耗时约 4 秒
- CPU 时间约 48 秒
- 内存占用 1,063,476 KB
速度提升明显，CPU 消耗也大幅降低。但有意思的是，内存占用反而高了不少。
考虑到去重计数往往是 DAX 查询变慢、CU 消耗飙升的罪魁祸首，这个性能改进还是相当可观的。
真正的问题：业务方不买账
性能提升是好事，但 ApproximateDistinctCount() 有一个大问题：你的最终用户可能不接受。
想象一下，你跑去跟老板说：「好消息！报表速度翻倍了，唯一的代价是新的近似去重计数和真实值只差大约 1.6%。」
老板大概率会不高兴，然后回你一句：「数字必须 100% 准确，否则我没法做决策。」
这话当然大概率是扯淡——大多数情况下，近似去重计数足够支撑决策了。
肉眼根本看不出差别
我把上面测试的查询做成了两张折线图，结果是这样的：
两张图用肉眼完全分不出来。
1.6% 的偏差在可视化层面几乎不可见，但业务方对「近似」这个词的抵触却是真实存在的。
国内用户怎么看？
国内 BI 场景里，这个问题同样存在。很多企业的报表会直接给到财务、运营做考核依据，数字对不上就是大问题。
我的建议是：
- 对内部分析、探索性看板：大胆用近似计数，性能收益很实在
- 对外报表、考核口径：还是老老实实用精确去重
- 如果一定要用：提前和业务方沟通清楚误差范围，别等上线了再解释
技术上的最优解，不一定等于业务上的最优解。这个函数很好用，但用在哪里，得想清楚。
