RQlyc的博客

现在市场上开源 BI 产品比较多，各个产品的侧重点不同，有的以报表为主、有的以可视化为主、有的以查询分析为主。这里我们选取了一些主流的开源 BI 产品，从产品功能、可视化能力、数据源支持以及使用文档等方面进行对比，希望对你有帮助。Superset由Airbnb贡献的轻量级BI产品，目前在GitHub上有3万多颗星，其受欢迎程度可见一斑。Superset提供了Dashboard和多维分析两大类功能，后者可以将制作的结果发布到Dashboard上也可以单独使用。数据源方面，Superset支持C

本次仍然评测这几款主流的报表工具：润乾报表、帆软报表、Smartbi、永洪 BI、亿信。之前在多源关联分片报表中验证了各个报表工具的多数据源关联功能，这些产品都能支持多数据源，但对不同类型数据源的支持程度并不一样。目前常用的关系型数据库基本上都提供 jdbc 接口，所有报表工具都支持，这里就不做详细说明，下面主要看下几种数据源的支持情况：1、 文件数据源，如 Excel、txt、csv 等。2、 webservices 接口数据源，如服务返回的 json 或 XML 格式数据3、 非关系型数据库

有些报表查询出的数据行数可达千万甚至上亿，这类报表通常被叫做大报表，大多数情况下都是些清单明细数据报表，也有少量分组报表。针对大报表，如果像常规报表一样，将数据一次性全取再交给前端呈现是不可行的。一是等待时间太长，用户体验差；二是很可能导致内存溢出造成应用崩溃。那么，目前的报表产品是如何解决这一问题的呢？本文将调研并测试几款报表产品的大报表解决方案，还是针对这三款产品：润乾报表、帆软报表、Smartbi，均为最新版本。首先了解下各家的解决方式或机制。解决机制帆软帆软提供两种引擎，行式

报表呈现有这么几个阶段：取数、报表计算、生成 html 及页面渲染，报表计算是考察报表性能中较为重要的一环。多数据源（集）关联报表是一种计算量随规模增长较大的报表，适合用于进行此项测试。本文将对比报表的关联运算性能，产品依然是三款：润乾报表、FineReport、smartbi，均使用最新版本，涉及报表数据来源为同库同表。测试采用多数据集间关联计算，报表格式很简单，具体可参考下面的说明。用例POS 交易情况统计，统计所有商户（包括还未使用但已申请且开头 pos 刷卡业务的），使用本行 pos 机

WEB 套打的基本解决思路是：把套打的格式做成一张图片，将要填入的数据按其在图片的坐标来定位，最后把数据填充到对应位置。但是具体实现时会遇到各种问题：1、 图片坐标定位不精准，实际打印效果有偏移；2、 多页数据套打时，无法进行数据准确定位；3、 套打数据的关联计算 / 页内计算支持性低；4、 格式改动后，代码需要重新编辑还有一种解决方法是通过报表工具，把套打格式扫描成图片，图片作为报表的背景图，然后以背景图为基准绘制报表格式，在对应位置编辑取数表达式以及其他数据处理方法，保证数据填充

在了解如何集成前，首先我们得找对易于集成的报表工具，什么样的报表易于集成？1. 同平台的比如：java 开发的项目找 java 开发的报表工具2. 没有复杂系统功能的因为含有复杂系统功能的报表工具，跟自己的报表门户平台集成会存在冲突，比如：用户管理体系，单点登录等。这时就不能做无缝集成了，只能进行跨系统调用。如找到易于集成的报表工具后，其操作就相对简单了，比如 java 的，直接将报表应用放进自己的项目中统一管理就可以了，不易于集成的，需要单独部署、处理调用及单点登录，维护起来很麻烦

首先 BI 工具得能集成，大部分不能集成，为什么呢？是因为 BI 主要面向终端用户，这就要求提供一套完整的解决方案，所以几乎所有厂家的 BI 都是一套独立的产品，包括组织架构管理、登录模块、权限控制、其他 BI 相关功能模块。以自助报表为例，让终端自行设计报表，最简单能想到的就是权限控制，不能让不同部门间、个人角色间看到不该看的数据，所以要求它必须配备一套组织管理、权限管理。既然是一整套系统，又很难把单独的 BI 功能模块拿出来做集成，这就会出现好多问题。集成时，需组织架构信息同步、单点、权限同步等等，

在报表应用中是可以使用 echarts 做图形展现的，实现很简单，因为 echarts 是使用 JavaScript 实现的开源可视化库，兼容当前绝大部分浏览器，可以流畅的在 PC 和移动端上显示。现在大多报表应用都会引入 echarts 丰富自己的图形展现，也有不少报表工具内置了 echarts，直接选择图形类型，简单配置分类、系列等属性就可以在报表中展现 echarts 图。如果报表内置的 echarts 图形中不包含要使用的，也可以简单操作就可以引入，具体引入方法参考 报表如何集成 echarts

答案是可以的，只是配置过程比较复杂。Tableau 有两个模块：tableau desktop 用来创建分析；tableau server 用来发布分析。集成的时候需要在 tableau server 中进行二次开发，创建票证、创建视图、兑换票证等一个完整流程都需要用户写代码开发实现。另外，由于 tableau 是一个完整的平台，无法单独拆出来 BI 模块让用户进行深度集成，所以集成时，需进行组织架构信息同步、单点登陆、权限同步等配置操作，工作量不减反而增加很多，实际用起来还是要跳转到 BI 平台上

这个问题不好去去说报表工具更强大或者 BI 工具更强大，因为他们两个在功能上的侧重点不同，所以对于不同的场景适用性也不一样。报表工具不仅能做数据展示和数据查询，还具备数据填报功能。常见的此类报表工具有：raqsoft、fine、smart。BI 工具主要侧重于数据分析，例如可以进行数据钻取、联动、切片、旋转等多维数据处理分析。常见的此类 BI 工具有：tableau，当然国内也有一些 BI 工具例如 finebi、smartbi、dql。不过，现在大部分报表工具已经包含了 BI 的基本功能（有些

实际项目开发中，很多情况会涉及到单据的打印。比如各种证件，发票，快递单的打印，这个功能在报表工具中叫套打，属于比较基础的功能。实现具体设置分为如下几步：1. 将票据所需的背景图，扫描成一张图片；2. 报表中将扫描的图片作为报表的背景图引入；3. 按照背景图调整单元格具体位置，边框等实现单据套打。不过有一点需要注意的是，有些单据打印量会很大，这个时候就需要厂商有大数据打印的解决方案了，否则打印过程中很有可能就卡死了。对于套打，国外报表产品以及 BI 类产品支持得都不好。以润乾报表为代表

word 报告不是简单的把图和表按顺序写上去，而是需要根据需求动态统计数据，根据统计结果来绘制表格或者统计图，那么就会存在一个问题，如果数据变了，那么需要重新修改 word 文档。有了报表工具之后，可以在报表工具中进行数据的预处理和图表排版，这样就解决了手工写报告的问题：数据变动引起的重复性写入。但是这种实现方式也有一些明显的缺点：1）绘制的报表会很长，不方便修改细节设置2）一些细节要求可能会达不到报告本身的要求，例如标题格式、换行 / 页位置等。3）如果客户需求变化，可能会导致重新制作报表，工作

Echarts 由百度研发的开源软件，是一个纯 JS 的图表库。Echarts 是 web 端的技术，前端展现，其在 J2EE 项目中经常被集成使用，图形类型多且直观、生动、可交互、可高度个性化定制。近几年内连续被开源中国评选为“年度最受欢迎的中国开源软件”，并且去年也成为了 Apache 孵化器项目，所以发展更加快速，用户群也越来越多。Echarts 图形展现没有问题，单独的导出也是支持的，但是 Echarts 多数还是被集成到其他页面。比如我们把 Echarts 和报表结合，报表中既有表格内容，

报表工具除了基本的绘制报表，完成数据呈现（也就是让终端用户能看到报表），打印也是报表的基本功能之一。当前报表工具很多，可以按地域、开闭源等划分，包括有杰表、水晶、StyleReport、birt、ireport、润乾、FR 等等，各家打印方式也各不相同，但总的来说，有 activex、applet、flash、pdf 等打印模式。对比来看：Activex 打印：主要是在 c/s 架构时代使用，当时发挥了极大作用的，处理得好且稳定，但随着 web 报表的普及，这种打印控件几乎没人采用了。Ap.

目前的国产操作系统基本都是基于 Linux 为基础进行二次开发，而国内应用的常用报表工具绝大多数是采用 java 语言开发，java 本身支持跨平台，在 linux 上的兼容本身就很好，所以报表工具对国产操作系统几乎都是支持的。包括硬件方面，经测试基于国产系统和硬件环境，也基本不会有什么问题。Linux 操作系统安装润乾报表一文中就介绍了 Linux 下安装配置报表工具的过程。但是，国产芯片的运算性能相对较低，经常要扩大集群规模才能达到国外芯片同样的性能，或者就只能应用于边缘业务。而报表业务常常伴随着强

报表工具中最成熟常用的基本都是桌面设计器，但是 web 在线制表工具也占有部分市场，这是因为它也有一些优点：1、报表设计和发布都在 web 端，无需额外安装桌面设计器2、web 在线制表工具可直接作为报表服务共享使用，用户体验好些但同时也存在着一些无法避免的缺点：1、web 制表工具大部分是用 js 写出来的用户体验，那么会存在一个问题：速度不够。2、web 制表工具所有的操作都是在浏览器中完成的，而工具本身无法接管浏览器的一切动作，对浏览器动作的可控性低导致其稳定性差。3、对浏览器

报表工具最常用的功能是对数据进行统计分析，那么它也支持数据采集功能吗？答案是：不一定。国外报表软件或者开源报表工具一般面向数据统计展现需求，对于填报、数据采集需求没有对应接口和功能；国内报表工具基本都带了填报功能，那么如何确认对数据采集的支持程度呢？可以通过以下几点进行数据采集功能验证：1、 人性化输入控件是否支持常用的下拉列表、复选框、下拉树等编辑风格；是否支持异步加载功能；是否支持控件间的动态关联。2、 Excel 支持性是否支持 excel 导入；是否支持数据校验 / 自

常用的数据文件格式比如 excel、csv、txt、xml 等，报表工具里边读取数据需求还是比较常见的，常用的方式大概是如下两种：一：通过 api 实现，目前报表工具 java 开发的比较多，大多带自定义数据集功能，可以通过接口程序读取对应的数据文件，这种方式也是以前比较常用的方式。二：随着需求的增多，做的好的报表工具都将这个需求内置到报表工具里了，也就是直接设置下文件名称就可以读取里边数据这两种方式都能实现，包括现在也有好多开源的代码拿过来使用，但是现在面临一个问题，如果数据文件比较大，原有的

在使用报表过程中，打印是必不可少的功能之一。当前常用的报表工具中，涵盖 applet、flash 及 pdf 打印多种方式。当然，Web 报表在浏览器端展现后也可以用浏览器自带的打印来完成，但这个是针对整个页面的，不仅对应报表部分，所以报表内容以外的信息也会被打印且不能连续多页打印。上面提到的打印方式中，除了借助浏览器本身的打印不需要安装插件外，其他的都是借助各自插件实现打印，原则上都要安装。只不过有的已经通过其他程序需要安装好了。具体来看：Applet 打印：需要 jre 环境，所以需要

自助报表主要的功能是业务人员在 web 端通过鼠标拖拽或者一些设置，实现数据的自助分析并形成报表（或统计图），这类需求的大多数厂商都能够满足需求，接下来就要看一些细节方面的问题：一：项目中是只有自助报表需求还是由复杂的固定报表 + 自助报表来组成，这样就要看下复杂的固定报表是专门采购报表工具来实现，还是和自助报表采用统一的工具。二：自助报表在 web 端操作，同样要集成到客户自己的系统中，比如 OA、ERP 等，这样就要看下工具是否能够被灵活集成、web 端样式是否能灵活修改和客户业务系统保持一致、

这个选择题应根据使用人群和需求来确定。如果是终端用户，自身有些使用工具和写 sql 的能力，但说到开发个报表管理系统却无能为力，这类用户就适合选择完整平台带开发工具的产品，平台多数独立使用，只需要报表工具拓展开发出想要的报表，借助平台功能发布一下就完事儿，另外还可借助其它功能，管理用户了、基于组织架构分配权限了等一系列后续工作，系统上线方便快捷。如果是软件开发集成商，那就优先建议选择报表中间件集成（不过这里也会有坑，集成商往往会被报表厂商演示过程中丰富的平台类功能吸引，但需求却只是需要在项目中嵌入报

大屏其实就是把多个组件元素整合到一个大的页面上展现。常规的不是太复杂的大屏，一般的报表工具中的 Dashboard 功能就可以实现。开发人员可以借助报表工具对布局进行设置，根据不同场景选用背景图，以及统计图形，加上合理配色，就可以做出一个下图这样可自适应屏幕的大屏展示效果。更为酷炫的复杂大屏，那就要在页面上下功夫，例如下面的这种效果，需要美工和工程师一起做了。这种大屏即使工具厂商不同，但实现方式也都基本一样，报表工具负责提供组件和框架，提供的组件如果能很方便组合，布局，增加动效.

目前，做手机报表的工具主要有两种类型：一种是提供移动端 APP 的，一种是 HTML 解析方式的。提供通用移动端 APP的，这种无法定制出自己需要的效果，因为 APP 中报表数据展现，需要根据不同用户使用场景，提供不同的功能。其实即使是同一个功能，也要根据用户不同的使用场景选择不同的展示形式。外围部分还是只能由应用开发人员实现，所以，提供 APP 的产品不仅不便于集成，即使做了大量修改后也未必能用起来。HTML5的解析方式，报表作为被集成的中间件产品，使用 HTML5 的解析方式，更加轻量化，调用报

BI 从早期提出的概念上来划分可以分为数据仓库、ETL、olap 和报表这几部分可以看到报表只是 BI 中的一个组成部分，只不过数据在 web 端展示时通常是通过报表形式，所以经常会把报表当做是 BI，这个概念比较容易混淆。报表工具的功能这些年都在不断的完善，现在报表和 BI 在功能上已经高度重合了，比如像数据仓库，现在好多报表工具也都有自己的存储数据的一些方式，可能就是叫法上的不同，如果真要区分一个项目中到底是要报表还是 BI 工具，可以通过一个简单的指标来衡量，在做数据呈现时，是侧重固定的报表多些还

目前大多数报表工具都可以从文件中取数做报表，但是支持方式各有不同，这里简单列举下：一：接口方式，报表工具一般支持 api 接口自定义数据集，自己写程序实现就行，这种方式对开发人员技术能力要求极高，比如要写代码读取文件，如果有条件过滤数据代码工作量更大，并且取数性能会有比较大的限制。二：一些报表在第一种方式的基础上做了封装，数据集中直接支持文件数据集，直接选择文件就行，但是这种方式也有一些缺点，如果文本文件数据量比较大，读取性能会比较低，并且往往是将数据直接读取到报表中再进行计算，对报表的计算性能也会