润乾集算报表优化应用结构之本地计算

在报表项目中,常常会碰到数据库压力很大影响整个系统性能的问题。由下面的传统方案的结构示意图可以看出,全部数据存储和源数据计算都放在数据库完成。当并发访问量较大的时候,虽然每个报表的数据量不大,还是会造成数据库压力过大,成为性能的瓶颈。多数数据库厂商提供的jdbc接口传输数据比较缓慢,在并发量较大的情况,对报表系统性能的影响也非常明显。

这种情况时可以考虑采用润乾集算报表提供的本地计算方案。

所谓本地计算,是将一部分计算任务从数据库中移出到报表服务器中完成。大多数有一定规模的应用系统中,数据库和应用服务器通常会部署在不同的物理机器上。其中,数据库处于中心地位,要为各个应用系统提供服务。如果运算大部分由数据库完成,则会导致数据库压力过大,而数据库的扩容成本和难度都相当高。而应用服务器则不同,不同应用会有不同的应用服务器硬件,且容易集群扩容。如果能将一部分运算移出数据库,转而由与应用服务器一起部署的报表服务器完成,则会很大程度地减小数据库压力,并且充分利用应用服务器所在机器的计算能力,提升系统性能。集算报表方案结构示意图如下:

从上图可以看出,润乾集算报表可以将部分数据从数据库转移到报表应用服务器的本地硬盘。这部分数据可以是计算的中间结果,也可以是部分基础数据。集算报表内置了集算引擎,可以通过简洁的脚本进行本地化的数据计算。因此,从数据存储和计算两方面都可以降低数据库压力。

部分数据和计算从数据库转移到报表应用服务器上,可以充分利用应用服务器集群的存储和计算能力。应用服务器无论是单机升级(纵向扩展)或者增加集群数量(横向扩展)都要比数据库服务器的成本低很多。在本地硬盘上读取数据的速度要比数据库jdbc快很多,可以解决这个瓶颈问题。集算引擎还可以进行多线程的并行计算,可以充分发挥应用服务器多cpu、多核的计算能力。因此,润乾集算报表方案是低成本提高报表应用系统性能的优选方案。

下面,通过“某公司客户累计销售额与去年全年销售额对比报表”的制作,来看一下集算报表是如何实现本地化计算的。报表如下图:

这张报表中的客户、订单数、销售额都是直接从数据库中计算的2010年1月-10月的数据。2009年全年的订单数、销售额是从报表应用服务器文件系统中的temp2009sales.b文件中读取。“销售额/去年销售额”则是今年和去年的数据共同计算的。报表上部的查询按钮是集算报表提供的“参数模板”功能,具体做法参见教程,这里不再赘述。

首先,要提前用集算器从数据库中读取2009年等各个年份的销售数据,计算好之后,以集算器的二进制编码导出到temp2009sales.b文件中,每年一个文件。中间数据制作好之后,数据库中2009年的数据就可以移除备份了,不再占用数据库的空间。

第二,编写集算器脚本salesProportion.dfx如下:

注意,脚本的参数是:argyear(要查询的年份),argmonth(要查询的月份)。

A1:连接预先配置好的数据源demo。

A2:从数据库中计算取出要查询的年份订单数、销售额。

A3:从前一年的数据文件中取出数据。

A4:将A3中的数据按照A2中的CLIENT字段对齐,A2中有A3中没有的补空行。

A5:利用A2来生成新的续表。其中增加了A4的对应行数据,比如A4(#).C:lastCOUNT就是A4的对应行(#是A2的当前行号)中取出C字段。

A6:关闭数据库连接。

A7:向报表返回结果集。

第三,在集算报表中定义报表参数(argyear、argmonth)和计算数据集:

上图中,参数名是指dfx定义的参数名称,参数值是指报表提交给集算引擎的值。这里是将报表的两个参数的值传递给集算器的同名参数。

第四,设计报表,如下图:

输入参数计算后,即可得到前面希望的报表。

时间: 2024-10-01 05:44:41

润乾集算报表优化应用结构之本地计算的相关文章

润乾集算报表优化应用结构之报表数据源复用

在报表项目中,经常有多个报表的数据源计算方法有共同的部分.使用润乾集算报表,采用可挂接算法的方案时(可参考[润乾集算报表优化应用结构之可挂接算法]),可以更方便地将这些共同部分用同一个脚本来完成,从而实现算法复用.算法复用的好处是:一个算法只实现一次,不会出现同一个算法多处实现导致不一致的情况.同时也避免一个算法实现很多次的重复劳动,减轻工作量. 下面通过两个报表复用同一个算法的例子来看一下具体的实现方法.报表1是"员工绩效工资明细表",可以按照STATE来选择不同的员工例如:STAT

润乾集算报表优化应用结构之混合数据源

在报表项目中,报表源数据常常会来自于多种异构数据源.例如:关系型数据库(oracle.db2.mysql),nosql数据库(mongodb),http数据源,hadoop(hive.hdfs)甚至是excel或者文本文件.通常的做法是采用ETL工具,将这些数据源都同步到数据仓库中.但是这样做的问题在于:1.配置复杂,难度较大:2.成本较高:3.数据无法实时访问,需要有较长时间的延迟:4.数据仓库的建设和管理都比较复杂:5.如果数据量很大效率会很低,而且要不断的ETL去各个应用系统同步数据:6.

润乾集算报表优化应用结构之实现T+0实时报表

在报表项目中,客户越来越关注源数据的实时性,希望看到最新发生的数据在报表中体现出来.但是,传统的报表工具+数据仓库+ETL方式很难做到这一点,往往是只能看到昨天.上周甚至是上个月的情况,也就是T+1.T+7.T+30统称T+n报表.很难实现T+0报表,也就是能体现实时信息的报表. 分析其原因在于:1.如果报表的历史数据和最新数据都从客户的生产系统读取,虽然可以实现T+0报表,但是会对生产数据库造成压力,影响客户的业务.2.如果采用数据仓库的方式,那么ETL从生产库中取出数据,需要较长的"窗口时间

润乾集算报表优化应用结构之减少存储过程

在报表应用中经常会使用存储过程实现报表的数据计算,但这会带来多方面的问题.存储过程的包只提供一层分类,无法用树形结构,容易造成代码管理混乱.有些程序员直接在现场在线修改存储过程,也不利于代码管理.升级存储过程的时候需要数据库的写权限,会对数据安全性造成影响.同时,由于SQL固有的一些问题(数据无序.缺乏集合.无法引用.分步不彻底)等,使得存储过程的编程比较困难. 很多情况下是为了提高性能而选择存储过程,但实际效果也不尽如人意.这主要是因为报表数据的计算一般都比较复杂,很难用SQL直接完成,需要通

润乾集算报表优化应用结构之可挂接算法

在报表项目中,有些报表的数据计算方法会经常改变.例如:某企业员工的实际工资是通过绩效得分计算出的,算法经常变动,需要在不改动其他代码的情况下用新算法替换旧算法.如果用Java来实现计算的话,虽然可以实现动态可挂接计算模块,但是存在缺乏基础类库.占用多余内存等问题. 采用润乾集算报表可以很好的解决这些问题,实现低耦合.热部署的动态挂接算法.集算报表挂接算法系统结合和其他报表工具+java的系统结构对比图如下: 上图可以看出,java程序必须要编译.打包才能更新.集算脚本是解释执行的,脚本文件同时也

润乾集算报表优化应用结构之报表复杂数据源的管理

在报表项目中,常常有些复杂数据计算是为一个报表专用的,其它报表用不到.可以用SQL实现写进报表数据源中,但由于SQL无法分步计算,经常会写出非常复杂难懂的长语句,不利于调试和维护.如果用Java或者存储过程来实现,计算程序会和报表模板又会分开,不利于管理.使用润乾集算报表的脚本数据集来实现报表专用计算,既可以写出简单易懂的分步骤计算脚本,又可以将脚本存放在报表模板中利于管理.系统结构的对比如下图: 下面通过一个具体的报表例子来看一下集算报表脚本数据集的用法.<年度客户销售分析报表>可以选择年份

润乾集算报表优化应用结构之数据分库存储

报表项目中,可能会出现报表源数据来自于不同数据库的情况.这是因为同一张报表可能会从多个业务系统取数据.例如:员工信息从人力资源系统中取出,销售数据从销售系统中取出.还有一种可能是,同一应用系统的数据库负载太大,不得已分成多个数据库的情况.例如:销售系统数据分成当前库和历史库. 报表工具需要连接的可能是同样类型的数据库,比如都是oracle或者db2:也可能是不同类型的数据库. 报表应用中,数据分库存储的解决办法有:1.建设专门的数据仓库:2.利用跨库访问的技术. 专门数据仓库的建设和管理比较复杂

润乾集算报表提升性能之过程优化

报表出现性能问题需要对数据源计算进行优化时,执行路径难以确定从而被干预是阻碍报表优化的难题之一.由于数据库执行路径对开发人员不透明,报表优化需要指定执行路径时,程序员会很难甚至无法干预.而一般报表工具不具备强计算能力,大部分计算仍然要依靠数据库进行,这就导致很多报表优化效果不理想. 不同于一般报表工具,润乾集算报表内置了专门用于数据计算的集算引擎,开发人员可以通过编写集算脚本完成报表数据源准备.与数据库执行SQL路径不可控相比,集算脚本的执行过程是可控的,开发人员可根据实际情况编写或更改计算执行

用润乾集算报表实现实时报表(T+0)的方案

在报表项目中,客户越来越关注源数据的实时性,希望看到最新发生的数据在报表中体现出来.但是,传统的报表工具+数据仓库+ETL方式很难做到这一点,往往是只能看到昨天.上周甚至是上个月的情况,也就是T+1.T+7.T+30统称T+n报表.很难实现T+0报表,也就是能体现实时信息的报表. 分析其原因在于:1.如果报表的历史数据和最新数据都从客户的生产系统读取,虽然可以实现T+0报表,但是会对生产数据库造成压力,影响客户的业务.2.如果采用数据仓库的方式,那么ETL从生产库中取出数据,需要较长的"窗口时间