润乾破解报表开发工作没完没了
很多做数据项目的同学都遇到过报表开发没完没了的问题，总是不断的有新报表要做，老报表要改，原本以为初级工程师就可以搞定的，却始终都得有高级工程师跟着，报表开发没完没了，资源投入也没完没了，一个看似简单的报表模块，却每每成了项目的拖累
为什么会这样呢？
报表没完没了确实是一个无法规避的事实，报表的业务稳定性本身就差，在统计分析过程中，总会催生出新的、更合理的需求，那就需要修改或者做新的才可以，这与实施方和用户的经验无关，谁都避免不了
没完没了不是问题，开发成本高才是问题
但这却并不是报表开发成本要像无底洞一样的原因
就像我们总是有很多衣服要洗一样，但我们却从来没觉的这有多麻烦，更不需要总是投入很多时间去做这件事，因为我们有好用的工具，全自动洗衣机
做报表也有工具可以用，那就是报表工具，但即使用了报表工具，很多项目还是要持续的投入人工成本，这样的状况，归根结底还是因为：工具不给力！
好的报表工具可以大幅度提升制表的效率，但报表开发的难题，并不是只有制表这一部分，还有相当一部分在数据准备上
应用中的报表，有 80% 的数据来源和计算都比较简单，一个简单的 SQL 语句就搞定了，但还有 20% 的情况中，数据准备工作就没有那么好做了，一些过程式的多步骤复杂计算，常常要写很长的多层嵌套的 SQL 或者存储过程才能搞定，如果数据来源再复杂一些，要对各类数据源混算，一些非关系数据库或者文本数据源都不支持 SQL 了，那还得用 JAVA 等语言来写，SQL 十几行能写完的，JAVA 恨不得写出几百行来，编码难度和效率就更糟糕了
然而恰恰就是这仅占 20% 的需要硬编码来做复杂数据准备的报表，可能会占去我们 80% 的工作量，让开发成本陡增
数据准备费时费力是罪魁
没有数据准备能力的报表工具，就相当于一台半自动洗衣机，很多事情都得工程师手工去做，就会耗费很多时间，资源投入才会一直没完没了
遗憾的是，大部分的报表工具，都没有数据准备的能力
有人可能会想，数据源准备，也不属于报表工具的能力范畴啊，所以这个开发困难，成本高的锅不能让报表工具来背，确实是的，数据源准备太困难不能怪报表工具，但仍然属于报表开发的范围，有能力解决这个难题的工具，才能真正解决报表投入没完没了的问题
那怎么解决呢？
数据准备工具化是解决之道
找一个能做数据准备的报表工具就行，润乾报表就是！
润乾报表专注报表领域二十多年，制表能力强劲，中国式复杂报表概念就是润乾率先提出并解决的，著名的非线性报表模型到目前为止仍是行业内复杂报表的标准解法，润乾一直也是业内公认的报表技术专家
润乾很早就注意到了数据准备会耗费了大量人工成本的问题，所以专门开发了数据准备的工具，在原先报表的基础上，集成了集算器 SPL 引擎，实现了工具化的报表数据准备层
润乾报表数据准备带来高效开发
SPL 比复杂 SQL 和存储过程以及 JAVA 的开发都要简单， 也只有比这些简单，才不用去占用高级工程师去写大段的代码，才能实现普通人员快速开发。
比如这个例子：报表中需要计算连续上涨超过 5 天的股票及上涨天数
SQL 写起来是这样的，需要三层嵌套
select code,max(risenum)-1 maxRiseDays
from (
select code,count(1) risenum
from(
select code,changeSign,sum(changeSign) over(partition by code order by ddate) unRiseDays
from(
select code,ddate,case when price>=lag(price) over(partition by code order by ddate)
then 0 else 1 end changeSign
from stock_record
)
)
group by code,unRiseDays
)
SQL 写的不太好的同学很难写出来，用 JAVA 来写的话那要再长十几倍，没法列在这里了。
而 SPL 写出来是这样的
| A | |
|---|---|
| 1 | =db.query(“select * from stock_record order by ddate”) |
| 2 | =A1.group(code; ~ .group@i(price <price[-1]).max(~.len()):maxrisedays) |
| 3 | =A2.select(maxrisedays>5) |
就简单很多，不仅简短，而且易于理解，初级工程师也能很快学会并写出来，实施成本也能降很多
大数据时代，报表的数据来源也是多种多样五花八门，很多 NOSQL，文本数据根本用不了 SQL，报表又需要对它们进行混合计算
那就只能是先都 ETL 到数据库，再用 SQL 算，或者干脆用 JAVA 来混算了，这就又是老问题，困难低效成本高
而 SPL 数据准备层则同样可以轻松解决这些问题，它能直接对接各类数据源，直接对各种格式数据进行计算
开发过程很简单，比如这个来自 HTTP 的 JSON 数据和来自 ORACLE 数据的混算，SPL 五行就可以做完，但 JAVA 或 SQL 就不知道得写多长了。
| 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) | 关联计算 |
数据准备层让开发变的简单，大大缩短了报表的开发周期，比如下面这些实际案例：
开源 SPL 缩短石化集团多维多层叉乘报表开发周期 120 倍
开源 SPL 缩短电力集团采购额月度走势报表开发周期 4 倍
还可以让初级工程师搞定高难问题，大大减少了人力成本
还能顺便优化应用架构
数据准备使用存储过程，中间表和 JAVA 等技术时，会导致这些过程和数据库还有应用产生耦合，随着系统不断的开发使用，它们会慢慢的累积起来，耦合会越来越严重。危害很大，很要命
比如与数据库的耦合
报表开发人员，原本只需要写 SQL 做报表，但用到存储过程和中间表，就需要动数据库，就得赋予相应权限，就会有安全风险
随着时间的推移，这些会变的越来越多，又不好管理，不能随意删除，就只能一直占用着数据库资源，影响容量，满了还得花大价钱扩容
它们还要计算，甚至有些已经弃用的也仍然在定期计算，会抢占数据库关键业务的计算资源，带来性能问题
它们一般都需要高级一些的工程师来编写，还有可能麻烦 DBA，人员成本就会变高
这些都是存储过程和中间表耦合带来的危害。 SPL 数据准备层则不会有这样的情况，因为它是存在数据库外面的，与报表模版存在一起，自然也就不会有存储过程那些安全风险和耦合的问题
需要中间表的计算，SPL 则可以把中间数据存储在数据库外，放到文件系统中，像文件一样去管理，就不用再担心冗余数据占用昂贵的数据库空间了。文件还会比数据库有更好的 IO 吞吐性能，相关计算也会更快
数据准备层本身还有计算能力，而且又把存储过程和中间表这些原本占用数据库计算资源的包袱都卸掉了，这样报表的计算大部分就放到库外了，数据库就可以去做更重要的关键业务计算了，不会被报表影响了
Java 程序与应用的耦合危害也很大
JAVA 代码需要和应用一起编译，报表的业务稳定性又低，总得加新的，改旧的，就得总改代码，重新编译，应用就得停机重启，严重影响了服务的稳定性和持续性，这是很致命的问题。
同样，写 JAVA, 就得 JAVA 人员，成本会更高
SPL 数据准备层也能很好的解决应用耦合的问题，它写出来的脚本也是类似报表模板的外置文件
不需要和主应用程序一起编译打包，而且它是解释执行的动态语言，在修改时不会涉及主应用程序，只要把脚本替换就可以，天然就支持热切换
使用 SPL 做数据准备，顺带就把应用架构也优化了，这些耦合的问题就都不存在了，就可以大幅度减少系统维护的工作，进一步节省出更多的人工成本了
再提升报表性能改善用户体验
性能问题也是投入资源很大的一个地方，报表如果性能不好，上线后就会有很多性能问题涌现出来，就得不断安排高级工程师去优化解决
数据准备层还对于报表性能的提升有很大帮助，可以释放更多人力资源出来
SPL 数据准备层采用全新的算法，比 SQL 的算法更高效，很多场景都比 SQL 算的要快很多
大数据量的情况下，有些数据库的 JDBC 取数太慢，会导致了性能问题，SPL 则可以通过并行取数方式数倍提升数据的传输性能
SPL 数据准备层要比报表本身的计算范围更广，能力更强，完全可以把原先要在报表中进行的性能低下的运算放到数据准备层中高效计算，这样大数据时代下报表的性能也一并都解决了
全面工具化让报表开发全自动
有了数据准备能力，润乾报表就将报表制作全面工具化了，让做报表从半自动洗衣机变成了全自动洗衣机
做表做得快，数据准备快，就可以大幅度提高效率，降低成本了，可以低成本应对，也就不怕报表多了，做的快，做的好，报表没完没了的问题也就解决了
