帆软 FineBI：“族秦者秦也，非天下也”

XILEJUN‍‍‍‍

喜乐君

喜乐君，Tableau咨询顾问、敏捷BI布道师，山东大学本硕，《数据可视化分析》《业务可视化分析》*4本书作者，连续创业者，Tableau Visionary 2021～2025‍‍‍‍‍‍‍‍‍

中国地质大学（武汉）经管学院 MBA 校外导师‍‍‍‍

以Tableau会友，致力于构建业务分析通识框架

XILEJUN.com 全球、XILEJUN.cn 国内同步上线

“唯有知识，让我们免于平庸”

大约一年前，我写了一篇评价 FineBI 6.1的文章，直言设计上的固有缺陷将成为进一步发展的障碍，特别是基础概念模糊、产品逻辑混乱。

帆软BI6.1升级有感：“天下苦秦久矣”

如今快一年了，上述问题不仅没有根本的改变，反而愈演愈烈，开始了“小补丁套中补丁、中补丁套大补丁”的奇特之旅；而产品设计缺陷导致的性能问题也成为大数据量的噩梦，不得不再增加“DEF 层级”默认最多4层的计算限制。

前几日我没忍住和帆软某高层谈及此时，对方表示未来产品会“淡化”DEF 功能。我只能表示“呵呵”，明明是产品设计有缺陷，开局就没有达到行业的基本标准，只是死扛不认，如今浪费巨资、懵逼客户之后，自己不得不再盖上一个大盖头。

回旋镖最终要飞回去了。

-未来心中有数-帆软软件2021届春季校园招聘-招聘求职-江苏省计算机学会

回想秦朝的覆灭，杜牧在《阿房宫赋》中感慨，“灭六国者六国也，非秦也；族秦者秦也，非天下也”。后世汉代常常以秦的兴衰为镜，也算是开创了少有的盛世局面。

如今，在 AI 的大潮中，中国的 BI 领域将迎来自2016年之后的第二波快速发展浪潮；后起之秀如果能好好借鉴帆软、QuickBI 等产品的“错误之路”，当能在 AI 、云服务器的潮流中走出自己的新路，就像 GoodData、Looker 甚至AirTable等。

01

—

FineBI 6.1版本再回顾

我这几天忍不住看了一下去年6.1之后的版本更新，比较重要的更新有几个：

https://help.fanruan.com/finebi/doc-view-1236.html

• 6.1.5 维度过滤支持扩展第④层“快速计算过滤”
• 6.1.5 “对于部分 DEF 场景的计算进行优化，避免复杂度上升”。「系统管理-BI 参数」中新增“DEF 共识嵌套层数”，默认4层！FineDB 数据库引擎增加参数SystemOptimizationConfig.etlDefComplexityLimit
• 6.1.4 增加快速表计算：同比增长、环比、同比等； Earlier 函数语法变化。
• 6.1.2 新增 Window 函数 ；过滤组件支持设置默认值
• 6.1.1 新增日期/文本按钮组过滤

从功能上看，除了 Window 函数都是功能的小修小改。

我个人对筛选（过滤）和 DEF相关的功能最为关注，因为高级筛选和 DEF 近乎等价，都是指定详细级别的预先聚合，同时又是反映BI 产品经理能力高低的镜子。

而筛选优先级和计算优先级，则是BI 产品是否强大的最高体现。

从目前的更新来看，帆软 BI 团队不仅没有彻底修改早期设计混乱导致的问题，而且打算通过“淡化”功能的方式暗地遮羞。

让我们从DEF 说起吧。

02

—

帆软 DEF 设计之成败

从目前来看，帆软DEF 功能的设计毫无疑问是失败的，虽然在它之前 QuickBI 、永洪、网易有数BI 都已经不同程度的过关。

失败原因在于 DEF 自身设计上的“拧巴”——产品经理既想学习 Tableau 的 LOD，又想学习 PowerBI 的 Calculate，还想强加差异（彰显产品特色？）。

最终，一个“既要又要还要”的强大def 功能就诞生了，只是注定非妖即神。

要知道，Tableau LOD 表达式和 PowerBI 的 Calculate 表达式是两个不同的方向，前者强调详细级别的叠加，后者强调筛选条件的叠加；前者对于“详细级别”，后者对应“表模型”。这也是典型了 Tableau 更适合业务多维分析、PowerBI 在财务领域/IT 领域更受欢迎的基因。

帆软BI 的 DEF 表达式，一方面借鉴了 Tableau LOD 表达式设计了三个语法：DEF、DEF_ADD、DEF_SUB，分别对应 DEF、Include、Exclude；另一方面增加 Calculate 的 filter 条件，将它作为 def 语法的第三个参数，并在后期引入了 CLEAN 弥补优先级设定上的不足。

FINEBI： DEF (聚合，维度，筛选条件)

如果不考虑大数据带来的性能挑战的话，我愿意把DEF 称之为“神”。

可惜没有“如果”，DEF 功能在几万行的情况下就尽显疲态，几百万的数据就慢如老狗，更何况 FINEBI 还有默认一千万数据提取的固有限制（早年号称过亿的宣传最近不多加了）。

让问题雪上加霜的是，帆软 BI 的产品经理觉得 Tableau Prep +Desktop 、PowerBI Query+PowerBI 的割裂都太 low 了，它们要设计“一体化分析产品”，追求“一站式分析”！

如果不考虑大数据带来的性能挑战的话，我愿意把 FineBI称之为“神”。

可惜，没有“如果”。

一个只能在手搓几万行 Excel 明细表上搔首弄姿的 BI，就已经不能称之为 BI 了。一个把 ETL 和可视化强行揉在一起的系统，注定做不了真正的“大数据分析”。

这种设计，加上帆软尚不成熟的数据引擎，直接把帆软6.0+的大数据分析赶上了绝路。

说 DEF 强大不？强大。

强大到难以驾驭，强大到无法使用！

不管是在 ETL 中使用，还是在可视化阶段，稍加不慎就将摧毁整个系统。

也正因为，6.1+的升级中增加了默认最多4层的 DEF 嵌套限制；并支持在 ETL 中增加自定义限制！但这并没有根本上解决问题，问题出现产品设计、数据引擎的优化上。

其实，这个问题我早在6.0正式上线之前就给帆软产品经理说过（当时对方是付了钱了，也许是想买我的“表扬”）。

当时的不以为然，现在恐怕后悔莫及吧。

我个人猜测，帆软 BI 7.0或者8.0，上述一体化设计就会彻底被抛弃——承担 ETL 的数据处理流程会从分析阶段“解脱”出来，彻底走上和被它“唾弃”的 Tableau/PowerBI 相同的路线！

到时候，所谓的“一站式分析”就摇身一变，非此之谓也！

03

—

DEF和计算优先级

DEF 功能上线其实是过于仓促了，产品经理和工程师很明显低估了 Tableau LOD 背后的复杂性。

DEF 虽然可以对应 SQL 的嵌套查询，但是又并非完全相同；性能低不在于这个功能本身，而在于分析背后要有一个很好的数据引擎：Tableau 的 Hyper，或者 PowerBI 的VertiPaq。

而帆软目前恰恰缺乏这方面的核心技术。

假设使用 ClickHouse ，跨表关键性能不能保证分析需求——DEF 和 LOD 背后恰恰就是逻辑关系模型转物化生成（虽然是 self-join自连接）。网易有数 BI 在使用 LOD 表达式时对大数据支持常常遇到问题，恐怕就与 clickhouse 脱不了干系。

同时，帆软 DEF 在设计之初就忽略了一个至关重要的，又有助于优化性能的关键：计算的优先级。

如果说 DEF 是嵌套子查询，它默认就要和 join 在一起，那何至于把“明细过滤”放在“DEF 新增列”之前呢？

要知道，DEF 和优先级应该同步推出，可惜帆软后知后觉，等到要解决优先级问题时，却发现之前埋下的地雷已经很难再重新再来一遍了。

可见，早期设计上的逻辑严谨性，是多么的重要。

要说逻辑严谨性，DEF 设计上另一个关键问题就是：

帆软 BI 内部直接都没有对维度、度量、过滤建立科学的理解。我可以在官方文档中找到大量错误表述或者概念歧义的例子。

比如，帆软官方文档中，竟然会认为“销售额”就是指标！

按照官方文档说明，“明细过滤”既可以来自于维度字段，也可以来自于“指标字段”。

https://help.fanruan.com/finebi/doc-view-2403.html

也正是基于这样的似是而非的理解，就有了下面更错误的“过滤优先级”。

在官方说明中，聚合前明细上的“销售额＞100”，竟然还聚合后的筛选使用了完全相同的表达方式！这种堪称幼稚的错误很明显成为了帆软用户潜移默化的“知识毒药”。

https://help.fanruan.com/finebi/doc-view-2405.html

基于这样的理解，上文中官方案例之低级就令人瞠目结舌，全文逻辑漏洞百出，毫无业务逻辑和技术逻辑可言。

而今，官方有了一些及其令人惊讶的“骚操作”，比如6.1.5 维度过滤支持扩展第④层“快速计算过滤”。

在官方案例中，“各个省份、各城市的销售额总和、排名”可以增加“明细筛选”（比如保留省份=江苏省），但是，如果默认筛选器会影响“排名计算”，因此“明细筛选”可以放在排序之后完成。

需求很简单，实现很绕口。

这个背后的错误和前面两个阶段的“销售额＜100”一样的，你以为是把“省份=江苏省”的筛选器优先级调整了？？！！

看上书是，但仅仅是“像”，但不是“是”。

要知道，调整前后的“省份”已经不是一个同一个字段啦！

就像“一个人不能两次迈入同一条河流”，聚合前明细表和聚合后结果的“省份”也不是同一个字段！明细表的“省份”是明细、不是“维度”；聚合表的“省份”是维度也是明细，但不是一个字段啊。

这就是为什么 Tableau 中绝对不会上述帆软 BI 的优先级调整，因为它不是优先级调整，而是完全不同的两个筛选逻辑。

如果不能理解这个，我觉得产品经理可以洗洗睡了（或者就好好看看书）。

喜乐君橱窗，图书优惠购！

04

—

DEF和计算优先级

当然，上述的很多错误理解其实并非帆软如此，之前测评的 QuickBI 也仅仅是今年才有所好转，但理解依然不彻底。我正在希望以我个人微薄的影响力，影响这家后起之秀产品的基础概念认知。

影响一家公司，我就能影响千万用户，此等功德，我自乐见其成。

偌大一个帆软公司，竟然对维度、指标、过滤层级的理解都是如此之幼稚、低级，还堂而皇之地把这些完全错误的知识尝试“投喂”给它的用户。我除了表示无奈和气愤，只能希望“市场先生”能做出应有的判断。

FineReport 的成功是“物理世界”的成功，而 BI 是抽象世界，完全不应该是一个逻辑。我不知道一群 Report 的“教徒”如何能搭建起 BI 的新世界。如果有一天帆软 BI 被其用户唾弃（虽然帆软市场部一直在知乎等阵地清理相关的言乱），我相信不是“误杀”。

在我看来，帆软BI 成败都是“市场先生”的胜利：成功了市场多一个选择，失败了后来人多一份教训。但是，对于很多分析师而言，一个设计不佳的产品可能浪费掉最宝贵的职业光阴，这才是我这里批评帆软的基本动力。

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

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

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

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

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

《业务可视化分析》第二版 202505

注意：

个人观点，仅供同行参考；

视频号上线《数据可视化分析》播客