如何解决BI系统性能差响应慢的问题
发布网友
发布时间：2022-04-22 08:09
共2个回答
热心网友
时间：2022-06-18 09:17
大部分的BI工具都是基于B/S 架构的。每一次来自浏览器的点击，都是通过HTTP协议像服务器发送一次 Request 请求，一次报表的查询本质上发送了一条 SQL 查询命令到了应用服务器端通过程序翻译再到数据库服务器做了一次数据查询动作。
如果这个 SQL 查询本身就比较复杂，底层数据模型建立的又不好，或者在数据库服务器硬件环境配置本身也不好的情况下，这条SQL的执行可能就需要花费很长的时间。这个是第一个时间损耗的点。第二个点就是SQL的查询可能返回了大量的数据，比如几十万、上百万、上千万、上亿的数据，这个数据最后打包通过HTTP协议Response响应返回，需要通过网络返回到Browser 浏览器端，几十万的数据可能有上百兆MB，上百万、上千万的数据可能是几百兆（MB）甚至一个GB的数据。大家试想一下平时下载个电影需要多长时间，下载一个几百兆的文件需要多长时间，这个还跟网络带宽有很大的关系，这个是第二个时间损耗的点。
数据返回到浏览器前端，在图表展现的时候，如果写了很多复杂的表达式、聚合函数，数据需要消耗本地浏览器所在电脑大量的内存来完成数据的计算。前端指标计算、条件表达式和各类聚合函数设计的越多，需要的时间就越长，这个就是第三个时间损耗的点。最后就是页面的渲染，图表越多、结构越复杂、列越多，数据渲染通过HTML组织到最后的呈现时间就越长，这个就是第四个时间损耗的点。
到最后页面全部加载完成，HTTP 请求终止与服务器断开连接。
在这个过程中，大量的时间损耗主要集中在数据查询、大数据量的返回，以及基于大数据量下的前端聚合函数、条件表达式的时间损耗上。所以，报表的优化首先要解决的就是在数据库服务器上的查询效率，SQL 的结构要合理、底层数据模型的结构要合理，这是SQL层面的优化，更是数据模型的优化。同时，减少数据的返回量，减少网络带宽的消耗，数据返回量小了，最终到前端聚合和渲染的速度也会加快。这样整个从查询到返回到展现的时间都会大大缩短。
有的朋友说，用户就是要查询大量的数据展现在二维表格上怎么办，还是按照刚才的四个点去分析。第一，通过设置合理的联动查询条件，逐步减少数据量的返回。第二，通过设置分页将查询分散在每一次与Server 的交互上，也可以减少数据量的返回。第三，提前将能够聚合的数据逻辑在服务器端完成，将计算前置，或者使用列式数据库或者分布式计算来减少查询阶段的时间消耗，都可以实现纯二维报表的优化。
当然也有朋友说使用C/S架构的BI工具是不是就可以解决这个问题。C/S架构的原理是Client 客户端和Server 服务器端的架构，将数据加载到本地电脑内存来计算，在性能和效率上比B/S架构确实要快很多。但C/S架构就意味着需要在每个用户的本地电脑上安装一套客户端软件，有多少用户就需要安装多少，并且在程序升级方面需要单独的升级，不太适合大批量的用户。对比B/S架构，B/S架构中用户只需要通过电脑上自带的浏览器随时访问报表，所有的程序升级都是在服务器上一次性升级就可以完成。
B/S架构和C/S架构没有孰优孰劣，只是在不同的场景下各有优劣。
热心网友
时间：2022-06-18 09:18
1、高速ETL技术
数据仓库，是海量数据运算的性能支撑基础。而想要建设一个好的数据仓库，首先必须要有高速的ETL技术。好的数据仓库技术的应用效果，要比写sql从数据库中取数快了不止百倍，无论再复杂的条件组合查询，一般都能在一分钟展示结果。
2、 “去掉”表关联技术
用户在进行商业智能分析取数的时候，数据往往来自多个数据表。数据表之间往往存在纵横交错的关联。查询的表关联越多，速度也就越慢。要解决这个问题，就得想办法“去掉”表关联。当然，这里的“去掉”是加了双引号的，并不是真正意义上的去掉，而是让熟悉企业数据库的IT人员预先把表关系建好在语义层中，支持多字段关联、内外连接。这样，最终用户在做查询或报表时，就不必理会表关联了，需要查什么直接拖放即可。
3、 代码表快速转换技术
我们都知道，计算机处理英文的速度要快于中文。针对这一特征，企业需要建立一张中英文代码转换表，在计算机进行处理时将中文转换成数字或者字符进行处理，处理结果出来之后再转换为中文。
4、 海量数据处理技术
面对大数据量的处理场景时，通常有这三种解决技术，一是缓存技术，一是并行计算技术，一是云计算。
数云,商业智能BI
