效益,因管理而变,管理因我们(Smartbi)而变
发布时间:2021-09-08 游览量:4454
你记得上次换手机是什么时候吗?
也许你忘了具体时间,但换机的理由不会忘:老手机太慢了!(看心情换机的土豪除外)
由于软件的不断膨胀,导致手机、电脑的性能越来越差,用户备受煎熬,遂产生了换机的念头。
手机慢了你可以随时换掉,公司的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厂商的长期努力!
电话:
邮箱: