原文地址：http://c.raqsoft.com.cn/article/1571024764129?r=CGQ
原地址可以下载更清晰的pdf版
报表选型中那些想不到的
坑
传统的选型是什么样的？
找厂商应答
自己根据项目需求想一个或者找一个
自己去验证
需求列表
这么选的结果如何？
你信了他的邪，你就掉进了
Keng
坑
你信了列表，你也掉进了
自己跟着列表测
厂家说：我们都满足！！！！！
什么原因造成了这样的结果？
列表太过宽泛，不够专业， 没有抓住验证的重点
厂家一看，确实写得我都满足
自己一测，写的也基本都满足
用进项目中，很多没想到
得知道坑在哪里才能不掉坑
找到那些坑 实际去验证看它到底行不行？？？
怎么样能不掉进坑？
报表选型中都有哪些坑？
乔布斯说：到处都是坑！！
目录页
01 开发工具
02 数据源
03 报表模型
04 呈现输出
05 自助报表
06 集成部署
07 填写采集
08 报表平台
09 性能
CONTENTS
开发工具
★是否提供独立安装的本地报表设计器 1
★布局方式是Excel式的还是控件式的 2
★能否直接将excel转换成报表模板
3
……. 4
5
6
7
要桌面设计器还是web设计器？
Web设计器：看着高大上，其实是鸡肋 行走江湖这么多年，没有几个真正用web设计器
设计报表的，影响 web应用稳定性，开发效率低。这个需求不提也罢
桌面设计器：必须 开发效率高，不会因为设计阶段的问题影响web应用。本质上报表
工具是给程序员用的，您见过哪个成熟的开发工具是WEB的？
桌面设计器稳定、功能全面、开发快捷
web设计器功能不全，受网络、服务器影响开发效率低
这个其实问一下工程师的感受就知道了，基本没有工程师愿意选择web端制表
布局方式是Excel式的还是控件式的？
Excel式的更直观，易上手，易操作
国产货大都都是Excel风格的，都满足，不用考察
其他方式的，控件式 条带拖拽式等，都不易摆放，不易对齐，设计不便
国外产品和开源产品很多都这样，可以批量放弃
控件式设计器，是不是看着就很陌生，无从下手
完全和我们平时看到的表格不一样，增加学习成本不说，即使学会了也不好设计
需要集成到eclipse中的，更费劲
各种依赖包，驱动，汉化，就得折腾一天
问自己一下：工程师一人天多少钱，每个工程师各浪费1人天，多少钱？是在省钱还是烧钱
能否直接将Excel转换成报表模板？
显然这样会很方便，业务报表经常已经有Excel的表样，直接读入省得再画。
也是国内的基本都满足，不用考察
国外的有些就不行，得完全手工重新画，工作量多出了很多
目录页
01 开发工具
02 数据源
03 报表模型
04 呈现输出
05 自助报表
06 集成部署
07 填写采集
08 报表平台
09 性能
CONTENTS
数据源
★非关系数据源是如何访问的？ 2
★txt，xls，xlsx，csv文件做为数据源支持情况 3
★报表可否同时从多数据源中取数
4
★特别要注意：SQL植入的安全问题 5
6
7
★对关系数据库的支持该怎么验证？ 1
关系数据库的支持该怎么验证
Oracle、DB2、SQL Server、MYSQL、INFORMIX
达梦 金仓 Gbase
。。。。。。。。。。。。。。等等 一大堆我都支持
是不是写得越多越牛？
其实这项不用考察，只要是关系数据库，写上的没写上的统统都会支持，因为这是世
界标准，列更多并不更值钱！
可访问的非关系数据源种类
1）不能简单相信“支持xx等”的说法，咱们需要
什么，必须自己想清楚，然后去验证
2）所谓的支持，是直接做好读取功能，还是只给
个二次开发的接口 ，这二者是完全不同的
文本数据源都会有，但是大数据量的呢？
txt，xls，xlsx，csv文件做为数据源，大部分国产的都允许，有些开源和免费的不行
BUT
你的读取方式是啥的，是流式读取的吗？如果不是，那大数据量肯定卡死，怎么解决
多数据源取数又如何
也是都号称支持
实际要看看自己都有哪些种类的数据源
文本
Webservice
hive
来自这些地方的数据能否同时在一个报表中关联，实际测一下就能刷掉一批
SQL植入的安全问题
参数查询 SQL相对固定，基本无风险
通用查询 语句替换，非常灵活，但是却可能泄露数据库信息哟！
该怎么防范？那就去问问报表厂商呗。
什么？没搞懂是啥意思，猛戳这里：报表的 SQL 植入风险及规避方法 - 乾学院
或者搜索 乾学院 再搜索文章标题
目录页
01 开发工具
02 数据源
03 报表模型
04 呈现输出
05 自助报表
06 集成部署
07 填写采集
08 报表平台
09 性能
CONTENTS
★分组交叉列表报表 1
★动态格间运算，支持跨行跨组的运算，支持独立
格的运算
2
★多级的分组与交叉报表，不规则分组，例如按段
分组、条件分组
3
★排名、同比、比上期、环比等设置 4
★表头横向纵向双向锁定 5
6
7
报表模型
报表模型
分组交叉列表报表的验证
什么？？？？这么简单的功能也是坑？？？？
对，是
坑是啥，是不要被列表误导去验证这些大家都支持的，在简单报表身上都不用浪费时间，
都支持！！！！！
中国式复杂报表的验证
来
我们挨个看看 哪里复杂
复杂表样
多片区整合、多表关联、复杂报表、条件汇总
复杂计算---特殊分组
不完全划分
（例如类别为：其他）
单片说明：
复杂计算---跨行组计算
排名
同期比
无规律跨格计算
·····
特殊分页需求
每页固定行数
分页汇总
补足空行
特殊分栏需求
按纸分页、横向分栏、数据明细
目录页
01 开发工具
02 数据源
03 报表模型
04 呈现输出
05 自助报表
06 集成部署
07 填写采集
08 报表平台
09 性能
CONTENTS
呈现输出
★图形种类是否全 1
★集成第三方统计图组件，如echarts，D3等，并
可以导出打印
2
★三种打印方式：applet、flash、pdf
3
★将报表结果、文本、图片等插入word模板中 4
★大屏 DashBaord 5
★移动端该如何支持？ 6
7
统计图种类该怎么考察？
不用考查
很多人喜欢把这个列一大堆，纯属多余。常见图形对任何成熟报表工具全都支持
而且还有很多开源图形包，要啥有啥；太特殊的真没有，也是到处都没有，只能自己做
是否支持种类更全第三方的统计图，才应该是考察重点
Echarts等第三方统计图的集成
为什么必须有？因为人家 漂亮 全面 简单，而且还 不要钱！！
有两个要点要验证：
1）是否内置支持，而不是开放接口
2）是否可以导出打印，图表不是光看就可以的，而这常常是开源包本身不提供的咯
坑的解读
★支持集成第三方统计图组件，如
echarts，D3等
工具中集成第三方图，可直接使用，不
需要通过二次开发方式引入
★echarts统计图也支持打印导出
前端动态的echarts图做为报表的一部
分打印或者导出成文件，不需要二次开
发操作
几种打印方式
APPLET打印 PDF打印 FLASH打印
word报告式报表有集中实现方式
只能在设计器中硬排版是不够的！！！！！！！
需要支持把报表实时插入到已有word中才可以，更方便
不要问我能不能做大屏
很多人觉得做大屏是报表工具的重要功能，其实呢：
大屏Dashboard主要是图，这是图形包以及程序员+美工的本事
程序员管数据、美工管样式、图形包负责呈现
其实没报表工具多少事！用不用工具，工作量都一样！
报表工具无非就是把图形包封装一下，省那么一点点从数据库取数的工作
坑的解读
简单的大屏
报表工具就是起个页面框架作用，
费功夫的内容还是这些图表
坑的解读
牛B的大屏
是美工精心设计再加工程师努力
实现的，工作量少不了。
报表工具仍然只是个框架
移动端应该怎么测评？
一个对所有用户都是一样的固定的移动端app，能直接拿来用吗？？？
答案显然是：用不了！每个应用都需要自己的APP，报表工具直接提供APP毫无意义！这
一项完全不用考察
那应当提供啥？
支持H5的输出，并且有demo让用户可以参考功能开发
目的是让应用程序员能方便地做出一个自己的APP，或者把报表功能嵌入到已有APP中！
目录页
01 开发工具
02 数据源
03 报表模型
04 呈现输出
05 自助报表
06 集成部署
07 填写采集
08 报表平台
09 性能
CONTENTS
自助报表的坑
★自助报表不是万能的！！！ 1
★支持排名、占比、环比、同比等指标计算 2
★是否可以一次建模满足多种跨表关联查询
3
★是否可被集成，是否提供源码供客户改造 4
5
6
7
自助报表不是万能的，上一套BI就啥也搞定了？
绝对不可能！！！！
目前市面上的BI，多维分析，自助报表，都做不了复杂的报表
比如上面提到的中国式复杂报表，就必须得用固定报表工具来做
排名、占比、环比、同比能直接做吗
很简单
实际验证下就可以
是否可以一次建模满足多种跨表关联查询
一次性建模，有新的关联查询需求时并不需要更新模型，
只有数据库中表及字段以及关联发生了改变才要再次改造模型
用下一页的验证示例，能卡掉一大半厂商哈，一般人我不告诉他
验证例子
老板说：明天我想针对每个销售，把上半年的订单情况做一个分析
工程师想：分析销售订单情况，需要 订单表、订单明细表、雇员表，于是做了cube，把
三个表做了关联
第二天：老板忽然又想针对省份，和客户做一下分析
工程师蒙了。因为他的CUBE里没有加地区表和客户表，老板也太坑了，又得重新改模型
了
不是老板坑，而是工具不给力，能被这一条卡到重新建模的工具都不是好工具
大宽表是解决方案吗？
有人会问：那我一次性把能想到的表和列都加到一个大 表里
不就行了吗
大宽表确实是大家常用来对付这件事的手段，也有一定效果
但是：坏处是空间太大，性能差
而且还是有搞不定的情况，比如自关联
能把数据结构以层次形式呈现并自动生成JOIN才是解决方案
是否需要集成和改造，要想好！！！
想一想，是否需要把自助报表功能嵌入到自己的页面中？
想！那就要考查自助报表是不是可集成，能不能被改造了
很不幸，大部分厂商提供的产品都无法被集成，也不允许用户自己改造
因为自助报表功能需要元数据支持，是在一个完整应用系统内的东西，很难将这一个功能
集成到别的应用中了
不能被集成，又不给源码，那就只能祈祷厂商给定制了，阿门。。。
目录页
01 开发工具
02 数据源
03 报表模型
04 呈现输出
05 自助报表
06 集成部署
07 填写采集
08 报表平台
09 性能
CONTENTS
集成部署
★支持与javaweb程序无缝集成
1
★报表支持热加载 2
★对集群的支持
3
★安全问题 4
5
6
7
能与javaweb程序无缝集成
无缝嵌入式集成
方便项目管理，报表作为整个系统的一部分，
统一使用用户系统的权限，流程等
大部分java项目，都愿意报表工具可以无缝集
成
不能无缝集成呢？
那就只能独立部署，然后调用了
当然独立部署也有一定的好处，可以把报表和
应用分离，互不干扰
但更多的是不便之处
要管理两个应用 两个服务器
要考虑调用的安全性，或者单点登录
报表支持热加载
大部分厂商都可以做到报表热加载了
如果做不到，那就会有大问题，谁的生产机也不可能会让频繁重启
但是如果报表中用到了程序数据源，这个就多半做不到热加载了
现在有一些厂商有数据中间层，数据中台的产品，可以做到热加载，这个是加分项，20%
困难的报表基本都会用到程序数据源
程序数据源的热加载
怎么才叫支持集群
应用都可以部署到集群上的 但这只是初始阶段
真地要支持集群，得有集群缓存同步的本事才行
访问A节点计算完的报表，再通过B节点查看就不用再算了，缓存已经同步，直接用就可
以了
如果没有缓存同步，那跳转了节点就得重新算，性能会损失很多；这个所谓的集群就不是
个整体，只是一堆独立机器的集合而已
安全问题很重要，但却不用考查
报表作为中间件产品，总是要嵌入到用户的系统中的
大部分安全问题，就该由主应用系统来负责了，报表工具不用管也管不了
不过前面说过的SQL植入问题除外，需要报表工具配合一下哈
目录页
01 开发工具
02 数据源
03 报表模型
04 呈现输出
05 自助报表
06 集成部署
07 填写采集
08 报表平台
09 性能
CONTENTS
填写采集的坑
★输入控件评测重点在哪
1
★可以用Excel中离线填写，并能复制Excel内容填
写
2
★能不能让业务人员不依赖于数据库进行自定义填
报，并自行生成统计表
3
4
5
6
7
输入控件评测重点在哪？
1.种类要多？
种类不用考察，号称支持填报的产品都会提供，各种下拉控件，复选框等
2.性能
这才是重点！必须有异步加载功能，因为一些下拉框，下拉树，数据量大的时候，如果没
有异步加载，就卡死了
3.动态关联
各控件之间要有动态关联能力（关联过滤，级联）
Excel导入填报重点看啥？
1. 填报模板能生成带有校验或自动计算的Excel
2. 导出的excel编辑后，可重新填进填报模板
3. 以上功能要包括复杂格式填报，而不仅仅是简单行式的（见下页示例）
简单行式excel导入填报，谁都可以做，做不了才怪
4. 导入的excel数据量大时，可以设置分批加载
导入填报示例
比如这样的表，能不能和填报模板对应起来，不写代码就能正确采集数据入库？
业务人员自定义填报
业务人员设计上
传填报模板
各级人员填报
自动汇总
数据分析
Excel离线填报
业务填报如果支持的不好会怎样
找技术去搞
搞技术去
因为需要填进数据库，
而填进数据库需要做
结构化，要懂数据库
原理
为啥要找技术？
1.自动结构化
2.不用数据库汇总
分析
因为要再汇总分析，
不计算的数据填报
上来也没意义
为啥要填进数据库？
那咋办？
这种表入库时会对应多个数据表，还有主外键关联！你想业务人员能自己造出
数据结构吗？
目录页
01 开发工具
02 数据源
03 报表模型
04 呈现输出
05 自助报表
06 集成部署
07 填写采集
08 报表平台
09 性能
CONTENTS
报表平台的坑
★是否开源
1
2
3
4
5
6
7
系统功能是否开源
用户组织、权限、调度、这些功能点其实都 不 用 考 查
一方面，只要喊报表平台，这些功能一定有，而且都差不多
另一方面，这些东西和应用环境密切相关，肯定不会全适合，到了现场反正还得改
所以，还不如问问是不是开源，或者是不是提供定制修改的服务？要收多少钱？
目录页
01 开发工具
02 数据源
03 报表模型
04 呈现输出
05 自助报表
06 集成部署
07 填写采集
08 报表平台
09 性能
CONTENTS
性能如何评测
★几种不专业的说法
1
★数据准备阶段的性能 2
★报表呈现阶段的性能
3
4
5
6
7
什么说法不专业
• 我们可以支撑多大多大数据量
• 千万数据几秒可以响应
不说场景，只说性能是不负责任的
在自己设计的场景下跑的快，未必在用户的场景下就灵
数据准备阶段的性能
大部分的性能问题，都出在数据准备阶段！！！！这时候考查报表工具的性能没有意义
• 数据量太大，不会异步加载
• jdbc读取慢
• 计算太复杂，需要复杂sql或者长存储过程
这些其实不该归罪与报表厂商，因为没有报表时候他们本身也慢
当然，如果厂商有数据计算工具，计算层来解决这些问题，那是应该加分的
报表呈现阶段的性能
少部分情况下才会体现报表本身的计算性能
怎样才能测出纯报表的性能
抛开数据准备的时间，单独统计报表运算的时间
• 多数据集关联的复杂报表
• 带部分明细的分组汇总表
可以用上面的两个例子来测试对比看看哪家的工具
计算能力更强
按着先烈们趟出的这些坑
挨个去评测
就可以排除掉一大部分了
开源的、免费的基本都不灵
功能不全，bug太多
总结！！！
然后就是从幸存者当中再筛选了
看您更看重什么
价格？
品牌？
服务？
然后！！！
THANKS