如何选择BI工具：Power BI“向左”，Tableau“向右”

Feb 20, 2023 V1
Feb 21, 2023 V1.1 第二部分增补DAX vs. Tableau/SQL

近期不少客户问我BI软件方面的选择，正好春节前后较为系统地使用了Tableau的几家同行产品，这里针对性地做一个简要对比，后续再根据大家问题不断补充。

一、选择BI的思考点

首先强调，没有“最好的BI工具”。但凡说这种话的人，不是暗藏目的，就是视野偏执。

每个产品都有它自己成长的环境，有其与众不同的基因。一个产品能被设计出来，还能被很多客户接受并发展壮大，一定有它存在的客观环境。所以说，没有最好的BI工具，只有最合适你/我/他/她的BI工具。

对于每个个人或企业组织，主要从如下几个角度考虑：

• 产品选型是面向业务方向的用户，还是面向IT或专业用户使用？
• 产品目的是定制开发复杂报表/复杂可视化，还是开发通用型可视化分析/侧重交互探索？

基于如上的考虑，可以划分如下的四个象限；每个象限对应不同的应用方向。

其次，软件选择既要考虑企业的内外部环境，也要考虑软件的成长基因。寻找“自我需求”和“软件最佳特征”的匹配。

比如说，一家连数据库都不成熟的企业，是不能上来就部署敏捷BI产品的，因为缺乏稳定、规范、持续更新的数据，更缺乏对规范数据的理解。这在很多传统企业非常普遍。此时，借助于填报、数据采集等工具，先解决“业务在线”、数据规范的问题，通常是相对最优选择，这也是很多国产工具自以为傲的地方。

我见过很多用OA流程来代替业务系统的公司，各类数据Excel处理然后上传，这类公司的业务系统往往杂乱无章，数据治理难上加难，几乎是敏捷BI的“墓地”。

再比如，一家虽有业务数据库（ 比如ERP系统），但并无数据仓库的企业，产品选择就要考虑BI产品能否“数据分析与轻型数仓一体”，借助BI带动数据仓库建设，时机成熟后再建设独立的数据仓库平台。既要避免“先数据仓库再BI”的重资产方式，也要避免单方面推动BI产品的“跛脚行为”。

我也见过不少企业，由于数据仓库孱弱、数据模型缺失，导致上层的仪表板缺乏灵活性、稳定性。这种用计算弥补模型不足的方式，是分析中的隐形“炸弹”，通常由外部实施方埋下，然后业务方在某一天引爆，最后导致BI平台被日渐抛弃。

当然，我也见过有些自傲的分析师，用power BI的表模型去理解Tableau，或者用Power BI/Tableau去实现过去的复杂报表，这几乎是“高射炮打蚊子”，与其这样，还不如选择一种国产的Report工具，它们在单一场景上有更好的优化，而且几乎基于Excel的“单元格编辑”范式，不用陷入表、表模型、高级计算的领域。

可见，一家数字化成熟度低的企业，最好的BI工具也无能为力；只有最合适，没有最好。这就要求企业首先能认清自我的现状，然后做出当前阶段的最优选。

二、BI的两大王者：Power BI“向左”，Tableau“向右”

作为BI产品的两大巅峰之作，Tableau生于2003年，至今刚满20岁；Power BI则整合自2015年，作为后来者发展迅猛，被越来越多公司所采用。虽然很多人把它们视为直接的竞争对手，但仔细研究起来，二者的成长基因、强势领域截然不同，因此就会对应到不同的矩阵位置。

1、Tableau和Power BI的两个方向

Tableau的强大，始于独创的VizQL®专利，如今二十年过去，Tableau的可视化基因依然无人能敌，不得不佩服斯坦福学术基因的强大。兼容了SQL的查询方式以及高度类似的函数体系，让Tableau具备了“人人可用”的潜力。在10.5版本加入的hyper引擎，则让Tableau在大数据环境中更添羽翼，几十亿的数据也全然不惧，配合2020年之后日渐强大的Data Management Add-on，让Tableau成为了Kimball教授笔下“BW/BI平台”的绝佳代表。

可见，Tableau的强大，始于可视化，兴于数据引擎+可视化引擎的强大组合，以及超级易用特征。

对比Power BI，它是由Power Query、Power Pivot、Power view以及Power Map多个组件整合而成，当然还有更底层的分析语言——DAX。Query完成查询，Pivot旨在建模，View完成可视化，Power Map则对应地理信息可视化，它们都不同时间发布，并整合在Excel的后续版本之中。也许是避免Excel过于臃肿，也许是需要顺应敏捷BI的大潮，Power BI以整合者的姿态出现，并与后来的Power Automate 组成了微软当前的Power 平台（power Platform）。

可见，Power BI的强大，始于Excel基础和DAX语言，兴于各大功能的整合，简化了企业从数据到分析展现的流程。

正因为此，我倾向于把Tableau视为业务方向的代表，它的易用、灵活、超级可视化，是每个业务用户的福音，即便是毫无IT或数据库背景的人（比如喜乐君自己），只需要简短的学习，凭借业务理解也可以借以遨游于大数据分析的海洋。而把Power BI视为技术方向的代表，它的专业、可扩展性，集成了Excel的“表格组织-单元格编辑”基因，又用DAX把“表模型”放大到近乎无限的境界，如果没有点IT基础或者编程的底子，想要熟练驾驭DAX，是短期难以完成的任务。

也许会有人对此不以为然，觉得DAX并非想象的那么难。

DAX is simple, but it is not easy. ——sqlBI

不妨举个例子。

如果要在销售明细表的基础上，先将数量和单价相乘，再根据视图计算求和，在Power BI中，你需要使用迭代函数（iterator），如下所示：

Total Sales := 
SUMX('superstore', [price] * [Quantity])

如果考虑到视图的详细级别，或者忽略特定字段计算合计百分比，或者忽略视图中的特定筛选器，还可能需要使用CALCULATE表达式和ALL、ALLexcept、Allselected等多种调节符。能写出来如下的表达式，和能理解背后的原理之间，是漫长的练习和思考。

Sales_all_Category := 
CALCULATE ( [Total Sales] , ALL('superstore'.Category)  )

你会发现，为了用好Power BI，你需要学习很多全新的概念，比如X函数、迭代（iteration）、上下文（context）、上下文转换（context transition）等等，任何一个概念卡壳都可能让学习者半途而废。——在学习了很多DAX内容后，我目前还对上下文转换一知半解，没有找到理解的最佳角度。正如Elia Nordlinder所言，“学习DAX最危险的是，眼下写出来的表达式可以运行，但距离理解为什么却是漫长的距离”。

The most dangerous thing with DAX is that you can write things that works, long before you understand what is happening behind the scenes. ——Elias Nordlinder

而在Tableau中，上述的SUMX迭代过程，仅需要行级别计算和聚合的组合就好，也不需要指定数据表（X函数一定是先指定表，再强调计算），它就像SQL的逻辑一样简单——Tableau的VizQL引擎，最后会把计算转化为SQL，包括表计算和LOD表达式，这赋予了二者高度兼容特征。

SUM ( [price]*[Quantity]) ) 

在前不久的一篇公众号中，我对比了DAX中最重要的计算（CALCULATE表达式）和Tableau最重要的计算（LOD表达式）的区别，从高级函数的发展也可以看出，“Power Bi向左，Tableau向右”。

在这篇文章中，喜乐君的总结恰恰代表了两个工具的两个方向：

从计算的角度看，CALCULATE表达式确实代表了极高的逻辑水平，它为优化大数据性能提供了一个绝佳方案，是大数据分析的代表作。它在POWER BI中的位置，犹如LOD之于Tableau。 二者的共同点是，产品经理总结了分析中高频的分析需求，然后将其封装为不同的函数。只是Tableau向右——把维度分类字段封装到FIXED表达式中，而POWER BI向左——把筛选条件封装到CALCULATE表达式中。

喜乐君

筛选及其对应的TRUE/FALSE计算是典型的技术视角，而LOD对应的维度、详细级别，既可能与聚合度、粒度等技术概念直接相通，又可以与业务中的维度分析、多维视角相关联，因此说是典型的业务视角。

看过喜乐君在B站讲解的“15大LOD表达式”案例，以及“Tableau在零售分析中的高级应用”视频的用户，想必能更加理解Tableau所代表的业务视角——这个视角是独立于工具的，只是Tableau做了最好的技术转换。

2、DAX是什么？

为了更好地理解Power BI是更适合IT用户或者专业开发者的，尝试换个角度来介绍Power BI底层的DAX，一旦理解了它，你就理解了Power BI的核心；反之，你理解不了它，就难说会用Power BI——DAX只是Power BI中四大板块之一，还有同样晦涩的表模型（Data Modelling）,相对简单的数据处理（Power Query）和可视化（Data visualizations）。

如果不能善用DAX，你将会错失Power BI中90%的分析潜力。 If we’re not utilizing DAX well, we’re missing roughly 90% of the analytical potential of Power BI. ——Sam McKay at EnterpriseDNA

DAX全称Data Analysis eXpressions（数据分析表达式），这里有个重点：DAX是面向分析的。对比我们熟知的SQL（Structured Query Language，结构化查询语言），SQL的设计初衷是数据库操作，包括增删改查多种场景。分析不是SQL的重点，以至于到了很晚的版本才增加了WINDOW函数（窗口函数），实现了聚合表的二次操纵，至今（未来应该也不会）也没有可视化的能力。

相比SQL，Tableau设计的VizQL相当于“SQL+可视化渲染”，而DAX相对于“更强大的SQL+可视化渲染”。

从分析的角度看，为什么说DAX是更强大的SQL？甚至于DAX是比SQL更适合分析的分析语言。

SQL是面向数据库的，我们可以把所有函数分为表操作函数和字段操作函数两大类，前者的代表是SELECT查询、JOIN操作符，后者的代表是SUM函数和YEAR函数。不管是MySQL、SQLServer，还是大数据的Hadoop Hive，都可以花点时间、轻松地把所有的函数分类地展现出来。

Tableau的VizQL会将拖拽可视化转化为SQL，因此Tableau计算几乎和主流SQL计算高度重合，大家可以从喜乐君绘制的“tableau函数大全”中一窥其体系。

但是，DAX呢？真得远比你想象的复杂。

究其原因，SQL操作的对象是表，产出的结果也是表，所有的交互都是内部的、函数控制的；反观DAX，它既要考虑表达式内部的函数，还要考虑页面、视图上的字段、筛选条件等的影响，这就是最为复杂的context（上下文）。在我看来，DAX的难点是既要平衡internal context和external context，又要理解row context、filter context以及context transition，这超过了大部分业务用户的技术极限和逻辑思考能力。

即便从函数的角度看，DAX也比SQL更加复杂。SQL只需要Select就能实现数据表的投影（project）、筛选（filter）及其组合，DAX则严格区分了不同的场景，在很长的时间内，虽然我知道每个函数做什么，但真得很难做出恰当的选择。

• 数据表抽取特定列（project投影）：FILTERS函数、SELECTCOLUMNS函数，还有Summarize和SummarizeColumns
• 数据表抽取特定行（filter筛选）：FILTER函数、按照条件筛选TOPN

除此之外，DAX中还有常用的ADDCOLUMNS、VALUES、DISTINCT，以及不太常用的ROW、ASSMISSINGITEMS等函数。这些“数据表计算”（table calculation）是SQL中没有的，而是从分析的视角出发重建的庞大体系。

表函数之外是字段函数，虽然每个人都会快速“学会”SUMX，但是只有在理解何为“迭代”（iteration）之后，你才能真正驾驭它，这个就需要建立在表逻辑之上。而要理解更重要的CALCULATE表达式，远远不是知道它的语法那么简单，重点在于ALL、Except、ALLSELECTED、KEEPFILTER，还有更抽象的USERELATIONSHIP、CROSSFILTER等调节符。

SalesLA :=
CALCULATE (
          [Total Sales],
          'Store Regions'[City Name] = "Los Angeles"
)

当然了，还让让很多人头晕的计算列（calculated columns）和度量值（Measure）之间的差异。虽然功能上，我们可以说前者是数据源阶段的数据准备，后者是问题阶段的聚合分析，但鉴于DAX在两个阶段均可使用，度量值、度量值这两个位置，叠加DAX的两类“上下文”（context），进一步增加了DAX理解的难度。

甚至于，高级用户可以完全绕开Power BI的可视化界面，把DAX当作一种语言来使用（类似于SQL）。这就是DAX公式和DAX查询的区别（参考Elias Nordlinder介绍）。

如下是一段DAX公式（DAX formula）：

Sales Amount :=
SUMX ( 
      Sales,
      Sales[Order Quantity] * Sales[Unit Price] * (1 - Sales[Discount Applied] 
)

相比之下，如下则是完全独立于power BI的DAX查询（DAX query），大家可以去DAX.do by SQLBI，在这个网站上执行DAX查询，体会SQL从数据表到数据表的过程。

DEFINE 
    MEASURE Sales[Sales Amount] = SUMX ( Sales, Sales[Quantity] * Sales[Unit Price] )
EVALUATE
SUMMARIZECOLUMNS (
    Product[Product Name]
    "Sales Amount", [Sales Amount]
)

现在再回首开头的那句话，你可能会理解，为什么Power BI的大师说“DAX is simple, but not easy”。网络上不少人说“7天成为数据分析师”“14天掌握Power BI”，不过是营销的噱头，从所知到所悟，从明白到懂得，是非常陡峭的学习坡道。

“学习 DAX最危险的莫过于，你写下的DAX虽然运行正确，但却要耗费漫长的时间去理解为什么。” The most dangerous thing with DAX is that you can write things that works, long before you understand what is happening behind the scenes.

这还仅仅是分析语言DAX，如果你想要完整地驾驭数据处理，你还要学习Power Query中的另一门语言——M语言。如果对比Prep Builder，Kettle等可视化ETL，你会发现Power BI的数据处理更像是technical的，缺乏更好地拖拽效果，以及功能封装。

正因为此，喜乐君个人之见，Power BI并不适合每个人（Power BI也从没像Tableau一样宣扬 we help people），相比Tableau入门容易、需要时日精深，基于DAX的Power BI入门就不容易、学习路径更加陡峭，需要更高的逻辑抽象能力。

三、国产BI工具的困境

补充Feb 25, 2023

近几年来，国产BI工具（中国场景下往往会包含报表的部分）有了很大的发展——当然主要是市场上，而非技术上。早期是老牌“北”润乾（2000，不过好像从报表转向研究SPL去了）、“南”帆软（2003）的天下，后来很多公司加入，比如永洪（2014）、观远软件（2016），还有很多大树下面好乘凉的网易有数BI、阿里Quick BI等产品发布，它们的报表及BI产品，基本是国内当前的主流。

不过，不管是和Power BI的DAX之高深莫测相比，还是和tableau的可视化及LOD之优雅相比，国产BI很难有称之为特色的功能。很多BI工具被困在客户“昨日的习惯”之中，为落后的产能耗费大量的精力；或者满足于东抄西凑却没有时间和精力构建完整的分析框架和体系。

1、“中国化”复杂报表，是敏捷分析的敌人

过去很多人会，Tableau能否做复杂报表、“中国化”报表，虽然我能感受到问这个问题的客户和个人在逐年减少，不过还是要强调的是，在我看来，这恰好是国产BI的“遮羞布”，是BI界的伪需求。

“中国化”并非总是好的，特别是是技术落后的数据领域。如果全世界都在主张“普世价值”，而独有你一人叽叽抗拒，你要么是超越大家的“神”，要么是抗拒改变的“魔”。在数据分析领域，基于数学的集合和谓词逻辑的关系型数据，几乎是全世界通用的规范，是数据分析的基础。规范的数据表中，数据明细行对应业务逻辑，字段列对应业务对象，二者交织构成了企业的业务记录。分析不过是对业务、数据的高度抽象，最终“反哺”业务优化运营、提高企业竞争力。

而所谓的“中国化”报表，通常是过度追求单元格级别的规范、过度追求表达上的嵌套形式，用形式上的丰富掩盖内容上的深刻和理解的不足。所以说，强调“中国化复杂报表”的企业，透漏了了深陷Excel习惯无法自拔的中高层传统领导及公司的落后数据文化，这是敏捷BI最大的敌人，是规范数据和可视化分析面前的巨大障碍。

多年有国企的领导问我，“Tableau能否在交叉表上加表头斜线”。当年，他可能没有意识到自己的无知，而我也没有意识到BI工具的差异。

可以说，复杂报表的数量，和一家企业的数字化文明程度成反比。

在《数据可视化分析2.0》中，我对比了与复杂报表相反的发展方向——metrics指标。相比形式化的复杂报表，指标代表了业务分析的未来——借助于关键KPI指标，帮助领导更快地发展问题。 Tableau的Metrics功能发布于2020年，而Power BI的相关功能发布于2022年年底。

2、填报不是BI分析，敏捷ETL和可视化才是

另一个常见的误区是，把数据填报视为BI工具的一部分，这在过去盛行一生。

不管把BI分析理解为低阶的Business information，还是高阶的business intelligence，BI都是规范数据的归纳、抽象、转换的过程。如下图所示，数据填报属于“信息化”建设内容，对应业务数据从无到有、从纸质到电子、从手工到自动化的过程，数据填报通常使用ERP、CRM、MES等专门的业务系统平台完成，部分管理数据会借助于OA（办公自动化）来采集和规整。

BI，是从数据库开始的。早期的BI工具侧重于可视化分析、交互探索，后来很多BI都在往前扩展，增加了敏捷ETL、数据管理，甚至部分数据仓库的功能。这也是数仓大师Kimball和Ross在大名鼎鼎的“The Data warehouse Toolkit”一书中期待的远景——Data Warehouse/Business intelligence Platform（DW/BI平台）。

从这个角度看，借助于 Data Management add-on增强的Tableau Server，以及结合 Microsoft Purview 的Power BI都贴近这个愿景。而国产BI的相关功能，在我看来还属于不够强大、支离破碎，更难言API开放和自定义。高级用户从某些BI工具背后的数据库系统表就能一窥平台的孱弱。

3、国产BI的关键领域

国产BI目前主要有两个领域：借助于填报弥补“业务不在线”及数据仓库的不足、借助于初中级可视化改善报表展现。 在面对数据建模、结构化分析等需要高度抽象的技艺时，国产工具的表现还很难讲，一些工具甚至抄错了方向，还努力修修补补希望跟上潮流。

目前，各类Report产品对应了业务“复杂报表”的区域（第四象限），这里市场占有率最多的是帆软Report。不过，这个市场趋势只会日渐萎缩，我更希望有其他BI产品能把这个日渐萎缩的市场免费，作为BI的前哨来使用，这将是未来几年不可多得的市场机会。

对于业务分析而言，BI竞争的主阵地则是面向业务的可视化分析。

其中帆软BI目前在市场宣传、客户选择上具有优势（有时候甚至带有“攻击性”，让我不舒服），但大数据支持、高级功能明显不足；近几年的市场新秀「观远BI」则在易用性上略胜一筹，云服务让它的应用集成如同Power BI一样简单易用、极容易与其他平台直接打通，但产品线略显凌乱，高级功能也未能跟上；永洪BI则似乎有掉队的嫌疑，我已经很久没有听到市场上的声音（当然也可能是对方擅长的政府国企领域有较低的曝光度）。

限于篇幅，本文暂不对国产BI做进一步展开对比。

还是开篇的那句话，“没有最好的BI，只有最合适的BI”。

参考文献：

• Home – SQLBI
• https://elias-nordlinder.medium.com/dax-series-1-what-is-the-dax-language-13054dff0ce7
• https://blog.enterprisedna.co/why-you-need-to-learn-dax-a-dax-overview/
• 7 reasons DAX is not easy – SQLBI
• DAX是什么 – DAX圣经 – Power BI极客
• 【致知篇57】DAX CALCULATE vs. Tableau LOD：从SUM+IF条件计算到SUMIF

@喜乐君

Feb 20, 2023 V1
Feb 21, 2023 V2
Feb 25, 2023 V2.1 修改power BI部分，补充第三部分