- 帆软BI6.1升级有感：“天下苦秦久矣” 2024/6 （加密访问）
- “只在门外，未到门内”：帆软BI DEF 函数“官方测评”的“测评” 2024/6
- 帆软“盗版知识”，似乎有我的“功劳” 2024/07
- 见微知著：帆软BI，是Report+，还是假BI？ 2024/07
帆软在2022年年底推出了 BI6.0版本，很明显依然是对标 Tableau 加速“模仿”，其中重点是数据源和工作表的双层解构、模仿 LOD 表达式的 DEF 函数。
前段时间，一名号称“李启方”的用户在其知乎上发布了号称“致敬”，实则“暗踩”Tableau 的对比文章。我本不想回应，但是考虑到“李启方”之流有诸多“明褒实贬”的行为，帆软也有很多商业使用我的文章而不通知、不付费的前科。我还是想回击一下，点到为止。
万字长文！致敬Tableau LOD15大详细级别表达式——FineBI的复刻
先看上面文章中的几个核心表述（为了保留证据，同时使用截图）：
Tableau作为国外知名BI产品，其LOD表达式可让用户轻松计算不在可视化详细级别层面上的聚合，做到沉浸式分析，但是LOD又并非能轻易学会。
为解决上手问题，官方博客提供了15个经典案例供用户学习，每一个都是经典的高级计算场景，实现能在一个视图中包含多个层次的跨层次分析，为业务分析师提供高级分析思路。
而FineBI作为目前国内帆软旗下领先的BI产品，以BI分析三大件：数据编辑、主题模型、DEF函数作为产品亮点，其中DEF函数（def、def-add、def-sub和earlier函数）则是其专门突破解决复杂计算场景的自研函数。
——帆软“李启方”
1、什么是 DEF？
“李启方”说，“DEF函数包含def、def-add、def-sub和earlier函数四个”。仔细看，这就是“外行”。
DEF ，很多人一看，以为是 Python 中的 def 函数定义，确实，帆软明知自己抄袭 Tableau，但是又难免想说这个是“自研”的，那就不能像永洪、QuickBI 一样光明正大地使用 LOD 这个词了。
所以，产品经理大概就想，既然LOD 是定义一个表达式，我们就用“定义”（define）的 DEF 吧，至少这个DEF 词汇肯定算得是下了功夫——自研的。
而且更加高级的是，tableau 用了三个词，Fixed 、Exclude、Include，帆软不少用户恐怕不知道啥是 exclude 和 include，甚至 fixed 会想这个是“修理啥”。于是，帆软就说我们更简单，DEF、Def-add 和 def-sub，一加一减，自研成就。当然，如果命名为 def-jia 和 def-jian，我想也是极好的。
说回来“李启方”，为什么说他外行？ 他竟然把“def、def-add、def-sub和earlier函数”合成之为 DEF 函数，这样就好和 Tableau 的 LOD 一决高下了！可是，Earlier 压根和 def 不是一个东西，放在一起完全是不明就里；而且四个合称“分析函数”——我觉得这个称呼也不准，甚至有误导性。如果 def 是分析函数，sum 就只能称之为“基础函数”（帆软确实也是这么称呼），简直就是胡说八道了。
当然，只是这样还是过于明显，总是要弄点 Tableau 没有的，于是帆软从楼上PBI 大叔那里偷学了“earlier”函数，阴阳一下 Tableau 说“你没有吧”。终于，帆软一方面说比 Tableau 厉害，又比 PowerBI 强大了。
作为分析函数，官方说是“输出任意层级、任意复杂度的计算指标”。同时非常难能可贵地坦白说：这个计算性能不行，只能在有限数据量基础上计算。当然何为“有限”，一万行，还是一百万，一千万？这个要各自揣测。但是测评的“李启方”肯定是不讲的。
你说帆软明白 lod 的本意了吗？没有，但说没有摸到边也不对，只能说：只到门外，未及门内。
祖曰：“汝作此偈，未见本性，只到门外，未入门内。如此见解觅无上菩提，了不可得，无上菩提，须得言下识自本心，见自本性，不生不灭，于一切时中，念念自见，万法无滞；一真一切真，万境自如如，如如之心，即是真实。若如是见，即是无上菩提之自性也。”
《六祖坛经》
2、看看“李启方之流”的 文章结论
通过本次测评，我们发现针对这15个案例，相较于Tableau的LOD表达式，FineBI的DEF函数在85%情况下能完成相同效果，无需写sql完成，易用性属于中上水平。但FineBI在部分场景下的易用性还稍显不足，例如书写复杂及过滤优先级问题，不过据FineBI产品团队透露，这些问题将在下半年得到解决。 总的来说，通过此次测评可看出FineBI的复杂计算体系已初步构建完成，能满足大部分复杂计算场景，但在各类功能细节处还需不断优化迭代，二者具体优劣势总结可直接见文末测评总结。 ——“李启方”
这一段最有意思了。我特意截图保留了原文和文章最后编辑时间（过段时间应该会修改了）。
首先，“李启方”（我们）发现，“FineBI的DEF函数在85%情况下能完成相同效果，无需写sql完成，易用性属于中上水平”，如果真能如此，那是相当厉害了。不过按照我们一些同行的反馈，恐怕85%言过其实，60%相对客观（不考虑性能），40%比较中肯（考虑性能、优先级等）。
甚至在和 PowerBI、Tableau 用户交流之后，有人得出了30分的结论（当然，仅仅代表个人观点）。
为什么会有这样的评价呢？基本有几个点：
1）帆软号称易用性不低，其实相比 Tableau 易用性差了不少，因为 LOD 表达式只有维度和度量两个部分，DEF 硬生生弄出了维度、聚合、筛选三个部分。所以它的语法是这样的：
DEF(聚合指标, [维度1,维度2,...], [过滤条件1, 2,...])
既没有 LOD 中冒号分割（有人耻笑没有用，那你面壁想一下什么是“键值对”），也没有 PowerBI 中的 Filter 层次过滤。我不知道这个是不是“李启方”说的“书写复杂度”。
如果既要赢 Tableau，又要赢 PowerBI，我想说“DEF 你做到了”，你成功练成了“葵花宝典”！你比 Tableau 多了过滤条件，比 PowerBI 多了 LOD 表达式！
2）
LOD 表达式本质是 SQL 聚合子查询，它和视图详细级别、聚合，乃至筛选的关系才是易用性的关键。更本质上看，一切都是计算优先级的设定——既要稳定，又要灵活。但是，由于 DEF 在设计之处很可能没有想清楚这个点，在“多层次”和“复杂组合”上用力过猛，弄了个更复杂的方案出来。
没有计算优先级的调整，优先级问题就不得不转换为计算的嵌套；一旦出现复杂嵌套，易用性和性能就会急剧下降。
为了挽回颜面，“李启方”以其神通早早的获得了“内部消息”：
不过据FineBI产品团队透露，这些问题将在下半年得到解决。
这个（2023年）下半年，已经过去了，不仅过去了，2024年都快过去快半年了。哥们，文章记得改改，遮羞布要时常拉一下。你以为软件开发那么容易？地基设计是三层楼，盖完了花点时间就能叠上十八层？？
3、“李启方”的测评总结
我本来想挨个点评一下15个案例，想想算了，我这不是“教人做事”嘛，不好不好。索性直接看结论吧。
作为BI产品资深用户，通过这次测评，老李我能明显发现，相较于目前国内其余BI产品，FineBI 6.0 的 DEF 函数在仪表板计算方面表现优秀，功能丰富且强大。
值得一提的是，FineBI内置了数据集功能，这不仅弥补了 DEF 函数在表处理方面的不足，还进一步增强了数据整理和准备能力。与之相对，Tableau 的 FIXED 函数虽然具有一定的计算能力，但缺少过滤能力，同时需要借助另一款名为 Tableau Prep 的工具来完成表处理操作，这带来了一定的阻碍。
我要笑死了，“BI 产品资深用户”说，FineBI 内置了数据集功能，弥补了 DEF 函数的不足，还增强了数据准备和数据整理能力。试问，除了你帆软，谁家还没有个数据集？？入围 Gartner 的 QuickBI 没有吗，还是永洪没有，还是观远没有？？ 这就像说“中国拥有了地球上960万平方公里的大片土地，弥补了人口众多的不足，还得以发展第二和第三产业。”
再说了，你们的 FineBI 安装的时候，为啥还提醒生产环境建议选择其他数据库，而且仅仅只吃几种数据库类型，自己心里没有点数吗？？
看他少不更事地来批评 Tableau ，我就释然了，他恐怕不知道 BI 的首字母怎么念，英文怎么写。
明明是你帆软DEF 没有事先考虑计算的优先级，导致自己在过滤上变得臃肿，反过来竟然说”Tableau 的 FIXED 函数虽然具有一定的计算能力，但缺少过滤能力”！这就好像说“我是矮且丑，可是你虽然高又帅，可是鞋子不合脚”😄
表扬自己言过其实也就罢了，非要无中生有、暗中踩踏，这是何等无知、无耻、无良之辈！
它的结论我就不点评了，一句话，无知者无畏。
不过正如开头所说，FineBI在各类功能细节处还需不断优化迭代，建议FineBI团队仍需踏实研究产品逻辑及用户习惯，期间还是有很多可改进及优化的地方，例如：
1、图表的灵活性：和Tableau对比，无法完成特殊的组合图和一些参考线的效果。
2、复杂函数书写： 目前，在涉及组内排序、组内累计、跨行计算等场景下，函数的书写较为繁琐，需要将其封装成快速计算，以便业务人员更便捷使用。
3、DEF计算优先级问题： 在仪表板中，DEF函数存在优先级问题。例如，在过滤组件和图表联动方面，明细过滤的机制使得部分结果过滤需在组件中配置。这会导致查看用户无法轻松地进行修改和调整。
4、指标计算转换为维度问题： 在柱形图和折线图等情境中，指标计算完成后需要将其转换为维度。然而，维度却无法被编辑，因此再次转换回指标进行编辑。同时，维度也无法参与公式计算，这在某些情况下需要保留一个维度加一个指标的组合。
5、NULL处理问题： 目前，在计算过程中，NULL值被视为当前日期，而非空值。这可能引发一些不准确的计算结果。
6、基础函数问题： 部分基础函数存在缺陷，例如计算时间差缺乏季度参数，导致无法直接计算季度差，限制了一些时间相关计算的可能性。此外，在FineBI组件内部，周数的计算结果与某些函数所得到的周数结果不一致。DEF_ADD不支持MAX_AGG日期等。
屠龙少年终成恶龙。
后补：关于经典LOD15个表达式
LOD15-1
LOD15-2 帆软复刻错误，DEF没有上下文，难以控制优先级。
LOD15-3 ……
补充：如何证明“李启方”不懂 DEF？
今日偶然发现一篇文章，帆软官方号“数据分析不是个事儿” 中一篇文章，原文见下面链接：
其中讲到数据分析的四种模式：
- 第一种模式就叫做 it 模式。
- 第二个模式，我们除了会准备一些数据拼成模型以外，还要区分维度和度量。…… （后面是胡说八道）
- 第三种模式的特点是强烈使用计算字段，…… （后面是胡说八道）
- 第四个模式，正好解决了刚才的问题，它实现了一种几乎完美的平衡。…… （后面是胡说八道）
我们以第三段为例，大家能明白他说的是什么的，可以评论解读一下 。在我看来，完全就是不懂装懂、制造“神秘感”的胡说八道。
第一个“假设”或者“猜测”——是不是所有的表计算都可以转化为def函数？
他不仅不知道这个假设对不对，后面竟然还假设它是对的。然后提出另一个假设：“假设 def 函数可以替换所有的表计算，那么表计算是否还需要？”
当然“李启方”之流也答不上来，所以又假设这个是对的，然后说：哎，那什么时候需要表计算？
全程既不知道，也不回答，提出一些完全误导人的问题。
这一段我换个说法就是：
- 是不是所有问题都能用 BI 解决啊？不知道啊。
- 假设所有问题（比如上厕所）也能用 BI 解决，那我们再假设“手纸是不是 BI 啊？”不知道啊。
- 假设“手纸也是 BI”，那到底还需要需要茅坑啊？不知道啊。
你看懂了么？没看懂我想说什么，但你知道我在胡说八道。
上面这一段其实就是这样。
“李启方”完全不知道 DEF 和表计算之间的区别。如果他知道的话，他应该说，既然 SQL 都能嵌套，那不需要窗口函数啊！！！
感觉这些文章就是为了骗饭软市场部的稿费，强行把500字扩展成了5000字。
顺带弄的帆软很神秘。