见微知著：帆软BI，是Report+，还是假BI？

又是一个愉快的周末，又到了我们一起关心“国产 BI”的时候，特别是在这个炎热的雨季。最近不少人来问我帆软 BI 的测评情况，也包含帆软厂家的几位读者。能帮助某些人认清现实，我就很高兴；倘若能被动地推送某些人/公司的一点点进步，我更加高兴。

今天说一下帆软 BI 的“明细过滤”吧。

沿着这个功能往前推，你可以看到 BI 背后其实满满的“Report”逻辑（难道产品经理是从 Report团队跳来的？）；往后看，你可以看到帆软 BI 永远不可能成为真正的敏捷、自助 BI——它被自己的过去“扯”住了。‍‍‍‍‍‍‍‍‍‍‍

01—是升级，还是退步？

前段时间帆软 FINEBI6.1“粉墨登场”，其中有一个功能是：“6.6 明细过滤更名指标条件”。

https://help.fanruan.com/finebi/doc-view-2292.html#2c27211ee20f972c

年初在“国产 BI 测评”中，我没有用这个功能，等到后来和永洪的产品经理交流，我才发现永洪BI 中“过滤列”暗藏玄机，如今看来简直一模一样。我不知道谁“学习了”谁，反正是“差生抄差生”，一起沉沦了。

几个月前我劝说永洪的产品经理把这个功能逐渐弱化直到删掉，没想到如今帆软“改头换面”以“指标过滤”的形式貌似还升级了。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

可惜的是，如果说帆软“明细过滤”和永洪“过滤列”本身就是歧义的“半成品”，那么帆软BI6.1把它改为“指标条件”的那一刻，只能说是进一步退步了。

还不如永洪的“过滤列”呢。

为什么这么说呢？

不管是帆软还是永洪，设计这个功能的初衷是诸如完成“合计百分比”的计算，比如帆软在官方文章中的案例：‍‍‍‍‍‍‍‍

https://help.fanruan.com/finebi5.1/doc-view-1608.html

我们先不骂蹩脚、低劣、毫无美感的筛选配置界面，单说上面的过程，可以分解为两步：‍‍‍‍‍‍‍

1-基于【毛利】字段增加“明细过滤”，生成【时尚馆毛利】字段‍‍‍‍‍‍‍‍

2-上述两个字段聚合相除，计算比值‍‍‍‍

敲黑板！！！

在计算“占比”时，分子和分母分别对应SUM 求和。这也意味着，新增“明细过滤”之后的新字段【时尚馆毛利】只是、仅仅增加了条件判断，而没有包含聚合本身（默认聚合方式独立于字段）。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

但凡稍微熟悉 EXCEL 或者 SQL 的人都知道，这个逻辑不过、仅仅是下面表达式的“拙劣翻版”：‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

  SUM（if(风格= "时尚馆", 毛利 , 0 ) ）
/ SUM (毛利)

既然如此，BI工具厂商完全可以花一点点点精力普及一下 IF 逻辑函数，何必大费周章去设计没有把问题弄简单，而只是弄复杂的“产品新功能”呢？ ‍

难道你们是按照上线的功能（不管好坏）发工资？？

02—一无是处的“明细筛选”！‍‍

为了让我的批评更令人信服，我说一下帆软BI（不管是6.0还是6.1）因为这个拙劣设计，而衍生出来的更拙劣限制、BUG，和使用上的“不适”。‍‍‍‍‍‍‍‍‍‍‍‍‍

官方说“功能说明”，其实完全是拙劣设计导致的“副作用”，纯属愚人烦恼。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

1）‍‍‍

视图中仅对「指标」进行明细过滤，不能对「维度」执行。‍

其实，针对任意的字段（对「指标」明细过滤其实不准确，后面批评），都只是一个 IF 逻辑判断的自定义计算而已啊。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

2）

“指标条件后的指标仅支持聚合函数。”

添加“明细过滤（指标过滤）”后，相当于字段级别的“全局筛选器”，这个字段在视图中不再完整，失去了灵活性，甚至不能再做判断！！！‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

字段级别的全局筛选，稍微不当，就会导致数据出错；还无法用计算修正。如下图我在 FineBI6.1的示例。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

3）‍‍“计算字段不支持设置明细过滤。”

有 IF在手，谁想用呢？？？

如果说这个功能有什么好处，我说：毫无好处！！

简直就是BI 版本的“世上本无事，庸人自扰之”。何必呢？

而且，它不仅“一无是处”，还会让 BI看版性能降低！诸此种种功能，这就是帆软 BI 永远达不到行业标准性能的原因！‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

为什么说性能会降低？

这个有点技术，我不展开。有兴趣的（恐怕也就是同行）可以去看看帆软官方帮助的示例，其中介绍了三个场景：‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

https://help.fanruan.com/finebi5.1/doc-view-1608.html

3.1 单指标明细过滤

3.2 多指标明细过滤

3.3 多个指标对同一个字段明细过滤

你看看它的结果，用 SQL 的思维想一下，大概就能知道“明细筛选”在数据引擎中的位置，以及对视图的影响。‍‍‍‍‍

03—和自助 BI 精神背道而驰！‍‍‍

明白了上面的功能性限制，你就知道这个功能本来就没有存在的必要，大概率是片面地理解了客户需求，或者为了迎合“小学生客户”于是开发了“幼儿园级别”功能，结果强行向下兼容，把自己勒个半死。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

到了6.1版本，感觉“明细过滤”名字不够高大上，既然维度基本不能用，索性改个“指标过滤”罢了。‍‍‍‍‍

都是愚人念经，自寻烦恼。‍‍‍‍‍‍

说到这里，某些人肯定坐不住了。

喜乐君，你诽谤！

为了安抚一下看客的心灵，我说一下Tableau 和隔壁“PowerBI”是如何优化此类需求的。‍‍‍‍‍‍‍‍‍‍‍‍

1

Tableau 会在各种最佳实践中，告诉大家请使用 SUM+IF 完成你想要的任何、任意、随心所欲的“条件”判断。用函数的通用性，确保功能的灵活性。‍‍‍‍‍‍‍‍

当然，SUM+IF 和 SUMIF 还是有一点点性能上的差异的，SUM+IF 以“真计算、假筛选”，不符合条件的明细行以空或者0的方式参与计算（推荐用 NULL，不推荐0）。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

相比之下，Excel 的 SUMIF 和 SUMIFS 是“真计算、真筛选”，所以性能高一点点。‍

为此，Tableau 在用户感知不到的数据引擎方面下功夫，有了列式数据引擎 hyper，SUM+IF 和 SUMIF 之间微小的性能差一就被抹平了，而且更复杂的逻辑判断也可以极快实现。

2

隔壁“帕弟”（PowerBI）的手艺则更是厉害，不仅在数据引擎中引入 tabular ，而且在用户感知的函数/表达式层面更上五层楼！直接将SUM+IF 升级为 SUMIF后更上层楼，推出了：‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

CALCULATE 表达式

如果说 SUMIF 优化了性能，胜过 SUM+IF；那么 CALCULATE 就优化了聚合，胜过了 SUMIF！

这才是实质性的功能设计！‍‍‍

有人会说，Tableau 和 PowerBI 孰好？‍‍‍

各有千秋，他们代表了完全不同的两个方向而已。在很久之前的一篇文章中，我曾经提过，国产 BI 的产品经理们，大多没领回精髓。‍‍‍‍‍‍‍

【致知篇57】DAX CALCULATE vs. Tableau LOD：从SUM+IF条件计算到SUMIF

能耐心看到这里，你大概能理解我当前的心情了。

假设把帆软 BI 比作一座大厦，“明细过滤”就像是是产品设计中异化出来的“毒瘤”，是过度迎合低质量客户的“拙劣功能”，即便换个“指标过滤”的新马甲。

这种设计，完全和真正敏捷 BI 背道而驰，它阻碍了筛选本应该有的超级灵活性，为自己徒增了烦恼和负担，产品注定只是大号的“report”，成不了自助的“交互仪表板”。

作为用户，你可能对此少有感知，只是觉得产品怪怪的不好用。‍

在我看来，这是产品设计者的“过错”，它们在虚拟的世界中，为无数的分析师挖了一道缺乏安全感的“壕沟”。‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

作为分析师，你会把你最好的职业生涯，托付在怎样的工具上呢？

@喜乐君 咨询顾问｜上海唯知唯识创始人‍‍‍‍‍‍‍‍‍‍

业务分析师、数据咨询顾问

Tableau Visionary 2021～2024

《数据可视化分析:Tableau原理与实践》2020.8

《业务可视化分析:从问题到图形的Tableau方法》2021.7

《数据可视化分析:分析原理与Tableau、SQL实践》2023.9‍‍‍

………… MORE …………