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

2011-07-14 06:14:55 2.5k 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

第一份BI分析项目总结 BI分析项目总结 1. 结合业务了解数据首先要对相关业务有一定的了解和认知，这样结合业务可以更高效的去了解数据库中包含了哪些数据，这些数据对应的业务是什么，即数据的作用。哪些是基础表（数据），哪些是次要数据，以及这些数据之间的业务关系。在查看数据的同时，要留意数据是否符合条件，如时间戳，颗粒度不够等问题，因为只有数据符合最基本的条件，这样的数据才有价值。只有对数据有了整体的把控后，才... 阅读详情

项目本来是个业务系统，原来的业务并不算太复杂吧，就是产生记录有一定量，记录多的表大概一年几千万吧。

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

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

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

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

我想知道怎样用BI、OLAP、数据仓库等技术来优化或减轻这个项目痛苦？

...全文

让数据中台飞起来—— Quick BI性能优化解决方案及实践 Quick BI“数据门户”在企业数据中台建设中的重要性企业在数据中台初步建设完成以后，怎样让客户直观感受到数据中台的价值？企业决策者、各部门管理人员、业务运营人员如何通过统一的窗口，快速看到数据中台提供的数据，并利用这些数据全方位的支持企业发展？基于Quick BI构建的企业数据门户，有效的解决了上述问题。 Quick BI“数据门户”是数据中台提供给业务人员使用的门户和窗口，以场景化分析的方式，为企业各类人员和角色，提供统一的可视化服务。作为真正触达用户的可视化工具，Quick BI“数据门户”在企阅读详情

chl

数据仓库 7,394 成员 6,741 内容

+ 关注 + 加入社区

切换为时间正序

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就是不对的，呵呵

加载更多回复（6）

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

相关推荐