BI产品的使用和问题解决（二）

 

现阶段各行各业在使用数据进行查询分析基本都是通过前端业务人员与信息部IT人员沟通，向他们解释具体的业务流程，然后IT人员再根据业务流程来获取数据建立模板这样一个流程来完成的。随着信息化的长期发展，这样一个使用流程的弊端越来越明显，具体表现在以下几个方面：

1、数据结构混乱。数据库经过多年建设，数据非常庞大复杂，IT人员几乎不太可能弄清楚所有数据表的结构；
2、沟通成本大。前端业务人员需要与信息部IT人员沟通，向他们解释具体的业务流程，然后IT人员再根据业务流程来获取数据建立模板，
这中间的沟通会反复好几次才能达到前端业务人员想要的效果；
3、响应时间慢。大部分的查询分析都需要IT人员建立，工作量大，前端人员等待的时间长，不能及时响应；
4、灵活性差。查询需求多样化，每个查询分析模板均是固定不可变更，不能满足一个模板的重复使用；
FineBI通过多人协同合作来解决上述弊端，系统管理员准备转义数据，将数据变成业务人员可理解的状态，且管理员无需具体了解所有数据表的结构，
FineBI会自动将数据库中的表间关系读取出来；业务人员借助其对业务关系的了解对数据进行二次加工，创建BI分析，并分享给领导或同事，
无需再与IT人员反复沟通，降低沟通成本和使用门槛，而且能够及时响应；其他人员在查看该分析的时候可以直接保存到本地并根据自己的需求修改，而不需要重复制作分析模板；领导直接查看分析，可通过修改统计维度和指标来达到了解各个方面数据的分析结果，灵活多变，利用分析结果查看问题、解决问题并辅助做出决策。
FineBI的定位是业务人员自己分析报表，所以在引擎部分将传统的关系型数据库非关系型化，这样用户在选择字段的时候才可以做到像在一张表里使用的效果，
重点是自主分析，传统数据库非关系型化。
1.1.1、fineBI4.0和fineBI4.1
FineBI4.0和4.1产品都是bug的修改，以及一些性能的修复。产品获取数据的方式两种：
1、直连sql数据集；
2、直接从数据库表中获取数据；
3、构建fineBI自己的cube.数据抽取的形式：
1、实时；
2、内存化。
针对汇总统计分析平台的需求主要是实现维度的自由拖拽和比年初【上年的12月分值】、比同期、比环期的求值。
问题：
1、比年初值计算不正确；
2、折叠按钮的汇总。比值都为空；
3、维度的自由托宅无法实现，需要固定维度的数量和维度位置；
4、对于精确去重的指标无法计算；
5、年度、季度无法计算指标的比值； 
6、对于比值计算，必须和紧跟时间，时间后面不能有其他维度;
7、在设计指标计算时候，中间变量无法实现隐藏。
1.1.2、fineBI5.0和fineBI工具的5.1版本
FineBI5.x的整个页面设计风格发生变化，编辑模式分为指标、维度、组件、图标类型、数据挖掘。5个主要板块，指标：自动将所有的整形变量识别出来，放置指标栏目。维度：自动将除整形变量的其他变量自动识别出来保存到维度栏目。图标类型：主要是包含一些表的样式例如交叉表、直方图、树形图、等图形样式，还有一些样式及表格属性的设置；数据挖掘：主要是针对当前的数据进行汇总或者预测【数据模型的思想】。获取数据的形式两种方式：1、直连sql数据集；2、直接库中同步表；数据的抽取方式：1、内存化；2、实时从数据库中抽取。
针对汇总统计分析需求与4.x的版本比较有那些改进和存在的缺陷；
第一阶段：
 问题：
        1 、count distinct 计算指标错误，把指标作为一个维度geoup by;
        2、比年初指标无法计算；
        3、预览模式无法实现维度的自由拖拽功能；
        4、不可累加指标的计算；
        5、维度的自由组合，进行数据的过滤；
        6、折叠按钮的汇总值,展示是空；
第二阶段
问题：
      1、维度自由组合的排序问题；
      2、维度的数据补全问题；
      3、指标设计的问题0/0-1与(0-0)/0的计算问题；
      4、count distinct报错的问题；
      5、基于编辑模式下实现维度的自由托拽功能，页面有许多的冗余组件或者功能，给用户太多的灵活操作，需要禁掉。
第三阶段
问题：
      1、数据补全问题；
      2、计算比年初或者比同期的时候需要取出13年的数据进行处理；
      3、数据导出的表样式有问题。
第四阶段
新增功能：
          1、通过当前用户去过滤数据集的权限；
          2、自主数据集的功能【4.x版本的cube构建功能实现】,数据最终的存储方式是内存化的，这个功能比较强大，消耗大量的内存；
          3、数值的计算不完全依赖与时间字段【时间维度后面可以和其他维度组合，求比值，并且计算】;
          4、系统管理部分对于常规项的处理；以及bi参数的说明;数据库连接配置；
          5、只能运维部分：资源迁移：只导出数据集和仪表板部分进行部署；备份还原：依赖与外联数据库的配置；
          6、安全认证，运行第三方语言的使用，R/Python的使用.
第五阶段
 问题： 
    1、指标的明细过滤和维度的排序一起使用，出现错误，排序的字段包含MT_被处理掉，引起的错误。示例:五级分类后三类的合同金额(*_amt_*)
     2、count(1)的使用出现报错，因为在计算部分FineBI使用了spdier计算方式，引起的计算的数值少一个值的问题，示例：计算账户累积数的时候,原始的值为145,实际查询结果是144。
     3、FineBI使用服务器数据集，所以在升级FineBI版本的时候，fr的版本对应的需要同步升级。
     4、FineBI的默认排序是根据AASCII嘛进行排序的，业务需要特殊的维度排序，所以采用依赖形式的排序规则。
      5、功能下钻按钮的报错，产品的逻辑问题，在修复中。
      6、FineBI的报表报错，联系管理员，查看日志报错连接sqprk报错，原因是和weblogic 的版本，以及对应下面的依赖包的错误问题引起来的，删除对应的jar不再报错，每次版本的跟新都是jar的跟新，兼容性不太友好。
      7、oracle字段类型是number的映射到FineBI的时候变成字符串;
      8、全局导出的功能，缺少过滤条件的导出；
      9、性能问题，页面初始化的报表加载时间较长大约在15-20s直接，页面的组件和控件的数量大概是40个左右，造成的,目前没有好的优化方案；
      10、FiineBI的字段识别功能，存在缺陷，第一次设计之后；
      11、apache代理之后，部分js无法加载；
      13、集群的选择，基于redis/基于apache做负载均衡/weblogic的集群部署；
     14、集群安全认证后的数据集连接，报表服务器需要做相应的Kerberos认证。
      以上就是在开发使用FIneBI的时候出现的一些问题，出现的问题厂商能够及时解决，并能对于问题出现的原因和原理给明确的说明，值得赞赏的。