国产BI的“耻辱”：QuickBI 计算功能测评（下）

作者注：国庆节前，我在去往武汉的漫漫高铁上写了一个“QuickBI 测评”主题文章，没想到小破站迎来数百次转发。

当然，“好景不长”，节后某机构就投诉下架，理由是“侵害商誉”。

作为回应，博客在重发之前文章基础上，增加中、下两篇，分数据、可视化、计算介绍 QuickBI，以正视听。

正如前文所讲，优秀 BI 应该至少在三个层面做到技术扎实、前后统一、理论自洽。

• 数据模型：包括物理模型和逻辑模型，其中逻辑模型是承接数据和指标、可视化的关键，也是国产 BI 普遍薄弱的环节。
• 可视化框架：主流的有 JS Library 范式和 笛卡尔范式，前者如 PBI，后者如 Tableau；国产 BI 嘴上都说抄Tableau，其实普遍是学 PBI，因为容易（当然 DAX 除外，某软就快学废了）。
• 计算体系：数据世界都是计算，数据合并、可视化都可以视为计算的特殊形态。

在之前两篇文章中，我概要地介绍了 QuickBI 在数据源/数据集、可视化方面的能力表现。本篇则会从计算的角度进一步完成评估。

众所周知，计算是 BI 产品最重要的功能，数据模型、交互筛选都可以视为计算的特殊形式， 计算集中体现了产品的水平。

• 国产 BI 的“耻辱”：QuickBI 的“后发优势”（删改版）
• 国产 BI 的“奇迹”：QuickBI 的“后发优势”（中）
• 国产BI的“耻辱”：QuickBI 计算功能测评（下） 本文 ‍‍

01—如何评价BI 产品的计算功能

这里采用《数据可视化分析（第 2 版）》中的思路，从几个角度评价计算的综合能力：

• 基本计算的体系：包括行级别计算和聚合计算的体系，计算创建/编辑的灵活性，函数的设定及其复杂性等
• 高级计算：表计算（窗口函数）和 LOD（聚合子查询）满足高级分析的能力，体现在多个详细级别（颗粒度）的问题上
• 计算的优先级设定及其调整，特别包括筛选的优先级次序

为了测评的公平公正（后期也可以用在其他产品上），这里我列举几个问题，每个问题都会对应若干个核心功能点。

第一阶段，先看基本计算的灵活性和易用性。可以用如下几个问题一探究竟：

• 强调聚合的灵活性：不同类别的销售额总和、利润率
• 强调行级别和聚合计算的组合：2022年，不同品牌的 销售额总和
• 行级别计算和聚合的嵌套：2022年，不同产品的销售额总和、YTD 销售额、MTD 销售额
• 行级别/聚合计算与 IF 判断的组合：不同产品的利润结构（利润＜0）和利润总和分类（SUM 利润＜0）

第二阶段，可以用如下的题目来测试BI 在高级分析的能力：

• 表计算：2024年各月的销售额总和及其同环比（差异计算）
• 表计算：各个子类别的销售额总和及其占比（合计百分比）
• 组合分析：不同订单频次的客户数量
• 组合分析+：各个年度的销售额及其客户阵列（Customer Cohort）

第三阶段，用部分题目评价计算的优先级及其调整。

这一部分较难，不在本次内容计划之中。

从某种意义上，国产 BI 产品实力，可以从计算体系的严谨性、灵活性和完备程度上一览无余。

号称比 Tableau 计算体系更好的大概率会扑街在未来的某条羊肠小道上，自以为能学习 DAX 精髓的也基本是盲人摸象；前人有言“摸着石头过河”，摸石头需要耐心、耐力，不能学习两天就自以为同时精通了 Tableau 和 PowerBI 两大体系，然后一边批评，一边打着“满足客户需求”的幌子弄出一些“特色功能”的，这会让整个体系更加脆弱。

02—基础计算功能测评（上）

本部分基于两个案例，介绍 QuickBI 的聚合计算、行级别计算的实现、易用性，特别批评计算字段的配置逻辑。这也是我以为深刻影响大量用户，不能建立科学的、规范的分析范式的“障碍”，这一障碍甚至胜过之前数据集的凌乱、可视化的僵化。

案例1：不同类别的销售额总和、利润率

这个问题非常简单——没有筛选条件，只有一个维度字段（Category，数据表中直接可用），重点就是两个度量是数据表中没有的：销售额总和、利润率。

其中，销售额总和 可以直接从数据表的 Sales 字段中SUM 聚合而来，几乎每个工具都可以拖曳完成，包括 Excel（称之为“求和项”）。

难点（如果一定要说有难点的话）在于“利润率”，它是两个聚合字段的比值，即不存在于数据表中，也不能经由拖曳直接完成，因此需要创建自定义计算而来。不同工具之间的差异，在于创建此类常见逻辑字段的灵活性和便利性。

借助于拖曳，Auick BI可以快速完成如下的条形图或交叉表，其中度量是销售额总和、利润总和。（我本来计划创建两个独立地条形图，但是 QuickBI 似乎无法完成，体现了可视化模板地简化）

如何使用上述已有的“Sales 求和”与“profit 求和”完成“利润率”计算呢。

为了让大家知道优秀的样式，我不得不搬出来 Tableau的实例。 在 Tableau 中，几乎每个字段胶囊都可以直接双击编辑，或者直接双击创建计算（如下图所示），或者拖曳其他胶囊创建“利润率”计算。官方称之为“即席计算（Ad-Hoc Calculation）”。

国产 BI 普遍把“即席分析”弄成了“快速查询”，不得不唏嘘一阵。在 QuickBI 中，没有上述如此便捷的方式，当然这个可以理解。

不能理解的是，我甚至不能在字段上右键新建计算！唯一的方式，只能是在字段之外、数据表下方位置，点击一个小小的加号，而后选择“新建计算字段”！

而每次创建计算字段，我都觉得是一次煎熬，如果你不能体会这个感受，大概是中毒已深、未曾分别真假便已入局。

鉴于利润率一定是聚合的比值，因此计算毫无疑问是这样的：

sum([Profit])/sum([Sales])

我之讨厌，在于诸如“利润率”的逻辑字段本身已经决定了它的度量属性，它的数值形式，完全不应该在创建计算字段之时让我选择数据类型、字段类型！

为了强调，我这里可以说“两个必然”：

• 聚合的结果必然是度量（measure）
• SUM、AVG 等常见聚合及其比值的结果必然是数值（number）

这里的配置，除了暴露 QuickBI 在产品设计阶段的“无知”，再没有任何的用处。由于这一问题如此的不科学，我不得不再次重提，万分强调。我甚至希望有朝一日 QuickBI 能因为我此处的诘问而修改这个功能。

03—基础计算功能测评（中）

延伸：为什么 QuickBI 的计算设置是“反常识”的异类

如果新用户不能理解上述我的“两个必然”，可以设想这样的场景。

你是中国海关的边检人员，看到全世界的游客来到中国，你会要求他们提供身份证明，比如姓名、国籍、性别等，还需要用 X 光机检查随手物品。 边检人员的经验、判断力，和X 光机的传感器就如同 BI 产品中的函数（function）——根据”输入"的信息，来"输出"对应的结果。

• 如果一个人带着公文包、工作签证，没有危险物品，边检和 X 光机的“输出”结果就是正常放行。
• 如果一个人指纹无法识别，甚至携带毒品，那么边检和 X 光机的“输出”就是警告和强制留置措施。

函数也是一样，FUCNTION 是特定功能的输入、输出的程序预设，每个函数都预设了规定（简称语法）。你问，或者不问，你设置，或者不设置，它都如此。

这就好像边检不会因为对面是一位日本人就问“你是人吗？”，也不会看到对方拿着中国护照却问“你是否要进入中国”。 否则，客户可以毫不意外的投诉他/她涉嫌歧视，或者工作能力不合格。

说回计算，

在 BI 工具中，SUM 函数的结果必然是度量，绝对不会是维度；

SUM 函数的结果必然是数值，绝对不会是字符串。

SUM 函数、SPLIT 函数、LEFT 函数都在程序设定之初都约束了它的输入和输出。所以，SUM(Profit) 可以，而 SUM(产品名称)就不行；SUM(profi)的结果一定是数值，不能是文本。（当然，先不要急于用 DAX 的计算列逻辑，抑或 SQL 中的窗口函数来反驳我，它们虽有特殊性，但和此问题不是一个场景）

也正因为此，我可以斩钉截铁的说，QuickBI 的计算字段之设置，是完完全全、彻彻底底的怪胎，是认知不足的产物，是“四不像”的奇葩。

之前用户对此无感，只能见到什么馒头吃什么；如今，我想努力告诉用户的是，这样的“三聚氰胺馒头”，你大可不必地咽下！

——如果你觉得难受，也不是你的错。

当然，这里的“数值格式化”姑且可以放过一马，虽然我觉得放在这里不是最佳选择，但并非不可原谅。毕竟，像利润率这样的计算，在一开始设置“百分位”的默认格式，确实有助于简化后期的显示。当然，也可以在事后调整。

比如在如下的两个视图中，分别使用不同的格式显示：左侧使用了视图阶段自定义的格式，右侧采用了计算阶段设置的默认格式。

延伸：关于注释的补充‍‍‍‍‍

说到创建计算字段这个“怪胎”，可能有人已经发现前面图示中的异常：我尝试用双斜线（//）、双短横（--）这两种常见的注释方式，字段保存都会报错。

但是，虽然我没有找到如何写注释的方式，但是似乎又解锁了写注释的特殊方法，或者说“BUGGG”。

如下图右侧所示，只要写用一下跨行注释的/**/，错误的注释方式就能用了！更神奇的是，双斜线似乎还创建了“隐藏字段”，出现在了字段提示中。难怪之前的报错是“引用了未知字段 COL_21”，这个所谓的 COL_21，大概率不过是我之前注释的内容罢了。

上图：错误的注释‍

上图：解锁注释的秘密道路‍‍‍‍

回到主题，上面极简的案例可以揭示 QuickBI 在计算上的基本能力——“扑街”如此狼狈，让我始料不及。

04—基础计算功能测评（下）

接下来，我们看一个稍微进阶的例子：

案例2：2022年，不同品牌的 销售额总和

这个例子我在书中、视频中多次提及，这个简单的问题背后，是每个部分都必须借助于计算方可完成。

• 2022年——背后是 YEAR 函数和逻辑判断（这里用订单日期）
• 品牌——背后是 SPLIT 拆分函数，是行级别函数和字符串函数的代表
• 销售额总和——背后是最常见的 SUM 聚合 ‍

1、这里先看神奇的筛选（这里称之为过滤）‍

筛选“2022年”的数据完成分析，相当于在 OrderDate 字段基础上增加自定义YEAR 计算获得日期的年度部分（datepart），而后使用逻辑判断返回“真/TRUE”的明细（YEA(OrderDate)=2022 ）。由于日期是特殊的字符串，是具有连续性的、层次性的字符串，几乎每个 BI 工具都能快速完成日期部分的选择（甚至 Excel 都有这个功能，只是没有那么好用）。

问题在于，当我尝试筛选的时候，我连续选择了好几年都没有找到有效的样本！

有人会说，这是你数据的问题！

是的，我承认，我事先并不知道这个数据表其实只有2014～2017年的数据（参见上图左上角）。我在默认弹出的日期筛选范围（2020～2029）中选择多个都不行，最后才不得不做了一个“各年度的销售额金额”柱状图来确认有效范围。

问题是，为什么筛选不能提示有效的数据值范围？难道这不应该是常识吗？甚至 Excel 都可以的，更别说 Tableau 和 PowerBI 了。可以看下图。

也许用户不知道这个值得优化，但一定感受到了不舒服；也许用户不知道背后的原理，但产品经理一定知道，每个字段（field）不仅仅有名字（field name），还有值的范围。范围可以是理论上可以容纳的所有可能，它们对应字段类型（data type），也可以是数据表中有效值的确定性组合，可以称之为值范围，或者“域“（domain）。

说到这里，我都生气 QuickBI 中乱用名词，比如数据类型、字段类型，这里暂且按下不表。‍‍‍

比如说，订单日期，理论上它可以是1900年1月1日到1999年12月31日的任意值，这通常在计算机程序设置预先定义。但具体到一个数据表中，比如上面的超市数据，实际的可用值就是2014年1月1日到2017年12月30日之间，很多日期没有销售记录，可以做一个简单的去重列表来获得。

对应到年度，YEAR(OrderDate)的数据类型是数字，系统约束的最大范围只在1900～1999之间；但具体到数据表，有效值只在2014～2017。因此可以说，YEAR(OrderDate)就是如下的多值的元组。

{2014, 2015, 2016, 2017}

回到 QuickBI 的过滤器上，当我选择年度筛选，就只应该高亮上面四年的数值，其他年度不可选，或者标记为灰色表示即便选了也没有意义。很显然，QuickBI 在这里偷懒了，我是不相信产品经理不知道这些的。

优秀的产品经理和开发经理，就是用程序开发简化用户的复杂度，或者说用程序的复杂性确保用户的易用性。

2、再说需要使用拆分获得的“品牌”字段

“品牌”字段来自于产品名称的拆分——以空格为分隔符，拆分第1部分。这里使用 SPLIT 函数可以轻松获得。

如果看一下 QuickBI 对 SPLIT 函数的定义就能看出，这本是一个极其简单的“输入>>输出”都异常明确的功能函数。输入必须是字符串，输出也必然是字符串。

SPLIT：使用分隔符将 string 分为多个子字符串，并返回其中一个。

只是我就不知道，为什么非要多此一举、画蛇添足，还容易让人误入歧途的增加数据类型、字段类型的选择。如果非要加，你也可以按照函数的特征，给出最佳的选择也好，并没有，SPLIT 的结果默认数据类型竟然是“度量”，字段类型竟然是“数值”，和事实完全相反！

这本来就是一个本不应该增加，增加了徒增用户使用负担的功能。

说的更彻底一些，这个功能掩盖了开发者的懒惰，因为结果本应该是每个类型的函数默认对应的。

另外，还有很多值得吐槽的地方，比如条形图结果竟然还可以被底部的“缩略轴”所过滤。它虽然没有筛选器的实质，但却做出了过滤的事情，让我期初很不习惯。

如果说，QuickBI 为了确保服务稳定，每个视图默认最多显示1000行，这个我可以理解，但是默认增加一个缩略轴，还是离散字段值的筛选器并加以筛选，这让我不明就里。

除了好看一点，减少一些性能负担，我不知还有什么好处。但我知道，这样的设置和分析的准确、明晰背道而驰。

另外，我对诸多设置都颇有微词，略说几个：

• 不管 Sales 字段如何设置聚合方式，坐标轴、工具提示的度量名称都“岿然不动”，没有准确表达聚合的含义
• 颜色图例只能加维度，不能加 SUM 销售额 这样的度量，莫名其妙，过度约束、技术偷懒。
• 排序应该对没有连续性的字段排序，在数值上排序是什么意思？排序都不需要看依据的？
• TOP N 是对具有连续性字段的排序、筛选，但过滤的对象是离散维度。在“品牌”上筛选毫无作用是几个意思？

05—测评还有必要继续吗？！

‍‍‍

我本来列了很多题目，可是第二个题目至此，写到这里，我已经没有了兴趣，也没有信心。如果某些厂家有兴趣，大可自己好好做做测试，而我也没有必要再继续写下去，自己不开心，他人也不领情。

目前，在我测评的所有国产 BI 工具中（包括数家 BI 厂家找我做付费测评在内），没有任何一家的计算体系能让我满意。帆软的计算止步于高级计算和优先级调整，观远的高级计算还远未成熟，永洪的计算旁生了一些奇怪的分支，QuickBI 的计算则完全是乱作一团。

如果要我说，对谁最失望，毫无疑问是 QuickBI。如果它没有进 Gartner，我压根不会注意到它；但它却进了，各项功能还如此“不堪入目”，实在与我的期望相差最远。

小学题目都做不好，测评中学和大学题目，只有啪啪啪打脸的份。

如果 QuickBI 内部人士看到，生气之余，不妨参考我原计划的题目，继续前面的测试，体会一下那种磕磕绊绊的感觉。

• 强调聚合的灵活性：不同类别的销售额总和、利润率
• 强调行级别和聚合计算的组合：2022年，不同品牌的 销售额总和
• 行级别计算和聚合的嵌套：2022年，不同产品的销售额总和、YTD 销售额、MTD 销售额
• 行级别/聚合计算与 IF 判断的组合：不同产品的利润结构（利润＜0）和利润总和分类（SUM 利润＜0）
• 表计算：2024年各月的销售额总和及其同环比（差异计算）
• 表计算：各个子类别的销售额总和及其占比（合计百分比）
• 组合分析：不同订单频次的客户数量
• 组合分析+：各个年度的销售额及其客户阵列（Customer Cohort）

最后，我想说，‍‍

我之所以批判如此详细，绝非为了批评而批评。“知我者谓我心忧”，不知我者骂我如鼠，五毛拒不谈我的功能和案例，只是人身攻击，恶劣之极令人厌烦，世间烦恼总是如此简单，我也不想理会了。

那就这样吧，让一切交给市场，交给“无形之手”，交给越来越聪明的客户们选择。

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

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

Tableau Visionary 2021～2024

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

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

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

………… MORE …………