你记得上次换手机是什么时候吗？
也许你忘了具体时间，但换机的理由不会忘：老手机太慢了！（看心情换机的土豪除外）
由于软件的不断膨胀，导致手机、电脑的性能越来越差，用户备受煎熬，遂产生了换机的念头。
手机慢了你可以随时换掉，公司的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厂商的长期努力！