文档介绍：产品解决方案:数据自助分析平台大部分公司选择Tableau作为可视化分析工具,原因都是基于其优秀的交互、快速的可视化分析,相比起传统的BI系统,它的短平快更得互联网时代的数据分析师青睐。但经过一段时间的使用及功能探究,我们发现tableau其实并不局限于“分析师工具”应用,只要完善了其中的权限功能,tableau大有成为企业级报表应用的潜力。一开始公司购买的tableau软件的初衷是服务于运营和数据分析人员,因此客户端账号的80%都直接分发给运营部门使用;技术部主要基于tableauserver服务器的稳定性、权限管控等方面进行简单的二次开发,而二次开发也仅仅只是把报表页面嵌入到系统当中,通过菜单访问控制、url传参等方式实现权限控制。产品架构图如下:业务流程如下:确定了产品设计方案和流程之后,重点需要攻克的是权限问题。由于tableau自身比较封闭,几乎没有二次开发的可能,因此在实现行级数据权限的过程中完全依赖于Tableau现有功能进行挖掘。经过一段时间的使用研究,我们总结了几套在tableau中可用的行级数据权限方案。,实现报表发布时传入指定参数,如:配置网站权限,则参数会传入website_id_p=XXX。,由于用来传参的字段不能在工作表的筛选器中直接用,传参和筛选用同一个字段会有冲突,因此会copy一个website_id生成website_id_p的字段用于传参。,并将筛选器设置为“仅相关值”。。以上这种方案实现起来最简单,也是官方推荐的方案,并且数据可以进行正常提取。但是也存在一个很致命的问题:因为是通过url传参,因此能够传入的参数是受浏览器限制的,市面上主流的浏览器支持传入的url长度都不超过3000个字符,比如谷歌浏览器。但是业务现状是,超过3000字符的权限类型有很多,该方案并不能支撑所有业务场景。,分别在两个权限表中作为参数插入(该参数是作为URL传用户ID时进行权限过滤的依据);;用户ID传参的方案可以完美实现多维度,多数据权限类型的可视化报表开发,并且可以与第一种URL传参的方式共存(如:url中既传user_id,又传website_id),基本可以实现业务部门对于行级数据权限控制的所有要求。方案也有缺陷,由于是在数据源中就写入参数,因此无法做数据提取(提取的结果为空),可视化报表的查询效率完全取决于