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

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

也许你忘了具体时间,但换机的理由不会忘:老手机太慢了!(看心情换机的土豪除外)

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

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

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

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

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

一张部署架构图,半部BI用户“血泪史”_第1张图片

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

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

于是,便有了以下这张Smartbi部署架构图:

一张部署架构图,半部BI用户“血泪史”_第2张图片

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

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

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

Smartbi应对:集群部署

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

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

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

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

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

Smartbi应对:负载均衡

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

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

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

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

一张部署架构图,半部BI用户“血泪史”_第3张图片

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

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

Smartbi应对:分布式缓存库

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

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

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

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

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

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

一张部署架构图,半部BI用户“血泪史”_第4张图片

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

Smartbi应对:Session共享

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

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

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

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

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

你可能感兴趣的