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

在报表项目中,客户越来越关注源数据的实时性,希望看到最新发生的数据在报表中体现出来。但是,传统的报表工具+数据仓库+ETL方式很难做到这一点,往往是只能看到昨天、上周甚至是上个月的情况,也就是T+1、T+7、T+30统称T+n报表。很难实现T+0报表,也就是能体现实时信息的报表。

分析其原因在于:1、如果报表的历史数据和最新数据都从客户的生产系统读取,虽然可以实现T+0报表,但是会对生产数据库造成压力,影响客户的业务。2、如果采用数据仓库的方式,那么ETL从生产库中取出数据,需要较长的“窗口时间”,一般是客户下班之后,到第二天早上上班之前,所以客户能看到的最新数据也只能是T+1。3、虽然理论上可以从历史库中和生产库中同时取数据形成实时报表,但是一般的报表工具都不具备跨库取数计算能力,其他的跨库计算方案又比较复杂,很难实施。

可以考虑采用润乾集算报表提供的T+0报表方案,利用集算报表的混合数据源能力实现低成本的实时报表。实现思路是:把不会发生变动的大量历史数据采用数据文件存储,少量新数据从生产库读取,在保证报表实时性的同时,降低了历史数据存储的成本,减少了报表系统造成的生产数据库的负载。传统T+n方案和集算报表T+0方案结构对比示意图如下:

上图润乾计算报表结构中“导出(非实时)”是指在非工作时间(例如晚上),将生产数据库新增数据同步到历史数据的数据文件中。具体实现是采用润乾集算器提供的命令行执行方式,配合操作系统定时任务方式,详见集算器教程。

这里通过“各州销售统计表”来说明一下润乾集算报表T+0方案的具体做法,报表如下:

上图报表中的历史销售数据量很大,来自于数据文件。同时,为了保证报表的实时行,当天的少量数据直接从生产数据库(db2)取出。

具体实现步骤如下:

第一步,在集算器中编写集算脚本sales-state.dfx。

A1:连接预先配置好的生产数据库(db2)。

A2:建立数据库游标,用简单的sql读取销售数据和销售人员的数据。从where条件中的days(current date)=days(orderdate)可以看到,销售数据仅仅读取当天的新数据。

A3:建立预先导出好的数据文件D:/files/sales/sales.b的游标。文件游标可以分批从比较大的数据文件中读取数据,避免出现内存溢出的情况。@b选项是指按照集算器提供的二进制编码来读取文件。

A4:将数据库游标(新数据)和文件游标(历史数据)纵向合并。

A5:利用groups函数,完成对合并后游标的分组汇总。

A6:按照销售总额的降序排列。

A7:关闭db2数据库连接。

第二步,在集算报表中建立db2数据源和集算数据集:

第三步:设计报表如下:

报表中的统计图具体制作方法参见集算报表教程。

需要说明的是,集算报表也支持数据采用其他的方式存储,比如mongodb、hdfs或者传统数据仓库。生产库中的新增数据可以用集算器导出,也可以用其他ETL工具导出。

时间: 2024-08-07 02:34:37

润乾集算报表优化应用结构之实现T+0实时报表的相关文章

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

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

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

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

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

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

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

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

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

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

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

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

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

在报表项目中,常常会碰到数据库压力很大影响整个系统性能的问题.由下面的传统方案的结构示意图可以看出,全部数据存储和源数据计算都放在数据库完成.当并发访问量较大的时候,虽然每个报表的数据量不大,还是会造成数据库压力过大,成为性能的瓶颈.多数数据库厂商提供的jdbc接口传输数据比较缓慢,在并发量较大的情况,对报表系统性能的影响也非常明显. 这种情况时可以考虑采用润乾集算报表提供的本地计算方案. 所谓本地计算,是将一部分计算任务从数据库中移出到报表服务器中完成.大多数有一定规模的应用系统中,数据库和应

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

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

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

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