BI领军者之一Tableau试用浅谈

下图是最新的Gartner BI Magic Quadrant，其中领军者之一的Tableau表现的异常突出，执行力象限上直接甩开其它产品一条街，前瞻性象限上略微超越了MSBI，怀着无比的好奇心，特意去Tableau官网下载了Desktop试用版体验一把，从种种细节中能够感受到浓浓的情怀，产品的确极具人性化，甚至官网的教学视频都是略带播音腔的中文语音，但为了客观分析这款产品的用户体验，我没有跟着视频去系统学习Tableau，只是浅尝辄止的拿自己项目中经常要用到的分析案例做些试验，毕竟不是Tableau开发专家，所以有说的不对的地方还请行家指正。

打开Tableau Desktop客户端，首先需要连接到数据源，支持的数据源非常全面，这里选择SQL Server做个ROLAP玩玩，看到，这不就是工匠情怀的体现嘛 :)

我连接的数据源是本地的AW数据库，需要指定几个待分析的表，我拖过去的是DimProduct, DimCustomer, FactInternetSales三张表，因为数据源有完善的主外键关系，所以这里也被正确的识别出表关系，另外，为Tableau随处可见的模糊查询输入框点个赞

看一下工作薄左侧数据源区域，Tableau并不是按物理表来区分维度和事实，而是默认根据表里的字段类型来做区分，用于聚合汇总的数字类型都被认为是事实度量值，其它类型如文本，日期以及主外键关键字都被认为是维度，也有一些字段本身既可做度量亦可作维度，例如UnitPrice单价，这时候是可以把UnitPrice从度量区域拖放到维度区域的。吐槽下数据源树状菜单没有找到"折叠全部"的功能，要定位到具体的字段比较麻烦，只能用查找字段的模糊输入框，还得敲键盘（还能更懒点吗？）。

工作薄中间的内容区域就很像数据透视表了，行上我拖放一个ProductKey, 列上我拖放一个Gender

用Profiler捕捉到执行的查询脚本如下，就是个简单的Group By

这时候在Tableau上做个一键行转列，或者把ProductKey和Gender维度都放在行区域上，观察到Tabular并没有去数据源刷新数据，而是客户端处理完成，也就是说Tableau客户端缓存了结果集，而Excel客户端是不会对结果集进行缓存的，所以Excel做类似的交互操作都必须得去数据源刷新数据，除非手动指定延迟布局更新。

Tableau这种做法有利有弊，利在于节省了重复加载数据的开销，而弊端在于如果数据源数据发生了变化，是无法通知Tableau客户端进行缓存过期，我做了个试验，执行下面脚本更新下数据源，然后再Tableau上进行上述的交互操作，发现Tableau客户端呈现的数据未做相应变更，Profiler也没有捕捉到任何查询命令，直到我在行区域再追加了一个维度，才得到正确的数据，Profilter也证实了数据刷新。那么Tableau至少应该有个手动触发刷新的功能吧，没找到这个功能。。。难道说只能部署到Tableau Server以后才能在页面上触发刷新？

update FactInternetSales set SalesAmount=SalesAmount+1

切换图表类型，这个在Tableau和Excel上都不会去数据源刷新，excel的图表的确不如tableau多样、美观，但tableau貌似是直接把透视表变成了透视图，而不像excel能够同时显示透视图表，并且图表还能互相联动

对ProductKey添加筛选器，还是得肉眼检索，或逐个录入，excel原生功能也是只能如此，而通常BU会希望能一把贴进去一堆sku key（以换行符或逗号间隔），excel可以定制功能来完善这个用户体验，详见XPivot用户手册里的Filter功能http://www.cnblogs.com/xpivot/p/4317706.html，Tabular似乎不具备这样的扩展性

但还是发现一处亮点，按公式指定条件来定义一些复杂逻辑，我假定一个需求是：汇总购买过sku 214或者购买过sku217的会员销售情况， 注意筛选器务必选择CustomerKey维度

生成的脚本有点复杂，这是ROLAP难以避免的问题，工具组织出来的SQL就不要指望性能多优越了，甚至这种脚本表达方式都没多少优化空间，除非in memory rolap，否则应对稍大点的数据量就会非常吃力。建议阅读下这个脚本，以充分理解rolap的工作原理

注意这里的"汇总购买过sku 214或者购买过sku217的会员销售情况"这个需求，不等同于sku 214和217的销售情况，主语不同（前者是分析人，后者是分析sku），分析的结果也完全不同，下图是后者的筛选器设置以及查询结果，注意筛选器换成了ProductKey

我们再来定义个需求，汇总购买过sku 214并且购买过sku217的会员销售情况，脚本和截图如下，筛选器用的还是CustomerKey，可以看到数据查询结果和前两个需求不一样了

max(iif([ProductKey]=214,1,0))+max(iif([ProductKey]=217,1,0))=2

上面的几个示例强调的是筛选器的选择需要格外注意，稍不留神就会用错，例如同样的需求，如果在Gender这个筛选器里设置公式，会发现也能顺利执行，但数据完全不对

追溯到脚本才发现原来是使用了Gender作为子查询关联字段了，BU当然没有这个能力去查看核对脚本，如果不注意是非常容易犯错误的

我又尝试用Tableau访问SSAS MOLAP数据源，Tableau对多维数据库的支持程度不足以实现以上几个典型的需求分析，可能还是受限于MDX的表达方式，工具难以把可视化设置简单无误的翻译成MDX脚本逻辑，显然这个难度是远远大于翻译成SQL的（PS: 对SSAS ROLAP的支持程度理论上来说应该会好过MOLAP吧，这个没做测试）。

由上可见，Tableau的可视化功能足够强大，至少上面这几个需求案例在excel里本身是无法实现的，我在excel BI解决方案里也是通过扩展插件功能来实现类似功能，但不像Tableau这种需要编码的条件组织方式，因为这种编码方式不但门槛略高，而且很容易用错，不适合给BU使用。另外，一些用户体验细节不如excel，找一个功能相对比较费劲，excel通常会把同样的功能做成各种快捷入口，以满足不同操作习惯的用户，不过话说回来，如果excel后续版本也能支持Tableau这种按公式定义筛选器的功能，还是很让人欢欣鼓舞的，至少IT角色的BI工作人员会非常喜欢。

这次试用主要是想体验下筛选器的灵活性，的确有值得称赞的设计，以后有机会的话再体验下传说中强大的计算引擎是怎么个工作原理，会不会是类似PowerPivot的Vertipaq引擎呢？始终认为这类东西就好比傻瓜相机和单反的区别，特定场合的确能够发挥优势，但涉及到针对性的调优就很无力，不如RDBMS的调优空间大，数据从RDBMS到MOLAP引擎就已经丧失了很多调优能力，再放到其它引擎能不能有足够的渠道用于灵活解决性能问题呢？BI产品在做宣传时，总能听到夸大其辞的宣称能够做到真正的BU-Driven秒出报表，故意忽略几个前提条件，其一就是得有一个干净的数据源，事实上绝大多数的业务生产库都不具备这样的前提条件，如果BU真的去业务生产库上做即时查询，别说秒出了，能够做到查询逻辑毫无破绽都是非常困难的事情。至于性能，是否都能做到秒出，取决于硬件和数据源调优，in-memory rolap性能足以媲美molap，如果公司硬通货缺乏的时候也能补充些软实力，可以先把rdbms的调优做好，再结合molap，使两者各擅所长的处理业务问题