报表工具选型总结

[mygaochunming]

前言

根据项目组的要求，需要选择一款合适的报表工具来完成报表的开发工作，作者对如何选择一款报表工具做了一些调研和研究，整理如下。（由于作者自身水平的问题，可能有理解不正确的地方，希望各位读者留言指正。）

作者项目技术栈：elementUI+java+mysql

报表工具是个啥

要说明报表工具是个啥，就得先说一下报表是个啥。

报表

有人给出这样得定义：

报表 = 多样的格式 + 动态的数据（根据这个定义，咱们常见得系统都算得上是报表系统。这里不评论该定义是否准确）

报表到底是个啥呢？我们先不定义，从作者接触到的报表需求说起：

报表的功能性需求

这些需求来源于用户，以作者的经验总结如下：

呈现

1. 多级表头，固定表头，固定列
2. 对数据进行分组、汇总，比如按照区域统计并汇总（合并行、合并列），支持常用公式。
3. 报表的行和列是根据数据定义的（动态行、动态列）
4. 多个数据源得数据在一张报表上展示
5. 数据可以钻取，即点击数据跳转至详情页面，或者报表之间联动
6. 数据驾驶舱等图表功能

打印

1. 能够预览，并打印到A4、A3甚至发票、快递单上（套打）
2. 不用预览，直接打印，且可以连续打印。

导出

1. pdf。导出pdf文档
2. excel。导出excel文档
3. 嵌入到word中。将报表导出并嵌入到word中的指定位置

填报

1. 人工填报。根据报表模板进行填写并保存数据。
2. 导入。根据导出的模板填写数据并导入系统。

其它查看方式

方便在移动端、大屏上查看

报表的非功能性需求

性能

用户打开你做的报表要等10分钟，有没有？有没有看到客户怨恨的小眼神？

快速响应

1. 开发速度快
2. 热部署

安全性

1. 数据安全。灵活的权限控制，只有得到授权的用户才能查看报表（查看权限），同一张报表不同身份的用户看到的数据是不一样的（数据权限）。对开放数据操作权限的数据源还需要防范sql注入的风险。对填报的数据要进行校验。
2. 系统安全。报表的生成与查询不影响正常业务的办理，也不会对业务数据造成副作用；

我们在没有使用报表工具之前是如何满足以上需求的

呈现

1、2没有问题，在elementUI的官网上都有例子。3、5也没有问题，很简单的一个功能。因为elementUI是展示层，只要数据格式正确，就能正常显示，不管数据源是从哪来的，所以第4条也没有问题。

针对第4条，前端可通过ajax访问多个后端（可以是异构的，比如java、c++等），前端对数据进行组织并展示。

打印

报表的打印一般提前定义出模板，后端返回html，前端调用window.print()打印。

如果希望所见即所得，则前端在展示的时候要跟打印的时候排版一致。

有的打印可以先转成pdf，再打印。

如果需要不用预览连续打印，可以使用第三方插件C-Lodop

导出

导出跟打印类似，也是提前定义好模板，后端根据模板生成excel或着pdf返回给前端。

填报

填报跟报表呈现类似，只是展示与数据模型之间做了双向绑定，当前端数据发生变化以后，通过保存动作将结果更新至数据源。

导入的方式有两种：

1. 前端解析数据，解析完成后与填报功能无异。
2. 后端解析数据返回给前端确认，解析完成后与填报系统无异。

其它查看方式

个人觉得普通的交叉报表在PC上展示的报表到了移动端不会好看，应该在移动端重新进行开发。

如果是图形类的，如echarts等在PC上和在移动端显示效果是一致的（猜测，没在移动端用过）。

大屏，你就把他当成一个普通的显示器，没什么两样。（作者遇到的需求是这样的）

性能

性能在实际应用中就是打开一个报表多长时间能将结果呈现给用户。

报表结果的呈现分为**“数据准备阶段”、“数据呈现阶段”**

数据准备阶段

1. 对实时性要求不高的报表，可以事先准备好数据。比如每天早上9点用户要看到过去一天的日报，每个月1号上午9点要看到上一个月的月报等，这些有明确时间节点的报表可以在一个固定的时间点（或者结合服务器的负载自动选择时间）提前计算好。如果计算过程比较耗时，可以选择分多步计算。
2. 对实时性要求相对较高的报表，比如1小时之前的数据，或者5分钟之前的数据，也可以采用第一条的办法。
3. 对实时性要求很高的报表，比如要实时观察业务数据的变化，则需要考虑引入实时计算系统。

​

针对第1、2条。
  如果业务办理与报表数据计算能够错峰，比如白天是业务高峰期，晚上几乎没有业务，则报表数据计算可以安排在晚上进行。
  如果业务办理与报表数据计算需要同时进行，则报表数据的计算与业务系统要分开，以免影响正常业务的办理。在数据库方面，如果选择分布式数据库则可以忽略性能的影响，如果是关系型数据库则要考虑读写分离的方案。
  为了保证性能可以考虑通过横向扩展后端计算服务的方式来实现，高可用和负载均衡不是本文的重点，这里不做详细介绍。

数据呈现阶段

在数据呈现阶段，web应用依托于web浏览器，而在web浏览器中展示数据，如果一次性加载数据量大的话会造成浏览器卡顿，可以考虑滚动加载、分页加载、预加载等方式（目前没有遇到一次性展示大量数据的需求）

快速响应

使用elementUI的table组件能快速开发出各种报表。

对于热部署，需要前端与后端配合解决。

前端可以通过vue编译生成静态文件覆盖原有的静态文件（在nginx上）。

如果你的后端是传统的后端，那你可能无法实现热部署，需要重启后端以更新后端的数据模型。

如果想要后端也能进行热部署，那么后端采用微服务的方式动态注册一个服务，可实现报表的热部署。

安全性

自建报表与自身系统使用相同的角色权限体系。可以通过读写分离等方案降低报表对正常业务系统的影响。

既然自己就能实现报表功能，为什么还要选择报表工具呢？

刚才咱们自已实现了（理论上）一套报表功能。

那么，用业务场景来检验一下：

1. 用户：我马上（客户以为报表不用花时间）要一个XX报表，格式是XXX样的，数据分别从XXX来（能遇到告诉你数据分别从哪来的客户，真是烧高香了）

   1）用vue画一个样子（使用mock数据）给客户看直至满足客户的要求；

   2）后台组织数据，并测试；

   3）将vue编译成静态文件，放到nginx的制定目录下，这里需要将报表单独打包（不要打到总的包中，否则需要覆盖整个js，造成客户端频繁加载）；

   4）在rout中添加报表链接；

   5）发布后端服务，如果你后端服务可以动态扩展，恭喜你部署成功，否则你需要重启后端。

2. 用户：XX报表添加一列显示，并且能够跳转到XX功能：

   1）在原来的报表功能上添加XX列

   2）后台组织数据，并测试；

   3）将vue编译成静态文件，覆盖nginx下原报表文件，这里需要将报表单独打包（不要打到总的包中，否则需要覆盖整个js，造成客户端频繁加载）；

   4）数据组织发生变化，无论如何你需要重启后端。

我们为啥要选择报表工具

我们首先从自建报表的一些问题入手：

1. 在呈现方面，以elementUI+echarts为例，能够实现以上报表需求的大部分（有些特殊的echarts中不包含的图表可能需要自建）。但是在实际操作中，数据的组织比较繁琐，要从数据层面考虑合并行、合并列，不是很直观。
2. 前端打印，调用的是window.print()。打印的效果需要不断的调试，这个也挺费时间，而且window.print()必须先预览后打印，不能直接打印，比如有些客户希望单据连续打印。这种需求一般借助第三方工具比如C-Lodop
3. 导出，跟打印类似，格式也得自己调（特别是导出pdf）。
4. 填报跟呈现的问题一样，主要是组织数据。
5. 作者遇到的大屏展示的需求与在普通屏幕上展示没什么区别，没有遇到在移动端展示的需求，不做评论。
6. 在性能上，如果对业务分析透彻，做好分步计算或者利用好中间表或缓存中间件是能够达到要求的，前提是你的团队要有这个能力。
7. 快速上线，如果上述自建的方式可以做到热部署，那基本上可以无感上线。
8. 安全方面，自建的报表系统与原系统的集成度高，角色权限与原系统使用一套，报表系统单独部署，数据库读写分离，可将报表系统对业务系统的影响降低。

如果要选择一套报表工具，那么看看该工具是如何解决这些问题的。

作者调研的报表工具是ActiveReportsJS，还有同事调研的的是FineReport和润乾报表。

就调研的结果来看：

1. 在呈现方面，报表工具都有报表设计器，通过拖拉拽的方式实现报表的展示样式。上面需求中的多级表头、合并单元格、固定行、固定列、动态行、动态列、数据的钻取以及多数据源的数据显示在一张报表上，这些基本都满足。差别：有的报表工具支持报表间数据的共享，有的不能。

   与自建报表的对比：报表工具通过拖拉拽能够设计出报表的样子，单元格与数据的绑定、多级表头、动态行、动态列的实现比较直观。

2. 在打印方面，报表工具设计出来的报表宽度、高度都是固定的，天然为打印准备的，所以所见即所得，在能否连续打印方面没有验证。

3. 在导出方面，报表工具一般支持pdf、excel的导出，且所见即所得。

4. 大部分报表工具支持填报功能。

5. 看各报表工具的功能介绍。（调研不详）

6. 有些报表工具支持数据中间层，有些不支持。（调研不详）

7. 大部分的报表工具独立部署且支持热部署。

8. 有的报表工具有自己的角色权限体系，防sql注入（调研不详）。报表工具可以独立部署，对原业务系统造成的影响较小，但要注意对数据库的访问压力，考虑读写分离或者通过增加中间表、中间库、缓存中间件等方案。

综上所述，如果你团队的技术水平有限、用户的报表量较多、用户的报表需求变化比较频繁、报表需要热部署，而且你项目经费允许，那么你该选择一款适合自己的报表工具。

以RDP报表工具为例看都提供了哪些功能，这里列举了一部分：

我们如何选择报表工具

如果你的团队想选择一款报表工具，那么以下几个方面做出判断。

根据该脑图可以做成一个表格，把需求标清楚，然后根据各报表工具提供的功能往表格上一一对应，选择一个更合适自己项目的报表工具或者选择自建。

参考文献

报表选型中那些想不到的坑
ActiveReportsJS
RDP报表工具