一个BI工具的痛点

从2020年12月，引入一个BI工具，到现在（2022年1月）发版并改进了有一个年头多了，来细数这一年做BI工具面临的棘手的问题。

文章目录

• 一个BI工具的痛点
• • 术语
  • 技术方面
  • • 无明确层次的抽象
    • 模型转SQL过程复杂
    • 无合理的报文结构
    • 不合理的数据库表结构
    • 复杂的权限问题
    • 下钻跳转问题
    • 维度、度量、表的替换
    • 查询性能
  • 项目方面
  • • 人员变动
    • 人员质量
    • 开发周期
  • 写给甲方们的考察建议
  • 写在最后

术语

• 仪表板
  一张页面（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年对其进行一步步解决！欢迎交流~