7,393
社区成员
发帖
与我相关
我的任务
分享向对BI项目有经验的高手请教一下，一个类BI项目的优化或改造
项目本来是个业务系统，原来的业务并不算太复杂吧，就是产生记录有一定量，记录多的表大概一年几千万吧。
后来要对这个系统加入报表功能，各种数据维度挖掘信息。于是很多开发的工作量都转到了做报表来了。
报表展现用了BO，而数据层为了给BO提供可用数据，用存储过程做数据抽取，放到report表中，这样一来，存储过程写了不下80个，而report表也上70个了。
现在项目经理觉得非常痛苦，因为存储过程太多，难以维护，又不可以重用；report表太多，一个报表做一套report表，已经有好几套了，好多数据信息是类似的，数据库变得越来越大。
预计未来还会接到不同的报表。继续现在的工作方式，则存储过程和report表都会继续膨胀。
我想知道怎样用BI、OLAP、数据仓库等技术来优化或减轻这个项目痛苦？
后来要对这个系统加入报表功能，各种数据维度挖掘信息。于是很多开发的工作量都转到了做报表来了。
报表展现用了BO，而数据层为了给BO提供可用数据，用存储过程做数据抽取，放到report表中，这样一来，存储过程写了不下80个，而report表也上70个了。
现在项目经理觉得非常痛苦，因为存储过程太多，难以维护，又不可以重用；report表太多，一个报表做一套report表，已经有好几套了，好多数据信息是类似的，数据库变得越来越大。
预计未来还会接到不同的报表。继续现在的工作方式，则存储过程和report表都会继续膨胀。
我想知道怎样用BI、OLAP、数据仓库等技术来优化或减轻这个项目痛苦？
...全文
请发表友善的回复…
发表回复
fredamaths 2012-03-16
- 打赏
- 举报
不知道版主的这个问题进展到什么程度了？
Warren 2012-02-10
- 打赏
- 举报
1、核心报表放到Portal上
2、开放Cube权限给相应用户（组），以方便这些用户定制自己的报表；
3、报表不可能满足用用丰富的想象力，处于安全因素，不可能对所有用户开放上面的权限，因此建立一个Service Desk team是有必要的，专门负责服务用户的数据请求。
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部门只做指标建模维护。
接决这个问题一方面是从技术角度去整理指标和报表，寻找共性，另一方面还是要用户去谈，否则无法从根源解决问题。建议：
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。虽然管理起来很容易很轻松，可是存在这些技术问题。
虽然占用很多空间，但是抛弃了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
然后调整下数据仓库的结构，按主题域设计，如果业务过于简单，那就直接将数据汇总，建立数据集市。以后出报表直接使用已经汇总后的数据进行处理即可。
增加即席查询功能，让用户自己设计报表。
使用功能更强大的报表工具，如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就是不对的，呵呵
项目本来是个业务系统，原来的业务并不算太复杂吧，就是产生记录有一定量，记录多的表大概一年几千万吧。
后来要对这个系统加入报表功能，各种数据维度挖掘信息。于是很多开发的工作量都转到了做报表来了。
报表展现用了BO，而数据层为了给BO提供可用数据，用存储过程做数据抽取，放到report表中，这样一来，存储过程写了不下80个，而report表也上70个了。
现在项目经理觉得非常痛苦，因……
[/Quote]
先分主题域，建对应CUBE，BO可以建对应UNIVERSE。存储过程重构下，生成对应的聚合表里，呵呵，其实SP也还是不错的，关键看怎么用，像你这样的业务做ETL可以，但你这样用SP来做REPORTING就是不对的，呵呵
加载更多回复（6）
