2021年11月，有着BI鼻祖之称的Tableau宣布退出中国市场，停止在中国的直接经营活动。而这个消息也引发了Tableau的国产化替代潮流。本文以有数BI为例，介绍了某公司替换Tableau的过程。

　　该公司经过十多年的积累，已形成强大的营销网络，孵化出多个品类领导品牌。在此过程中，公司十分重视数据平台的建设。随着Tableau退出中国市场，公司选择了有数BI作为替代升级方案。

　　该公司的大数据应用体系是通过对Tableau产品的高度集成，融合了各大事业部、品牌的数据可视化门户系统，通过自研的权限引擎、集成底座，接入了公司各业务系统的数据。

　　该应用体系对可视化工具提出了要求，需要支持报告级别的权限参数传递、快速的图表响应能力、符合平台风格的视觉设计。

　　在数据开发侧，数据开发人员已经习惯Tableau的设计、开发特点，对可视化工具来说，也需要具备操作简单、设计便捷、类Tableau操作、数据处理等能力，以便适应大量报告的迁移工作。

　　该公司的大数据应用体系作为唯一的权限设计中心和用户入口，所有的底层工具都必须适配大数据应用体系的权限体系，这是对有数BI提出的刚性要求。

　　举例来说，公司内的业绩分析报表，当用户身份为事业部A的时候，则仅能看到事业部A的数据；若用户身份为集团高层，则可看到全部数据。

　　有数BI的做法是针对数据源配置用户可查看的数据范围，这样用户查看的时候，就无须针对每一个报表一一配置权限。但该公司的大数据应用体系特色是有可能出现单一用户多个身份，因此大数据应用体系的用户权限会根据查看的报告不同而发生变化，因此需要报告级的灵活控制方法。

　　针对场景特色，有数BI提供了全新的报告级别权限参数控制体系，通过全局参数的形式来传递权限，使得大数据应用体系在极小的改动成本下集成了有数BI的可视化报表。

　　不仅如此，有数BI还改进了原有的权限参数直接在URL上暴露出来的缺点，将参数本身加密到token内，从而保证传递值不被篡改，确保数据安全。

　　让Tableau最为自豪的是hyper自研数据引擎，该引擎提供了数据提取能力，并提供了高性能的数据响应能力。

　　以该公司某一数据集提取至hyper为例，经过测试，该数据集由5张表组成，最终形成的宽表字段数量约为150个，数据量为3400万，以此数据集制作了dashboard（包含6个指标卡信息、2张表格信息以及折线图和柱状图信息）。

　　经过多次测试得到的报告的整体平均完成响应时长为3.1秒，同比Greenplum的分布式数据库的性能提升了10倍以上，也远远优于直连的Oracle数仓。

　　有数BI的做法则是采用了基于clickhouse的自研动态物化视图技术,基于动态分区和字段索引能力,能够在性能上对标Tableau hyper，同时具备高可用特性。

　　该动态物化视图技术是有数BI自身会自动识别及提取报告使用的字段血缘，自动对数据集建立物化视图，从而加速报告查询，而该物化视图的生成、查询、销毁等生命周期的管理都由系统本身进行管理，无需人为干预。

　　通过动态物化视图技术，有数BI提取的数据量级达到了 278 GB（还在继续快速增长），管理了70个以上的物化视图，前10个物化视图的数据量级都在2000万以上，最大的单个数据集为8GB，数据量级为7000万以上，但查询响应能力仍然在3s以内。

　　该公司的大数据应用体系作为集团面向业务用户开放的唯一数据可视化平台，需要遵循统一的视觉规范管理。在使用Tableau的时候，视觉规范基本上依靠数据分析师的自觉，未能形成规范和产品层面的约束力。

　　而有数BI在项目实施的过程中，首先根据客户的特色指定了统一视觉规范，同时在产品里内置了主题管理功能，将色彩、线条等限制通过产品进行约束，将规范具现化，从而保证了视觉风格的统一。

　　Tableau虽然在产品功能设计上十分追求精益求精，但它的产品面向人群主要是专业性较强的数据分析师等人群，面向的分析场景也偏向于小规模的场景，因此在报表开发的时候缺乏一些批量操作，例如批量设置数据格式、批量重命名字段、批量修改数据类型等；

　　有数BI基于多年的应用落地实践，对大量常规操作，例如报告权限批量设置、用户批量导入、数据格式、类型、名称批量设置等做了较多优化，提升开发效率，减少重复工作。

　　同时，在操作上，有数以浮动式布局为特点，通过拖拉拽等方式开发，体验犹如制作PPT，产品上还具备显示、隐藏、切换TAB等特色交互能力，进一步丰富报告制作。

　　在Tableau的迁移过程，有数BI本身的计算字段也是完全兼容Tableau的计算字段，例如最为泛用的LOD计算字段、表计算字段。

　　在计算字段的学习成本上，擅长Tableau的分析师无需重新学习即可掌握有数BI的计算字段功能。

　　对于擅长使用SQL处理数据的分析师而言，使用SQL可能更为简单，但对于团队协作来说，大量的SQL逻辑，会使逻辑的可阅读性变得比较复杂。

　　同时，由于有数BI的数据准备的功能特点，面对业务逻辑变化的时候，每个节点的调整，都能实时观察后续任意节点的数据变化，这是直接使用SQL所不具备的开发能力。

　　Tableau的另外一个强大的功能是其关系模型。通过关系模型可以消解多对多关联带来的数据膨胀问题，同时提升查询能力。

　　实际上 ID=1的销额应该为10，销量为100+200=300，而ID=2的销额为20+30=50，销量为300，但如果根据宽表直接计算则会得到 ID=1 ，销额为20，销量为300；ID=2，销额为50，销量为600 。

　　为什么正确的数据却得到了错误的结果？原因是在于AB表关联的时候，每一张表里AB的ID都并非唯一性，致使其关联后的宽表形成了“数据膨胀”，从而导致计算不准确（实际上，数据膨胀不仅导致数据不准确，还会因为数据量大量膨胀，导致查询的数据量大幅度增加，严重拖累查询性能）。

　　Tableau通过关系模型的能力消除了数据膨胀，而有数BI也提供了同样的能力消除了数据膨胀，从而得到正确的计算结果，具体可见介绍文章困扰老王多年的难题，关系模型一步搞定了？

　　Tableau的数据更新计划依赖于手动，而有数BI则提供了手工调度、定时计划、依赖调度、数据重跑等多种能力来完成数据的提取与更新。

　　有数BI的定时计划支持月、周、天、时、分、秒级别的调度设置，而依赖调度则可以根据源端的数据更新节点自动触发有数的数据提取任务（包括有数的抽取、数据准备、物化视图等相关能力）。

　　目前在平台上有约100个数据提取的相关任务（还在陆续增加）使用了依赖更新功能，使得该公司的可视化数据的及时性大幅度提升，摆脱了以往依赖分析师手工调度的局面。

　　同时，有数BI还具备多渠道的数据预警与推送能力（如邮件、短信、企微、钉钉、webhook）等也是Tableau所不具备的，下图为基于第三方OA平台的数据推送方案流程图：

　　Tableau本身不具备数据录入的能力，该公司单独采购了一个数据录入工具集成在大数据应用体系内，不同事业部、不同公司、不同业务员有近百张数据填报模板需要不同的人员来维护录入数据。

　　（1）由于Tableau无法支持跟数据录入工具的账号体系打通，致使填报系统需要单独再创建一套用户体系，然后从另外的入口进行数据的录入。

　　（2）现在的数据录入工具，对填报模板没有类excel可视化的灵活编辑功能，都是菜单项的配置，配完之后需要在其他页面查看效果，同时，对填报数据的录入权限和查看权限需要对每张填报进行配置。

　　（1）有数BI内，数据填报和报告模块是天然一体的，采用一个账号体系，天然集成，无需额外开发。

　　（2）有数BI数据填报模板支持流式（类问卷）和制式（类Excel）等多种填报风格，操作灵活，同一套相似的模板可以反复使用，节省了大量重新开发的时间。

　　不仅如此，有数BI还支持数据入库规则，可以设置主键和数据插入的方式，方便对数据的更新和修改。

　　为满足系统信创要求，有数BI对整体部署实施方案进行改造，使应用能在信创环境下稳定持久运行。具体的改造内容包括但不限于：

　　宿主机环境：应用可以运行在装载国产CPU芯片的宿主机环境，如：海光7280芯片、鲲鹏920芯片；

　　缓存方案：采用国产缓存数据库替代Redis，如宝兰德BES CacheDB、腾讯Credis；

　　通过以上内容的改造，有数BI可以实现在全栈信创环境中运行。本次改造将有数BI现有的各类系统数据，如数据连接信息、模型信息、报告内容等进行迁移，从非信创环境迁移至信创环境。对应的模块与系统功能与当前环境保持一致，不改变现有用户群体的使用习惯。

　　在Tableau迁移至有数BI的过程中，有数BI基于客户自身的特点，在Tableau的优势、劣势项上进行了大量的优化，更加适合国内用户的使用习惯；同时在Tableau向有数BI的迁移过程中提供了集成方案、数据处理、计算字段等多方面的能力兼容，使得迁移成本、人员学习成本最低化，以最快最方便的形式完成产品替换。

　　同时，有数BI能够提供的快速的技术支持响应能力、客户定制化开发、信创支持，这方面也是Tableau在国内非常缺乏的能力。