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

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

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

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

后来公司的数据仓库慢慢成形，而我也慢慢脱离了用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的生产者消费者模式就相当于充当了一个容器，生产者和消费者彼此之间不直接通讯，生产者生产完数据之后不用等待消费者处理，直接扔给阻塞队列，消费者也不找生产者要数据，而是直接从阻塞队列里取，阻塞队列就相当于一个缓冲区，平衡了生产者和消费者的处理能力。

总结

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