微软BI方案参考---来自这些年的工作经验

自我介绍：

在学校的时候从asp转到asp.net从而接触了c#和.net，期间为学校和社会做过很多的门面网站和一个BS的政务系统。毕业后从事BI的开发工作，主要关注SSAS往上的部分，包括复杂的动态报表的开发，后期发现Silverlight的优势所以研究RIA在BI中的应用，并把地图数据也应用进项目。第一个项目就取得了意想不到的效果，也成为了在BI圈里应用RIA方案里比较早的一批吃螃蟹的人。先后经历过公安，保险，广告以及电信行业的BI。

题外话：为什么博客园id是aspnetx而从事的确实BI以及silverlight相关的工作，大致的原因就是如此吧。

正题：

为什么BI，海量数据的统计和分析通过BI的方案，相比于纯TSQL的统计，可以提高查询和分析的性能，另外通过多维分析的方式可以帮助客户更好的去理解数据。

最近总被问到相关的类似问题，所以平时就总结了一些，逐渐有了不成形的积累，大致记录如下。

微软可能受到些制约，所以很多产品在国内的支持力度并不是很给力，从事相关开发的人也相对少一些。本文主要根据我这些年的经验总结，给各位做评估的项目一些参考。

根据情况的不同，文中提及的产品名称没有标注版本，但通常都指其最新版本。后续版本可能会略有变化，但根据笔者的经验不会出现在未来三年中。

微软的BI产品体系：

SQLServer

BI的核心，其中从下到上包括三个部分，SSIS，SSAS，SSRS

SSIS负责ETL以及整体BI的调度。图形话界面比较直观。

SSAS，分析服务，包括Cube和数据挖掘。它也是跟我们通常所见的表和库相同的另外一种独立的库。

SSRS，报表，包括订阅和发布等功能，最新的版本集成了dundas的一些东西，比之前效果好那么一点。

以上三个模块的开发都是通过visual studio shell。

附属产品体系

Office

体现在Excel中，Visio也有一些，但未见过应用。

MOSS

Sharepoint的收费版本，微软的门户解决方案。

PPS被集成到了新版中，就是以前的普科。

按照微软的产品架构的解决方案：

Windows Server

IIS

SQLServer->SSIS-SSAS-SSRA

MOSS->PPS

Office

优点，全套微软的解决方案，各部分无缝集成。前端客户培训成本低，都是其比较熟悉的Office工具。

缺点，完全依赖于微软的体系方案。比如要用PPS的一个功能，那么就被迫要部署MOSS以及购买MOSS整个的授权，对MOSS的维护又是一定的成本。

建议，除非你已经决定了采购微软的这些产品，否则还是建议你阅读完本文。

比较常见的方案：

Windows Server

IIS

SQLServer->SSAS

ETL层自定义框架

前端利用第三方组件自行开发

优点，ETL和UI自己开发，可以解决比较复杂的需求。相对来说对于UI层差别很大，比如据说微软内部很多部门就是自己用Excel去连数据。

缺点，开发维护的成本高。

值得提一句的是，我所最近经历的项目ETL都是由团队自己封装的框架，完全不用SSIS。这个方案微软美国总部的某些专家也有提到。而我之前团队的兄弟们，除非数据量在1000万以内，否则都是宁可自己去实现ETL。

关于为什么舍弃SSIS，先前团队的兄弟们曾反映过一个细节，就是在抽取Oracle数据的时候经常半路死掉，一直找不到问题。后来咨询过一些DBA，他们说是由于Oracle的驱动版本造成的问题。我相信这么一个比较折腾人的细节，就足够让很多兄弟抛弃SSIS这个平台了。

我推荐的方案：

Windows Server

IIS

SQLServer->SSAS

ASP.NET->WebServices

Silverlight

GIS

这个是我一直推荐的BI+RIA+GIS的方案。也就是利用商业智能，加富客户端比较强的展现能力，并通过地图的辅组来为客户更好的展现数据。

需要的知识体系：

操作系统，最基本的操作和维护安装等。

数据库，BI最基本的技能。

IIS，BS的方案现在已经成为方案的首选，另外某些情况下SSAS也要依赖一下IIS

SQL，主要在ETL层用到，而且工作量要超过整个BI的一半以上。

MDX，这个是用来查CUBE的，如果可以数据挖掘，那么还需要DMX。

Powershell，某些东西用它来做会省很多事儿。

.net，Powershell依赖这个，而且下面几样也依赖这个。

C#，封装服务，和silverlight开发用。

Silverlight，相比Flash的话，有经验的.net开发人员接触这个更快。

项目里根据需要可能需要一些第三方商业组件的支持，比如silverlight的chart组件，这个购买一套现成的绝对比投入几个人月去开发合算的多。

国内BI 的现状：

首先，数据质量。这个在很多行业内都存在，数据的质量都比较愁人，比如外键的数值字段居然能出现全角的数字字段。IT力度实施不够也是一个原因，就像教老婆记账一样，老婆不会或者不愿意去做，最后即使做了，得到的数据也是没有意义的。

其次，需求。需求的混乱原因很多，对BI的不了解和对自己本身业务的认知程度。所谓知己知彼百战百胜，但很多行业以及项目实际上并不“知己”。

总之，项目很多，成功的少，大多都是为了报表和面子问题而去BI。

微软的方案适合你吗？

相对于其它解决方案，可以说微软的产品确实存在些不足的地方，但是，随着SQLServer的版本演进，目前的版本来说这个差距应该已经说很小了，当然也不存在其它产品解决的了，而微软的产品解决不了的情况。

如果是遇到实在解决不了的问题，那么我觉得应该首先审视一下BI的建模，然后审视一下需求，因为大多数你费劲去解决的东西，实际上后来都不是用户所关注的，后者是纯粹的面子工程。

实现我的功能需要多长时间？

这个是经常被问到的问题。考虑这个问题主要还是要从几个方面来分析：数据的情况，比如数据量和数据质量等，此外还有需求的复杂程度以及业务的复杂程度，都决定时间的长短。当然这些确定了，项目才可以继续做计划。

另项目基本上都是以螺旋上升的形式来开发，很少说有第一版就成功的，这个过程是需要不断探索和积累的。

相关人员好招聘否以及Team的构建

很少有直接就做BI的人，但基本上都有两种情况，一种是从DBA转过来的，一种是从开发转过来的。我想我是后者。前者偏重底层，后者偏重表层。招聘的时候可以根据这个特点以及项目的情况来选择。

关于Team的构建，我见过比较多的是后边和前边分开的那种。也就是说数据库层的BI开发是管“后边”的人，做.net开发的是“前边”的人。我不反对这种划分，但是按照我的经验来说，一定要注意前后的衔接，虽然两个部分是两个队伍，但是一定要有一个认知就是大家是一个队伍，共同承担着项目的成败。而这里也需要一个天平来做一些决策，有些东西通过后边来解决，可以省很多前边的人的事，而有些东西如果前边稍微处理下，能给后边的人少很多麻烦。

BI有比较合适的参考资源吗？

我建议看SQLServer的Books on line，尽量看英文版吧，中文版有些细节翻译的实在不敢恭维。此外，微软的webcast也很值得在参考，虽然每节课都很长而且比较枯燥和抽象，但还是建议没事看看。

总结：

从某一个产品的角度来讲，也许微软在这小的方面做的不是很好，但是整体来说跟其它方案已经没有什么太大的差距，对，是太大的差距，差距还是有的，但是他的某些优点又足以弥补。此文从一个从业人员的经验角度出发，尽量不带任何感情色彩。部分可能带有本人在某些领域的短见，或者存在着错误以至于误人子弟，还请各位高手们指出。BI是个有潜力的领域，是个有价值的领域，国内也算个新生领域吧，圈子很小，还望有高人给予指点。