自我介绍:
在学校的时候从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是个有潜力的领域,是个有价值的领域,国内也算个新生领域吧,圈子很小,还望有高人给予指点。