【产品对比】非对称之战：Tableau VS. FINE BI-喜乐君-敏捷BI布道师

Apr, 2023
Nov, 2023 Update

客观的说，目前唯一能和Tableau“比肩而立”的BI，唯有微软Power BI；但二者又并非“你死我活”的同质化竞争，而是各有侧重，在各自的方向上做到了最优（可以参考 Tableau VS. Power BI系列文章，参考1）。迄今为止，没有任何一家国产BI的综合功能能和上述二者比肩，甚至难言“望其项背”；如果国产BI厂家不能清晰地认识到自己和国际一流BI的差距，而是任由市场部门大肆宣传“Tableau退出中国、微软退出中国”的假消息，甚至动辄论证“超越Tableau遥遥领先”，这将是对行业客户最大的不负责任。喜乐君尊重竞争者急切地赶超、努力“登堂入室”的心态，但拒绝打着“信创”和“自主创新”旗号的恶意中伤。

喜乐君写下这篇对比文章，一方面是借此帮助理解不断阶段、不同架构的工具之间的差异，另一方面是帮更多人避免市面上某些市场化言论的误导。“桃李不言、下自成蹊”，好产品不需要言过其实的推荐，大肆宣扬的背后则往往暗藏玄机。

2019年，喜乐君曾写过两篇Tableau对比帆软的文章（Tableau 2019 VS FineBI 5.0)，时隔三年，FINE BI6.0姗姗来迟，Tableau全球易帜Salesforce，中国区域取消直营、销售则易手Software One和阿里（参考2）。在这个时间点，基于过去多年项目实践、数据咨询的经验，喜乐君想更加深入地对比二者的差异，帮助更多企业做出明智的、符合当前阶段的选择。

⚠️“帆软”是一个企业名称，其中包含Fine Report，Fine BI、简道云、九数云等多个数据类产品（参考3），本文主要选择“Fine BI”，与Tableau Desktop（参考4）对比，本文暂不对ETL展开对比（优劣过于明显）。
⚠️本文未经Tableau官方及帆软官方，或其他利益相关者审定；未经允许，不得用于商业目的；仅代表个人立场。

一、以终为始：企业到底需要怎样的分析平台？

产品对比的主要目的，是辅助企业或个人用户做出适合自己的工具选择。产品只有差异化特色，既无好坏，更无绝对的第一和第二；但每个企业和个人却又自己的成长阶段，有自己的需求和使命。因此，识别自己的需求，明确企业所处的数字化阶段，有助于做出明智的选择。

1、企业不同阶段对应的BI形态

从企业数据化阶段来看，企业存在如下的几个阶段，对应不同的信息化和数字化工具。

“传统企业”：“传统”一词和行业无关，指业务不在线、数据难以被完整、准确、及时记录的“落后状态”。数据Data依然存在，只是以纸质、零星软件平台的方式存在，无法被直接使用。这个阶段的企业，很容易听信“数据填报就是BI”的市场片面之词，真以为自己走在了行业前列。以国有企事业单位最为明显（容易上当受骗）。
“企业信息化“：Information信息是DATA有效整合的形态，这个阶段企业的典型特征是软件平台众多，最典型的是ERP、MES、CRM等围绕生产、客户的数据采集系统，它们与业务流程直接相关，是数据的收集者和整理者；分析侧重于Report、PPT而非可视化Dashboard，更鲜少探索性问题分析。这个阶段，数据治理成为关键，填报、低代码、RPA等各种补丁用来维持整个系统的运转。整个分析生态往往被IT部门掌控。
“敏捷BI”阶段：企业不在满足于Report、PPT，而侧重于从数据中探索业务问题，这个阶段的典型特征是数据仓库（Data Warehouse）出现，业务系统与分析系统二者分离，同时，业务用户日渐成为分析主力。这个阶段，Tableau、power BI等敏捷BI开始在业务部门中成长起来，分析从IT部门转向业务部门。数据共享中心、精益中心，甚至专职数据分析师开始涌现，并迅速转变过去低效的分析模式。
“数字化企业”：数据成为企业决策的关键环节，从上而下，数据驱动的企业文化日渐形成，并推动构建以数据为中心的业务模式，比如从传统的产品销售到订阅。这个阶段，BI工具得以在业务部门中普及，假设验证成为业务决策的关键构成部分，不同的工具平台、软件相互辅助，共同服务于“业务决策”一个中心。

从上述的阶段分析来看，不同的企业阶段，对应不同的工具需求，对应不同的员工能力。敏捷BI是Business Intelligence，而非仅仅是Business Information，基于这样的认知，BI辅助决策需要包含如下的功能部分：

“数据仓库”：外部数据仓库，或者BI平台自建的Data Warehouse，正如Kimball 和Ross两位大师在Building the Data Warehouse一书中所倡导，DW/BI Platform才能把数据和分析的价值发挥到最优。
从“数据”到“数据服务”：虽然有了DW，但是数据资料并非就必然是数据服务，企业级的BI平台，不仅要支持单表的分析，还要支持主题的分析，此时数据模型、指标定义就成为关键，缺乏这个逻辑层，就难以实现数据准备和业务分析的分离，会制约长期的分析效率。在这个环节，工具的性能是常见的瓶颈。
敏捷分析：面向业务用户、人人可用的分析工具，是数据资产转化为价值决策的关键；分析工具应该支持多种可视化样式、便捷的仪表板制作、综合的交互功能、多种函数特别是高级分析函数，分析结果支持订阅、通知、下载等多种服务方式。在这个环节，图形设计方式和计算是常见的瓶颈。
敏捷ETL：对于数据质量较好，或者IT部门支持充分的企业而言，面向业务的敏捷ETL是锦上添花；但是对于对于数据质量欠佳的企业而言，敏捷ETL更像是及时雨，它有助于弥补数据质量的不足。

基于上述的功能板块，企业首先要实现建立数据采集、数据分析相互独立的分析框架，参考如下的架构所示，有助于理解“大数据可视化分析平台”在企业数据架构中的总体位置。

基于这样的架构，再把DW/BI平台进一步展开为更多的逻辑层次，其中的关键是数据服务（数据资料和通用计算）、可视化分析内容、分析服务。每个部分都可以进一步展开更多的内容，上下贯通、左右相连，共同组成大数据分析平台。

对于不同阶段的企业而言，这个架构的作用会有所不同，传统企业会认为过于“前沿”，它们的首要目标是数据采集，为了满足一定的分析功能，它们会选择“填报类型工具”做补充，并且强调Excel等工具在数据治理中的关键作用。而以IT为主导的信息化建设之下，IT会选择简单可视化工具作为补充，特别是部署简单、方便开发、性能稳定、便于嵌入的产品，像Smart BI。

参考B站视频：短期的“形式”，长期的“主义”——伪BI头牌“填报”

而对于数据质量较好的企业，才会对独立的BI分析工具有所需求，并且期望分析从IT团队转向业务部门——这是business information和business intelligence 的重大区别。同时，这就要求BI工具足够便捷，学习成本过高则业务用户难以普及（比如Power BI），同时功能要足够强大，解决纷繁复杂、灵活多变的探索性问题需求。

当然，更高阶段的工具总是可以向下兼容的，但脱离企业阶段的工具往往难以发挥最大的价值，而且对用户提出了过高的要求。这也是选择工具时不可不慎的地方。明智的企业应该选择略高于当前阶段的工具，而且借助于优秀的软件工具、卓越的咨询顾问实现跨越，而非飞跃。

2、Tableau20周年

2023年，是Tableau公司成立20周年（2003～2023），这个寿命超过了全世界公司的平均寿命，而且在10岁上市纽交所（代码DATA）。创始人是典型的技术派，创始人甚至获得了图灵奖。Tableau在20年前就奠定了最重要的可视化基因，并被后来众多公司模仿学习。

如今，Tableau已经成长为庞大的DW/BI+ai的平台，依然以Desktop可视化为主力产品，2018年推出的Prep Builder则是敏捷ETL的代表，在被Salesforce收购后，Tableau正在加强以Tableau Server为中心的云服务能力。

3、Fine BI发展简史

帆软成立于2006年，成立之初的重点是“报表工具”（Fine Report），当年和润乾有南北分庭抗礼之势（北润乾南帆软），后来以持续的产品和市场力量几乎占据了中国报表的半壁江山，如今也是帆软最重要的收入来源。

帆软BI首个版本开始于2013年（参考资料：“到Fine Report站稳脚跟后，大概是2013年了，我们意识到需要拓宽赛道，就顺应市场需求推出Fine BI产品”）。大约在同一年前后，Tableau开始进入中国，逐渐吸引了一大批忠实客户。帆软BI早期版本并未有明显出彩之处，甚至5.0版本都难以被普遍接受，不得不在2021年全面重写架构、推翻重来（参考资料），至少从形式上更像Tableau。在我看来，产品实力依然显著落后于国际同行，特别是数据引擎、关系主题模型、高级交互和高级计算等方面。

在2023年，帆软BI才姗姗来迟地推出测试的Saas云版本，显著落后于其他厂商。

在国产报表和BI细分行业，帆软也许不是产品力第一的企业，但绝对是“营销力”第一的企业，你甚至会感觉到一种用力过猛的感觉，这种力量反过来推动了“自我感觉良好”的氛围。

二、非对称之战：Tableau和FineBI

虽然Tableau在被Salesforce收购后，发展态势有所减缓，但目前还没有工具能撼动它在业务用户中形成的“敏捷自助分析”的行业地位。因此，Tableau和Fine BI的比较，注定是一场不对称的较量，在一开始胜负既分；不过，接下来的比较，依然有助于用户了解BI的能力组合，从而评估自己的所处阶段，和所需的工具。

1、数据接入和数据建模

数据连接是分析的起点，看似简单，实则关联着整个分析世界。它的左侧是数据准备（输出高标准的数据表），右侧是数据模型（提供跨单表的主题分析）；同一个计算在两侧也会展现为不同的样式，这既是ETL和可视化的分界线，也是Power BI中“计算列”（calcualted columns）和“度量值”（measures）的分界线。

这里先仅仅说右侧的部分，按照复杂程度，至少包含单表连接、多表合并、多表匹配、数据模型四个环节。其中前面两个是所有工具的通用基础，后者两个是工具之间的差异化所在。

从功能的位置和设置来看，FineBI6.0更像Power Pivot，它们都把行级别的数据合并（并集/上下合并，连接/左右合并）单独处理，而把多表关系置于分析之中，而不像Tableau可以在在一个界面中以逻辑层、物理层整合在一起。

功能/工具	Tableau	Power BI	FINE BI6.0	备注
1、单表连接/自定义SQL	☑️	☑️	☑️	入门必备
2、多表合并（Union/JOIN）	☑️	☑️ Pivot	☑️自助数据	入门必备
3、多表关系（relationship）	✅✅ 可多事实表	✅✅✅Pivot 多事实表共用维度表	✅ 关联视图
4、包含合并和关系的Model	✅✅	✅	❌	不是所有的关系默认是数据模型
5、数据混合（临时关系）	✅✅✅混合	✅Treatas函数	❌	PBI代码学习成本极高

可以用一句话形容Tableau中的关键功能：相同业务场景用Union并集、相近的业务场景用Join连接、相同的业务主题用Relationship关系、跨业务主题用Blend混合。

1）基本功能对比

Fine BI 6.0的“关联视图”提供了上述多表关系的设置选项，不过官方说明该功能主要用于“权限控制”（也许是我理解了这个文档，参考5），这句话误解了“关系/关联”在数据分析中的重要性。当然，这也许意味着，它可能不能很好地支持多个事实表；同时，如果你要构建一个包含“行级别合并、多表关联”的数据模型，可能也很难达到你的预期。特别是它没有默认的基数设置，必须配置，但这恰恰是业务用户的技术瓶颈。

真正的数据模型，不仅仅是支持多事实表的多种合并、关联方式，而且要考虑业务需求，在最为详细级别的级别、在业务上有意义的级别建立关系，而且可以是多事实表的关联关系。所以，数据关系（帆软称之为关联）只是“数据模型”的前提，但并非等价。

在Tableau中，数据关系向下兼容行级别的数据合并，二者构成了“物理层-逻辑层”的层次关系；这个过程可以在Desktop的数据源阶段完成，不像Power BI一样需要跳转到Power Pivot中单独完成（这里先不说Pivot使用了单独的M语言）。

当然，数据合并并非仅仅上面提到的几种，其实数据合并是一个庞大的功能组合。喜乐君在《数据可视化分析2.0》一书中总结了“数据合并的分类矩阵”，如下所示。在这里，明细表级别的合并是入门功能，为所有工具普遍支持（包括excel）；问题或者说聚合级别的匹配，以及数据模型的支持度则是BI工具差异化所在。其中难点在于关系的支持度和向下兼容程度。

在关系上，Power BI的表模型是巅峰，而在混合上，Tableau的拖拽混合绝对是优雅、易用之巅峰，无出其右。这也是国产BI普遍的弱点——国产BI往往还在行级别的合并、连接上用力，逻辑层次的关系功能都泛善可陈，甚至严重不足。

2）Fine BI中缺失的关系场景

随着关系的类型越来越细化，工具之间的差异就会暴露无疑。包括数据源的类型、连接的方式（实时/提取），又都会对数据关系的设置构成明显的影响。Fine BI甚至对与Excel合并的实时数据库有一定要求（参考6）。

按照位置区分，关系又可以分为数据源阶段的稳定关系（relationship）和问题阶段的临时关系两种情景。

按照数据表特征区分，关系又可以分为事实表+维度表的简单关系，和多事实表的高级关系。

在部分业务问题中，我们甚至会遇到临时性的关系，比如销售过程转化分析中完成“不同年月的转化率”，此时需要从两个表中获得不同日期对应的的不同聚合。这种既临时性，又聚合后关联的匹配，就对产品提出了更高的要求。在Tableau中，可以使用混合（blend），而在power BI，则有“非活动关系”可供借鉴。

网络图片：采悟（认识Power BI中的非活动关系和USERELATIONSHIP函数）

从上面的介绍可以看出，目前Tableau在数据关系模型最为友好，临时关系也用混合的方式变得异常友好，当然也存在无法使用共享维度等问题（已经列在开发计划）；Power BI的关系模型则最为专业，甚至支持环形关系，适合构建宏大的主题分析，当然这也意味着几乎只有IT专业用户才能完全驾驭。

相比之下，Fine BI6.0只是解决了之前没有的“关系匹配”问题，但在多事实表关系、从关系到模型、临时关系、数据支持度等多个方面，都还存在改进的空间。这也意味着，它目前很难被用于构建宏大的“数据主题模型”，这就限制了从数据到数据服务（data service）的支持度。一个完整的数据模型，既要高屋建瓴地支持指定详细级别的预先匹配，又要向下兼容行级别的数据合并，还要考虑一些“模型”之外的临时性关系。

如下所示，喜乐君绘制了一个通用的关系模型，包含了数据合并、数据模型的常见概念。

当然，Tableau在数据模型方面也有不足，比如不支持“网状结构”，暂不支持“共享维度”（shared dimension），也不像DAX那么“高级”（可以在代码中任意引用）。不过，面向业务用户，它已经做到了最佳的平衡，高于、但又没有高于太多业务用户的理解能力和业务场景。对于业务用户而言，想要掌握DAX背后的Related、Related Table、treatas等函数，需要极高的逻辑抽象能力方可实现。

2、数据可视化和仪表板分析

在数据接入或构建必要的模型之后，就进入了可视化分析的范围。可视化绘制的易用性（50%）、交互和仪表板探索（35%）、高级图标的支持度（15%）就成为主要的考量因素。

首先，我想强调的是，业务分析中可视化图形不是“因人而异”的主观设计，也不是追求“形式主义”的设计美学，而是追求以最佳的可视化样式帮助业务领导获得信息、做出判断。这个过程的背后是心理学、决策体系，是有原理可循的科学。所以，基本上可以认为，可视化图表的最佳样式、框架基本是客观的、预设的；分析师只能在这个框架基础上做补充、完善。

举个简单的例子，要分析“产品的销售额”，基于单一的销售额字段，首先要考虑的就是条形图，如果产品非常多就要考虑分布，这可以视为是确定性的思考范式；如果贸然用饼图、气泡图等，都会让展现走向“形式”，而非业务分析。

其次，业务可视化有两个重点：从问题到最佳可视化图形、多个可视化图形的交互设计。

只有最佳的可视化图形，才能顺应观众视觉上的“潜意识属性“；避免像3D、阴影、复杂动画等不合理形式带来的干扰。而在纷繁复杂的业务探索分析面前，交互赋予可视化仪表板以灵魂，最常见的交互是筛选、高亮，辅助性的有跳转、导航、下载等，高级形态则是借助变量（参数，或集合，或数组，或参数表）而来的高级交互，代表性的有Tableau中的参数动作（parameter action）、集动作（set action）和动态对象可见性（dynamic zone visibility）。

基于这样的考虑，我们来看一下“可视化领域的梵高”——Tableau，和国产BI的代表产品——Fine BI的对比。

1）可视化的设计架构（Tableau VS. Others BI)

Tableau最以为傲的可视化架构，来自于斯坦福大学几十年前的Polaris项目，其核心内容曾发表在communications of the acm等多篇专业期刊中。二十多年的中国，还鲜有BI产品能用类似的科学理论去支撑自己的产品设计，更多的是“拿来主义”的开源组件，和锦上添花的“自研算法”。在可视化BI领域，由于Tableau如此卓越、超前的设计理念，很多人甚至说，世界上只有两种BI：Tableau BI 和 others BI。了解背后的原理，你会知道此言虽然“过誉之嫌”，但也印证了Tableau可视化的卓越能力。

【致敬Tableau20周年】分析工具篇SQL、DAX、VizQL（上）

在这篇论文中，作者介绍了Tableau原型的数学基础，并根据字段的维度/度量、离散/连续/次序特征解释了“通用可视化框架”的可能性框架，并用拖拽的可视化界面实现了用户的“所见即所得”。Tableau20年后的今天，这个界面只有必要的调整，确无本质的变化；它的持久生命力，就在于Tableau对字段的特征分类上，特别是连续/离散的分类。

相比之下，不管是Fine BI，还是Power BI，甚至于观远、Qlik，都没有像Tableau一样对字段设置默认的连续、离散属性，这就意味着，字段的显示样式难以被“预设”。可视化的基础是笛卡尔空间，笛卡尔空间依赖于坐标轴，坐标轴基于连续性的字段才有意义。

基于这样的字段属性，不管是拖拽Tableau中的字段，还是双击、多选，Tableau都会根据字段特征推荐可用图形和最佳图形，背后是“问题——字段属性——推荐可视化”的技术逻辑。在“智能推荐”（show me）中，只有聊聊十几种图形，既是对业务应用的抽象概括，也是Tableau自动推荐图形专利的绝佳应用。

如下所示，Fine BI6.0和很多BI工具一样，列举了很多种图标类型，包括常见的条形图、饼图、折线图，也包括一些业务中使用较少的雷达图、桑基图、漏斗图。从可视化的绘制来看，Fine BI既借鉴了Tableau最为经典的多层“标记”设计理念（为每个度量轴对应一个“标记”），又使用了类似于Power BI的初始模板路线，因此不同的图形会看到不同的设置选择题。同时，还强化了帆软最为擅长的“报表类图表”，可以是说融合了多个产品的特色。

基于上述的对比会发现，对于不对字段做连续、离散分类的BI工具而言，“构建可视化”之前就需要增加人工的选择环节，变成了“问题及其字段——人工选择合适的图形——在可视化框架中填入字段”。为了提高这个“人工选择”的效率，各类工具就开始内置多种图形模版，这在方便业务用户的同时，也让工具失去了通用性和灵活性——无法完成超过预设模版的其他图标。为了弥补这个不足，像Power BI就会开发扩展，并运行用户上传图表模版。

可见，基于字段特征的智能推荐，和基于预设模版的选择设置，代表了两条可视化逻辑、两类BI工具范式，各有利弊、各有千秋。对于业务用户而言，Tableau的方式智能化程度高、灵活易用、可视化图表没有“上限”，但对字段理解要求高、容易让新用户无所适从、高级图表难以实现；Fine BI和Power BI的方式更“傻瓜式”、对高级图表支持性好，但也缺乏灵活性，阻碍了业务用户的探索精神。这也是喜乐君特别喜欢Tableau及其背后方法论的原因。

更多可视化逻辑方面的内容，欢迎参考：【工具对比】Tableau VS. Other BI可视化路径差异

2）仪表板交互设计

Tableau中“工作表/图表——仪表板——故事”的三层叙述方式由来已久，算是业内较为通用的框架，不过BI领域普遍使用的是“工作表/图表——仪表板”的双层框架，不管是帆软、观远，还是Power BI。随着Fine BI6.0对产品结构做出了两大调整（数据源-内容，工作表-仪表板），它和Tableau在仪表板组合方面的差距在缩小（很明显有明显模仿的痕迹，但Tableau架构确实是经过市场考验的好体系），但在交互方面较少有“几座山”的遥远距离。

我们先来看一下Fine BI6.0中自带的“图表实用场景”仪表板，如下所示。下图左侧显示了仪表板中可用的组件类型（图表、过滤组件、其他），右侧每个图表旁边则有常见的设置选项。拖入的组件默认“拼接”，具有自动磁吸功能，也可以改为“悬浮”。

工作表的关键是如何选择可视化图形类型，仪表板的关键则是图表、组件的布局和交互。

Fine BI的组件相对简单，默认分为三类：可视化图表组件、过滤组件、其他（tab组件、图片、URL页面）。Fine BI的仪表板可以对比Power BI的页面，它们都没有“容器类型”的组件（像Tableau的水平、垂直），设计师难以预设布局，拖拽组合的体验很难说优秀；相比Power BI，Fine BI的磁贴提示不够明显，很容易让新用户“抓狂”。

相比之下，Tableau既显著地强调了“平铺”和“浮动”两类布局方式——平铺始终占满整个画布，哪怕只有一个工作表；浮动则完全自定义，适合于草稿设计；又区分了“容器对象”和“内容对象”——内容对象和筛选对象可以非常方便地置于容器之中，这种“容器-对象”的双层布局在复杂页面中非常实用。

当然，Fine BI和Tableau在仪表板方面，最大的差距在“交互”。

在上面的实例仪表板中，我们发现Fine BI只有过滤、联动、导出Excel、跳转等极其有限的交互功能，再把参数也视为仪表板交互功能之一（虽然我找了半天也没发现如何直接把参数添加到仪表板），我们发现依然是极其单薄的。

在仪表板交互中，最基本的交互是筛选（针对的是字段），其次是导航、跳转、下载（通常针对的是仪表板或单个工作表），不同BI工具在后者上的表现能力大同小异，能力差异体现在筛选上。如同小学计算可以直接口算、大学计算需要借用变量甚至方程求解一样，交互也可以按照是否依赖于“变量”（variables）分为基本交互和高级交互两大类。如下所示：

在Tableau中，用户可以极其方便地创建筛选、设置筛选，并通过“操作”自定义筛选的起点、终点、筛选字段及交互方式，同样的深度自定义却没有出现在Fine BI产品中。更远的距离还在于，分析师能否在仪表板中方便的引用单值参数（parameter）和多值参数（集set），并做深度的自定义，这在标杆分析、基准对比等案例中非常重要。类似的案例，我任意就可以讲解十个之多，借助于敏捷的交互能力，探索性分析才会成为现实。

当然，基于变量的交互要想变成实现，必须依赖于计算的支持。Fine BI在交互上的孱弱，与产品的函数能力弱有直接的关系，特别是窗口函数和组合函数等包含聚合的高级函数。

3、计算体系和分析深度

说到计算，BI领域的两大高峰是主打易用、通用路线的Tableau计算，和以专业、高深见长的Dax语言（Power BI）。Fine BI的计算，目前还卡在基本计算和高级计算之间，并未找到适合自己道路的计算体系。

工具的计算能力基本可以通过内置函数（built-in functions）体现，函数是最优算法、最优路径的程序固化，实现了产品经理和软件工程师对分析的理解。在DAX中，我们可以看到精湛的表模型、表操作计算；在Tableau 表计算和LOD详细级别表达式计算中，可以看到聚合的二次计算逻辑——这些都是分析计算的精华。

在Fine BI中，我们可以看到如下众多的函数，但在最重要的高级计算函数上，只有寥寥几个窗口函数，和6.0版本新发布的DEF函数。

聚合是分析的本质（喜乐君），直接聚合函数是所有BI工具的标配，但聚合的二次计算则并非被每家BI所支持，就像窗口函数并非适用于所有的数据库管理软件一样（Mysql直到8.0才支持，Power BI也晚至2024年才会增加）。

SQL

通用性计算，全代码化

数据准备：字符串、日期
通用计算：算术、逻辑计算
分析：聚合函数、窗口函数
表操作： SELECT及嵌套子查询

代码、灵活、可控

Tableau

SQL+拖拽即席计算

数据准备：字符串、日期
通用计算：算术、逻辑计算
分析：聚合函数、表函数🌹
【差异】组合计算：LOD表达式

通用性强、可视化拖拽

Fine BI

基本计算+类DAX高级计算

数据准备：字符串、日期
通用计算：算术、逻辑计算
分析：聚合函数、快速计算
🆕DEF表达式（瑕疵）

通用性差、高级函数不足

1）表计算（窗口计算/快速计算）对比

聚合的二次计算，代表是合计和排序，SQL可以使用SUM(SUM([measure])) 实现，并用over (partition by A order by B)来精准控制。类似的操作，就是BI工具走向高级的必经之路。

Tableau的表计算（table calculation）脱胎于SQL的窗口函数（window calculation），但又有明显的改造和升级。它以其易用的配置，众多的函数，帮助SQL向业务用户普及了“聚合的二次分析”这一高级场景，帮助业务用户快速实现同环比、排序、移动平均等以往难以实现的题目。它的改进主要体现在两个方面：

为窗口函数增加了可视化的操作——通过选择“计算依据”，直接生成over后的partition by和order by
通过参考线、分布分析、趋势线等模型化工具，简化了表计算的自定义难度

反观Fine BI，它的“快速计算函数”几乎走向了SQL和业务用户的反面，提高、而非简化了二次分析的难度。这里以ACC_SUM为例，它的官方说明如下：

ACC_SUM(x_agg(array),range):根据横纵轴或行列维度添加的字段对指标进行跨行累计的计算。

• 参数说明第一个参数为用户计算的指标，该指标必须为聚合函数或聚合指标。第二个参数range为用户设置计算的范围，0为对所有行进行累计，1为对组内所有行进行累计。

• 示例 acc_sum(sum_agg(array),0)用户横轴轴拖拽销售日期（年分组），则该指标计算结果为，根据销售日期（年）对销量进行分组汇总，然后根据对所有行从上到下进行累加，获得每年的累计销量。
帆软BI帮助

你会发现，Fine BI借鉴了Power BI的程序化设置方式，而非分Tableau的可视化设置方式，采用0和1控制范围（partition by），这个逻辑完全阻碍了业务用户的理解和便捷使用。如下所示，当在横轴、纵轴中分别有分类字段时，对聚合值的排序就极其容易走向歧途，归根结底，Fine BI既没有像Power BI一样能实现精细化的代码控制，也没有像Tableau一样实现相对/绝对随意切换的依据调整。这就让高级的分析函数失去了它应有的灵活性。

如果看函数的体系，你会发现Tableau的表计算体系及其接近于SQL窗口函数，同时做了一些精细化调整，尽可能避免业务用户的代码操作，工具应该让复杂的问题变简单，这才是敏捷BI应有之义。如下，展示了排序函数的对比。

除此之外，Tableau还有WINDOW系列函数（典型如WINDOW_AVG）、偏移计算函数（LOOKUP/PREVIOUS/FIRST/LAST）、索引函数（INDEX）等多个表计算函数，可以和SQL的SUM(SUM ()) 窗口函数、LAG/LEAD/ROW_NUMBER等多个函数对应，这种继承既降低了工具之间的转换成本，也确保了理解上的通用性。

据power Bi方面的通知，它们将在2024年发布类似于SQL窗口函数、Tableau表计算函数的功能，增加WINDOW_X为代表的窗口函数。这是非常重要的内容，要知道，这个功能Tableau已经发布远不止5年（从我开始用Tableau就已经存在），国产BI很多都还没有搞情况如何取舍（比如多加国产BI工具保留了明细行级别的开窗计算）。

2）LOD详细级别表达式VS. DEF表达式

DEF表达式是Fine BI6.0新增加的高级函数（应该是取DEFINE之义），旨在实现“指定粒度的聚合”。虽然语法看似解决Tableau LOD，其实逻辑上更像DAX语言中的Calculation 和LOD函数的结合体，这种结合就有利有弊。它的表达式如下：

DEF (聚合, [维度1,维度2,…], [过滤条件1, 过滤条件2,…])
FINE BI6.0

上述的计算，对满足过滤条件下的明细行，计算指定维度组合的聚合计算。比如DEF(sum_agg(购买数量), [产品], [是否会员 = “是” ])，可以计算会员在产品分组下的购买数量。第二、三个参数可以缺省。

在这个DEF表达式中，你可以看到LOD和DAX CALCULATE两类顶级表达式的影子。

Tableau LOD表达式：{FIXED [产品] : SUM(购买数量) }
DAX CALCULATE表达式： CALCULATE（ SUM(购买数量) , FILTER( [是否会员] = “是” ) }

在LOD中，筛选条件需要嵌入SUM之中，或者在外部添加上下文筛选器，它用计算优先级（Operation Orders）解决过滤过滤的问题；而在CALCULATE中，它只有聚合和条件两个部分，维度条件可以直接放在视图中，或者写入FIlter之中。

从结构上，DEF定义表达式之时，同时采用了两家顶级BI的最佳表达式的特征，然后努力融为一体，正因为此，帆软的市场伙伴应该会说，“DEF既比LOD强大……，又比DAX好用……”。我真不知道他们哪里来的信心，只能说“无知者无畏”。

问题也处在这里，1+1并不总是大于2，特别是不同质的物种拼凑出来的高概率“不伦不类”，最终失去了它最重要的特色。DEF表达式追求功能上的完整性的同时，也提高了用户的使用难度，严重制约了底层的计算性能。一旦数据量筛选，或者计算逻辑略微复杂，计算性能就变成显著的问题。

所以，在我看来，FINE BI的DEF表达式，更像是“农民起义”，是对一次参考、借鉴的“草创”，一次高级分析的“冲锋”，但是限于企业整体的分析理解和水准，还需要很多次的持续努力，才能有所成就。如果要真正地实现对两大表达式的融合，Fine BI至少要弥补如下的短板：

计算的优先级设定和调整：筛选的本质是计算，计算必有优先次序。Tableau通过功能预设、上下文筛选等方式调整次序；DAX通过计算列、度量值，以及Row Context、FIlter context、上下文转换（context transform）实现。帆软中没有这样的自定义设定，让它在复杂问题中，要么走向逻辑上的复杂，要么走向性能上的孱弱。
底层模型优化：DAX的Calculate中FILTER并非我们习以为常的筛选条件，它是基于条件的表模型（table model），FINE BI没有这样的底层模型，对不符合过滤条件的也会执行同样的计算。
计算与视图的关系处理：计算服务于视图聚合，计算与视图中已有的维度、过滤条件的关系，是高级计算的难点，当然，背后的本质依然是“计算优先级”。Tableau的处理逻辑简单，Power BI的处理逻辑复杂，各有优劣。

表面上，DEF是学习Tableau LOD，却又结合了DAX Calculate的逻辑，却没有想到自己既缺少Tableau计算优先级的设定，又缺乏DAX中表模型的基因。考虑数据支持、计算性能，我只能说DEF表达式并非大家想象的理想，距离高效的商业应用还有很长很长的距离。

4、性能与“企业级”技术支持

说到性能，不得不提Tableau的两大基石：专利技术VizQL可视化渲染引擎，和Hyper列式数据引擎。它们是Tableau所向披靡的关键，是无可匹敌的可视化效果，与支持企业级TB、PB大数据的基础力量。

一直以来，国产BI一直在努力模仿Tableau的可视化渲染引擎，可以说样子上已经有了七八成相似，不管是“像素级”模仿的有数BI和永洪，还是骨子里学习Power Bi、嘴上说超过Tableau的Fine帆软BI。

但是，没有一家工具可以达到Tableau的高度，为什么？

因为“形像神不像”。

不管是帆软、永洪，还是观远，甚至Power BI，你会发现大家都在字段的抽象分类上采用了偏向技术的路径，强调数据类型（比如帆软只有3个数据类型）、强调维度-度量分类（有时候还用了指标这样的唬人之词）。但没有强调真正支持可视化框架的连续、离散分类。这让各路工具在可视化展现上，都没有达到Tableau的高度。

另一个影响企业级别支持的则是数据引擎。

对于企业及BI而言，BI毫无疑问的适合数据仓库整合方可实现最大功力，也就是必须以DW/BI的一体化平台方式看到BI。新秀的BI公司比如观远会选择Spark等最新的技术，帆软则从努力被淘汰的Cube艰难地切换到新技术，却至今未能迈过亿级数据的门槛，几十万的导入、百万千万级的数据连接也会出现严重卡顿。

归根结底，Fine BI为代表的BI，只是前段的展现层，难以与数据仓库、数据集市整合在一起，这就迫使企业不得不在数据中台阶段加大投入，预先完成各种中间表、聚合表、逻辑视图、ETL，这反过来进一步加重了体系的脆弱性，让数据一致性、准确性、完整性成为巨大的挑战。

相比之下，Power BI从设计之初就建立了超级强大的表模型（tabular），Tableau中迈向企业级支持路上收购了Hyper先进技术（和SAP HANA同出一处）；而后起之秀的国产BI也得以享受Spark等计算引擎的先进技术实现不错的成绩。

如果考虑到服务器集群等方面的支持，国产BI更有漫长的道路要走。

5、综合比较小结

本章从三个视角，重点比较了Fine BI和Tableau的差异，并间接提及了与业内领先、更为相似的Power BI，虽然还有更多的主题、更多的要点做详尽对比，本文也不在展开，否则就变成了更佳复杂的“技术测评”。

在每个主题，假设以相对最优的产品为基准，我们可以粗略的估计另外两个产品的相对得分。个人观点，如下所示。

对比主题	FINE BI	Tableau	Power BI
数据合并与模型	5 分高级关系不足，模型不足	10分（基准）临时关系易用共享维度不足	9分抽象度高、高可定制，学习成本高
可视化与仪表板交互	6分基本图形和高级图形灵活性差、交互功能不足	10分（基准）通用性最好交互功能齐全	8分图表模版丰富缺乏自动推荐，参数等高级交互难用
计算和高级分析计算	5分基本计算，高级计算弱表计算难以控制 DEF计算体系欠佳	8分表计算易用、LOD强大缺乏表操作函数（转ETL )	10分（基准）计算功能强大、函数齐全技术要求高、门槛高
性能和企业支持	3分本地支持尚可，大数据性能明显不足；集群支持能力弱。	10分（基准）无限服务器扩展，超大数据量支持，专利引擎速度	9分表模型强大，支持网状结构，云服务优势；学习难度略高
总分	19	38	36

虽然说，没有一个最优的产品，但是在不同的方向上，总是有相对最优可选，比如IT方向希望的高级、代码、高度可控、确定性，比如业务方向倾向的易用、灵活、“所见即所得”。Power“向左”，Tableau“向右”，它们都在自己专注的道路上做到了相对最优。Fine BI则希望扎根传统的Report经验、借鉴彼此的优势（特别是Power BI），为中国的数字化客户提供更易用的选项，希望它在这条路上能保持自己，同时有所“差异化”。

站在业务的角度看，Tableau可以作为“DW/BI+ai”平台使用，是企业敏捷BI、业务可视化探索的最佳选择，Fine BI在可视化探索分析、高级计算、数据模型等方面还有欠缺，更适合于对已有数据的总结性分析，生成Report或初中级可视化，或者复杂报表、大屏。对于尚未完成“信息化”，或者有大量管理数据需要“电子化”的企业，则适合选择支持填报的Report工具。

三、“所需”与“所予”：我们需要怎样的国产BI？

在从多个角度对比了Fine BI相对于Tableau（以及Power BI）的距离之后，我们可以随之思考：处于不同发展阶段的各类企业，到底需要怎样的“BI工具”？站在“国产BI”的角度则是，在两大BI巨头之间，应该走怎样的“差异化”路线，才能真正赋能数字化转型路上的企业和个人？

首先，我尝试从一名业务用户、一名数据咨询顾问的角度现身说法，聪明的业务用户需要的是既能解决当下问题，又能引领自我能力提升的产品。过度迎合客户而设计的产品，虽然可能是你当下的“优选”，但同时也会早早地决定个人能力的天花板。因此，优秀的敏捷BI应该既简单易用，又有近乎无限的成长边际，在专业性和易用性上保持平衡，才有助于帮助用户建立在职场中的竞争力和职业壁垒。

其次，从企业的角度看，企业追求“投入产出最大化”，软件、服务和人力都是直接的成本，企业最宝贵的是时间，“用金钱换取时间”是企业的典型策略，所以产品价格不是唯一考量要素，和成本价格足以匹配的产出价值才是关键。同时，企业软件瓶盖应该考虑兼容性，未来企业的数据服务将越来越像财务共享中心，将是一类企业资产中心。

“未来已来“，只有对那些充分理解、并融入数据世界的个人和企业而来，才有可能。在数字化的世界，我们用技术和工具换取了认知和见识，提前看到了其他人看不见的世界和道路，从而实现了领先。作为类似“数据”的逻辑体，“金钱”只是认知能力的逻辑上的“变现”，对于个人、企业都适用的。

从这个角度，回到第一部分的问题：“企业到底需要怎样的分析平台”，每个人心中会有差异化的答案，但又具有很多的相似性。这个相似的部分，应该是通用软件平台要努力打造的部分；而差异化的部分，则是企业胜出的关键点。从企业获取、整理和利用数据的解读看，企业数字化需要建立在如下的能力和工具基础上：

信息化工具：实现业务在线、管理在线、行为在线，典型如ERP、OA、日志管理系统。
数据仓库：视“数据为资产”，需要确保妥善的保存、整理和预先处理，这就是DW/ETL工具的价值。
BI平台：实现数据到决策的“最后一公里”，数据借助于分析转化为价值决策。

从前往后，技术的复杂性、确定性的东西在减少，业务的抽象程度、主观性的认知在增加。真正的BI平台绝非是“填报”和“复杂中国报表”，甚至不是“大屏”——我甚至把这三个功能视为是影响数字化进程的“三大毒瘤”；真正的BI平台应该侧重数据整理、逻辑加工、知识变现，其中的关键是敏捷ETL、业务“指标”、可视化探索，它们才是数字化进程的“启迪者”。

所以，从未来相当长的时间段看，数字化企业需要的是DW/BI一体的平台，同时要求能赋能客户的平台。这些系统化的能力，可以被优秀的企业整合，成为超级服务。在近期的某次客户培训中，我就系统介绍了如下的工具能力和关键架构：

敏捷分析知识体系（喜乐君）

从这个角度看，我向来不支持那些主打填报、复杂中国报表和大屏的企业，虽然它们看似热闹非凡，但它们已经几近未来的尘埃和过客。我对能认真钻研业务逻辑、耐心打造精品、为客户提供咨询价值的企业则心怀敬畏。它们的代表可能是：

SAP/Salesforce：未来的SF如同昨日的SAP，将是云世界的业务流程重塑者；
Excel/Tableau：未来敏捷分析工具的地位，就会像今朝的excel一样普遍，认知能力和工具齐头并进。
麦肯锡/IBM：为客户提升价值，帮助客户更真切地触碰未来的咨询顾问。

相比之下，目前国内优秀的BI企业，要么过度迎合客户需求，要么失去了差异化的思考，走向“拿来主义”和“形式主义”，未能在科学的、客观的体系框架做出有价值的创新性研究，形成自己的差异化硬实力，因此，我个人对“国产BI”未来几年的发展依然持比较保留的态度。在这种情况下，充分地利用Tableau、Power BI这类优秀工具，更能保持“数据心智”上的“年轻态”，更能触碰未来，把握未来。

参考文献：

Nov 6, 2023 更新第一部分

【产品对比】非对称之战：Tableau VS. FINE BI