凭什么它能成为报表神器?这五大技术硬货不得不服

经常被报表折磨的人一定听过这样一句话:“新人不识愁滋味,爱接需求,爱接需求,为做报表晕转头,一张能做一个周。“

作为一个做了十几年数据的报表开发人,回想自己刚到公司的时候,公司数据系统什么都没有,连提取数据都很困难,做报表就更不要想了,每次都是东拼西凑,做点简单图表就算是报表了。

更多时候是业务那边拿出一撂纸往咱面前一堆:“就照这个做吧”,立马头就晕了,随便选一张搞个两三天是家常便饭,运气坏了折腾一礼拜也不是多罕见的事。

后来公司的数据仓库慢慢成形,而我也慢慢脱离了用Excel做报表的低级阶段,但是新的问题又随之而来:

整个运营部门只有我的主机承担着整个公司的报表数据,隔三差五就会因为数据量过大而造成宕机,一宕机数据平台就停转,数据系统一停转数据就会丢失,造成的严重损失不说,最难受地是每天都要担惊受怕。

举个简单的例子,之前我们曾经用过一家国内厂商的报表平台,在业务不多的时候表现还是很正常的,一旦到了业务高峰期就根本不能切换窗口,我们当时想把资源切换到另一个服务器上,却发现无论怎么操作都没办法把资源切换过去,领导们听说这个事都赶过来了,围在周围商讨如何解决,同时急电该厂家技术支持立即赶往现场救火,后来我们终于发现问题:报表系统在数据库的日志读取时因为数据量过大,直接造成了系统的卡死,以致业务系统宕机,无法处理业务请求。

等到我们处理好故障之后,看看时间,这时间已经过去一个小时了,相关外联单位的打来的电话已经打爆了,耽误了业务系统的处理,大家都走不了。

这也说明,当我们在为企业选型报表工具的时候,不单单要关注报表工具的灵活性、功能性和性价比,更重要地要关注它的功能性和技术性,有没有技术瓶颈、能不能预览缓存、有没有集群缓存机制、会不会经常宕机等等,这些都是普通业务人员无法发现的。

按照我们这几年的经验来说,国外诸如JasterReport、BIRT这样的基本不用考虑了,国内厂商的话,技术比较成熟的也就是FineReport等一些工具吧,基本上报表平台的稳定性都很强,基本没有出现过宕机情况。

下面我就结合报表平台FineReport,以及自己的经验,总结了下面五个硬技术,来简单梳理一下一个优秀的报表工具应该具有什么样的“高精尖”技术:

一、Web集群

什么叫做集群呢?简单类别一下,有一家银行只开放了一个业务办理窗口,但是来办理业务的人有100人,因此大家排起了长队,突然这个窗口的银行柜员忙晕了过去,于是窗口上便挂出了“暂停服务”的牌子,整个队伍就要等待窗口重新开放。

如果你是行长,你会怎么办?你肯定会说,这还不简单,多开放几个窗口一同办理不就行了。

对了!这就是集群,报表服务器就相当于银行的窗口,以前我们都是把所有的工程负载都集中到一台主机上,也就是只有一个窗口,但是数据一旦达到阈值,就会产生宕机(也就是“暂停服务”),这个时候整个系统就会失效停断,这个时候我们就需要集群,来增加服务器节点实现并发线性增长:

这也是解决宕机的一种常用方法,FineReport在这一方面就做得十分完美,可以依据算法将需求合理分配到各个节点上,任何一个节点宕机都不会影响系统的正常工作,也就是“无主机模式”。

后来我才发现原来FineReport拥有着一套非常成熟的集群架构,我将其总结为““负载均衡+web容器+状态服务器+文件服务器+外置数据库”,这几乎可以成为国内报表集群方案的标准模板!

负载均衡就是合理分流,速度快的节点多分一些,速度慢的少分一些,这也是集群系统的入口;

web容器相当于银行柜台,作用是处理客户端发出的请求;

有了请求就要进行验证和缓存,状态服务器就是用来管理服务器缓存的;

文件服务器相当于银行前台的电脑,保证每个窗口的信息同步更新,也就是资源文件的实时一致性;

最后,虽然服务器节点有很多,但还要用同一个外置数据库才行,这样才能保证节点之前的配制信息是一样的;

二、Swift引擎

做报表开发的都知道,我们所有的报表日志和文件都需要写入数据库,需要数据的时候再从数据库里提取,但是很多报表工具在日志存取上的效率很差,一旦日志过大就会导致系统过慢甚至宕机。

而FineReport自主开发了一款很牛X的引擎——Swift引擎,其实就是一个分布式数据库,我们可以理解为是一个公共账本,你可以在这个账本上写数据,我也可以写数据,我可以看被人记录的数据,也能拿到自己单独的数据。

但是这个公共账本能允许记录多少数据?会不会在查询的时候要排队?会不会因为数据太多导致崩溃?我想要看数据的时候会不会影响别人?

而这也正是Swift引擎真正强大的地方,以上的问题我也曾经担心过,但是没想到swift引擎竟然全都迎刃而解了!

首先,swift采用的不是cube导入数据才能查询的方式,而是换了一套数据结构,数据只要插入了就可以零延迟查询,根本不需要排队;

而且理论上支持数据的无限增长,只要不超过单机的物理瓶颈,你就可以放心地往这里放数据;

最后,swift引擎支持非对称分布式,服务之间职责分工明确,互不干扰,比如导入机器跟查询机器分开,避免导入数据时太占资源影响查询。

三、基于 JVMTI 的增强内存管理技术

这个技术虽然听起来比较深奥,但是我发现这是提高报表平台稳定性的最好办法!

很多其他工具是怎么预防宕机的呢?方法比较简单,就是一旦负荷超载了,内存达到了一定阈值就要排队,永远预留一定的内存空间,防止其宕机时内存空间不足,但同时也会产生一个问题——不宕机的时候也要持续排队。

而不得不佩服FineReport,他们应该是深入研究了JVM GC机制的底层原理,采用了JVMTI去检测jvm的编程接口,加入了强制GC机制:

也就是内存达到阈值后进入排队,触发一次GC,如果没有释放足够空间,就再次GC;而如果内存达到阈值后触发了GC,释放的空间足够用,系统就会继续运行,不会继续触发GC,这样就不会导致宕机了,可以大大增加平台的稳定性。

四、HTML解析技术

大家都知道HTML是用来书写网站的一种语言,在我用之前的报表工具打印导出报表模板时,经常会遇到“以html显示内容”的情况,就可能会造成导出后数据有误、线条不显示等等,后来我找到了真正原因:

因为如今用户开发的系统基本上趋向于BS架构的浏览器,这些系统可能由不同的语言开发,包括HTML、ASP、JSP、PHP等,如果我们要将制作好的报表嵌入到这些页面中,就要进行HTML的解析,而你的工具要是没有这个技术,就会出现上面的情况。

而像我这样的代码狗一般就会直接找源代码,调用参数才能解决,但是对于很多业务人员来说基本上就是无能为力了。

而FineReport显然考虑到了这一点,它所拥有的html解析器基本上杜绝了HTML的显示问题,实现了PDF、Excel、Word导出的html解析。

五、大数据集导出

在进行报表开发的时候,经常遇到一个问题:当我导出大数据量的模板时,极容易存在时间过长或者内存占用过大的情况。

这是为什么呢?因为你在对数据集进行取数的过程中,必须现在进行报表计算,然后才能导出,类似于excel的函数计算,会大大增加宕机的风险

而经过使用后,我发现FineReport就不会出现这样的问题,直到我询问了他们的开发人员才明白了FR是如何在技术层面解决大数据集导出问题的:

首先,他们使用的是SXSSFWorkbook流式行导出,速度真的非常快,而且他们采用的是生产者消费者模式,一个线程用于取数,把数据行存在队列中,另一线程读取行导出。

通俗点说,生产者就是生产数据的线程,消费者就是消费数据的线程,如果生产者处理速度很快,而消费者速度很慢,那么生产者就必须等待消费者处理完,才能继续生产数据,反之亦然。

而FineReport的生产者消费者模式就相当于充当了一个容器,生产者和消费者彼此之间不直接通讯,生产者生产完数据之后不用等待消费者处理,直接扔给阻塞队列,消费者也不找生产者要数据,而是直接从阻塞队列里取,阻塞队列就相当于一个缓冲区,平衡了生产者和消费者的处理能力。

总结

对于一个从事了十年报表工作的人来说,一个成熟的、强大的、简洁的报表平台工具是极为重要的,它不光要解决各种中国式的复杂报表,最主要的是它要能够为企业快速搭建起数据平台,这样的工具才是真正对企业来说有用的,否则都只是空有其表,华而不实!

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20190919A06DW100?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券