Excel/PBI/国产BI：分析师成长障碍知多少！

01—什么是“透视”？

使用 Excel 及其延伸工具 powerbi 的分析师，无一不熟悉“透视”一词。但是，真能理解“透视”为何意的人又少之又少。

前几日我在海南为客户做 tableau 培训和分析项目，吸引吸引一位 PowerBI 用户转粉 Tableau，席间因为一个数据表处理说起来“透视”一词，就有了如下的对话：

客户：PowerBI 中有一个 powerPivot 很强的，可以说是 powerbi 的前身，其中有一个“逆透视”，就是把数据表“扭一下”。

XILEJUN：这个“扭一下”还是很形象的。“逆透视”在 Tableau Prep 中称之为“转置”，英文称之为 Pivot。Pivot 本意是“枢纽”“支点”。所以，什么是“透视”？

客户：这么说“透视”就是“转置”。

XILEJUN：Excel 中还有一个概念是“透视表”，那什么是“透视表”？

客户：哈哈哈 😂😂😂 

客户心神领会，因为我在培训时特别强调，分析的本质是聚合，透视表的本质不是“转置”，恰恰是“聚合”过程。

图片

为什么我常说“Excel 是表哥表姐通往高级分析师的‘障碍’？”

首当其冲就是概念的模糊影响了理解分析的本质。透视/Pivot 是其中最为明显的。

PowerPivot 的本意当然不是“超级转置”，而是以转置为代表的数据处理和（更重要的）以“透视表”为代表的高级聚合。随着 DAX 语言的引入，PowerPivot 中出现了专门为了完成分析而设计的表达式（Expression）。

- Calculate 度量表达式：凡是使用这个都可以创建度量，相当于在代码中虚拟出了“透视表”的阶段。 

- SUMX 聚合表达式：可以视为 SUM+IF 和 SUMIF、SUMIFS 等的“进化版”，将筛选条件和聚合整合在一起，不仅仅可以在明细中完成预先聚合（对应 Excel 明细表），而且可以在“透视表”阶段完成问题聚合（对应问题）。为此，设计了 Calculated Columns 和 Calculated  Measure 两个入口。

PowerPivot 和后来的 PowerBI 一方面模糊了两个阶段的可视化界限，另一方面又强化了两个阶段的代码逻辑（计算列/度量值），其实提高了学习门槛。加上 Pivot 的理解不能通透，导致很多学习者“一入深似海”，皓首穷经却始终难得精髓。

再回首已百年身！

学习者应该铭记一句话：

Excel 的透视 = 聚合

“转置”不是分析的充分条件，“聚合”才是。

02—何为“维度”

如果说“透视”的误解是 Excel 的“伤疤”（这是历史原因导致的，毕竟 Excel 的年龄超过大部分分析师了），那么对“维度”的误解就是数据分析界的“毒瘤”。

如果说历史原因，维度的误解与 Kimball 的“维度建模”方法论息息相关。当然，这并非 Kimball 的错，而是传统上主导分析的 IT 技术人员把数据仓库中的概念过度地推演到敏捷分析领域。

虽然数据仓库是为分析而生的，但又和敏捷分析在技术上有很多明显差异，特别是很多“度量”（Measure）不能在数据仓库中被物化，比如利润率。而维度是“度量”的分组依据，它却可以被物化。也许，这就是称之为“维度建模”而不是“度量建模”的原因之一吧。

但是！

维度建模方法中，“维度”一词是对数据表（table）的定义，与“维度表”相对而生的不是“度量表”，而是“事实表”（Fact table）！

何为事实？是包含精确计量值的业务过程之详细记录，比如销售明细表、发票明细表。

也正因为此，“维度建模”中的“维度”，和敏捷分析中的“维度”，并非是同一个概念，而只是同一个英文单词的两个场景。前者是客观的、先于问题的，后者是主观的、基于问题的。

图片

就像“老虎”，客观的老虎是动物园的那只老虎，主观的老虎是心中的那只“老虎”。

同是“老虎”，场景不同，涵义迥异。不能因为共用了一个词，就说动物园的“猫”和心中的“恶念”是同一个范围的东西。

由于国产 BI 的很多产品经理都是从数据仓库、数据中台，甚至“report 项目经理”摇身一变而来的，这就导致产品设计中的功能设定带有了浓重的“经验烙印”。

最常见的“瑕疵”，就是在数据源阶段，以维度和度量将字段区分为两个部分，这在 QuickBI 、网易有数中最为明显，如下所示（网易有数）。

图片

在 观远 BI 中，虽然数据源阶段没有使用维度和度量的分类，但是在视图阶段，却将维度和数值并列（如下图所示），这依然不是“究竟法门”。

图片

在观远 BI 中，维度、数值、聚合度量三个概念并列出现，这其实是极其迷惑性的设计。如果不是产品经理理解上的瑕疵，可能就是为了追求“设计上的差异化”。

从视图区域来看，不管是“数值”还是“动态数值”，其实都必然是与聚合相应的。

和数值（number）相对应的应该是“字符串”（String），而非维度。

和维度（dimensions）相对应的必然是“度量”（Measure），而非数值。

难道聚合度量就必须是数值吗？

当然不是。

举例而言，“每个客户的 首次订单日期”，这里的 Min 聚合结果是“日期”，而不是“数值”。

或者复杂一点，“每个学生 的 最低成绩科目”（这其实是两个问题的组合）。这就是为什么一些高级分析工具中，还有 Agg_string 文本聚合函数的原因之一了。

也许有人抬杠说：日期也是数值。你说的对，日期总是可以转化为数字，因为它们都是连续性的；但这么讲下去，我还说“所有的数值也是字符串”呢。

谁还不是字符串，不是字符，不是 bit，不是1和0呢？但这是客观的“构成”，不是主观的角色，已经离题太远。

这就是更进一步混淆维度/度量和数据类型的“超级杠精”了。

当然，这两个概念，在一些巧妙之地确实是有关联的，甚至可以转化的。之前我和漆泽勇为大家讲解过一个“股票收益率分析”，大家不妨问一下：

下面表中的“收益率”，是数值，还是“度量”呢？

图片

不妨把你的理解，写在文末留言区。

精彩至极，必有回响（好书相赠）。

03—此空真空，非彼空·NULL

在程序设计过程中，还有一些过度设计的例子，常常是“无良又强势的甲方”，以“强奸民意”之方式，带偏了没有主见的产品经理。

典型代表是 NULL 的处理。

我在很多工具中见到过 NULL 的“空值处理”逻辑，比如改为0，更有甚者改为“-”（短横）。

如果这个处理放在视图中，也就罢了；一些工具把这个过程放在数据源阶段，就有点过头了。

图片

这个问题的深层原因，与数据库的设计有关。虽然我们习惯的以为数据库的分类是“有无相生、高下相傾”的二分法，非是即否、非1即0；其实不是的。

数据库是“三分谓词”，是、否、Unknown。

表现在数据上就是，1、0、NULL。

很多甲方当然不管、不听、不理解，我就要给我弄成短横！！

我只能说，有些客户是真“gou”，不懂装懂，只会用“纳税人”的钱砸人，别听这些 SB 客户忽悠！

他们不懂 NULL 的真谛，也不懂“空性”的智慧，当然更不会懂软件设计应有的严谨。

04

—

有上下文，无“上下文”

上下文 CONTEXT  vs 筛选 Filter

这个是 PowerBI 世界的关键概念，也是一堵高墙，我看很多人把它讲解的玄乎其神，实在是无力吐槽。

在我看来，与其把功夫花在“上下文”上，不如花在更确定性的概念上“详细级别” 和 “筛选条件”上。就不会出现永洪的奇葩设计“条件列”，还有帆软“东施效颦”的 Lod了。

如果未来一两年再不见有谁把这个概念说清楚（不是说复杂），也许我就分点精力讲一讲，如“阿克萨洪水”洗一洗同行。

国内 PowerBI 领域东施效颦者众，能有自己见解者寡。看看那些嘴上学习 Tableau、背后抄袭 PowerBI 的“成就”，就可见一斑。

当然，令我头痛的远不止上面这些，还有“M 百万”“Operational 操作型数据库”等等很多。

比如，PowerBI 简体版把M 翻译为“百万”，就像非生物学小说硬要把 “一个人”翻译成 “一只全身无毛、直立行走的动物”，纯碎是多此一举。

很多工具学坏不学好，不仅也把 M 翻译为“百万”，还更上一层楼把“中国特色”的“万”翻译为“ten thousand”试图反向输出给西方。

只有一个字形容：绝！