码迷,mamicode.com
首页 > 其他好文 > 详细

复杂报表复杂在哪?

时间:2015-05-11 18:21:30      阅读:224      评论:0      收藏:0      [点我收藏+]

标签:复杂报表分析   复杂数据源   报表数据源   集算器   集算报表   

  报表开发者总会遇到一些较为复杂的报表,这类报表的数目通常很少,但花费的开发时间却很多,有时候还会变成疑难问题。本文将讨论这些复杂报表到底复杂在哪方面,以及该用什么方法去解决,希望对提高报表的开发效率有所帮助。

  以前的复杂报表主要复杂在前端:

n  单元格合并,斜线表头。

n  字体风格根据数据大小发生变化。

n  任意单元格之间的计算。比如针对几条特殊的明细数据,计算它们和汇总值的比例。

n  片区之间有规律的计算。比如横向表头是产品分类,纵向表头由两种分组拼成:三层机构分组、单层年度分组,交叉处要显示某类产品在不同分组中的销售额。

n  不规则分组。比如按照州、州府间隔显示各州的产品销量(总计时不能重复计算州府的销量)。

  

  报表工具经过十年的发展,上述前端难题大都已经得到了妥善的解决,比如Style ReportRunqian ReportQlikViewTableau,它们各自用不同的方法解决了上述难题。


  现在的报表主要复杂在后端,即数据源的计算。

n  复杂的业务逻辑。比如:找出连续三个月销售额增长超过10%的销售人员,展示他们的销售额和销量。再比如:找出购买过参数列表中所有itemCustomer,展示这些Customer的帐户余额。

n  跨库计算。比如:某企业要根据绩效和基本工资核算不同工种员工的实际工资,基本工资存储在财务管理软件的MSSQL数据库中,而绩效分数存储在绩效考核系统的Oracle数据库中,请将绩效分数转化为工资数额并呈现在报表中。再比如:某连锁商场各门店都有自己的数据库,总部需要用报表来呈现这些数据的汇总结果。

n  非数据库数据源的计算。比如:根据Excel中的数据,从多只股票中选出连续上涨5天的股票。再比如:根据日志中的数据,展示出指定时间段内每个用户对每种产品的关注时间。

n  多源合并为单源。比如,BIRTCrystal ReportJapserReport等报表工具对多数据库支持不够方便,经常需要编写用户自定义数据源将多源合并为单源。

   

   常见的报表工具只负责将取到的数据呈现出来,不涉及后端数据的生成,报表开发者必须自己想办法解决上述问题,因此报表后端的复杂性一直是困扰报表开发者的最大障碍,也是复杂报表之所以显得复杂的主因。同时,现代报表讲究简洁易读,用户对复杂样式的要求在逐渐降低,而对数据本身的关注程度更高,复杂报表的重点早已从前端呈现转移到后端数据源。事实上,前端的复杂性也大多可以通过后端来解决,比如片区之间有规律的计算、不规则分组,这就使报表数据源的计算更加重要。

 

   解决报表中复杂的数据源计算,可以采用SQL\SP,中间数据库、自定义数据源等三种方式。

   

   SQL\SP理论上可以解决复杂的业务逻辑,但一方面仅限于单数据库的情况,对于其他情况无能为力,比如:非数据库数据源、跨库计算、多源合并为单源。另一方面,复杂业务逻辑并非普通的报表开发者就能轻易实现,往往需要调配更加资深的程序员。由此可见,SQL\SP能解决的问题有限,对人员的要求较高,不足之处非常明显。

   

   中间数据库可以用来实现跨库计算,即把异种数据库的数据加载到同一个数据库,再用报表工具来访问中间数据库中的统一视图。中间数据库一般需要单独配置,会增加额外的成本负担。另外,中间数据库有一个加载的过程,实时性比较差。如果想实现增量实时加载,就需要建立调度任务或在源库中添加触发器和时间戳,并书写较为复杂的数据加载脚本,显然,额外的开发工作量会显著增加。不仅如此,很多商业软件的数据库是不允许擅自修改的,无法添加触发器和时间戳,性能的提升也就无从谈起。由此可见,中间数据库的不足之处是成本高、开发工作量大、实时性和性能得不到保障。


  非数据库数据源的计算也可以采用中间数据库的办法,优缺点也大致相同,区别主要在实时性和成本上。首先,非数据库数据源难以增加触发器和时间戳,无法实现实时计算。其次,很多非数据库数据源的数据量较大,会占用宝贵的数据库存储空间,成本更高。比如前面根据日志数据计算关注时间的例子,商业网站每天的日志都有几千万条,一年的数据可能就有几个TB之多,中间数据库不得不面临频繁升级之苦。大数据量还会对性能产生较大的影响,要想提升数据库的性能,就要采用并行数据库,成本非常昂贵。


  自定义数据源是大部分报表工具都会提供的接口,解决多源合并为单源的问题比较方便,其中最常见的是用户自定义Java Bean。用户自定义Java Bean允许开发者用高级语言将异构数据库、异种数据源、半结构化数据源的数据合并为单一数据源,优点是灵活自由无所不能,但缺点也同样明显。和SQL/esProc/R这类专业的数据计算语言不同,JAVA等高级语言缺乏结构化计算函数,开发者首先要实现过滤、分组、汇总、排名、排序、唯一值、关联算法等大量的底层函数才能进行计算,开发工作量巨大。对于一般甚至是较为简单的算法来说,用高级语言实现都极为困难。

R语言也可以用作自定义数据源。它的优点是库函数丰富,可以进行混合计算,缺点是没有JDBC接口,在性能和稳定性也较差,所以实践中很少有人用它来解决报表数据源中的复杂计算。


润乾公司开发的集算报表不仅可以很好的实现报表的复杂展现问题,也可以很好的完成报表中复杂的数据源计算任务。

集算报表内置了编程语言集算器esProc,是自定义数据源编程的利器。和SQL类似,集算报表的esProc是专业的数据计算语言,具有丰富的结构化数据计算函数,所以可以轻松解决第一类难题:复杂的业务逻辑。和R语言类似,集算报表通过esProc可以直接进行数据库、文本文件、Excel、半结构化数据的混合计算,无需中间库暂存,因此能够实现高性能低成本的跨库计算和非数据库数据源计算。esProc面向应用开发者,语法简单,代码易于书写,交互性强,调试功能完善,因此对开发者的技术要求较低。集算报表可以通过jdbc方式调用esProc,也可以通过定义“集算器数据集”来直接调用。集算报表内置esProc单机并行计算引擎,可以将充分利用多CPU或者多CPU核的计算资源,性能表现优异。

下面举例说明集算报表自定义数据源编程的方法,比如前面跨库计算中的例子“根据绩效分核算实际工资”。

技术分享

l  跨库的关联计算:A5

l  复杂的业务逻辑:A6-C9

l  结构化数据计算函数:A4A10-A13

l  返回输出结果:A14

集算报表调用这个集算器程序的配置如下:

技术分享

 上图中ds1接收esProc返回的结果集,test.dfxesProc的程序文件名。


本文出自 “高性能报表数据计算” 博客,请务必保留此出处http://report5.blog.51cto.com/8028595/1650225

复杂报表复杂在哪?

标签:复杂报表分析   复杂数据源   报表数据源   集算器   集算报表   

原文地址:http://report5.blog.51cto.com/8028595/1650225

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!