作者注:国庆节前,我在去往武汉的漫漫高铁上写了一个“QuickBI 测评”主题文章,没想到小破站迎来数百次转发。当然,“好景不长”,节后某机构就投诉下架,理由是“侵害商誉”。
冷静下来想想,第一,打脸不打脸;第二,不打脸的前提是“能听进意见”,哪怕是假装的呢。
原计划要写一个长长的“QuickBI 测评”(下),最近时间有限,不如长话短说,这里仅就仪表板之可视化图形举例一二,以为“中篇”,以飨诸君。本文以案说“法”,少作发挥;如果这篇文章还能被投诉,那我内心将只有悲凉。
01—回顾和展望:评价基准
优秀 BI 应该至少在三个层面做到技术扎实、前后统一、理论自洽。
- 数据模型:包括物理模型和逻辑模型,其中逻辑模型是承接数据和指标、可视化的关键,也是国产 BI 普遍薄弱的环节。
- 可视化框架:主流的有 JS 范式和 笛卡尔范式,前者如 PBI,后者如 Tableau;国产 BI 嘴上都说抄Tableau,其实普遍是学 PBI,因为容易(当然 DAX 除外,某软就快学废了)。
- 计算体系:数据世界都是计算,数据合并、可视化都可以视为计算的特殊形态。
在上篇中,我提到的 QuickBI 的几个致命问题:
https://xilejun.com/other-bi/cn_bi/quickbi-is-it-the-best-bi-of-china/
- 只有物理模型,没有逻辑模型;还把连接、联合、关系等多个概念放在一起,影响了使用者的理解,这是我强烈反对的;某种程度上阻碍了使用者构建标准的分析理解。
- 数据表的约束过于严苛,在存储引擎中映射出来的“数据库字段名称”被滥用;数据类型过于简单等等,都是成为优秀 BI 分析平台的障碍。
- 字段属性、字段角色、字段计算混乱,归根到底是数据表和计算的理解有明显的“认知漏洞”。特别是计算,创下了国产 BI 混乱体系的巅峰。
本篇简化篇幅,从可视化角度一窥“可视化框架”的问题种种,也希望其他国产 BI 以此为戒。
02—从QuickBI 之柱状图看可视化
可视化的图形可以分为三类:
一类:“三图一表”的简单展示,即条形图、折线图、饼图和交叉表
二类:分布和相关性,典型如直方图、散点图和盒须图
三类:结构性分析,典型如百分比条形图和 RFM 类问题
后面两种直接拿来考验 QuickBI 太难了,本次只看最简单的“柱状图”和折线图。
废话不说,直接上案例。
示例1:极简的柱状图的扩展限制
极简柱状图只有一个维度(分类)和一个度量(答案),如下所示。随着字段增加,问题随着复杂,可视化工具应该做好极简柱状图增加多个维度、度量,标记颜色、标签等的可能性。
问题是,Subcategory 已经在“类别/维度”区域,竟然无法添加到“颜色图例”!
当然,如果注意到这里的“颜色图例”后面竟然标记了“维度”,你就应该猜到,颜色中无法增加度量!!!也就是不能为销售额最多的着深色以突出!
示例2:两个分类字段的柱状图
如果在“类别”中增加两个维度字段,QBI 竟然把字段值用连字符拼接放在横轴上!还弄个角度倾斜着,为什么不直接换行呢?
如果想要两个字段不拼接,QBI 单独设计了一个 新区域“拆分/维度”。注意,它是独立于“类别”“值轴”和“颜色图例/维度”的新区域。
内行人应该能看出来了,QuickBI 对每个可视化图形都做了完全自定义的改造,这种改造初衷一定是为了“易用性”和“差异化”,但是稍不留神就会翻车。
03
—
从QuickBI 之折线图看可视化
相比于柱状图,折线图的关键是“折线”所依赖的日期轴,“轴”Axis 的背后是连续性,不管是数字轴(quickbi 称之为值轴),还是日期轴。
我们可以看一下Quickbi 中日期轴的创建和变化。
示例3:日期折线图
日期字段默认会预设多个计算字段(相当于 datetrunc 截取,虽然后面只是标记 month)。把 order_date(month) 加入“类别轴/维度”,把 Quantity 加入“值轴/度量”,就会出现下图。
看上不还不错。
但要注意的是,既然日期是连续的坐标轴,都能生成轴axis 的“ order_date(month) ”日期字段和 “quantity 总和”数值字段就具有了某种意义上的一致性!
我们可以把这种共同特征称之为“连续性”。
也正是因为这种共同特征,日期也可以用数字来表示,比如常见的“UNIX时间戳”,就是从1970年1月1日(UTC/GMT的午夜)开始所经过的秒数(不考虑闰秒),这是人类觉得不友好,但是计算机和未来智能机器人会非常喜欢的“时间记忆法”,因为它可以建立不同国家、时区的人类和机器之间的公共基准!
下图是当前时间点的时间戳和日期的转换。
理解了这一点,你就理解了可视化最重要的字段角色:连续Continuous 和离散 discrete。
很可惜,quickBI 显然没有从这个角度构建可视化的基础架构,所以接下来的扩展,就会出现匪夷所思的现象。
示例4:折线图的简单扩展(分区)
比如,在上面折现基础上增加一个维度字段放在日期之前。竟然出现如下神奇的一幕:新字段和日期被拼接了——就像柱状图中所见的一样。
从这个角度看,quickBI 当然没有把日期的“连续性”视为是独立的特征,事实上,QuickBI 也确实没有连续、离散的功能,就像 PowerBI一样。
这里反映的另一个关键问题是,Country 字段不仅没有分区,反而和日期拼接后似乎还保持了“连续性”,这就出现了“United Status-202210”和“Canada-202210”这两个被自定义拼接的字段构建了连线!
这当然是毫无道理的。
当然,QuickBI 的工程师肯定在着急:吴老师,你用的功能不对,你应该用“拆分/维度”!!!
我们放在“拆分”中,就会出现United States 和 Canada 两个分区。
日期没有“连续性”特征的一个明证,就是它甚至可以被排序,这本应该是“City”这样的离散字段才应该具有的特征——只有没有连续性的字段才需要外部的排序依据。
04、QuickBI 可视化:向左还是向右?
为什么会出现这样的问题呢?这就是 QuickBI 在同时学习 Tableau 和 PowerBI 并尝试打造“瓴羊特色国产 BI”的时候,由于认知不足掉沟里了。
要知道,Tableau 和 PowerBI 是截然不同的两个道路,Tableau 是建立在连续和离散基础上的笛卡尔空间,PowerBI 是建立在 D3.JS 等 Chart Library 基础上的“定制化图表库”。
Tableau 在笛卡尔空间基础上,构建了可视化的界面,可谓艺术品。
而 PowerBI 则围绕基本图形基础上,打造了几百个之多的可视化扩展。常见的图形的配置项目也各不相同。
来自 datama-solutions.github.io|
在使用上,你会发现Tableau 可以根据所点击字段自动切换可视化;PowerBI 和其他 BI 则反之,你需要先选一个类型。
虽然 Tableau 也在开发自己的可视化扩展,比如桑基图、Tableau Tableau,但是这是在笛卡尔标准空间之外的新体系;PowerBI 再怎么扩展,也不会出现另一条道路(或者说很难)。
回看 QuickBI 的可视化,注意每个图形底部的说明,这毫无疑问是在学习 Tableau 的 “智能推荐”。
比如折线图,Tableau 的智能推荐是:“1个日期,0或多个维度,1个或多个度量”;而 QuickBI 的提示是“最少1个维度,最少一个度量”。
这里的关键是“1个日期”!
为什么它要在“维度”之外强调?你却舍弃了?
为什么单独说日期,因为连续性的日期构建“日期轴”,之后才有了折线。
但是,由于 QuickBI 中没有为字段区分连续、离散属性,那就失去了构建可视化的精髓。不仅各种提示千篇一律,甚至出现“明细表”中“不限制度量个数”的笑话!
可以看看 Tableau 的逻辑,QBI 没有学习最重要的“灵魂”,只剩了阉割的形式。
我觉得它入围 Gartner 不是它的错,是 Gartner 的错。
05—谦虚谨慎,戒骄戒躁
可惜的是,很多国产 BI 在“模仿”的时候,尚未通达理解,就开始各种魔改,或者自负地做出取舍,以至于最后不伦不类,还希望强加于分析师之上。
那如何说服分析师群体和表哥表姐,把最好的十年、二十年职业生涯,浪费在这样不负责的产品之上呢?
在我的《数据可视化分析》书中,有一段非常重要的话,我这里稍作修饰就是:
- 维度和度量,是问题上的字段角色定义
- 连续和离散,是可视化上的字段角色定义
如果不能理解这句话的深意,请不要说你是BI 产品的产品经理或者工程师!你的无知正在葬送“国产 BI ”的未来。
我也希望国产工具有朝一日发展起来,这样对整个行业的进步大有裨益,我也能获得更高质量的客户(而不是天天深陷泥潭,还要解释“大屏不是数据分析”)。
少数人以为我是抬Tableau、贬国产 BI,我只能说你 too young。
其一,Tableau 作为全世界敏捷 BI 的翘楚,20年的历史不需要我“抬”,国产 BI 都在“学习”甚至“像素级抄袭”已经说明它的地位。我喜欢 Tableau,只是简单的因为:Tableau 真正地影响了我的一生职业生涯。
其二,如果我只是想“贬低”国产 BI,我大可不必说到“错误的细节”。有耐心的国产 BI 经理可以借此学习,没有耐心的可以置之不理。
几年之后,且看国产 BI 再洗牌。
希望 大家 还在饭桌上。
@喜乐君 咨询顾问|上海唯知唯识创始人
业务分析师、数据咨询顾问
Tableau Visionary 2021~2024
《数据可视化分析:Tableau原理与实践》2020.8
《业务可视化分析:从问题到图形的Tableau方法》2021.7
《数据可视化分析:分析原理与Tableau、SQL实践》2023.9
………… MORE …………