BI_01_一个BI工具的痛点

简介: BI_01_一个BI工具的痛点

术语

  • 仪表板
    一张页面(H5/PC/PAD)
  • 组件
    组成仪表板的各种组件(图表、文本、筛选器等)
  • 维度、度量、指标
    与数据分析相关的术语,类似与SQL中的group字段与select中的字段

技术方面

无明确层次的抽象

在项目不断的迭代,需求不断的增加(变态)中,原本简单明确的抽象层次被部分无良开发人员大量堆积的定制化逻辑冲破,

原本可以一刀切开的西瓜变成了人为加强过的钢化玻璃——藕断丝连。这让新入场的开发学习成本大大增加,

同时,也让新增的需求会搞不清写在哪一(几)个位置。

模型转SQL过程复杂

项目中对一个组件的模型定义较为复杂,其转换为SQL的过程也十分复杂,难以修改,定位错误。

而且,使用SQL的拼接,带来了SQL注入的风险(万幸Kylin等OLAP的数据源不支持delete、update等操作),也导致了未支持不同数据库的方言。

另外,这是一个计算十分密集的操作,在压测时,其计算对CPU的占用会是明显的短板。

无合理的报文结构

由于参与人数多,且无权威引领方(甲方流泪),报文结构逐渐臃肿,许多一个含义的字段出现多种表达,而且没有好好的维护文档。

这不仅让开发时产生了选择障碍,而且也出现了乱使用相近字段导致问题的情况。

而其带来的后果却很隐性且严重,例如报文体积变大,一个图表的查询结果报文大小在300K-1600K(甚至更大),

而一张仪表板的数据查询组件数量少则四五个,多则上百个(真实存在…),一页仪表板的报文能够在2M-30M,

这无疑导致了外网的手机用户显示耗时、流量、耗电量蹭蹭蹭的往上飙(一个轻度用户一个月流量跑了几个G)。

不合理的数据库表结构

在表结构设计时,由于错误使用反范式(JSON),将许多需要修改的字段写入其中,并且用上了CLOB、压缩等离谱的操作,

导致仪表板的修改操作十分的困难,十分容易遗漏,以及十分多的脏数据存留。

而且随着项目的发展,其会成为性能优化过程中十分头疼的事。

另外,由于这样的非结构化存储,仪表板的导入导出功能开发周期也十分的长。

复杂的权限问题

BI工具本身的业务逻辑并不算十分复杂,但是当业务需求结合着复杂权限问题,修改难度就会上来。

例如,管理岗与业务岗的区分、管理岗仅能看本机构以及下属机构、管理岗仅能看同级机构以及下属机构、

当下钻时遇到子机构仅一个时将自动将其下钻、机构列表的排序顺序需要在查询后根据另一个系统请求来的顺序重排等等。

下钻跳转问题

下钻作为一个优秀的BI工具必有的一个特性,往往通过层级维度的方式作为解决方案。

然而,也会遇上一些问题,例如一共有5层维度,其在第三层时,需要跳转去其他页面(样式不同)继续下钻。

那么不同页面上下钻、跳转字段的关联就是一个必须要处理的问题。

维度、度量、表的替换

例如排行榜等组件编排的页面,其往往是看一个度量值的排行,当度量值够多时,需要重复配置的页面就会有许多。

例如机构不同层次看的样式不同时,维度如果不能替换,又会需要多配置许多仪表板。

例如日、月、季、年这样的维度,查询的表不是同一张表时,模型查询的表就要进行替换(字段相同)。

查询性能

性能问题有许多块,这样一个数据分析用户编排出的通用页面,对于前端渲染耗时、后端解析耗时、数据端查询耗时都有很高要求。

项目POC时,往往会因为数据端数据量不够大、仪表板中组件数量少等等原因,导致体验尚可、TPS等指标还算在线,

而真实投产后,慢的将会离谱。

项目方面

一个优秀的产品,其项目的各种因素也是十分重要的。

人员变动

人员大幅度变动是项目很难受的事情,20多个开发人员,在两周内完成了与第二批开发者的交接,其一期留下的人员不足3人,可谓是伤筋动骨。

教训就是长期项目的合作伙伴的选择,还要考虑其稳定性。

人员质量

BI工具的定位是工具,与其他金融级业务系统不同,其线上的风险相对更小,因其面向往往是B端用户,而非C端用户。

所以,这一年的开发有许多低级错误,是从前在开发金融级业务系统从未见过的。

例如,删除或修改一条记录,与其关联的记录并没有相应的去做删除和修改,且屡禁不止。

对人员的要求,开发规范的要求,不能因项目风险小而放开。

开发周期

这个周期问题可以说是现阶段难以避免的硬伤,《人月神话》表示了,项目的开发周期并不是无限加人就能无限缩短的。

面临紧迫的开发周期,项目质量下降是不可避免的。也只能以多走查、评审的方式来稍微扶扶风气。

写给甲方们的考察建议

  1. 在业务上,考察其是否支持下钻、跳转、对标等功能是否支持;权限系统是否有考虑且灵活。
  2. 在性能上,将一个页面配上至少50个组件;查询的图表中的维度、度量数量超过15个、查询的行数超过1000。
  3. 在代码上,考察其代码层次是否清晰、表结构是否合理、接口报文是否拆分合理。
  4. 在合作伙伴上,考察其稳定性,真实性。避免项目中人员大换血、多层虚假合同的能力不足人员入场。

写在最后

问题被归纳总结后,也要在2022年对其进行一步步解决!欢迎交流~

目录
相关文章
|
6月前
|
SQL 搜索推荐 数据挖掘
一文详解报表工具和BI工具的区别
一文详解报表工具和BI工具的区别
|
存储 数据可视化 数据挖掘
【数据可视化和BI技术】数据可视化和BI技术的原理、方法和工具,如Tableau、Power BI
【数据可视化和BI技术】数据可视化和BI技术的原理、方法和工具,如Tableau、Power BI
262 0
|
5月前
|
SQL Java 关系型数据库
技术心得记录:开源BI分析工具Metabase配置与完全使用手册
技术心得记录:开源BI分析工具Metabase配置与完全使用手册
694 0
|
6月前
|
自然语言处理 数据可视化 数据挖掘
首批!瓴羊Quick BI完成中国信通院大模型驱动的智能数据分析工具专项测试
首批!瓴羊Quick BI完成中国信通院大模型驱动的智能数据分析工具专项测试
202 1
|
6月前
|
数据可视化 Linux Apache
CentOS部署Apache Superset大数据可视化BI分析工具并实现无公网IP远程访问
CentOS部署Apache Superset大数据可视化BI分析工具并实现无公网IP远程访问
|
6月前
|
数据可视化 BI Apache
大数据可视化BI分析工具Apache Superset实现公网远程访问
大数据可视化BI分析工具Apache Superset实现公网远程访问
|
SQL 搜索推荐 数据可视化
运营也用的起来的数据分析工具:Quick BI即席分析详解
数据部门是一个容易被投诉的“高危”部门,需求响应慢、数据准确性不高会影响业务的发展。 然而数据分析师每周动辄就有几十个需求在手,无限的加班也无法解决所有问题,到底怎样才能改变BI分析师的需求响应问题呢?
643 0
|
SQL 分布式计算 数据可视化
外部工具连接SaaS模式云数据仓库MaxCompute实战——BI分析工具篇
MaxCompute 是面向分析的企业级 SaaS 模式云数据仓库,以 Serverless 架构提供快速、全托管的在线数据仓库服务,消除了传统数据平台在资源扩展性和弹性方面的限制,最小化用户运维投入,帮助企业和大数据开发者经济并高效的分析处理海量数据。
1783 1
外部工具连接SaaS模式云数据仓库MaxCompute实战——BI分析工具篇
|
数据挖掘 BI
【视频特辑】全链路开放集成!Gartner魔力象限上榜的BI工具你也可以拥有
Quick BI作为唯一一个连续两年入选Gartner魔力象限的中国BI产品,具备强大的全链路开放集成能力,可以轻松的与企业原有系统匹配融合
206 0
【视频特辑】全链路开放集成!Gartner魔力象限上榜的BI工具你也可以拥有
|
数据可视化 数据挖掘 大数据
【视频特辑】全链路开放集成!Gartner魔力象限上榜的BI工具你也可以拥有
Quick BI作为唯一一个连续两年入选Gartner魔力象限的中国BI产品,具备强大的全链路开放集成能力,可以轻松的与企业原有系统匹配融合
【视频特辑】全链路开放集成!Gartner魔力象限上榜的BI工具你也可以拥有

热门文章

最新文章