一张部署架构图，半部BI用户“血泪史”

​你记得上次换手机是什么时候吗？

也许你忘了具体时间，但换机的理由不会忘：老手机太慢了！（看心情换机的土豪除外）

由于软件的不断膨胀，导致手机、电脑的性能越来越差，用户备受煎熬，遂产生了换机的念头。

手机慢了你可以随时换掉，公司的BI平台慢了，你就得被迫忍受了。

随着数据的爆炸性增长，BI系统要处理数据越来越多，动辄TB级、甚至PB级。

于是，服务器宕机、反应迟钝、查询缓慢等各种性能问题接踵而来。

BI系统的用户，心里苦啊~~~

各路BI厂商也意识到这些问题，纷纷推出各种性能解决方案。

其中，Smartbi产品服务众多头部客户，性能必须得HOLD住！

于是，便有了以下这张Smartbi部署架构图：

这张图包括4“味药”：集群部署、负载均衡、分布式缓存库、Session共享，是Smartbi从多年实践中总结出来的“药方”。

其实，又何尝不是半部BI系统用户的“血泪史”？

BI系统用户血泪之：服务器宕机

Smartbi应对：集群部署

单机处理到达瓶颈的时候，把单机复制几份，这样就构成了一个“集群”。集群中每台服务器是这个集群的一个“节点”，所有节点构成了一个集群。每个节点都提供相同的服务，这样系统的处理能力就相当于提升了好几倍。

所以，提升Smartbi性能最直接的办法，就是集群部署：在多台节点上安装Smartbi，把用户的请求分派给不同的节点进行处理，提高整体性能。即使有节点崩溃了，还有其它节点可以使用，避免了服务器宕机这种灾难性的故障。

集群部署的好处是系统扩展非常容易。随着业务的不断发展，当前的系统又支撑不住了，那么给这个集群再增加节点就行了。

而且，通过X86集群代替以前的小型机，价格明显降低。

BI系统用户血泪之：系统反应迟钝

Smartbi应对：负载均衡

采用集群的方式，有个关键的问题是：用户的请求究竟由哪个节点来处理？

最好能够让此时此刻负载较小的节点来处理，这样使得每个节点的压力都比较平均。要实现这个功能，就需要在所有节点之前增加一个“调度者”的角色，用户的所有请求都先交给它，然后它根据当前所有节点的负载情况，决定将这个请求交给哪个节点处理，这个“调度者”叫做：负载均衡服务器。

Smartbi的负载均衡服务器（Smartbi proxy）采用前后端分离的框架，保障请求被分发到合适的节点上。这种方式解决了系统反应迟钝的问题，保证用户业务的持续稳定运行。

各节点定时向Smartbi proxy汇报自身的状态信息，Smartbi proxy根据节点的内存、CPU等差异性判断其可用性和服务能力，把请求分发到合适的节点上。如果节点属于“断开”状态，则将此节点临时从待选取列表中剔除。

若节点的资源使用率达到了设置的阈值，那么会触发告警，以发送邮件的方式对异常节点进行前端提醒。

BI系统用户血泪之：数据查询缓慢

Smartbi应对：分布式缓存库

分布式系统是由一组通过网络进行通信，为了完成共同的任务而协调工作的计算机节点组成的系统。目的是利用更多的服务器，处理更多的数据。

听起来是不是跟“集群”很像？这里就有必要搞清楚两者的区别。

简单地说，集群是不同的节点处理不同的请求，而分布式是不同的节点处理同一个请求，分布式架构需要基于集群部署。

例如，用户要么登录集群里的节点A，要么登录节点B，但登录后的每一次数据查询，可以由另一个集群的节点C和节点B共同执行。

Smartbi的高速缓存库（Smartbi MPP）采用分布式架构，将任务并行地分散到多个节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果，极大提升了大规模数据处理能力，解决了用户数据查询缓慢的问题。

除了Smartbi MPP，Smartbi高速缓存库也支持Vertica、Presto+Hive、星环等MPP数据库。

BI系统用户血泪之：强制重新登录

Smartbi应对：Session共享

Smartbi将会话（Session）信息统一存储在缓存数据库Redis中，实现多个应用服务器共享会话信息，保证服务器重启或切换后，仍然可以正常操作，不会跳转至登录页面，也不会出现“HTTP 400”和“HTTP 500”错误。

Redis作为缓存服务器，是基于内存、可持久化的日志型、Key-Value数据库，用于存储登录信息、Session 等信息，集中管理所有的服务器状态，并对所有的访问和操作进行验证。

Smartbi通过Session共享实现产品无状态化：即使服务器在宕机、断电、切换等情况下，都无须用户重新登录，保障业务操作不中断、数据/模板不丢失。

不管BI系统用户还有多少“血泪史”，相信办法总比困难多。

提升产品性能，改善用户体验，需要BI厂商的长期努力！