本文共 6673 字,大约阅读时间需要 22 分钟。
[推荐]
讨论下:你碰到的业务系统中,报表统计功能如何组织
-
-
- (阿呢陀佛,一切皆空)
- 等 级:
- 结帖率:
-
| 楼主发表于:2009-07-01 11:50:13 在很多业务系统中,往往涉及报表数据统计的功能,这些统计功能往往根据不同的行业、不同的分析角度而进行,不过,其相同点都是对业务明细数据根据需求进行各种统计汇总组合。这些功能在业务数据量较少的前期,一般没什么性能问题,但随着时间、业务的发展,数据量越来越多,而之前的一些速度很快的报表功能会变得越来越慢。这些现象估计有比较多人员在实际中碰到,所以,现在想看看各位日常中是如何解决这种问题的,最好包括从明细数据的组织、报表结果的数据如何组织、功能架构的原理逻辑等一系列的角度说明下。 另外,在数据仓库、数据挖掘等领域,数据量那么大,类似上述的现象问题又是如何解决的? 欢迎大家将实际中的上述类似问题的解决方案分享下,谢谢! ps: 可用分不多,倾我所能了。 | | | |
|
-
-
- (acmain)
- 等 级:
-
| #1楼 得分:5回复于:2009-07-01 11:58:05 建议网上搜索一下 OLTP, OTAP, ETL, 数据仓库的知识。 数据仓库和你所说的现在这种事务的操作数据库数据理今不同。 | | |
|
-
-
- (kjhzls)
- 等 级:
| #2楼 得分:4回复于:2009-07-01 20:42:24 是否能够再建立一个数据库。专门用于查询方面的工作。 | | |
|
-
-
- (威海的风)
- 等 级:
| #3楼 得分:3回复于:2009-07-02 14:57:49 |
|
-
-
- (阿呢陀佛,一切皆空)
- 等 级:
-
| #4楼 得分:0回复于:2009-07-07 16:40:39 1楼你误解我的意思了 我的意思是: 目前很多公司的业务系统,肯定有相关报表统计功能需求的,我想问的一般像这些功能大家平时都怎么去设计的。例如,某公司一个产品系统,一般都会在这个产品系统里附有按多个角度去“统计产品销售汇总”的统计分析功能,当产品记录、销售明细记录少时,直接对明细表进行统计,那肯定是没问题的,假如随着业务的发展,后来产品去到了几百万中,销售记录每天都有几千万条,这时,如果再像业务系统刚建立时直接对源明细表来进行统计的话,那这时肯定会大大影响这个产品系统的性能。 类似上面的案例,大家平时应该碰到很多,我就是想看看大家的解决方案?为什么要这样处理? | | |
|
-
-
- (阿呢陀佛,一切皆空)
- 等 级:
-
| #5楼 得分:0回复于:2009-07-09 11:38:05 |
|
-
-
- (威海的风)
- 等 级:
| #6楼 得分:2回复于:2009-07-09 11:45:13 |
|
-
-
- (acmain)
- 等 级:
-
| #7楼 得分:1回复于:2009-07-09 11:50:08 你的这个问题,已经是数据仓库的概念了。 我们是把数据从在线事务数据库中提取出来,形成data warehouse, 以供报表分析工具使用。在提取中设置不同的维度来实现。 所以仍建议你先看一下数据仓库的概念。 | | |
|
-
-
- (阿呢陀佛,一切皆空)
- 等 级:
-
| #8楼 得分:0回复于:2009-07-09 16:19:17 DW这个我弄过一段时间,是比较独立出来的了, 而我现在要问的,只是一些业务应用系统中一些业务简单的汇总统计功能罢了,难道一个小业务系统,也要专门去搞一个DW来处理,有点太过了吧? 奇怪了,难道你们平时的系统都没有统计功能模块的(例如一些统计报表之类的)?我只是想了解下你们平时在这方面怎么处理的,不会是为了一个系统中某个小统计功能而去搞个DW吧? | | |
|
-
-
- (acmain)
- 等 级:
-
| #9楼 得分:1回复于:2009-07-09 16:24:27 看你的系统有多小了。 如果你的客户不能忍受效率上的问题,则只能把数据预先提出来。 每天晚上跑个脚本,按照事先确定的颗度把数据整理出来,放到另外一个表中。这样早上用户上班的时候就可以进行分析了。 视情况而定,是否需要放到另外一个数据库中,分离的数据库会减小对在线事务数据的影响。 (以上的数据仓库中的一小部分概念,并不是让你去建一个真正的数据仓库) 至于,如果你的系统很小,直接在你的事务表中做查询用户可接受的话,那你当然可以什么都不用做。 | | |
|
-
-
- (阿呢陀佛,一切皆空)
- 等 级:
-
| #10楼 得分:0回复于:2009-07-09 16:30:15 呵,这样的回复才贴切嘛 你上面说了2种方案 但现在问题时,如果要考虑基于这个报表的汇总数据易于扩展呢(即从这个报表的汇总数据,很容易满足给其它一些统计功能利用)? | | |
|
-
-
- (acmain)
- 等 级:
-
| #11楼 得分:1回复于:2009-07-09 16:34:45 你上面说了2种方案 只说了一种方案啊。第二种是什么? 但现在问题时,如果要考虑基于这个报表的汇总数据易于扩展呢(即从这个报表的汇总数据,很容易满足给其它一些统计功能利用)? 这个问题在数据仓库中有提到,如何规则你的数据粒度。总之是要找一个平衡。 | | |
|
-
-
- (阿呢陀佛,一切皆空)
- 等 级:
-
| #12楼 得分:0回复于:2009-07-09 16:45:33 哈,你自己说了都不知道? 1、中间表保存 2、直接在事物表进行查询 但现在问题时,如果要考虑基于这个报表的汇总数据易于扩展呢(即从这个报表的汇总数据,很容易满足给其它一些统计功能利用)? 这个问题在数据仓库中有提到,如何规则你的数据粒度。总之是要找一个平衡。 这样的话,如果要考虑易于扩展的话,那粒度上来说,是不是选择最小粒度来进行保存比较合适?但这样的话,那数据记录数可能就很多(跟明细记录差别不是太大了)。 你认为呢? | | |
|
-
-
- (acmain)
- 等 级:
-
| #13楼 得分:1回复于:2009-07-09 17:19:43 当然最小的粒度就是原表的每条记录。但基本上没有这种需求。 这个你要先自己了解需要哪些维度,然后进行规划。 比如维度有 分店,日期,产品, 数据为数量, 则最小粒度为 (分店,日期,产品) 这个不可能靠一个贴子这种交流来完成设计,需要你的的用户来决定,有经验的BI设计师,会帮助用户考虑到一些东西并提出自己的建议,新手,则只能根据用户要求的来设计,一旦用户半年后提出新的需求要求更细的粒度,则会出现麻烦。 | | |
|
-
-
- (阿呢陀佛,一切皆空)
- 等 级:
-
| #14楼 得分:0回复于:2009-07-09 17:32:59 当然最小的粒度就是原表的每条记录。但基本上没有这种需求。 一般也不会这样做啦,肯定经过一定的转换的嘛 | | |
|
-
-
- (阿呢陀佛,一切皆空)
- 等 级:
-
| #15楼 得分:0回复于:2009-07-09 17:35:13 比如维度有 分店,日期,产品, 数据为数量, 则最小粒度为 (分店,日期,产品) 这个不可能靠一个贴子这种交流来完成设计,需要你的的用户来决定,有经验的BI设计师,会帮助用户考虑到一些东西并提出自己的建议,新手,则只能根据用户要求的来设计,一旦用户半年后提出新的需求要求更细的粒度,则会出现麻烦。 这样看来的话,如果考虑到扩展性,则开始根据业务实际情况定义合适的最小粒度是很重要的咯? | | |
|
-
-
- (威海的风)
- 等 级:
| #16楼 得分:1回复于:2009-07-09 18:04:48 |
|
-
-
- (acmain)
- 等 级:
-
| #17楼 得分:1回复于:2009-07-09 18:47:10 |
|
-
-
- (小井(偶是菜鸟!))
- 等 级:
| #18楼 得分:1回复于:2009-07-09 22:40:49 mark 听听大家的看法! 楼主所提出的问题,也是我所困惑的 | | |
|
-
-
- (冰岛男孩)
- 等 级:
| #19楼 得分:1回复于:2009-07-10 08:35:03 |
|
-
-
- (soupred)
- 等 级:
| #20楼 得分:1回复于:2009-07-10 08:51:42 |
|
-
-
- (why796056)
- 等 级:
| #21楼 得分:1回复于:2009-07-10 11:50:08 |
|
-
-
- (散人)
- 等 级:
| #22楼 得分:1回复于:2009-07-10 14:08:57 根据报表所需要的查询,首先要对数据库进行优化,如建立索引什么的。 对大型的表,可根据需要定时将数据从表中取出,放到另外一个表中,专门供查询用,不影响事务的进行。 数据量再大的话,可以定期从数据库备份数据到另外一个数据库,查询这个数据库了。 如果再大的话,那就用DM和DW,用专门的DTS工具抽取数据,进行重新组织和处理了,就是所谓的数据仓库系统了。 | | |
|
-
-
- (czl923)
- 等 级:
| #23楼 得分:1回复于:2009-07-10 14:50:19 1、这些业务系统大多是分年度进行分析统计的 2、可以用动态表的方式,表名+年度 形式,每年一套;这样可以解决你性能的问题 3、如果表数据量过大的话,可以考虑下采取表分区的形式,这样性能问题可解决部分 希望对你有帮助!!! | | |
|
-
-
- 等 级:
| #24楼 得分:1回复于:2009-07-10 23:39:14 你不会是想用别的解决吧,数据仓库这里数据量大,有几个是在业务层解决的,都是在DB层。 | | |
|
-
-
- (春泥)
- 等 级:
| #25楼 得分:1回复于:2009-07-11 10:09:48 |
|
-
-
- (孤舟)
- 等 级:
| #26楼 得分:1回复于:2009-07-11 18:10:26 |
|
-
-
- (风林火山)
- 等 级:
| #27楼 得分:1回复于:2009-07-13 08:46:55 |
|
-
-
- (QQ熊)
- 等 级:
| #28楼 得分:0回复于:2009-07-13 11:39:39 我倒是觉得现在要是有一种系统的解决问题的方法就好了。这个系统要具备这样几个功能: 1、收集数据。能够根据需要,方便的生成收集数据的页面。(带导出excel表格)(当然要有用户管理、授权的功能) 2、储存数据。 3、分析数据。 | | |
|
-
-
- (D-J)
- 等 级:
| #29楼 得分:0回复于:2009-07-13 12:07:52 | 该回复于2009-07-13 12:10:28被版主删除 | |
|
-
-
- (marskbt)
- 等 级:
| #30楼 得分:0回复于:2009-07-13 13:05:00 没研究过数据仓库,被迫把原来公司做的报表都改成PROCEDURE了,哎,改了我几个月…… -_-b | | |
|
-
-
- (Mark Liang)
- 等 级:
| #31楼 得分:0回复于:2009-07-13 13:53:10 楼主 看你讲内容就知道你走入了一个误区; 一个系统肯定有它能承受能力设计,在设计系统时候就应该对业务量和数据量有所评估。 当业务量和数据量开始飙升或者差不多超过系统能承受压力时候,我们必须改善或者修改系统架构来解决,不是增加一两个表就可以解决了。 当报表速度慢了,我们首先是检查问题出现原因。是SQL 不优化?还是系统数据量太大超过我们估算?是否服务器配置不好等等。 若SQL 不好,可以优化;若数据量太大,之前没有考虑数据量到,只能临时增加一些机制来快速解决,如:每个月对某些特定数据进行统计;若服务器不好,就要求买;出现问题原因很多;但可以总结为:系统使用初中期出现的问题,一般都是SQL不优化 和 对系统数据量评估不足。到了系统使用后期就是数据量爆炸性增加,系统需要修改架构。 | | |
|
-
-
- (阿呢陀佛,一切皆空)
- 等 级:
-
| #32楼 得分:0回复于:2009-07-13 15:38:15 其实你后面提到的那些点,都是在我前面问的解决方案的一部分,你这些方面都是从大的角度去论述。 如果要细一点,我觉得可以如下: 1、物理组织上: 分表(区)、同库、分库、分服务器等; 2、处理逻辑上: 直接查询、采用一般固定式的中间表、采用基于数据仓库的数据中间表(易扩展)等; 3、其它: 表字段数据类型优化、数据表关系设计优化、索引优化、SQL写法优化、硬件资源的优化、任务调度的资源均衡等; | | |
|
-
-
- (阿呢陀佛,一切皆空)
- 等 级:
-
| #33楼 得分:0回复于:2009-07-13 15:50:34 |
|
-
-
- (威海的风)
- 等 级:
| #34楼 得分:0回复于:2009-07-15 09:39:05 哎,目前我做的一个系统初期数据量不是很大,但日积月累那数据也是相当的庞大,系统如何设计好呢? | | |
|
-
-
- (随便逛逛)
- 等 级:
| #35楼 得分:0回复于:2009-07-15 10:41:38 一般按某一用户可变粒度在闲时生成报表,一般不会是即时生成。 报表嘛,肯定是落后于实际的。你如果要及时报表,那统计的数据是不完全的 | | |
|
-
-
- (cuijian0987)
- 等 级:
| #36楼 得分:0回复于:2009-07-15 11:18:19 | 该回复于2009-07-15 11:29:17被版主删除 | |
|
-
-
- (Mark Liang)
- 等 级:
| #37楼 得分:0回复于:2009-07-16 22:22:28 楼主: 这些内容都是一些固定的手法,具体方案选择要多方面来决定没有一个固定形式。 | | |
|
-
-
- (mnyh11)
- 等 级:
| #38楼 得分:0回复于:2009-07-17 11:12:56 |
|
-
-
- (kisler)
- 等 级:
| #39楼 得分:0回复于:2009-07-31 07:48:35 我也遇到过相似的问题,其实我的解决方式很简单,楼主可以参考一下:以前的陈年老数据可以做一个数据库归档,归档方法很多,我是建立另一个库,将陈年数据放到新库里面,再在相关数据表上建一个分区视图,这样不影响用户的数据查询,报表统计的性能也提升了。 | |
转载地址:http://gteli.baihongyu.com/