在选择了Tableau作为公司的可视化分析工具之后，由于tableau自身比较封闭，几乎没有二次开发的可能，因此在实现行级数据权限的过程中完全依赖于Tableau现有功能进行挖掘。经过一段时间的研究分析，我们总结了几套在tableau中可用的行级数据权限方案。
一、首先说下大的软件环境：
公司购买的tableau软件主要服务于事业部的运营、数据分析人员，因此客户端账号的80%都直接分发给业务部门使用；技术部主要基于tableauserver服务器的稳定性、权限管控等方面进行简单的二次开发，其实这所谓的二次开发也仅仅只是把tableau发布的报表页面嵌入到公司自己开发的系统当中，通过菜单访问控制、url传参等方式实现权限控制。
产品架构图如下：
二、权限问题解决方案：
把tableau的页面嵌入到系统中后，每个可视化报表也就是一个功能菜单，因此菜单权限的控制完全不是问题，业务部门可以在内部就进行菜单权限的管控。数据权限的实现比较曲折，也尝试过几种方案。
第一种方案：通过url传参，将需要控制的权限类型作为参数带入可视化报表url参数中；
1、在嵌入可视化报表的系统中开发一个小功能，实现报表发布时传入指定参数，如：配置网站权限，则参数会传入website_id_p=XXX；
2、报表开发过程中需要用到事实表中的网站website_id字段，由于用来传参的字段不能在工作表的筛选器中直接用，传参和筛选用同一个字段会有冲突，因此会copy一个website_id生成website_id_p的字段用于传参。（注：copy出来的website_id_p字段可以不用作为字段显示到报表中）
3、显示筛选器，并将筛选器设置为“仅相关值”。
4、发布到server后就可以在server端试验数据权限是否生效。
以上这种方案实现起来最简单，也是官方推荐的方案，并且数据可以进行正常提取。但是也存在一个很致命的问题：因为是通过url传参，因此能够传入的参数是受浏览器限制的，市面上主流的浏览器支持传入的url长度都不超过3000个字符，比如谷歌浏览器。但是业务现状是，超过3000字符的权限类型有很多，如产品分类、仓库，这部分权限无法通过这个方案来支持。因此，我们又苦苦寻找其他方案。
第二种方案：将用户ID作为参数传到url中，关联权限表进行控制；
这个方案的实现分为两个阶段。
第一阶段，我们在后台创建两个数据源，一张是做权限控制的权限表，另一张是数据事实表，用权限表作为主表关联事实表，传入的用户ID的参数控制权限表中所能看到的权限类型，以此来实现权限过滤。但是由于tableau的sql语法中对于两个数据源左关联的操作支持得并不好，因此当事实表有多个维度时，除了第一个维度字段之外的其他维度字段都会显示为“ * ”号，第一阶段到此宣告失败，具体的操作步骤也就不再描述。
第二阶段，还是用传入用户ID的方式，但是选择了参数字段来实现，具体操作如下：
1、编写自定义SQL创建事实表、权限表（这里举的例子使用了两个权限类型，因此创建了两个权限表1和2），并使用内关联；
2、创建一个名为user_id的参数，分别在两个权限表中作为参数插入（该参数是作为URL传用户ID时进行权限过滤的依据）；
3、利用这个数据源开发可视化报表并发布，开发完成后的页面显示如下；
至此，用户ID传参的方案可以完美实现多维度，多数据权限类型的可视化报表开发，并且可以与第一种URL传参的方式共存（如：url中既传user_id，又传website_id），基本可以实现业务部门对于行级数据权限控制的所有要求。当然，这个方案也有缺陷，由于是在数据源中就写入参数，因此无法做数据提取（提取的结果为空），可视化报表的查询效率完全取决于直连数据库的查询效率。
总体来说，作为运营、数据分析师的可视化分析工具，tableau的分析效率高、学习成本低，也是目前市场上大部分数据分析师必备的分析工具，因此引入该工具进来之后业务部门的推广应用比想象中的要快，这也是当初选择tableau的主要原因。在解决了行级数据权限的问题之后，tableau甚至可以作为企业级可视化报表应用的选项之一，希望这些经验能够帮助到其他有需要的朋友。
网友评论