ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 技术相关:从报表工具的选型说起

技术相关:从报表工具的选型说起

原创 Linux操作系统 作者:szandrew 时间:2009-07-18 10:34:40 1 删除 编辑
技术相关:从报表工具的选型说起
--王珏原创

    反思最近5年来的项目经验,想起了我们项目组的“报表工具”的选型。非常有意思的是,我所在项目组的“报表工具”总是能够在公司范围内得以推广,但推广后却又招来一片骂声。
    最初我们使用的报表工具是“明宇报表”,这个报表我没太多的体会,因为我到这个公司的时候,公司内部已经在使用这个报表工具了,它的选型以及在公司的退出和我没有任何关系。
    故事真正的开始在2004年低,我们公司接到某省电信的一个所谓“综合资源管理系统”的项目(开拓性的项目)。当时的设计目标差不多就是(我主要从技术角度说明问题,不提或少提那些电信业务):
  1. 整合。整合历史遗留的多个资源管理系统。

  2. 想怎么查,就怎么查”。说的具体点,就是查询条件不确定(不是条件的值不确定,而是条件本身不确定),备查对象也不确定。说的抽象点,就是不满足于作业控制层的信息系统,需要构建知识管理层以上的信息系统(参见:需求相关:以“信息库”的思想建设“管理系统”)。

  3. 其他就是所谓的电信的“支持前端”之类的业务要求(于本主题无关,在此不在赘述)。
    大概一看到这种需求,第一感就是:“整合”这种需求需要按照数据仓库的模式来,啥ETL,数据复制呀之类的。“查询”需求需要DSS之类的工具,而我直接 接触过的DSS工具还是大约在98年在深圳做程序员时使用的Delphi中所内带的DSS工具。经过一些简单的选型工作(1、内部同事推荐。2、上网搜搜 哪个BI工具市场占有率高)很容易就找到了Microstrategy的产品MSTR。找到这个工具后我才发现,原来此电信早就在其一个专业资源系统中使用了这个工具。剩下来的就是我们项目组的与众不同了:
  • 整理的所有的业务数据,按照“维度”,“度量”,“层次”等概念进行建模。(至今我还保留着我绘制的MindManager的模型脑图,这也是我们项目组作重要的文档(参见:配置管理:文档配置库不是历史的垃圾堆))
    其实这些工作,也就是简单到“按照MSTR的说明书”办事。正如,规范设计,规范施工就不会有房屋质量问题一样。奇怪的是,客户以前虽然也用 Microstrategy但却拿它当报表工具用,自然也指出了MSTR一大堆的不是。然而,随着我们项目在使用MSTR方面取得的成功,不仅仅使得客户 对MSTR这个产品异常喜欢(还单独购买的MSTR的license),而且我们公司内部也立刻把Microstrategy作为主力工具进行推广(包括 商务上的推广)。然而,没过多久(我们项目组完成项目后的自然解散),在其他项目组中,当Microstrategy沦落为报表工具以后,大家也就骂声一 片了。

    第二个故事是在2007年,那时我接手一个“互联网业务分析系统”,业务需求简单来说,就是要在应用层进行协议分析,自然也需要进行“报表”以及“数据分 析”的工作。Microstrategy被否认的直接原因有两个:1、花费太大(主要原因);2、Microstrategy是一个独立的系统,无法和我 们的网管系统有效整合(这还是个次要原因)。
    这样我们项目组就有面临对于报表工具的再次选择,公司给我们的要求是:1、开源;2、Java实现的便于和我们的网管系统整合。选择过程也不复杂,经过1、个人推荐;2、上网搜搜当下最流行的报表工具。而我又给加上了一个要求,必须选择一个BI工具,原因是:
  1. 适应“需求的变化”。我们的项目需求存在很多不确定性因素,而单纯的报表工具没法适应需求的变化。
  2. 开发人手紧缺。单纯的报表工具报表要一张一张的开发浪费成本,而BI工具在模型建立完成后,剩下的工作就不多了。
  3. 开发过程必须适应“敏捷”。为了让项目过程“可视化”,必须要求在每一个阶段(差不多每一个月)都能有“看得见进展”体现在“可运行的系统”上。
  4. “内 容”比“形式”更重要。在我看来,内容正确了,形式可以再进行调整;反之,内容失败了,项目也就失败了。极端情况,即使当BI工具开发出内容合适的报表, 但用户就是不认可其形式,我们再用其他开发工具再把这报表的格式调整到用户满意(可以充分适应需求的变化),所花销的成本都是可接受的。(这也是我的开发 理念:需求相关:以“信息库”的思想建设“管理系统”
    经过上面的要求,我们项目组很容易就锁定了“JPivot+Mondrian”,同样当我们建立了MDX模型后,后面的项目过程也就一帆风顺(除了被领导、QA们经常指责我们的系统“太丑”以外)。
    随着JPivot+Mondrain这种BI工具在我们项目组的成功,此价格便宜量又足的工具又在公司内部进行大力推广。遗憾的是,随着时间的推移,这对工具又是骂声一片。原因很简单:
  1. 做报表太过于复杂。不建模就做报表,当然复杂喽。
  2. 报表样式不符合“需求”。

    当BI工具沦落为报表工具,这也就是它们的宿命。那么从技术选型来看,常常犯的错误又是什么呢?我个人认为大约有如下几点:
  1. 拿某个“工具”当万金油,以为它能解决所有问题。(判断标准,可以参见: 银弹规则在技术选型时的运用)。
  2. 不能深入理解一个工具存在的意义,换句话说就是它的优点是什么?不理解它适合于做什么?
  3. 缺 乏分析设计,越高级的工具,起到的负面作用越大。换句话说,越是高级的工具,需要的技能越多,学习周期越长,为了有效的利用这个工具,需要的设计规划也越 多。举例来说,用电脑打字,在很多情况下并不比纸和笔更好用,如果做一个有“规划”的文字编辑工作,电脑就比纸和笔强很多了。

上述所谓的“BI”混淆了“BI展现工具”和“BI”概念区别,这样有助于说明本文的主要问题。完整的BI应该是:ETL、数据仓库、OLAP、数据挖掘、数据展现等技术的综合运用(参见:wiki商业智能)。但由于项目的规模,数据量的规模,以及一系列的限制条件,因此在项目中首先遇到的一般都是BI数据展现部分,因此我本文中不对此作出严格区别。


Link URL: http://blog.sina.com.cn/s/blog_592060b50100e005.html

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/91771/viewspace-609553/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2009-07-18

  • 博文量
    18
  • 访问量
    25992