这才是解锁多数据源报表的正确方法
现代报表工具大都支持多源报表，这是一个很基础的功能
功能虽然都有，支持的力度却都不太够，不彻底，并没有真正解决多源报表的难题
报表工具支持的多源过于简单
报表工具在设计报表阶段，可以设置多数据来源
对来自关系数据库的多源数据都支持的比较好，不管是多表，还是多库，都可以，用 SQL 把各个来源的数据都取出来，放到报表中就行
但这种方式，只能解决最简单的多源需求，复杂的需求解决不了，难点也解决不了
多源数据真正的难点
难点一：非关系型数据源难做
进入大数据时代以来，数据不仅是大了，而且存储的方式也多了，除了传统的关系数据库外，还有
1.MongoDB、Cassandra、HBase、Redis 这些 NoSQL 数据库；
2.TXT/CSV、Excel、JSON/XML 等文件；
3.HDFS 等分布式文件系统；
4.webService；
5.ES、Kafka 等其他数据源形式
很多工具就不能直接读取这其中某些来源的数据了，只能通过 JAVA 自定义数据集的方式来读取数据了，就会很不方便
难点二：报表容量和性能压力大
报表工具大都只会读取原始数据，把各种来源的数据全部读到报表中，然后让报表再去算
这就会带来两个问题
一是数据量大时，占用空间容量可能引发报表内存溢出问题
二是全量读取进来后，计算也是问题，这些多源数据常常在业务逻辑上有关联，做报表的时候大部分都会涉及到多个数据源之间的关联混算，在报表呈现阶段做这些关联运算，复杂度经常是平方级的，数据量不大时都没问题，数据量稍大时，到几千行，那性能就会急剧下降了，再好的工具处理这样的运算也会有问题
那能否在报表外算完再把结果给报表以规避容量和性能问题呢？，如果是单数据库，那没问题，写句 SQL 就完了
但现在讨论的就是多数据源问题，就没那么简单了
要么全导入到单库中再算，但这要考虑管理上是否允许这样操作，容量是否够，每次遇到这样的库外数据都要往数据库中放？
然后还得考虑时效，数据的导入都需要时间，量少的耗时短可能无所谓，量大的可能进度都被耽误了，而且一般业务数据都是实时变动的，导入数据的方式也基本很难保证数据的实时性
要么自己用 Java 算，虽然没有入库的一系列问题了，但是开发成本高， JAVA 计算数据的能力很弱，写起来工作量很大，简单做个求和运算都需要写数行代码的循环来实现，更别说逻辑复杂的运算了，动辄几百行的代码，一个报表还可以承受，报表一多，就承受不了这样的高成本了
另外 JAVA 代码需要和项目应用一起编译，也会带来报表和应用高耦合的问题，还会影响报表本身热切换的能力
都不是好办法
解锁多源报表的正确方法
到这里我们其实已经看出来了，问题根源在于报表工具的多源能力太差，然后用外围的方法协助又成本高弊端多
要解决这个问题，正确方法还是要从报表工具本身的多源能力出发，从根本上解决问题
润乾报表就从根本上解决了这个问题，它独创了一个 SPL 数据计算层，直接在工具内就把多源计算的问题解决了
这个SPL 计算层支持常见的各类数据源，非关系数据源都可以直接进行读取，不需要再通过 API 接口开发
比如下面两个例子，它能快速读取来自 MongoDB 和 JSON 的数据并进行计算
| A | |
|---|---|
| 1 | =mongo_open(“mongodb://127.0.0.1:27017/mongo”) |
| 2 | =mongo_shell(A1,“test1.find()”) |
| 3 | =A2.new(Orders.OrderID,Orders.Client,Name,Gender,Dept).fetch() |
| 4 | =mongo_close(A1) |
| 5 | =db.query@x(“select ID,Name,Area from Client”) |
| 6 | =join(A3:o, Orders.Client;A5:c,ID) |
| A | B | |
|---|---|---|
| 1 | =httpfile(“http://125.125.315.88:6868/demo/order.json”:“utf-8”).read() | 读取 Restful 数据 |
| 2 | =json(A1) | 解析数据 |
| 3 | =connect(“oracle”) | 连接 oracle 数据源 |
| 4 | =A3.query(“select 订单 ID, 回款 ID, 客户 ID, 金额 from 回款表”) | 从 oracle 取数 |
| 5 | =join(A2:order, 订单 ID;A4:hk, 订单 ID) | 关联计算 |
原本要做各种转换把数据导入到库里，或者用大段的 JAVA 来写，现在简单几行 SPL 代码就轻松搞定了
而且 SPL 计算层，不仅能轻松读取非关系数据源的数据，它还支持流式计算能力，可以边读取边过滤计算，报表的很多运算都涉及过滤或分组聚合，源数据数据量大，使用 SPL 可以用游标方式计算，只把结果提交给报表
比如我们要从一个270 万行的贷款订单表中，筛选出2018 年以后订单金额 principal 大于 5000 的数据并按用户和年份分组汇总订单金额
如果把 270 万行数据全量读取到报表中来做过滤和分组汇总，一方面会很慢，另外内存也放不下
而用 SPL 游标，简单几行就可以实现过滤运算和分组汇总，再把结果传给报表
| A | |
|---|---|
| 1 | =file(“listinginfo.csv”).cursor@tcm() |
| 2 | =A1.select(auditing_date>date(“2018-01-01”) && principal>5000) |
| 3 | =A2.groups(user_id,year(auditing_date):Year;sum(principal):Total) |
不需要把所有数据都读取到报表内再计算，就可以很大程度减轻报表的容量压力，这里还能支持并行计算提高性能
数据准备层还可以帮助报表内的计算提升性能，把一些报表内原先算的慢的，挪到数据准备层来快速算完
比如刚才提到的数据量大时的关联计算如果放在报表内可能会导致性能急剧下降
但如果把这个关联放到报表外的 SPL 数据准备层来做，就可以使用低复杂的 HASH 算法（而在报表工具中无法对多个数据源先统一处理，实现不了这种算法），那性能就会大幅度的提升了
说在最后
大数据时代，报表多源混算的场景越来越多，越来越复杂，光靠报表工具的那点多源能力，根本不能胜任，靠外围的数据转换或者 JAVA 编码，也是低效困难的方法
润乾报表的 SPL 计算层，简单几行代码就可以搞定多样性数据源的难题，不仅让报表做起来更轻松，更是帮用户省下了大把的人工成本，这才是解锁多源报表难题的正确方法
