现在的位置: 首页 > 综合 > 正文

分析系统的几个技术方案

2012年06月29日 ⁄ 综合 ⁄ 共 1841字 ⁄ 字号 评论关闭

 

摘要

分析系统通常作为整个IT系统的一部分,具体技术上的划分属于BI的范畴,对于一个大型的信息系统来说,分析模块是比较重要的一块,这里根据常见的需求,以及个人的一些经验,总结出若干技术方案以供参考。

 

 

一切都是T-SQL

就是所有的统计数据都是通过SQL语句从存储过程中得到,这样的方案我见过很多,通常都是数据非常少,而且是需求特别明确的情况。

另也有高手用类似Cube聚合的方法将要统计的数据按照各个维度粒度存放好(若干表中),这样的方案也未尝不可,如果一定要抛弃已成型的技术产品的话。

经验:

有几个项目最终会是如此简单呢?所以这是我极其不推荐的一个方案。无论怎样,这都是效率最低,最不灵活风险最高的一个方案。除非你真的能限制住用户的需求,或者用户的需求就是确定的。

 

 

对报告的格式和输出要求比较高的

适合的方案:Reporting Services

这类报表在很多行业中都可能遇到,比如下面这张:

image

这类报表的特点是行列比较多,格式比较固定,通常要求系统严格按照这个格式来出。对格式的要求,我曾经见过最变态的是,将输出的表格跟表样对着阳光比,差一个像素都不行。而不得不提的是,SSRS的设计和输出往往都会有些误差,这一点跟word差不多,相信很多写过毕业论文的朋友多会有这样的经验,所以调整起来往往都是一个痛苦的过程。

再就一点,这样的报表量需求往往都非常大,尤其是政务部门,通常都会100张以上。

经验:

从目前来说确实没有什么比较好的方案可以取代这个方法,而且本身报表服务的授权是在整个SQLServer授权当中的,所以没有理由不用它。

 

 

对报告的快速开发要求高的

适合的方案:MOSS+PPS

image

通常比较适合对报表或者报告的格式没有什么明确的要求,只要求将数据表述明白,而要求就是能快速的制作出来。比如领导明天要看这个月各方面费用的支出情况,那么很明显通过PPS是最快的,而且借助MOSS的平台发布也很容易。

另外也可以考虑第三方的解决方案,比如Dundas,微软曾购买过很多它的产品集成到SQLServer中。先前这家公司是做组件的,但是现在只做Dashboard了,效果也很不错:

image

经验:

如果在整体的解决方案中,这里只OLTP+OLAP,没有MOSS的规划的话,那么为了PPS而去部署一个MOSS实例明显是不明智的,暂且不说MOSS的授权费用以及部署开发和维护的难度,毕竟BI只占MOSS里很小的一部分,所以这个时候考虑一些第三方的解决方案也是可取的。

 

 

对炫丽程度要求高以及有特殊功能需求的

适合的方案:Silverlight等其它RIA方案。

通常都是用户给领导看的,需要互动性比较强,而且绚丽程度比较高的。

image

还记得07年之前,那个时候开发一些特殊的BI应用,只能硬着头皮用asp.net去写,而且还要关注麻烦的webform页面架构的页面周期的各个阶段,那个时候考虑过RIA的方案,不过苦于Flash上手实在别扭(不是困难,大家都懂的)。幸运的是微软后来出Silverlight了,这对于苦苦寻求前端方案的我们来说是一个好消息,而后来在BI中成功应用RIA 方案,确实在用户中(尤其是政务部门)取得了不错的反响。

很多很难的问题,通过.netcoding都会很好的解决,所以适合开发一些极端特殊的分析方法。

经验:

设计,封装,在这里很重要。对用户需求的理解,以及对这个行业的理解,会直接影响到这两个方面输出的结果。所以这也是对技术点覆盖最广的一个方案。

 

 

对预测要求比较高的

适合的方案:接口提供

预测和挖掘是BI中最高的一个层次,实现的思路基本就是根据历史的数据,通过一定的数学算法发现一定的规律,然后判断一个位置的数据某属性是什么样的。购物网站上的商品推荐通常都是通过这种方式实现的。

这种比较合适的方案是模块中通过Services的方式暴露给其它系统做访问接口,从而得到预测结果的数据。

经验:

预测的前提是,数据,要大量的数据,而且是真实数据,最关键的是有质量的数据。这些就好比你请律师,那么即使你是原告也要告诉律师最真实的情况,而且不要落下细节,如果碍于面子而隐瞒或者伪造了什么,那么律师再有能力也帮不到你。

 

 

总结

以上对技术的实现方案做了一个大体的总结,不是很全但应该可以覆盖大多数需求了。其实比较难的还是做Solution,就是跟客户说为什么用微软的产品而不是其它产品,本文涉及技术架构的方面比较多。诚然微软在这方面的各方面资源都要欠缺很多,但这些微软已经在不断的做改善,而且目前的产品已经相对成熟。

抱歉!评论已关闭.