分析系统的几个技术方案

 

摘要

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

 

 

一切都是T-SQL

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

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

经验：

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

 

 

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

适合的方案：Reporting Services

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

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

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

经验：

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

 

 

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

适合的方案：MOSS+PPS

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

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

经验：

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

 

 

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

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

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

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

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

经验：

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

 

 

对预测要求比较高的

适合的方案：接口提供

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

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

经验：

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

 

 

总结

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