向对BI项目有经验的高手请教一下,一个类BI项目的优化或改造

chl 2011-07-14 06:14:55
项目本来是个业务系统,原来的业务并不算太复杂吧,就是产生记录有一定量,记录多的表大概一年几千万吧。

后来要对这个系统加入报表功能,各种数据维度挖掘信息。于是很多开发的工作量都转到了做报表来了。

报表展现用了BO,而数据层为了给BO提供可用数据,用存储过程做数据抽取,放到report表中,这样一来,存储过程写了不下80个,而report表也上70个了。

现在项目经理觉得非常痛苦,因为存储过程太多,难以维护,又不可以重用;report表太多,一个报表做一套report表,已经有好几套了,好多数据信息是类似的,数据库变得越来越大。

预计未来还会接到不同的报表。继续现在的工作方式,则存储过程和report表都会继续膨胀。

我想知道怎样用BI、OLAP、数据仓库等技术来优化或减轻这个项目痛苦?
...全文
2180 点赞 收藏 26
写回复
26 条回复
fredamaths 2012年03月16日
不知道版主的这个问题进展到什么程度了?
回复 点赞
Warren 2012年02月10日
1、核心报表放到Portal上
2、开放Cube权限给相应用户(组),以方便这些用户定制自己的报表;
3、报表不可能满足用用丰富的想象力,处于安全因素,不可能对所有用户开放上面的权限,因此建立一个Service Desk team是有必要的,专门负责服务用户的数据请求。
回复 点赞
pyf_ting 2012年01月13日
数据本身的分析确实比较重要,数据颗粒度问题必须要清楚。 主要是分析出底层统计数据对象,尽量减少存储过程,统计数据对象从大到小的过程需要特别注意,不要什么报表都独立成一个存储过程对象。
回复 点赞
jerry_lyz 2011年11月21日
report表的粒度设计细一些,具备一定的冗余,将相同度量的指标能放到一个表里面的就放到一个表里面。之后再在这些表的基础上进行聚合,形成报表视图。
回复 点赞
dengfeiling 2011年11月18日
让用户自己设计报表,培训也是个挑战。
回复 点赞
hackbaby_lyb 2011年11月17日
都是高手啊,学习了。
回复 点赞
xdop 2011年11月15日
mark顺便顶一下17楼的高见,这真的不是技术问题,是个管理问题
回复 点赞
兔巨侠 2011年11月14日
建立data mart,把能汇总的数据都整合好,然后建立cube,最后才用报表,其实说的这些楼上都已经说了,能有bi延伸出来是好事啊,可以长期维护和挖掘数据来赚钱。。。。
回复 点赞
fredamaths 2011年11月10日
现在的公司跟你是同样的做法,用存储过程把数据插入到report表中,在取report表进行展现。
这报表一天一天的做,以后维护是多么郁闷啊!
回复 点赞
压码路 2011年11月10日
这是不少BI项目中都碰到的问题,很多项目最后都会变成一个庞大的报表系统,然后指标定义混乱。
接决这个问题一方面是从技术角度去整理指标和报表,寻找共性,另一方面还是要用户去谈,否则无法从根源解决问题。建议:
1、先向企业分管业务的老总反映此问题,说明会增加运维成本。
2、通过领导召集相关报表用户,培训他们使用多维查询及导出报表,将报表变化无常的压力分解到业务部门去,IT部门只做指标建模维护。
回复 点赞
555555555555555 2011年10月13日
你们现在的方法比较好。

虽然占用很多空间,但是抛弃了BI的工具。如果你使用BI软件来制作repository,那么你们将面临更多的问题,例如软件升级不同工具的移植转换。

换一个BI软件就要做很多工作。 一个例子就是Oracle从10g 10.1开始引入了Oracle DI,这个东西设计模式是ELT,和其他的BI工具不同,很多其他的BI工具软件使用的是ETL。相比做这个部分的移植和维护,比sql存储过程移植维护就困难多了。

除了这一点,另外一点是sql存储过程的移植还是很多人可以独立完成的,这些人也是可以替代的。但BI维护人员就不同了,一个存储过程很多人能看懂。

所以我认为,就我手头的项目来看,使用存储过程还是上策。容易维护,容易更新,容易升级移植。虽然占用很多空间,对管理要求高。

不同BI工具作出来的功能根本没法移植,就拿Oracle来说Oracle Data Miner和Oracle Data Integrator就没法相互转换,目前来说,我们项目ODM做的activity就没法导入ODI。虽然管理起来很容易很轻松,可是存在这些技术问题。
回复 点赞
zhuxu1234 2011年10月11日
我觉得首先得梳理下业务,做到能预见到以后报表数据的来源等;
然后调整下数据仓库的结构,按主题域设计,如果业务过于简单,那就直接将数据汇总,建立数据集市。以后出报表直接使用已经汇总后的数据进行处理即可。
增加即席查询功能,让用户自己设计报表。
使用功能更强大的报表工具,如cognos

回复 点赞
wangzhewu3 2011年10月10日
来学习,求设计模式
回复 点赞
wangzhewu3 2011年10月10日
来学习,求设计模式
回复 点赞
am2000 2011年09月21日
不要眉毛胡子一把抓
回复 点赞
memoryys 2011年08月20日
study.
回复 点赞
jsphyun 2011年08月20日
来学习的!
回复 点赞
netplanet 2011年08月19日
缺少Data Mart (Star Schema). 一般来说,report应该建立在data mart上而不是直接建立在Dataware House上。Data Mart 由ETL过程(存储过程或者ETL工具)填充。所以应该根据现有的报表需求设计一个或多个Data Mart。尽量把需要的KPI先在一个较细的粒度上在Data Mart里准备好,避免在调用报表时on the fly计算所有KPI
回复 点赞
悠哉小蜗牛 2011年08月19日
可以尝试做一些公共模型出来,前提是必须对业务有很好的了解。前段展现的话只需一些简单的查询语句即可。
回复 点赞
vzyuelei2010 2011年07月21日
[Quote=引用楼主 chliang 的回复:]
项目本来是个业务系统,原来的业务并不算太复杂吧,就是产生记录有一定量,记录多的表大概一年几千万吧。

后来要对这个系统加入报表功能,各种数据维度挖掘信息。于是很多开发的工作量都转到了做报表来了。

报表展现用了BO,而数据层为了给BO提供可用数据,用存储过程做数据抽取,放到report表中,这样一来,存储过程写了不下80个,而report表也上70个了。

现在项目经理觉得非常痛苦,因……
[/Quote]
先分主题域,建对应CUBE,BO可以建对应UNIVERSE。存储过程重构下,生成对应的聚合表里,呵呵,其实SP也还是不错的,关键看怎么用,像你这样的业务做ETL可以,但你这样用SP来做REPORTING就是不对的,呵呵
回复 点赞
发动态
发帖子
数据仓库
创建于2007-09-28

6843

社区成员

6741

社区内容

其他数据库开发 数据仓库
社区公告
暂无公告