再说帆软BI：业务分析最关键概念“追本溯源”
再说帆软BI：业务分析最关键概念“追本溯源”
01—帆软测评的再继续
六月份帆软 BI 发布6.1，我在高铁上随手翻了一下“更新清单”，惊坐起，于是有了“帆软 BI6.1升级有感”的文章。
- 帆软BI6.1升级有感：“天下苦秦久矣” 2024/6/15
一些同行觉得“说话重了”，但我却觉得其实已晚了三秋，商业竞争、时不我待；产品已经发布，几无回天之力。
我本想这就是一个“BI小号”，区区万人关注，提醒一下帆软的产品经理就罢了。后来看了一些官方文章和批评 Tableau 的软文，就有了“周末连载”：
- “无知之幕”：帆软DEF官方案例之吐槽 2024/6/21
- 帆软“盗版知识”，似乎有我的“功劳” 2024/7/1
- 见微知著：帆软BI，是Report+，还是假BI？ 2024/7/7
上述文中，我极力跳出6.1产品功能设计的缺陷本身，指向帆软 BI 更宏观的问题：
- 学Tableau/PowerBI同行未得精髓，“画虎不成反类犬”，把一些简单问题复杂化，把复杂问题“神秘化”。
- 模仿我的知识体系，还不得要领，在狭隘的“知识体系”东拼西凑，无法传递业务分析的最佳实践，拉低了国内分析师的认知水准
萨特说“他人是地狱”，很多人看了我的文章就像骂人，我很理解；就像我用国产 BI“恨铁不成钢”一样。不过，这也让我看到了国产 BI 的巨大商机和个人成长机会，正是因为行业认知水平普遍低下，我才能借助于 Tableau/PowerBI 等优秀产品站在行业之巅，钻入“时间的裂缝”，轻松赚到来自未来的钱。
本来我想这个系列就此打住的，本意是帮助帆软BI 更好地认识到自我，很多人感受到“批评”背后的善意，目的达到就好了。
但是，
前几天手痒，看了几篇之前痛骂的帆软官方帮助文档。令我大跌眼镜的是，改了，但越改越错了！
为了帮助大家以正视听，我不得不再说几句，以免“以讹传讹”。
02—帆软“认识数据表”的“再批评”
以“认识数据表”为例 https://help.fanruan.com/finebi/doc-view-2347.html
先看一下改版之前的内容。下图是2024年1月份版本的原始内容。
这里参考了我书中的部分内容，特别是“问题结构”和维度/度量的诠释方法，虽未告知，但我也很开心。只是，由于理解未能通透，或者想尽可能简化问题，错误地把筛选、甚至“筛选条件”视为维度。
当然，有人会说，“凭什么你说的就是对的！”我就要把“筛选视为维度”，就像 PowerBI 是把“维度视为筛选”！
当然没问题，观点不需要一致，思想需要解放，但合理的观点需要自洽，不能前后矛盾。
PowerBI 能把“维度视为筛选”，并为此设计 FILTER CONTEXT 的逻辑体系令人着迷又困惑，那是产品经理的本领。就不知道，帆软写帮助文档的人，可有此等“本领”？
重点来了，2024年7月改版如下>>
第一，为了避免说“抄袭喜乐君嫌疑”，删除了之前至关重要的“问题结构”的图片，全文中也没有“问题”这一关键词。
在之前文章中，有一句提纲挈领的话“维度就是看数据或者分析问题的角度”，虽有瑕疵，但瑕不掩瑜。
我从来不反对你们抄（或者说借鉴），我反对的是“抄不完整”、误人子弟。结果，为了倒掉“脏水”，反而扔了“孩子”。
第二，引入了“事务”（transaction）和“事实表”（fact table）。
自以为高级的“诠释”，也让文章走向错误之路，可谓满地黄砂、寸草不生。
我不知道写文档的同学是否是计算机、信息专业背景，抑或只是觉得这样更显高级，而没想到竟会是“驴唇不对马嘴”。我前几天友情提醒他们，他们似乎完全没有意识到问题，还表示这已经是“集大成”。
可是，作为头部的 BI 厂家，帆软需要的不是我的“公益指导”，而是顿悟时刻（难道我之前“骂”的不够清楚吗？）不是“拼凑的集成”，而是“逻辑自洽”。
如果一个人连维度/度量，事实表/聚合表，数据类型/字段角色……这些概念的背后逻辑还需要别人指点，只能说明缺乏基本的分析素养。
鉴于这个问题其实普遍地出现在大多数国产 BI 中，我这里就当把《数据可视化分析》未能展开的背景说明一二。
“事务”和“事实表”是数据库领域的专业概念，虽然侵染到分析领域，但本性未改。如果说“维度/度量/筛选”的诠释还能有一家之言的空间，事务/事实表则几乎没有。（推荐参考 Inmon的Building the Data Warehouse，英文版最佳）
“事务”是对相对完整的业务事件的抽象概括，源自最早信息化的金融领域。比如在 ATM 取款100元，看似简单的一件事情，背后是验证身份、核查余额、锁定账户、扣减账户、出款、解锁、凭证等一系列的具体事务。所有这些事务都会被精确地记录在数据库的各种数据表中，这些用来精确计量业务记录（measurement）的数据表称之为“事实表”（fact table）。
注意，我这里特别标记了英文。
重点是，这里的 measurement表示动作的名词形式，就像 develop 是动词形式的“发展”，development 表示“发展”的过程。Measurement 代表业务过程的记录，和问题中的“度量”（measure）截然不同，和分析中的“指标”（metrics）当然也迥异。也正因为此，维度/度量（指标）的诠释，与事务、事实表并无直接的关系。
当然，这不意味着他们没有间接的关系，维度/度量和事实表关联的纽带是“聚合”，而“聚合”正是度量 measure的本质。
能理解这里，帆软这篇“认识数据表”的根本症结才算找到了：要么好好写事实表的关联概念，要么好好写聚合表的关联概念，不能乱套。
- 事实表相关概念：业务事务、数据映射、数据结构、数据类型、关系范式、表关系、表合并、数据清理，等
- 聚合表相关概念：聚合过程、问题结构、字段角色、衍生指标、二次聚合、窗口函数，等
帆软的官方文档用事务和事实表描述维度/指标（度量），这简直就是认知上的裂痕。
在这方面，我自己也有认知“陷落”的时刻，我大约花了三年时间彻底走出来，如果有人看《数据可视化分析》第一版和《业务可视化分析》第一次印刷的版本，还能找到我之前认知错误、虚假宣传的“罪证”。这也是我2023年完全重写《数据可视化分析》第二版，而非小修小改再“哄一哄读者”的关键原因。
说到这里，我个人非常推荐各家 BI 公司由产品经理来完成产品文档核心部分的撰写（纲要、核心要点、知识体系），而非交给一些大学生边理解、边“遍访百家”然后杜撰。
甚至说，产品文档的主题部分，应该在产品设计过程甚至产品开发之前就由产品经理完成。这样，也可以看看哪些产品经理真有学问。BI 行业的产品经理，目前技术实力并非大家想象的那么令人敬畏，看看他们设计的产品就知道了。
说到这里，忍不住发表一下帆软 BI 6.0的“个人看法”。
两年前，帆软 BI6.0还算“惊艳”，它基本上照抄了 Tableau “数据源+可视化”和“工作表+仪表板”的双层结构，以及最重要的 LOD 表达式（当然揉入了 DAX 的一些因素，只是神似）。虽然还有问题，但至少朝向好的方向在走。
今年，帆软BI6.1则走向了歧途，它没有修复 DEF 中遗漏的“计算优先级调整”，反而在薄弱之处“叠床架屋”，以至于大厦摇摇欲坠。所谓的新功能在我看来设计阶段就“误入歧途”，完成之后还想“以强势宣传灌喂客户”，只怕要不了多远就名声扫地，我猜最近升级6.1的客户应该有别样体会的。
再看看现在官网写的DEF案例（【FineBI学习打卡】DAY61 如何计算同期累计值？（下）https://bbs.fanruan.com/thread-149722-1-1.html），难度都堪比 DAX了，不如，早点规划7.0吧。
03—刨根问底，为什么？？？
如此简单的问题，为什么国产 BI 普遍在维度/度量上理解陷入一种“自研”且“自癫”的状态？
常见的错误是，大量的工具在数据源阶段区分维度、度量，在写计算字段时按照维度/度量区分。你看 Tableau 没有这么“用力过猛”。
更深层次的错误是，直接把字段的数据类型（data type）和字段的角色类型（field role）建立关联，导致布尔结果一律放在维度中。
为啥如此？这个要“拷问”两位师父了。
其一，Tableau 区分了维度和度量，但多有语焉不详。
在早年的论文中也明确了分类的重要性，但是大部分产品经理看一遍，看前半段“default role”的结果，忽视了后半段自定义的重要性。而且字段类型、数据角色确实是在一起讲的（毕竟是一篇浓缩的论文）
同时，在产品设计中，大部分忽略了“度量”的本质是聚合。
“利润”是因为包含“默认聚合方式”才称之为度量，不是看上去是“数字”才是度量！
这就好像很多人以为“我智商高所以学习好”，但其实真正的原因是“我很努力所以才显得智商高”，所谓的“智商”根本不存在，它是主观的定义，遮挡了客观的努力。
Tableau 今年产品20年，DAX 也已经14年了！别人十年二十年成长起来的严密逻辑知识，你凭什么想要三天学会呢？还想拳打 Tableau、脚踢 PowerBI。
其二，PowerBI 不区分维度和度量。
大部分国产 BI 嘴上说“学习”Tableau，其实骨子里都是 PowerBI 的套路。
但是， PowerBI 是IT 编程的路线，先有 Tabular 表模型，后来 DAX，再有 PowerBI（如果我没理解错的话）。这就导致它追求代码逻辑的严谨性，而不追求可视化末端的功能。
举例，你看Power Query 只区分字段是否 Summarize 及其类型，并未对“不聚合”进一步定义。
在Power Query 中，你可以设置默认聚合，这样在 Power BI 拖曳中就自动构建了 Calculate 度量表达式。不过，由于高级用户大多使用 DAX“硬搓”计算，所以这个默认聚合方式的重要性几乎没有了。
更重要的是， PowerBI 既没有维度/度量，也没有连续/离散，它是用 Summarize、SummarizeColumns 表达式指定 Measure 存在的环境（context），而非必须先有图表的“笛卡尔空间”。
小白往往忽略了这个地方的重要性，某些“专家”也是。
在国产 BI 测评中，我就“维度/度量”问题展开解释过 N 遍，在我迄今使用过的帆软/QuickBI/有数 BI/永洪 BI/观远 BI 中，客观的说，观远 BI 是唯一能在维度/度量及其与计算关系中勉强过关的（虽然也存在计算结果要选择字段类型的“多余设计”，这一点产品经理已经同意将改进，并增加计算有效性验证）。
QuickBI 最令人失望，它不仅在数据连接阶段就区分维度和度量，而且还要在计算后选择类型/角色（下图），简直是无理至极！
永洪 BI 、观远 BI的数据类型支持远远胜过帆软，这在大数据场景下，对性能很重要，当然也意味着略高的学习难度（观远默认的英文尤其如此，应该改进）。反观帆软BI仅支持数字、文本、日期，明显过于简单了。
爱因斯坦说，“凡事要追求简单，但不要过于简单”，这里也是适用的。
说到这里，可以出一个思考题：下面的这个计算，结果应该是放在维度上呢，还是放在度量上呢？ 欢迎读者留言回答（你一定比很多国产 BI 做的好）
IF SUM(profit ) < 0 then '亏损' // 字符串是维度吗？
else '盈利' // 字符串
end 如果还有不解之处，欢迎观看我的公益视频“20个最重要的数据分析概念”吧。
数据分析关键概念：度量
@喜乐君 咨询顾问｜上海唯知唯识创始人
业务分析师、数据咨询顾问
Tableau Visionary 2021～2024
《数据可视化分析:Tableau原理与实践》2020.8
《业务可视化分析:从问题到图形的Tableau方法》2021.7
《数据可视化分析:分析原理与Tableau、SQL实践》2023.9
………… MORE …………
腾讯云开发者
